AWS Cloud Operations Blog

Considerations for migrating workloads between AWS Regions

Amazon Web Services (AWS) provides a highly reliable, scalable, and low-cost cloud infrastructure platform in many Regions around the world. AWS has designed these Regions to be isolated from each other. This design enables applications to achieve a high level of fault tolerance and stability. Regions are further grouped into partitions such as aws, aws-gov, aws-cn and aws-iso. The partitions are more isolated than Regions from a network and security perspective.

As AWS opens up new Regions, customers may look to migrate workloads from existing Regions for reasons such as improving latency or meeting new compliance requirements. Another common scenario is independent software vendors (ISV) who want to expand their customer base by extending their product offering to a new Region. Embarking on such a migration requires going through the migration journey of assessing the source environment, mobilizing resources to lay the foundation, and finally, migrating the workloads.

This post covers some important considerations when migrating workloads from one AWS Region to another within the same partition. Migrating across partitions requires additional considerations that aren’t covered in this blog post.

Build a business case and consider the cost implications

As with any migration, it is recommended to start with the assess phase and develop a business case. Document the reasons for the migration and quantify and qualify the benefits to align stakeholders and executives. For example, if you are migrating to improve user experience, document the number of potential users affected and the benefits in terms of latency and business value.

Evaluate the cost to migrate your workloads to the target Region. Apart from the usual migration costs such as project execution, double bubble and others, consider the following costs:

  • Service price: As service prices vary in each Region, explore the AWS service price points and create estimates for your workload in the target Region.
  • Spending commitment: Review your spending commitments, such as Amazon EC2 Reserved Instances (RI) and AWS Savings Plans as their scope may be limited to a Region. You have the option to sell your existing Amazon EC2 Reserved Instance in the Reserved Instances Marketplace. You can also purchase Reserved Instances in the target Region from the Reserved Instance Marketplace or directly from AWS. For more detailed information about how to buy and sell Reserved Instances, see Sell in the Reserved Instance Marketplace and Amazon EC2 Reserved Instance Marketplace.
  • Egress costs: There is an egress cost for moving data out of the existing Region into the target Region. However, there is no ingress cost for moving data into the target Region. The egress costs vary depending on how the data is transferred, whether it is through the internet, VPC peering, AWS Transit Gateway, or another mechanism. Further information on data transfer costs is available in the Overview of Data Transfer Costs for Common Architectures blog post.

Decide the aspects of the workload to migrate

Identify the AWS services used in the end-to-end workflow of the workload, starting from the deployment pipeline to the day-to-day operations. Think also of the source and target dependencies, and how end users interact with the workload. Knowing this will help to set a clear scope for the migration and inform you of the full impact caused by any changes. Unlike an on-premises datacenter that customers typically exit at the end of a migration, the AWS source Region is still accessible post migration. This creates a choice on what to migrate to the target Region and what to retain in the source Region.

Some workload components to consider for migration are:

  • Configuration: An example of this would be parameter groups and option groups within Amazon Relational Database Service (Amazon RDS). Other examples are configurations such as detailed monitoring or VPC flow logs for an Amazon Elastic Compute Cloud (Amazon EC2) instance and Amazon Virtual Private Cloud (VPC), respectively. There may be cases where you want to migrate older copies of configuration files.
  • Code/Software package: Examples of this include code/software packages available in container images in Amazon Elastic Container Registry (Amazon ECR) or functions in AWS Lambda.
  • Data: This involves migration of historical and ongoing data from the source to the target Region. This is not always required, and depends on the workload requirements. For example, retain historical data in Amazon Simple Storage Service Glacier (Amazon S3 Glacier) if it isn’t critical to run the workload in the target Region. Another example is a workload that needs to be split across Regions based on user location, and only selective data is to be moved to the target Region.
  • Supplemental Data: Data including backups, snapshots, and logs aren’t usually important for running the workload. You can retain the existing supplemental data in the source Region, and only have newly created data in the target Region.

Ensure workload compatibility in the target Region

There may be differences between Regions. These differences may be temporary as services and features are released to Regions at different schedules. Ensure the workload is compatible in the target Region prior to migration. This is done by first capturing workload details including instance types, services, software versions, quotas, etc., and then comparing them with the capabilities of the target Region. The differences between Regions can be in the following areas:

Establish the Foundation in the new Region

Establish a foundation in the target Region before migrating workloads. If the cloud foundation is already set up on AWS, extend it to the target Region. Start by enabling the target AWS Region. Next, ensure the target Region is ready for you to deploy, configure, and secure workloads and is also ready for on-going operations. Consider using AWS Control Tower for better handling of environments spread across multiple accounts and Regions.

Consider these categories when extending a foundation:

  • Infrastructure: Ensure the appropriate networking is in place in the target region. For example, setup an AWS Direct Connect connection from on-premises data centers to the target Region and configure Transit Gateway for Inter-Region peering. If this migration is to support region expansion, consider using AWS Transit Gateway Network Manager to help with centralized management and visualization. Ensure security information and event management (SIEM) solutions, firewalls, and other security appliances are in place for the target Region.
  • Security: Implement security policies and controls in the target Region to protect resources from external or internal vulnerabilities and threats. This involves multiple activities, such as updating Service Control Policies (SCP) and AWS Identity and Access Management (IAM) to allow operations in the target Regions. Other examples include leveraging multi-Region keys in AWS Key Management Service (AWS KMS) and AWS Secrets manager.
  • Business Continuity: Build resiliency into applications in the target Region to meet business and security goals, Recovery Point Objectives (RPO), and Recovery Time Objectives (RTO). You may want to select a new secondary Region for disaster recovery, where you can store a copy of your data. Update your backups and disaster recovery processes to point to the new secondary Region.
  • Operations: Ensure robust observability measures are implemented and evaluate data gathering techniques. For example, Amazon CloudWatch provides automatic features for observability across different Regions. Evaluate health checks and synthetic testing, such as canaries, within the target region to inform performance and availability metrics. When migrating customer-facing workloads, consider utilizing Amazon CloudWatch Internet Monitor to assess current and anticipated performance, as the network paths may change in the target Region.
  • Finance: Extend existing cloud financial management processes to cover the target Region. Introduce mechanisms to track spend across Regions for each application so that stakeholders have visibility for decision making.
  • Governance, Risk Management, and Compliance: Extend governance, risk and compliance processes that are managed centrally. For example, in the target Region, create a new log group in CloudWatch to collect and store environment logs centrally. Another example is to extend change management processes to the target Region to control the change lifecycle in your target Region.

Choose your migration path

The approach listed in this section assumes you are rehosting to a new Region but as with any other migration, there are several potential migration strategies. Choose your rehost path by first categorizing the AWS services in your workload based on their AWS Fault Isolation Boundaries and cross-Region capability. Then, select one of the available migration paths.

Global services

For global services including Amazon Route 53 and Amazon CloudFront, changes are typically made to configuration or code to extend the data plane to the target Region. Take the example of CloudFront, where you can configure the origin to reflect the newly created resource in the target Region. Another example is IAM, which may have hard-coded access to resources in certain regions that need to be altered.

Regional and zonal services with cross-Region capability

There are a growing number of services with cross-Region capability such as AWS KMS, Amazon Aurora Global Database, and Amazon DynamoDB. With these services, configuration changes are required to extend the resource to the target Region. An example of this is AWS KMS, where replica keys can be created in another Region when using a customer managed key. Secondary Regions are also supported with Amazon Aurora Global databases.

In many of these cases, you can promote the resource in the secondary Region to be independent. You can then delete the resource in the source Region thereby effectively migrating the resource from the source to the target Region. However, there are some cases, such as in AWS KMS, where the home region of the customer managed key cannot be changed.

There are additional options for migrating these types of services, as listed in the All Other Services section.

All Other Services

For most regional and zonal services, you can use migration mechanisms similar to an on-premises data center to AWS Cloud migration. This commonly involves one of the three options – redeploy, restore, or replicate.

  • Redeploy: You can redeploy in the target Region for services such as Amazon ECR, Lambda, Amazon Simple Queue Service (Amazon SQS), and stateless applications in Amazon EC2. There are some services such as AWS DMS and AWS Elastic Disaster Recovery where the only option is to redeploy and reconfigure the service in the target Region.
  • Restore: You can take backups/snapshots and restore them in the target Region for services such as Amazon EC2 and Amazon RDS.
  • Replicate: You can use replication tools such as AWS Application Migration Service for server migration and AWS DataSync for Amazon FSx. Some software such as PostgreSQL or MySQL offer native replication methods that can also be used for migrating workloads. If using an AWS replication tool, check the availability of the service and its features in the source and target Region.

While this approach is generally applicable to AWS partner solutions, we recommend working with your partner to learn more about the available options. Remember to update other components including DevOps pipelines, operational scripts/processes, and documentation such as operational runbooks and playbooks to reflect the change in Region.

Conclusion

Comprehensive planning and testing are imperative when undertaking any type of migration, including cross-Region migrations. Customers should plan for all elements of the migration, including failback processes for unanticipated outcomes. AWS makes this process easier by providing multiple migration paths, tools, and the ability to retain the existing infrastructure until the migration is successfully completed.

Reach out to your AWS contact and support team if you have questions about migrating workloads between AWS Regions.

About the authors

Vineedh George

Vineedh George

Vineedh George is a Solutions Architect helping organizations accelerate their adoption of cloud-based solutions. He is passionate about identifying and solving problems that deliver value.

Bryn Price

Bryn Price

Bryn Price is a technologist, paragliding pilot, and Senior Specialist Solutions Architect at AWS having more than 20 years of technology experience within various industries, including telecommunications, banking, and software companies. He is now focusing on helping customers modernize their technology and transform their business to SaaS. He loves defying gravity and discussion of any topic, from migration to microservices.

Harpreet Virk

Harpreet Virk

Harpreet Virk is a Senior Modernization Solutions Architect who is passionate about databases and helping customers migrate and modernize their workload into AWS. He has over 23 years of experience in large enterprises and extensive experience in databases and managing large database teams.

Mike Kuznetsov

Mike Kuznetsov

Mike Kuznetsov is a Principal Migration and Modernization Solutions Architect at AWS. He works with large enterprise customers, helping them to rehost and modernize applications at scale as they migrate to AWS. He enjoys solving complex technical challenges to unblock customer migrations. In his free time, he loves to spend time with his family and spark curiosity in his kids.