Skip to main content
Cloud_migration

Cloud Migration


1: Introduction

AWS announced on the 13th of December 2016 the immediate availability of the new Europe (London) Region. The London Region joined Ireland and Frankfurt as AWS’s third European location, and provides customers with a new option for end users and applications benefiting from infrastructure located in Europe. 

The new London Region is currently available for multiple services, including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), and Amazon Relational Database Service (Amazon RDS).

It is clear AWS has positioned this very well, especially in light of the impending exit of the UK from the European Union.

“In light of the post-Brexit vote, I wanted to reassure our customers we see the UK as a fast innovator, a huge talent pool and a fast adopter of technology trends. We at AWS will continue to be an inward investor in the UK and will continue on a path to launch a UK region at the end of the year. Our message is to keep calm and keep on innovating in the UK, in cloud computing and AWS” said Gavin Jackson, AWS UK, Ireland and Europe managing director.

 

2: Why Move Data Across AWS Regions?

Post-Brexit, UK companies will need to think about what data they own and where it is stored - so there are in-line with the UK data jurisdiction rules. 

Data jurisdiction under the combined regimen of the DPA, GDPR (including transition from the DPA), Investigatory Powers Act 2016 and then the subsequent legislative compliance upon Brexit, means businesses of any size, based in the UK, are going to have a tumultuous few years catching up with all the legislative changes. Not just theirs, but also their clients’, who will need to have assurances about their data, especially in the reach of UK investigatory powers cross jurisdiction, into the EU.

Companies will have to seriously consider how they split companies to maintain a distinct, clear and unambiguous separation between EU data jurisdiction and UK jurisdiction. It may be that a non-UK holding company might have to be formed and the UK company separated out completely from the rest of EU operations. This would include assets in the cloud.

AWS has positioned itself in such a way as to be able to take advantage of Brexit. It is one of those companies whose cloud division is indifferent to the result. 

Thus, it is their ability to move between regions that makes AWS what it is. When we finally leave the EU, London has its own data centre which, like Frankfurt, has two availability zones, separate from the EU. This is enough for most applications, but for those applications requiring a third availability zone, then either EU transfer is required, or a second vendor is required. Hence, senior IT personnel, Enterprise Architects and CIO/CTO executives will have to think hard about how they want to host their data and run scenario analyses to verify they will work.

 

3: The Challenges

3.1: Missing Services In The AWS Target Region

While most AWS services operate within a region, the following services operate across all regions and require no migration:

  • WS Identity and Access Management (AWS IAM)
  • AWS Management Console
  • Amazon CloudWatch

Furthermore, as all services are accessible using API endpoints, you do not necessarily need to migrate all components of your architecture to the new region depending on your application. 

When planning a migration to a new region, we recommend that you check what AWS products and services are available in that region.

Not everything is available in the London Region. Non-global AWS services will slowly migrate across to the London Region over time. Yet, it still has a lot even out of the box. Looking at the EC2 instances, most of the general-purpose setups are there.

One of the major challenges of moving data to AWS London Region is that only HVM is supported for Linux AMI Virtualization Types. This could be a problem if you want to migrate an existing EC2 instance with PV virtualization type from another region, as you would not be able to do it with ease, particularly if you have an image from the marketplace as instances launched from a Marketplace; AMI cannot be converted. You should backup your data and migrate your workload to a new HVM instance manually.

Migration of AMIs across regions is supported using the EC2 AMI Copy function. AMI Copy enables you to copy an AMI to as many regions as you want from the AWS Management Console, the Amazon EC2 CLI, or the Amazon EC2 API. AMI Copy is available for AMIs backed by Amazon Elastic Block Store (EBS) and instance store-backed AMIs and is operating system-agnostic.

Each copy of an AMI results in a new AMI with its own unique AMI ID. Any changes made to the source AMI during or after a copy are not propagated to the new AMI as part of the AMI copy process. You must recopy the AMI to the target regions to copy the changes made to the source AMI.

Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main difference between PV and HVM AMIs is the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.

 

3.2: Volume Of The Data To Be Transferred

Data transfer costs can be a nasty surprise for folks new to AWS—and a big headache for even the most advanced users.

Data transfer costs are fees for moving data across AWS services to and from EC2. There’s a fee for transferring data into EC2 from another AWS service, and a fee for transferring data out of EC2 to another AWS service; these fees differ for each AWS service.

It’s important to note that data transfer costs vary based on the region. For each region, there’s a cost for moving data across services within that same Region, and a different (generally greater) cost for moving data across services outside that Region. Some regions may have higher or lower data transfer costs than others, which is often based on capacity.

 

3.2.1: Making Region Selections

As a general rule, pulling across regions will result in higher data transfer fees. It’s kind of like making a local call versus a long-distance call: if all of your machines are in the same physical location, it won’t require much for them to interact and your bill will be minimal. But if you have to communicate across the country, you’re going to rack up a large phone bill (or AWS bill, as it were). The pricing for AWS S3 exemplifies this concept: whereas transferring data to and from S3 across different regions has a distinct price, transferring data to and from S3 within the same region is free.

Since pulling across regions is expensive, you’ll likely want to limit the number of regions that your data transfer spans. The cheapest solution is a data transfer route limited to a single AZ within a single region. Your next best option is a data transfer route spanning multiple AZs within the same region. Finally, a large data transfer route that has to span across multiple regions will have the most significant data transfer fees.

When you are choosing a region, keep in mind that all regional data transfer costs are not created equal. Note the variety, for example, in how much it costs to transfer up to 40 TB of data OUT of EC2 to the Internet from each region:

 

AWS_Regions

 

Businesses hoping to architect in an Asia Pacific Region, for example, might consider building in Asia Pacific Singapore over Asia Pacific Tokyo in order to minimize data transfer costs.

 

3.3: Multiple Region Multi-VPC Connectivity

Amazon Virtual Private Cloud (Amazon VPC) offers a comprehensive set of virtual networking capabilities that provide AWS customers with many options for designing and implementing networks on AWS cloud. With Amazon VPC, customers can provision logically isolated virtual networks to host their AWS resources. 

Customers can create multiple VPCs within the same region or in different regions, in the same account or in different accounts. This is useful for customers who require multiple VPCs for security, billing, regulatory, or other purposes and want to integrate AWS resources between their VPCs more easily. More often than not, these different VPCs need to communicate privately and securely with one another for sharing data or applications.

 

3.3.1: General Best Practices

When connecting multiple VPCs in different AWS Regions, there are some universal network-design principles to consider:

  • Ensure that your VPC network ranges (CIDR blocks) do not overlap.
  • Make sure the solution you choose is able to scale according to your current and future VPC connectivity needs.
  • Ensure you implement a highly available (HA) design with no single point of failure.
  • Consider your data-transfer needs, as this will affect the solution you choose. 
  • Use network equipment that supports IPsec, VPN tunnels and Border Gateway Protocol (BGP), when applicable.
  • Connect only those VPCs that really need to communicate with each other.

 

4: The Strategy

4.1: Data Transfer Within AWS

There are two aspects to data transfer within AWS:

 

4.1.1: Data Transfer Across Regions:

Data transfer between AWS services and across AWS regions is treated as internet data transfer and it is charged at $0.02/GB (outgoing data transfer). These costs fluctuate a lot depending on the region (e.g. all data transfer from AWS Singapore to other AWS regions is charged at $0.09/GB).

 

Data transfer into an AWS region from any service in any other region is free.

 

4.1.2: Data Transfer Within A Region:

Inter-regional AWS data transfer costs depend on whether data is being exchanged within an availability zone or across availability zones.

a) Within availability zone (AZ):

Data transfer costs for transferring data in the same region and within the same availability zone are zero, with one caveat. You must be using a private IP address.

If you are using a public or Elastic IPv4 address or IPv6 address data transfer out from EC2 will be charged at 0,01/GB. In the same way, data transfer into AWS EC2 will be charged at 0.01/GB if using a public or Elastic IPv4 address or IPv6 address.

b) Across availability zones in the same region:

Data transfer between AWS services located in the same region but in different availability zones is considered as regional data transfer and is charged at $ 0.01/GB (outgoing data transfer).

In the same way, data transfer into EC2 from an AWS service in another availability zone is charged at $ 0.01/GB.

 

4.2: Minimizing Data Transfer Costs

Minimizing data transfer costs depends on designing an infrastructure in which data flows along the least expensive routes. Since the cost of a data transfer route is generally determined by which service types and regions are involved, minimizing those fees will come down to your selection of service types and regions, and the direction of data flow across them.

 

4.2.1: How To Minimize AWS Data Transfer Costs

Minimizing AWS data transfer costs should always be a multi-pronged strategy. Here are a few tips:

  • AWS data transfer costs are generally higher for data transfer between regions as compared to inter-region data transfer between availability zones.
  • Data transfer costs between availability zones are in turn higher as compared to costs for data transfer within an availability zone.

In general, you can say that costs are the highest if data is transferred between regions. They get lower if you transfer data between availability zones within a region and are the lowest if you transfer data within an availability zone.

  • Architect your systems so there’s a minimal data transfer across AWS regions or availability zones.
  • Architect your AWS environment such that data transfer is restricted to within an availability zone or at the most within a region.
  • Since different AWS regions have different associated data transfer costs, it is always a good idea to look at the cost structure of different candidate regions before deciding about using a region.
  • Whenever possible try to use private IP addresses instead of public or elastic IP addresses.

 

4.3: Automation Scripts

It’s no secret that migrating software and services from an on-premises environment to the cloud entails unique considerations and requirements. To provide confidence in the outcome of your migration, your migration strategy needs to scale easily. This means that a large part of your workflow must be automated. There is no shortage of documentation on why automation in the cloud is important. This approach is still valid when you plan to migrate from an AWS region to another.

One of the challenges when executing a rehost is the amount of time it takes to manually confirm that a migrated application is performing as expected. Migrations that incorporate automation and rapid testing pipelines to validate proper migration are not only more likely to succeed but also improve efficiency as you take advantage of repeatable processes and decrease manual verification times.

4.3.1: Docker & AWS

Currently, most of our projects are using containers, and deploying microservices or distributed applications on production systems with Docker is becoming the new normal. Migrating your application from one region to another becomes mostly trivial with containers and with the new AWS containers services announced last week such Amazon Elastic Container Service for Kubernetes (EKS) and AWS Fargate, it becomes easier than ever to manage your container clusters on your production environment within AWS.

4.3.2: Migrating With AWS CloudFormation

AWS CloudFormation gives developers and systems administrators an easier way to create and manage a collection of related AWS resources, enabling them to update those resources in an orderly and predictable fashion.

You can use AWS CloudFormation sample templates or create your own templates to describe the AWS resources and any associated dependencies or runtime parameters required to run applications.

While many customers use AWS CloudFormation to create development, test and multiple production environments within a single AWS region, these same templates can be reused in other regions. You can address disaster recovery and region migration scenarios by running such a template with minor modifications in another region.

 

4.4: Simulation And Testing

Tests are a critical part of the migration process. They ensure quality, but more importantly, they help find issues early in the development phase, lowering the cost of fixing them later during the process.

 

4.4.1: Benefits Of Automated Tests Over Manual Tests

At least three major benefits of automation are evident:

  • Preservation of the QA engineer’s precise intent and the elimination of variance in test steps. The more a test case is automated, the more reliable the test’s steps shall be. A human testing manually will occasionally fat-finger a button, enter a typo, or absent-mindedly repeat a command.
  • Protection against quality regressions. Product developer unit tests provide a strong guard against this issue at the module level.
  • Long-term monitoring over extended deployments and load testing.

 

5: Conclusions

When you undertake any type of system migration, we recommend comprehensive planning and testing. 

You should be sure to plan all elements of the migration, with failback processes for unanticipated outcomes. 

AWS makes this process easier by enabling cost-effective testing and the ability to retain the existing system infrastructure until the migration is successfully completed.


About the author: Giuseppe Malanga
Giuseppe is a Solution Architect at Zaizi with 7 years of experience in data management, data integration and business processes. He has been involved in several Alfresco and Activiti projects, for private and public sector, hosted on-premise or in the cloud. In recent months, he designed and implemented case management solutions for public sector, which has required the integration between Activiti and microservices.