Amazon SAA-C03: Alta disponibilidad, tolerancia a fallos y recuperación ante desastres — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Despliegues Multi-AZ y replicación

Las arquitecturas Multi-AZ abordan la falla de un único centro de datos o Zona de Disponibilidad, y nada más. Esta distinción es el punto que más se malinterpreta en el diseño de alta disponibilidad. Un despliegue Multi-AZ tolera la pérdida de una AZ dentro de una región; no tolera una interrupción de toda una región, un deterioro del servicio regional o la eliminación accidental de un recurso que replica inmediatamente dicha eliminación en la instancia en espera (standby). La replicación propaga fielmente los datos erróneos —corrupción lógica, errores de esquema, escrituras de ransomware—, razón por la cual la replicación y las copias de seguridad son complementarias, no sustitutas.

Para Amazon RDS, Multi-AZ aprovisiona una réplica en espera (standby) síncrona en una AZ diferente. Las escrituras se confirman en ambas instancias antes de la confirmación de recepción (acknowledgment), lo que proporciona un RPO (Objetivo de punto de recuperación) efectivamente de cero y un RTO (Objetivo de tiempo de recuperación) típicamente de 60 a 120 segundos durante la conmutación por error (failover) automática. En el despliegue clásico de instancia Multi-AZ, la instancia standby no es legible; existe únicamente para durabilidad y conmutación por error. Los despliegues de clúster Multi-AZ (dos instancias standby de lectura) reducen aún más el tiempo de conmutación por error y proporcionan cierto escalado de lectura, pero siguen limitándose a una sola región.

Para el escalado de lectura, agregue réplicas de lectura. Las réplicas de lectura utilizan replicación asíncrona y existen para descargar las consultas de informes, análisis y paneles de control. Tratar una réplica de lectura como un mecanismo de conmutación por error para alta disponibilidad (HA) es incorrecto por tres motivos: la replicación es asíncrona (pérdida de datos en la promoción), la promoción es manual o mediante scripts (no automática) y el endpoint principal no se conserva. Cuando una carga de trabajo creciente necesita más capacidad de lectura sin nueva complejidad, agregue una réplica de lectura; cuando el requisito es la conmutación por error automática con cero pérdida de datos, use Multi-AZ. Cuando el RPO/RTO debe sobrevivir a una falla de región para un motor relacional, Aurora Global Database proporciona una latencia de replicación interregional por debajo del segundo y un RTO de conmutación por error administrada por debajo del minuto.

Amazon ElastiCache sigue el mismo patrón con los grupos de replicación. Un grupo de replicación de Redis con Multi-AZ habilitado mantiene una instancia principal y una o más réplicas en distintas AZ; si la principal falla, ElastiCache promueve una réplica y actualiza el endpoint principal. Para el escalado horizontal, Redis (con el modo de clúster habilitado) particiona los datos en fragmentos (shards), donde cada fragmento es su propio grupo de replicación. Memcached, por el contrario, no replica: la pérdida de un nodo significa la pérdida de datos para esa partición.

Amazon FSx ofrece tipos de despliegue Multi-AZ para FSx for Windows File Server y FSx for ONTAP, utilizando replicación síncrona entre un servidor de archivos preferido y uno en espera. FSx for Lustre es generalmente de una sola AZ (efímero o persistente); la durabilidad para Lustre proviene de las asociaciones de repositorios de datos de S3, no de la replicación entre AZ.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Copias de seguridad automatizadas de RDS y recuperación a un momento dado

Las copias de seguridad automatizadas de RDS combinan una instantánea (snapshot) diaria con cargas continuas de registros de transacciones a S3 cada 5 minutos, lo que permite la recuperación a un momento dado (PITR) a cualquier segundo dentro de la ventana de retención de 1 a 35 días. Si su RPO es de 2 horas, las copias de seguridad nativas de RDS ya lo cubren; no se requiere una programación de instantáneas adicional, y superponer AWS Backup es redundante a menos que necesite copias interregionales, aislamiento entre cuentas o la semántica de Vault Lock más allá de lo que ofrece la copia de instantáneas de RDS. La copia de seguridad automatizada predeterminada es a menudo la respuesta correcta más económica para requisitos de RPO modestos.

AWS Backup como el plano de control centralizado

AWS Backup es el plano de control basado en políticas para la gestión de copias de seguridad en EBS, EC2 (como AMIs), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, S3 y más. En lugar de crear scripts con lógica de instantáneas específica para cada servicio, usted define planes de respaldo que agrupan reglas que describen la frecuencia, la ventana de respaldo, las ventanas de inicio/finalización, las transiciones del ciclo de vida al almacenamiento en frío, la retención y las bóvedas de destino. Los recursos se inscriben a través de asignaciones de recursos por etiqueta (tag) o ARN, por lo que una convención de etiquetado como Backup=Daily se convierte en el contrato operativo que rige la cobertura. Para flotas de cientos de instancias EC2, la selección basada en etiquetas es el enfoque de menor esfuerzo: aplique la etiqueta y deje que AWS Backup enumere, en lugar de crear programaciones por instancia.

Una bóveda de copias de seguridad es el contenedor cifrado con KMS donde residen los puntos de recuperación. El acceso se controla mediante políticas de recursos en la bóveda.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Copias interregionales y entre cuentas

El bloque CopyActions es el mecanismo para las copias de recuperación de desastres (DR) interregionales. AWS Backup gestiona la copia de la instantánea, la vuelve a cifrar con una clave KMS de la región de destino (la bóveda de destino debe hacer referencia a una clave en esa región) y aplica un ciclo de vida independiente. Las instantáneas de EBS y RDS se guardan por defecto en la región de origen; si toda la región se ve afectada, también lo estarán las instantáneas. Cualquier requisito normativo o empresarial que mencione la resiliencia regional debe incluir un paso explícito de copia interregional, ya sea a través de las acciones de copia de AWS Backup, la copia interregional de instantáneas automatizadas de RDS o las políticas de DLM con destinos interregionales.

Para las copias entre cuentas, AWS Organizations delega una cuenta de administrador para AWS Backup; la política de la bóveda de origen permite el acceso a la cuenta de destino, y la bóveda de destino permite las copias desde el origen. Esta es la forma rentable de centralizar la recuperación de desastres (DR): una cuenta de administración contiene los puntos de recuperación de muchas cuentas de cargas de trabajo y puede restaurar en cualquiera de las regiones. Para EC2, una copia de AMI a una segunda región más el uso compartido de instantáneas le permite lanzar instancias allí sin infraestructura activa (warm). Las instantáneas cifradas requieren compartir la CMK: la cuenta o región de destino necesita kms:CreateGrant y acceso a la clave. Omitir esto es la razón por la que las restauraciones entre cuentas fallan silenciosamente.

Un RPO de 24 horas se satisface de forma económica con una instantánea diaria automatizada copiada a otra región, lo que es mucho menos costoso que una réplica de lectura interregional o un clúster en espera tibio (warm standby). Pase a la replicación continua solo cuando el RPO descienda por debajo de lo que la cadencia de las instantáneas puede ofrecer.

Ciclo de vida de las AMI y copias de seguridad de EC2

Dos mecanismos automatizan las copias de seguridad de EC2: Data Lifecycle Manager (DLM) y AWS Backup. DLM es anterior a AWS Backup y crea instantáneas (snapshots) de EBS o AMI basadas en políticas y programadas, con acciones de copia entre regiones y entre cuentas. AWS Backup subsume esta funcionalidad y añade políticas centrales, Vault Lock y un alcance multiservicio. Prefiera AWS Backup si ya lo utiliza para otros servicios; use DLM para escenarios puramente de EBS/AMI donde no necesite las características de un almacén (vault).

Para las capas web sin estado (stateless) detrás de un grupo de Auto Scaling sin datos locales persistentes, hacer copias de seguridad de las instancias EC2 en ejecución es un desperdicio. La postura correcta es “hornear” (bake) una AMI reforzada (hardened) (a través de EC2 Image Builder o un pipeline de CI), referenciarla en la plantilla de lanzamiento (launch template) y dejar que el ASG se encargue del reemplazo de instancias. El esfuerzo de copia de seguridad se concentra en las capas con estado (stateful) cuyas copias de seguridad nativas y automatizadas cumplen con el RPO.

Inmutabilidad: Vault Lock y Object Lock

Una instantánea (snapshot) simple en su cuenta puede ser eliminada por cualquiera con el permiso de IAM adecuado; las instantáneas por sí solas no satisfacen los requisitos de inmutabilidad. Los regímenes regulatorios (SEC 17a-4, FINRA, HIPAA, GDPR) frecuentemente exigen una retención de tipo “escribir una vez, leer muchas” (WORM) que ni siquiera los administradores pueden eludir. Dos mecanismos de AWS ofrecen esto.

AWS Backup Vault Lock impone el modo WORM en un almacén de copias de seguridad (backup vault):

En el modo de cumplimiento, una vez que transcurre el período de reflexión, ningún usuario —incluida la cuenta raíz (root)— puede acortar la retención, eliminar puntos de recuperación antes de su vencimiento o quitar el propio bloqueo. Esto frustra tanto la eliminación por parte de personal interno como la de un operador de ransomware que haya comprometido completamente la cuenta.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock proporciona WORM a nivel de objeto en modo Gobernanza (los usuarios con privilegios con s3:BypassGovernanceRetention pueden anularlo) o en modo Cumplimiento (nadie, incluido el usuario raíz, puede eliminar o acortar la retención). La retención legal (Legal Hold) es independiente de los períodos de retención. Object Lock requiere el versionado y debe habilitarse en el momento de la creación del bucket para una protección completa.

Reservas de capacidad para la región de conmutación por error (failover)

Un plan de DR que asume que la región de conmutación por error (failover) tendrá capacidad de EC2 disponible el día de un evento a gran escala no es un plan. Cuando una región falla, todo el mundo conmuta por error simultáneamente, y los tipos de instancia —especialmente los grandes, los de GPU o las formas especializadas— pueden agotarse. Las Reservas de Capacidad bajo Demanda (ODCRs) en la región de destino garantizan la capacidad para un tipo de instancia, plataforma y AZ específicos, y se facturan se usen o no. Combínelas con un Savings Plan para compensar el costo. Para compromisos de GPU/ML a largo plazo, se aplican los Capacity Blocks; para flexibilidad de familias, una Capacity Reservation Fleet cubre múltiples familias de instancias. El principio es: si el negocio requiere cómputo garantizado en la región de DR, resérvelo; no confíe en la disponibilidad bajo demanda de “mejor esfuerzo” (best-effort).

Selección de la estrategia de DR

AWS canoniza cuatro niveles de DR, cada uno con una compensación distinta entre costo y recuperación:

El nivel correcto lo dictan el RPO y el RTO del negocio, no la preferencia arquitectónica. Un RPO de 24 horas tolera copias diarias de instantáneas entre regiones (Copia de seguridad y restauración). Un RPO de segundos exige replicación continua: réplicas de lectura entre regiones, Aurora Global Database, DynamoDB Global Tables o S3 Cross-Region Replication. Intentar un RPO de 5 minutos con instantáneas nocturnas es arquitectónicamente imposible, sin importar el presupuesto. Por el contrario, optar por defecto por el modelo activo-activo para cada carga de trabajo es un antipatrón de costos: exige datos globalmente consistentes (DynamoDB Global Tables o Aurora Global con reenvío de escritura), cómputo duplicado a escala completa y un direccionamiento de tráfico complejo a través de Route 53 o Global Accelerator. Elija el patrón más económico que cumpla con el RPO/RTO establecido; para un RPO de 2 horas, la copia de seguridad y restauración o la luz piloto suelen ser suficientes, y la espera activa es un exceso de ingeniería.

Protección contra eliminación y salvaguardas en capas

La resiliencia no es simplemente “¿tenemos copias de seguridad?”, sino “¿puede un solo actor, error o ataque borrarlas?”. Los controles en capas previenen la catástrofe del “clic equivocado”:

• RDS: habilite DeletionProtection y exija una instantánea final al eliminar.
• EC2: habilite DisableApiTermination y DisableApiStop en instancias críticas.
• DynamoDB: habilite la protección contra eliminación y la recuperación a un momento dado (point-in-time recovery).
• S3: Versionado + MFA Delete + Object Lock para la inmutabilidad.
• CloudFormation: DeletionPolicy: Retain en recursos con estado y protección contra la terminación del stack.
• IAM SCPs: deniegue backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance y ec2:DeleteSnapshot fuera de los roles de emergencia (break-glass).

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Combinados con Vault Lock en modo de cumplimiento, estos producen una defensa en profundidad: ni siquiera una credencial de administrador comprometida puede destruir los puntos de recuperación de última línea de defensa.

Trampas comunes

Tratar Multi-AZ como DR. RDS Multi-AZ, ElastiCache Multi-AZ y FSx Multi-AZ residen todos dentro de una única región. Una interrupción de la API regional, la eliminación accidental de una tabla o una migración de esquema mal aplicada afectan a ambos nodos. Cualquier requisito que mencione “otra región”, “fallo regional” o “RPO entre regiones” exige la replicación o copia entre regiones; Multi-AZ por sí solo no cumple el requisito.

Confundir las réplicas de lectura con la alta disponibilidad (HA). Las réplicas de lectura son asíncronas, se promueven manualmente y cambian los puntos de conexión (endpoints). Resuelven el escalado de lectura, no la conmutación por error (failover) automática.

Asumir que las instantáneas (snapshots) equivalen al cumplimiento normativo (compliance). Las instantáneas sin Vault Lock (modo de conformidad) u Object Lock pueden ser eliminadas por cualquier principal con el permiso de IAM adecuado y por la cuenta raíz. La retención regulatoria WORM requiere una configuración explícita de inmutabilidad con un período de reflexión (cooling-off) bloqueado y transcurrido.

Instantáneas solo locales para un RPO regional. Las instantáneas de EBS y RDS se guardan por defecto en la región de origen. La resiliencia regional requiere una acción explícita de copia entre regiones.

Copias de seguridad sin restauraciones probadas ni capacidad reservada. Una instantánea que nunca has restaurado es una hipótesis, no una copia de seguridad. Los simulacros de restauración revelan roles de IAM faltantes, problemas de acceso a claves de KMS en la región y cuenta de destino, y tipos de instancia no disponibles. Sin reservas de capacidad (Capacity Reservations) para cargas de trabajo críticas, es posible que la región de DR simplemente no tenga la configuración que necesitas cuando todos realizan la conmutación por error simultáneamente, y el RTO se vuelve ilimitado.

Sobrediseñar hacia una arquitectura activo-activo. Duplicar el cómputo global, la replicación de datos globalmente consistente y el enrutamiento de tráfico complejo son costosos. Si el RPO/RTO no lo justifica, una arquitectura de tipo pilot light o warm standby es la correcta.

Hacer copias de seguridad de las capas sin estado (stateless). Hacer instantáneas de servidores web efímeros detrás de un ASG desperdicia dinero y complica la recuperación. Crea (hornea) AMIs, haz referencia a ellas en las plantillas de lanzamiento (launch templates) y concentra la inversión en copias de seguridad en los datos con estado (stateful).

← Gestión · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →