AWS 386: Multi-Region artifact, configuration, secret, and deployment strategy
Why this lesson matters
Multi-Region runtime does not guarantee a deployable second Region. A release needs immutable artifacts available and authorized locally, versioned configuration, usable secrets and KMS keys, independent capacity, ordered infrastructure/data/application changes, regional health gates, traffic control, rollback, and audit evidence.
Four release planes
| Plane | Examples | Regional question |
|---|---|---|
| Artifact | S3 ZIP, ECR image, AMI, package | Same bytes/digest copied, scanned, decryptable? |
| Configuration | IaC parameters, AppConfig, Parameter Store | Which values are global versus Region-specific? |
| Secret/key | Secrets Manager, KMS, certificates | Replica availability, policy, rotation/version? |
| Deployment/control | Pipeline/action/roles/alarms/DNS | Can each Region deploy and recover independently? |
Build once and promote by digest/hash. S3 replication and cross-Region pipeline artifact stores need versioning, KMS policy/grants, replication role, destination ownership, failure monitoring, and integrity comparison. ECR replication creates regional copies; prove digest, scan/policy, pull permission, and lifecycle. AMIs have regional IDs and encrypted snapshot/key dependencies. Never map “latest” to production evidence.
Configuration, secrets, and keys
Classify configuration as identical global intent, Region-specific infrastructure identity, environment secret reference, or runtime dynamic feature value. Version schemas and validate complete regional parameter sets before rollout. Avoid copying endpoints, subnet IDs, ARNs, quotas, or failover roles from Region A into Region B.
Secrets Manager replication creates regional replicas with their own regional access path; understand primary/replica promotion, rotation behavior, version stages, and KMS keys. Parameter Store is Regional and requires an explicit replication/governance mechanism when used cross-Region. Certificates and service-linked resources may need separate regional issuance. Never export plaintext secrets through pipeline artifacts or logs.
Multi-Region KMS keys can share key material/identity relationships but each regional key has its own policy, grants, enablement, aliases, monitoring, and availability. A replica artifact encrypted with an unusable destination key is not ready. Include key disable/deletion and recovery tests.
Pipeline topology and release order
Choose centralized orchestration with regional action/artifact stores, independent regional pipelines triggered by a signed release manifest, or a hybrid. Central orchestration simplifies sequence/evidence but is a control-plane dependency; independent pipelines improve regional autonomy but require deterministic coordination and duplicate governance.
Recommended order depends on data compatibility: backward-compatible infrastructure/schema, regional configuration/secrets, artifact verification, secondary/standby deployment and tests, primary canary, bake, wider traffic, then contract cleanup after rollback windows. Active-active systems need compatibility while versions differ across Regions. Never roll back code into data it cannot read.
Health gates are regional and global: exact release ID, synthetic transaction, error/latency/saturation, replication lag, queue age, dependency health, capacity/quota, secret retrieval, artifact/key access, and business SLI. DNS/Global Accelerator traffic shift and application deployment are separate operations with TTL/session/cache/state consequences.
Maintain a regional readiness ledger before each release: artifact digest and replication time, template/configuration version, secret version stage, key state/policy test, certificate expiry, quotas and capacity reservation, data lag, current release, alarm baseline, and break-glass role test. Evidence expires, so define maximum age. A disaster declaration must not discover that the standby Region has never pulled the current artifact or decrypted its secret.
Read-only inspection and architecture exercise
aws codepipeline get-pipeline --name PIPELINE --region ap-south-1
aws s3api head-object --bucket ARTIFACT_BUCKET --key KEY --version-id VERSION --region ap-south-1
aws ecr describe-images --repository-name REPO --image-ids imageDigest=DIGEST --region ap-south-1
aws secretsmanager describe-secret --secret-id SECRET --region ap-south-1
aws kms describe-key --key-id KEY_ARN --region ap-south-1
aws cloudwatch describe-alarms --alarm-names RELEASE_ALARM --region ap-south-1Design Mumbai and Singapore active-passive delivery for a stateful API with RPO 5 minutes and RTO 30 minutes. Produce release manifest, artifact replication/integrity/KMS flow, configuration matrix, secret/certificate rotation, infrastructure/data/code order, regional canaries, traffic/failback, evidence ledger, and independent break-glass deployment.
Test 20 failures: S3 replication lag, replica KMS deny, ECR image missing, AMI copy partial, mutable tag, wrong subnet parameter, secret replica stale, rotation during deploy, key disabled, certificate absent, regional quota, action role trust, secondary test passes wrong endpoint, primary canary fails, alarm missing data, data lag exceeds RPO, DNS TTL/session, one Region on new schema, rollback artifact expired, and central pipeline Region unavailable.
Cost and acceptance
Price duplicate compute/data, cross-Region replication/transfer, S3/ECR/AMI/snapshots, KMS/secrets/configuration, pipelines/builds, logs/metrics, synthetic tests, DNS/accelerator, NAT, idle capacity, and exercises. This lesson creates nothing.
Submit the four-plane design, immutable manifest, config/secret/key matrices, pipeline choice, ordered release and failover/failback, health gates, 20 failures, RTO/RPO timing, cost, and decommission. Pass requires regional artifact integrity, no plaintext secret, destination key proof, data-compatible mixed versions, independent recovery, and measured traffic outcome.