AWS no es un único ordenador gigante: es una red de datacenters repartidos por todo el mundo, organizados en regiones. Entender qué es una región y cómo elegir la correcta es una de las primeras decisiones prácticas que tomarás, y afecta a la velocidad, el coste y la legalidad de tu proyecto.

Qué es una región

Una región AWS es una zona geográfica del mundo donde AWS tiene un grupo de datacenters. Cada región es independiente de las demás.

Algunos ejemplos de regiones (con su código, que usarás mucho):

Región Ubicación Código
Europa (Irlanda) Dublín eu-west-1
Europa (Fráncfort) Alemania eu-central-1
Europa (España) Aragón eu-south-2
EE. UU. Este (Norte de Virginia) Virginia us-east-1
Asia Pacífico (Tokio) Japón ap-northeast-1
América del Sur (São Paulo) Brasil sa-east-1

Hay decenas de regiones por todo el planeta, y AWS añade nuevas con frecuencia. El código (eu-west-1, etc.) es el nombre técnico que verás en la consola y en el código de Terraform.

Por qué hay varias regiones

Tener datacenters en muchos sitios resuelve tres cosas:

  1. Cercanía a los usuarios → menos latencia (la app va más rápida).
  2. Cumplimiento legal → algunos datos deben quedarse en un país concreto.
  3. Resiliencia → si una región tiene un problema grave, puedes operar desde otra.

Importante: las regiones están aisladas entre sí a propósito. Si despliegas algo en Irlanda, no aparece automáticamente en Tokio. Esto es bueno para la seguridad y la tolerancia a fallos, pero significa que tú decides dónde va cada cosa.

Cómo elegir la región correcta

Elegir región es una decisión que conviene pensar. Estos son los cuatro factores clave:

  1. Proximidad a tus usuarios (latencia)

Cuanto más cerca esté la región de tus usuarios, más rápida será tu aplicación.

Ejemplo: Si tus clientes están en España, elige una región europea (España, Irlanda o Fráncfort), no una en Tokio. Los datos viajando de ida y vuelta a Japón añadirían un retraso perceptible.

  1. Cumplimiento legal y soberanía de datos

Algunas leyes obligan a que los datos de los ciudadanos se almacenen dentro de ciertas fronteras.

Ejemplo: El RGPD europeo hace que muchas empresas prefieran mantener los datos de clientes europeos en regiones de la UE. Veremos esto en el subcapítulo 3.4.

  1. Coste

Los precios varían entre regiones. El mismo servidor puede costar distinto en Virginia que en São Paulo.

Dato útil: us-east-1 (Norte de Virginia) suele ser de las más baratas y donde antes aparecen los servicios nuevos. Pero si tus usuarios están en Europa, el ahorro no compensa la latencia.

  1. Servicios disponibles

No todas las regiones tienen todos los servicios. Las regiones más nuevas o pequeñas pueden no tener aún los servicios más recientes. Antes de elegir, comprueba que la región tiene lo que necesitas.

Un caso especial: us-east-1

La región Norte de Virginia (us-east-1) es la más antigua y «central» de AWS. Conviene saber dos cosas:

  • Es donde AWS suele lanzar primero los servicios nuevos.
  • Algunos servicios globales (como ciertas partes de facturación o el servicio de certificados para CloudFront) requieren us-east-1, aunque tus usuarios estén en otro sitio. Lo verás más adelante en el libro.

Regla práctica para empezar

Si estás aprendiendo o dudando, una buena regla por defecto:

Elige la región más cercana a ti (o a tus usuarios) que tenga los servicios que necesitas.

Para alguien en España, Europa (España), Europa (Irlanda) o Europa (Fráncfort) son elecciones sensatas para la mayoría de proyectos.

Lo que debes recordar

  • Una región es una zona geográfica con datacenters de AWS; hay muchas por el mundo y cada una tiene un código (eu-west-1, us-east-1…).
  • Las regiones están aisladas entre sí: tú decides dónde poner cada cosa.
  • Elige región según latencia (cercanía), legalidad (soberanía de datos), coste y servicios disponibles.
  • us-east-1 es especial: la más barata, donde llegan antes los servicios nuevos y requerida por algunos servicios globales.

En el siguiente subcapítulo bajaremos un nivel: dentro de cada región hay varias zonas de disponibilidad (AZ), la clave de la alta disponibilidad.

Cloud, AWS & Terraform — De cero a experto

Capítulo 1 · Qué es el cloud computing

Capítulo 2 · El mercado cloud y los grandes proveedores

Capítulo 3 · Regiones, zonas de disponibilidad y edge

Capítulo 4 · Cómputo: EC2

Capítulo 5 · Almacenamiento: S3

Capítulo 6 · Redes: VPC

Capítulo 7 · Identidad y acceso: IAM

Capítulo 8 · Bases de datos gestionadas

Capítulo 9 · Por qué Infraestructura como Código

Capítulo 10 · HCL: el lenguaje de Terraform

Capítulo 11 · Providers y estado

Capítulo 12 · Tu primera infraestructura real en Terraform

Capítulo 13 · Balanceo de carga y autoescalado

Capítulo 14 · Serverless con Lambda

Capítulo 15 · Mensajería y eventos

Capítulo 16 · Entrega de contenido y DNS

Capítulo 17 · Contenedores en AWS

Capítulo 18 · Módulos: reutilización y composición

Capítulo 19 · Workspaces y gestión de entornos

Capítulo 20 · Backends remotos y locking

Capítulo 21 · Testing de infraestructura

Capítulo 22 · Terraform en CI/CD

Capítulo 23 · Seguridad en profundidad

Capítulo 24 · Observabilidad: logs, métricas y trazas

Capítulo 25 · Optimización de costes

Capítulo 26 · Alta disponibilidad y disaster recovery

Capítulo 27 · Well-Architected Framework de AWS

Capítulo 28 · Arquitecturas serverless a escala

Capítulo 29 · Plataformas de datos en AWS

Capítulo 30 · Multi-cuenta y landing zones

Capítulo 31 · Platform Engineering e Internal Developer Platform

Capítulo 32 · Certificaciones AWS relevantes

Capítulo 33 · Proyectos para consolidar lo aprendido

Capítulo 34 · Recursos y comunidad

© Copyright 2024. Todos los derechos reservados