Migration with AWS Application Migration Service

Most large lift-and-shift migrations to AWS use AWS Application Migration Service. This service works on a physical level by moving data that is stored on any directly attached block storage device (such as a hard drive or SAN drive) to the corresponding Amazon Elastic Block Store (Amazon EBS) storage device on AWS. It essentially implements a traditional backup/restore procedure (by cloning the hard drives), but also provides a recovery point objective (RPO) of near seconds and a recovery time objective (RTO) of minutes by achieving Continuous Data Protection (CDP) synchronization mode between the source systems and the target storage devices in the staging area.

Advantages

For lift-and-shift migrations of any scale, AWS Application Migration Service has many benefits:

Disadvantages

When you use block-level replication tools such as AWS Application Migration Service, you might encounter the following corner cases and factors to consider:

Best-fit scenarios

AWS Application Migration Service covers almost any lift-and-shift migration fully, with few disadvantages, as discussed in the previous two sections. This tool can handle most of the corner cases, such as database clusters, as long as the longer cutover window required for these systems satisfies your migration requirements.

The following sections cover two scenarios in more depth:

Large-scale migration with multiple migration waves

An example of a large-scale migration is a data center exit that is characterized by size and speed requirements, and usually involving a specific time constraint (such as the end of the lease contract for the data center). In this case, the scale dictates the approach. The migration waves are determined and grouped by applications, including databases, and each wave has a planned preparation, migration, and final cutover phase with specific downtime requirements.

Inside each migration wave, the database servers are best moved at scale by using AWS Application Migration Service block-level replication, except for a few exceptions for the following special cases that might require a separate migration approach:

For each special case, consider the tradeoff between your downtime requirements and the level of effort involved in using another migration tool. In some cases, it’s much easier to use the same migration approach for all systems instead of using separate tools and creating different processes for specific systems. If AWS Application Migration Service doesn’t support the downtime requirements for a specific system, we recommend that you use one of the methods described in the Migration with native database tools and AWS DMS section instead.

Single application migration

The single application scenario represents a granular approach for migrating a single business-critical application that requires minimum or near-zero downtime during migration, or a few such applications. The scope of the migration might vary, depending on business criticality and downtime requirements, as opposed to the speed and scale requirements of the previous (large-scale migration) scenario. If the application allows for downtime within the RTO of AWS Application Migration Service, it should be handled in the same way as any large-scale migration described earlier.

However, in cases where the cutover time must be as close to the minimum as possible—for example, when the migrated database has read patterns that require a long time to operate at full performance and the cutover windows have to remain small—you should consider a more detailed and granular approach. In general, that approach involves additional steps and requirements, which require more effort and time. One of the steps is to separate the database migration from the application server migration and to use the database migration tools described in the next section to keep the source and the target databases in sync. You can use various methods to achieve synchronization. Each method has its own advantages and disadvantages, and involves different tradeoffs between the amount of downtime and the complexity of synchronization. Nevertheless, keeping the database in sync between the source and target environments enables you to unlink the database layer from the application layer. Assuming that application servers don’t store persistent data locally, but pass everything to the database layer, synchronization also removes downtime restrictions from the application layer.

Decoupling the database and application layers enables you to migrate application servers by using AWS Application Migration Service as in the previous scenario. Target application servers can be started in the target environment while source systems are still working, processing the data, and storing it in the database layer. Because the database layer is already in sync with the target, cutover time is minimal—it only involves switching networks and redirecting customer requests from the old source system to the target environment. You can use multiple methods to do this, following the guidance for blue/green deployments, typically by switching DNS endpoints, using weighted DNS zones, using AWS Global Accelerator to reduce Time to Live (TTL) DNS propagation delays, and similar methods.