Cómo diseñar una arquitectura AWS Multi-AZ sin sobredimensionar

1. Primero: ¿qué significa realmente Multi-AZ?

Cuando hablamos de una arquitectura Multi-AZ en AWS, estamos hablando de desplegar recursos en más de una Availability Zone, o zona de disponibilidad, dentro de una misma región.

Una región de AWS, por ejemplo eu-west-1 en Irlanda, está formada por varias zonas de disponibilidad. Cada zona es como un centro de datos, o grupo de centros de datos, separado físicamente del resto, con alimentación, red y conectividad independientes.

La idea es sencilla: si una zona tiene un problema, tu aplicación no debería caer entera. Puede degradarse, puede ir más lenta o puede perder parte de capacidad, pero debería poder seguir funcionando desde otra zona.

Para un alumno que empieza, la forma más fácil de entenderlo es esta:

• Una sola AZ: si esa zona falla, tu aplicación puede caer.
• Varias AZ: si una zona falla, otra puede seguir atendiendo tráfico.
• Varias regiones: si una región completa falla, otra región podría asumir el servicio.

Y aquí viene el primer error típico: pensar que Multi-AZ significa duplicarlo absolutamente todo. No siempre. Lo importante es saber qué componentes necesitan alta disponibilidad, qué nivel de servicio espera el negocio y cuánto coste tiene mantener esa resiliencia.

2. La alta disponibilidad no empieza en AWS, empieza en el negocio

Antes de abrir la consola de AWS y empezar a crear subredes, balanceadores o bases de datos, hay que hacerse una pregunta muy poco técnica pero muy importante:

¿Cuánto daño hace que esta aplicación deje de funcionar?

No es lo mismo una web pública que genera ventas cada minuto, que una aplicación interna que solo se usa de lunes a viernes, que un entorno de pruebas, que una base de datos crítica para facturación.

En AWS puedes diseñar arquitecturas muy resistentes, pero todo tiene coste. Más zonas, más balanceadores, más NAT Gateways, más réplicas, más backups, más tráfico entre zonas, más monitorización y más operación.

Por eso, una buena arquitectura no es siempre la más grande. Una buena arquitectura es la que cumple el objetivo sin tirar dinero.

3. RTO y RPO explicado sin complicarlo

En muchas arquitecturas aparecen dos conceptos que suelen sonar más complicados de lo que realmente son: RTO y RPO. Para CLF-C02 no necesitas ser arquitecto senior, pero sí entender la idea.

Concepto	Qué significa	Ejemplo sencillo	Cómo afecta al diseño
RTO	Tiempo máximo que la aplicación puede estar caída	“Como mucho puede estar 15 minutos sin funcionar”	Define si necesitas failover automático, Auto Scaling, Multi-AZ o procesos manuales
RPO	Cantidad máxima de datos que puedes perder	“Puedo perder como mucho los últimos 5 minutos de datos”	Define backups, replicación, frecuencia de copias y diseño de base de datos
Degradación aceptable	Qué puede seguir funcionando aunque no esté todo al 100%	“Durante una incidencia acepto solo lectura, pero no nuevas compras”	Permite ahorrar costes si no todo necesita estar activo al máximo

Un ejemplo práctico:

Imagina una tienda online. Si se cae durante 5 minutos, puede perder ventas. Si además pierde pedidos ya realizados, el problema es mucho más grave. Por eso, el RTO habla del tiempo sin servicio y el RPO habla de la pérdida de datos.

En el examen CLF-C02, muchas preguntas no te pedirán diseñar una arquitectura completa, pero sí reconocer qué servicio ayuda a conseguir alta disponibilidad, recuperación, escalabilidad o protección de datos.

4. Patrón base de arquitectura web Multi-AZ

Vamos con un patrón muy típico y muy útil para entender AWS:

• Una VPC como red principal.
• Subredes públicas en dos Availability Zones.
• Subredes privadas en dos Availability Zones.
• Un Application Load Balancer en subredes públicas.
• Instancias EC2 o contenedores en subredes privadas.
• Un Auto Scaling Group repartido entre zonas.
• Una base de datos gestionada, normalmente Amazon RDS Multi-AZ o Amazon Aurora.
• Monitorización con Amazon CloudWatch.

La idea es que los usuarios entren por Internet, lleguen al balanceador y el balanceador reparta el tráfico entre las instancias sanas que están en subredes privadas.

Las instancias no necesitan tener IP pública. De hecho, lo normal es que no la tengan. El balanceador es la pieza expuesta y las instancias quedan protegidas en una capa privada.

5. La VPC: donde empieza el orden

Una VPC es tu red virtual dentro de AWS. Dentro de esa VPC creas subredes, tablas de rutas, gateways, reglas de seguridad y conectividad.

Para una arquitectura Multi-AZ básica, lo normal es crear subredes en al menos dos zonas. Por ejemplo:

Tipo de subred	Zona A	Zona B	Uso habitual
Pública	Public Subnet A	Public Subnet B	ALB, NAT Gateway, bastion si existiera
Privada de aplicación	App Subnet A	App Subnet B	EC2, ECS, servicios de aplicación
Privada de base de datos	DB Subnet A	DB Subnet B	RDS, Aurora, bases de datos

La diferencia entre subred pública y privada no es el nombre. La diferencia real está en la tabla de rutas.

Una subred pública tiene una ruta hacia un Internet Gateway. Una subred privada no tiene salida directa hacia Internet. Si necesita salir para descargar parches, llamar APIs externas o acceder a repositorios, normalmente lo hace mediante un NAT Gateway.

Esto es muy importante porque en AWS muchas veces la seguridad no depende de una sola cosa. Depende de capas: rutas, Security Groups, NACLs, IAM, cifrado, monitorización y buenas prácticas.

6. Application Load Balancer: la puerta de entrada

El Application Load Balancer, o ALB, es una pieza clave en muchas arquitecturas web.

Su trabajo principal es recibir tráfico HTTP o HTTPS y repartirlo entre varios destinos, normalmente instancias EC2, contenedores o direcciones IP.

Pero no solo reparte tráfico. También ayuda a detectar qué instancias están sanas mediante health checks. Si una instancia deja de responder correctamente, el balanceador deja de enviarle tráfico.

Esto es justo lo que queremos en una arquitectura Multi-AZ: que el tráfico vaya a los recursos sanos, aunque una instancia o una zona tenga problemas.

¿Por qué poner el ALB en varias AZ?

Porque si el balanceador solo estuviera asociado a una zona, esa zona se convertiría en un punto débil. En una arquitectura bien planteada, el ALB se asocia a subredes públicas en al menos dos zonas de disponibilidad.

Después, el Target Group del balanceador apunta a las instancias o servicios que están por detrás.

7. Auto Scaling: no pagar de más y reaccionar mejor

Uno de los errores más comunes al pensar en alta disponibilidad es decir: “si necesito dos zonas, pongo la misma capacidad completa en cada zona”.

A veces tiene sentido. Pero muchas veces no.

Para eso existe Auto Scaling. Un Auto Scaling Group puede lanzar instancias EC2 en varias Availability Zones y ajustar la cantidad de instancias según la demanda.

Por ejemplo, puedes definir:

• Mínimo: 2 instancias.
• Deseado: 2 instancias.
• Máximo: 6 instancias.

Así tienes una base mínima repartida entre zonas, pero no pagas siempre por el pico máximo.

Si sube la CPU, aumenta el número de peticiones o crece la latencia, Auto Scaling puede lanzar más instancias. Si baja la carga, puede reducir capacidad.

La clave está en elegir bien las métricas. Escalar solo por CPU no siempre es suficiente. En aplicaciones web también puede tener sentido mirar número de peticiones, latencia, cola de trabajo o métricas personalizadas.

Error típico

Poner un Auto Scaling Group sin alarmas bien pensadas, sin límites razonables o sin probar cuánto tarda una instancia nueva en estar realmente preparada.

Una instancia puede aparecer como creada, pero eso no significa que la aplicación ya esté lista para recibir tráfico. Por eso existen conceptos como health checks, warmup, cooldown y validaciones de arranque.

8. La base de datos suele mandar más que las EC2

En muchas arquitecturas, las instancias de aplicación son relativamente fáciles de reemplazar. Si una EC2 cae, Auto Scaling puede crear otra. Si una zona falla, el balanceador puede enviar tráfico a otra zona.

Pero la base de datos es otra historia.

La base de datos guarda el estado importante: usuarios, pedidos, pagos, sesiones, inventario, registros, etc. Por eso hay que tratarla con mucho más cuidado.

Amazon RDS Multi-AZ

Con Amazon RDS Multi-AZ, AWS mantiene una instancia principal y una réplica en standby en otra zona de disponibilidad. Si la instancia principal falla, AWS puede hacer failover hacia la standby.

Esto mejora la disponibilidad, pero hay algo importante: la standby no se usa normalmente para repartir lecturas en el diseño clásico de RDS Multi-AZ. Su objetivo principal es estar preparada para recuperación.

Amazon Aurora

Amazon Aurora tiene una arquitectura diferente. Su almacenamiento se replica automáticamente entre varias zonas de disponibilidad. Además, puede tener réplicas de lectura y suele ofrecer muy buena disponibilidad y rendimiento para aplicaciones críticas.

Backups

Multi-AZ no sustituye a los backups.

Esto es clave. Si alguien borra una tabla por error, si una aplicación corrompe datos o si se ejecuta una mala operación, tener Multi-AZ no te salva necesariamente. La réplica puede recibir también el dato malo.

Para eso necesitas backups, snapshots, retención y pruebas de restauración.

9. NAT Gateway: útil, pero ojo con el coste

El NAT Gateway permite que recursos en subredes privadas salgan a Internet sin ser accesibles directamente desde Internet.

Ejemplo sencillo: tienes una EC2 privada que necesita descargar actualizaciones del sistema operativo. No quieres ponerle IP pública. Entonces esa instancia sale a Internet mediante un NAT Gateway.

Hasta aquí perfecto.

El problema es que el NAT Gateway tiene coste por hora y coste por datos procesados. Y si creas uno por cada zona de disponibilidad, mejoras la resiliencia, pero también aumentas el coste fijo.

¿Un NAT o varios NAT?

Diseño	Ventaja	Riesgo o coste
Un solo NAT Gateway	Más barato	Si falla la zona del NAT, otras zonas pueden quedarse sin salida
Un NAT Gateway por AZ	Mejor resiliencia y menos dependencia cruzada	Más coste fijo mensual
VPC Endpoints	Reducen salida a Internet para servicios AWS compatibles	Hay que diseñarlos y saber qué servicios aplican

Para CLF-C02, no hace falta que calcules precios exactos, pero sí debes entender la idea: algunos servicios mejoran disponibilidad o seguridad, pero también tienen impacto en coste.

10. Dónde se suele sobredimensionar una arquitectura Multi-AZ

Sobredimensionar es montar más capacidad de la necesaria “por si acaso”. A veces se hace por miedo, a veces por desconocimiento y a veces porque nadie ha medido bien la carga real.

Estos son errores bastante habituales:

• Poner demasiadas instancias fijas: en lugar de usar Auto Scaling con mínimos y máximos razonables.
• Duplicar NAT Gateways sin analizar tráfico: puede ser correcto, pero conviene saber por qué se hace.
• Usar bases de datos muy grandes para tapar problemas de consultas: a veces el problema no es la instancia, sino índices mal diseñados o consultas pesadas.
• Guardar todo en almacenamiento caro: en S3, por ejemplo, hay clases de almacenamiento según uso, acceso y recuperación.
• No usar servicios gestionados: mantener tú mismo algo que AWS podría gestionar puede aumentar operación y riesgo.
• No apagar entornos no productivos: desarrollo, pruebas o laboratorios no siempre necesitan estar 24x7.
• No revisar métricas: si nadie mira CloudWatch, se termina dimensionando “a ojo”.

11. Observabilidad: si no lo mides, no sabes si funciona

Una arquitectura puede parecer preciosa en un diagrama, pero si no tienes métricas, logs y alarmas, vas bastante a ciegas.

En AWS, el servicio principal para monitorización es Amazon CloudWatch. Con CloudWatch puedes recopilar métricas, crear alarmas, revisar logs y reaccionar ante eventos.

En una arquitectura Multi-AZ deberías vigilar, como mínimo:

• Healthy hosts del ALB: cuántos destinos sanos tiene el balanceador.
• Errores 4xx y 5xx: errores de cliente y servidor.
• Latencia: cuánto tarda en responder la aplicación.
• CPU de EC2: útil, aunque no siempre suficiente.
• Memoria: requiere agente de CloudWatch en EC2.
• Escalados del Auto Scaling Group: cuándo añade o elimina instancias.
• Conexiones a base de datos: para detectar saturación.
• Almacenamiento libre: especialmente en bases de datos.
• Eventos de failover: para saber cuándo RDS o Aurora han cambiado de nodo.

También conviene enviar logs de aplicación a CloudWatch Logs o a una solución centralizada. Porque cuando algo falla, necesitas saber qué ha pasado, no solo ver que “está en rojo”.

12. Seguridad básica en una arquitectura Multi-AZ

Multi-AZ mejora disponibilidad, pero no sustituye a la seguridad.

Una arquitectura puede estar muy bien repartida entre zonas y aun así ser insegura si tiene puertos abiertos a todo Internet, credenciales mal gestionadas o permisos IAM demasiado amplios.

Algunas buenas prácticas básicas:

• No exponer las EC2 directamente si no hace falta. Mejor que reciban tráfico desde el ALB.
• Usar Security Groups restrictivos. Por ejemplo, permitir tráfico a las EC2 solo desde el Security Group del ALB.
• No guardar secretos en código. Usar servicios como AWS Secrets Manager o Systems Manager Parameter Store.
• Cifrar datos en reposo. Por ejemplo, en RDS, EBS o S3.
• Usar HTTPS. Normalmente con certificados gestionados en AWS Certificate Manager.
• Aplicar mínimo privilegio en IAM. Cada rol debe tener solo los permisos que necesita.

13. Multi-AZ no es Multi-Region

Este punto es muy importante, porque suele generar confusión.

Multi-AZ significa que usas varias zonas dentro de una misma región. Esto te protege frente a fallos de una zona de disponibilidad.

Multi-Region significa que usas varias regiones de AWS. Esto puede ayudarte frente a una caída regional, requisitos de residencia geográfica, baja latencia global o continuidad de negocio más avanzada.

Diseño	Protege principalmente frente a	Complejidad	Coste
Single-AZ	Fallos menores de instancia si hay recuperación manual o backups	Baja	Más bajo
Multi-AZ	Fallo de instancia o de zona de disponibilidad	Media	Medio
Multi-Region	Fallo regional o necesidad de servicio global	Alta	Más alto

Para la mayoría de aplicaciones empresariales normales, Multi-AZ suele ser un muy buen equilibrio entre disponibilidad, complejidad y coste.

Multi-Region es potente, pero no es gratis ni sencillo. Hay que pensar en replicación de datos, DNS, consistencia, operación, pruebas, seguridad, despliegues y recuperación.

14. Ejemplo de arquitectura razonable para una web

Vamos a bajarlo a tierra con un ejemplo típico.

Supón que tienes una aplicación web para alumnos. Los usuarios entran, consultan contenido, hacen tests y guardan progreso.

Una arquitectura razonable podría ser:

• Route 53 para gestionar el DNS del dominio.
• CloudFront para distribuir contenido estático y mejorar rendimiento.
• S3 para alojar imágenes, CSS, JavaScript o contenido estático.
• Application Load Balancer para entrada HTTP/HTTPS a la parte dinámica.
• EC2 Auto Scaling Group o ECS en subredes privadas para la aplicación.
• RDS Multi-AZ para la base de datos relacional.
• CloudWatch para métricas, logs y alarmas.
• AWS Backup o snapshots gestionados para recuperación.
• IAM con roles y permisos mínimos necesarios.

¿Se podría hacer más complejo? Sí. ¿Hace falta siempre? No.

Podrías añadir WAF, Shield, Aurora, ElastiCache, SQS, Lambda, EventBridge, multi-región, pipelines CI/CD y muchas más piezas. Pero cada pieza debe tener una razón.

15. Cómo puede aparecer esto en el examen CLF-C02

En el examen AWS Certified Cloud Practitioner no te van a pedir configurar una VPC paso a paso como en un examen de arquitectura avanzada. Pero sí pueden preguntarte por conceptos.

Por ejemplo, podrían preguntarte:

• Qué servicio reparte tráfico entre varias instancias.
• Qué servicio permite escalar automáticamente capacidad.
• Qué diseño mejora disponibilidad dentro de una región.
• Qué diferencia hay entre Multi-AZ y Multi-Region.
• Qué servicio se usa para monitorización y alarmas.
• Qué servicio gestionado de base de datos puede configurarse en Multi-AZ.
• Qué ventaja tiene usar servicios gestionados frente a administrarlo todo en EC2.
• Cómo se controla el coste evitando capacidad fija innecesaria.

Asociaciones rápidas para memorizar

Necesidad	Servicio o concepto AWS
Repartir tráfico web	Elastic Load Balancing / Application Load Balancer
Escalar EC2 automáticamente	Auto Scaling Group
Alta disponibilidad de base de datos relacional	Amazon RDS Multi-AZ
Monitorización y alarmas	Amazon CloudWatch
DNS y enrutamiento	Amazon Route 53
Contenido estático y objetos	Amazon S3
Distribución global de contenido	Amazon CloudFront
Salida a Internet desde subred privada	NAT Gateway
Conectividad privada a servicios AWS	VPC Endpoints

16. Checklist para revisar tu diseño Multi-AZ

Antes de dar por buena una arquitectura Multi-AZ, conviene hacerse estas preguntas:

• ¿La aplicación está desplegada en al menos dos Availability Zones?
  Si todo está en una sola zona, no tienes alta disponibilidad real frente a fallo de AZ.
• ¿El ALB está asociado a subredes públicas en varias zonas?
  El balanceador debe poder recibir tráfico aunque una zona tenga problemas.
• ¿Las instancias o contenedores están en subredes privadas?
  No deberían estar expuestos directamente a Internet salvo que exista una razón clara.
• ¿El Auto Scaling Group puede lanzar capacidad en más de una zona?
  Si solo escala en una AZ, el diseño queda limitado.
• ¿La base de datos tiene estrategia de alta disponibilidad?
  RDS Multi-AZ, Aurora o una alternativa coherente con los requisitos.
• ¿Existen backups y se ha probado la restauración?
  Un backup que nunca se ha restaurado es más una esperanza que una garantía.
• ¿Las tablas de rutas son coherentes?
  Subred pública con Internet Gateway, subred privada sin exposición directa.
• ¿Se ha revisado el coste de NAT Gateway, instancias y base de datos?
  La resiliencia tiene coste. Hay que saber dónde se está gastando.
• ¿CloudWatch tiene alarmas útiles?
  No basta con tener métricas. Hay que enterarse cuando algo va mal.
• ¿Se ha probado un fallo?
  Parar una instancia de prueba, revisar health checks y validar recuperación ayuda mucho.

17. Errores típicos que conviene evitar

Estos errores son muy normales cuando estás aprendiendo AWS:

Error 1: pensar que Multi-AZ es backup

No. Multi-AZ ayuda a que el servicio siga funcionando si falla infraestructura. Pero si borras datos, necesitas backups o mecanismos de recuperación.

Error 2: poner todo público

Que algo funcione no significa que esté bien diseñado. Una EC2 con IP pública y SSH abierto a Internet puede funcionar, pero no es una buena práctica.

Error 3: usar instancias enormes sin medir

Antes de subir tamaño de instancia, mira métricas. A veces el problema está en la base de datos, en consultas lentas, en falta de caché o en mala configuración.

Error 4: no probar el failover

Una arquitectura no está validada solo porque el diagrama diga Multi-AZ. Hay que probar qué pasa cuando algo falla.

Error 5: olvidar la operación diaria

Alguien tiene que mirar alarmas, revisar costes, actualizar sistemas, analizar logs y documentar procedimientos. La nube reduce trabajo, pero no elimina la responsabilidad.

18. Decisión práctica: cuándo Multi-AZ es suficiente y cuándo no

Multi-AZ suele ser suficiente cuando quieres protegerte frente a fallos dentro de una región: una instancia que cae, una zona que se degrada, mantenimiento de infraestructura o pérdida parcial de capacidad.

Para muchas aplicaciones web, APIs internas, portales corporativos, paneles de gestión y servicios empresariales, Multi-AZ ofrece un equilibrio muy razonable.

Pero si el requisito es soportar la caída completa de una región, dar servicio global con baja latencia o cumplir requisitos regulatorios en varias geografías, entonces hay que mirar hacia Multi-Region.

Escenario	Diseño razonable	Comentario
Blog, web corporativa o portal informativo	S3 + CloudFront o ALB + Auto Scaling si hay backend	No siempre necesitas una arquitectura compleja
Aplicación web de negocio	ALB + Auto Scaling + RDS Multi-AZ	Buen equilibrio entre disponibilidad y coste
Aplicación crítica con datos importantes	Multi-AZ + backups + monitorización + pruebas de recuperación	La base de datos y el RPO son claves
Servicio global crítico	Multi-Region con estrategia de datos y DNS failover	Más potente, pero bastante más complejo

19. La operación también forma parte de la arquitectura

Esto es algo que se aprende rápido en proyectos reales: el diagrama no opera la plataforma.

Puedes tener una arquitectura muy bien dibujada, pero si nadie sabe qué hacer cuando salta una alarma, la solución está incompleta.

Por eso conviene documentar:

• Qué alarmas existen y qué significa cada una.
• Quién recibe avisos cuando algo falla.
• Cómo se comprueba si el ALB tiene targets sanos.
• Cómo se revisa si Auto Scaling ha lanzado instancias.
• Cómo se consulta el estado de RDS o Aurora.
• Cómo se restaura una copia de seguridad.
• Cómo se actúa si una zona queda degradada.
• Cómo se revisa el coste mensual.

Una arquitectura madura no es solo la que resiste fallos. Es la que el equipo sabe entender, mantener y recuperar.

20. Resumen para quedarte con lo importante

Si estás preparando CLF-C02, quédate con estas ideas:

• Multi-AZ mejora la disponibilidad dentro de una región.
• No es lo mismo que Multi-Region.
• El ALB reparte tráfico entre recursos sanos.
• Auto Scaling ayuda a ajustar capacidad y controlar costes.
• RDS Multi-AZ mejora disponibilidad de base de datos.
• Los backups siguen siendo necesarios.
• CloudWatch permite monitorizar, crear alarmas y detectar problemas.
• Las subredes privadas reducen exposición directa a Internet.
• El NAT Gateway da salida a Internet a recursos privados, pero tiene coste.
• Una buena arquitectura busca equilibrio entre disponibilidad, seguridad, rendimiento y coste.

Conclusión

Diseñar una arquitectura AWS Multi-AZ no consiste en meter servicios porque sí ni en duplicar todo sin pensar. Consiste en entender qué necesita la aplicación, qué impacto tendría una caída y cuánto merece la pena invertir para reducir ese riesgo.

Para una base sólida de AWS, especialmente si estás preparando la certificación AWS Certified Cloud Practitioner CLF-C02, lo importante es entender el papel de cada pieza: VPC, subredes, ALB, Auto Scaling, RDS Multi-AZ, CloudWatch, backups y costes.

Cuando entiendes cómo encajan esas piezas, empiezas a ver AWS de otra forma. Ya no memorizas servicios sueltos: empiezas a pensar como alguien que diseña soluciones reales.