AWS prescriptive-guidance documentation change
Summary
Updated documentation with improved resource specificity, corrected terminology, grammatical fixes, added AWS Knowledge Center references, and adjusted section headers. Changes include clarifications about cross-account resource migration processes for various AWS services.
Security assessment
The changes primarily involve documentation improvements, typo fixes, and added references without addressing specific security vulnerabilities. While some sections mention security practices (like KMS key limitations or S3 ACL changes), these are existing security considerations rather than new security content or vulnerability fixes.
Diff
diff --git a/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/resource-migration.md b/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/resource-migration.md index 0a4b8e3ac..59e12629a 100644 --- a//prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/resource-migration.md +++ b//prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/resource-migration.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Transitioning to multiple AWS accounts](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Transitioning to multiple AWS accounts](introduction.html) @@ -7 +7 @@ -AWS AppConfigAWS Certificate ManagerAmazon CloudFrontAWS CodeArtifactAmazon DynamoDBAmazon EBSAmazon EC2Amazon ECRAmazon EFSAmazon ElastiCache (Redis OSS)AWS Elastic BeanstalkElastic IP addressesAWS LambdaAmazon LightsailAmazon NeptuneAmazon OpenSearch ServiceAmazon RDSAmazon RedshiftAmazon Route 53Amazon S3Amazon SageMaker AIAWS WAF +AWS AppConfig configurations and environmentsAWS Certificate Manager certificatesAmazon CloudFront distributionsAWS CodeArtifact domains and repositoriesAmazon DynamoDB tablesAmazon EBS volumesAmazon EC2 instances or AMIsAmazon ECR registriesAmazon EFS file systemsAmazon ElastiCache (Redis OSS) clustersAWS Elastic Beanstalk environmentsElastic IP addressesAWS Lambda layersAmazon LightsailAmazon Neptune clustersAmazon OpenSearch Service domainsAmazon RDS snapshotsAmazon Redshift clustersAmazon Route 53 domains and hosted zonesAmazon S3 bucketsAmazon SageMaker modelsAWS WAF web ACLs @@ -9 +9 @@ AWS AppConfigAWS Certificate ManagerAmazon CloudFrontAWS CodeArtifactAmazon Dyna -# Resource replication or migration between AWS accounts +# Resource migration @@ -11 +11 @@ AWS AppConfigAWS Certificate ManagerAmazon CloudFrontAWS CodeArtifactAmazon Dyna -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. +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. @@ -15 +15 @@ This section focuses on strategies for replicating data between AWS accounts. Yo -###### This section reviews options for migrating the following data resources: +This section reviews options for migrating the following data resources: @@ -43 +43 @@ This section focuses on strategies for replicating data between AWS accounts. Yo - * Amazon Lightsail instances + * Amazon Lightsail @@ -57 +57 @@ This section focuses on strategies for replicating data between AWS accounts. Yo - * Amazon SageMaker AI models + * Amazon SageMaker Runtime models @@ -66 +66 @@ This section focuses on strategies for replicating data between AWS accounts. Yo -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](https://aws.amazon.com/blogs/mt/cross-account-configuration-with-aws-appconfig/) (AWS blog post). +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](https://aws.amazon.com/blogs/mt/cross-account-configuration-with-aws-appconfig/) (AWS blog post). @@ -70 +70 @@ AWS AppConfig doesn’t support directly copying its configuration to another AW -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. +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 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 Route 53 hosted zone or DNS provider within 72 hours for the certificate to be properly validated. @@ -74 +74 @@ You can’t directly export an AWS Certificate Manager (ACM) certificate from on -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](https://repost.aws/knowledge-center/resolve-cnamealreadyexists-error) (AWS Knowledge Center). +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](https://repost.aws/knowledge-center/resolve-cnamealreadyexists-error) (AWS Knowledge Center). @@ -82 +82 @@ Although an organization can have multiple domains, the recommendation is to hav -You can use one of the following services to migrate an Amazon DynamoDB table to a different AWS account: +You can use one of the following services to migrate a Amazon DynamoDB table to a different AWS account: @@ -86 +86 @@ You can use one of the following services to migrate an Amazon DynamoDB table to - * DynamoDB import and export to Amazon S3 + * Amazon DynamoDB import and export to Amazon S3 @@ -105 +105 @@ You can take a snapshot of an existing Amazon Elastic Block Store (Amazon EBS) v -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. +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](https://repost.aws/knowledge-center/account-transfer-ec2-instance) (AWS Knowledge Center). @@ -131 +131 @@ By default, an AWS Lambda layer that you create is private to your AWS account. -## Amazon Lightsail instances +## Amazon Lightsail @@ -133 +133 @@ By default, an AWS Lambda layer that you create is private to your AWS account. -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](https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-exporting-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](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) (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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html#liw-quickly-launch-instance) (Amazon EC2 documentation). +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](https://aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-exporting-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](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) (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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html#liw-quickly-launch-instance) (Amazon EC2 documentation). @@ -151 +151 @@ For Amazon Relational Database Service (Amazon RDS), you can share manual snapsh -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. +You can also use AWS Database Migration Service (AWS DMSs) 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. @@ -171 +171 @@ You can use Amazon Simple Storage Service (Amazon S3) Same-Region Replication to - * 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](https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) (AWS blog post). + * 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](https://aws.amazon.com/blogs/aws/heads-up-amazon-s3-security-changes-are-coming-in-april-of-2023/) (AWS blog post) @@ -178 +178 @@ You can use Amazon Simple Storage Service (Amazon S3) Same-Region Replication to -## Amazon SageMaker AI models +## Amazon SageMaker models @@ -180 +180 @@ You can use Amazon Simple Storage Service (Amazon S3) Same-Region Replication to -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](https://repost.aws/knowledge-center/sagemaker-cross-account-model) (AWS Knowledge Center). +Amazon SageMaker 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 model to a different AWS account](https://repost.aws/knowledge-center/sagemaker-cross-account-model) (AWS Knowledge Center).