Infraestructura global de AWS y resiliencia

Toda carga de trabajo de AWS acaba respondiendo una pregunta: ¿dónde corre, y qué pasa cuando ese lugar se rompe? El examen lo llama Dominio 3, Tarea 3.2: «Definir la infraestructura global de AWS», y es una de las tareas más rentables de CLF-C02 porque un solo error de vocabulario (Región frente a Zona de Disponibilidad frente a ubicación de borde) puede costarte varias preguntas de golpe. El encuadre de la propia AWS es directo: el CTO de Amazon Werner Vogels dice «Todo falla, todo el tiempo», y el Well-Architected Framework existe para que puedas «preparar tu carga de trabajo para el fallo» en lugar de fingir que no ocurrirá.

En esta lección vas a:

• separar Regiones, Zonas de Disponibilidad y ubicaciones de borde por definición, recuento y capacidad;
• explicar por qué las Regiones están aisladas: tolerancia a fallos, residencia de datos y latencia;
• elegir una Región con el conjunto de decisión de cumplimiento, latencia, precio y características;
• aplicar la regla de diseño de AZ (AWS entrega ≥3 AZs por Región; tu aplicación usa ≥2);
• distinguir CloudFront, Route 53 y Global Accelerator por su plano de entrada;
• situar Local Zones, Wavelength, Outposts y Snow en el continuo híbrido de borde;
• definir con precisión resiliencia, disponibilidad, tolerancia a fallos, alta disponibilidad y recuperación ante desastres;
• leer y calcular RTO y RPO, y ordenar las cuatro estrategias de DR por coste frente a velocidad de recuperación;
• estudiar cuatro casos de estudio de resiliencia publicados por AWS, dos de ellos añadidos en esta revisión;
• aprender qué lanzó AWS de verdad entre 2025 y octubre de 2026: Regiones, Local Zones y planes anunciados pero aún sin abrir;
• practicar con 12 preguntas estilo examen más cuatro comprobaciones interactivas.

---

1. Regiones, Zonas de Disponibilidad y ubicaciones de borde

1.1 Las tres definiciones, con las palabras de AWS

Tres hechos sobre la relación hacen la mayor parte del trabajo del examen:

1. Una Región contiene al menos tres AZs: «Cada Región de AWS consta de un mínimo de tres AZs, aisladas y físicamente separadas, dentro de un área geográfica» (en octubre de 2026: 39 Regiones y 124 AZs en activo, con 7 AZs más y 2 Regiones más anunciadas para el Reino de Arabia Saudita y Chile).
2. Las AZs no comparten puntos únicos de fallo. La tarea 3.2 de la guía del examen exige explícitamente el conocimiento de que «las Zonas de Disponibilidad no comparten puntos únicos de fallo».
3. Las ubicaciones de borde son una capa de entrega, no una capa de cómputo. Los beneficios de las ubicaciones de borde, según la guía del examen, son la latencia y la descarga para la entrega: nunca «ejecuta mi aplicación aquí».

1.2 Ejemplo E1: reconciliar el recuento de AZs

El bloque de estadísticas de AWS dice 124 AZs (en octubre de 2026). Las tablas de IDs de AZ en la documentación de infraestructura global cubren solo las 34 Regiones que una cuenta estándar puede ver. Reconcilia ambas:

La aritmética solo cierra si el 124 publicado cuenta las Regiones que existen hoy, no la Región saudí anunciada pero aún sin abrir. Las adiciones anunciadas (+7 AZs, +2 Regiones) son planes, nunca hechos de lanzamiento: el examen no te reconocerá tratar un anuncio como una apertura.

1.3 Para qué sirve cada capa

• 📚 ¿Sabías que…? AWS interconecta «todas las AZs ... con una red de alta banda y baja latencia sobre fibra metropolitana dedicada y totalmente redundante», cifra todo el tráfico entre AZs, y declara que el rendimiento «es suficiente para lograr replicación síncrona entre AZs». Las AZs están «físicamente separadas por una distancia significativa, muchos kilómetros» y sin embargo «todas están a menos de 100 km (60 millas) entre sí» (en octubre de 2026). Ese sobre apretado pero no diminuto es exactamente por qué la replicación síncrona multi-AZ es posible y por qué una Región entera aún puede caer por un solo evento regional.

1.4 Dónde están las Regiones (en octubre de 2026)

Contar las Regiones lanzadas por geografía da una comprobación de cordura útil sobre las afirmaciones de «alcance global», y muestra por qué no puedes dar por supuesto que tu Región preferida exista:

De aquí salen dos lecciones. Primero, «AWS no tiene Región en X» es una respuesta de examen legítima: la disponibilidad de servicios es un factor real de selección de Región, no un formalismo, porque un conjunto definido de servicios centrales se entrega con cada apertura de Región mientras que un nivel adicional «suele lanzarse dentro de los 12 meses de la apertura de una nueva Región». Segundo, los recuentos cambian cada trimestre: trata la tabla como una instantánea fechada en octubre de 2026 y vuelve a comprobar las páginas de infraestructura global de AWS antes de citar cualquier cifra fuera de esta lección. (Esta investigación no pudo reconciliar cada entrada del mapa con la propia tabla de documentación de AWS, así que la columna «listadas» es un recuento del mapa, no un total oficial.)

Actualizaciones de 2026 (en octubre de 2026)

La infraestructura global no se quedó quieta mientras estudiabas. Lo que sigue es cada adición de infraestructura fechada y publicada por AWS de 2025 to 26 encontrada en este ciclo de investigación: los lanzamientos llevan fecha, los planes no, y solo los lanzamientos cuentan:

• 📚 ¿Sabías que…? 2025 fue el año más denso en aperturas de Regiones de este ciclo de investigación, cuatro Regiones en poco más de ocho meses (Tailandia 2025-01-07, México 2025-01-14, Taiwán 2025-06-06, Nueva Zelanda 2025-09-02), y sin embargo la cifra principal publicada por AWS en octubre de 2026 seguía siendo 39 Regiones y 124 AZs. Cada una de esas aperturas viene con el mínimo de diseño de AWS de al menos tres AZs aisladas y físicamente separadas, y por eso el total de AZs y el total de Regiones suben juntos y no de forma independiente.

---

2. Por qué las Regiones están aisladas: tolerancia a fallos, residencia de datos, latencia

2.1 Tolerancia a fallos: dominios de fallo separados a propósito

Las Regiones están aisladas para que ningún único evento regional pueda tumbar todo lo que ejecutas. El mecanismo es el aislamiento de fallos, la guía prescriptiva de AWS lo define como restringir «el alcance del impacto a un contenedor de fallo previsto cuando ocurre un fallo», y declara que «Redundancia, La tolerancia a fallos se logra mediante la redundancia que elimina los puntos únicos de fallo (SPOF)».

La propia tolerancia a fallos tiene una definición precisa: «la capacidad de resistir el fallo de un subsistema y mantener la disponibilidad (hacer lo correcto dentro de un SLA establecido). Para implementar la tolerancia a fallos, las cargas de trabajo usan subsistemas de reserva (o redundantes).» Las reservas en caliente cuestan dinero; ese coste es por qué la tolerancia a fallos se sitúa por encima de la simple alta disponibilidad en la escalera de precios.

2.2 Residencia y soberanía de datos

Algunas cargas de trabajo solo pueden ejecutarse legal o contractualmente en una geografía concreta. AWS te da tres niveles anidados de control de residencia:

1. Nivel de Región: elige una Región dentro de la jurisdicción requerida (y, cuando haga falta, un tipo de cuenta especial como AWS GovCloud (US) o las Regiones AWS China);
2. Nivel de Local Zone: AWS describe las Local Zones como una manera de «abordar los requisitos de residencia de datos» permitiéndote «controlar dónde se ejecutan tus cargas de trabajo y dónde residen tus datos» en una metrópoli concreta;
3. Nivel de Wavelength Zone: los datos «permanecen dentro de los límites geográficos que especifiques» cuando colocas cómputo dentro de una instalación 5G de un operador.

2.3 Latencia: la proximidad es una entrada de diseño

La documentación de Regiones de AWS es directa: «puedes reducir la latencia de red cuando seleccionas una Región cercana a la mayoría de tus usuarios» (en octubre de 2026). La consecuencia práctica es una regla de dos niveles:

• Cómputo que debe estar cerca de los usuarios → elige la Región más cercana que tenga los servicios que necesitas, o una Local Zone / Wavelength Zone en esa metrópoli;
• Contenido que puede almacenarse en caché → deja la carga de trabajo en una Región y deja que los 750+ PoPs de CloudFront (en octubre de 2026) acorten el camino para el resto.

2.4 Ejemplo E2: la redundancia multiplica la disponibilidad

La documentación de fiabilidad de AWS muestra la aritmética de componentes independientes. Dos componentes cada uno con un 99.9% de disponibilidad, que fallan de forma independiente, se combinan como:

$$1 - (0.001 \times 0.001) = 1 - 10^{-6} = 0.999999 = \mathbf{99.9999\%}$$

Esa es la promesa detrás de ejecutar en dos AZs: la probabilidad de fallo de cada AZ es (aproximadamente) independiente de la otra, así que la pareja es vastamente más disponible que cualquiera de sus miembros. La misma fórmula explica el lado oscuro: tres dependencias duras que cada una tiene un 99.99% limitan toda la carga de trabajo a:

$$0.9999^3 = 0.9997 = \mathbf{99.97\%}$$

Un eslabón débil baja el techo de una arquitectura por lo demás excelente. Esta es la aritmética de resiliencia favorita del examen: la redundancia solo ayuda cuando las partes redundantes son genuinamente independientes (AZs distintas, no dos servidores en un mismo rack).

---

3. Elegir una Región: cumplimiento, latencia, precio y características

3.1 Los cuatro factores (más dos que olvidas)

El orden importa más que la lista: en el examen, un límite legal o regulatorio declarado gana a cualquier otro factor, y «más barato en otro sitio» nunca gana cuando está en juego la residencia. La propia redacción de AWS para el factor de coste es condicional: despliega en una Región más cara solo cuando la latencia, la residencia o la soberanía lo exijan.

3.2 Ejemplo E3: el presupuesto de disponibilidad al año

Los porcentajes de disponibilidad son presupuestos anuales, no garantías por caída. 8,760 horas al año:

Léelo como un presupuesto: una carga de trabajo prometida al 99.9% ya ha gastado un tercio de su asignación anual tras 2 horas 55 minutos de inactividad. Por eso un requisito de negocio de «cuatro nueves o mejor» cambia tu arquitectura: te empuja de una sola AZ a multi-AZ, y eventualmente de una Región a dos.

Grafica la misma tabla y la forma del presupuesto es inconfundible: cada nueve adicional es aproximadamente un recorte de diez veces en la inactividad que se te permite:

• 📚 ¿Sabías que…? AWS opera «casi 20 millones de kilómetros» de fibra de red en octubre de 2026, y el precio por Región no es uniforme: el pilar de costes del Well-Architected te dice explícitamente «identifica las diferencias de coste regional» en lugar de asumir una lista de precios global. Los recursos de Local Zone también se precian por encima de su Región madre (en octubre de 2026): la proximidad cuesta dinero. Cualquier opción que afirme «precios idénticos en cada Región» es errónea de entrada.

3.3 Ejemplo E4: por qué «39 Regiones» no es lo que ve tu cuenta

Circulan tres totales de Regiones distintos en la documentación de AWS, y solo uno de ellos es lo que muestra tu consola (todos en octubre de 2026):

Comprueba la aritmética: $39 - 2 - 2 - 1 = 34$, y $34 - 17 = 17$. El examen usa esto para evaluar si confundes lanzadas, visibles y habilitadas:

Si una pregunta dice «las 39 Regiones están disponibles para todos los clientes por defecto», es errónea en dos cuentas a la vez: tipo de cuenta y estado de activación.

---

4. La regla de diseño de Zonas de Disponibilidad

4.1 Dos números distintos, ambos correctos

Esta es la distinción examinada de forma más fiable del Dominio 3, y los candidatos la pierden al confundir dos reglas que responden preguntas distintas:

Así: AWS te da ≥3; tú debes usar ≥2. Una pregunta que describe tu arquitectura con solo las subredes de una AZ está describiendo un punto único de fallo; sin importar cuántas AZs tenga la Región. AWS también indica que puedes «ejecutar en múltiples AZs para lograr una tolerancia a fallos aún mayor», es decir, que tres están disponibles si tu presupuesto y tu tolerancia a la complejidad lo permiten.

4.2 IDs de AZ frente a códigos de AZ

Una trampa sutil que ha aparecido en exámenes reales:

• Códigos de AZ (us-east-1a, us-east-1b) son relativos a la cuenta: en Regiones antiguas, la letra que ve una cuenta dada está mapeada a un centro de datos físico distinto para distintas cuentas (cuentas creadas antes de noviembre de 2025).
• IDs de AZ (euw1-az1, use1-az1) identifican la misma ubicación física en toda cuenta de AWS: el identificador seguro para reglas entre cuentas, landing zones y emparejamientos de red.

En octubre de 2026 las tablas de IDs de AZ listan 109 IDs de AZ en las 34 Regiones estándar. Regla práctica para el examen: si una pregunta involucra dos cuentas, la respuesta involucra IDs de AZ, no letras.

4.3 Ejemplo E5: ¿tu diseño usa las AZs que te dieron?

Una Región con 3 AZs (en octubre de 2026, la configuración más común) ejecuta una aplicación con un ALB cuyas subredes están todas en una AZ, una instancia EC2 y una base de datos sin reserva:

Corrección por orden de prioridad: (1) añadir subredes e instancias en una segunda AZ (mínimo del ALB, elimina el punto único de fallo de la AZ); (2) habilitar un despliegue de base de datos multi-AZ (reserva síncrona en la segunda AZ); (3) solo entonces considerar una segunda Región con una estrategia de DR para el fallo regional. El paso 1 cuesta menos y elimina el fallo que el examen pregunta con más frecuencia.

---

5. Servicios de borde: CloudFront, Route 53 y Global Accelerator

Los tres están delante de tus Regiones, y los tres aparecen en la Tarea 3.2 como beneficios de las ubicaciones de borde. El examen los distingue por su plano de entrada: respuestas DNS, contenido en caché, o una dirección IP anycast estática.

5.1 Amazon CloudFront: el plano caché/CDN

• «Reduce la latencia entregando datos a través de más de 750 Points of Presence (PoPs) dispersos globalmente»: más de 750 PoPs en más de 100 ciudades de más de 50 países, más más de 1,140 PoPs incrustados en más de 300 ciudades dentro de ISPs, y 15 cachés de borde regional que están dentro de una Región (todo en octubre de 2026).
• Mecánica: DNS resuelve al usuario hacia el PoP más cercano → en un acceso a caché el PoP responde → en un fallo de caché busca en tu origen (Amazon S3, un ALB, un origen de medios) y almacena el resultado.
• SLA: al menos 99.9% de actividad mensual (en octubre de 2026).
• Uso en el examen: almacenar en caché y entregar contenido cerca de los usuarios, más el failover de origen como palanca documentada de desvío de tráfico para DR.

5.2 Amazon Route 53: el plano DNS

• «Route 53 usa una red global de servidores DNS en una serie de ubicaciones en todo el mundo para ofrecerte alta disponibilidad y mejor rendimiento.»
• Políticas de enrutamiento que nombra el examen: latencia, geoproximidad, basada en IP, failover y ponderada: más los health checks, que es como se consigue el failover DNS automatizado.
• SLA: no disponible «solo si los cuatro servidores de nombres virtuales asignados a la Hosted Zone dejan de responder a todas las consultas DNS»; los créditos de servicio empiezan por debajo del 100% de actividad (en octubre de 2026).
• La trampa que debes memorizar: las respuestas DNS se cachéan por los resolvers según el TTL, así que un failover puede tardar tanto como el TTL que configuraste.

5.3 AWS Global Accelerator: el plano de IP anycast

• «Mejora el rendimiento de red de tus aplicaciones hasta en un 60%» y ofrece «failover rápido para arquitecturas multi-Región y multi-AZ» con «enrutamiento determinista al eliminar las dependencias de la caché DNS» (afirmaciones en octubre de 2026).
• Da a tu aplicación direcciones IP estáticas anunciadas anycast desde la red de borde de AWS: los clientes se conectan a una IP fija, y el tráfico se dirige en el borde hacia endpoints sanos.
• 130 puntos de presencia en 95 ciudades de 53 países (en octubre de 2026).
• El uso en el examen: cargas de trabajo no HTTP o sensibles a listas blancas de IP y failover que no puede esperar al TTL de DNS.

5.4 La comparación de los tres planos

• 📚 ¿Sabías que…? Los tres servicios pueden apilarse en lugar de elegirse de forma aislada: Route 53 resuelve un nombre amigable, CloudFront sirve el front-end en caché desde el más cercano de los 750+ PoPs (en octubre de 2026), y Global Accelerator transporta el tráfico de la API en IP anycast estáticas hacia dos Regiones con failover por health check. El whitepaper de recuperación ante desastres de AWS lista exactamente estos tres, Route 53, Global Accelerator y el failover de origen de CloudFront, como el conjunto de gestión de tráfico para desviar usuarios durante la recuperación.

5.5 Ejemplo E6: la ventana del TTL de DNS forma parte de tu tiempo de failover

Supón que un registro de failover de Route 53 tiene un TTL de 300 segundos, y el endpoint primario falla en t = 0. Un resolver recursivo que pidió la respuesta 240 segundos antes del fallo aún conserva una respuesta en caché válida:

Nada de esto condena el failover DNS, los health checks y el enrutamiento por failover de Route 53 son una palanca documentada de gestión de tráfico de DR, y para la política DNS global (latencia, geoproximidad, ponderada) es la respuesta correcta. El punto examinable es aritmética sobre tus propios objetivos: si el RTO declarado es de 60 segundos y el TTL de tu registro de failover es de 300 segundos, la capa de DNS sola puede reventar el presupuesto, y el enunciado te está apuntando a Global Accelerator (IP anycast estáticas, «enrutamiento determinista al eliminar las dependencias de la caché DNS») o a acortar el TTL. Trata siempre el TTL como un componente invisible del tiempo de recuperación, en octubre de 2026 AWS no publica un tiempo de failover por defecto, así que el número que configures es el número que obtienes.

---

6. El continuo híbrido de borde: Local Zones, Wavelength, Outposts y Snow

No toda carga de trabajo pertenece al núcleo de una Región. AWS ofrece un continuo desde totalmente operado por AWS, en las profundidades de una Región hasta hardware en tu propio edificio: el examen evalúa si puedes situar cada opción en ese continuo.

Tres aclaraciones que a las preguntas de examen les encanta difuminar:

• Las Local Zones las despliega AWS; los Outposts los despliega el cliente. Ambos presentan las mismas APIs de AWS, así que la frase del enunciado que decide es «en una metrópoli que opera AWS» (Local Zone) frente a «en mi centro de datos» (Outposts).
• Wavelength va incrustado en el operador: no lo eliges por residencia sola; lo eliges cuando la carga de trabajo debe estar junto a una red 5G/telecom.
• Snowball es un dispositivo de transferencia, no un destino de cómputo, y AWS ha publicado una fecha firme: «El 31 de diciembre de 2026, AWS dejará de dar soporte a los dispositivos AWS Snowball en todas las Regiones comerciales de AWS» (Storage Optimized y Compute Optimized), mientras que los clientes de GovCloud y de la Región ADC con trabajos Snow activos no se ven afectados (anuncio en octubre de 2026).

• 📚 ¿Sabías que…? La página de producto de AWS Local Zones describe «más de 30 metrópolis en todo el mundo» en seis continentes (en octubre de 2026), mientras que el bloque de estadísticas de infraestructura global de AWS publica una cifra distinta de Local Zones y su página de ubicaciones lista más encabezados de ciudad que cualquiera de las dos; esta investigación no pudo reconciliar esos recuentos, así que trata cualquier total de Local Zones como no verificado y vuelve a comprobarlo antes de citarlo. La misma cautela aplica a las Wavelength Zones (el bloque de estadísticas y los códigos de zona contados discrepan). Los recuentos cambian; las relaciones no.

---

7. Vocabulario de resiliencia: tolerancia a fallos, alta disponibilidad, recuperación ante desastres

7.1 Cinco términos, cinco significados

La página «qué es la alta disponibilidad» de AWS añade el límite que el examen evalúa textualmente: «Los sistemas de alta disponibilidad no forman parte de la recuperación ante desastres... La recuperación ante desastres trata de volver a poner en marcha tus sistemas si tus sistemas HA existentes fallan.» En otras palabras: la HA la mantiene en pie; la DR la devuelve. La tolerancia a fallos es el primo más caro de la HA: no solo se recupera rápido, nunca se detiene visiblemente.

7.2 RTO y RPO: los dos números de los que vive o muere un plan de DR

Ambos los define tu organización, no AWS (en octubre de 2026):

• RTO: Objetivo de tiempo de recuperación: «el retraso máximo aceptable entre la interrupción del servicio y la restauración del servicio.» → cuánto tiempo se te permite estar caído.
• RPO: Objetivo de punto de recuperación: «la cantidad máxima aceptable de tiempo desde el último punto de recuperación de datos.» → cuántos datos se te permite perder.

La dirección es donde los candidatos pierden puntos: RTO = inactividad, RPO = pérdida de datos. Una ventana de RPO mayor es peor (más datos perdidos); un RTO mayor es peor (caída más larga). Para la medición, el RTO se comporta como el MTTR, y el RPO siempre está antes del desastre en la línea de tiempo.

7.3 Ejemplo E7: leer el RTO y el RPO en una línea de tiempo

Una base de datos falla a las 12:00. El respaldo utilizable más reciente se escribió a las 09:00, y el servicio se restauró a las 14:00.

$$RPO = 12{:}00 - 09{:}00 = \mathbf{3\ hours\ of\ acceptable\ data\ loss}, \qquad RTO = 14{:}00 - 12{:}00 = \mathbf{2\ hours\ of\ downtime}$$

Ahora voltea eso en un requisito: el negocio declara RTO ≤ 1 minuto, RPO ≤ 1 segundo para el checkout. Un RPO de 3 horas y un RTO de 2 horas incumplen ambos objetivos por órdenes de magnitud: la respuesta es una estrategia con replicación continua (warm standby o multi-sitio activo-activo), no un mejor calendario de respaldos. Y si el negocio declara en cambio RTO ≤ 24 horas, RPO en horas, la restauración de respaldos puede satisfacerlo al menor coste de las cuatro estrategias.

7.4 Disponibilidad, tolerancia a fallos y DR son tres preguntas distintas

7.5 Convertir el enunciado de una pregunta en el término correcto

La manera más rápida de puntuar en vocabulario es leer la forma temporal del enunciado y no sus sustantivos:

Dos frases cierran el círculo del vocabulario: «La HA mantiene en marcha una carga que ya corre; la tolerancia a fallos sigue sirviendo a través de un fallo; la DR restaura una carga que cayó.» Y la frase-límite de la propia AWS, «Los sistemas de alta disponibilidad no forman parte de la recuperación ante desastres», significa que una pregunta que ofrece «nuestro diseño multi-AZ satisface nuestros requisitos de DR» está ofreciendo una trampa: el multi-AZ cubre que falle una AZ, no la Región entera.

---

8. Estrategias de recuperación ante desastres: coste frente a velocidad de recuperación

8.1 Las cuatro estrategias y sus bandas publicadas

El pilar de Confiabilidad del Well-Architected (REL13-BP02) publica las bandas de objetivo, y el whitepaper de DR publica la forma de coste/complejidad (todo en octubre de 2026):

La frase que decide la mayoría de las preguntas pilot light frente a warm standby: «el pilot light no puede procesar peticiones sin que primero se tome una acción adicional, mientras que el warm standby puede manejar tráfico (a niveles de capacidad reducidos) de inmediato.» (Un warm standby ejecutado a capacidad completa se llama a menudo hot standby.)

8.2 Ejemplo E8: ¿qué estrategia encaja con el objetivo?

El negocio publica estos objetivos (todos en octubre de 2026):

Coste y recuperación se mueven juntos: a medida que exiges RTO/RPO más pequeños, compras más capacidad inactiva. El patrón del examen es darte un número («RTO en decenas de minutos») y pedirte la estrategia: decenas de minutos es la firma del pilot light; RPO en segundos con RTO en minutos es warm standby; casi cero / potencialmente cero es activo-activo.

8.3 Desvío de tráfico y pruebas: la mecánica de la DR

La recuperación es inútil si los usuarios no pueden alcanzar la copia recuperada. El whitepaper de DR de AWS nombra explícitamente el conjunto de gestión de tráfico:

Y la disciplina que hace real cualquiera de las dos: «evalúa y prueba periódicamente tu estrategia de recuperación ante desastres.» La AWS Resilience Hub existe para validar tus objetivos de RTO y RPO declarados frente a tu arquitectura real (en octubre de 2026). Un plan de DR sin probar es una hipótesis, no una estrategia.

• 📚 ¿Sabías que…? El pilar de confiabilidad de AWS publica una tabla de aritmética de disponibilidad que puedes reutilizar textualmente: 99% → 3 días 15 horas, 99.9% → 8 horas 45 minutos, 99.95% → 4 horas 22 minutos, 99.99% → 52 minutos, 99.999% → 5 minutos de inactividad al año (en octubre de 2026). Combínala con las bandas de DR y podrás convertir cualquier SLA de negocio en una estrategia: cuatro nueves de disponibilidad no pueden lograrse con una restauración diaria, y cinco nueves prácticamente mandan warm standby o activo-activo más recuperación automática.

8.4 Activo/pasivo, en caliente/en tibio, y las tres preguntas que debes hacerte primero

El vocabulario de DR tiene dos ejes extra que las preguntas de examen cuelgan sin avisar:

Antes de elegir cualquier estrategia, el whitepaper de DR de AWS te obliga a resolver tres decisiones:

1. ¿Cuáles son los RTO y RPO numéricos? Ambos están «definidos por la organización»; sin números, toda estrategia «cualifica» y ninguna está justificada.
2. ¿Cuál es la topología de escritura? El activo-activo solo tiene sentido cuando las escrituras pueden manejarse entre Regiones (escrituras globales, locales o particionadas): una carga de escritura mayoritaria y una globalmente particionada tienen costes completamente distintos.
3. ¿Cuánto costará la capacidad inactiva, y se ha probado la estrategia? El whitepaper de AWS instruye a los equipos para que «evalúen y prueben periódicamente su estrategia de recuperación ante desastres», y la AWS Resilience Hub valida los objetivos de RTO y RPO declarados frente a la arquitectura (en octubre de 2026).

Una heurística de examen útil: si el enunciado te da números y un presupuesto, baja por la escalera desde el activo-activo hasta que los objetivos aún se cumplan al menor coste; si el enunciado te da números y dice que el coste no importa, la respuesta es la estrategia más rápida que los cumpla.

---

9. Diseño para el fallo: los principios de operación

9.1 Los principios de diseño de fiabilidad del Well-Architected

Las decisiones de infraestructura solo rinden cuando se emparejan con hábitos de operación. Los principios de diseño de fiabilidad del Well-Architected (en octubre de 2026) son lo bastante cortos como para memorizarlos:

El blog de arquitectura de AWS destila la mentalidad en la frase de Vogels, «Todo falla, todo el tiempo», y añade que «deberíamos diseñar con el fallo en mente... El AWS Well-Architected Framework está diseñado para ayudarte a preparar tu carga de trabajo para el fallo.» La lente de movilidad conectada enuncia el corolario como un requisito duro: «La arquitectura debe garantizar que no exista ningún punto único de fallo.»

9.2 Los antipatrones que el examen marca como erróneos

---

Casos Reales

AWS publica cómo se ven estos patrones en producción. Cada cifra de abajo es afirmada por el cliente o por AWS y sin auditar, citada para que puedas verificar la fuente: el punto examinable es el patrón (qué dominio de fallo se protegía, qué servicio hizo el desvío, qué objetivo se movió), no el número de marketing.

Caso A, Capital One: failover regional automatizado (resiliencia multi-Región)

Lección de examen: la página de resiliencia de Capital One es una historia multi-Región, mientras que su página de migración es una historia de coste/agilidad: no mezcles sus cifras (el tiempo de prueba de DR −70% y el entorno de desarrollo 3 meses → minutos de la página de migración pertenecen a otra página de caso). Lo que hace de esto un caso de resiliencia es la combinación de failover automatizado + desvío de tráfico con Route 53 + pruebas continuas.

Caso B, Amazon Prime Video: seis Regiones para una emisión en vivo (resiliencia a escala global)

Lección de examen: esto es lo que significa el «uso de múltiples Regiones» (Tarea 3.2 de la guía del examen) cuando la razón es alcance global y baja latencia, no soberanía. Observa que seis Regiones se usaron para entrega y procesamiento, mientras que CloudFront aún transportó la última milla: la capa de borde y la capa de Región resuelven partes distintas del mismo problema.

Caso C, Bangkok Flight Services: recuperación ante desastres multi-AZ para un manejador de carga

Lección de examen: esta es la regla de diseño de aplicación ≥2-AZ comprada como resultado de negocio. Sin sitio de DR on-premises, el primer movimiento de resiliencia de AWS fue multi-AZ dentro de una Región: alta disponibilidad y aislamiento de fallos, no recuperación ante desastres multi-Región. Si el enunciado pregunta qué protege frente a que falle una AZ, Bangkok es la forma de la respuesta; si pregunta por que falle la Región entera, este diseño por sí solo no basta.

Caso D, NASA JPL / Perseverance: escala tolerante a fallos para una misión que no puedes reintentar

Lección de examen: Perseverance es la pareja del Well-Architected «escalar horizontalmente para aumentar la disponibilidad agregada de la carga» y «dejar de adivinar la capacidad» en producción: un pico de telemetría se absorbe con más unidades pequeñas en lugar de una más grande, y Spot es asequible porque el trabajo es tolerante a fallos e interrumpible: que es exactamente como AWS enmarca para qué cargas de trabajo es Spot. Observa la fecha del blog: una historia de misión de 2021 con fecha de consulta de octubre de 2026, nunca presentada como cifra fresca.

Qué comparten los cuatro casos

• 📚 ¿Sabías que…? Los cuatro casos se apilan en una sola escalera de dominios de fallo: Bangkok Flight Services protege la AZ (multi-AZ dentro de una Región), Capital One protege la Región (failover regional automatizado, horas → minutos), Prime Video protege la entrega global (seis Regiones más el borde de CloudFront), y NASA JPL protege la propia capacidad (Auto Scaling sobre Spot y On-Demand, 4.4 TB de telemetría al día). Peldaños distintos, la misma regla: iguala el peldaño con el fallo que describe el enunciado, y nunca pagues por un peldaño más alto del que se te preguntó.

---

Preguntas de Práctica (Practice Questions)