# AMS Workload Ingest (WIGS)
**Topics**
+ [Migrating Workloads: Prerequisites for Linux and Windows](ex-migrate-instance-prereqs.md)
+ [How Migration Changes Your Resource](ex-migrate-changes.md)
+ [Migrating Workloads: Standard Process](mp-migrate-stack-process.md)
+ [Migrating workloads: CloudEndure landing zone (SALZ)](ex-migrate-instance-cloud-endure.md)
+ [AMS Tools account (migrating workloads)](tools-account.md)
+ [Migrating workloads: Linux pre-ingestion validation](ex-migrate-instance-linux-validation.md)
+ [Migrating workloads: Windows pre-ingestion validation](ex-migrate-instance-win-validation.md)
+ [Workload Ingest Stack: Creating](#ex-workload-ingest-col)
Use the AMS workload ingest change type (CT) with an AMS cloud migration partner, to move your existing workloads into an AMS-managed VPC. Using AMS workload ingest, you can create a custom AMS AMI after moving migrated instances onto AMS. This section describes the process, pre-requisites, and steps that your migration partner and yourself take for AMS workload ingestion.
**Important**
The operating system must be supported by AMS workload ingest. For supported operating systems, see [Migrating Workloads: Prerequisites for Linux and Windows](ex-migrate-instance-prereqs.md).
Every workload and account is different. AMS will work with you to prepare for a successful result.
The following diagram depicts the AMS workload ingestion process.
![\[Workflow diagram showing workload ingestion process from customer instance to AMS stack.\]](http://docs.aws.amazon.com/managedservices/latest/appguide/images/Workload_ingestion_product_process.png)
# Migrating Workloads: Prerequisites for Linux and Windows
Before ingesting a copy of an on-premises instance into AWS Managed Services (AMS), certain prerequisites must be met. These are the prerequisites, including those that differ between Windows and Linux operating systems.
**Note**
To simplify the process of determining if the instances are ready for ingestion, validation tools for both Windows and Linux have been created. These tools can be downloaded and run directly on your on-premises servers as well as EC2 instances in AWS. [Linux Pre-WIGS Validation.zip](samples/linux-prewigs-validation.zip), [Windows Pre-WIGS Validation.zip](samples/windows-prewigs-validation.zip).
BEFORE YOU BEGIN, for Linux and Windows:
+ Perform a full virus scan.
+ The instance must have the `customer-mc-ec2-instance-profile` instance profile.
+ Install the [ Amazon EC2 Systems Manager (SSM) Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) and make sure that the SSM Agent is up and running.
+ A minimum of 10GB of free disk space on the root volume is recommended to run AMS workload ingest (WIGS). Operationally, AMS recommends disk utilization less than 75% and alerts when disk utilization reaches 85%.
+ Determine a time frame for the ingestion with your migration partner.
+ The custom AMI exists as an EC2 instance in the target production AMS account (this is the migration partner's responsibility).
**Important**
The operating system must be supported by AMS workload ingest.
The following operating systems are supported:
Microsoft Windows Server: 2008 R2, 2012, 2012 R2, 2016, 2019 and 2022
Linux: Amazon Linux 2023, Amazon Linux 2, and Amazon Linux, CentOS 7.x, CentOS 6.5-6.10, Oracle Linux 7: minor versions 7.5 and above, Oracle Linux 8: minor versions up to 8.3, RHEL 8.x, RHEL 7.x, RHEL 6.5-6.10, SUSE Linux Enterprise Server 15 SP3, SP4, and SAP specific versions, SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04
The following AMIs are not supported:
Amazon Linux 2023 Minimal AMI.
**Note**
The AMS API/CLI (amscm and amsskms) endpoints are in the AWS N. Virginia Region, `us-east-1`. Depending on how your authentication is set, and what AWS Region your account and resources are in, you may need to add `--region us-east-1` when issuing commands. You may also need to add `--profile saml`, if that is your authentication method.
# LINUX Prerequisites
Observe the requirements listed in [Migrating Workloads: Prerequisites for Linux and Windows](ex-migrate-instance-prereqs.md) and ensure the following before submitting a WIGS RFC:
+ The latest enhanced networking drivers are installed; see [Enhanced Networking on Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html).
+ Third-party software components that will conflict with AMS components have been removed:
+ Anti-virus Clients
+ Backup Clients
+ Virtualization software (such as VM Tools or Hyper-V Integration services)
+ Access Management Software (Such as SSSD, Centrify, or PBIS)
+ Ensure SSH is properly configured - This temporarily enables private key authentication for SSH. AMS uses this with our configuration management tool. Use these commands:
```
sudo grep -q "^PubkeyAuthentication" /etc/ssh/sshd_config && sudo sed "s/^PubkeyAuthentication=.*/PubkeyAuthentication yes/" -i /etc/ssh/sshd_config || sudo sed "$ a\PubkeyAuthentication yes" -i /etc/ssh/sshd_config
```
```
sudo grep -q "^AuthorizedKeysFile" /etc/ssh/sshd_config && sudo sed "s/^AuthorizedKeysFile=.*/AuthorizedKeysFile %h\/.ssh\/authorized_keys/" -i /etc/ssh/sshd_config || sudo sed "$ a\AuthorizedKeysFile %h/.ssh/authorized_keys" -i /etc/ssh/sshd_config
```
+ Ensure Yum is properly configured - RedHat requires licensing to use their Yum Repositories. The instance needs to be licensed via a Satellite Server or RedHat Cloud Server. Use one of these links if licensing is needed:
+ [Red Hat Satellite](https://www.redhat.com/en/technologies/management/satellite)
+ [Red Hat Cloud Access](https://www.redhat.com/en/technologies/cloud-computing/cloud-access)
+ If you use Red Hat Satellite, WIGS requires the addition of Red Hat Software Collections (RHSCL). The WIGS system uses RHSCL to add a Python3.6 interpreter alongside whatever is configured on the system. To support this solution, the following repositories must be available:
+ rhel-server-rhscl
+ rhel-server-releases-optional
# Windows Prerequisites
Observe the requirements listed in [Migrating Workloads: Prerequisites for Linux and Windows](ex-migrate-instance-prereqs.md) and ensure the following before submitting a WIGS RFC:
+ Powershell version 3 or higher is installed.
+ [AWS EC2 Config](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_Install.html) is installed on the instance with the workload that you will migrate.
+ Install the AWS drivers that support the latest generation instance types: PV, ENA, and NVMe. You can use the information in these links:
+ [Upgrading PV Drivers on Your Windows Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html)
+ [Enhanced Networking on Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking.html)
+ [AWS NVMe Drivers for Windows Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html)
+ [Part 3: Upgrading AWS NVMe drivers](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html#upgrade-nvme)
+ [Part 5: Installing the Serial Port Driver for Bare Metal Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html#install-serial-port-bare-metal)
+ [Part 6: Updating Power Management Settings](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html#power-management)
+ (Optional but recommended) Disable critical Services – Set critical application services, such as databases, to disabled, but ensure that any changes are documented so they can be reverted to their original startup mode during the application verification stage.
+ (Optional but recommended) Create a Failsafe AMI from the prepared instance:
+ Use the Deployment \$1 Advanced stack components \$1 AMI \$1 Create
+ During creation, add a tag Key=Name, Value=APPLICATION-ID\$1IngestReady
+ Wait until AMI is created before proceeding
+ Third-party software components that will conflict with AMS components have been removed:
+ Anti-virus Clients
+ Backup Clients
+ Virtualization software (such as VM Tools or Hyper-V Integration services)
**Note**
[ The End-of-Support Migration Program for Windows server (EMP)](https://aws.amazon.com/emp-windows-server/) includes tooling to migrate your legacy applications from Windows Server 2003, 2008, and 2008 R2 to newer, supported versions on AWS, without any refactoring.
# How Migration Changes Your Resource
The ingestion RFC described in this section takes the next step of adding configurations to the instance, once it is migrated to your AMS account, so that AMS can manage it.
The configurations added are AMS-specific as follows.
*Changes made to ingested Linux instances*:
+ Software that is installed:
+ [Cloud Init](https://cloud-init.io/): Used to configure private keys for Jarvis Access.
+ [Python 3](https://www.python.org/downloads/release/python-367/) (scripting language) for all supported operating systems (Except for CentOS 6, RHEL 8, OracleLinux 7).
+ [ AWS CloudFormation Python Helper Scripts](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-helper-scripts-reference.html): AWS CloudFormation provides scripts used to install software and start services on an Amazon EC2 instances.
+ [AWS CLI](https://docs.aws.amazon.com/cli/index.html#lang/en_us): The AWS CLI is an open source tool built on top of the AWS SDK for Python (Boto) that provides commands for interacting with AWS services.
+ [AWS SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html): The SSM Agent processes requests from the Systems Manager service configures the machine as specified in the request.
+ [AWS CloudWatch Logs Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html): Sends logs to CloudWatch.
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/index.html#lang/en_us): A deployment service that automates application deployments to Amazon EC2 instances, on-premises instances, or serverless Lambda functions.
+ [Ruby](https://www.ruby-lang.org/en/documentation/installation/): Required for CodeDeploy
+ [System Performance Tools (sysstat)](https://github.com/sysstat/sysstat): Sysstat contains various utilities to monitor system performance and usage activity.
+ [AD Bridge (Formerly PowerBroker Identity Services)](https://github.com/BeyondTrust/pbis-open): Joins non-Microsoft hosts to Active Directory domains.
+ [Trend Micro Deep Security Agent](https://success.trendmicro.com/solution/1104569-deploying-deep-security-agent-dsa-for-linux): Anti-Virus software.
+ Software that is changed:
+ The instances are configured to use the UTC timezone.
*Changes made to ingested Windows instances*:
+ Software that is installed:
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell): The AWS Tools for PowerShell let developers and administrators manage their AWS services and resources in the PowerShell scripting environment.
+ [Trend Micro Deep Security Agent](https://help.deepsecurity.trendmicro.com/Welcome.html): Anti-Virus protection
+ AMS PowerShell Modules containing PowerShell code for controlling Boot, Active Directory Join, Monitoring, Security, and Logging.
+ Software that is changed:
+ Server Message Block (SMB) version 1 is disabled.
+ Windows Remote Management (WinRM) is enabled and configured to listen on port 5986. A firewall rule allowing this inbound port is also created.
+ Software that *might be* installed or changed:
+ [Microsoft .Net Framework 4.5 (Developer platform)](https://www.microsoft.com/net), if a version lower then .Net Framework 4.5 is detected.
+ For Windows 2012, ad Windows 2012R2, we upgrade to [PowerShell 5.1](https://docs.microsoft.com/en-us/skypeforbusiness/set-up-your-computer-for-windows-powershell/download-and-install-windows-powershell-5-1).
# Migrating Workloads: Standard Process
**Note**
Because two parties are required for this process, this section describes the tasks for each: an AMS Cloud Migration Partner (migration partner), and an Application Owner (you).
![\[Workflow diagram showing migration steps from on-premises to AWS EC2 and AMS.\]](http://docs.aws.amazon.com/managedservices/latest/appguide/images/migration-ams-wigs.png)
1. Migration partner, Set Up:
1. The migration partner submits a Service Request to AMS for an IAM role for the purpose of migrating your instance. For details on submitting service requests, see [Service Request Examples](https://docs.aws.amazon.com/managedservices/latest/userguide/serv-req-mgmt-examples.html).
1. The migration partner submits a [Admin Access Request](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-access-admin-request-col.html). The AMS Operations team provides the migration partner access to your account through the requested IAM role.
1. Migration partner, Migrate Individual Workloads:
1. The migration partner migrates your non-AWS instance to a subnet in your AMS account through native Amazon EC2 or other migration tooling, with the `customer-mc-ec2-instance-profile` IAM instance profile (must be in the account).
1. The migration partner submits an RFC with the Deployment \$1 Ingestion \$1 Stack from migration partner migrated instance \$1 Create CT (ct-257p9zjk14ija); for details on creating and submitting this RFC, see [Workload Ingest Stack: Creating](ams-workload-ingest.md#ex-workload-ingest-col).
The execution output of the RFC returns an instance ID, IP address, and AMI ID.
The migration partner provides you with the instance ID of the workload created in your account.
1. You, Access and Validate the Migration:
1. Using the execution output provided you (AMI ID, instance ID, and IP address) by the migration partner, submit an access RFC and log into the newly-created AMS stack and verify that your application is working properly. For details, see [Requesting Instance Access](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-access-admin-request-col.html).
1. If satisfied, you can continue to use the launched instance as a 1-tier stack and/or use the AMI to create additional stacks, including Auto Scaling groups.
1. If not satisfied with the migration, file a service request and reference the stack and RFC IDs; AMS will work with you to address your concerns.
CloudEndure landing zone workload ingest process is described next.
# Migrating workloads: CloudEndure landing zone (SALZ)
This section provides information on setting up an intermediate migration single-account landing zone (SALZ) for CloudEndure (CE) cutover instances to be available for a workload ingest (WIGS) RFC.
To learn more about CloudEndure, see [CloudEndure Migration](https://aws.amazon.com/cloudendure/).
**Note**
This is a predefined, security hardened, migration LZ and pattern.
Prerequisites:
+ A customer AMS account
+ Network and access integration between AMS account and the customer on-premise
+ A CloudEndure account
+ A pre-approval workflow for an AMS Security review and signoff, run with your CA and/or CSDM, (for example, misuse of the IAM user permanent credentials provides the ability to create/delete instances and security groups)
**Note**
Specific preparation and migration processes are described in this section.
![\[AWS architecture diagram showing data flow between on-premises server and AWS cloud services.\]](http://docs.aws.amazon.com/managedservices/latest/appguide/images/migration-ams-wigs-solution.png)
Preparation: You and AMS operator:
1. Prepare a Request for Change (RFC) with the Management \$1 Other \$1 Other \$1 Update change type to AMS for the following resources and updates. You can submit separate Other \$1 Other Update RFCs, or one. For details on that RFC/CT, see [Other \$1 Other Update](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-other-other-update-col.html) with these requests:
1. Assign a secondary CIDR block in your AMS VPC; a temporary CIDR block that will be removed after the migration is completed. Ensure that the block will not conflict with any existing routes back to your on-premise network. For example, if your AMS VPC CIDR is 10.0.0.0/16, and there is a route back to your on-premise netword of 10.1.0.0/16, then the temporary secondary CIDR could be 10.255.255.0/24. For information on AWS CIDR blocks, see [VPC and Subnet Sizing](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing).
1. Create a new, private, subnet inside the initial-garden AMS VPC. Example name: `migration-temp-subnet`.
1. Create a new route table for the subnet with only local VPC and NAT (Internet) routes, to avoid conflicts with the source server during instance cutover and possible outages. Ensure outbound traffic to the Internet is allowed for patch downloads, and so that AMS WIGS pre-requisites can be downloaded and installed.
1. Update your Managed AD security group to allow inbound and outbound traffic to/from `migration-temp-subnet`. Also request that your EPS load balancer (ELB) security group (ex: `mc-eps-McEpsElbPrivateSecurityGroup-M79OXBZEEX74`) be updated to allow the new, private, subnet (i.e. `migration-temp-subnet`). If the traffic from the dedicated CloudEndure (CE) subnet is not allowed on all three TCP ports, WIGS ingestion will fail.
1. Finally, request a new CloudEndure IAM policy and IAM user. The policy needs your correct account number, and the subnet IDs in the `RunInstances` statement should be: your .
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`.
**Note**
If you want a more permissive policy, discuss what you need with your CloudArchitect/CSDM and obtain, if needed, an AMS Security Review and Signoff before submitting an RFC implementing the policy.
1. Your preparation steps to use CloudEndure for AMS workload ingestion are done and, if your migration partner has completed their preparation steps, migration is ready to be performed. The WIGS RFC is submitted by your migration partner.
**Note**
IAM user keys won't be directly shared, but must be typed into the CloudEndure management console by the AMS operator in a screen-sharing session.
Preparation: Migration Partner and AMS Operator:
1. Create CloudEndure migration project.
1. During project creation, have AMS type-in IAM user credentials in screen-sharing sessions.
1. In **Replication Settings** -> **Choose the subnet where the Replication Servers will be launched**, select **customer-application-x** subnet.
1. In **Replication Settings** -> **Choose the Security Groups to apply to the Replication Servers**, select both Sentinel security groups (Private Only and EgressAll).
1. Define cutover options for the machines (instances).
1. Subnet: **migration-temp-subnet**.
1. Security Group: Both "Sentinel" security groups (Private Only and EgressAll).
Cutover instances must be able to communicate to the AMS Managed AD and to AWS public endpoints.
1. Elastic IP: **None**
1. Public IP: **no**
1. IAM role: **customer-mc-ec2-instance-profile**
The IAM role must allow for SSM communication. Better to use AMS default.
1. Set tags as per convention.
Migration: Migration Partner:
1. Create a dummy stack on AMS. You use the stack ID to gain access to the bastions.
1. Install the CloudEndure (CE) agent on the source server. For details, see [Installing the Agents](https://docs.cloudendure.com/Content/Installing_the_CloudEndure_Agents/Installing_the_Agents/Installing_the_Agents.htm).
1. Create local admin credentials on the source server.
1. Schedule a short cutover window and click **Cutover**, when ready. This finalizes the migration and redirects users to the target AWS Region.
1. Request stack Admin access to the dummy stack, see [Admin Access Request](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-access-admin-request-col.html).
1. Log into the bastion, then to the cutover instance using the local admin credentials you created.
1. Create a failsafe AMI. For details on creating AMIs, see [AMI Create](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-ami-create-col.html).
1. Prepare the instance for ingestion, see [Migrating Workloads: Prerequisites for Linux and Windows](ex-migrate-instance-prereqs.md).
1. Run WIGS RFC against the instance, see [Workload Ingest Stack: Creating](ams-workload-ingest.md#ex-workload-ingest-col).
# 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/appguide/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/appguide/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/appguide/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/appguide/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/).
# Migrating workloads: Linux pre-ingestion validation
You can validate that your instance is ready for ingestion into your AMS account. The workload ingest (WIGS) pre-ingestion validation performs checks such as operating system type, available disk space, the existence of conflicting third party software, etc. When executed, the WIGS pre-ingestion validation produces an on-screen table, with an optional log file. The results provide a pass/fail status for each validation check along with the reason for any failures. In addition, you can customize the validation tests to suit your needs.
Frequently asked questions:
+ **How do I use Linux WIGS pre-ingestion validation?**
Follow these steps to download and use the AMS Linux WIGS pre-ingestion validation scripts:
1. Download a ZIP file with the validation scripts
[Linux WIGS Pre-ingestion Validation zip file](samples/linux-prewigs-validation.zip).
1. Unzip attached rules to a directory of your choice.
1. Follow the instructions in the **readme.md** file.
+ **What validations are performed by the Linux WIGS pre-ingestion validation?**
The AMS Linux WIGS pre-ingestion validation solution validates the following:
1. There are at least 5 Gigabytes free on the boot volume.
1. The operating system is supported by AMS.
1. The instance has a specific instance profile.
1. The instance does not contain Antivirus software or Virtualization software.
1. SSH is properly configured.
1. The instance has access to Yum Repositories.
1. Enhanced networking drivers are installed.
1. The instance has the SSM Agent and it is running.
+ **Why is there support for a custom configuration file?**
The scripts are designed to run on both on-premise physical servers and on AWS EC2 instances. However, as shown in the list above, some tests will fail when run on-premises. For example, a physical server in a datacenter would not have an instance profile. In cases like these, you can edit the configuration file to skip the instance profile test to avoid confusion.
+ **How do I ensure I have the latest version of the script?**
An up-to-date version of the Linux WIGS Pre-Ingestion Validation solution will be available under **AMS Helper Files** section on the main Documentation page.
+ **Is the script read-only?**
The script is designed to be read-only except for the log files it produces, but best practices should be followed to run the script in a non-production environment.
+ **Is WIGS pre-ingestion validation available for Windows?**
Yes. It is available under the **AMS Helper Files** section on the main Documentation page.
# Migrating workloads: Windows pre-ingestion validation
You can use the pre-WIGs validator script to validate that your instance is ready for ingestion into your AMS account. The workload ingest (WIGS) pre-ingestion validation performs checks such as operating system type, available disk space, the existence of conflicting third party software, and so on. When run, the WIGS pre-ingestion validation produces an on-screen table and an optional log file. The results provide a pass/fail status for each validation check along with the failure reason. In addition, you can customize the validation tests.
Frequently asked questions:
+ **How do I use Windows WIGS pre-ingestion validation?**
You can run the validation from a GUI and web browser, or you can use Windows PowerShell, SSM Run Command, or SSM Session Manager.
**Option 1: Run from a GUI and web browser**
To run the Windows pre-WIGs validation from a GUI and web browser, do the following:
1. Download a ZIP file with the validation scripts:
[Windows WIGS Pre-ingestion Validation ZIP file](samples/windows-prewigs-validation.zip).
1. Unzip attached rules to a directory of your choice.
1. Follow the instructions in the **README.md** file.
**Option 2: Run from Windows PowerShell, SSM Run Command, or SSM Session Manager**
**Windows 2016 and later**
1. Download the ZIP file with the validation scripts.
```
$DestinationFile = "$env:TEMP\WIGValidation.zip"
$Bucket = 'https://docs.aws.amazon.com/managedservices/latest/appguide/samples/windows-prewigs-validation.zip'
$DestinationFile = "$env:TEMP\WIGValidation.zip"
$ScriptFolder = "$env:TEMP\AWSManagedServices.PreWigs.Validation"
```
1. Remove existing files from `C:\Users\AppData\Local\Temp\AWSManagedServices.PreWigs.Validation`.
```
Remove-Item $scriptFolder -Recurse -Force -ErrorAction Ignore
```
1. Invoke the script.
```
Invoke-WebRequest -Uri $bucket -OutFile $DestinationFile
Add-Type -Assembly "system.io.compression.filesystem"
```
1. Unzip attached files to a directory of your choice.
```
[io.compression.zipfile]::ExtractToDirectory($DestinationFile, $env:TEMP)
```
1. Run the validation script interactively and view the results.
```
Import-Module .\AWSManagedServices.PreWigs.Validation.psm1 -force
Invoke-PreWIGsValidation -RunWithoutExitCodes
```
1. (Optional) To capture the error codes listed in the **Exit Codes** section, run the script without the `RunWithoutExitCodes` option. Note that this command terminates the active PowerShell session.
```
Import-Module .\AWSManagedServices.PreWigs.Validation.psm1 -force
Invoke-PreWIGsValidation
```
**Windows 2012 R2 and earlier**
If you're running Windows Server 2012R2 or below, you must set TLS before you download the zip file. To set TLS, complete the following steps:
1. Download the ZIP file with the validation scripts.
```
$DestinationFile = "$env:TEMP\WIGValidation.zip"
$Bucket = 'https://docs.aws.amazon.com/managedservices/latest/appguide/samples/windows-prewigs-validation.zip'
$DestinationFile = "$env:TEMP\WIGValidation.zip"
$ScriptFolder = "$env:TEMP\AWSManagedServices.PreWigs.Validation"
```
1. If there are existing validation files, then remove them.
```
Remove-Item $scriptFolder -Recurse -Force -ErrorAction Ignore
```
1. Set the TLS version.
```
[System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
```
1. Download WIG validation.
```
Invoke-WebRequest -Uri $bucket -OutFile $DestinationFile
Add-Type -Assembly "system.io.compression.filesystem"
```
1. Unzip the attached rules to a directory of your choice.
```
[io.compression.zipfile]::ExtractToDirectory($DestinationFile, $env:TEMP)
```
1. Run the validation script interactively and view the results.
```
Import-Module .\AWSManagedServices.PreWigs.Validation.psm1 -force
Invoke-PreWIGsValidation -RunWithoutExitCodes
```
1. (Optional) To capture the error codes listed in the **Exit Codes** section, run the script without the RunWithoutExitCodes option. Note that this command terminates the active PowerShell session.
```
Import-Module .\AWSManagedServices.PreWigs.Validation.psm1 -force
Invoke-PreWIGsValidation
```
**Note**
You can download and run the PowerShell scripts. To do this, download the [pre-wigs-validation-powershell-scripts.zip](samples/pre-wigs-validation-powershell-scripts.zip).
+ **What validations are performed by the Windows WIGS Pre-Ingestion Validation?**
The AMS Windows WIGS pre-ingestion validation solution validates the following:
1. There is at least 10 Gigabytes free on the boot volume.
1. The operating system is supported by AMS.
1. The instance has a specific instance profile.
1. The instance does not contain antivirus software or virtualization software.
1. DHCP is enabled on at least one network adapter.
1. The instance is ready for Sysprep.
+ For 2008 R2 and 2012 Base and R2, Sysprep verifies that:
+ There is an unattend.xml file
+ The sppnp.dll file(if present) is not corrupt
+ The Operating System has not been upgraded
+ Sysprep has not run more than the maximum number of times per Microsoft guidelines
+ For 2016 and above, all of above checks are skipped as neither cause problems for that OS
1. The Windows management instrumentation (WMI) subsystem is healthy.
1. Required drivers are installed.
1. The SSM Agent and is installed and running.
1. Warning is given to verify if the machine is in grace period due to the RDS License Configuration.
1. Required registry keys are set properly. For more details, see the README in the Pre-ingestion Validation zip file.
+ **Why is there support for a custom configuration file?**
The scripts are designed to run on both on-premise physical servers and on AWS EC2 instances. However, as shown in the list above, some tests will fail when run on-premises. For example, a physical server in a datacenter would not have an instance profile. In cases like these, you can edit the configuration file to skip the instance profile test to avoid confusion.
+ **How do I ensure I have the latest version of the script?**
An up-to-date version of the Windows WIGS pre-ingestion validation solution will be available under the **AMS Helper Files** section on the main Documentation page.
+ **Is the script read-only?**
The script is designed to be read-only except for the log files it produces, but best practices should be followed to run the script in a non-production environment.
+ **Is WIGS Pre-Ingestion Validation available for Linux?**
Yes. The Linux version launched on 31 October, 2019. It is available under the **AMS Helper Files** section on the main Documentation page.
## Workload Ingest Stack: Creating
### Migrating an instance to an AMS stack with the Console
Screenshot of this change type in the AMS console:
![\[Instance migration details showing ID, execution mode, version, classification, and description.\]](http://docs.aws.amazon.com/managedservices/latest/appguide/images/guiIngestStackFromPartMigStackCreateCT.png)
How it works:
1. Navigate to the **Create RFC** page: In the left navigation pane of the AMS console click **RFCs** to open the RFCs list page, and then click **Create RFC**.
1. Choose a popular change type (CT) in the default **Browse change types** view, or select a CT in the **Choose by category** view.
+ **Browse by change type**: You can click on a popular CT in the **Quick create** area to immediately open the **Run RFC** page. Note that you cannot choose an older CT version with quick create.
To sort CTs, use the **All change types** area in either the **Card** or **Table** view. In either view, select a CT and then click **Create RFC** to open the **Run RFC** page. If applicable, a **Create with older version** option appears next to the **Create RFC** button.
+ **Choose by category**: Select a category, subcategory, item, and operation and the CT details box opens with an option to **Create with older version** if applicable. Click **Create RFC** to open the **Run RFC** page.
1. On the **Run RFC** page, open the CT name area to see the CT details box. A **Subject** is required (this is filled in for you if you choose your CT in the **Browse change types** view). Open the **Additional configuration** area to add information about the RFC.
In the **Execution configuration** area, use available drop-down lists or enter values for the required parameters. To configure optional execution parameters, open the **Additional configuration** area.
1. When finished, click **Run**. If there are no errors, the **RFC successfully created** page displays with the submitted RFC details, and the initial **Run output**.
1. Open the **Run parameters** area to see the configurations you submitted. Refresh the page to update the RFC execution status. Optionally, cancel the RFC or create a copy of it with the options at the top of the page.
**Note**
If the RFC is rejected, the execution output includes a link to Amazon CloudWatch logs. AMS Workload Ingest (WIGS) RFCs are rejected when requirements are not met; for example, if anti-virus software is detected on the instance. The CloudWatch logs will include information about the failed requirement and the actions to take for remediation.
### Migrating an instance to an AMS stack with the CLI
How it works:
1. Use either the Inline Create (you issue a `create-rfc` command with all RFC and execution parameters included), or Template Create (you create two JSON files, one for the RFC parameters and one for the execution parameters) and issue the `create-rfc` command with the two files as input. Both methods are described here.
1. Submit the RFC: `aws amscm submit-rfc --rfc-id ID` command with the returned RFC ID.
Monitor the RFC: `aws amscm get-rfc --rfc-id ID` command.
To check the change type version, use this command:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```
**Note**
You can use any `CreateRfc` parameters with any RFC whether or not they are part of the schema for the change type. For example, to get notifications when the RFC status changes, add this line, `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` to the RFC parameters part of the request (not the execution parameters). For a list of all CreateRfc parameters, see the [AMS Change Management API Reference](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html).
You can use the AMS CLI to create an AMS instance from a non-AMS instance migrated to an AMS account.
**Note**
Be sure you have followed the prerequisites; see [Migrating Workloads: Prerequisites for Linux and Windows](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-prereqs.html).
To check the change type version, use this command:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID
```
*INLINE CREATE*:
Issue the create RFC command with execution parameters provided inline (escape quotes when providing execution parameters inline), and then submit the returned RFC ID. For example, you can replace the contents with something like this:
```
aws amscm create-rfc --change-type-id "ct-257p9zjk14ija" --change-type-version "2.0" --title "AMS-WIG-TEST-NO-ACTION" --execution-parameters "{\"InstanceId\":\"INSTANCE_ID\",\"TargetVpcId\":\"VPC_ID\",\"TargetSubnetId\":\"SUBNET_ID\",\"TargetInstanceType\":\"t2.large\",\"ApplyInstanceValidation\":true,\"Name\":\"WIG-TEST\",\"Description\":\"WIG-TEST\",\"EnforceIMDSV2\":\"false\"}"
```
*TEMPLATE CREATE*:
1. 0utput the execution parameters JSON schema for this change type to a file; example names it MigrateStackParams.json:
```
aws amscm get-change-type-version --change-type-id "ct-257p9zjk14ija" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > MigrateStackParams.json
```
1. Modify and save the execution parameters JSON file. For example, you can replace the contents with something like this:
```
{
"InstanceId": "MIGRATED_INSTANCE_ID",
"TargetVpcId": "VPC_ID",
"TargetSubnetId": "SUBNET_ID",
"Name": "Migrated-Stack",
"Description": "Create-Migrated-Stack",
"EnforceIMDSV2": "false"
}
```
1. Output the RFC template JSON file; example names it MigrateStackRfc.json:
```
aws amscm create-rfc --generate-cli-skeleton > MigrateStackRfc.json
```
1. Modify and save the MigrateStackRfc.json file. For example, you can replace the contents with something like this:
```
{
"ChangeTypeId": "ct-257p9zjk14ija",
"ChangeTypeVersion": "2.0",
"Title": "Migrate-Stack-RFC"
}
```
1. Create the RFC, specifying the MigrateStackRfc file and the MigrateStackParams file:
```
aws amscm create-rfc --cli-input-json file://MigrateStackRfc.json --execution-parameters file://MigrateStackParams.json
```
You receive the ID of the new RFC in the response and can use it to submit and monitor the RFC. Until you submit it, the RFC remains in the editing state and does not start.
The new instance appears in the Instance list for the application owner's account for the relevant VPC.
1. Once the RFC completes successfully, notify the application owner so he or she can log into the new instance and verify that the workload is operational.
**Note**
If the RFC is rejected, the execution output includes a link to Amazon CloudWatch logs. AMS Workload Ingest (WIGS) RFCs are rejected when requirements are not met; for example, if anti-virus software is detected on the instance. The CloudWatch logs will include information about the failed requirement and the actions to take for remediation.
### Tips
**Note**
Be sure you have followed the prerequisites; see [Migrating Workloads: Prerequisites for Linux and Windows](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-prereqs.html).
**Note**
If a tag on the instance being migrated has the same key as a tag supplied in the RFC, the RFC fails.
**Note**
You can specify up to four Target IDs, Ports, and Availability Zones.
**Note**
If the RFC is rejected, the execution output includes a link to Amazon CloudWatch logs. AMS Workload Ingest (WIGS) RFCs are rejected when requirements are not met; for example, if anti-virus software is detected on the instance. The CloudWatch logs will include information about the failed requirement and the actions to take for remediation.
**Note**
If the RFC is rejected, the execution output includes a link to Amazon CloudWatch logs. AMS Workload Ingest (WIGS) RFCs are rejected when requirements are not met; for example, if anti-virus software is detected on the instance. The CloudWatch logs will include information about the failed requirement and the actions to take for remediation.
If needed, see [Workload ingestion (WIGS) failure](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-troubleshoot.html#rfc-valid-execute-wigs).