Servicios zonales

Availability Zone Independence (AZI) AWS permite ofrecer servicios zonales, como Amazon EC2 y Amazon EBS. Un servicio zonal es aquel que permite especificar en qué zona de disponibilidad se implementan los recursos. Estos servicios funcionan de forma independiente en cada zona de disponibilidad de una región y, lo que es más importante, también fallan de forma independiente en cada zona de disponibilidad. Esto significa que los componentes de un servicio de una zona de disponibilidad no dependen de los componentes de otras zonas de disponibilidad. Podemos hacerlo porque un servicio zonal tiene planos de datos zonales. En algunos casos, como en el caso de EC2, el servicio también incluye planos de control zonales para operaciones alineadas por zonas, como el lanzamiento de una instancia de EC2. Para esos servicios, AWS también proporciona un punto final en el plano de control regional para facilitar la interacción con el servicio. El plano de control regional también proporciona una funcionalidad de ámbito regional y sirve como capa de agregación y enrutamiento sobre los planos de control zonales. Esto se muestra en la siguiente figura.

Un servicio zonal con planos de control y planos de datos aislados por zonas

Las zonas de disponibilidad ofrecen a los clientes la posibilidad de operar cargas de trabajo de producción con mayor disponibilidad, tolerancia a errores y escalables de lo que sería posible en un solo centro de datos. Cuando una carga de trabajo utiliza varias zonas de disponibilidad, los clientes están mejor aislados y protegidos de los problemas que afectan a la infraestructura física de una única zona de disponibilidad. Esto ayuda a los clientes a crear servicios redundantes en todas las zonas de disponibilidad y, si se diseñan correctamente, permanecen operativos incluso si una zona de disponibilidad sufre errores. Los clientes pueden aprovechar AZI para crear cargas de trabajo resilientes y de alta disponibilidad. La implementación de AZI en su arquitectura le ayuda a recuperarse rápidamente de un error aislado en una zona de disponibilidad, ya que los recursos de una zona de disponibilidad minimizan o eliminan la interacción con los recursos de otras zonas de disponibilidad. Esto ayuda a eliminar las dependencias entre zonas de disponibilidad, lo que simplifica la evacuación de las zonas de disponibilidad. Consulte los patrones de resiliencia avanzados para zonas de disponibilidad múltiples (Multi-AZ) para obtener más información sobre la creación de mecanismos de evacuación en las zonas de disponibilidad. Además, puede aprovechar aún más las zonas de disponibilidad si sigue algunas de las mismas prácticas recomendadas que se AWS utilizan para sus propios servicios, como implementar solo los cambios en una única zona de disponibilidad a la vez o eliminar una zona de disponibilidad del servicio si un cambio en esa zona de disponibilidad no funciona correctamente.

La estabilidad estática también es un concepto importante para las arquitecturas de zonas de disponibilidad múltiple. Uno de los modos de error que debe tener en cuenta con las arquitecturas de zonas de disponibilidad múltiple es la pérdida de una zona de disponibilidad, lo que puede provocar la pérdida de la capacidad de una zona de disponibilidad. Si no ha aprovisionado previamente suficiente capacidad para hacer frente a la pérdida de una zona de disponibilidad, la carga actual podría sobrecargar la capacidad restante. Además, tendrá que depender de los planos de control de los servicios zonales que utilice para reemplazar la capacidad perdida, lo que puede resultar menos fiable que un diseño estable desde el punto de vista estático. En este caso, aprovisionar previamente suficiente capacidad adicional puede ayudarle a mantener una estabilidad estática ante la pérdida de un dominio de errores, como una zona de disponibilidad, al poder continuar con sus operaciones normales sin necesidad de cambios dinámicos.

Puede optar por utilizar un grupo de instancias EC2 de escalado automático implementado en varias zonas de disponibilidad para escalar dinámicamente los niveles de entrada y salida, en función de las necesidades de su carga de trabajo. El escalado automático funciona bien para los cambios graduales en el uso que se producen entre minutos y decenas de minutos. Sin embargo, el lanzamiento de nuevas instancias de EC2 lleva tiempo, especialmente si las instancias requieren un arranque (por ejemplo, instalar agentes, binarios de aplicaciones o archivos de configuración). Durante este tiempo, la capacidad restante podría verse abrumada por la carga actual. Además, la implementación de nuevas instancias mediante el escalado automático depende del plano de control EC2. Esto supone una compensación: para mantener la estabilidad estática ante la pérdida de una única zona de disponibilidad, debe aprovisionar previamente suficientes instancias de EC2 en las demás zonas de disponibilidad para gestionar la carga que se ha desplazado fuera de la zona de disponibilidad afectada, en lugar de confiar en el escalado automático para aprovisionar nuevas instancias. Sin embargo, el aprovisionamiento previo de capacidad adicional puede suponer un coste adicional.

Por ejemplo, durante el funcionamiento normal, supongamos que su carga de trabajo requiere seis instancias para atender el tráfico de clientes en tres zonas de disponibilidad. Para mantener la estabilidad estática frente a un error en una sola zona de disponibilidad, debe implementar tres instancias en cada zona de disponibilidad, es decir, nueve en total. Si fallara una sola instancia equivalente a una zona de disponibilidad, aún le quedarían seis y podría seguir atendiendo al tráfico de clientes sin necesidad de aprovisionar ni configurar nuevas instancias durante el fallo. Lograr una estabilidad estática para la capacidad de EC2 conlleva un coste adicional, ya que, en este caso, se está ejecutando un 50% más de instancias. No todos los servicios en los que puede aprovisionar recursos previamente conllevarán costes adicionales, como el aprovisionamiento previo de un bucket de S3 o un usuario. Deberá sopesar las desventajas de implementar la estabilidad estática con el riesgo de superar el tiempo de recuperación deseado para su carga de trabajo.

AWS Las Zonas Locales y los Outposts acercan el plano de datos de determinados AWS servicios a los usuarios finales. Los planos de control de estos servicios residen en la región principal. Tu instancia de Local Zone o Outposts tendrá dependencias en el plano de control para servicios zonales como EC2 y EBS en la zona de disponibilidad en la que creaste la zona local o la subred de Outposts. También dependerán de los planos de control regionales para los servicios regionales, como Elastic Load Balancing (ELB), los grupos de seguridad y el plano de control de Kubernetes administrado por Amazon Elastic Kubernetes Service (Amazon EKS) (si usa EKS). Para obtener información adicional específica sobre Outposts, consulta la documentación y las preguntas frecuentes sobre soporte y mantenimiento. Implemente la estabilidad estática cuando utilice Zonas Locales o Outposts para ayudar a mejorar la resiliencia y controlar las deficiencias del avión o las interrupciones en la conectividad de la red con la Región principal.