Cerramos la Parte I uniendo todo lo aprendido sobre la geografía de AWS —regiones, zonas de disponibilidad y edge locations— bajo tres conceptos que guiarán muchísimas de tus decisiones de arquitectura: latencia, resiliencia y soberanía de datos. Son las tres preguntas que te harás cada vez que diseñes algo en la nube.

La latencia es el tiempo que tardan los datos en ir de un punto a otro y volver. Se mide en milisegundos (ms). Cuanto menor sea la latencia, más rápida y fluida se siente tu aplicación.

La latencia depende mucho de la distancia física: los datos viajan rápido, pero no infinitamente rápido. Cruzar un océano siempre añade retraso.

Ejemplo: Un usuario en Madrid accediendo a un servidor en Madrid puede tener ~5 ms de latencia. El mismo usuario accediendo a un servidor en Tokio puede tener ~250 ms. Esa diferencia es perceptible: la web «va a tirones» con la opción lejana.

Cómo reducir la latencia con lo que has aprendido:

• Elige una región cercana a tus usuarios (subcapítulo 3.1).
• Usa CloudFront y edge locations para servir contenido desde el punto más cercano (subcapítulo 3.3).

Dato: Para servicios donde cada milisegundo cuenta (videojuegos online, trading financiero, videollamadas), la latencia es la prioridad de diseño.

La resiliencia es la capacidad de tu sistema de seguir funcionando a pesar de los fallos. Como vimos, en la nube se asume que el hardware fallará, así que diseñamos para que eso no tumbe el servicio.

Cómo conseguir resiliencia con lo aprendido:

La palabra clave aquí es redundancia: tener copias o componentes de repuesto repartidos, de modo que la caída de uno no implique la caída del todo.

Ejemplo real: Una pasarela de pagos no puede caerse nunca. La diseñan multi-AZ para sobrevivir a fallos de datacenter, y replican datos en una segunda región por si una región entera tuviera un problema catastrófico. Así garantizan que los pagos siguen funcionando pase lo que pase.

Veremos la resiliencia en profundidad en el Capítulo 26 (alta disponibilidad y recuperación ante desastres), con conceptos como RTO y RPO.

La soberanía de datos se refiere a las leyes y regulaciones que determinan dónde se pueden almacenar y procesar ciertos datos, y qué leyes se les aplican según el país donde estén.

No es un tema técnico, sino legal, pero condiciona decisiones técnicas (qué región eliges).

Ejemplo real — el RGPD: El Reglamento General de Protección de Datos de la Unión Europea regula cómo se tratan los datos personales de ciudadanos europeos. Muchas empresas, para cumplirlo con tranquilidad, deciden almacenar los datos de sus clientes europeos en regiones de AWS dentro de la UE (España, Irlanda, Fráncfort…).

Otros ejemplos de requisitos de soberanía:

• Datos de sanidad que por ley deben permanecer en el país.
• Datos de administraciones públicas con exigencias de localización.
• Sectores financieros con normativas estrictas sobre dónde residen los datos.

Cómo lo gestionas con lo aprendido: eligiendo la región adecuada (subcapítulo 3.1). Como las regiones están aisladas y sabes exactamente en qué país está cada una, puedes garantizar que los datos no salen de donde deben.

Cuando diseñes cualquier sistema en AWS, estos tres conceptos se traducen en tres preguntas:

1. Latencia: ¿Dónde están mis usuarios? → Elige región cercana + CloudFront.
2. Resiliencia: ¿Qué pasa si falla un datacenter o una región? → Multi-AZ y, si es crítico, multi-región.
3. Soberanía: ¿Hay leyes sobre dónde deben estar mis datos? → Elige región que cumpla la normativa.

A veces estas tres fuerzas entran en tensión y hay que equilibrarlas:

Ejemplo de compromiso: Tus usuarios más rápidos estarían servidos desde Virginia (latencia baja para América), pero la ley te obliga a guardar datos europeos en la UE (soberanía). Solución típica: alojas los datos en Europa (cumples la ley) y usas CloudFront para acelerar la entrega globalmente (mitigas la latencia).

• Latencia: tiempo de respuesta; se reduce acercando la región y usando edge locations/CloudFront.
• Resiliencia: capacidad de seguir funcionando ante fallos; se logra con redundancia multi-AZ y, si es crítico, multi-región.
• Soberanía de datos: requisitos legales sobre dónde residen los datos; se cumple eligiendo la región adecuada.
• Casi toda decisión de arquitectura geográfica nace de equilibrar estas tres fuerzas.

Con esto cierras la Parte I. Ya dominas los fundamentos conceptuales de la nube. En la Parte II dejamos la teoría y entramos en lo práctico: los servicios esenciales de AWS, empezando por el cómputo con EC2.