Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Apéndice B: Guía de servicio global de redes periféricas

En el caso de los servicios globales de redes periféricas, debe implementar la estabilidad estática para mantener la resiliencia de su carga de trabajo durante un deterioro del plano de control de AWS servicios.

Route 53

El plano de control de Route 53 consta de todas las API públicas de Route 53 que cubren la funcionalidad de las zonas alojadas, los registros, las comprobaciones de estado, los registros de consultas de DNS, los conjuntos de delegación reutilizables, las políticas de tráfico y las etiquetas de asignación de costos. Se encuentra alojado en la us-east-1. El plano de datos es el servicio DNS autorizado, que se ejecuta en más de 200 ubicaciones PoP y responde a las consultas de DNS Región de AWS en función de las zonas alojadas y los datos de comprobación de estado. Además, Route 53 tiene un plano de datos para las comprobaciones de estado, que también es un servicio distribuido a nivel mundial en varios. Regiones de AWS Este plano de datos realiza comprobaciones de estado, agrega los resultados y los datos de DNS público y privado de Route 53 y. Durante una alteración del plano de control, es posible que las operaciones de tipo CRUDL para la Ruta 53 no funcionen, pero la resolución del DNS y las comprobaciones de estado, y las actualizaciones del enrutamiento que resulten de los cambios en las comprobaciones de estado, seguirán funcionando.

Esto significa que cuando planifique dependencias en la Ruta 53, no debe confiar en el plano de control de la Ruta 53 en su ruta de recuperación. Por ejemplo, un diseño estable desde el punto de vista estático consistiría en utilizar el estado de las comprobaciones de estado para realizar conmutaciones por error entre regiones o para evacuar una zona de disponibilidad. Puede utilizar los controles de enrutamiento del controlador de recuperación de aplicaciones (ARC) de Route 53 para cambiar manualmente el estado de las comprobaciones de estado y modificar las respuestas a las consultas de DNS. Existen patrones similares a los que proporciona ARC que puede implementar en función de sus requisitos. Algunos de estos patrones se describen en Creación de mecanismos de recuperación ante desastres mediante la Ruta 53 y en la sección de disyuntores de verificación del estado avanzados de patrones de resiliencia Multi-AZ. Si ha optado por utilizar un plan de DR multirregional, aprovisione previamente los recursos que requieran la creación de registros DNS, como las instancias de ELB y RDS. Un non-statically-stable diseño consistiría en actualizar el valor de un registro de recursos de Route 53 mediante la ChangeResourceRecordSets API, cambiar el peso de un registro ponderado o crear nuevos registros para realizar la conmutación por error. Estos enfoques dependen del plano de control de la Ruta 53.

Amazon CloudFront

El plano de CloudFront control de Amazon consta de todas las CloudFront API públicas para administrar las distribuciones y está alojado en us-east-1. El plano de datos es la propia distribución servida desde PoPs la red perimetral. Realiza la gestión de solicitudes, el enrutamiento y el almacenamiento en caché del contenido de origen. Durante una alteración del plano de control, es posible que las operaciones de tipo CRUDL para CloudFront (incluidas las solicitudes de invalidación) no funcionen, pero el contenido seguirá almacenándose en caché y publicándose, y las conmutaciones por error de origen seguirán funcionando.

Esto significa que, cuando planifique dependencias enCloudFront, no debe confiar en el plano de CloudFront control en su ruta de recuperación. Por ejemplo, un diseño estable desde el punto de vista estático consistiría en utilizar conmutaciones por error de origen automatizadas para mitigar el impacto de una discapacidad en uno de sus orígenes. También puede optar por crear un equilibrio de carga de origen o una conmutación por error con Lamda @Edge. Consulte Tres patrones de diseño avanzados para aplicaciones de alta disponibilidad con Amazon CloudFront y Amazon S3 para crear aplicaciones de geolocalización activa CloudFront y activa multirregiones para obtener más información sobre ese patrón. Un non-statically-stable diseño consistiría en actualizar manualmente la configuración de la distribución en respuesta a un error de origen. Este enfoque dependería del plano CloudFront de control.

Certificate Manager

Si utiliza certificados personalizados en su CloudFront distribución, también depende de ACM. El uso de certificados personalizados en la CloudFront distribución se basa en el plano de control ACM en la región us-east-1. Durante una alteración del plano de control, los certificados existentes configurados en su distribución seguirán funcionando, al igual que las renovaciones automáticas de certificados. No confíe en cambiar la configuración de la distribución ni en crear nuevos certificados como parte de su ruta de recuperación.

AWSFirewall de aplicaciones web (WAF) y WAF Classic

Si lo utiliza AWS WAF con su CloudFront distribución, depende del plano de control de WAF, que también está alojado en la región us-east-1. Durante una alteración del plano de control, las listas de control de acceso web (ACL) configuradas y sus reglas asociadas siguen funcionando. No confíe en la actualización de las ACL web de WAF como parte de su ruta de recuperación.

AWS Global Accelerator

El plano de control AGA consta de todas las API AGA públicas y está alojado en us-west-2. El plano de datos es el enrutamiento de red de las direcciones IP anycast proporcionadas por AGA a los puntos finales registrados. AGA también utiliza las comprobaciones de estado de Route 53 para determinar el estado de sus puntos finales de AGA, que forman parte del plano de datos de Route 53. Durante una alteración del plano de control, es posible que las operaciones tipo CRUDL para AGA no funcionen. El enrutamiento a los puntos finales existentes, así como las configuraciones existentes de comprobaciones de estado, marcación de tráfico y peso de puntos finales que se utilizan para enrutar o desviar el tráfico a otros puntos finales y grupos de puntos finales, seguirán funcionando.

Esto significa que, al planificar las dependencias de AGA, no debe confiar en el plano de control de AGA en su ruta de recuperación. Por ejemplo, un diseño estable desde el punto de vista estático consistiría en utilizar el estado de las comprobaciones de estado configuradas para evitar errores en los puntos finales que no estén en buen estado. Consulte Implementación de aplicaciones multirregionales AWS con AWS Global Accelerator para ver ejemplos de esta configuración. Un non-statically-stable diseño consistiría en modificar los porcentajes de marcado de tráfico de la AGA, editar los grupos de puntos finales o eliminar un punto final de un grupo de puntos finales durante una discapacidad. Estos enfoques dependerían del plano de control de la AGA.

Amazon Shield

El plano de control de Amazon Shield Advanced consta de todas las API públicas de Shield Advanced y está alojado en us-east-1. Esto incluye funciones como CreateProtectionCreateProtectionGroup, AssociateHealthCheckDesribeDRTAccess, yListProtections. El plano de datos es la protección contra ataques DDoS que proporciona Shield Advanced, así como la creación de las métricas de Shield Advanced. Shield Advanced también utiliza las comprobaciones de estado de Route 53 (que forman parte del plano de datos de Route 53), si las ha configurado. Durante una alteración del plano de control, es posible que las operaciones de tipo CRUDL para Shield Advanced no funcionen, pero la protección contra DDoS configurada para sus recursos, así como las respuestas a los cambios en las comprobaciones de estado, seguirán funcionando.

Esto significa que no debe confiar en el plano de control de Shield Advanced en su ruta de recuperación. Si bien el plano de control de Shield Advanced no proporciona la funcionalidad directa que normalmente utilizaría en una situación de recuperación, puede haber ocasiones en las que sí lo haga. Por ejemplo, un diseño estable desde el punto de vista estático sería tener los recursos de DR ya configurados para formar parte de un grupo de protección y tener asociadas las comprobaciones de estado, en lugar de configurar esa protección después de que se produzca el error. Esto evita depender del plano de control de Shield Advanced para la recuperación.