How do I migrate my Security, Identity and Compliance resources to another region?

If you are migrating data from the Middle East (UAE) Region (me-central-1), then you might experience increased error rates as we continue making progress with restoration efforts. For additional information about recovery efforts and service updates that impact your AWS accounts, see the AWS Personal Health Dashboard. For assistance with this event, contact AWS Support through the AWS Management Console or the AWS Support Center.

This is part of a series of articles that provide general guidance on migrating resources form one Region to another. It covers the following services:

• AWS Identity and Access Management (IAM)
• AWS Security Token Service (AWS STS)
• AWS Key Management Service (AWS KMS)
• Amazon Cognito
• AWS Identity and Access Management Access Analyzer
• AWS IAM Identity Center
• AWS Secrets Manager
• AWS Certificate Manager (ACM)

For general guidance and a full list of domain and service-specific migration guides, see How do I migrate my resources to another region?

For other domains, see the following resources:

• How do I migrate my Compute and Container resources to another region?
• How do I copy an EBS Snapshot to another region using coldsnap and the EBS Direct APIs?
• How do I migrate my Database resources to another region?
• How do I migrate my Database resources to another region using a logical dump?
• How do I migrate my Networking and Content Delivery resources to another region?
• How do I migrate my Storage resources to another region?
• How do I migrate my Application Integration resources to another region?

AWS Identity and Access Management (IAM) and Security Token Service (STS)

Configure IAM Federation and STS Regional Endpoints for Multi-Region Resiliency

• The signin.aws.amazon.com endpoint is the us-east-1 regional SAML sign-in endpoint, not a global endpoint - relying solely on it creates a single point of failure
• For SAML 2.0 federation, use regional SAML sign-in endpoints to improve federation resiliency
• In Regions enabled by default, requests to the AWS STS global endpoint are automatically served in the same Region where the request originates
• In opt-in Regions, requests to the AWS STS global endpoint are served by US East (N. Virginia) only
• Use regional AWS STS endpoints to reduce latency and provide redundancy for your applications
• Configure workloads to fail over to a secondary regional AWS STS endpoint in a geographically distant location from the primary region

Configure Multi-Region SAML Federation Endpoints

Configure your identity provider to use regional SAML endpoints for resilient federated console access.

Regional SAML sign-in endpoint URLs follow the format https://<region-code>.signin.aws.amazon.com/saml. If a regional endpoint becomes disrupted, your IdP can be adjusted to use another functioning regional endpoint.

1. Identify the regional SAML sign-in endpoints for your primary and failover regions from the SAML sign-in endpoints reference
2. Configure your external IdP with the regional endpoint for your primary region
3. Configure a failover regional endpoint in your IdP following the guidance in How to use regional SAML endpoints for failover
4. If a regional endpoint becomes unavailable, update your IdP configuration to use the failover regional endpoint. Consult your IdP documentation for specific implementation steps

Configure Regional STS Endpoints Using Shared Configuration File

Use the AWS shared configuration file to set regional STS endpoints.

1. Open the configuration file at ~/.aws/config (Linux/macOS) or C:\Users\USERNAME\.aws\config (Windows)
2. Add the sts_regional_endpoints parameter to your profile: [default] region = us-east-2 sts_regional_endpoints = regional Valid values: legacy (uses global endpoint sts.amazonaws.com) or regional (uses the endpoint for the configured region)

Configure Regional STS Endpoints Using Environment Variables

Use environment variables to set regional STS endpoints globally for your shell session.

1. Set the environment variable for regional STS endpoints in your shell. For a list of supported SDKs, see Compatibility with AWS SDKs
2. To persist across sessions, add the variable to your shell's startup script

Configure Regional STS Endpoints Using SDK Endpoint URL

Manually construct a regional STS endpoint URL in your application code.

1. Configure the STS client with a specific regional endpoint URL. For example, using AWS SDK for Python (Boto3): import boto3 sts_client = boto3.client('sts', region_name='us-east-2', endpoint_url='https://sts.us-east-2.amazonaws.com')

Verify STS Global Endpoint Usage with Trusted Advisor

Use AWS Trusted Advisor to identify workloads still using the global STS endpoint.

1. Review the "STS global endpoint" check in Trusted Advisor to identify API calls to the global STS endpoint sts.amazonaws.com from Regions other than US East (N. Virginia). This check is available across all AWS Support Plans at no additional cost
2. Update identified workloads to use regional STS endpoints using one of the methods above

---

AWS Key Management Service (AWS KMS)

Key Considerations and Prerequisites

• KMS keys cannot be migrated between regions - encrypted data must be decrypted in the source region and re-encrypted with a key in the target region
• Integrated AWS services (S3, EBS, Secrets Manager, etc.) cannot make cross-region calls to decrypt data keys
• Multi-region keys do not solve this for integrated services - AWS services that integrate with AWS KMS treat multi-region keys as single-region keys
• Multi-region keys are only useful for client-side encrypted ciphertexts and DynamoDB global tables
• Symmetric KMS keys with imported key material are not interoperable across regions, even with identical key material
• The ReEncrypt API cannot re-encrypt data with keys in different regions

Migrate Encrypted Resources Using Service-Specific Methods

Each AWS service has its own method for migrating encrypted resources between regions.

1. Identify the AWS service that owns the encrypted resource (EBS, S3, Secrets Manager, etc.)
2. Decrypt the resource using the KMS key in the source region
3. Re-encrypt the resource using a KMS key in the destination region
4. Consult the specific service's documentation for migration steps. For example, EBS allows you to specify target region and KMS key ARN using the DestinationRegion and KmsKeyId parameters in the CopySnapshot API

Migrate Client-Side Encrypted Data with Multi-Region Keys

Use this workflow if you encrypted data client-side using a multi-region key.

Multi-region keys allow you to replicate keys to other regions for client-side decryption without re-encryption.

1. Replicate your multi-region key to the target region following the replication guidance
2. Use the replicated key in the target region to perform client-side decryption operations

Migrate Client-Side Encrypted Data with Single-Region Keys

Use this workflow for data encrypted with single-region keys using the Encrypt API or data keys from GenerateDataKey APIs.

This applies to data encrypted directly with the Encrypt API or encrypted data keys from GenerateDataKey, GenerateDataKeyWithoutPlaintext, GenerateDataKeyPair, or GenerateDataKeyPairWithoutPlaintext APIs.

1. Decrypt your data or data key using the source region key, using the Decrypt API or [aws kms decrypt](https://docs.aws.amazon.com/cli/latest/reference/kms/decrypt.html) CLI command
2. Encrypt your plaintext data with a key in the destination region, using the Encrypt API or [aws kms encrypt](https://docs.aws.amazon.com/cli/latest/reference/kms/encrypt.html) CLI command

Migrate Data Encrypted with AWS Encryption SDK

Use this workflow for data encrypted using the AWS Encryption SDK.

The keyring that decrypts the encrypted message must be compatible with the one used to encrypt the message.

1. Decrypt your ciphertexts using your existing keyring with a key from the source region
2. Create a new keyring with a KMS key in your target region
3. Encrypt your data using the new keyring to produce ciphertexts that can be decrypted in the target region
4. Review AWS Encryption SDK code examples for your programming language or use the AWS Encryption SDK Command Line Interface

---

Amazon Cognito

Key Considerations and Prerequisites

• There is no direct operation to migrate or copy a Cognito User Pool and its users from one region to another
• User Pool configuration must be exported and recreated in the target region
• User passwords cannot be migrated directly - users will need to reset passwords after migration
• The 'sub' attribute (unique identifier) cannot be migrated between User Pools
• Some User Pool settings cannot be changed after creation, including sign-in options, required attributes, and username case sensitivity
• Third-party identity providers will require updated SP metadata to establish trust with the new User Pool

Migrate User Pool Configuration

Export your source User Pool configuration and recreate it in the target region.

1. Use the DescribeUserPool API to retrieve your User Pool's configuration
2. Export app client configurations using ListUserPoolClients and DescribeUserPoolClient
3. Create a new User Pool in the target region using the CreateUserPool API or console, applying the same configuration. Review Getting started with user pools and CreateUserPool code examples for guidance
4. Recreate app clients using CreateUserPoolClient and configure third-party identity providers following the identity federation setup guidance
5. Update SP metadata in your IdP configuration to establish trust with the new User Pool

Migrate Users with CSV Import

Use the built-in CSV import feature to migrate large quantities of users and their attributes.

1. Retrieve user data from your source User Pool using the ListUsers API
2. Download a CSV template from your destination User Pool that matches its attribute schema
3. Populate the CSV template with user records from your source User Pool
4. Submit the CSV file as an import job to your destination User Pool
5. Set passwords for imported users using the AdminSetUserPassword API (users will be in 'RESET_REQUIRED' state)

Migrate Users with Lambda Trigger

Use the Migrate User Lambda trigger to migrate users as they authenticate.

This approach migrates users when they successfully authenticate or complete the ForgotPassword flow. It may not be suitable for immediate migrations as you must wait for all users to complete authentication.

1. Create a Lambda function with an authorization policy that permits only the cognito-idp.amazonaws.com service principal to invoke it
2. Implement a Migrate user Lambda trigger including the required migration logic. Review the example code in the documentation
3. Configure the Lambda trigger in your new User Pool following the importing users with a Lambda trigger guidance

Migrate Users with User Profiles Export Guidance

Use the AWS Guidance for User Profiles Export with Amazon Cognito for a framework-based migration approach.

This guidance provides Step Functions workflows to export and import user profiles, groups, and group memberships. Note that this solution does not support User Pools with MFA enabled and does not transfer user passwords.

1. Review the implementation guide to understand costs and limitations
2. Access the sample code repository for deployment resources
3. Deploy the ExportWorkflow to export user data from your source User Pool to a DynamoDB global table
4. Run the ImportWorkflow Step Functions workflow in your target region to populate the new User Pool with data from the global table

Update Your Application

Configure your application to use the new User Pool in the target region.

1. Replace references to your old User Pool and app client identifiers with the new User Pool identifiers in your application code
2. Update your AWS SDK configuration to point to the new region and User Pool. Review code examples for authentication
3. If using Managed Login, configure your domain and customize resources following the Managed Login documentation

Migrate Identity Pool Configuration

Export your Identity Pool configuration and recreate it in the target region.

1. Call DescribeIdentityPool to capture the full configuration
2. Call GetIdentityPoolRoles to capture IAM role mappings
3. Create a new Identity Pool in the target region using CreateIdentityPool or follow the getting started guidance
4. Configure identity providers following the third party identity providers guidance and update SP Entity ID and ACS URL in your IdP
5. Associate IAM roles with the new Identity Pool using SetIdentityPoolRoles
6. Update the IAM roles' trust policies to allow the cognito-identity.amazonaws.com principal to perform sts:AssumeRoleWithWebIdentity
7. Update your application to reference the new Identity Pool ID and region

---

Amazon GuardDuty

Configuring Amazon GuardDuty in a New AWS Region

• Amazon GuardDuty is a regional service; detectors are scoped to a specific region and there is no built-in cross-region migration mechanism.
• A detector represents the GuardDuty service in a region — only one detector is allowed per account per region. All configuration (filters, IPSets, ThreatIntelSets, suppression rules) is scoped to that detector and must be recreated in the target region.
• Findings are not migrated; GuardDuty begins generating new findings from current activity after the detector is enabled in the target region. Existing findings from the source region can be exported to S3 for historical retention beyond the 90-day in-service retention period.
• For AWS Organizations setups, the delegated GuardDuty administrator account is regional — it must be designated separately in each region where GuardDuty is enabled.
• Verify that all desired protection plans (S3 Protection, EKS Audit Logs, RDS Protection, Runtime Monitoring, Malware Protection) are available in the target region before proceeding, as feature availability varies by region.
• The following steps are intended for a delegated admin account or a standalone account for Amazon GuardDuty enabled only in the impacted region.

Creating the Detector

Create a new detector in the target region and enable the desired protection plans. By default, a new detector enables S3 Logs, Kubernetes Audit Logs, and Malware Protection for EC2, but Runtime Monitoring and EKS Runtime Monitoring are not enabled by default.

1. Create a new detector using the Getting started with GuardDuty console or the create-detector CLI.
2. Enable the desired protection plans explicitly during or after detector creation.

Creating Custom Threat Detection Lists

IPSets (trusted IP lists) and ThreatIntelSets (known malicious IP lists) are regional and must be created in the target region. The S3 objects containing the list files must be accessible from the target region.

1. Create trusted IP lists using Customizing threat detection with entity lists and IP address lists or the create-ip-set CLI.
2. Create threat intel sets using the create-threat-intel-set CLI.

Creating Filters, Suppression Rules, and EventBridge Automation

Saved filters, suppression rules, and EventBridge rules are regional and must be created in the target region.

1. Describe existing filters in the original region using list-filters and get-filter CLI to capture current configuration.
2. Create saved finding filters using Filtering findings in GuardDuty or the create-filter CLI.
3. Create suppression rules (filter-based auto-archive rules) using Suppression rules in GuardDuty.
4. Create any EventBridge rules that trigger automation based on GuardDuty findings (such as SNS notifications or Lambda remediation) using Processing GuardDuty findings with Amazon EventBridge.
5. If findings were being exported to S3, recreate the publishing destination using the create-publishing-destination CLI.

Configuring AWS Organizations Setups

If you are using GuardDuty with AWS Organizations, the delegated administrator and member account configuration must be set up separately in the target region.

1. Designate the delegated GuardDuty administrator account in the target region from the organization management account using Designating a delegated GuardDuty administrator account.
2. Reconfigure organization auto-enable preferences for new and existing member accounts in the target region using Setting organization auto-enable preferences.
3. Add any necessary member accounts in the target region if you are setting up a delegated admin account.

---

AWS Certificate Manager (ACM)

Key Considerations and Prerequisites

• ACM is a regional service — certificates cannot be directly copied or transferred between regions. Integrated services such as Elastic Load Balancing and API Gateway cannot reference an ACM certificate from a different region. The private key of an ACM certificate is protected by AWS KMS using a region-specific AWS managed KMS key.
• For CloudFront distributions, the ACM certificate must reside in us-east-1 (N. Virginia) regardless of where your origin or other resources are located. CloudFront certificates do not need to be migrated when moving resources out of another region.
• ACM-issued public certificates require domain validation (DNS or email) in each region where a new certificate is requested. If using DNS validation, the same CNAME record works across all regions, so re-validation is not required for additional certificate requests in new regions.
• AWS Private CA certificate authorities are also regional resources — you cannot copy a private CA between regions. To use a private CA in multiple regions, you must create a separate CA in each target region.
• ACM public certificates are valid for 198 days and are automatically renewed 45 days before expiration (certificates with the older 395-day validity period renew 60 days before expiration), as long as the certificate is in use by an AWS service and the DNS validation record remains in place.
• ACM service quotas are per-region, per-account. Before migrating, verify that the target region has sufficient quota. ACM certificates per region: 2,500 (default). Expired and revoked certificates count toward this total. Certificates signed by AWS Private CA do not count.
• Review What is AWS Certificate Manager? and Services integrated with ACM to identify which services depend on the certificate.

Identify ACM Certificate Types

Before planning a migration, identify which types of certificates you have. Each type has a different migration path.

• Non-exportable, Amazon-issued public ACM certificates — the most common type. Validated via DNS, email, or HTTP. Private key stored in AWS KMS, region-locked, non-exportable. Public ACM certificates created before June 17, 2025 cannot be exported. Migration path: request a new certificate in the target region with the same domain name, SANs, and key algorithm, then validate it independently.
• Exportable, Amazon-issued public ACM certificates — available for public certificates created on or after June 17, 2025. Private key can be exported via aws acm export-certificate. Migration path: export and re-import into the target region, or request a new exportable public certificate in the target region.
• Imported ACM certificates — certificates obtained from an external CA and imported into ACM. ACM does not auto-renew these. If you still have the original certificate body, private key, and chain, re-import them into the target region. If the private key is no longer available, obtain a new certificate from your CA.
• Private ACM certificates (issued by AWS Private CA) — issued for internal/private use. Can be non-exportable or exportable depending on the template used at issuance. Migration path: create a Private CA in the target region (recommended as a subordinate under your existing root CA), then issue new certificates from the target region CA.

Inventory Certificates in the Source Region

List all certificates and capture their metadata before provisioning in the target region.

1. List all certificates using the ListCertificates API.
2. Retrieve full details for each certificate using the DescribeCertificate API. Note the certificate type (AMAZON_ISSUED or IMPORTED), CertificateAuthorityArn (to identify Private CA-issued certs), domain name, SANs, key algorithm, validation method, whether the certificate is exportable, and associated resources.
3. Categorize each certificate: Type: AMAZON_ISSUED with no CertificateAuthorityArn is non-exportable Amazon-issued; Type: AMAZON_ISSUED with a CertificateAuthorityArn is Private CA-issued (check if exportable); Type: IMPORTED is an imported certificate.

Provision Non-Exportable Amazon-Issued Certificates in the Target Region

Use this workflow for non-exportable, Amazon-issued public certificates. You cannot transfer the existing certificate or its private key.

1. Request a public certificate in AWS Certificate Manager in the target region, or use the RequestCertificate API. Match the domain name, SANs, key algorithm, and validation method from the source certificate.
2. Validate the certificate using DNS or email validation. If your source certificates were DNS-validated and the CNAME records are still in place, the target region certificates will validate automatically with no additional action. If the CNAME records were removed, create new ones following AWS Certificate Manager DNS validation. Email-validated certificates require manual approval of validation emails sent to domain contacts.
3. Wait for the certificate to reach ISSUED status using the DescribeCertificate API. DNS-validated certificates typically issue within minutes if the CNAME records are in place.

Provision Exportable Amazon-Issued Public Certificates in the Target Region

Use this workflow for exportable public certificates created on or after June 17, 2025. You can either export and re-import, or request a new certificate.

1. To export and re-import: Export an AWS Certificate Manager public certificate from the source region, or use the ExportCertificate API. Then import certificates into AWS Certificate Manager in the target region, or use the ImportCertificate API. Once imported, ACM treats the certificate as an imported certificate and will not auto-renew it.
2. Alternatively, request a new exportable public certificate in the target region and re-validate via DNS or email using the same process as non-exportable certificates.

Provision Imported Certificates in the Target Region

Use this workflow for certificates obtained from an external CA and previously imported into ACM. You need the original certificate body, private key, and chain.

1. Import a certificate into ACM in the target region, or use the ImportCertificate API.
2. If you no longer have the private key, obtain a new certificate from your CA and import that instead.
3. To renew an imported certificate, obtain a new certificate from your issuer and reimport it using Reimport a certificate to preserve the existing ARN and service associations. Imported certificates are not auto-renewed by ACM.

Provision Private CA Certificates in the Target Region

Use this workflow for certificates issued by AWS Private CA. You need a Private CA in the target region before issuing certificates.

1. Create a private CA in AWS Private CA in the target region. The recommended approach is to create a subordinate CA under your existing root CA, which preserves a single chain of trust. Clients that already trust your root CA will automatically trust certificates issued by the new subordinate. If your root CA is external, export a CSR from the new subordinate and get it signed by your external root.
2. Request a private certificate in AWS Certificate Manager from the target region CA.
3. If the certificates are exportable, you can alternatively export from the source region and import into the target region using the same export/import process as exportable public certificates. The imported certificate's chain will still reference the source region CA, and ACM will not auto-renew it.
4. Update any clients that pin or explicitly trust the source region CA certificate to also trust the target region CA.

Update Service References in the Target Region

Once certificates are issued in the target region, update your services to reference the new certificate ARNs. Always verify the update by confirming the service is serving the correct certificate (for example, using openssl s_client -connect).

1. For Application Load Balancers, update HTTPS listener certificates following SSL certificates for your Application Load Balancer.
2. For Network Load Balancers, update TLS listener certificates following Update a TLS listener for your Network Load Balancer.
3. For Classic Load Balancers, update SSL certificates following Replace the SSL certificate for your Classic Load Balancer.
4. For CloudFront distributions, the certificate must be in us-east-1. If you need to update the certificate, update the distribution's ViewerCertificate following Use alternate domain names and HTTPS.
5. For API Gateway custom domain names, update the domain configuration following Setting up custom domain names for REST APIs.

---

AWS IAM Access Analyzer

Key Considerations and Prerequisites

• IAM Access Analyzer is a regional service; analyzers are scoped to a specific region and there is no built-in cross-region migration mechanism
• There are three types of analyzers as described in Using AWS Identity and Access Management Access Analyzer: Unused Access analyzers cover global IAM resources and only need to be created in a single region, while External Access and Internal Access analyzers are regional and should be created per region
• IAM Access Analyzer also provides Checks for validating policies and IAM Access Analyzer policy generation; policy generation depends on CloudTrail logs, so disruption to the CloudTrail delivery pipeline in a region impacts the accuracy of generated policies
• Findings are not migrated; they are regenerated from current resource policies after the analyzer is created in the new region
• The AWSServiceRoleForAccessAnalyzer service-linked role is created automatically when a new analyzer is created.

Note: Verify SLR creation is permitted in the target region before proceeding.

Create a New Analyzer in the Target Region

Create the analyzer using the console, CLI, or IaC. For organization-level analyzers, use the ORGANIZATION type from the delegated admin or management account.

1. Create a new analyzer using the Getting started with AWS Identity and Access Management Access Analyzer console or the create-analyzer CLI
2. For account-level analyzers, specify --type ACCOUNT; for organization-level analyzers, specify --type ORGANIZATION

Recreate Archive Rules and EventBridge Automation

Archive rules and EventBridge rules are regional and must be recreated in the target region.

1. Recreate archive rules that suppress or auto-archive known findings using Archive rules or the create-archive-rule CLI
2. Recreate any EventBridge rules that trigger automation based on Access Analyzer findings (such as SNS notifications or Lambda remediation) using Monitoring AWS Identity and Access Management Access Analyzer with Amazon EventBridge
3. After creating the analyzer in the target region, findings generations timing varies by type. The external access findings typically appears within 30 minutes, internal access findings may take several minutes to hours for the initial scan, and unused access findings depend on the configured tracking period (1–365 days) and available CloudTrail activity data.

---

AWS IAM Identity Center

Key Considerations and Prerequisites

• IAM Identity Center is a regional service deployed in a single region for your AWS Organization, built on highly available infrastructure with Availability Zone architecture
• Multi-region replication is available only in commercial Regions enabled by default and currently requires an external identity provider as the identity source
• Organization instances set up in an opt-in Region as the primary region do not support multi-region replication - consider switching regions if regulatory requirements permit
• Switching the primary region requires deleting the current instance and recreating all configuration in the new region
• Store backup configurations or document them as infrastructure as code (IaC) before making changes

Enable Multi-Region Replication

Use this workflow if your primary region is a commercial Region enabled by default and you want to replicate IAM Identity Center to an additional region.

Ensure all prerequisites are met before starting. The duration of initial replication depends on the amount of data in your instance.

1. Create a replica key in the additional region
2. Add the region in IAM Identity Center
3. Update your external IdP setup. If your IdP does not support multiple assertion consumer service (ACS) URLs, work with the IdP to enable this support
4. Confirm firewall and gateway allow-lists are updated
5. Provide updated information to your users, including new AWS CLI profiles for the additional region

Follow the detailed steps in Replicate to an additional Region. For AWS managed applications, review Deploying and managing applications across multiple AWS Regions - only applications that support customer managed KMS keys and additional region deployment can be used with multi-region replication.

Switch IAM Identity Center to a New Primary Region

Use this workflow to move IAM Identity Center to a different region by deleting and recreating the instance.

1. Back up your current configuration using the IAM Identity Center API reference to capture permission sets, application assignments, users, and groups. Refer to Managing identity source transition for AWS IAM Identity Center and the sample scripts on GitHub for guidance
2. Optionally, generate a detailed permission set dataset following How to automate the review and validation of permissions for users and groups in AWS IAM Identity Center
3. If you have AWS managed applications enabled, disable them before deleting the instance following Disabling an AWS managed application
4. Delete your current IAM Identity Center instance
5. Create a new IAM Identity Center instance in the target region and recreate users, groups, permission sets, applications, and assignments using your backed-up configuration

Configure Emergency Console Access via Direct Federation

Use this workflow to set up emergency access to the AWS Management Console when IAM Identity Center is unavailable but the IAM data plane and your external IdP are available.

This configuration uses emergency access through direct SAML federation to an emergency operations account. During normal operations, no one has access because the emergency IdP group has no members.

1. Create an emergency operations account in your organization in AWS Organizations
2. Connect your IdP to the emergency operations account using SAML 2.0-based federation
3. Create a role for third-party identity provider federation in the emergency operations account, and create an emergency operations role in each workload account with required permissions
4. Delegate access to your workload accounts for the IAM role in the emergency operations account
5. Create an emergency operations group in your IdP with no members, and create a rule enabling SAML 2.0 federated access to the AWS Management Console
6. During a disruption, add trusted users to the emergency operations group in your IdP. Users sign in to the IdP, access the console, assume the emergency operations role, and switch roles to the emergency access role in workload accounts

---

AWS Secrets Manager

Key Considerations and Prerequisites

• AWS Secrets Manager has a native feature to replicate customer-created secrets to another region — you don't need to manually copy secret values
• Before you can replicate a secret to another Region, you must have that Region enabled
• Replicating a secret to another region is non-destructive — the primary remains fully active in the source region. This option creates a linked replica in the target region that stays in sync with the primary.
• If your secret uses the default aws/secretsmanager key, replication uses the same managed key in the target region automatically
• If using a customer-managed KMS key, you need a KMS key (or replica key) in the target region and must specify it in the replication call
• The IAM principal doing the replication needs kms:Decrypt permissions for the key in the source region, along with kms:GenerateDataKey, and kms:Encrypt permissions for the KMS key in the target region.
• Managed secrets from services like Amazon RDS, Amazon Redshift, Amazon DocumentDB, Amazon ECS, AWS Glue DataBrew, AWS DataSync, AWS Direct Connect, Amazon EventBridge, AWS AppFlow, AWS Marketplace, AWS OpsWorks for Chef Automate, AWS Parallel Computing Service, and Amazon Redshift query editor v2 cannot be replicated — follow region migration or DR recommendations of the respective services such that the managed secret is created in the new target region

Replicate Secrets

This method creates a linked replica in the target region that stays in sync with the primary. Use this for ongoing multi-region use or disaster recovery.

1. Open the secret in the AWS Secrets Manager console, choose Actions, then Replicate secret, and select the target region (and optionally a KMS key)
   1. Alternatively, call ReplicateSecretToRegionsfrom the primary region of the secret using the AWS CLI: aws secretsmanager replicate-secret-to-regions \ --secret-id MyTestSecret \ --add-replica-regions Region=eu-west-1
   2. If you want to use a customer-managed KMS key in the target region, specify it in the replication call: aws secretsmanager replicate-secret-to-regions \ --secret-id MyTestSecret \ --add-replica-regions '[{"Region":"eu-west-1","KmsKeyId":"arn:aws:kms:eu-west-1:123456789012:key/your-key-id"}]' \ --region us-east-1
2. If you turn on rotation for your primary secret, Secrets Manager rotates the secret in the primary Region and the new secret value propagates to all of the associated replica secrets — see Replicate AWS Secrets Manager secrets across Regions

Promote Replica to Primary

Use this method if you want to fully move to the new region (not just replicate). Promoting a replica secret disconnects the replica secret from the primary secret and makes the replica secret a standalone secret — changes to the primary secret won't replicate to the standalone secret.

1. Replicate the secret to the target region using the Replicate Secrets procedure
2. Promote the replica to a standalone primary by opening the AWS Secrets Manager console, navigating to your replica Secret, choosing the ‘Promote to standalone secret’ option and choosing the region. This can also be done by calling StopReplicationToReplicafrom within the replica region — see Promote a replica secret to a standalone secret.
3. Consider turning on rotation for the newly promoted replica secret — migrate any rotation resources like Lambda functions or managed external rotation configuration that you used for the original secret
4. Point applications to use the newly promoted secret in the new Region and thoroughly test that your workloads operate with the secret created in target region

Migrate Back to Original Primary Region

Use this method when you want to start using the secret from the original primary region again.

1. Get the current valuefrom the promoted secret in the target region and update the original primary in the source region with that value.
2. Update the original primary in source region with the retrieved value.
3. Re-establish replication from the source region to the target region — this will overwrite the promoted standalone secret.
   1. Note: The ForceOverwriteReplicaSecret flag is required because a secret with that name already exists in the target region (the promoted standalone)
4. Point applications back to the source (primary) region secret ARN/endpoint if they were temporarily redirected to the target region during the outage
5. Setup rotation operations on the original secret using existing or new Lambda functions or managed external rotation configuration

---

In collaboration with Vania Toma and Francesco Penta