Aller au contenu

AWS Mis à jour le 2026-10-05

CodePipeline multi-régions : warm-standby réellement validé à chaque release

Configurez AWS CodePipeline pour que chaque release déploie la même build vers votre région principale et votre région de reprise après sinistre (DR), puis vérifie que les deux fonctionnent. Votre région de relève reste à jour, et un basculement sert la même version que vos utilisateurs ont déjà.

Si votre application sur AWS a une région de relève pour la reprise après sinistre (DR, pour disaster recovery), CodePipeline peut déployer chaque release dans les deux régions en même temps. L’exemple utilise ca-central-1 comme région principale et us-east-1 comme relève tiède (warm standby) : la seconde région a déjà son infrastructure en marche et peut prendre le trafic. Le problème courant, c’est que la relève n’est mise à jour qu’à la main, alors elle prend du retard sur la principale. Quand la région principale tombe en panne et que le trafic bascule, la relève sert une version plus ancienne de l’application, et son schéma de base de données peut ne plus correspondre. Le basculement devient alors un second incident. La solution consiste à déployer le même artéfact de build (le paquet produit par votre build) dans les deux régions à chaque release, puis à vérifier les deux. CodePipeline le permet avec des actions inter-régions, qui copient l’artéfact dans chaque région. Les clés multirégions d’AWS Key Management Service (KMS) permettent aux deux régions de déchiffrer cet artéfact avec la même clé.

Ce qui se passe

Le pattern de pipeline inter-régions a trois pièces qui doivent s’aligner :

  • Réplication d’artéfacts. CodePipeline peut répliquer les artéfacts depuis la région d’origine du pipeline vers des régions additionnelles, mais seulement si vous déclarez ArtifactStores (pluriel) au lieu de ArtifactStore (singulier) au niveau du pipeline. Chaque région obtient son propre bucket S3 et sa propre clé KMS.
  • Action inter-régions. Une action de déploiement peut spécifier Region dans sa déclaration d’action. CodePipeline choisit l’artéfact depuis le bucket régional correspondant, exécute l’action contre l’application CodeDeploy dans cette région, et rapporte le statut à l’exécution du pipeline de la région d’origine.
  • Même artéfact, deux régions. L’artéfact est construit une seule fois dans la région d’origine et répliqué. Il n’y a pas de second build. C’est ce qui rend l’affirmation « déployé vers DR » fiable — ce sont littéralement les mêmes octets que le staging a validés.

L’ordre des opérations sur un basculement devient alors :

  1. Le contrôle de santé Route 53 sur la principale échoue → le trafic bascule vers DR.
  2. DR exécute déjà la release courante (parce que chaque release a déployé vers elle). Pas besoin de redéploiement d’urgence.
  3. La base de données de la région DR est le réplica en lecture ou le partenaire actif-actif de la principale — promouvez-la.
  4. Communiquez l’incident, surveillez la récupération, planifiez le retour à la normale.

Sans la pratique chaque-release-déploie-vers-DR, l’étape 2 devient « contacter quelqu’un pour faire un déploiement » et le RTO double. Avec elle, le basculement est mécanique.

Comment vérifier

La définition de pipeline inter-régions, abrégée aux parties qui comptent :

AppPipeline:
  Type: AWS::CodePipeline::Pipeline
  Properties:
    Name: app-pipeline
    RoleArn: !GetAtt PipelineRole.Arn
    ArtifactStores:
      - Region: ca-central-1
        ArtifactStore:
          Type: S3
          Location: !Ref ArtifactBucketCanada
          EncryptionKey:
            Id: !GetAtt ArtifactKeyCanada.Arn
            Type: KMS
      - Region: us-east-1
        ArtifactStore:
          Type: S3
          Location: !Ref ArtifactBucketUsEast
          EncryptionKey:
            Id: !GetAtt ArtifactKeyUsEast.Arn
            Type: KMS
    Stages:
      # ... Source, Build, Test stages run in home region (ca-central-1)
      - Name: DeployPrimary
        Actions:
          - Name: DeployPrimary
            Region: ca-central-1
            ActionTypeId: { Category: Deploy, Owner: AWS, Provider: CodeDeploy, Version: '1' }
            Configuration:
              ApplicationName: !Ref ProdAppCanada
              DeploymentGroupName: !Ref ProdGroupCanada
            InputArtifacts: [{ Name: BuildOutput }]

      - Name: ValidatePrimary
        Actions:
          - Name: SyntheticsPrimary
            Region: ca-central-1
            ActionTypeId: { Category: Test, Owner: AWS, Provider: CodeBuild, Version: '1' }
            Configuration: { ProjectName: !Ref PrimarySyntheticsProject }
            InputArtifacts: [{ Name: BuildOutput }]

      - Name: DeployStandby
        Actions:
          - Name: DeployStandby
            Region: us-east-1
            ActionTypeId: { Category: Deploy, Owner: AWS, Provider: CodeDeploy, Version: '1' }
            Configuration:
              ApplicationName: !Ref ProdAppUsEast
              DeploymentGroupName: !Ref ProdGroupUsEast
            InputArtifacts: [{ Name: BuildOutput }]

      - Name: ValidateStandby
        Actions:
          - Name: SyntheticsStandby
            Region: us-east-1
            ActionTypeId: { Category: Test, Owner: AWS, Provider: CodeBuild, Version: '1' }
            Configuration: { ProjectName: !Ref StandbySyntheticsProject }
            InputArtifacts: [{ Name: BuildOutput }]

Le ArtifactStores pluriel est obligatoire dès que vous avez une action inter-régions. Chaque entrée doit être une région dans laquelle le pipeline a au moins une action. Le bucket S3 dans chaque région doit être dans la même région que l’entrée — CodePipeline ne copiera pas inter-régions depuis un bucket us-east-1 vers une action ca-central-1.

Les clés KMS méritent une réflexion soigneuse. Le pattern le plus simple est une CMK régionale par région, avec le rôle de service du pipeline accordé kms:Decrypt sur les deux. Le pattern plus élégant est une clé KMS multi-régions — une seule clé logique avec des répliques dans les deux régions, de sorte que l’artéfact chiffré en ca-central-1 se déchiffre en us-east-1 sans re-chiffrement. Créez la principale multi-régions :

aws kms create-key \
  --region ca-central-1 \
  --multi-region \
  --description "CodePipeline artifact key (multi-region primary)"

Puis répliquez vers us-east-1 :

aws kms replicate-key \
  --key-id mrk-abc123 \
  --replica-region us-east-1

Les deux répliques partagent le même matériel de clé et le même préfixe d’ID de clé (mrk-), donc les métadonnées KMS de l’artéfact voyagent inchangées.

Vérifiez que l’action inter-régions utilise bien le bon bucket régional :

aws codepipeline get-pipeline-state \
  --name app-pipeline \
  --query 'stageStates[?stageName==`DeployStandby`].actionStates[0].latestExecution'

L’exécution devrait montrer summary référençant l’ID de déploiement us-east-1. Si elle référence ca-central-1, le champ Region: sur l’action est absent ou erroné.

La correction

La pratique du pipeline inter-régions a six règles qui tiennent à chaque engagement multi-régions :

Chaque release déploie vers chaque région. Toute la raison pour laquelle l’inter-régions fonctionne est que la DR n’est jamais périmée. Un pipeline qui déploie conditionnellement vers DR (« seulement les week-ends » ou « seulement les releases taguées ») garantit que la région DR dérive. La dérive est l’incident.

Validez la région standby de la même manière que la principale. L’étape ValidateStandby exécute des synthétiques contre les points d’accès us-east-1. Si les synthétiques standby échouent, le pipeline échoue — même si la principale a déjà réussi. C’est la porte qui attrape « le déploiement semblait bien mais DR est cassée ». Sans elle, vous découvrez la cassure pendant un basculement, ce qui est le pire moment possible.

Utilisez des clés KMS multi-régions, pas des clés par région. Deux clés séparées fonctionnent, mais les clés multi-régions éliminent l’étape de re-chiffrement et rendent les politiques IAM symétriques. Le coût est un appel aws kms replicate-key supplémentaire à la configuration.

Les applications CodeDeploy dans chaque région doivent être indépendantes. Une seule application CodeDeploy ne peut pas s’étendre sur plusieurs régions. Vous avez besoin de ProdAppCanada et ProdAppUsEast comme ressources séparées, avec des groupes de déploiement séparés, des groupes Auto Scaling séparés, des groupes cibles séparés. Le pipeline les colle ensemble, pas le service de déploiement.

Assomption de rôle IAM inter-régions. Le rôle de service du pipeline dans la région d’origine doit faire confiance aux rôles de déploiement dans les deux régions. Si vous utilisez le déploiement multi-compte (compte DR séparé du principal), cela devient plus élaboré — le rôle pipeline du compte d’origine assume un rôle du compte DR, qui a les permissions CodeDeploy en us-east-1. Faites ce bloc de confiance correctement à la configuration ; le déboguer après que le pipeline ait déjà exécuté une fois est significativement plus difficile.

Le basculement est un runbook séparé. Le pipeline garde DR fraîche ; il n’exécute pas le basculement. Le basculement c’est les bascules de contrôle de santé Route 53 plus la promotion de base de données plus les alertes de surveillance. Les deux pièces doivent exister — un pipeline sans runbook de basculement laisse DR prête mais inutilisée, et un runbook de basculement sans pipeline pratique le basculement contre du code périmé.

Le pipeline inter-régions est le travail d’ingénierie qui rend vraie l’affirmation « nous avons une DR ». Toute autre pièce — l’infrastructure standby, les runbooks, le test de basculement — en dépend.

Stack Harbor bâtit et opère les workflows CodePipeline en production dans le cadre de l’onboarding Gestion AWS et de la couche Pipeline de déploiement en continu. Si votre chemin de release passe encore par SSH et un message Slack, commencez par une consultation d’infrastructure.