How to Smoothly Exit the Cloud: Migrating Key Services

“Migrate to the cloud, ditch your hardware, and save money.”

We’ve heard this advice from all sides for the past seven years. Unfortunately, it often becomes clear too late that migrating to the cloud, or even adopting a cloud-native approach, not only fails to deliver the desired savings but can also lead to unpredictable costs and vendor lock-in. Cloud pricing is very complex, and what initially appears to be a clear advantage often turns out to be an unpleasant surprise.

Attempting to exit the cloud can then result in a major dilemma: should you rewrite half of your application and two-thirds of your business processes, or continue paying more and more for cloud services?

Can we avoid problems with cloud migration?

The simplistic advice would be: “Just don’t go to the cloud.” But that’s an oversimplified view. For example, at the beginning of a project, launching in the cloud is a very reasonable and rational choice, and it would be unfortunate to reject it outright. There are also other specific situations and projects for which a cloud-native approach is the best option. Therefore, we recommend that instead of making categorical judgments for or against the cloud, you should keep in mind when entering the cloud that you might want to leave one day.

With this mindset, you won’t get locked into the world of cloud services, and by sticking to proven standard protocols and procedures, you can maintain flexibility. Even if you are already in the cloud, it’s worth looking at your setup and considering how to escape potential lock-in. In today’s article, we will look at several key services that our clients most often deal with when leaving AWS and how to make their transfer as smooth as possible. This is by no means an exhaustive list of everything you might encounter, but from experience, I can say that getting on top of these few services can save a lot of trouble during the transition.

Elastic Kubernetes Service (EKS)

In recent years, Kubernetes (K8s) has become the de facto standard for running containerized applications. Its simplicity, automatic scaling, high availability, and easy cluster expansion with additional nodes are all advantages that K8s offers over traditional infrastructure. Kubernetes was created in 2014 for Google’s internal needs but quickly left its data centres and began to conquer the world. EKS can be run on AWS either on dedicated EC2 instances or using the Fargate tool in serverless mode.

How to migrate EKS from the public cloud?

The great advantage of EKS is its universality. Thanks to 100% compatibility with classic Kubernetes, the transition to your own infrastructure is relatively seamless. You just need to take existing deployments and send them to another cluster.

However, one thing to be a bit cautious about is the ingress settings. AWS uses ingress in the form of its balancers in EKS, so for your own K8s, you need to adjust the ingresses. In most cases, this involves a simple rewrite of the ingress class from AWS to NGINX.

EC2

EC2 virtual servers, along with S3 and RDS, are among the oldest and still very popular services that AWS offers. These servers, running on Linux or Windows and available on the ARM platform, are very similar in nature to traditional servers, making their migration from the cloud easier. Although the configuration of operating systems and applications on EC2 may be comparable to other virtualization platforms or even physical servers, you cannot assume that an EC2 configuration will work elsewhere without adjustments.

How to migrate EC2 from the public cloud?

Migrating EC2 is relatively straightforward due to their similarity to traditional servers. However, it is important to adjust cloud-specific configurations, such as load balancers and network settings, to match the new hosting environment. Special attention should also be paid to operating systems, especially if you use Amazon Linux, which may require modifications to be compatible with more common distributions like RHEL, Debian, or Ubuntu.

S3

The S3 object storage, one of AWS’s first products, now has several open-source alternatives such as MinIO and CEPH, which are fully compatible with AWS S3 and often offer additional features.

How to migrate S3 from the public cloud?

These open-source alternatives can be used for migrating S3. The key is to adjust S3 endpoints in applications to point to the new location. This is usually simple if your applications already use an abstraction layer for working with S3.

In infrastructures we build for clients at vshosting, you most often encounter implementations of MinIO or S3 on the CEPH platform because they provide excellent compatibility and scalability.

RDS

The RDS relational database service supports the most widespread database systems such as MySQL/MariaDB, PostgreSQL, MSSQL, and Oracle.

How to migrate RDS from the public cloud?

When migrating from RDS or its special version Aurora, you may face challenges in data transfer, as AWS does not allow connecting an external database in slave mode for seamless data copying. The only solution is to export data from RDS and import it into your own database solution, which requires application downtime and can be time-consuming if you have a large amount of data.

Elastic Container Service (ECS)

If you want to start using application containerization but don’t want to jump straight into full-fledged K8s, you might opt for ECS. This simple runtime environment for Docker containers, like EKS, uses the power of dedicated EC2 servers or serverless via Fargate. However, the similarity and interoperability end there. ECS is Amazon’s proprietary solution, and there is no 100% alternative for it.

How to migrate ECS from the public cloud?

Since ECS is an exclusive Amazon service, migration requires significant adjustments. On a classic Docker server, you can use existing ECS containers, but the entire deployment method needs to be rewritten from scratch as ECS configurations are not transferable. From experience, we can recommend that if you are considering dockerization, skip the step with ECS and move straight to EKS. The slightly more complicated start will quickly pay off not only in terms of much greater clarity but also in the ability to easily migrate from the cloud to your own K8s.

Lambda

Lambda is a serverless environment for running code. It is one of the first and practically the most used solutions for running applications using batch processing. On the AWS platform, you can run various applications in Lambda written in PHP, NodeJS, or Python.

How to migrate Lambda from the public cloud?

When transitioning to your own solution, consider whether you need to maintain the serverless and event-driven concept or if you can switch to full-fledged containerization. If a serverless approach is necessary, you can use several projects that implement Lambda behaviour in a classic K8s cluster, such as Knative. The downside of this transition is the need to operate the entire K8s cluster on which the functions run. With Knative, you can run functions written in various languages like PHP, NodeJS, Python, or Go, so there is no need to rewrite the application itself.

Final Notes: Gaining Control Over Your Cloud Strategy

As you can see, migrating from the cloud can be straightforward if alternatives to the most commonly used services are considered in advance. However, AWS offers other services that may not be as easily migratable. It is crucial to carefully consider all aspects before deploying new technologies in the cloud. There are certainly applications that are worth running in the cloud long-term (e.g., AI or storage in exabyte scales), but most projects can suffice with solutions that don’t close the door to moving to cheaper and more transparent alternatives.