Cuando Marta creó la cuenta de MercadoFresco en la lección anterior, dejamos anotada una decisión sin justificar del todo: la región será eu-west-1. Esta lección explica por qué, y para ello tenemos que abrir el capó y ver cómo está construido AWS por dentro.

Entender la infraestructura global no es cultura general: es la base de la alta disponibilidad. El servidor de MercadoFresco se cae los viernes porque es uno. La forma de que eso deje de pasar es repartir la aplicación entre instalaciones físicamente separadas que no fallan a la vez. Para diseñar ese reparto necesitas saber qué es una región, qué es realmente una zona de disponibilidad, qué servicios son globales y cuáles no, y cuánto cuesta mover datos entre unos sitios y otros.

1. Las tres capas de la infraestructura de AWS
2. Regiones: qué son, cómo se nombran y por qué están aisladas
3. Zonas de disponibilidad: qué es realmente una AZ
4. Por qué las letras de las AZ se barajan entre cuentas
5. Red de borde: edge locations, PoP y regional edge caches
6. Infraestructura especializada: Local Zones, Wavelength y Outposts
7. Servicios globales, regionales y zonales
8. Cómo elegir región: los cinco criterios
9. Diseño multi-AZ: qué falla y qué sobrevive
10. Decisión de región para MercadoFresco
11. Coste del tráfico entre AZ y entre regiones

La infraestructura de AWS se organiza en una jerarquía de tres niveles. Interiorízala, porque casi todo lo demás se deriva de ella.

Una región de AWS es un área geográfica del mundo donde AWS ha construido un grupo de centros de datos. Ejemplos: Irlanda, Fráncfort, París, España, Norte de Virginia, Tokio, São Paulo.

Los identificadores siguen un patrón fijo, y conviene saber leerlo porque los escribirás cientos de veces en la CLI y en las plantillas:

Regiones europeas que te interesan como profesional en España:

Ojo con us-east-1 (Norte de Virginia): es la región más antigua y grande, donde AWS estrena casi todos los servicios, y donde viven forzosamente algunas cosas globales (como la métrica de facturación que vimos en 01-02, o los certificados de CloudFront). No la uses como región principal si tus clientes están en Europa.

Este es el punto conceptual más importante: las regiones son independientes entre sí. No es una frase de marketing, es una propiedad de diseño con consecuencias prácticas muy concretas:

• Un recurso creado en eu-west-1 no existe en eu-west-3. Si buscas tu instancia en la región equivocada, la consola te dirá que no hay nada.
• Los datos no salen de una región salvo que tú lo pidas explícitamente (replicación entre regiones, copia de una instantánea, transferencia). Esto es la base del cumplimiento del RGPD.
• Un fallo grave en una región no propaga a las demás. Es la unidad de aislamiento de fallos más grande que existe.
• Los precios varían por región. El mismo servidor puede costar un 20 % más en São Paulo que en Irlanda.
• Algunos servicios nuevos no están disponibles en todas las regiones.

Regla mental: piensa en cada región como una nube completa y separada que casualmente comparte la consola, la API y tu cuenta con las demás.

Una zona de disponibilidad (Availability Zone, AZ) es un conjunto de uno o más centros de datos dentro de una región, con:

• Alimentación eléctrica independiente: su propia acometida y sus propios generadores.
• Refrigeración independiente.
• Conectividad de red independiente.
• Separación física real: están a kilómetros de distancia unas de otras, lo bastante lejos para que una inundación, un incendio o un corte eléctrico no afecte a dos a la vez, y lo bastante cerca para que la latencia entre ellas siga siendo mínima.

Esa doble condición —lejos para el riesgo, cerca para la latencia— es la clave de todo el diseño:

Que la latencia entre AZ sea de 1-2 milisegundos es lo que hace posible que una base de datos RDS en modo Multi-AZ escriba de forma síncrona en dos AZ a la vez: cada transacción se confirma en las dos antes de dar el OK, y si una AZ desaparece, no se pierde ni un pedido. Con 40 ms esto sería inviable.

Las AZ se nombran añadiendo una letra al identificador de la región: eu-west-1a, eu-west-1b, eu-west-1c.

Aquí hay un detalle que confunde a mucha gente y que conviene entender bien.

eu-west-1a no es el mismo centro de datos para todas las cuentas de AWS. AWS asigna las letras de forma aleatoria e independiente para cada cuenta. La eu-west-1a de MercadoFresco puede ser físicamente la misma instalación que la eu-west-1c de otra empresa.

¿Por qué? Para repartir la carga. Si las letras fueran fijas, la mayoría de los clientes elegiría "la a" por costumbre y esa zona se congestionaría mientras las otras quedarían vacías. La aleatorización distribuye el uso de forma uniforme.

Consecuencias prácticas:

• No compares letras de AZ entre cuentas. Decir "despliega en la 1a" a un compañero de otra empresa no significa nada.
• Para identificar la zona física real existe el AZ ID, que sí es estable y global: euw1-az1, euw1-az2, euw1-az3. Este identificador es el mismo para todas las cuentas.

Puedes ver la correspondencia de tu cuenta con este comando (la CLI se instala y configura en la lección 01-05; aquí solo mostramos el resultado para que lo reconozcas):

Explicado línea a línea:

• aws ec2 describe-availability-zones: servicio ec2, operación que lista zonas.
• --region eu-west-1: sobre qué región preguntamos.
• --query '...': filtro JMESPath que se queda solo con tres campos y les pone nombre.
• --output table: formato de tabla legible en lugar de JSON.

Salida aproximada:

Fíjate: en esta cuenta, eu-west-1a corresponde físicamente a euw1-az2. En otra cuenta la correspondencia sería distinta.

Además de regiones y AZ, AWS tiene una tercera capa mucho más numerosa y repartida: la red de borde (edge network).

El flujo es una jerarquía de cachés:

Para MercadoFresco esto tiene un efecto directo: las fotos de producto (miles de imágenes que apenas cambian) se pueden servir desde el edge de Madrid en pocos milisegundos, sin tocar el origen en Irlanda. Eso mejora la experiencia del cliente y reduce carga y coste de salida.

Los servicios que usan esta red son CloudFront (red de distribución de contenido), Route 53 (DNS), AWS Shield y AWS WAF (protección) y Global Accelerator. Cómo se configura CloudFront es la lección 03-04; Route 53 es 03-05; Shield y WAF, 04-04 y 04-05. Aquí solo necesitas saber que esa capa existe y que está fuera de las regiones.

Además de lo anterior, AWS ofrece tres extensiones que probablemente no usarás al principio, pero que conviene reconocer por su nombre.

MercadoFresco no necesita ninguna de las tres. Su latencia objetivo (una tienda web) se resuelve sobradamente con una región europea más CloudFront.

Este es uno de los puntos donde más se equivocan los principiantes: no todos los servicios de AWS tienen el mismo alcance.

Casos que conviene matizar porque generan confusión:

• Amazon S3: el bucket es regional y sus datos se replican automáticamente entre varias AZ, pero el nombre del bucket es único a nivel global. Nadie más en el mundo puede llamar a su bucket igual que tú.
• Amazon RDS: una instancia individual es zonal. En modo Multi-AZ hay una réplica en otra AZ, con conmutación automática. El endpoint de conexión no cambia al conmutar.
• AWS Lambda: tú despliegas la función en una región y AWS se encarga de ejecutarla en varias AZ. Es regional y no tienes que preocuparte de la redundancia.
• VPC: la VPC es regional, pero cada subred pertenece a una única AZ. Esta es la pieza que usarás para repartir tus servidores (lección 03-01).

Regla práctica: si el recurso es zonal, es tu responsabilidad tener otro igual en otra AZ.

Elegir región no es una cuestión de gusto. Estos son los cinco criterios, en orden de importancia habitual.

Cada 1.000 km añaden aproximadamente 10 ms de ida y vuelta por la velocidad de la luz en la fibra, más el retardo de los saltos de red. Referencias aproximadas desde Madrid:

Para una tienda online, la diferencia entre 35 ms y 100 ms es perfectamente perceptible: una página que hace 20 peticiones encadenadas acumula más de un segundo de retardo extra.

MercadoFresco trata datos personales de clientes españoles: nombre, dirección, teléfono, historial de compra. El RGPD no prohíbe sacar datos de la UE, pero exige garantías adicionales y documentación cuando se transfieren a terceros países. La forma más simple de cumplir sin abogados es no sacarlos: elegir una región de la Unión Europea.

Esto descarta directamente us-east-1 y, en la práctica, también eu-west-2 (Londres), que quedó fuera de la UE tras el Brexit.

No todas las regiones ofrecen todos los servicios, ni todos los tipos de instancia. Las regiones más antiguas y grandes (us-east-1, eu-west-1, eu-central-1) tienen el catálogo más completo; las más recientes (como eu-south-2) van incorporando servicios progresivamente.

Antes de comprometerte con una región, comprueba en la página de disponibilidad regional de AWS que todos los servicios de tu arquitectura están ahí. Descubrir a mitad de proyecto que te falta un servicio es muy caro.

El mismo recurso cuesta distinto según la región. Tomando us-east-1 como índice 100, los órdenes de magnitud aproximados son:

La diferencia entre regiones europeas es de un dígito porcentual: no compensa sacrificar latencia o cumplimiento para ahorrar un 5 %.

Si tu aplicación depende de un sistema que ya está en otro sitio (un ERP, un proveedor externo, una base de datos heredada), colocarte cerca reduce latencia y coste de transferencia. En el caso de MercadoFresco, el servidor de la oficina desaparecerá al terminar la migración, así que este criterio no pesa.

Vamos a lo importante. ¿Qué pasa exactamente cuando cae una AZ, y cómo se sobrevive?

Si eu-west-1a sufre un corte eléctrico, MercadoFresco está caída al 100 %. Es exactamente la misma fragilidad del servidor de la oficina, solo que en un edificio más bonito. Mucha gente migra a la nube y se queda aquí, sin darse cuenta de que no ha ganado disponibilidad.

Ahora simulemos la caída completa de eu-west-1a:

Resultado: en lugar de una caída total de horas, MercadoFresco tiene una degradación de uno o dos minutos. Eso es la diferencia entre perder la tarde del viernes y no enterarse.

1. Dimensiona para N-1. Si necesitas 4 servidores para atender el pico y los repartes 2 y 2, al caer una AZ te quedan 2 y no llegas. Reparte 3 y 3, o usa escalado automático que reaccione.
2. No pongas estado en el disco local de una instancia. Las fotos de producto no pueden vivir en el disco de un EC2: si esa instancia desaparece, desaparecen. Van a S3 (lección 02-03).
3. Prueba el fallo. Una arquitectura multi-AZ que nunca se ha probado es una hipótesis. Apagar deliberadamente una instancia y comprobar que el servicio sigue en pie es un ejercicio sano.

Repartir entre dos regiones protege contra el fallo de una región entera, pero multiplica la complejidad: replicación de datos a decenas de milisegundos, DNS con conmutación, coste de transferencia y el doble de infraestructura. Para MercadoFresco es innecesario hoy. La regla general de la industria es: multi-AZ desde el principio, multi-región solo cuando el negocio lo justifique.

Marta compara las tres candidatas realistas con los cinco criterios:

Decisión: eu-west-1 (Irlanda), con este razonamiento explícito:

• La latencia de 35-45 ms es perfectamente aceptable para una tienda web, y además la mayor parte del peso de la página (fotos de producto) se servirá desde el edge de Madrid vía CloudFront, con lo que la latencia percibida será mucho menor que la latencia al origen.
• El catálogo completo evita el riesgo de descubrir a mitad de proyecto que falta un servicio, algo crítico cuando el curso va a recorrer once módulos de servicios distintos.
• Está en la UE, con lo que el RGPD se cumple sin transferencias internacionales.
• Es la región con más documentación y ejemplos, lo que importa mucho en un equipo de tres personas sin especialista en AWS.

Marta anota además una revisión futura: cuando eu-south-2 complete su catálogo y si la latencia se vuelve un factor competitivo, se reevaluará. Documentar la decisión y su fecha de revisión es una buena práctica de arquitectura.

El precio de mover datos dentro de AWS sorprende a muchos equipos. Estos son los órdenes de magnitud que debes tener en la cabeza:

Ejemplo concreto para MercadoFresco: si los servidores de aplicación de eu-west-1a consultan la base de datos de eu-west-1b, cada gigabyte de resultados cruza una frontera de AZ y se factura. Con 500 GB al mes de tráfico entre capas, serían unos 10 $/mes. No es dramático, pero:

• Diseña para que el tráfico caliente se quede dentro de la AZ cuando puedas.
• No lo hagas a costa de la disponibilidad. Pagar 10 $ al mes por sobrevivir a la caída de un centro de datos es una de las mejores compras que puede hacer MercadoFresco.

Y una advertencia importante: el coste entre AZ no debe empujarte a poner todo en una sola AZ. Ese ahorro es exactamente el que te costará la tarde del viernes.

• Crear recursos en la región equivocada. Es el error número uno de los principiantes: creas una instancia, cierras el navegador, vuelves al día siguiente con otra región seleccionada y "ha desaparecido". No ha desaparecido: sigue facturando en la otra región. Lo veremos con detalle en la lección 01-04.
• Creer que "está en AWS" implica alta disponibilidad. Una única instancia EC2 en una única AZ tiene, aproximadamente, la misma disponibilidad que un servidor bien mantenido en la oficina. La redundancia hay que diseñarla.
• Suponer que eu-west-1a es lo mismo en todas las cuentas. Usa el AZ ID (euw1-az1) cuando necesites hablar de la zona física, por ejemplo al compartir subredes entre cuentas.
• Elegir us-east-1 porque "es la que sale en todos los tutoriales". Si tus usuarios y tus datos están en Europa, es una mala elección por latencia y por cumplimiento.
• Repartir en dos AZ pero dimensionar solo para el total. Si al perder una AZ te quedas por debajo de la capacidad necesaria, tu diseño multi-AZ solo sirve para no caer del todo, no para seguir dando servicio.
• Olvidar que hay recursos zonales sin réplica. Un volumen EBS vive en una AZ. Su instantánea, en cambio, se guarda en S3 y es regional: por eso las instantáneas son la forma de mover un disco de una AZ a otra.
• Consejo: documenta por escrito la región elegida, los motivos y la fecha de revisión. Cambiar de región más adelante es un proyecto de migración completo, no un ajuste de configuración.
• Consejo: cuando diseñes, pregúntate siempre "¿qué pasa si esta AZ desaparece ahora mismo?". Si la respuesta es "se cae la tienda", tienes trabajo por hacer.

Responde razonadamente:

1. Un compañero te dice: "he desplegado en eu-west-1a, despliega tú también ahí para que estemos juntos". Trabajáis en cuentas de AWS distintas. ¿Qué le contestas y qué dato le pides?
2. Clasifica como global, regional o zonal: un usuario IAM, un bucket S3, una instancia EC2, una función Lambda, un volumen EBS, una distribución de CloudFront, una subred.
3. ¿Por qué es posible que una base de datos replique de forma síncrona entre dos AZ pero no entre dos regiones?

Para cada escenario, elige región y justifica con al menos tres de los cinco criterios:

Escenario A. MercadoFresco decide abrir una filial en México con clientes exclusivamente mexicanos y catálogo propio. Los datos de clientes mexicanos no se mezclan con los españoles.

Escenario B. Sara necesita un entorno donde procesar durante la noche los informes de ventas históricos, sin usuarios interactivos, con datos ya anonimizados y sin datos personales. El coste es el criterio dominante.

MercadoFresco despliega en eu-west-1 con esta configuración:

• 2 instancias EC2 de la tienda: una en eu-west-1a, otra en eu-west-1b. Cada una soporta como máximo 600 pedidos por hora.
• 1 base de datos RDS en modo Multi-AZ, con la primaria en eu-west-1a.
• Las fotos de producto en S3.
• Un Application Load Balancer delante de las instancias.
• El pico del viernes es de 900 pedidos por hora.

Responde:

1. ¿Qué ocurre exactamente si eu-west-1a se cae un martes a las 10:00 (200 pedidos/hora)?
2. ¿Y si se cae un viernes a las 19:00, en pleno pico?
3. Propón dos cambios concretos para que el escenario del viernes no degrade el servicio, e indica cuál de los dos preferirías por coste.

Solución 1

1. Le contestas que las letras de las AZ no coinciden entre cuentas: su eu-west-1a puede ser otra instalación física que la tuya. Le pides el AZ ID (por ejemplo euw1-az2), que sí es estable y global, y buscas en tu cuenta qué letra le corresponde con aws ec2 describe-availability-zones.

2. Recurso	Alcance
   Usuario IAM	Global
   Bucket S3	Regional (con nombre único global)
   Instancia EC2	Zonal
   Función Lambda	Regional
   Volumen EBS	Zonal
   Distribución de CloudFront	Global
   Subred	Zonal

3. Porque la replicación síncrona exige esperar la confirmación del destino antes de dar por buena la transacción. Entre AZ, ese viaje cuesta 1-2 ms, un sobrecoste asumible por operación. Entre regiones cuesta 30-40 ms o más, lo que reduciría el rendimiento de escritura en un orden de magnitud y haría inviable la aplicación. Por eso entre regiones se replica de forma asíncrona, aceptando una pequeña ventana de posible pérdida de datos.

Solución 2

Escenario A: mx-central-1 (México) o, en su defecto, us-east-1/us-west-2.

• Latencia: una región en México o en el sur de EE. UU. está mucho más cerca de los clientes mexicanos que cualquier región europea (que estaría a más de 150 ms).
• Cumplimiento y residencia del dato: los datos de clientes mexicanos quedan en su jurisdicción y, al no mezclarse con los europeos, no se crea una transferencia internacional innecesaria.
• Disponibilidad de servicios: hay que verificar que la región elegida ofrezca todos los servicios de la arquitectura; si faltan piezas, una región estadounidense consolidada con buena latencia hacia México es la alternativa razonable.
• Precio: sa-east-1 (São Paulo) quedaría descartada por ser notablemente más cara y no aportar ventaja de latencia frente a las opciones norteamericanas.

Escenario B: eu-north-1 (Estocolmo).

• Precio: es habitualmente de las regiones más económicas de Europa, y el coste es el criterio dominante del enunciado.
• Latencia: irrelevante, porque es un proceso por lotes nocturno sin usuarios interactivos.
• Cumplimiento: está en la UE y, además, los datos ya están anonimizados, con lo que el requisito es doblemente holgado.
• Disponibilidad de servicios: hay que comprobar que ofrece los servicios de análisis necesarios; si faltara alguno, eu-west-1 sería la alternativa por muy poca diferencia de precio.

Un matiz: si esos datos hay que moverlos desde eu-west-1, el coste de transferencia entre regiones podría anular el ahorro. Habría que calcularlo antes de decidir.

Solución 3

1. Martes a las 10:00 (200 pedidos/hora). El ALB detecta que la instancia de 1a no responde y deja de enviarle tráfico en segundos. RDS conmuta la primaria a eu-west-1b en 1-2 minutos, sin pérdida de datos, y el endpoint de conexión no cambia. La instancia de 1b puede con los 200 pedidos/hora (su límite es 600). Las fotos en S3 no se ven afectadas. Impacto para el cliente: uno o dos minutos de errores en operaciones de escritura, y después servicio normal.

2. Viernes a las 19:00 (900 pedidos/hora). El mismo corte de 1-2 minutos por la conmutación de RDS, pero después queda una sola instancia con capacidad para 600 pedidos/hora frente a una demanda de 900. El sistema queda saturado: colas, tiempos de respuesta altos y errores. Se pierden aproximadamente un tercio de los pedidos durante todo el incidente. El diseño evita la caída total, pero no la degradación grave, porque no está dimensionado para N-1.

3. Dos cambios posibles:

   • Opción A: tres instancias fijas (una en 1a, una en 1b y una tercera repartida), de modo que al perder una AZ queden 2 × 600 = 1 200 pedidos/hora de capacidad, suficiente para el pico de 900. Coste: una instancia más encendida 24/7 todo el mes.
   • Opción B: grupo de escalado automático repartido en las dos AZ, con mínimo 2 instancias y máximo 4, que escale por CPU o por número de peticiones. En el pico del viernes habría 3 o 4 instancias; al caer una AZ, el grupo lanza reemplazos en la AZ sana.

   Preferible: la opción B por coste. Solo se paga capacidad extra durante las horas del pico (unas pocas al día) en lugar de mantener una instancia adicional las 730 horas del mes, y además reacciona automáticamente a picos no previstos. Su único inconveniente es el tiempo de arranque de las instancias nuevas, que se mitiga con una imagen preparada y con un umbral de escalado suficientemente anticipado. El escalado automático se trata en el módulo 2 y el balanceo en el 3.

Ya sabes cómo está construido AWS por dentro y, sobre todo, por qué esa estructura importa para tu arquitectura. Has visto las tres capas —regiones, zonas de disponibilidad y red de borde—, la nomenclatura eu-west-1, el aislamiento entre regiones que sostiene el cumplimiento del RGPD, y qué es realmente una AZ: instalaciones con energía, refrigeración y red independientes, separadas kilómetros pero unidas por fibra a 1-2 ms, que es justo lo que hace posible la replicación síncrona de bases de datos.

Has aprendido a distinguir servicios globales, regionales y zonales —la clave para saber qué redundancia te da AWS gratis y cuál tienes que diseñar tú—, a razonar la elección de región con cinco criterios (latencia, cumplimiento, catálogo, precio y proximidad), y a estimar el coste del tráfico entre AZ y entre regiones. Y MercadoFresco ya tiene su decisión tomada y documentada: eu-west-1, con despliegue repartido en dos zonas de disponibilidad.

En la siguiente lección, 01-04 «Consola de administración de AWS», bajamos al terreno: recorremos la consola con la que trabajarás a diario, aprenderemos a no caer en la trampa del selector de región que acabamos de mencionar, veremos cómo etiquetar y localizar recursos dispersos con Tag Editor, y crearás tu primer recurso real en la cuenta de MercadoFresco.