Tema-1 AWS Regions y Availability Zones: Guía Completa y Simple

Source: Dev.to

Infraestructura Global de AWS

Estructura jerárquica

MUNDO
├── Regiones (Geographic Areas)
│   ├── Availability Zones (AZ)
│   ├── Local Zones
│   └── Wavelength Zones
└── Edge Locations

Conceptos clave

• Región: zona geográfica grande con múltiples data centers. Cada región está aislada de las demás para maximizar la tolerancia a fallos.
• Availability Zone (AZ): data center físico independiente (o grupo de data centers) dentro de una región. Cada AZ tiene su propia energía, red y refrigeración.
• Principio fundamental: una aplicación en AWS debe ejecutarse en varias AZ, nunca en una sola, para lograr alta disponibilidad.

Regiones y sus códigos

Mapa simplificado

Mundo
├── Estados Unidos → us-east-1, us-west-2
├── Europa → eu-west-1, eu-central-1
├── Asia → ap-southeast-1, ap-northeast-1
└── América del Sur → sa-east-1

Por qué usar regiones

• Reducir latencia: los usuarios están más cerca de los servidores.
• Cumplir regulaciones: los datos permanecen en jurisdicciones específicas.
• Aumentar disponibilidad: redundancia geográfica.
• Disaster Recovery: respaldo en caso de desastres naturales.

Availability Zones

Dentro de cada región, AWS dispone de múltiples AZ. Cada AZ es:

• Un data center físico (o conjunto de ellos).
• Totalmente independiente de las demás AZ.
• Con su propia energía, red y refrigeración.
• Conectada a otras AZ mediante redes de alta velocidad y baja latencia.

Ejemplo de la región us-east-1

us-east-1
├── us-east-1a (AZ A)
├── us-east-1b (AZ B)
├── us-east-1c (AZ C)
├── us-east-1d (AZ D)
├── us-east-1e (AZ E)
└── us-east-1f (AZ F)

Analogía visual

Ciudad          → Región
Edificio        → Availability Zone
Pisos/Oficinas   → Servidores

Ejemplo práctico

Imagina que Miami fuera una región y los edificios A, B y C fueran sus AZ. Cada edificio tiene su propia electricidad, internet y seguridad. Si una AZ falla, las demás siguen operativas.

Arquitectura con Load Balancer

Usuario
    |
Load Balancer
    |
├── Aplicación en AZ A (❌ falla)
├── Aplicación en AZ B (✅ funciona)
└── Aplicación en AZ C (✅ funciona)

API Gateway + Lambda (Multi‑AZ automático)

Internet
    |
API Gateway
    |
┌───────────────────────┐
│ Lambda Functions       │
├── AZ A: Lambda Instance│
├── AZ B: Lambda Instance│
└── AZ C: Lambda Instance│
└───────────────────────┘

RDS Multi‑AZ

Internet
    |
Application Load Balancer
    |
├── AZ A: EC2 + Auto Scaling
├── AZ B: EC2 + Auto Scaling
└── AZ C: EC2 + Auto Scaling
    |
    v
RDS Multi‑AZ
├── AZ A: Primary DB
└── AZ B: Standby DB

Características importantes

• API Gateway: funciona en múltiples AZ automáticamente.
• Lambda: se ejecuta en varias AZ sin configuración adicional.
• RDS Multi‑AZ: base primaria y respaldo automático.
• Load Balancer: distribuye tráfico entre AZ saludables.

Uso de múltiples regiones

Cuándo considerarlas

• Disaster Recovery extremo: protección contra fallos a nivel regional.
• Usuarios globales: reducir latencia para clientes en diferentes continentes.
• Requerimientos legales: datos deben permanecer en jurisdicciones específicas.
• Compliance: regulaciones específicas por país o región.

Comparación Región vs AZ

Buenas prácticas

• Siempre usar al menos 2‑3 AZ para aplicaciones críticas.
• Comenzar con una sola región; expandir a otras solo si la latencia o requisitos regulatorios lo exigen.
• Aprovechar los servicios Multi‑AZ (RDS, DynamoDB, ElastiCache, etc.) cuando estén disponibles.
• Planificar Disaster Recovery solo si es crítico para el negocio.
• Evitar colocar todo en una sola AZ (punto único de falla).
• No usar múltiples regiones innecesariamente, ya que aumenta complejidad y costos.
• Considerar la latencia entre AZ en aplicaciones sensibles al tiempo de respuesta.
• Monitorear los costos de transferencia de datos entre regiones.

Resumen de conceptos clave

Conceptos Clave
• Región = zona geográfica grande
• AZ = data center físico independiente
• Una región tiene múltiples AZ (mínimo 3)
• Múltiples AZ = alta disponibilidad
• Una región suele ser suficiente para la mayoría de los casos

Referencias

• AWS Global Infrastructure – Documentación oficial de Regiones y AZ.
• AWS Well‑Architected Framework – Reliability Pillar.
• AWS Latency Calculator – Herramienta para estimar latencia entre regiones.

Última actualización: diciembre 2024