AWS Cloud Practitioner #2: Infraestructura Global AWS - Regions, AZs y Edge Locations

🎯 Lo que Aprenderás Hoy

Al finalizar este post, podrás:

• Comprender la estructura global de AWS (Regions, AZs, Edge Locations)
• Diferenciar entre Region, Availability Zone y Edge Location
• Elegir la región correcta para tus aplicaciones
• Diseñar para alta disponibilidad geográfica

El Problema Real

Tu startup de eCommerce está creciendo. Tienes usuarios en:

• Estados Unidos (60%)
• Europa (30%)
• Asia (10%)

Desafíos:

1. Latencia: Usuarios en Europa experimentan tiempos de carga de 800ms (tu servidor está en Virginia)
2. Compliance: GDPR requiere que datos de usuarios europeos permanezcan en Europa
3. Disponibilidad: Si tu data center falla, TODO el negocio se cae

Pregunta: ¿Cómo diseñas una arquitectura global, rápida y resiliente?

Respuesta: Entendiendo la infraestructura global de AWS.

Metodología Bottom-Up

Como en el post anterior, construiremos conocimiento elemento por elemento:

1. Primero: ¿Qué es una Region?
2. Luego: ¿Qué es una Availability Zone?
3. Después: ¿Qué es un Edge Location?
4. Finalmente: Cómo todo se conecta en la infraestructura global

🔸 Elemento 1: AWS Region

¿Qué es?

Una AWS Region es un área geográfica que contiene múltiples data centers de AWS.

Cada región es completamente independiente y aislada de las demás. Lo que pasa en us-east-1 (Virginia) NO afecta directamente a eu-west-1 (Irlanda).

Características Clave

• Nombre: Identificador único (ej: us-east-1, eu-west-1, ap-southeast-1)
• Ubicación: Área geográfica específica
• Independencia: Cada región opera de forma autónoma
• Servicios: No todos los servicios AWS están disponibles en todas las regiones

Regiones Principales (2025)

América:
- us-east-1 (N. Virginia) - La más grande
- us-west-2 (Oregon)
- sa-east-1 (São Paulo)
 
Europa:
- eu-west-1 (Irlanda)
- eu-central-1 (Frankfurt)
 
Asia Pacífico:
- ap-southeast-1 (Singapore)
- ap-northeast-1 (Tokyo)
- ap-south-1 (Mumbai)

¿Cómo Elegir una Región?

Considera 4 factores:

1. Proximidad a usuarios (Latencia)

• Regla: Elige la región más cercana a tus usuarios principales
• Ejemplo: App para usuarios en Brasil → sa-east-1

2. Cumplimiento legal (Compliance)

• Algunos países requieren que los datos permanezcan en su territorio
• GDPR (Europa), LGPD (Brasil), regulaciones financieras

3. Servicios disponibles

• No todos los servicios AWS están en todas las regiones
• Verifica que los servicios que necesitas estén disponibles

4. Pricing

• Los precios varían entre regiones
• us-east-1 suele ser la más económica

Ejemplo Práctico

# Listar todas las regiones disponibles
aws ec2 describe-regions --output table
 
# Lanzar instancia en región específica
aws ec2 run-instances \
  --region us-west-2 \  # Oregon
  --image-id ami-xxx \
  --instance-type t2.micro

🔸 Elemento 2: Availability Zone (AZ)

¿Qué es?

Una Availability Zone es uno o más data centers físicos dentro de una región.

Cada región tiene múltiples AZs (mínimo 3, usualmente 3-6) que están:

• Físicamente separadas (kilómetros de distancia)
• Conectadas con latencia ultra-baja (< 1ms)
• Independientes en energía, refrigeración, networking

¿Por qué Múltiples AZs?

Alta Disponibilidad y Tolerancia a Fallos.

Si un data center falla (terremoto, inundación, falla eléctrica), los otros siguen funcionando.

Estructura

Region: us-east-1 (N. Virginia)
  ├── AZ: us-east-1a
  ├── AZ: us-east-1b
  ├── AZ: us-east-1c
  ├── AZ: us-east-1d
  ├── AZ: us-east-1e
  └── AZ: us-east-1f

Cada AZ puede tener múltiples data centers físicos.

Caso de Uso: Multi-AZ Deployment

Problema: Aplicación crítica que NO puede tener downtime.

Solución: Desplegar en múltiples AZs.

# Lanzar instancias EC2 en diferentes AZs
aws ec2 run-instances \
  --availability-zone us-east-1a \
  --instance-type t2.micro \
  --count 2
 
aws ec2 run-instances \
  --availability-zone us-east-1b \
  --instance-type t2.micro \
  --count 2

Resultado:

• Si us-east-1a falla → us-east-1b sigue sirviendo tráfico
• Disponibilidad del 99.99%+ (vs. 99.5% single AZ)

🔸 Elemento 3: Edge Location

¿Qué es?

Un Edge Location es un punto de presencia (PoP) de AWS usado principalmente para CloudFront (CDN de AWS) y otros servicios de edge.

NO son data centers completos como las AZs. Son cachés distribuidas globalmente.

Características Clave

• Cantidad: 400+ Edge Locations globalmente (muchas más que regiones)
• Propósito: Cachear contenido cerca de los usuarios
• Latencia: Milisegundos (contenido servido desde la Edge más cercana)

¿Cómo Funciona?

1. Usuario en Sydney solicita imagen de tu sitio web
2. CloudFront verifica si tiene esa imagen en la Edge Location de Sydney
3. Si sí: Sirve desde Sydney (ultra-rápido)
4. Si no: Obtiene del origen (tu S3 en us-east-1), cachea en Sydney, y sirve

Próximas solicitudes son instantáneas.

Ejemplo Práctico

Sin CloudFront (sin Edge):

• Usuario en Sydney → Server en Virginia
• Latencia: ~200-300ms
• Ancho de banda: caro

Con CloudFront (con Edge):

• Usuario en Sydney → Edge Location en Sydney
• Latencia: ~5-10ms (primera vez ~200ms)
• Ancho de banda: optimizado

// Crear distribución CloudFront
const cloudfront = new AWS.CloudFront();
 
const params = {
  DistributionConfig: {
    Origins: {
      Items: [{
        Id: 'my-s3-bucket',
        DomainName: 'my-bucket.s3.amazonaws.com',
        S3OriginConfig: { OriginAccessIdentity: '' }
      }]
    },
    Enabled: true,
    Comment: 'CDN for my website'
  }
};
 
cloudfront.createDistribution(params);

🔗 Conectando Todo: La Arquitectura Global

Ahora que entiendes cada elemento, veamos el panorama completo:

Jerarquía

AWS Global Infrastructure
│
├── Regions (30+)
│   │
│   ├── Region: us-east-1
│   │   ├── AZ: us-east-1a (1+ data centers)
│   │   ├── AZ: us-east-1b (1+ data centers)
│   │   └── AZ: us-east-1c (1+ data centers)
│   │
│   └── Region: eu-west-1
│       ├── AZ: eu-west-1a
│       ├── AZ: eu-west-1b
│       └── AZ: eu-west-1c
│
└── Edge Locations (400+)
    ├── Edge: Sydney
    ├── Edge: Tokyo
    ├── Edge: London
    └── Edge: New York

Arquitectura Global Ejemplo

Empresa multinacional con usuarios globales:

1. Región principal: us-east-1 (Virginia)

   • Base de datos principal
   • Aplicaciones core
   • Desplegadas en 3 AZs para alta disponibilidad

2. Región secundaria: eu-west-1 (Irlanda)

   • Replica de base de datos (para compliance GDPR)
   • Aplicaciones para usuarios europeos
   • También en múltiples AZs

3. Edge Locations: 400+ globalmente

   • CloudFront cachea contenido estático
   • Usuarios obtienen respuestas en < 50ms

Resultado:

• Latencia global: < 100ms
• Disponibilidad: 99.99%+
• Compliance: GDPR cumplido
• Disaster recovery: Región secundaria como backup

Comparación Rápida

Casos de Uso Reales

Caso 1: Startup Global de SaaS

Problema: Usuarios en 50 países. Latencia variable.

Solución:

• Primary: us-east-1 (mayoría de usuarios en USA)
• Secondary: eu-west-1 (usuarios europeos)
• Secondary: ap-southeast-1 (usuarios asiáticos)
• Edge: CloudFront en todas las Edge Locations

Resultado:

• Latencia < 100ms para 95% de usuarios
• Compliance cumplido (datos localizados por región)
• Costos optimizados (solo regiones necesarias)

Caso 2: Aplicación de Video Streaming

Problema: Videos pesados, alto tráfico global.

Solución:

• Storage: S3 en us-east-1 (origen)
• Distribution: CloudFront con Edge Locations globales
• Encoding: MediaConvert en región primaria

Resultado:

• Videos se sirven desde Edge más cercana
• Ahorro de 60% en costos de transferencia de datos
• Experiencia fluida para usuarios globales

✅ Best Practices

Al Diseñar Multi-Region

• ✓ Empieza con una región: No sobre-ingenierizar desde el inicio
• ✓ Expande cuando sea necesario: Basado en métricas reales de usuarios
• ✓ Considera compliance primero: Requisitos legales no son negociables
• ✓ Usa CloudFront: Antes de multi-region, prueba con CDN

Al Diseñar Multi-AZ

• ✓ Siempre usa al menos 2 AZs: Para producción
• ✓ Idealmente 3 AZs: Para máxima disponibilidad
• ✓ Load Balancer cross-AZ: Distribuye tráfico automáticamente
• ✓ Database Multi-AZ: RDS ofrece esto fácilmente

Al Usar Edge Locations

• ✓ CloudFront para static assets: Imágenes, CSS, JS
• ✓ Configure TTL apropiado: Balance entre freshness y cache hit
• ✓ Invalida cache cuando sea necesario: Pero tiene costo

❌ Errores Comunes

Error 1: "Una AZ es suficiente"

Problema: Single point of failure.

Solución: Siempre usa al menos 2 AZs para producción. El costo adicional es mínimo comparado con el riesgo.

Error 2: "Voy a usar todas las regiones desde el inicio"

Problema: Complejidad innecesaria, costos altos, gestión difícil.

Solución: Empieza con 1 región. Expande basado en necesidad real (usuarios, compliance, disaster recovery).

Error 3: "CloudFront es solo para sitios web"

Realidad: CloudFront también acelera APIs, video streaming, downloads de software, y más.

📝 Preparación para el Examen

Puntos Clave

• 📌 Region = área geográfica con múltiples AZs
• 📌 AZ = uno o más data centers dentro de una región
• 📌 Edge Location = PoP para CloudFront (CDN)
• 📌 Eligir región: Proximidad, compliance, servicios, pricing
• 📌 Multi-AZ = alta disponibilidad dentro de una región
• 📌 Multi-Region = disaster recovery global

Pregunta de Práctica

Una empresa debe cumplir con GDPR y tener datos de usuarios europeos en Europa. ¿Qué deben hacer?

A) Usar us-east-1 con CloudFront B) Usar Edge Locations en Europa C) Desplegar en una región europea (ej: eu-west-1) D) Usar múltiples AZs en us-east-1

🎓 Resumen

Lo que aprendimos:

1. Region: Área geográfica independiente con múltiples AZs
2. Availability Zone: Data center(s) para alta disponibilidad
3. Edge Location: Cache global para CloudFront
4. Elegir región: Proximidad + compliance + servicios + precio
5. Alta disponibilidad: Multi-AZ deployment

Infraestructura Global AWS:
  Regions (30+)
    └── AZs (3-6 por región)
         └── Data Centers
 
  Edge Locations (400+)
    └── CloudFront CDN

⏭️ Próximo Post

En el Post #3 exploraremos Los Superpoderes de la Nube:

• Elasticity vs Scalability
• High Availability
• Fault Tolerance
• Agility
• Cómo estos conceptos se implementan en AWS

📚 Recursos

• AWS Global Infrastructure
• Regions and Availability Zones
• CloudFront - CDN de AWS

Tags: #AWS #CloudPractitioner #GlobalInfrastructure #Regions #AvailabilityZones #EdgeLocations

Post 2 de 25 - Serie AWS Cloud Practitioner Certification