# AMS Tools account (migrating workloads)
Your Multi-Account Landing Zone tools account (with VPC) helps accelerate migration efforts, increases your security position, reduces cost and complexity, and standardizes your usage pattern.
A tools account provides the following:
+ A well-defined boundary for access to replication instances for system integrators outside of your production workloads.
+ Enables you to create an isolated chamber to check a workload for malware, or unknown network routes, before placing it into an account with other workloads.
+ As a defined account setup, it provides faster time to onboard and get set up for migrating workloads.
+ Isolated network routes to secure traffic from on-premise -> CloudEndure -> Tools account -> AMS ingested image. Once an image has been ingested, you can share the image to the destination account via an AMS Management \$1 Advanced stack components \$1 AMI \$1 Share (ct-1eiczxw8ihc18) RFC.
High level architecture diagram:
![\[AWS account structure with Management, Shared Services, Network, Security, and Log Archive accounts.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/high-level-diagram_v1.png)
Use the Deployment \$1 Managed landing zone \$1 Management account \$1 Create tools account (with VPC) change type (ct-2j7q1hgf26x5c), to quickly deploy a tools account and instantiate a Workload Ingestion process within a Multi-Account Landing Zone environment. See [Management account, Tools account: Creating (with VPC)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-malz-master-acct-create-tools-acct-col.html).
**Note**
We recommend having two availability zones (AZs), since this is a migration hub.
By default, AMS creates the following two security groups (SGs) in every account. Confirm that these two SGs are present. If they are not present, please open a new service request with the AMS team to request them.
SentinelDefaultSecurityGroupPrivateOnlyEgressAll
InitialGarden-SentinelDefaultSecurityGroupPrivateOnly
Ensure that CloudEndure replication instances are created in the private subnet where there are routes back to on-premise. You can confirm that by ensuring that the route tables for the private subnet has a default route back to TGW. However, performing a CloudEndure machine cut over should go into the "isolated" private subnet where there is no route back to on-premise, only Internet outbound traffic is allowed. It is critical to ensure cutover occurs in the isolated subnet to avoid potential issues to the on-premise resources.
Prerequisites:
1. Either **Plus** or **Premium** support level.
1. The application account IDs for the KMS key where the AMIs are deployed.
1. The tools account, created as described previously.
# AWS Application Migration Service (AWS MGN)
[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) (AWS MGN) can be used in your MALZ Tools account through the `AWSManagedServicesMigrationRole` IAM role that is created automatically during Tools account provisioning. You can use AWS MGN to migrate applications and databases that run on supported versions of Windows and Linux [operating systems](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html).
For the most up-to-date information on AWS Region support, see [the AWS Regional Services List](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
If your preferred AWS Region is not currently supported by AWS MGN, or the operating system on which your applications run is not currently supported by AWS MGN, consider using the [CloudEndure Migration](https://console.cloudendure.com/#/register/register) in your Tools account instead.
**Requesting AWS MGN Initialization**
AWS MGN must be [initialized](https://docs.aws.amazon.com/mgn/latest/ug/mandatory-setup.html) by AMS before first use. To request this for a new Tools account, submit a Management \$1 Other \$1 Other RFC from the Tools account with these details:
```
RFC Subject=Please initialize AWS MGN in this account
RFC Comment=Please click 'Get started' on the MGN welcome page here:
[ https://console.aws.amazon.com/mgn/home?region=*MALZ\$1PRIMARY\$1REGION*\$1/welcome](https://console.aws.amazon.com/mgn/home?region=AP-SOUTHEAST-2#/welcome) using all default values
to 'Create template' and complete the initialization process.
```
Once AMS successfully completes the RFC and initializes AWS MGN in your Tools account, you can use `AWSManagedServicesMigrationRole` to edit the default template for your requirements.
![\[AWS MGN, Setup application migration service.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/aws_mgn_firstrun.png)
# Enable access to the new AMS Tools account
Once the tools account is created, AMS provides you with an account ID. Your next step is to configure access to the new account. Follow these steps.
1. Update the appropriate Active Directory groups to the appropriate account IDs.
New AMS-created accounts are provisioned with the ReadOnly role policy as well as a role to allow users to file RFCs.
The Tools account also has an additional IAM role and user available:
+ IAM role: `AWSManagedServicesMigrationRole`
+ IAM user: `customer_cloud_endure_user`
1. Request policies and roles to allow service integration team members to set up the next level of tools.
Navigate to the AMS console and file the following RFCs:
1. Create KMS key. Use either [Create KMS Key (auto)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-kms-key-create-auto-col.html) or [Create KMS Key (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-kms-key-create-rr-col.html).
As you use KMS to encrypt ingested resources, using a single KMS key that is shared with the rest of the Multi-Account Landing Zone application accounts, provides security for ingested images where they can be decrypted in the destination account.
1. Share the KMS key.
Use the Management \$1 Advanced stack components \$1 KMS key \$1 Share (managed automation) change type (ct-05yb337abq3x5) to request that the new KMS key be shared with your application accounts where ingested AMIs will reside.
Example graphic of a final account setup:
![\[AWS architecture diagram showing Migration VPC, IAM, and Permissions with various components and connections.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/WIGS_Account_ExpandedV1.png)
# Example AMS pre-approved IAM CloudEndure policy
To see an AMS pre-approved IAM CloudEndure policy: Unpack the [WIGS Cloud Endure Landing Zone Example](samples/wigs-ce-lz-examples.zip) file and open the `customer_cloud_endure_policy.json`.
# Testing AMS Tools account connectivity and end-to-end setup
1. Start with configuring CloudEndure and installing the CloudEndure agent on a server that will replicate to AMS.
1. Create a project in CloudEndure.
1. Enter the AWS credentials shared when you performed the prerequisites, though secrets manager.
1. In **Replication settings**:
1. Select both AMS "Sentinel" security groups (Private Only and EgressAll) for the **Choose the Security Groups to apply to the Replication Servers** option.
1. Define cutover options for the machines (instances). For information, see [Step 5. Cut over](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/step5.html)
1. **Subnet**: Private subnet.
1. **Security Group**:
1. Select both AMS "Sentinel" security groups (Private Only and EgressAll).
1. Cutover instances have to communicate to the AMS-managed Active Directory (MAD) and to AWS public endpoints:
1. **Elastic IP**: None
1. **Public IP**: no
1. **IAM role**: customer-mc-ec2-instance-profile
1. Set tags as per your internal tagging convention.
1. Install the CloudEndure agent on the machine and look for the replication instance to come up in your AMS account in the EC2 console.
The AMS ingestion process:
![\[Flowchart showing AMS ingestion process steps from customer instance to application deployment.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/Ingestion_Process_v1.png)
# AMS Tools account hygiene
You'll want to clean up after you are done in the account have shared the AMI and no longer have a need for the replicated instances:
+ Post instance WIGs ingestion:
+ Cutover instance: At a minimum, stop or terminate this instance, after the work has been completed, via the AWS console
+ Pre-Ingestion AMI backups: Remove once the instance has been ingested and the on-premise instance terminated
+ AMS-ingested instances: Turn off the stack or terminate once the AMI has been shared
+ AMS-ingested AMIs: Delete once sharing with the destination account is completed
+ End of migration clean up: Document the resources deployed through Developer mode to ensure clean-up happens on regular basis, for example:
+ Security groups
+ Resources created via Cloud-formation
+ Network ACK
+ Subnet
+ VPC
+ Route Table
+ Roles
+ Users and accounts
# Migration at scale - Migration Factory
See [Introducing AWS CloudEndure Migration Factory Solution](https://aws.amazon.com/about-aws/whats-new/2020/06/introducing-aws-cloudendure-migration-factory-solution/).