Replicación nativa
Utilice la ruta de replicación del servicio para los estados admitidos. Ejemplos: nuevas imágenes de ECR, replicación de objetos S3 o una réplica de base de datos aprobada.
Ver el patrón →Estrategias de recuperación
La vía de recuperación adecuada.
Para cada componente de AWS.
Descubra cómo se integran las imágenes, los certificados, los controles de red, los secretos, los datos y la infraestructura. Estos diagramas muestran el diseño de recuperación de Dockfield; cada implementación para clientes se delimita y prueba por separado.
Elegir por servicio y objetivo de recuperación
Siete familias, un blueprint de recuperación.
Una carga de trabajo puede combinar varias familias. Un servicio de contenedores necesita tener listos a la vez su imagen, red, identidad, secretos y datos. La recuperación de configuración y la de datos de la aplicación requieren evidencias y tiempos distintos.
Espejo basado en eventos
Capture los eventos de cambio, inspeccione la configuración actual y reconcilie los equivalentes asignados en DR. SG y NACL requieren un reconciliador personalizado.
Ver el patrón →Reconstrucción declarativa
Reconstruye la infraestructura compatible desde el blueprint de recuperación, siguiendo el orden de dependencias. Ejemplos: VPC, balanceadores de carga, ECS y EKS.
Ver el patrón →Copia de seguridad y restauración a un punto en el tiempo
Recupera el estado desde un punto de restauración aprobado mediante las rutas de copia de seguridad nativas del servicio. Ejemplos: RDS, Aurora y recursos compatibles de AWS Backup.
Ver el patrón →Volver a emitir o recrear
Crea un recurso de destino válido y asigna su nueva identidad. Ejemplo: certificados ACM para la cuenta y región de destino.
Ver el patrón →Plano de control de recuperación compartido
Coordina las decisiones de enrutamiento entre los entornos protegidos. Los controles de enrutamiento de ARC actúan sobre las comprobaciones de estado de Route 53.
Ver el patrón →Gestión de la organización
Administra de forma centralizada los controles aplicables, con administración delegada y ajustes regionales específicos de cada servicio.
Ver el patrón →Imágenes · carga inicial + replicación nativa continua
ECR: protege la imagen y luego reconstruye el servicio.
Las imágenes existentes y los futuros envíos siguen rutas distintas. La imagen de destino debe estar disponible antes de que ECS o EKS inicie la carga de trabajo recuperada.
Prepara el destino
Configura las reglas de replicación nativa y los permisos del registro de destino. El contenido existente necesita su propia ruta de copia; comprueba el resumen de destino y la versión aprobada.
Revisa los controles del repositorio
El cifrado, la inmutabilidad de etiquetas, los permisos y las reglas del ciclo de vida requieren configuración en el destino o plantillas de creación adecuadas. La replicación nativa de imágenes no propaga las eliminaciones del origen.
Referencias de AWS: Replicación de ECR
Certificados · reemisión / reimportación
ACM: nuevo certificado de destino, ARN asignado.
Registra los requisitos del certificado: nombres, tipo, método de validación y asociación con la carga de trabajo. Solicita o importa un certificado en la cuenta y región de destino; después, asigna su ARN al listener recuperado.
La región determina la identidad
Un ARN de ACM de origen no es un certificado de destino. Prepara la emisión y la validación DNS antes de un ejercicio de recuperación; comprueba la asociación del listener de destino.
El material privado permanece protegido
El descubrimiento no requiere claves privadas. Cualquier importación usa una ruta de clave segura aprobada. Los certificados de CloudFront usan us-east-1 aunque la aplicación esté en otro lugar.
Referencias de AWS: Regiones y uso de ACM · Importar certificados
Controles de red · reconciliar + retener cambios de riesgo
Grupos de seguridad y NACL: refleja la intención de forma segura.
Estos servicios no ofrecen replicación nativa de SG/NACL entre cuentas. Un reconciliador de Dockfield usa los eventos de cambio como señales, lee la configuración actual, asigna referencias y aplica reglas de destino aprobadas. La reconciliación periódica cubre eventos omitidos o retrasados.
| Control | Grupo de seguridad | ACL de red |
|---|---|---|
| Ubicación | Recurso / interfaz de red | Asociación de subred |
| Comportamiento del tráfico | Stateful; se registran las respuestas permitidas | Stateless; permite la ruta de retorno necesaria |
| Modelo de reglas | Reglas de permiso; asigna los ID de SG referenciados | Reglas ordenadas de permiso / denegación; conserva los números |
| Asignación del destino | VPC de destino, referencias de SG y CIDR aprobados | Asociaciones de subredes de destino, CIDR y reglas entrantes / salientes |
Los eventos son señales, no el estado completo
Usa los eventos de escritura compatibles de CloudTrail y un registro habilitado. Vuelve a leer la configuración autorizada, gestiona los reintentos de forma idempotente y registra pruebas de reconciliación.
Revocar un permiso también puede ser arriesgado
La revisión de políticas cubre los cambios de acceso y asociaciones, además de la eliminación completa del recurso. Retener un cambio requiere la atención de un revisor; mantener el acceso es una decisión temporal consciente.
Referencias de AWS: EventBridge mediante CloudTrail · Comportamiento de ACL de red
Estado confidencial · separado del descubrimiento
Secrets Manager: mantén los valores fuera del blueprint.
El descubrimiento inventaría los metadatos y las dependencias de los secretos sin llamar a GetSecretValue. La protección operativa de secretos sigue una ruta autorizada independiente para gestionar valores cifrados, permisos de KMS, rotación y puntos de conexión de destino.
Misma cuenta, varias regiones
Las réplicas regionales nativas propagan las actualizaciones y la rotación de secretos. Usa una clave de KMS adecuada para la región de destino y verifica que los ajustes de conexión apunten al servicio recuperado previsto.
Una cuenta independiente requiere un diseño aparte
La replicación regional nativa no es replicación entre cuentas. Elige una ruta de sincronización controlada o acceso compartido autorizado; el acceso compartido por sí solo no crea una copia aislada. El acceso entre cuentas requiere permisos de recursos, identidad y KMS administrado por el cliente.
Referencias de AWS: Réplicas regionales · Acceso entre cuentas
Recuperación de datos con estado · réplica / copia de seguridad / PITR
Recupera los datos hasta un punto fiable.
Elige la ruta de datos por separado del blueprint de infraestructura. RDS y Aurora usan patrones de restauración o replicación adecuados al servicio; DynamoDB, EBS, EFS y FSx requieren sus propias rutas de protección compatibles. Se prueban expresamente la selección del punto de recuperación, el acceso al destino y la retención.
Se miden RTO y RPO
El intervalo de captura de infraestructura no es el RPO de los datos de la aplicación. La duración de restauración, el retraso de replicación, los puntos de restauración retenidos y la carga de trabajo probada definen la evidencia real de recuperación.
Otros servicios con estado
Los objetos S3 existentes pueden requerir Batch Replication por separado de la replicación de objetos nuevos. EFS, FSx y las instantáneas de volúmenes usan los mecanismos compatibles con el servicio, la cuenta y la región elegidos.
Referencias de AWS: Restauración de RDS a un punto en el tiempo · Alcance de la replicación de S3
Recuperación declarativa · orden de dependencias
Reconstruye el servicio conectado.
El blueprint describe la configuración compatible y las asignaciones de destino. La protección de estado nativa aporta imágenes y datos; la automatización de infraestructura reconstruye el servicio asociado siguiendo el orden de dependencias.
Resolver identidades de destino
Los ID de cuenta de origen, regiones, ARN de certificados, claves de KMS, ubicaciones de imágenes y referencias de puntos de conexión requieren asignaciones de destino.
El estado deseado de la plataforma importa
En Kubernetes, recupera las especificaciones de las cargas y los datos persistentes, no los ID efímeros de pods. El servicio necesita comprobaciones reales de la aplicación, además de un plano de control saludable.
Patrón de diseño de Dockfield: la cobertura de servicios compatibles y las asignaciones de dependencias se definen durante la evaluación.
Tráfico · preparación → aprobación → acción de enrutamiento
ARC controla el tráfico cuando la recuperación está lista.
Los controles de enrutamiento influyen en las comprobaciones de estado de Route 53 y el tráfico DNS. La puerta de validación y aprobación humana de Dockfield es un control de aplicación; las reglas de seguridad configuradas de ARC la complementan. El motor de recuperación crea la carga antes de que se habilite una acción de enrutamiento.
La aptitud no es una conmutación por error en vivo
Un estado aprobado en la interfaz no demuestra que hayan cambiado los controles de enrutamiento. Registra la acción de control y confirma el comportamiento del servicio recuperado y de DNS.
Seguridad y reversión
Configura reglas de seguridad adecuadas, ensaya la transición y la reversión aprobadas y ten en cuenta la caché de DNS y el comportamiento de los clientes.
Referencias de AWS: Control de enrutamiento de ARC · Reglas de seguridad de ARC
Controles de organización · configuración central
Gobierna una vez. Verifica cada límite de recuperación.
Control Tower, AWS Config, Security Hub y GuardDuty tienen modelos distintos de configuración organizativa y regional. Usa el patrón de administración central aplicable y verifica la cobertura, agregación y permisos en cada cuenta y región de DR. La confianza de IAM y el acceso a KMS siguen siendo dependencias explícitas.
Cobertura específica del servicio
Tener un administrador central no significa que todos los destinos estén cubiertos automáticamente. Registra las regiones habilitadas necesarias, las cuentas miembro y las fuentes de evidencia.
Un blueprint es un contrato de recuperación
Para cada recurso, registra la estrategia, la asignación de destino, el responsable, la regla de aprobación, la evidencia de protección y la última prueba de recuperación satisfactoria.
¿Qué debe registrar el blueprint de recuperación?
- Servicio de origen y relaciones de dependencia
- Cuentas y regiones de destino, identidades asignadas y puntos de conexión
- Estrategia de protección, requisitos previos y última reconciliación
- Política de puntos de restauración, RTO / RPO medidos y evidencia de validación
- Gestión de cambios destructivos, responsable de aprobación y ruta de reversión
Consulta inicial gratuita
¿Qué rutas de recuperación encajan con tu entorno de AWS?
Empieza por una carga de trabajo crítica, sus dependencias y un objetivo de recuperación medible.