6.3.4. Multi-Region Key and Certificate Management
First Principle: Global applications require encryption keys and certificates that work across Regions. Without multi-Region key management, cross-Region data access requires complex key-sharing arrangements or data re-encryption at Region boundaries.
This is new content for the SCS-C03.
KMS Multi-Region Keys:
- Create a primary key in one Region and replica keys in other Regions
- Same key ID and key material across all Regions — data encrypted in one Region can be decrypted in another
- Use case: cross-Region disaster recovery, global database encryption, multi-Region application encryption
- Replica keys are independent — usable even if primary Region is unavailable
AWS Private Certificate Authority (Private CA):
- Issue private X.509 certificates for internal resources
- Certificates for mTLS, code signing, IoT device identity, VPN authentication
- Supports certificate hierarchies: root CA → subordinate CA → end-entity certificates
- Sharing: Share a CA with other accounts in your organization through RAM (a private CA is a Regional resource)
- Integrates with ACM for certificate deployment to ALB, CloudFront, API Gateway
AWS Certificate Manager (ACM):
- Free public certificates (auto-renewed) for ALB, CloudFront, API Gateway
- Managed renewal: ACM renews a certificate automatically when it is in use by an integrated service and DNS validation can complete (the validation CNAME is still in place); email-validated certificates need action, and imported certificates are never renewed by ACM
- Each renewal issues a new certificate with a new key pair, so clients that pin the leaf certificate or its public key break at renewal — AWS advises against pinning ACM certificates (pin a root CA if you must)
- Standard public certificates cannot be exported — they are usable only with integrated AWS services. ACM also offers exportable public certificates (requested as exportable, paid per certificate) for EC2, containers or on-premises servers; ACM renews them, but you deploy each renewal yourself
- ACM public certificates are issued for server authentication only (no client-authentication usage since June 2025), and no public CA can issue for internal-only hostnames — so mTLS client certificates, device identities and internal names come from a private CA such as AWS Private CA
- Private certificates (via Private CA integration) can be exported and used on EC2
| Need | Solution |
|---|---|
| Public HTTPS for ALB/CloudFront | ACM public certificates (free, auto-renew) |
| Private mTLS between services | Private CA + ACM private certificates |
| Cross-Region encryption with same key | KMS multi-Region keys |
| IoT device authentication | Private CA certificates |
| On-premises workload certificates | Private CA + export via ACM |
⚠️ Exam Trap: A standard ACM public certificate cannot be exported, so a certificate installed directly on an EC2 instance or container comes from Private CA, an imported certificate, or an ACM exportable public certificate (public domain names only). Internal-only names and mTLS client certificates point to Private CA.
Scenario: A company runs a global application with databases in us-east-1 and eu-west-1. Cross-Region replication requires data encrypted in one Region to be readable in the other. You create a KMS multi-Region key with primary in us-east-1 and replica in eu-west-1. Data encrypted with either key is decryptable by both.
Reflection Question: How do multi-Region KMS keys simplify cross-Region disaster recovery compared to traditional approaches of re-encrypting data at Region boundaries?
