Diseño de infraestructura

Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZ

Explicamos cómo us-east-1a apunta a diferentes AZ físicas por cuenta, por qué se introdujeron los AZ ID (use1-az1), la intención de diseño de distribución uniforme de capacidad y las consideraciones para la especificación de AZ entre cuentas.

約 3 分で読めます

us-east-1a no es el mismo lugar para todos

Los nombres de Availability Zone de AWS (us-east-1a, us-east-1b, etc.) se mapean a diferentes AZ físicas por cuenta. La us-east-1a de la cuenta A y la us-east-1a de la cuenta B pueden apuntar a centros de datos físicamente diferentes. Este diseño es intencional por parte de AWS para distribuir uniformemente la capacidad. Si todos los usuarios se concentraran en us-east-1a, esa AZ específica se sobrecargaría. Al aleatorizar el mapeo por cuenta, la carga se distribuye naturalmente entre todas las AZ físicas.

Introducción de AZ ID - Identificación única de AZ físicas

Dado que el mapeo de nombres de AZ difiere por cuenta, se necesitaba un método para especificar la misma AZ física entre cuentas. Por ejemplo, al compartir subredes entre cuentas con RAM (Resource Access Manager), es necesario especificar la misma AZ física. Para esto se introdujeron los AZ ID. Los AZ ID (como use1-az1, use1-az2) son identificadores que apuntan de forma consistente a la misma AZ física independientemente de la cuenta. Están disponibles en la consola de EC2 y a través de la API, permitiendo la coordinación precisa de AZ entre cuentas.

Implementación del mapeo - Cómo se determina

El mapeo entre nombres de AZ y AZ físicas se asigna aleatoriamente al crear la cuenta. AWS no publica el algoritmo de mapeo, pero se han determinado algunas características a partir de observaciones. Primero, el mapeo es fijo por cuenta y no cambia con el tiempo. Segundo, el mapeo es independiente por región, por lo que el patrón de mapeo en us-east-1 no tiene relación con el de us-west-2. Tercero, el número de AZ disponibles varía por región, y el mapeo se ajusta en consecuencia.

Casos donde el mapeo de AZ se convierte en un problema

Hay casos donde las diferencias en el mapeo de AZ causan problemas reales. El más común es el costo de transferencia de datos entre cuentas. Si la us-east-1a de la cuenta A (física: use1-az1) y la us-east-1a de la cuenta B (física: use1-az2) son AZ físicas diferentes, la comunicación entre ellas incurre en cargos de transferencia entre AZ. Para evitar esto, es necesario alinear usando AZ ID. Otro caso es el diseño de alta disponibilidad multi-cuenta, donde es importante entender qué AZ físicas se están utilizando realmente para diseñar adecuadamente los dominios de fallo.

Local Zones y Wavelength Zones - Conceptos extendidos de AZ

Como extensiones del concepto de AZ existen Local Zones y Wavelength Zones. Las Local Zones son infraestructura a pequeña escala ubicada fuera de las regiones de AWS, proporcionando cómputo y almacenamiento de baja latencia en ciudades específicas. Las Wavelength Zones están integradas en redes de operadores de telecomunicaciones, proporcionando latencia ultra baja para aplicaciones 5G. Ambas se gestionan como extensiones de AZ, pero tienen características diferentes a las AZ estándar en cuanto a servicios disponibles y modelos de precios. Para profundizar en diseño de infraestructura y arquitectura de AZ, los libros relacionados (Amazon) también pueden ser útiles.

Servicios relacionados

Amazon EC2Un servicio de cómputo que proporciona servidores virtuales en la nubeAWS Resource Access ManagerComparta recursos de AWS de forma segura con otras cuentas dentro de su organización

Artículos relacionados

Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.La estructura oculta de los 12 dígitos del ID de cuenta de AWS - Por qué son 12 dígitos y qué se puede inferirUna exploración curiosa de por qué los ID de cuenta de AWS son números de 12 dígitos, la intención de diseño incorporada en la estructura ARN, y las consideraciones de seguridad sobre lo que se puede inferir a partir de un ID de cuenta.

Más sobre este tema

Por qué Auto Scaling escala rápido hacia afuera y es cauteloso al reducir - Intención de diseño de la lógica de decisión asimétricaExplica la razón del diseño asimétrico de EC2 Auto Scaling que ejecuta el scale-out inmediatamente mientras establece un período de enfriamiento para el scale-in, el mecanismo de prevención de flapping y la lógica interna del Target Tracking Scaling.Infraestructura adaptable a la demanda con AWS Auto Scaling - Diseño y optimización de políticas de escaladoPresenta cómo utilizar los 3 tipos de políticas (Target Tracking, Predictive y Scheduled) y lograr la optimización de costos con instancias Spot mediante Mixed Instances Policy.Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.Infraestructura de computación por lotes - Procesamiento paralelo a gran escala con AWS BatchExplicamos cómo construir procesamiento por lotes a gran escala con AWS Batch. Cubrimos el diseño de colas de trabajos, auto-escalado de entornos de cómputo, optimización de costos con instancias Spot y la construcción de infraestructura de lotes ideal para computación científica y procesamiento de datos a gran escala.Streaming en vivo con calidad broadcast - Construcción de plataforma de distribución a gran escala con AWS Elemental MediaLive y MediaPackageExplicamos cómo construir una plataforma de streaming en vivo con calidad broadcast usando AWS Elemental MediaLive y MediaPackage. Cubrimos transcodificación en tiempo real, DRM, inserción de anuncios y distribución multi-CDN.Construcción de render farm administrado con AWS Deadline Cloud - Migración de renderizado VFX a la nubeExplicamos la construcción de render farms con Deadline Cloud, la programación de trabajos y la optimización de costos mediante instancias Spot.

Artículos y servicios similares

El diseño de Availability Zones de AWS - La diferencia en confiabilidad que genera la separación física y el aislamiento de fallosExplicamos la filosofía de diseño de las AZ de AWS como grupos de centros de datos físicamente independientes, comparándolas con las zonas de disponibilidad de Azure y GCP, y analizamos la diferencia en madurez del aislamiento de fallos a partir de incidentes reales.Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.Regiones y ubicaciones de borde de AWS - La ventaja física de 33 regiones y más de 600 PoPAnalizamos el significado de que AWS despliegue 33 regiones, más de 100 AZ y más de 600 ubicaciones de borde en el mundo, desde la comparación de puntos de presencia con Azure y GCP y el valor estratégico del sistema de 3 regiones en Japón.Hallazgos más comunes en Well-Architected Review - 5 errores de diseño que los ingenieros pasan por altoExplicamos los problemas de diseño señalados repetidamente en AWS Well-Architected Review, centrándonos en 5 áreas: despliegue en una sola AZ, falta de backups, logs sin utilizar, optimización de costos abandonada y permisos excesivos en Security Groups.Computación edge y 5G - Ultra baja latencia con AWS Wavelength y Local ZonesExplicamos la computación de ultra baja latencia con AWS Wavelength y Local Zones. Presentamos el procesamiento en el edge de redes 5G, la colocación cercana en áreas urbanas, casos de uso y la diferenciación con regiones normales.