Landing zone considerations for a large migration

A landing zone is a well-architected AWS environment that is scalable and secure. By establishing standards for the landing zone, such as defining the number of accounts and designing the subnets and security groups, you build a solid foundation. This foundation gives you the ability to enable, provision, and operate your environment for both business agility and governance at scale while accelerating your cloud adoption journey. For more information about landing zones and strategies for building them, see Setting up a secure and scalable multi-account AWS environment.

In addition to the standard business, operational, security and compliance considerations for your landing zone strategy, you must consider how to facilitate a large migration. You must design the landing zone to support existing, on-premises workloads during the migration and after, in cases where some workloads remain on premises. This guide provides additional landing zone considerations that affect the migration velocity and overall migration timeline.

Typically, landing zones are designed and deployed to support new workloads in the AWS Cloud. This is because organizations are adopting AWS before making the decision to migrate a large number of existing applications. The benefit of this approach is that the organization gains valuable knowledge and skills in AWS before the large migration, but it can also lead to conflicts between the various stakeholders. Some stakeholders might want to modernize the application during the migration because they want to take advantage of cloud-native features. However, the common goal of a large migration is to achieve maximum migration velocity and ease the transition by migrating as many applications as possible without modifying the workload. You then modernize these applications after the migration is complete.

Some key factors of the landing zone that can affect your large migration program project are:

• Network bandwidth availability and management

• Account strategy for workload isolation and resource management

• Security and administrative controls for migrated workloads

This section reviews the infrastructure, operations, and security questions that you should consider when building your AWS landing zone. It also contains recommendations for how to design and deploy your landing zone to support a large migration project. As you answer the questions in this section, these decisions become migration principles, which you document according to the instructions in Document your decisions as large migration principles.

Infrastructure considerations

Have you considered?	Description	Actions
How much data will you migrate per day and per week?	The desired migration velocity dictates the type of network connection and network throughput requirements. It also can affect the wave planning selection criteria.	After you have completed the portfolio assessment, determine the total amount of storage needed for all migrated resources in the cloud. Use this value to calculate the amount of time required to migrate the data using the current network bandwidth. You might need to increase the bandwidth to meet the migration timeframes, or you might need to use alternatives, such as AWS Snow Family solutions. In the foundation playbook templates, you can use the Data replication calculator (Microsoft Excel format) to calculate the required bandwidth for each migration wave.
What is the average write speed of the source servers in each wave?	The bandwidth required to transfer the replicated data is based on the write speed of the participating source servers. The amount of bandwidth required for server replication is the average write speed of your source servers multiplied by the number of servers in the largest wave.	During portfolio assessment, you need to determine the average number of data writes performed per by each server. In the foundation playbook templates, you can use the Data replication calculator (Microsoft Excel format) to understand the bandwidth required for migration traffic. The bandwidth required for migration traffic is in addition to the bandwidth used for normal business activity. After the migration is complete, you no longer need the additional bandwidth to support the migration activities.
Could additional network activities or existing infrastructure limit or reduce the replication speed?	If the network bandwidth also supports other business functions, these activities can reduce the amount of bandwidth available for replicating servers during the migration.	Early in the project lifecycle, carefully assesses and calculate the network bandwidth required to support all business activities. Consider the bandwidth needed for normal business activities, server replication, and new migration-related activities, such as syncing on-premises file shares with data on AWS. Providers might have long lead times to increase the network capacity, and you might need to upgrade the existing on-premises infrastructure. Consider whether any additional upgrades would be required as a consequence of upgrading the network infrastructure. Assessing bandwidth requirements early in the project provides time to make any necessary changes.
Does your current AWS subnet strategy meet the IP addressing requirements for migrating the on-premises workloads?	The number of servers and workload isolation requirements dictates the subnet strategy for your landing zone. Large migrations might require larger subnets than you expect. In a large migration, you group workloads in subnets similar to their setup in the on-premises infrastructure. To simplify the migration, larger, flatter subnet designs are preferred initially, and then, during modernization, you redesign the subnets as needed.	When the portfolio assessment has enough information about the infrastructure inventory, assess the on-premises network structure and incorporate it into the landing zone design as early as possible.
How many servers do you plan to replicate and migrate in parallel?	The size of the largest migration wave affects the subnet requirements and AWS service quotas.	Review the high-level migration plan, and use that to design your subnet. For example, if you have a plan to migrate 200 servers into one subnet, the Classless Inter-Domain Routing (CIDR) range for that subnet should have enough IP addresses to support the target number of servers. Also, increase the AWS service quota for each target account as needed.
Have you identified the security group strategies for your migration resources?	Security groups are used to manage the inbound and outbound traffic for AWS resources. It is important to design security groups early in order to avoid delaying the migration.	In your runbook for application prioritization, review the migration strategies, and then design the security groups based on the migration strategies. For example, if the migration strategy is to rehost most of the workloads, consider a temporary, generic security group that supports migration cutover instead of refactoring the network and applying application-specific security groups.
Are there load balancers in use?	Typically, when migrating servers in an environment with load balancers, you need to assess the configuration of the load balancer and then migrate the load balancer. Migration options for the load balancer include using Elastic Load Balancing (ELB) or a partner appliance-based solution.	Assessment of load balancers needs to start early in the discovery phase in order to account for any custom configurations. In most environments, load balancer configurations are fairly standard, but some might have complex logic that determines whether you can migrate to ELB or a partner appliance-based solution.
Do any servers need to retain their source IP address?	The safest and easiest way to migrate servers to the cloud is to allocate new IP addresses to the migrated instances. In some situations, you might need to keep the same IP address as the source server. For example, a legacy application might have a hardcoded IP address that no one knows how to change.	Keeping source IP addresses affects how you form move groups when wave planning. The most common approach is to migrate a whole subnet to AWS in a single move group because this makes routing and switching straight-forward at the network level. The following are key actions for keeping IP addresses: Carefully assess cross subnet communications between servers. Decide how you will switch routing of IP addresses for migrated servers. Common options include switching a whole subnet or deploying a network technology that manages static IP routing on a server-by-server basis.
How much latency is acceptable between the source and AWS?	It is common to start the migration with VPN links because they can be set up quickly and then transition to a direct connection established using AWS Direct Connect. VPN links generally have higher and more variable latency, which affects data throughput and, more importantly, application response times.	If you are using a high or variable latency connection type, review each application’s requirements and plan the migration waves accordingly. Plan to put applications that require low latency connections in later waves, when alternative connection types are available.

Operations considerations

Have you considered?	Description	Actions
Have you identified an AWS account strategy for your landing zone?	AWS best practices for a well-architected environment recommend that you should separate your resources and workloads into multiple AWS accounts. You can think of AWS accounts as isolated resource containers: they offer workload categorization and can reduce the scope of impact in the event of a disaster.	In your runbook for application prioritization, review your selected migration strategies and use them to determine your account strategy. For example, if you want to migrate as quickly as possible and rehost is the most common migration strategy, fewer accounts is easier to manage. However, if your migration strategies require modernizing applications and you need to separate business units for compliance reasons, you should include one or more accounts for each business unit in your account strategy.
Do you need to switch monitoring tools during the migration? If so, is this part of the migration process, or does it occur before or after the migration?	Monitoring tools are critical for cloud operations. Your existing tools might not work in the cloud because of compatibility or licensing reasons. As part of the design, you need to decide which monitoring tools to use for the workload in the AWS Cloud.	Select a monitoring tool before starting the migration. Make sure the migration team incorporates instructions for setting up monitoring in the migration patterns. We recommend building an automation script that replaces or reuses the monitoring tools, as needed.
Have you identified application owners, and are they aware of any changes that must be made to the application so that it functions properly in the cloud?	Large migration is a transformation rather than just an infrastructure project. Include application owners early to support the migration. For example, application owners validate the wave plan, create test plans, and participate in the cutover.	Work with a project management office and Cloud Enablement Engine team to align with application team leaders and make sure that communication is clear across all application teams. For more information about communication and project transparency, see the Project governance playbook for AWS large migrations.
Have you selected a backup and recovery solution, and does it work with migrated workloads?	Backup and recovery tools are critical for cloud operations. Your existing tools might not work in the cloud because of compatibility or licensing reasons. As part of the design, you need to decide which backup and recovery tools to use for the workload in the AWS Cloud.	Select backup and recovery tools before starting the migration. Make sure the migration team incorporates instructions for setting up backup and recovery in the migration patterns. We recommend building an automation script that replaces or reuses the backup and recovery tools, as needed.
Have you identified all shared services and deployed them in the landing zone?	Shared services are services that support multiple applications, such as email, Active Directory, or shared database environments. You typically need to deploy shared services in the cloud before the migration so that migrated applications perform as expected.	Schedule a deep dive with the infrastructure team and application team leaders before completing the landing zone design. Review and confirm the list of shared services that you must deploy in the cloud before starting the migration. The most common shared services are Active Directory, network devices, Domain Name System (DNS), and infrastructure software.
Have you reviewed AWS service quotas for your target AWS Region and account?	Every AWS service has a service quota. Some of these quotas can be increased. It is important to review quotas before cutover. If insufficient resources are available, the cutover might fail.	Review the migration plan. For any target account that requires an increased service quota, request an increase. For more information and instructions, see AWS service quotas.
Do you need to upgrade your AWS Support plan?	AWS Enterprise support plan offers 24/7 phone support and faster response times than other plans. Because the cutover window is usually very short, having access to an experienced engineer to help resolve cutover issues can be critical to the success of a large migration.	Contact your AWS account team to discuss different support options and select the appropriate support plan for your large migration project.
Have you notified your AWS technical account manager (TAM) about your large migration plan?	The AWS Enterprise On-Ramp support team assigns a pool of Technical Account Managers (TAMs) who coordinate access to proactive programs, preventative programs, and AWS subject matter experts. Your TAMs can schedule availability of support resources as needed.	Notify your AWS technical account manager of your upcoming large migration project and share your migration plan. Your TAMs will make sure AWS support resources are available when needed. For example, your TAMs can schedule a support engineer during cutover, and the engineer can help mitigate technical issues and streamline the cutover.

Security considerations

Have you considered?	Description	Actions
Have you identified AWS Identity and Access Management (IAM) roles and policies for access management?	Manage identity and access for all members of your large migration project. By attaching IAM roles to the migrated resources and defining access policies, you control who can access the migrated resources in the cloud.	Work with the migration team to identify the roles and responsibilities. Determine which roles can access which AWS account, and identify the level of access that each role has. Work with the security teams to validate that the IAM roles are correct for each target AWS resource.
Are there any compliance requirements for your workloads?	Workloads might have different compliance requirements, such as the Health Insurance Portability and Accountability Act (HIPAA) or payment card industry Data Security Standard (PCI DSS). You must identify these requirements before the migration and plan for how to meet them.	Work with compliance team and portfolio team to identify the compliance requirements for each application, and design your target AWS account accordingly. For example, you might need to migrate some workloads to AWS GovCloud (US) or to a specific AWS Region. We recommend that you document the compliance requirements for each application so that you can use this information later in the application prioritization and wave planning process.
Does your security team need to review and approve any tools or services that you plan to use during the migration?	A large migration project to the AWS Cloud uses many services, such as AWS Application Migration Service, AWS Database Migration Service (AWS DMS), AWS DataSync, and portfolio discovery tools (such as Flexera One). Some organizations require that all new tools and services are approved before use.	Work with the migration team to identify all of the tools, services, and applications that you expect to use in the migration. Work with the security team to review the company policies and approve these tools accordingly before the migration starts.