Cloud vendor lock-in: 4 real-life scenarios and lessons learned

What exactly does getting locked-in with a cloud vendor mean? Here are 4 scenarios that show how vendor lock-in works on real-life examples.

Przemek Królik

Nov 28, 2022 | 7 min read

The rise of cloud computing caused massive disruption across the tech industry. There’s hardly any industry left today that hasn’t been transformed by cloud services.

From large enterprises to tiny startups - everyone is betting on the accessibility, scalability, and flexibility of the cloud in building digital capabilities or products.

But over time, the public cloud computing landscape became dominated by three major players: Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure. These and many other cloud vendors design their services in a way that makes switching to alternatives painful for businesses.

As more and more companies migrate to the public cloud, the experience of vendor lock-in becomes more common.

But what exactly does getting locked-in with a cloud vendor mean? Here are 4 real-life scenarios that show why everyone who uses public cloud services should be interested in this topic.

What is cloud vendor lock-in?

Vendor lock-in happens when you depend on a vendor for products and services because switching to another service is too painful (costly, difficult, and time-consuming).

In the cloud world, getting locked-in means that you can’t easily switch vendors without encountering obstacles like excessive fees, legal restrictions, or technological incompatibility.

Why is getting locked into cloud services a problem?

Vendor lock-in comes with one primary problem: leaves you vulnerable to any modifications made by the vendor (be it in pricing or functionalities).

Let’s imagine that you have an application running on AWS. You decide to switch to Google Cloud Platform because it offers much better rates for the type of virtual machines you’re using, in the same region. Or, because you want to use the incredibly powerful Big Data tools that Google offers.

It doesn’t matter what your reason is - sooner or later, you’re going to discover that you’re locked in.

AWS and Google Cloud Platform have some specifics (like semantics or APIs) that don’t match. So, moving apps or data across them is very difficult and expensive.

This is the gist of the vendor lock-in problem: the lack of standardization between cloud providers shuts the doors to interoperability and portability of applications and data.

But don’t worry, there’s a way out.

Here are 4 scenarios that show how vendor lock-in works on real-life examples and what you can do to prevent this from happening to your business.

Real-life vendor lock-in scenarios and lessons learned

1. Cloud outage = your product’s downtime

Outages happen even to the largest cloud providers, leaving a trail of affected services behind them.

Do you remember the two major outages AWS and Google Cloud experienced last year? The AWS outage caused downtime to services from major companies - from Adobe and Autodesk to New York City’s Metropolitan Transport Authority and the Washington Post!

One failure at Google and thousands of people get blocked because they can’t log into their Gmail, Calendar, and other Google Cloud applications.

What if you’re a startup preparing to launch a marketing campaign and are running your application on Google?

If you don’t have a plan B, you’re stuck with whatever happens to your cloud provider.

Lesson learned: Have a solid Disaster Recovery/Disaster Prevention plan in place. Take advantage of solutions like hot/cold regions or multi-cloud to support your application even when your cloud vendor goes down. Don’t lose your brand reputation because a data center got burned.

2. High egress fees might break your wallet

Putting data on the cloud is free. Most data transfers between internal cloud-based services within the same cloud computing area are free. But transferring data to a different area or out of that cloud service altogether comes at a charge.

And sometimes, companies forget about that. Only later do they discover that one of their services based on moving data from one provider to another is causing their cloud bill to snowball.

An internal document leaked from AWS demonstrated this point really well.

Apple was charged $50 million in data transfer fees in just one year.

Pinterest had to spend over $20 million. Netflix and Airbnb were charged more than $15 million.

All of these companies buy hundreds of millions worth of public cloud services each year, so maybe they just didn’t notice burning $15 million on egress fees?

This isn't very likely.

Lesson learned: Pay attention to your vendor’s egress fees and know what you’re getting into before signing the contract. This is especially important if you’re reserving capacity in advance for one or three years.

Implement a solution that monitors and reports on the egress fees if you move data between areas. Balance ingress and egress to avoid charges spiraling out of control.

Stay updated

Get informed about the most interesting MasterBorn news.

Your email

Submit

Send me interesting information about MasterBorn by email.

Check our Policy to know how we process your personal data.

3. The vendor goes out of business or sunsets a service

Ok, I admit that going out of business isn’t a likely scenario for a tech giant like Amazon, Google, or Microsoft.

But it’s potentially realistic for a smaller provider. Do you remember how a data center belonging to the French cloud vendor OVHcloud burned down in March? What if the fire consumed other data centers as well and the company never recovered from it, shutting down operation?

Here’s another scenario you should consider:

The vendor might change their product offering and sunset a service you’re using.

For example, back in 2013 Nirvanix stopped offering cloud services and gave customers only two weeks’ notice to move data off of their platform.

Lesson learned: Have a plan B for one of those scenarios. Don’t rely on one provider too much and always keep your eye open to other options. Consider running applications in cloud-agnostic solutions or going multi-cloud and gaining experience across different cloud platforms to move applications smoothly if anything like that happens.

4. You miss out on optimization opportunities

This is the hidden cost of vendor lock-in.

When you put all your eggs into one AWS or Google Cloud basket, you can’t use resources from other vendors.

And who knows, maybe these resources could give you better performance at a lower price?

Consider this example:

Let’s say that you’re running your application on a compute-optimized virtual machine on Google Cloud (c2-standard-4) in the US West region. The instance has 4 CPUs and 8 GiB RAm. It costs $0.25 per hour. Not a bad deal?

But look, here’s an AWS instance called c6g.xlarge that has the exact same parameters and costs only $0.204!

When you’re locked into Google Cloud, you can’t take advantage of this savings opportunity and will end up paying more for the same resources.

Lesson learned: Be wary while committing to specific cloud resources (for example, AWS Reserved Instances). Buying capacity upfront might give you a discount but will lock you out of other opportunities. Developing a multi-cloud strategy may give your teams maximum flexibility in chasing better pricing for the same (or even better) performance.

How to avoid vendor lock-in?

As you can see, vendor lock-in has some pretty dire consequences.

That’s why so many companies are now focusing on building applications that are vendor-neutral and fully portable.

But it takes expert knowledge of the public cloud ecosystem to avoid the fate of getting locked in.

Team up with experts who know the cloud inside out and can help you set up an optimal infrastructure that balances performance/cost and helps you avoid vendor lock-in.