Resource replication or migration between AWS accounts - AWS Prescriptive Guidance

Resource replication or migration between AWS accounts

After migrating from a single AWS account to multi-account architecture, it’s common to have production and non-production workloads running in the preexisting account. Migrating these resources to dedicated production and non-production accounts or organizational units helps you manage access and networking for these workloads. The following are some options for migrating common AWS resources into another AWS account.

This section focuses on strategies for replicating data between AWS accounts. You should strive to have your workloads be as stateless as possible to avoid needing to replicate compute resources between accounts. It is also beneficial to manage your resources through infrastructure as code (IaC) so that you can reprovision an environment in a separate AWS account.

AWS AppConfig configurations and environments

AWS AppConfig doesn’t support directly copying its configuration to another AWS account. However, it is a best practice to manage the AWS AppConfig configurations and environments separately from the AWS accounts that are hosting the environments. For more information, see Cross-account configuration with AWS AppConfig (AWS blog post).

AWS Certificate Manager certificates

You can’t directly export an AWS Certificate Manager (ACM) certificate from one account to another because the AWS Key Management Service (AWS KMS) key used to encrypt the certificate’s private key is unique to each AWS Region and account. However, you can simultaneously provision multiple certificates with the same domain name across multiple accounts and Regions. ACM supports validating domain ownership by using DNS (recommended) or email. When you use DNS validation and create a new certificate, ACM generates a unique CNAME record for every domain on the certificate. The CNAME record is unique for each account, and it must be added to the Amazon Route 53 hosted zone or DNS provider within 72 hours for the certificate to be properly validated.

Amazon CloudFront distributions

Amazon CloudFront doesn’t support migration of distributions from one AWS account to another AWS account. However, CloudFront does support the migration of an alternate domain name, also known as a CNAME, from one distribution to another. For more information, see How do I resolve the CNAMEAlreadyExists error when I set up a CNAME alias for my CloudFront distribution (AWS Knowledge Center).

AWS CodeArtifact domains and repositories

Although an organization can have multiple domains, the recommendation is to have a single production domain that contains all published artifacts. This helps development teams find and share packages across an organization. The AWS account that owns the domain can be different from the account that owns any repositories associated to the domain. You can copy packages between repositories, but they must belong to the same domain. For more information, see Copy packages between repositories (CodeArtifact documentation).

Amazon DynamoDB tables

You can use one of the following services to migrate an Amazon DynamoDB table to a different AWS account:

  • AWS Backup

  • DynamoDB import and export to Amazon S3

  • Amazon S3 and AWS Glue

  • AWS Data Pipeline

  • Amazon EMR

For more information, see How can I migrate my Amazon DynamoDB tables from one AWS account to another (AWS Knowledge Center).

Amazon EBS volumes

You can take a snapshot of an existing Amazon Elastic Block Store (Amazon EBS) volume, share the snapshot with the target account, and then create a copy of the volume in the target account. This effectively migrates the volume from one account to another. For more information, see How can I share an encrypted Amazon EBS snapshot or volume with another AWS account (AWS Knowledge Center).

Amazon EC2 instances or AMIs

It is not possible to directly transfer existing Amazon Elastic Compute Cloud (Amazon EC2) instances or Amazon Machine Images (AMIs) to a different AWS account. Instead, you can create a custom AMI in the source account, share the AMI with the target account, launch a new EC2 instance from the shared AMI in the target account, then deregister the shared AMI. For more information, see How do I transfer an Amazon EC2 instance or AMI to a different AWS account (AWS Knowledge Center).

Amazon ECR registries

Amazon Elastic Container Registry (Amazon ECR) supports both cross-account and cross-Region replication. You configure replication on the source registry and a registry permissions policy on the target registry. For more information, see Configuring cross-account replication (Amazon ECR documentation) and Allow the root user of a source account to replicate all repositories (Amazon ECR documentation).

Amazon EFS file systems

Amazon Elastic File System (Amazon EFS) supports cross-account and cross-Region replication. You can configure replication on the source file system. For more information, see Replicating file systems (Amazon EFS documentation).

Amazon ElastiCache (Redis OSS) clusters

You can use a backup of an Amazon ElastiCache (Redis OSS) database cluster to migrate it to a different account. For more information, see What are best practices for migrating my ElastiCache (Redis OSS) cluster (AWS Knowledge Center).

AWS Elastic Beanstalk environments

For AWS Elastic Beanstalk, you can use saved configurations (Elastic Beanstalk documentation) to migrate an environment to a different AWS account. For more information, see How do I migrate my Elastic Beanstalk environment from one AWS account to another AWS account (AWS Knowledge Center).

Elastic IP addresses

You can transfer Elastic IP addresses between AWS accounts that are in the same AWS Region. For more information, see Transfer Elastic IP addresses (Amazon VPC documentation).

AWS Lambda layers

By default, an AWS Lambda layer that you create is private to your AWS account. However, you can optionally share the layer with other AWS accounts or make it public. To copy a layer, you reprovision it in another AWS account. For more information, see Configuring layer permissions (Lambda documentation).

Amazon Lightsail instances

You can create a snapshot of an Amazon Lightsail instance and export the snapshot to an Amazon Machine Image (AMI) and an encrypted snapshot of an Amazon EBS volume. For more information, see Exporting Amazon Lightsail snapshots to Amazon EC2 (Lightsail documentation). By default, the snapshot is encrypted with an AWS managed key created in AWS Key Management Service (AWS KMS). However, this type of KMS key cannot be shared between AWS accounts. Instead, you manually encrypt a copy of the AMI with a customer managed key that can be used from the target account. For more information, see Allowing users in other accounts to use a KMS key (AWS KMS documentation). You can then share the copied AMI with the target AWS account and launch a new EC2 instance for Lightsail from the copied AMI. For more information, see Launch an instance using the new launch instance wizard (Amazon EC2 documentation).

Amazon Neptune clusters

You can copy an automated snapshot of the Amazon Neptune database cluster to another AWS account. For more information, see Copying a database (DB) cluster snapshot (Neptune documentation).

You can also share a manual snapshot with up to 20 AWS accounts that can directly restore a DB cluster from the snapshot. For more information, see Sharing a DB Cluster Snapshot (Neptune documentation).

Amazon OpenSearch Service domains

To copy data between Amazon OpenSearch Service domains, you can use Amazon S3 to create a snapshot of the source domain and then restore the snapshot into a target domain in a different AWS account. For more information, see How do I restore data from an Amazon OpenSearch Service domain in another AWS account (AWS Knowledge Center).

If you have network connectivity between the AWS accounts, you can also use the cross-cluster replication (OpenSearch Service documentation) feature in OpenSearch Service.

Amazon RDS snapshots

For Amazon Relational Database Service (Amazon RDS), you can share manual snapshots of DB instances or clusters with up to 20 AWS accounts. You can then restore the DB instance or DB cluster from the shared snapshot. For more information, see How do I share manual Amazon RDS DB snapshots or Aurora DB cluster snapshots with another AWS account (AWS Knowledge Center).

You can also use AWS Database Migration Service (AWS DMS) to configure continuous replication between database instances in different accounts. However, this requires network connectivity between the accounts, such as VPC peering or a transit gateway.

Amazon Redshift clusters

To migrate an Amazon Redshift cluster to a different AWS account, you create a manual snapshot of the cluster in the source account, share the snapshot with the target AWS account, and then restore the cluster from the snapshot. For more information, see How do I copy an Amazon Redshift provisioned cluster to a different AWS account (AWS Knowledge Center).

Amazon Route 53 domains and hosted zones

You can transfer Amazon Route 53 domains between AWS accounts. For more information, see Transfer a domain to a different AWS account (Route 53 documentation).

You can also migrate a Route 53 hosted zone to a different AWS account. For more information about when this is recommended or required, see Migrate a hosted zone to a different AWS account (Route 53 documentation). When you migrate a hosted zone, you recreate it in the target AWS account. For instructions, see Migrating a hosted zone to a different AWS account (Route 53 documentation).

Amazon S3 buckets

You can use Amazon Simple Storage Service (Amazon S3) Same-Region Replication to copy objects between S3 buckets in the same AWS Region. For more information, see Replicating objects (Amazon S3 documentation). Note the following:

  • Change the replica ownership to the AWS account that owns the destination bucket. For instructions, see Changing the replica owner (Amazon S3 documentation).

  • Update the bucket owner conditions to reflect the AWS account ID of the target bucket. For more information, see Verifying bucket ownership with bucket owner condition (Amazon S3 documentation).

  • As of April 2023, the Bucket owner enforced setting is enabled for newly created buckets, making bucket access control lists (ACLs) and object ACLs ineffective. For more information, see Amazon S3 Security Changes Are Coming (AWS blog post).

  • You can use S3 Batch Replication (Amazon S3 documentation) to replicate objects that existed before replication was configured.

Amazon SageMaker AI models

SageMaker AI models are stored in an Amazon S3 bucket during training. By granting access to the S3 bucket from the target account, you can deploy a model stored in the source account to the target account. For more information, see How can I deploy an Amazon SageMaker AI model to a different AWS account (AWS Knowledge Center).

AWS WAF web ACLs

AWS WAF web access control lists (web ACLs) must reside in the same account as the resources they are associated to, such as Amazon CloudFront distributions, Application Load Balancers, Amazon API Gateway REST APIs, and AWS AppSync GraphQL APIs. You can use AWS Firewall Manager to centrally manage AWS WAF web ACLs across your entire organization in AWS Organizations and across Regions. For more information, see Getting started with AWS Firewall Manager AWS WAF policies (Firewall Manager documentation).