AWS, Azure or Google: Do the differences between cloud providers really matter?
When evaluating public cloud providers, it is easy to get hung up on the differences. AWS, Microsoft Azure, and Google Cloud each have their own terminology, pricing, service catalog, and purchasing variations. But do these differences ultimately matter?
Though we are able to align comparable products across AWS, Azure, and Google Cloud, there are of course differences between these offerings. In fact, with the number of products and services available today (we’ve counted 176 from AWS alone), comparing each is beyond the scope of this article.
For our purposes, we can compare what is still the core product for cloud service providers: compute. Compute products make up about two thirds of most companies’ cloud bills, so the similarities and differences here will account for the core of most users’ cloud experiences.
Here’s a brief comparison of the compute option features across cloud providers:
Of course, if you plan to make heavy use of a particular service, such as Function-as-a-Service/serverless, you’ll want to do a detailed comparison of those offerings on their own.
That covers functionality. How do the prices compare? One way to do this is by selecting a particular resource type, finding comparable versions across the cloud providers, and comparing prices. Here’s an example of a few instances’ costs as of this writing (all are Linux OS):
For more accurate results, pull up each cloud provider’s price list. Of course, not all instance types will be as easy to compare across providers – especially once you get outside the core compute offerings into options that are more variable, more configurable, and perhaps even charged differently (in fact, AWS and Google actually charge per second).
Note that AWS and Azure list distinct prices for instance types with the Windows OS, while Google Cloud adds a per-core license charge, on top of the base instance cost.
The table above represents the default On Demand pricing options. However, each provider offers a variety of methods to reduce these base costs, which we’ll look at in the Purchasing Options section.
At first glance, it may seem like the cloud providers each have a unique spread of offerings. But many of these products and services are quite similar once you get the names aligned. Here are a few examples:
Obviously, this is not a sign of substantive differences in offerings – and just goes to show that the providers are often more similar than it might appear at first glance.
Comparisons of the myriad purchasing options are worth several articles on their own, so I’ll keep it high level here. These are the most commonly used – and discussed – options to lower costs from the listed On Demand prices for AWS, Microsoft Azure, and Google Cloud.
Each of the major cloud providers offers a way for customers to purchase compute capacity in advance in exchange for a discount: AWS Reserved Instances, Azure Reserved Virtual Machine Instances, and Google Committed Use discounts. There are a few interesting variations, for example, AWS offers an option to purchase “Convertible Reserved Instances”, which allow reservations to be exchanged across families, operating systems, and instance sizes. On the other hand, Azure offers similar flexibility in their core Reserved VM option. Google Cloud’s program is somewhat more flexible regarding resources, as customers must only select a number of vCPUs and memory, rather than a specific instance size and type.
What about if you change your mind? AWS users have the option to resell their reservations on a marketplace if they decide they’re no longer needed, while Azure users will pay a penalty to cancel, and Google users cannot cancel.
Spot and preemptible instances
Another discounting mechanism is the idea of spot instances in AWS, low-priority VMs in Azure, and preemptible VMs, as they’re called on Google. These options allow users to purchase unused capacity for a steep discount. The cost of this discount is that these instances can be interrupted (or perhaps Azure puts it best with their “evicted” term) in favor of higher priority demand – i.e. someone who paid more. For this reason, this pricing structure is best used for fault-tolerant applications and short-lived processes, such as financial modeling, rendering, and testing. While there are variations in the exact mechanisms for purchasing and using these instance types across clouds, they have similar discount amounts and use cases.
Sustained use discounts
Google Cloud Platform offers another cost-saving option that doesn’t have a direct equivalent in AWS or Azure: Sustained Use Discounts. This is an automatic, built-in discount for compute capacity, giving you a larger percentage off the more you run the instance. Be aware that the GCP prices listed can be somewhat misleading, as a sustained use discount is already built in, assuming full-month usage – but it is nice to see the cloud provider looking after its customers and requiring no extra cost or work for this discount.
A last sort of “purchasing option” is related to contract agreements. With all three major cloud providers, enterprise contracts are available. Typically, these are aimed at enterprise customers, and encourage large companies to commit to specific levels of usage and spend in exchange for an across-the-board discount – for example, AWS EDPs, Azure Enterprise Agreements. As these are not published options and will depend on the size of your infrastructure, your relationship with the cloud provider, etc., it’s hard to say what impact this will have on your bill and how it will compare between clouds.
The 'it' factor
There’s also just the pure perception of the differences between cloud providers.
For instance, some may perceive Azure as a bit stodgy, while Google Cloud seems slick but perhaps less performant than AWS. Some appreciate AWS and Azure’s enterprise support more and find Google Cloud lacking here, but this is changing as Google onboards more large customers and focuses on enterprise compatibility.
There are also perceptions regarding ease of use, but actually, we find these to be most affected by the platform you’re used to using. Ultimately, whatever you’re most familiar with is going to be the easiest – and any can be learned.
Do the differences really matter?
On some of the factors we went through above, the cloud providers do have variations. But on many variables, the providers and their offerings are so similar as to be equivalent. If there’s a particular area that’s especially important to your business (such as serverless, or integration with Microsoft applications), you may find that it becomes the deciding factor.
The fact of the matter is, you’re likely to be using multiple clouds soon, if you’re not already – so you will have access to the advantages of each provider. Additionally, applications and data are now more portable than ever due to containers.
So, prepare yourself and your environment for a multi-cloud reality. Build your applications to avoid vendor lock-in. Use cloud-agnostic tools where possible to take advantage of the benefits of abstraction layers.
Even if you’re only considering one cloud at the moment, these choices will benefit you in the long run. And remember: if your company is telling you to use a specific cloud provider, or an obscure requirement drives you to one in particular – don’t worry. The differences don’t matter that much.
Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.
- » Microsoft beats AWS to $10bn JEDI contract: Defining multi-cloud and analysing administrative influence
- » If your enterprise is still on the fence around cloud - here's what you need to know today
- » A guide to enterprise cloud cost management – understanding and reducing costs
- » Why cloud IT infrastructure demand continues to fluctuate as 2019 draws to a close
- » Improving application performance in the age of complex infrastructure: A guide