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:
- Instance type: Amazon provides a variety of instance types for services such as Amazon EC2, Amazon RDS, AWS Database Migration Service (AWS DMS) etc. There may be scenarios where certain instance types are not yet available in a Region or where older instance types are not available in new Regions. Depending on the service, there may be different ways to ensure that the instance type exists in a Region. For example, for Amazon EC2, you can use the describe-instance-type-offerings API.
- Marketplace/Third-party products: Community Amazon Machine Images (AMI) and AWS Marketplace products such as marketplace AMI and container images may not be available in all Regions. There may also be licensing restrictions when using third-party products in another Region. Review the use of any third-party products in your workload and follow up with the relevant AWS partner for more information.
- Service and/or feature availability: There may be scenarios where a particular service is not yet available in a Region or the service is available, but certain features aren’t. There may also be cases where you find some APIs are not supported in certain regions, or there are differences in them. In all of these cases, you will find the service availability information in the product documentation page. You can identify regional feature parity using the AWS CloudFormation registry. Some examples include:
- Features supported in Amazon RDS by AWS Region and DB engine as listed in the product documentation.
- Amazon S3 supports authenticating requests using Signature Version 2 only in older Regions. This needs to be changed to use Signature Version 4 which is supported in all Regions.
- Amazon S3 dash Region endpoints are supported only in older Regions and need to be converted to S3 dot Region endpoints in newer Regions.
- Operational services such as AWS CloudShell may not be available in all Regions. In other cases, operational features such as the EC2 serial console may not be available in all Regions.
- Runtime versions: There may be scenarios where a particular runtime version is not available for a managed service in the target Region. The product documentation contains the versions supported within a Region. For example, Lambda does not support runtimes that are set to be deprecated within the next six months in new Regions.
- AWS Service Quotas: Anticipate the required capacity for your workload in the target Region and plan accordingly. The default AWS service quotas for each AWS service are, unless otherwise noted, Region-specific, and these can vary for each Region. Increases can be requested for some quotas while other quotas cannot be increased. Service quotas are available in the Service Quotas console.
- Certification/Compliance: Consult the most recent reports in AWS Artifact to verify if the target Region meets the specific compliance requirements for your workload.
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.