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.
Servicios regionales
Los servicios regionales son servicios que AWS se basan en varias zonas de disponibilidad para que los clientes no tengan que averiguar cómo aprovechar al máximo los servicios zonales. Agrupamos de forma lógica el servicio implementado en varias zonas de disponibilidad para ofrecer a los clientes un único punto final regional. Amazon SQS y Amazon DynamoDB
AWS cree que la mayoría de los clientes pueden alcanzar sus objetivos de resiliencia en una sola región mediante el uso de servicios regionales o arquitecturas Multi-AZ que se basan en servicios zonales. Sin embargo, algunas cargas de trabajo pueden requerir redundancia adicional, y puede utilizar el aislamiento Regiones de AWS para crear arquitecturas multirregionales con fines de alta disponibilidad o continuidad empresarial. La separación física y lógica entre ellas Regiones de AWS evita los fallos correlacionados entre sí. En otras palabras, al igual que si fuera un EC2 cliente y pudiera beneficiarse del aislamiento de las zonas de disponibilidad mediante la implementación en todas ellas, puede obtener el mismo beneficio con los servicios regionales si se despliegan en varias regiones. Esto requiere que implemente una arquitectura multirregional para su aplicación, lo que puede ayudarle a resistir las deficiencias de un servicio regional.
Sin embargo, lograr los beneficios de una arquitectura multirregional puede resultar difícil; requiere un trabajo cuidadoso para aprovechar el aislamiento regional y, al mismo tiempo, no deshacer nada a nivel de aplicación. Por ejemplo, si va a realizar la conmutación por error de una aplicación entre regiones, debe mantener una separación estricta entre las pilas de aplicaciones de cada región, tener en cuenta todas las dependencias de la aplicación y realizar la conmutación por error de todas las partes de la aplicación a la vez. Lograrlo con una arquitectura compleja basada en microservicios que tiene muchas dependencias entre las aplicaciones requiere planificación y coordinación entre muchos equipos empresariales y de ingeniería. Permitir que las cargas de trabajo individuales tomen sus propias decisiones de conmutación por error hace que la coordinación sea menos compleja, pero introduce un comportamiento modal gracias a la importante diferencia de latencia que se produce entre las regiones y dentro de una sola región.
AWS por el momento, no proporciona una función de replicación sincrónica entre regiones. Cuando se utiliza un almacén de datos replicado de forma asíncrona (proporcionado por AWS) entre regiones, existe la posibilidad de que se pierdan datos o se produzcan incoherencias si se conmuta por error la aplicación entre regiones. Para mitigar las posibles incoherencias, necesita un proceso de reconciliación de datos fiable en el que pueda confiar y que pueda tener que funcionar en varios almacenes de datos de su cartera de cargas de trabajo, o bien estar dispuesto a aceptar la pérdida de datos. Por último, debe practicar la conmutación por error para saber que funcionará cuando la necesite. La rotación periódica de la solicitud entre regiones para practicar la conmutación por error supone una inversión considerable de tiempo y recursos. Si decide utilizar un almacén de datos replicado de forma sincrónica en todas las regiones para dar soporte a sus aplicaciones que se ejecutan desde más de una región al mismo tiempo, las características de rendimiento y la latencia de una base de datos de este tipo, que abarca cientos o miles de millas, son muy diferentes a las de una base de datos que opera en una sola región. Esto requiere que planifique su pila de aplicaciones desde cero para tener en cuenta este comportamiento. También hace que la disponibilidad de ambas regiones sea una fuerte dependencia, lo que podría reducir la resiliencia de la carga de trabajo.
