AWS Secrets Manager Multi-Region Strategy - Replication and Cross-Account Sharing
Learn how to achieve disaster recovery with multi-region replication and build centralized management from a security account using cross-account access.
Multi-Region Secrets
Secrets Manager's multi-region secrets feature automatically synchronizes a primary region's secret to up to four replica regions. Each replica has its own ARN but can be accessed using the same secret name. Applications retrieve secrets from region-specific endpoints, so if the primary region fails, they can continue accessing secrets from a replica region. Replicas are read-only, and updates can only be made in the primary region. In the event of a primary region failure, you can promote a replica to primary to enable writes.
Cross-Account Access
In multi-account environments, the recommended approach is to manage secrets in a central security account and reference them from workload accounts. Configure a resource-based policy on the secret to allow GetSecretValue for IAM roles in workload accounts. On the workload account side, attach a policy to the IAM role granting access to the secret ARN in the security account. You also need to configure cross-account Decrypt permissions in the KMS key policy. This setup centralizes secret management while allowing applications in each account to access secrets securely.
Versioning and Availability During Rotation
Secrets Manager manages secret versions using labels. AWSCURRENT points to the currently active version, and AWSPREVIOUS points to the immediately preceding version. During rotation, a new password is created with the AWSPENDING label, and after the database password update and connection test succeed, it is promoted to AWSCURRENT. The alternating users strategy uses two database users alternately, maintaining connectivity through one user while the other's password is being rotated. On the application side, using the SDK's caching library is recommended - it continues using the pre-rotation password within the cache TTL and retrieves the new password when the TTL expires.
Secrets Manager Pricing
Secrets Manager pricing consists of approximately 0.40 USD per secret per month and approximately 0.05 USD per 10,000 API calls (as of August 2026). Multi-region replication incurs the same monthly fee for secrets in each replica region. Replicating to 4 regions costs approximately 2.00 USD per secret per month (0.40 x 5 regions). While this is more expensive than Parameter Store's SecureString (standard parameters are free), the value of automatic rotation and multi-region replication should be factored into the decision.
How Replicas Work and DR
Secrets Manager can replicate secrets to multiple regions. When you update the secret in the primary region, its contents are automatically reflected in the replica regions. Applications in each region can read the secret from a region close to them, so they avoid the latency of access across regions. From a disaster recovery perspective, if the primary region becomes unavailable, you can switch to a replica region and continue operations. A mechanism that reliably distributes the same credentials to multiple regions is the foundation of a highly available system.
Encryption and Key Management in Replication
Secrets are encrypted per region, so when you create a replica, you specify the encryption key to use in the replica region. The same key cannot be used across regions, so you prepare a corresponding key for each region and design permissions so that each region can decrypt. As a result, applications in each region can retrieve secrets securely using that region's key. Because key management is separated by region, access control on a per-region basis also becomes clear. When you design replication, it is important to plan not only the data itself but also, together with it, the placement of the keys that decrypt it and their permissions.
Designing Multi-Region Applications
For applications that run services in multiple regions, it is important that each region can operate autonomously. If you replicate secrets to each region in advance, applications can obtain credentials locally and operate without depending on regions outside their own. As a result, even if communication between regions fails, each region can keep functioning independently. Completing processing in a region close to users also makes responses faster. For services deployed globally, a design that distributes common components such as secrets to each region leads to achieving both availability and performance.
Operational Considerations
There are several points to keep in mind when operating multi-region secrets. Replication takes a slight amount of time to reflect changes, so you take into account the possibility that an old value is read from a replica immediately after an update. When you update credentials through rotation, verify that the change propagates reliably to each region. Creating a replica means the secret is stored in each region and incurs the corresponding cost, so limit replicas to the secrets that you truly need in multiple regions. Clean up replicas that are no longer needed. Operating with three points in mind, namely replica consistency, rotation propagation, and cost, is the key to keeping a multi-region configuration stable.
Summary
Secrets Manager's multi-region replication and cross-account sharing enable enterprise-scale secret management. By combining replica placement for disaster recovery, centralized management in a security account, and availability during rotation through versioning, you can build a robust secret management foundation.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Secrets Manager official page
- AWS KMS official page
- AWS Lambda official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.