The Ops Community ⚙️

Cover image for How to Avoid Cloud Repatriation
Eyal Estrin
Eyal Estrin

Posted on • Updated on • Originally published at eyal-estrin.Medium

How to Avoid Cloud Repatriation

I have been working with public clouds since 2015, and in the past couple of months I see more and more discussions (on newsletters, LinkedIn, and technical forums) about a term called “Cloud Repatriation”.

In this post, I will share my opinion on “Cloud Repatriation” and how I believe organizations can better prepare themselves in advance, to avoid such scenarios.

What is Cloud Repatriation?

Cloud repatriation is when a company decides to move existing workloads from the public cloud to its data centers or co-location facilities.

The main reason companies decide on such a drastic move (after already investing in the public cloud) is due to cost.

About a decade ago, when companies considered moving to the public cloud, there was a myth that moving to the cloud will allow companies to save money on IT spending.

Another myth about the public cloud that caused companies to re-think about the move to the cloud was the ability to easily migrate existing workloads from the on-premise to the cloud using a "lift & shift" strategy (also known as "we will re-architect it later…"), which in the long term found out to be perhaps the worst strategy to move applications to the cloud.

I am not suggesting that the public cloud is suitable to run 100% of the workloads currently running on-premise – there are scenarios where your company would leave workloads locally due to legacy application constraints, latency issues (if there is no public cloud region in your country), or regulatory constraints.

So how do we prepare our company in advance, to avoid decisions such as going back on-premise?

Cloud Strategy

The ideal time to create a cloud strategy is before deploying the first workload in the public cloud.

Even if your company already deployed a playground for gaining experience with the cloud, it still has time to invest in a cloud strategy.

The most important thing to keep in mind is that the public cloud allows us many capabilities, with a single goal – serving our business and providing us with business value.

The goal is never to migrate to the cloud just for the sake of migration.

We always need to ask ourselves – how can we use the public cloud to enable our business?

Another important question we need to ask ourselves – what systems/applications do we currently have and which of them are we going to move to the cloud or are worth the effort to move to the cloud?

Even if our cloud strategy to going "cloud first", it does not mean 100% of our applications will be migrated to the cloud – it only means that we will review each existing or new application if they are suitable to run in the cloud, and our priority is to move applications to the cloud (when feasible and when it makes sense in terms of cost, effort and technology capabilities).

Important note – having a cloud strategy is not enough – we must review and update our strategy regularly, according to our business requirements.

Architectural Decisions

To gain the most value from the public cloud, we need to consider the most suitable way to run our applications in the cloud.

Although virtualization is still a valid option, it might not be the best option.

Moving to the public cloud is a perfect time to consider modern deployments.

Containerization is very popular both in the public cloud and in companies developing cloud-native applications.

The cloud offers us an easy way to run containers based on managed Kubernetes services, allowing us to focus on our business requirements, while leaving the maintenance of the control plan to the cloud provider.

Another option the gain benefit from the cloud is to use serverless – although each cloud provider has its alternative for running serverless (or Function as a Service), it does provide us with an easy way to run cloud-native applications, while taking benefit of the entire cloud providers eco-system.

Having a regular review of our workload architecture will allow us to make changes and take the full benefit of the public cloud – from scale, elasticity, and rich service eco-system.

Financial Management

I mentioned earlier that one of the reasons companies consider the public cloud to be more expansive than managing their data centers is because they tend to compare slightly different things.

Running our data centers requires us to take care of physical security, power, cooling, and redundancy for everything we use.

In the public cloud, the cloud provider takes responsibility for managing the data centers, including the manpower required to run their data center, and the cost of using compute, network, storage, and software license – everything is embedded as part of the price we pay for consuming resources in the cloud.

Migrating workloads to the cloud, without understanding the importance of cost or financial management aspects will lead to disappointment from the cloud or to high monthly or yearly costs.

We must understand our cloud provider(s) pricing options (from on-demand, reserved instances / saving plans, to spot instances).

We need to match the most suitable pricing option to our target service or workload, and we need to have trained employees (such as DevOps, engineers, developers, or architects) monitoring, reviewing, and regularly adjusting the pricing options to our workloads.

Failing to monitor the service cost, will end up with a high bill.

Employee Training / Awareness

This is the most important thing to invest in.

Migrating to the cloud requires investment in training our employees.

Our employees need to have a solid understanding of how services run on the cloud, what is the most suitable service to select for each workload, when to choose virtualization, and when to use modern compute services such as containers or serverless.

If we are considering multi-cloud, we need to make sure our employees are trained and knowledgeable in running various workloads and multiple services on top of multiple different cloud providers (a well-known challenge for any company).

We need to invest in training our employees about automation – from provisioning the entire environment using Infrastructure-as-Code to writing automation scripts to take actions (such as powering down idle VMs, performing data replication, and more).


Moving to the cloud might be challenging for small, medium, or legacy organizations.

Running to the cloud without preparations will be both a costly and disappointing decision.

If we prepare in advance, develop a cloud strategy, and invest in employee training, we will be able to get the most value out of the public cloud and minimize the chance for cloud repatriation.

Additional References

About the Author

Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.

Eyal is an AWS Community Builder since 2020.

You can connect with him on Twitter and LinkedIn.

Top comments (0)