How to approach a GCP-to-AWS migration

Migration cycles and process

A cloud migration typically encompasses a series of steps. These are best practices that should be followed regardless of the destination, but we can use them specifically to guide a GCP-to-AWS migration.

• Discovery. Assess the organization's application portfolio and find the workloads subject to migration. Prioritize by department or business need, and collect any necessary workload metrics.
• Design and build. Design your AWS architecture, along with any underlying operational components, such as storage and database services. Then, provision and interconnect your new resources and services, and migrate any data or databases.
• Integrate and test. Connect to the network. Test the application, followed by small user groups, to validate the performance and signal user acceptance of the migrated workload. Adjust and optimize as needed, typically in parallel to the workload still running in production on GCP.
• Cut over. Once the AWS environment is optimized and validated, redirect live traffic there and start its production use. Use a rollback procedure if problems arise.

Lift and shift limitations

A cloud-to-cloud migration involves different considerations than a transition from a private data center to the cloud. AWS and GCP provide hundreds of types of IT resources, delivered as a service, at a global scale; an enterprise data center is inherently dissimilar.

That's not to say you don't face challenges when moving from GCP to AWS. In fact, it can sometimes be harder.

For example, you could attempt a lift and shift migration, a technique commonly used for moving from a private data center. This is often called rehosting. Ideally, the workload, data and associated services are moved from one environment to another on an almost 1:1 basis.

Tools like AWS Server Migration Service (SMS) help, but moving between cloud providers can be more complicated because of differences in configurations and operating system support. In most cases, an existing VM running in one cloud must first be captured or saved as a standard file format and then moved into an instance prepared in another cloud.

To move from GCP to AWS, Amazon's agent-based CloudEndure Migration can speed the lift-and-shift approach. It can rehost VMs from multiple sources, including physical, virtual and other clouds. It also minimizes challenges with compatibility, performance disruptions, long cutover windows or long-distance data transfers.

For databases, AWS Database Migration Service can move a commercial database without disrupting the source database and maintaining access for applications. You could also use the service to transition to a native AWS database service, such as Amazon Aurora.

If a direct conversion isn't possible, use a combination of migration tools. In a GCP-to-AWS migration, you could use Google's Migrate for Compute Engine tool to move a workload from GCP to the local data center first and then use a tool such as AWS SMS to move it from the local data center to AWS. The workload should be tested and validated at every step of the process.

There are also third-party, cloud-agnostic tools designed to migrate from GCP to AWS, including Carbonite Migrate, Corent SurPass and NetApp Cloud Volumes ONTAP.

Rebuild and rewrite considerations

Cloud architects will more often look to rebuild their apps as part of a cloud-to-cloud migration. They'll rearchitect the workload using features provided by the target cloud to accommodate the migrated code and data. AWS and Google offer similar services, but the architectures aren't 1:1.

Cloud architects may also take the opportunity to adopt capabilities that weren't available in GCP, such as those included in services like AWS Outposts. They might even take it a step further and rewrite, i.e., refactor, the application. For example, if a GCP-hosted app relies on a more traditional VM-based architecture on AWS.

Before you do any of that, consider these potential differences between environments as you plan your migration.

Target region. Not all resources and services are available in all regions. Verify that AWS has a region close enough to your intended users, yet still offers the suite of resources and services necessary to architect a suitable infrastructure. Consider that GCP and AWS treat regions differently, and target region location and availability can impact a migration decision.

Networks. Complex workloads in GCP will employ VPCs, subnets and load balancers to organize and direct workload traffic. Similar network configurations must be accounted for in AWS. Other network considerations include the use of a NAT gateway for outgoing internet connections or the incorporation of dedicated high-speed connectivity through services such as AWS Direct Connect.

Server instances. Select target server instances with the minimum suitable vCPU and memory. For example, an instance in GCP with 2 GB of memory and 4 vCPUs could potentially be migrated to a m4.xlarge on AWS with 4 vCPUs and 16 GB of memory using Amazon Elastic Block Store.

Database migrations. Database migrations often need to be completed first and should be treated as dependencies. It's usually necessary to keep databases replicated or synchronized until the workload is actually cut over. For example, a database in Cloud SQL could be moved to Amazon Relational Database Service.

It can be helpful to perform tests or proof-of-principle work to test migrations between database services in advance. If this is unsuccessful, the database may need to be deployed as a workload on Amazon EC2 and not through an existing service.

Monitoring and logging. You'll need to adjust to any monitoring and logging tools to track the health and performance of the workload. Amazon monitoring services include AWS CloudTrail and Amazon CloudWatch.

Component services. A workload can depend upon an array of services, and architecting a target environment for a complex application may require challenging service migrations between GCP and AWS. For example, messaging might need to move from Pub/Sub in GCP to RabbitMQ or ActiveMQ in AWS, while Cloud DNS might move to Amazon Route 53, and storage on Persistent Disk would migrate to Amazon S3.

Cost. Standard cloud cost models are not substantially different between GCP and AWS, but the costs for their services can vary. Every compute and storage resource will impose recurring costs for the resources consumed. Many services carry a per-use cost or other fee based on the amount of usage.

Consider the cost implications of serverless computing. Both GCP and AWS charge for invocations, duration and network usage. GCP charges $0.40 per invocation beyond 2 million calls, while AWS charges $0.20 per million calls with additional pricing for compute time, network usage and free tier credits. So even when a workload can be migrated from Google Cloud Functions to AWS Lambda, the cost for running that workload in AWS can be different.

Don't overlook egress fees. Data egress from GCP can cost $0.08 per GB when moving 10 TB or more, though data ingress to the destination cloud such as AWS is free. And be mindful of the differences in AWS' and Google's discount schemes for things like long-term commitments or sustained use.

Migrate with professional services and other considerations

Turn to professional services when in-house expertise and tooling is insufficient for a migration between GCP and AWS. For example, AWS Professional Services can supplement an in-house team, adding detailed knowledge of the target cloud, such as best practices and documentation, to help develop optimized and cost-effective infrastructures. The AWS Migration Competency Partners network can also streamline migration and other operational tasks.

Finally, remember that sometimes all this effort might not be worth it. Perhaps you could be better served by a SaaS offering that does a better job than what your IT team built on GCP. In other cases, you'll go through this analysis and find a migration doesn't make any practical sense.

For example, some applications may not be suitable for migration between clouds. This is usually when the workload would require too much refactoring or cannot be operated adequately in the target cloud -- possibly because a key service is not available or does not meet SLA requirements. Those applications can be revisited and reassessed in the future. If your GCP-hosted application is older or lightly used, you can often remove it outright.