Imported from aws-samples/sample-migration-agentic-cli-assistant (.kiro/skills/migration-security/SKILL.md). Install upstream with npx skills add aws-samples/sample-migration-agentic-cli-assistant --skill migration-security. Copyright stays with the author.

Security Services Migration

Security: Always ensure migrated resources meet or exceed the security configuration of the source resources. Refer to SECURITY.md for security requirements.

AWS Certificate Manager (ACM) Certificate Migration to a New Region (Detailed Version)

Key Considerations

• ACM is a regional service: certificates cannot be directly copied or transferred between regions.
  • ACM certificates are bound to the region in which they were requested or imported. Integrated services (ELB, API Gateway, etc.) cannot reference an ACM certificate from a different region.
  • The private key of an ACM certificate is protected by AWS Key Management Service (AWS KMS) using a region-specific AWS managed key. AWS KMS keys are regional resources.
• For CloudFront distributions specifically, ACM certificates must reside in us-east-1, they do not need to be migrated when moving resources out of another region.
• ACM-issued public certificates require domain validation 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 Certificate Authority (AWS Private CA) instances 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 service quotas are per-region, per-account. Before migrating, verify that the target region (Region B) has sufficient quota to accommodate the new certificates. Key quotas to check:
  • ACM certificates per region: 2,500 (default). Expired and revoked certificates count toward this total.

What "Migration" Actually Means

Since you cannot directly move an ACM certificate between regions, migration means provisioning equivalent certificates in the target region. The exact steps depend on the certificate type (see above), but the general process is:

1. Inventory all certificates in Region A, noting their type
2. For each certificate, follow the migration path for its type
3. Validate or verify the new certificates in Region B
4. Update your services in Region B to reference the new certificate ARNs

The certificates in Region B will have different ARNs. For non-exportable Amazon-issued certs, they will also have different serial numbers and private keys. For exported/imported certs, the certificate material can be identical but the ARN will still differ.

Migration Workflow

Step 1: Inventory Certificates in Region A

List all certificates and capture their metadata: domain name, Subject Alternative Names (SANs), key algorithm, validation method (DNS or EMAIL), and status.

# Note: default filtering only returns RSA_1024 and RSA_2048 certificates.
# You must explicitly include all key types to get a complete inventory.
aws acm list-certificates --region <region-a> \
  --includes keyTypes=RSA_1024,RSA_2048,RSA_3072,RSA_4096,EC_prime256v1,EC_secp384r1,EC_secp521r1 \
  --query 'CertificateSummaryList[*].[CertificateArn,DomainName,KeyAlgorithm,Type]' \
  --output table

For each certificate, get the full details:

aws acm describe-certificate --region <region-a> --certificate-arn <arn>

Copy down which certificate attributes are important. Here's a sample list:

• Certificate type (check the Type field: AMAZON_ISSUED or IMPORTED, and CertificateAuthorityArn to identify Private CA-issued certs)
• Domain name
• SANs (SubjectAlternativeNames)
• Key algorithm (e.g., RSA_2048, EC_prime256v1)
• Validation method (DNS or EMAIL)
• Whether the certificate is exportable (Private CA-issued certs with the appropriate template)
• InUseBy: Associated resources (ELBs, API Gateways, etc.)
• Tags

Based on the Type, identify which types of certificates you have, as each type has a different migration path:

• Non-Exportable, Amazon-Issued Public ACM Certificates

  • These are the most common type. You request them through ACM, Amazon issues them using the Amazon public CA, and the private key is managed entirely by AWS. You do not have access to the private key. See Public Certificates
    • Validated via DNS, EMAIL, or HTTP (HTTP is only available for certificates associated with CloudFront, and does not support wildcard domains)
    • Private key stored in AWS KMS, region-locked, non-exportable

• Exportable, Amazon-Issued Public ACM Certificates

  • Available for public certificates created on or after June 17, 2025. These are issued by the Amazon public CA, but you can export the private key. See Exportable Public Certificates.
    • You are responsible for redeploying the renewed certificate after export
    • Subject to additional pricing (unlike non-exportable public certs which are free)

• Imported ACM Certificates

  • These are certificates you obtained from an external CA (or generated yourself) and imported into ACM. ACM does not manage issuance or renewal for these.
    • The customer provided the certificate body, private key, and chain at import time
    • ACM does not auto-renew these; the customer is responsible for renewal and re-import before expiration
    • The private key was provided by the customer when they imported it, so they may still have it

• Private ACM Certificates (Issued by AWS Private Certificate Authority)

  • These are certificates issued by AWS Private CA for internal/private use (e.g., mTLS, internal services). They are not publicly trusted. Clients must have the private CA certificate installed in their trust stores.
    • Can be non-exportable or exportable
      • If exportable, the private key can be exported via aws acm export-certificate (encrypted with a passphrase)
    • The issuing Private CA's trust chain is specific to that CA

Step 2: Provision Certificates in Region B (by Type)

The provisioning step differs depending on the certificate type identified in Step 1.

Type 1: Non-Exportable, Amazon-Issued Certificates

Request a brand new certificate in Region B. You cannot transfer the existing one.

aws acm request-certificate \
  --region <region-b> \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" "api.example.com" \
  --validation-method DNS \
  --key-algorithm RSA_2048

Match the domain name, SANs, key algorithm, and validation method from the source certificate. Other attributes like Tags can also be matched. Then proceed to Step 3 for validation.

Type 2: Exportable, Amazon-Issued Public Certificates

For public certificates that are exportable. You may also want to copy over Tags if applicable.

Option A — Export from Region A and import into Region B:

# Export from Region A (requires a passphrase to encrypt the private key)
aws acm export-certificate \
  --region <region-a> \
  --certificate-arn <arn> \
  --passphrase fileb://path-to-passphrase-file \
  | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' > exported-cert.pem

# Split into separate files (certificate, chain, private key), then import into Region B
aws acm import-certificate \
  --region <region-b> \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://chain.pem

Note: once imported into Region B, ACM treats the certificate as an imported certificate. It does not auto-renew. You are responsible for re-exporting and re-importing when the source certificate renews. Risk: If you forget to re-export after renewal, the Region B certificate expires without notification.

Option B — Request a new exportable public certificate in Region B and re-validate via DNS or email (same process as Type 1). It’s important to point out the costfor using this service.

Type 3: Imported Certificates

Re-import the original certificate material into Region B. You need the original certificate body, private key, and chain.

aws acm import-certificate \
  --region <region-b> \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://chain.pem

If you no longer have the private key, you cannot re-import. You will need to obtain a new certificate from your CA and import that instead. Imported certificates are not auto-renewed by ACM. You remain responsible for renewal and re-import in both regions. You might also want to consider copying tags as well.

Type 4: Private ACM Certificates (AWS Private CA)

First, verify you have an AWS Private CA in Region B. If not, create one by following Create a private CA in AWS Private CA. It's important to plan the CA hierarchy carefully rather than just creating a standalone root CA in Region B:

• Recommended: Create a subordinate CA in Region B under your existing root CA. This preserves a single chain of trust. Clients that already trust your root CA will automatically trust certificates issued by the new subordinate in Region B, with no trust store changes needed. If your root CA is hosted in AWS Private CA, the subordinate signing process is automated. If your root is external, you'll need to export a CSR from the new subordinate and get it signed by your external root.
• Alternative: Create a new root CA in Region B. This creates an independent trust chain. Every client, application, and mTLS peer that validates certificates must be updated to trust the new root. This is more disruptive but may be appropriate if you want full isolation between regions.
• Key algorithm: Match the key algorithm family of your existing CA hierarchy (RSA or ECDSA). The subordinate CA's signing algorithm family must match the parent CA's key algorithm family.
• Revocation: Configure CRL distribution or OCSP on the new CA so clients in Region B can check revocation status. If your Region A CA uses CRL, the S3 bucket hosting the CRL is regional — you'll need a new CRL bucket in Region B. Verify the CRL bucket has Block Public Access configured appropriately, default encryption enabled, and a bucket policy enforcing TLS-only access.
• Cost: AWS Private CA charges a monthly fee per CA, plus per-certificate issuance fees. Factor this into your customer’s cost planning.

Once the CA is active and its certificate is installed, issue new certificates from the Region B CA:

aws acm request-certificate \
  --region <region-b> \
  --domain-name internal.example.com \
  --certificate-authority-arn arn:aws:acm-pca:<region-b>:<account>:certificate-authority/<ca-id>

If the certificates are exportable, you can alternatively export from Region A and import into Region B (same export/import process as Type 2, Option A). Note that:

• The imported certificate's chain will still reference the Region A CA, which may matter for clients that validate the full trust chain.
• Once imported, ACM treats them as imported certificates and does not auto-renew them. The Region B copy can silently expire if you do not re-export after the source renews.

Any clients that pin or explicitly trust the Region A CA certificate will need to be updated to also trust the Region B CA.

Step 3: Validate Certificates in Region B

This step applies to Amazon-Issued certificates. Imported certs are already valid upon import. Private CA certs issued via request-certificate do not require DNS/email validation.

DNS Validation (Recommended)

DNS validation uses CNAME records to prove domain ownership. A critical insight: DNS validation CNAME records are interoperable between regions. If a CNAME validation record already exists in Route 53 for a domain (from the Region A certificate), requesting the same domain in Region B will auto-validate using that existing record. This means:

• If your Region A certificates were DNS-validated and the CNAME records are still in place, Region B certificates for the same domains will validate automatically with no additional action.
• If the CNAME records were removed, you will need to create new ones. Get the required records from:

aws acm describe-certificate --region <region-b> --certificate-arn <new-arn> \
  --query 'Certificate.DomainValidationOptions[*].[ResourceRecord.Name,ResourceRecord.Value]' \
  --output table

Then create the CNAME records in Route 53 or your DNS provider.

Email Validation

Email-validated certificates require manual action. AWS sends validation emails to domain contacts (admin@, postmaster@, etc.). Each certificate request in Region B triggers a new round of validation emails that must be approved. This cannot be automated.

Step 4: Verify Issuance

Wait for certificates to reach ISSUED status:

aws acm describe-certificate --region <region-b> --certificate-arn <new-arn> \
  --query 'Certificate.Status'

DNS-validated certificates typically issue within minutes if the CNAME records are in place. Email-validated certificates depend on how quickly the validation emails are approved.

Step 5: Update Service References

Once certificates are issued in the target region, update your services to reference the new certificate ARNs. 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.

Extra Considerations

Exported Certificates Lose Auto-Renewal

When you export a certificate (public or private) from Region A and import it into Region B, ACM treats it as an imported certificate in Region B. This means ACM will not auto-renew it.

Risk: The source certificate in Region A auto-renews normally, but the imported copy in Region B does not. If you do not re-export and re-import after each renewal, the Region B certificate expires without notification. In a DR scenario, this means your failover region may have expired certificates, and you won't discover it until you actually attempt failover.

Mitigation:

• Use Amazon EventBridge to subscribe to ACM Certificate Approaching Expiration events for the Region B (imported) certificate
• Subscribe to the source certificate's renewal success event in Region A to trigger the re-export/re-import workflow
• Include Region B certificate expiration checks in your regular DR readiness monitoring
• Consider requesting new certificates natively in Region B (instead of export/import) to get auto-renewal, accepting the trade-off of needing to re-validate

Private CA Trust Chain Considerations

When creating a new Private CA in Region B, the CA certificate will be different from the one in Region A. This affects:

• Clients that validate the full certificate chain (they need to trust the new CA)
• Applications doing certificate pinning
• mTLS configurations where the server validates client certificates against a specific CA

The recommended approach is to create the Region B CA as a subordinate under the same root CA used in Region A. This way, clients that trust the root CA will automatically trust certificates from both regions.

Certificate Pinning

Certificate pinning is the practice of associating a host with a specific certificate or public key, rather than relying solely on the standard certificate chain validation. If customers are certificate pinning, migration will break connectivity unless the pins are updated. The impact depends on the certificate type:

• For non-exportable Amazon-issued public certificates, migration requires requesting an entirely new certificate in Region B. The new certificate has a different public key, serial number, and fingerprint. Any client pinning to the leaf certificate or its public key may reject the new certificate. Pins must be updated to include the new certificate's public key.
• For exportable Amazon-issued public certificates, if you export from Region A and import into Region B, the certificate material (including the public key) is identical. Leaf-level pins continue to work. However, if you choose to request a new certificate in Region B instead, the same leaf-pin breakage applies as with non-exportable certs.
• For imported certificates, re-importing the same certificate body and private key into Region B preserves the exact same public key and fingerprint. Leaf-level pins continue to work. If you import a replacement certificate from your CA (e.g., because the private key was lost), the public key differs and pins must be updated.
• For private certificates issued by AWS Private CA, if you create a new CA in Region B and issue new certificates, both the leaf certificate and the CA certificate will differ. Clients pinning to the leaf public key, the CA public key, or the CA certificate fingerprint will all need to be updated. If you export and re-import from Region A, the leaf certificate material is preserved, but clients pinning to the issuing CA will still reference the Region A CA. The safest approach is to pin to the root CA's public key rather than intermediate or leaf keys, especially if you use a subordinate CA in Region B under the same root.

AWS recommends against certificate pinning for ACM-issued certificates because ACM can rotate the issuing intermediate CA at any time. If pinning is required, pin to the root CA rather than the leaf or intermediate. Before migrating, audit your applications and clients for any pinning configurations and plan pin updates.

CloudFront Certificates

CloudFront requires certificates in us-east-1 regardless of where your origin is. If you are migrating resources out of a region but your CloudFront distribution's certificate is already in us-east-1, you do not need to migrate that certificate. It stays in us-east-1.

ACM Service Quotas in the Target Region

ACM service quotas are per-region, per-account. Before migrating, verify that the target region (Region B) has sufficient quota to accommodate the new certificates. Key quotas to check:

• ACM certificates per region: 2,500 (default). Expired and revoked certificates count toward this total. Certificates signed by AWS Private CA do not count.
• ACM certificates per year (last 365 days): 5,000 (default). This is twice the certificate quota. You can request up to 5,000 per year but only hold 2,500 at any time.
• Imported certificates per region: 2,500 (default). Separate quota from ACM-issued certificates.
• Domain names per certificate: 10 (default, adjustable up to 100). If your source certificates have more than 10 domain names, confirm the same quota applies in Region B.
• Private CAs per region: 200 (default). Deleted CAs count toward this quota until their restoration period ends.

If you need higher quotas in Region B, request increases via the AWS Support Center before starting the migration. Reference: https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html

Post-Migration Checklist

• All Region A certificates have equivalent certificates in Region B
• All Region B certificates are in ISSUED status
• DNS validation CNAME records are in place for auto-renewal in Region B
• Services in Region B reference the correct Region B certificate ARNs
• Email-validated certificates have been manually approved
• Imported certificates have been re-imported with valid private keys
• Private CA certificates have been re-issued from a Region B CA
• CloudFront distributions confirmed to still use us-east-1 certificates (no migration needed)
• Monitoring/alerting configured for certificate expiration in Region B
• ACM service quotas in Region B verified and increased if needed (certificates, imported certificates, domain names per cert)

AWS Key Management Service (AWS KMS) Migration Guide

Key considerations:

• AWS KMS keys themselves cannot be migrated to another region - ciphertexts generated from an AWS KMS key can only be decrypted in the source region and re-encrypted with a key in a target region.
• Associated resources encrypted with an AWS KMS key (Secrets Manager Secret, S3 object, EBS volume etc...) residing in affected regions must be decrypted using the AWS KMS keys in that region, then re-encrypted with an AWS KMS key in the target region to function in the target region. This is only possible if the AWS KMS service is accessible and can handle cryptographic operations in the source region.
• Multi-region keys may sound like the DR solution to solve this, but this is not the case for the majority use-cases. Multi-region keys can be replicated to other target regions, but will not support the use of integrated resources encrypted with an AWS KMS key from an affected region - this is only useful for client-side encrypted ciphertexts and DynamoDB global tables
  • AWS services that integrate with AWS KMS for encryption at rest or digital signatures currently treat multi-Region keys as though they were single-Region keys.
• Symmetric AWS KMS keys with imported key material are not interoperable, even if the exact same external key material is imported into multiple AWS KMS keys.
  • For asymmetric keys and HMAC keys, importing key material creates compatible and interoperable keys that operate within and outside of AWS. These keys, however, cannot be used with integrated services. This is only relevant if a customer is using imported asymmetric keys for client-side encryption.

Moving Encrypted Resources Between Regions

• To migrate a resource protected by an AWS KMS key to another region, we need to follow the idea that integrated services cannot make cross-region calls to decrypt a data key. They also cannot rely on multi-region keys, if the underlying resource was encrypted in another region.
• For all integrated resources, the following approach enables resource usage in the target region:
  • Decrypt the resource using the key in the source region
  • Encrypt the resource using a new key in the destination region
• Each service and integrated resource will have its own method for implementing this
  • e.g. EBS allows you to specify a target region and AWS KMS key ARN with the ‘DestinationRegion’ and ‘KmsKeyId’ request parameters in the CopySnapshot API.
  • Many services will have their own method outlined within this document. Please refer to the section in this document regarding your service for information specific to the integrated resources of that service.

Required IAM policy for cross-region snapshot copy:

{
  "Effect": "Allow",
  "Action": ["ec2:CopySnapshot", "ec2:DescribeSnapshots"],
  "Resource": [
    "arn:aws:ec2:<source-region>:<account-id>:snapshot/*",
    "arn:aws:ec2:<target-region>:<account-id>:snapshot/*"
  ]
}

Moving Encrypted Data Between Regions

• If a customer has used a multi-region key to encrypt data from a client-side encryption operation, they can replicate their key to another region and use the key in that region to perform client-side decryption on that data. In this case, the decryption of a ciphertext and re-encryption with an AWS KMS key in the target region is not necessary. Customers can follow our documentation to replicate a key to a new region within the same partition here.
• For data that was encrypted through client-side encryption methods with a single-region key:
  • If data was encrypted directly using the Encrypt API or you have an encrypted data key returned from the GenerateDataKey/GenerateDataKeyWithoutPlaintext/GenerateDataKeyPair/GenerateDataKeyPairWithoutPlaintext APIs, you can simply decrypt that data/data key with the Decrypt API and use it for any required purposes, or use the Encrypt API, using a valid key in your destination region to verify that your data is operational and reliant on only your destination region.
  • The ReEncrypt API cannot be used to re-encrypt data with keys in different regions.
  • Decrypt - Decrypt your data/data key encrypted direct with a key in the affected region:

Customer Responsibility — Data Protection: Customers are responsible for protecting sensitive data in CLI operations. The CLI examples below show plaintext data in command arguments for clarity. In production environments, use file-based input (fileb://) with restricted permissions (chmod 600). Clear shell history after operations involving sensitive data.

aws kms decrypt \
--key-id arn:aws:kms:<SOURCE_REGION>:<ACCOUNT_ID>:key/a1234567-3bf1-4a30-a83b-00b87d7t876e \ 
--ciphertext-blob fileb://Base64EncodedCiphertext \
--encryption-context KeyName1=String1,Keyname2=String2
--query 'Plaintext'

* Encrypt - Encrypt your plaintext data with a key in a new region:

aws kms encrypt \
--key-id arn:aws:kms:<DESTINATION_REGION>:<ACCOUNT_ID>:key/98fg76hj54-3bf1-4a30-a83b-aab123cd \
--plaintext fileb://Plaintext \
encryption-context KeyName1=String1,Keyname2=String2 \
--query 'CiphertextBlob'

• Encryption SDK
  • Customers may also use the Encryption SDK to encrypt client-side data, relying on the ESDK to implement recommended data key management practices and other useful features. To encrypt their data with a new key through the encryption SDK, customers can encrypt their ciphertexts using their existing key. The keyring that decrypts the encrypted message must be compatible with the one used to encrypt the message. One of its wrapping keys must be able to decrypt an encrypted data key in the encrypted message.
  • They can then create a new Keyring, with a key residing in their target region and Encrypt their data using that new Keyring. The ciphertexts produced with this keyring can then be used to make same-region calls for Encryption SDK encrypted data in the customer’s target region, allowing their workloads to function as reliant on only that region, with single-region latency.
  • Python examples:
    • Decrypt existing ciphertexts:

Customer Responsibility — Code Security: These Python examples are for reference. Production implementations must include try/except blocks around AWS KMS and encryption operations, validate source_kms_key_id format before use, and avoid hardcoding region names.

def decrypt_with_keyring(
    source_kms_key_id: str
):
    # 1. Instantiate the encryption SDK client.
    client = aws_encryption_sdk.EncryptionSDKClient(
        commitment_policy=CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT
    )
    # 2. Create a boto3 client for KMS.
    kms_client = boto3.client('kms', region_name="me-south-1")
    
    # 3. Create your keyring
    mat_prov: AwsCryptographicMaterialProviders = AwsCryptographicMaterialProviders(
        config=MaterialProvidersConfig()
    )

    keyring_input: CreateAwsKmsKeyringInput = CreateAwsKmsKeyringInput(
        kms_key_id=source_kms_key_id,
        kms_client=kms_client
    )

    kms_keyring: IKeyring = mat_prov.create_aws_kms_keyring(
        input=keyring_input
    )
    
    # 4. Customers will need to retrieve their ciphertext wheverer it is stored
    # TODO - load cipertext
    
    # 5. Decrypt data encrypted in the source region
    plaintext_bytes, _ = client.decrypt(
        source=ciphertext,
        keyring=kms_keyring,
        # Provide the encryption context that was supplied to the encrypt method
        encryption_context=encryption_context,
    )

    * Encrypt with target region key:

def encrypt_with_target_keyring(
    dest_kms_key_id: str
):
    # 1. Instantiate the encryption SDK client.
    client = aws_encryption_sdk.EncryptionSDKClient(
        commitment_policy=CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT
    )
    # 2. Create a boto3 client for KMS.
    dest_kms_client = boto3.client('kms', region_name="<INSERT_TARGET_REGION>")
    
    # 3. Create your keyring
    dest_mat_prov: AwsCryptographicMaterialProviders = AwsCryptographicMaterialProviders(
        config=MaterialProvidersConfig()
    )

    dest_keyring_input: CreateAwsKmsKeyringInput = CreateAwsKmsKeyringInput(
        kms_key_id=dest_kms_key_id,
        kms_client=dest_kms_client
    )

    dest_kms_keyring: IKeyring = dest_mat_prov.create_aws_kms_keyring(
        input=dest_keyring_input
    )
    
    # 4. Customers will need to retrieve the data to encrypt
    # TODO - load plaintext
    
    # 5. Encrypt data in the destination region
    ciphertext, _ = client.encrypt(
        source=EXAMPLE_DATA,
        keyring=dest_kms_keyring,
        # Provide new or the same encryption context and store alongside ciphertext
        encryption_context=encryption_context
    )

    * Customers are responsible for handling their own data and compliance with their data handling standards. AWS is responsible for the security of the AWS KMS service infrastructure and the encryption of key material at rest.

AWS IAM Identity Center Migration Guide

AWS IAM Identity Center

Key Considerations:

• AWS IAM Identity Center is a regional service. The organization instance of AWS IAM Identity Center is deployed by customers in a single region of choice for their AWS Organization. AWS IAM Identity Center is built from highly available AWS infrastructure and uses an Availability Zone architecture designed to minimize single points of failure.
• In February 2026, multi-region replicationsupport for AWS IAM Identity Center was launched. Multi-Region support is available only in commercial Regions enabled by default in your AWS account and presently possible where identity source is an external identity provider. Organization instances set up in an Opt-in Regionas primary region, are not currently supported.
• Thus, if you’d like to have access to AWS Management console through AWS IAM Identity Center where an opt-in Region is the primary Region, then consider switching AWS Regions if your regulatory and data residency requirements permit.
• If your AWS IAM Identity Center is deployed in commercial Regions enabled by default, consider enabling multi-region replication.

Switching primary Region of IAM Identity Center to target region:

You can switch your IAM Identity Center Region only by deleting your current IAM Identity Center instance and creating an instance in another Region. You need to recreate users, groups, permission sets, applications, and assignments in the new IAM Identity Center instance. You can use the IAM Identity Center account and application assignment APIs to get a snapshot of your configuration and then use that snapshot to rebuild your configuration in a new Region. Refer to this blog and sample scripts on Github here for detailed guidance on how to back up permission sets and application assignments. Additionally, refer to this blog to generate a dataset that contains details about permission set (be careful that this might cause increase in costs). Store these backup configurations or verify that they are fully documented as infrastructure as code (IAC).

If you already enabled an AWS managed application with your existing IAM Identity Center instance, disable the application before deleting IAM Identity Center. For instructions on disabling AWS managed applications, see Disabling an AWS managed application.

Temporary Alternative: Accessing AWS Management console through external IDP when multi-region support is not enabled or unavailable (opt-in region):

Set upemergency access to the AWS Management console through direct federation to an emergency operations account. This configuration works when IAM Identity Center is unavailable, but the IAM data plane and your external identity provider (IdP) are available. To configure emergency access, you must complete the following tasks:

1. Create an emergency operations account in your organization in AWS Organizations. This account will become your emergency operations account.
2. Connect your IdP to the emergency operations account by using SAML 2.0-based federation.
3. In the emergency operations account, create a role for third-party identity provider federation. Also, create an emergency operations role in each of your workload accounts, with your required permissions.
4. Delegate access to your workload accounts for the IAM role that you created in the emergency operations account. To authorize access to your emergency operations account, create an emergency operations group in your IdP, with no members.
5. Configure the emergency operations group in your IdP to use the emergency operations role by creating a rule in your IdP that enables SAML 2.0 federated access to the AWS Management Console.

During normal operations, no one has access to the emergency operations account because the emergency operations group in your customer’s IdP has no members. In the event of an IAM Identity Center disruption, customers use their IdP to add trusted users to the emergency operations group in their IdP. These users can then sign in to the IdP, navigate to the AWS Management Console, and assume the emergency operations role in the emergency operations account. From there, these users can switch roles to the emergency access role in the workload accounts where they need to perform operations work.

Multi-region replication process in commercial Regions enabled by default:

To replicate IAM IDC to another region (when primary region is a Region enabled by default), first verify all the pre-requisites here are met. Then:

1. Step 1: Create a replica key in the additional Region
2. Step 2: Add the Region in IAM Identity Center
3. Step 3: Update external IdP setup
4. Step 4: Confirm firewall and gateway allow-lists
5. Step 5: Provide information to your users

The above is listed in detail on documentation here. If external IDPs do not support multiple assertion consumer service (ACS) URLs in their IAM Identity Center application, then work with external IDPs to enable this support. If that is not possible, then in the event of a disruption occurs in primary region manually update the ACS URL in the external IdP with the additional Region's ACS URL.

The duration of the initial replication to an additional Region depends on the amount of data in your IAM Identity Center instance.

AWS CLI users create AWS CLI profiles for additional Regions for each of the profiles they have for the primary Region. Then, they can switch to that profile if there is a service disruption in the primary Region.

AWS managed applications: Only those applications that support IAM Identity Center configured with a customer managed AWS KMS key and supports deployment in additional regions of IAM Identity Center can be used in multi-region replication. Use document Deploying and managing applications across multiple AWS Regions for guidance.

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

Note: The following guidance applies only if you have configured regional endpoints in your IAM identity federation or STS configuration. This does not apply to all customers.

AWS Identity and Access Management (AWS IAM) - Console Login - Identity Federation

Note: The endpoint signin.aws.amazon.com is the us-east-1 regional SAML sign-in endpoint used for federated authentication, allowing users to access AWS services through single sign-on (SSO) with external identity providers [1]. The AWS General Reference SAML sign-in endpoints lists AWS regional endpoints available globally. The format of the endpoint URL is as follows, where <region-code> is the AWS Region of the endpoint: https://<region-code>.signin.aws.amazon.com/saml. All regional endpoints have a region-code value in the DNS name, except for us-east-1. The endpoint for us-east-1 is signin.aws.amazon.com—this endpoint does not contain a Region code and is not a global endpoint.

Key Considerations:

• For SAML 2.0 Federation, when customers workloads are not deployed in us-east-1, it is recommended to use Regional endpoints. It is recommended to use regional endpoints instead of the us-east-1 endpoint to improve federation resiliency, as having only the us-east-1 endpoint configured means customers won't be able to federate into AWS if that single endpoint becomes unavailable
• If a customer is using a regional endpoint and service in that region becomes disrupted, they can use a regional endpoint for a region that is operating as expected to access the AWS console through direct SAML federation or use the signing.aws.amazon.com endpoint as the us-east-1 regional SAML sign-in endpoint.
• Additionally, customers can configure federation with multi-Region SAML endpoints to further increase resiliency for federated access into customers AWS environment. As outlined in the linked documentation, in an event where a customer is using a regional endpoint and service in that region becomes disrupted, the customer’s external IdP can be adjusted to use another regional endpoint which is functioning as expected. Customers should migrate their endpoint usage to an endpoint that is functioning as expected. The process for engaging this migration will differ greatly based on the IdP being used for federation. Customers should consult their external IdP for guidance on implementing this.

Regional Disruption:

• In a scenario where a customer cannot access their AWS account through Identity federation, due to unexpected behavior with the configured regional endpoint, they must prioritize regaining access to their environment, starting with the management account of their AWS Organization. Customers logging into the AWS management console using their root credentials utilize the AWS Sign-in endpoint in the us-east-1 Region exclusively signin.aws.amazon.com, with no alternative regional endpoints available regardless of the user's geographic location. AWS strongly recommends customers not to use the root user for everyday tasks and instead create an administrative user in IAM Identity Center or use IAM users and roles with temporary credentials. However, in the event where a customer has been relying on a regional endpoint for federation and has lost access to the account, through all other means, the root user may be used temporarily as a last resort to regain access and reconfigure Identity federation resources, allowing for the continued use of role-based access. Immediately rotate root credentials and re-establish role-based access after recovery. Once access has been regained to the management account, they can typically use the OrganizationAccountAccessRole to access member accounts and make any necessary adjustments to their Identity resources.

AWS Security Token Service (AWS STS)

Key Considerations:

• In Regions that are 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 a single AWS Region, US East (N. Virginia).
• It is advised to use Regional AWS STS endpoint to reduce latency or provide additional redundancy for your applications.

Recommendations:

• If customers are using Regional endpoints and are unable to connect to STS endpoint of that region due to region disruption, then they will need to have their workloads/applications utilize another STS regional endpoint - mostly of a geographical location that is distant from the primary region. That is, customers should have their workloads/applications configured to failover to secondary regional AWS STS endpoint in case of a primary region failure. This would work for those who can have multi-region resiliency and are not confined to operate within a specific geographical location per their regulations.
• If using regional endpoint of a opt-in region (with no regulatory restrictions of operating in a specific geographical location), customers can configure their workloads/applications to make requests to the AWS STS global endpoint, as those will continue to be served in US East (N. Virginia) Region.

Configuration Migration

• Customers have the following options to set the Regional AWS STS endpoint if they are using AWS CLI v1 or if their AWS SDK version doesn’t default to a Regional STS endpoint:
  • Option 1 — Use a shared AWS configuration file setting The configuration file is located at ~/.aws/config on Linux or macOS, and at C:\Users\USERNAME\.aws\config on Windows. To use the Regional endpoint, customers must add the sts_regional_endpoints parameter. The following example shows how customers can set the value for the Regional AWS STS endpoint in the US East (Ohio) Region (us-east-2), by using the default profile in the AWS configuration file: [default] region = us-east-2 sts_regional_endpoints = regional The valid values for the AWS STS endpoint parameter (sts_regional_endpoints) are:
    • legacy (default) — Uses the global (legacy) AWS STS endpoint, sts.amazonaws.com.
    • regional — Uses the AWS STS endpoint for the currently configured Region.
  • **Option 2 — Use environment variables **Environment variables provide another way to specify configuration options. They are global and affect calls to AWS services. Most SDKs support environment variables. When customers set the environment variable, the SDK uses that value until the end of a shell session or until customers set the variable to a different value. To make the variables persist across future sessions, customers must set them in their shell’s startup script. For a list of AWS SDKs that support environment variable settings for Regional AWS STS endpoints, see Compatibility with AWS SDKs.
  • Option 3 — Construct an endpoint URL Customers can manually construct an endpoint URL for a specific Regional AWS STS endpoint. The following example shows how customers can configure the STS client with AWS SDK for Python (Boto3) to use a Regional AWS STS endpoint by setting a specific endpoint URL: import boto3 sts_client = boto3.client('sts', region_name='us-east-2', endpoint_url='[https://sts.us-east-2.amazonaws.com](https://sts.us-east-2.amazonaws.com/)')
• Finally, if you have AWS Trusted Advisor enabled, review the output of the “STS global endpoint” check to identify and monitor the use of global (legacy) STS endpoint sts.amazonaws.com in your AWS environment from workloads running in AWS Regions other than US East (N. Virginia). The Trusted Advisor check monitors API calls to the global STS endpoint, identifies which AWS Regions are making these calls, and flags usage of the global STS endpoint. This check is available to customers across AWS Support Plans and is available at no additional cost.

Migration Checklist

[] If using a regional federation endpoint - Reconfigure IdP resources and identity resources with a trust relationship to the target endpoint
[] Reconfigure access configuration to utilize the target region endpoint
[] Check ~/./aws/config file for regional endpoint configuration and change if necessary
[] Check `**AWS_DEFAULT_REGION** and **AWS_REGION** environment variables and change if necessary
[] Review SDK Client configuration constructor methods for regional endpoint configuration and change if necessary

IAM Access Analyzer

IAM Access Analyzer is a feature of AWS IAM.

Key Considerations:

• No migration path. IAM Access Analyzer is a regional service — analyzers are scoped to a specific region and analyze resources within that region. There's no built-in cross-region replication or migration mechanism like some other services.
• The different types of IAM Access Analyzersare as below:
  • “Unused Access” analyzer analyze IAM users and roles, which are global IAM resources (not regional). So it only needs to be created in a single region to get coverage across the entire account or organization.
  • “External Access” analyzer finds resources shared with entities outside your zone of trust (another account, public, etc.). This is regional and needs one per region to determine external access per region
  • “Internal access” analyzer determines which principals within your organization/account have access to specific resources (S3, RDS snapshots, DynamoDB). This is regional and needs one per region to determine internal access per region
• IAM Access Analyzer also offers policy checks and policy generation. The former is a pure logical check and is dependent on actions taken to create/modify a policy. The latter is dependent on reading information from CloudTrail logs. In case the CloudTrail logs delivery pipeline in the region is disrupted, then that would impact the freshness of the activity data used to generate policies - which would further impact the accuracy of the policy generated based on the API activity of an impacted region.

Recommendations:

Since analyzers don't have state that transfers (findings are regenerated from current resource policies), "migration" is really just recreating analyzer configuration in the target region:

1. Create a new analyzer in the target region via Console, CLI, or IaC. The AWSServiceRoleForAccessAnalyzer service-linked role is created automatically.

bash
aws accessanalyzer create-analyzer \
--analyzer-name my-analyzer \
--type ACCOUNT \
--region <REGION>

For org-level analyzers, use --type ORGANIZATION (requires delegated admin or management account)

1. Recreate archive rules — any rules that had to suppress/archive findings need to be recreated in the new region. These aren't automatically copied.
2. Recreate EventBridge rules — if there are automation triggered by Access Analyzer findings (e.g., SNS notifications, Lambda remediation), those EventBridge rules are also regional and need to be set up in the new region.
3. IaC is the cleanest path — if using CloudFormation or CDK, then one can deploy the same template/stack to the new region. This is the recommended approach for repeatability.
4. Findings will regenerate — after creating the analyzer, it will scan and generate fresh findings within a few minutes to hours. No need to "migrate" findings.

AWS WAF Migration Guide

Method 1: Copy AWS WAF JSON Configuration

Note: This method does not copy related IPSets, Regex pattern sets, or Rule groups. Create these dependencies in the target region first with the same names.

Export WebACL Configuration:

Using AWS Console:

1. Navigate to AWS WAF Console
2. Select source WebACL
3. Download JSON configuration

Using AWS CLI:

aws wafv2 get-web-acl \
  --name YOUR_WEBACL_NAME \
  --scope YOUR_SCOPE \
  --region YOUR_SOURCE_REGION > waf_config.json

Create WebACL in Target Region

1. Navigate to AWS WAF Console in target region
2. Create new WebACL
3. Use JSON from previous step

Method 2: Use AWS WAF WebACL Cross-Region Copy Script

For complex configurations with many dependencies, use the automated script wafv2_clone_v5.py

Usage:

python3 wafv2_clone.py [Source Region] [Source Scope] [Target Region] [Target Scope]

Examples:

python3 wafv2_clone.py me-central-1 REGIONAL eu-west-1 REGIONAL
python3 wafv2_clone.py ap-southeast-1 REGIONAL us-east-1 CLOUDFRONT

Application Load Balancer (ALB) / Network Load Balancer (NLB)

Prerequisites

Before creating load balancers in the target region:

• VPC, subnets, and route tables must exist
• Security groups must be created (manually replicate from source region)
• SSL certificates must exist in target region (request via AWS Certificate Manager)

Method 1: Manual Creation

Create ALB

• Create Application Load Balancer Documentation

Create NLB

• Create Network Load Balancer Documentation

Register Targets

After creating the load balancer, register your target instances or IP addresses.

Method 2: Automated Analysis and Creation

Use automation tools to analyze source ALB configuration and create an identical ALB in the target region.

Required Information:

• Source ALB name and region
• Target region
• Target VPC ID
• Target subnet IDs
• Target security group IDs
• Target SSL certificate ARNs

Configuration to Consider:

• ALB listeners and listener rules
• Target groups
• Health check settings
• Routing rules
• SSL/TLS policies

AWS WAF Clone Script Approach

To clone a full AWS WAF configuration between regions, execute in this order (each step builds ARN mappings used by subsequent steps):

1. Clone IPSets: aws wafv2 list-ip-sets → aws wafv2 get-ip-set → aws wafv2 create-ip-set in target region
2. Clone Regex pattern sets: aws wafv2 list-regex-pattern-sets → aws wafv2 get-regex-pattern-set → aws wafv2 create-regex-pattern-set in target region
3. Clone Rule groups: aws wafv2 list-rule-groups → aws wafv2 get-rule-group → replace source ARNs with target ARNs from steps 1-2 → aws wafv2 create-rule-group in target region
4. Clone WebACLs: aws wafv2 list-web-acls → aws wafv2 get-web-acl → replace source ARNs with target ARNs from steps 1-3 → aws wafv2 create-web-acl in target region

The ARN remapping is critical — every IPSet, Regex set, and Rule group referenced in a WebACL has a region-specific ARN that must be updated to the newly created resource's ARN in the target region.

Migration Priority and Security Improvements

When planning security service migrations, prioritize by risk:

ACM Certificates:

1. Public-facing certificates expiring within 30 days (HIGH — service outage risk)
2. Certificates used for mTLS between services (HIGH — authentication failure risk)
3. Internal certificates with long validity (MEDIUM)

• Measurable improvement: Zero expired certificates in target region; all certificates validated and associated with resources before cutover

AWS KMS:

1. Production data with compliance requirements (HIGH — regulatory risk)
2. Cross-region encrypted snapshots and backups (HIGH — data recovery risk)
3. Development/test encryption keys (LOW)

• Measurable improvement: All encrypted resources accessible in target region; key policies follow least-privilege; no orphaned grants

AWS IAM Identity Center:

1. Enable multi-region replication if in commercial regions with external IdP (preferred approach)
2. Recreate configuration manually if replication is unavailable

• Measurable improvement: All users can authenticate in target region; MFA enforcement maintained; no permission escalation during migration

IAM & STS:

1. Production workloads with high authentication volume (HIGH — latency impact)
2. Multi-region federation configurations (MEDIUM)

• Measurable improvement: Regional STS endpoint configured; failover tested; no authentication disruption during region switch

AWS WAF:

1. WebACLs protecting public-facing APIs with PII/payment data (HIGH — data exposure risk)
2. WebACLs with custom rules for known attack patterns (MEDIUM)
3. WebACLs with only managed rule groups (LOW — quick to recreate)

• Measurable improvement: All WebACL rules active in target region; no gap in protection during migration; rule counts match source

Data Security Requirements for Migration

• Data classification: Identify which resources contain regulated data (PII, PHI, PCI) before migration. Apply encryption and access controls matching or exceeding the source region configuration.
• Encryption in transit: All data transfers during migration use TLS/HTTPS (AWS CLI default). For certificate exports, use the passphrase-encrypted export API.
• Encryption at rest: Maintain encryption on all migrated resources. Do not downgrade from KMS-encrypted to unencrypted during migration.
• Access logging: Enable AWS CloudTrail in the target region before starting migration to capture all API activity.