How to migrate from Azure to Amazon's cloud with AWS SMS

Understanding AWS SMS

An organization can use AWS SMS to automate and orchestrate the replication of Windows and Linux VMs into the AWS public cloud. SMS was limited to on-premises vSphere and Hyper-V VM migrations prior to adding support for Azure VMs.

SMS identifies the VMs to migrate and replicates them as Amazon Machine Image (AMI) files. Once an AMI is created, it can be deployed automatically -- or later, if desired -- in a suitable Amazon EC2 instance. But the real power of SMS is its ability to handle the orderly migration of VM groups, which enables administrators to organize broad infrastructure migrations to AWS. This is particularly useful when migrating groups of related VMs that work together to compose an overarching application.

For example, SMS can use an AWS CloudFormation template to launch the AMIs for groups such as database servers, file servers, web servers and application servers. It can launch AMIs in each group in the desired order -- ensuring that the application will operate as expected in AWS.

Continuously replicate or migrate from Azure to AWS

Use of SMS is not necessarily a one-time action. Since it does not affect the source VM, SMS can schedule and orchestrate multiple replications of the same VM to AWS AMIs. As a result, changes to local or Azure VMs can be periodically updated to AWS. For example, organizations can test updates locally -- or in Azure -- and then use SMS to replicate to AWS for production deployment. SMS users can set up initial replication schedules, select replication intervals, follow the progress of each VM replication and use scripts to tailor the startup of each VM in AWS.

SMS depends on the use of connectors, which are dedicated utilities deployed to the source environment. These connectors enable AWS SMS to scan the available VMs in the source environment and select those VMs for migration to AWS. Connectors are available for VMware, Hyper-V and Azure. Depending on the source environment, administrators may require a specific connector download, as well as a pre-fabricated script to install the connector. The installation process varies by source environment and AWS SMS documentation provides detailed instructions.

AWS SMS also imposes numerous requirements and makes several programmatic changes to the imported VMs. Taken together, the requirements and changes needed to run SMS can impact the ability of an organization to use the service or inhibit the migration of certain VMs. It's important to review the prevailing requirements for SMS and its connectors in the AWS SMS documentation before attempting to use the service. And even then, it's worth testing the migration process before adopting SMS broadly.

For example, potential SMS adopters must consider these issues: the impact of anti-malware and intrusion detection tools; remote access permissions for Windows and Linux VMs; specific vSphere, Hyper-V and Azure connector requirements; support for underlying operating, file systems and volume types; the OS and AWS licensing applied to each SMS replication job; and myriad other limitations in terms of image format, file system, boot-up, networking and so on.

Migrate from Azure to AWS

An application migration with AWS SMS involves four general procedures: creating the application, configuring the launch settings for the application, starting the replication and then actually launching the application. An application, in this case, is a series of AWS resources that would eventually hold the migrated application components. Each AWS SMS task can be accomplished using the AWS SMS API, AWS Command Line Interface or AWS SDKs.

Create. Administrators use the AWS SMS console to access the Applications page and create a new application. Administrators stipulate the details for the new application, then select the source VMs and arrange them into desired groups. This is where the connectors are critical in identifying the available VMs in the local vSphere, Hyper-V or Azure cloud environments.

Configure. The second step is to configure the replication settings for the application, allowing administrators to define how source VMs are replicated to the AWS application environment. Administrators can set the replication period, schedule the replication start and delete AMIs when done. They can also set server-specific settings that define the license type and pause a source VM before migration.

Administrators can then define the launch settings for the migrated application. They select the group launch order and a specific script to execute at launch time, which can be used to further tailor the launch in AWS. Finally, administrators specify parameters for the network and security, defining factors including the VPC, subnet, security group and public accessibility.

Replicate. This can typically be started by selecting the configured application and starting the replication process. Once started, the actual replication can take anywhere from 30 minutes to several days depending on the data volume. Administrators can follow the progress in the Replication status reporting field, and failed replications will be denoted as status messages.

Launch. Once the migration is complete, administrators locate and launch the selected application. They can also track the status of the launch, and failed launches will be denoted in the Launch status field. After the application has launched, administrators can use regular AWS monitoring and reporting to oversee the application.

Pricing and availability

There is no separate fee for using SMS, but there are costs to consider. For example, SMS creates an Elastic Block Store snapshot with each replication. Users pay for the snapshots and should delete unneeded ones post-migration. There is additional cost involved in S3 storage used for temporary file work, resulting in short-term S3 charges. And finally, users must pay for all of the EC2 instances and all additional services associated with the migrated application running in AWS.

SMS is also currently limited to 50 concurrent VM migrations per account, as well as 50 concurrent application migrations per account, with no more than 10 groups and 50 servers in each application.