Réplication native
Utilisez le mécanisme de réplication du service pour l’état pris en charge. Exemples : nouvelles images ECR, réplication d’objets S3 ou réplica de base de données approuvé.
Voir le modèle →Stratégies de reprise
La bonne voie de reprise.
Pour chaque composant AWS.
Découvrez comment les images, les certificats, les contrôles réseau, les secrets, les données et l’infrastructure s’articulent. Ces diagrammes présentent la conception de reprise Dockfield ; chaque mise en œuvre client est délimitée et testée séparément.
Choisir par service et objectif de reprise
Sept familles, un seul blueprint de reprise.
Une charge de travail peut combiner plusieurs familles. Un service conteneurisé a besoin de son image, de son réseau, de son identité, de ses secrets et de ses données au même moment. La reprise de configuration et celle des données applicatives reposent sur des preuves et des délais distincts.
Miroitage déclenché par les événements
Capturez les événements de changement, inspectez la configuration actuelle et réconciliez les équivalents mappés dans DR. Les SG et NACL nécessitent un réconciliateur personnalisé.
Voir le modèle →Reconstruction déclarative
Reconstruisez l’infrastructure prise en charge à partir du blueprint de reprise, dans l’ordre des dépendances. Exemples : VPC, équilibreurs de charge, ECS et EKS.
Voir le modèle →Sauvegarde et restauration à un instant donné
Restaurez l’état depuis un point de restauration approuvé avec les mécanismes de sauvegarde natifs du service. Exemples : RDS, Aurora et ressources AWS Backup prises en charge.
Voir le modèle →Réémettre ou recréer
Créez une ressource de destination valide et associez sa nouvelle identité. Exemple : certificats ACM pour le compte et la région cibles.
Voir le modèle →Plan de contrôle de reprise partagé
Coordonnez les décisions de routage entre les environnements protégés. Les contrôles de routage ARC agissent sur les vérifications d’état Route 53.
Voir le modèle →Gouvernance de l’organisation
Gérez de façon centralisée les contrôles applicables, avec une administration déléguée et des paramètres régionaux propres à chaque service.
Voir le modèle →Images · initialisation et réplication native continue
ECR : protégez l’image, puis reconstruisez le service.
Les images existantes et les futurs envois suivent des parcours différents. L’image de destination doit être disponible avant qu’ECS ou EKS ne démarre la charge de travail restaurée.
Préparez la destination
Configurez les règles de réplication native et les autorisations du registre de destination. Le contenu existant nécessite son propre parcours de copie ; vérifiez l’empreinte de destination et la version approuvée.
Les contrôles du dépôt nécessitent une attention particulière
Le chiffrement, l’immutabilité des balises, les autorisations et les règles de cycle de vie nécessitent une configuration cible ou des modèles de création adaptés. La réplication native des images ne propage pas les suppressions à la source.
Références AWS : Réplication ECR
Certificats · réémission / réimportation
ACM : nouveau certificat de destination, ARN associé.
Définissez les besoins du certificat : noms, type, méthode de validation et association à la charge de travail. Demandez ou importez un certificat dans le compte et la région de destination, puis associez son ARN au listener restauré.
L’identité régionale compte
Un ARN ACM source n’est pas un certificat de destination. Préparez l’émission et la validation DNS avant l’exercice de reprise ; vérifiez l’association au listener de destination.
Les éléments privés restent protégés
La découverte ne nécessite pas de clés privées. Toute importation suit un parcours sécurisé approuvé. Les certificats CloudFront utilisent us-east-1 même si l’application se trouve ailleurs.
Références AWS : Régions et usages ACM · Importer des certificats
Contrôles réseau · rapprocher + suspendre les changements à risque
Groupes de sécurité et NACL : reproduisez l’intention en toute sécurité.
Ces services ne proposent pas de réplication native des SG/NACL entre comptes. Un réconciliateur Dockfield utilise les événements de changement comme signaux, lit la configuration actuelle, associe les références et applique les règles approuvées à la cible. Une réconciliation périodique couvre les événements manqués ou retardés.
| Contrôle | Groupe de sécurité | ACL réseau |
|---|---|---|
| Placement | Ressource / interface réseau | Association de sous-réseau |
| Comportement du trafic | État avec suivi des réponses autorisées | Sans état ; autorisez le chemin de retour requis |
| Modèle de règles | Règles d’autorisation ; associez les ID SG référencés | Règles autoriser / refuser ordonnées ; conservez les numéros |
| Association à la destination | VPC cible, références SG et CIDR approuvés | Associations de sous-réseaux cibles, CIDR et règles entrantes / sortantes |
Les événements sont des signaux, pas l’état complet
Utilisez les événements d’écriture CloudTrail pris en charge et une piste activée. Relisez la configuration de référence, gérez les nouvelles tentatives de manière idempotente et suivez les preuves de réconciliation.
Une autorisation révoquée peut aussi présenter un risque
L’examen des règles couvre les modifications d’accès et d’associations, ainsi que la suppression complète de ressources. Suspendre un changement nécessite l’attention d’un réviseur ; conserver l’accès est une décision temporaire et consciente.
Références AWS : EventBridge via CloudTrail · Comportement des ACL réseau
État sensible · distinct de la découverte
Secrets Manager : ne placez pas les valeurs dans le blueprint.
La découverte inventorie les métadonnées des secrets et leurs dépendances sans appeler GetSecretValue. La protection opérationnelle des secrets suit un parcours distinct et autorisé qui gère les valeurs chiffrées, les autorisations KMS, la rotation et les points de terminaison cibles.
Même compte, plusieurs régions
Les réplicas régionaux natifs propagent les mises à jour des secrets et leur rotation. Utilisez une clé KMS adaptée à la région cible et vérifiez que les paramètres de connexion pointent vers le service restauré prévu.
Un compte distinct exige une conception dédiée
La réplication régionale native n’est pas une réplication entre comptes. Choisissez un parcours de synchronisation contrôlé ou un accès partagé autorisé ; l’accès partagé seul ne crée pas de copie isolée. L’accès inter-comptes exige des autorisations de ressources, d’identité et de clés KMS gérées par le client.
Références AWS : Réplication régionale · Accès inter-comptes
Reprise des données avec état · réplica / sauvegarde / PITR
Restaurez les données à un point fiable.
Choisissez le parcours des données indépendamment du blueprint d’infrastructure. RDS et Aurora utilisent des modèles de restauration ou de réplication adaptés au service ; DynamoDB, EBS, EFS et FSx nécessitent leurs propres mécanismes de protection pris en charge. Le choix du point de reprise, l’accès à la destination et la rétention sont explicitement testés.
RTO et RPO mesurés
L’intervalle de capture de l’infrastructure ne correspond pas au RPO des données applicatives. La durée de restauration, le retard de réplication, les points de restauration conservés et la charge de travail testée définissent les preuves réelles de reprise.
Autres services avec état
Les objets S3 existants peuvent nécessiter une réplication par lots distincte de la réplication des nouveaux objets. EFS, FSx et les instantanés de volumes utilisent les mécanismes pris en charge pour le service, le compte et la région choisis.
Références AWS : Restauration à un instant donné RDS · Périmètre de réplication S3
Reprise déclarative · ordre des dépendances
Reconstruisez le service connecté.
Le blueprint décrit la configuration prise en charge et les associations cibles. La protection d’état native fournit les images et les données ; l’automatisation de l’infrastructure reconstruit les services associés dans l’ordre des dépendances.
Résoudre les identités de destination
Les ID de compte source, régions, ARN de certificats, clés KMS, emplacements d’images et références de points de terminaison nécessitent des associations cibles.
L’état souhaité de la plateforme compte
Pour Kubernetes, récupérez les spécifications des charges et les données persistantes plutôt que les ID de pods éphémères. Le service nécessite de vrais contrôles applicatifs, au-delà de la santé du plan de contrôle.
Modèle de conception Dockfield : la couverture des services pris en charge et les associations de dépendances sont définies lors de l’évaluation.
Trafic · disponibilité → approbation → action de routage
Les contrôles ARC acheminent le trafic lorsque la reprise est prête.
Les contrôles de routage influencent les vérifications d’état Route 53 et le trafic DNS. La validation et l’approbation humaine de Dockfield forment un contrôle applicatif ; les règles de sécurité ARC configurées les complètent. Le moteur de reprise construit la charge de travail avant qu’une action de routage soit admissible.
L’admissibilité ne signifie pas un basculement réel
Un état approuvé dans l’interface ne prouve pas que les contrôles de routage ont changé. Consignez l’action de contrôle et confirmez le comportement du service restauré et du DNS.
Sécurité et retour arrière
Configurez des règles de sécurité adaptées, répétez la transition et son retour arrière approuvés, et tenez compte de la mise en cache DNS et du comportement des clients.
Références AWS : Contrôle de routage ARC · Règles de sécurité ARC
Contrôles de l’organisation · configuration centralisée
Gouvernez une fois. Vérifiez chaque limite de reprise.
Control Tower, AWS Config, Security Hub et GuardDuty ont des modèles d’organisation et de configuration régionale différents. Utilisez le modèle d’administration centralisée approprié, puis vérifiez la couverture, l’agrégation et les autorisations dans chaque compte et région DR. La relation de confiance IAM et l’accès KMS restent des dépendances explicites.
Couverture propre à chaque service
Un administrateur central ne garantit pas automatiquement la couverture de toutes les destinations. Consignez les régions activées requises, les comptes membres et les sources de preuves.
Un blueprint est un contrat de reprise
Pour chaque ressource, consignez la stratégie, l’association à la destination, le responsable, la règle d’approbation, les preuves de protection et le dernier test de reprise réussi.
Que doit contenir le blueprint de reprise ?
- Service source et relations de dépendance
- Comptes et régions cibles, identités et points de terminaison associés
- Stratégie de protection, prérequis et dernière réconciliation
- Politique de point de restauration, RTO / RPO mesurés et preuves de validation
- Gestion des changements destructifs, responsable de l’approbation et parcours de retour arrière
Consultation initiale gratuite
Quels parcours de reprise conviennent à votre environnement AWS ?
Commencez par une charge de travail critique, ses dépendances et un objectif de reprise mesurable.