How to Choose a Cloud Service Provider… and Why It Should Probably Be AWS

If you’re trying to figure out how to choose a cloud service provider (CSP), you might feel overwhelmed with the number of providers to choose from and the different services they offer. It’s a full-time job to keep up to date with just one of these providers, let alone all of them. There is a massive amount of information to digest when choosing between the Big Three — Microsoft Azure, Google Cloud Platform, or Amazon Web Services (AWS) — not to mention other competitors like Alibaba Cloud, Oracle Cloud, and IBM Cloud.

Your CSP is the baseline infrastructure for your entire business, making it extremely painful and expensive to switch providers. Therefore, it’s critical to make the right choice from the beginning.

The Logicata team has been working with AWS for over seventeen years (dating all the way back to the introduction of the now industry-standard S3 storage service). We have extensive experience in AWS, and we feel like we can comment on the industry as a whole because we also have plenty of direct experience with other big-name providers and talk to a lot of industry professionals with deep experience outside of AWS.

Based on our experience, we believe that AWS is as good as or better than the alternatives in almost every metric. That’s why we’ve built our business around being a managed service provider (MSP) with a strong focus on and passion for AWS. In this article, I’ll go through the step-by-step decision-making process that we recommend to our clients when choosing a CSP and why we think AWS is almost always the winner.

What to consider when choosing a cloud provider

Choosing a CSP is a big commitment, so it is important to make sure that your CSP will be an asset to your business rather than a liability. For that reason, you should consider the following factors when choosing the CSP your business will rely on: innovation, reliability, and security.

Innovation

You want a CSP that is constantly at the bleeding edge of technology since it will be able to more efficiently manage your infrastructure. Website and application stacks today are much more complicated than they were twenty years ago and are likely to only get even more so.

Small differences in features could be the difference between an okay and excellent experience for your customers. Since you are competing with other companies that are also constantly trying to improve their applications, we believe that it’s important to choose a CSP that is always innovating by building out new features and incrementally improving existing ones.

You don’t want to be in a position where competitors are taking advantage of new features from their CSP in the back-end infrastructure to improve customer experience (or decrease hosting costs!) and your CSP hasn’t kept up. This could be something like serverless functions or a new type of technology like generative AI.

Azure

Azure’s main innovations have come in the spaces of the Internet of Things (IoT) and AI. Azure was one of the first public cloud platforms to embrace deep learning models and MLOps (a combination of machine learning and DevOps) through ML Azure Services. This aligns with the company-wide goals of Microsoft, which has recently acquired a large stake in OpenAI to integrate tools like ChatGPT into AI-based search.

Google Cloud Platform

Google has an edge in big data and analytics. Analytics, especially, will be critical to your site no matter which provider you go with. Since Google developed and later open sourced Kubernetes, it has also been at the forefront of its innovation. There are obviously a lot of synergies between containerized deployment and the cloud, as there are similar motivations for each to abstract away from physical hardware.

Google Cloud Platform also has generally more mature networking capabilities. It can move data between regions more effectively than other CSPs, although this could be a double-edged sword. As there are fuzzier boundaries between regions, security could become more of an issue, although we’re not aware of any major issues like this so far.

AWS

AWS has been in the cloud infrastructure game longer than Google and Microsoft since it essentially started the cloud computing industry. AWS has a long history of constant, incremental improvement and more significant innovations, particularly around price and performance.

One fairly recent example of this is AWS’s Graviton-based instances. AWS developed its own CPU optimized for running cloud workloads. In particular, AWS worked closely with the PHP community to optimize PHP running on Graviton CPUs, speeding up execution time by 37% and improving price performance by 40%. We discussed this at length in our article about best practices while using PHP on AWS.

A critical point is that AWS is very careful not to introduce breaking changes, and when it does, it provides detailed notifications well in advance. This is a vital trust factor when running your critical infrastructure.

AWS backs up its innovation with a strong culture of customer obsession, which is its first leadership principle. This manifests itself through an obsession with cutting costs, price transparency, and constant innovation.

Reliability

There are two major components of reliability:

• Availability: your site’s or service’s uptime
• Longevity: how long the infrastructure that you’ve built on remains operational and compatible with your application

In a perfect world, all sites and services would have 100% uptime so that customers are never turned away. Unfortunately, this isn’t practical due to the realities of hardware and software upgrades, bugs, power outages, tornadoes, wildfires, etc.

Nobody can offer perfection, but providers do give specific metrics and guarantees so that they are at least on the hook to compensate you for downtime. This information can be found in each provider’s service-level agreements (SLAs).

Each provider has a separate agreement for each service. Azure’s are on separate pages of the same Word document that it publishes every month, while Google Cloud Platform and AWS have separate web pages for each service. It’s worth noting that for comparable services across different CSPs (such as managed databases from different providers), the SLA uptime and service credit values are similar, if not identical.

	Service Credit
Uptime Percentage	Azure	Google Cloud Platform	AWS
< 99.9%	10%	10%	10%
< 99%	25%	25%	30%
< 95%	100%	100%	100%

Guarantees are generally presented as a percentage of spend that is refunded or credited if uptime falls below a certain percentage. So all the guarantees related to compute between Microsoft Azure (p. 74 of the August 2023 version), Google Cloud Platform, and AWS are almost identical.

Because the guarantees are so similar, they aren’t a useful point of comparison between CSPs. It’s better to check the actual track record of service incidents to see what the reality of their service is. Guarantees are a great concept, but if your application is regularly unavailable to your users, the compensation is meaningless compared with the impact on your business.

Each provider tracks each incident with specific information that customers would care about. You can read through some of these for Azure, Google Cloud Platform, and AWS yourself to get an idea of how transparent each provider is and how committed they are to quickly jumping on issues and, ideally, preventing them in the first place. All of these reports are helpful, but we think that AWS has the most in-depth reports showing the quickest time to action.

Another component of reliability is how long the services that you build on will be supported. No matter which provider you choose, it takes a lot of work to get up and running with your business’s infrastructure. If one of the cloud services you rely on is discontinued, this work will all have to be repeated using different tools or on a different provider, risking downtime and great expense.

To minimize (and ideally eliminate) the impact of unreliable cloud infrastructure and rapidly deprecated services, you need to know the track records of different providers before making any decisions.

Azure

Azure deprecates minor functionality fairly regularly but doesn’t have a reputation for killing major services. Overall, we have little to say about Azure in this regard.

Google Cloud Platform

Unfortunately, we cannot say the same about Google Cloud Platform. Google kills services all the time. We think that the best (and most entertaining) explanation of this comes from a blog post written by ex-Google engineer Steve Yegge (warning: it contains quite a bit of foul language).

Steve is extremely frustrated that his corporate alma mater is not living up to the same standards it had when he worked there so long ago. Several of his quotes show this clearly:

“I searched for ‘deprecated’ on Google and Amazon’s developer sites, respectively, and even though AWS has hundreds more service offerings than GCP, Google’s developer docs mention deprecation around 7x as often.”

“In the Google world, deprecation means: ‘We are breaking our commitments to you.’ It really does. That’s what it ultimately means. It means they are going to force you to do some work, possibly a large amount of rework, on a regular basis, as punishment for doing what they told you to do originally — as punishment for listening to their glossy marketing on their website: Better software. Faster! You do everything they tell you to do, and you launch your application or service, and then, bang, a year or two later it breaks down.”

“I know I haven’t gone into a lot of specific details about GCP’s deprecations. I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to… I dunno, everything, has forced me to rewrite it all after at most 2–3 years, and they never automate it for you, and often there is no documented migration path at all. It’s just crickets.”

We aren’t quite as invested in Google Cloud Platform as Steve, but we’ve seen this pattern of Google regularly deprecating services as well. The most recent example that comes to mind is when it canceled its domain registration business. This has caused quite a backlash among the technical community. A domain underscores your technical infrastructure, and registering these assets takes time and effort. So for such an important service to be canceled seemingly out of the blue places a big question mark over what else might be canceled in the future.

AWS

AWS does deprecate functionality, but major functionality and service deprecation are extremely rare. It is ingrained in AWS’s culture to keep services for as long as possible. And when services are deprecated, it gives plenty of time and resources to migrate to a new solution, as exemplified by the retirement of EC2-Classic Networking in 2022 and 2023.

AWS announced the retirement of this fifteen-year-old service on July 28, 2021. The company gave clear conditions for who was affected in their post (in addition to reaching out to customers individually) and clear dates for the migration process with more than a year of lead time. AWS also reiterated its focus on avoiding the disruption of any workloads and provided strong support to help businesses understand exactly how to migrate.

AWS’s commitment to service longevity is a big factor in why we focus on them, as we’ve had problems with service deprecation in the past. Our very own Adriano dealt with this after building on the infrastructure from SoftLayer, a global provider that was acquired by IBM in 2013.

After the acquisition, IBM closed many of SoftLayer’s data centers. It contacted all customers and gave short notice, asking them to migrate their existing workloads. We personally know how big of a headache this kind of thing can be, which is why we try to avoid it for ourselves and our clients whenever possible.

Data security

When using cloud computing to manage your infrastructure, make sure that your provider has strong data security practices. Leaking sensitive data directly impacts your company’s brand image and reputation (and can also have regulatory and financially punitive implications), so it is important to make sure your provider is doing everything it can to protect this data.

No company is perfect with this, as perfect security is impossible, but it is a good idea to check out the histories of each provider’s major data breaches to get an idea of where your data will be safest.

Overall, when it comes to data security, we think that Google Cloud Platform and AWS are about even, but Azure still has work to do in order to mitigate the severity of customer data leaks. You can track cloud vulnerabilities yourself to get an idea of the current known vulnerabilities and which platforms they affect. As of the summer of 2023, this seems to validate our feeling that Azure has more serious breaches than AWS and Google Cloud Platform.

Azure

Although Azure strives to promote transparency when it comes to data breaches, we have several concerns about its security practices. One notable example had to do with the BlueBleed data breach: Microsoft accidentally leaked a massive amount of customer data through a misconfigured endpoint between 2017 and 2022 and did not feel that it had a GDPR obligation to report it to regulators after it was discovered.

Even if Microsoft had no obligation to report it to regulators by the letter of the law, it is not a good look. We’d like to see it be a little more proactive to ensure that everything is safe and secure when sensitive customer data is on the line, even if it doesn’t necessarily “have to.”

Microsoft also downplayed the impact of the leak. Again, even if it was technically correct, we would have liked to see the focus be on making its security practices more robust for its customers rather than trying to minimize its own blame.

Another major incident occurred back in 2020 when it was discovered that Microsoft accidentally exposed 250 million customer service records from as far back as 2005 by failing to password-protect a database. Microsoft quickly jumped on this issue once it became aware, but the vulnerability was technically out there for more than a decade.

We also feel that Microsoft’s data breaches are more severe than those of Google Cloud Platform or AWS. You can also check out the timeline of major Microsoft data breaches and look more deeply into each to judge for yourself.

Google Cloud Platform

As shown in its breach timeline, Google Cloud Platform has had relatively few data breaches in recent history. However, it doesn’t have such a great record of maintaining privacy, as is shown at the bottom of the timeline. In these cases, even though you don’t have to deal with the danger of your data being leaked to hackers, it may not be truly “secure” from advertisers or government agencies.

AWS

AWS also has data breaches, which you can view in its breach timeline. Despite this, we appreciate how thorough and transparent AWS is when there are breaches. It often scrubs the logs all the way back to the beginning of the service and guarantees the scope of the attack.

A quote from one such incident exemplifies this:

“Analysis of logs going back to the launch of the service have been conducted and we have conclusively determined that the only activity associated with this issue was between accounts owned by the researcher. No other customer accounts were impacted.”

What this means for us as an MSP and your business is that if (and often it’s a matter of when) a security incident occurs, we can quickly gain an accurate understanding of the magnitude of the problem and start taking corrective action to reduce the damage. We don’t have to spend valuable time going down fruitless paths and wondering if we’re still exposed somehow.

Other considerations when choosing a cloud service provider

So far, we’ve covered the major technical considerations when choosing a CSP, but there are also non-technical considerations.

For most businesses, the biggest of these is vendor lock-in, although we have a slightly different take on this. Setting up your infrastructure with a CSP costs so much time and money that we think it’s best to just pick one you trust and go all in. This makes more sense because you avoid multiplying the setup and maintenance time and costs that you could face if you were to try to keep multiple options open in case your first choice doesn’t work out.

Another important consideration is ease of adoption. Your engineering staff is likely your biggest expense, so you could save a lot of time and effort required for a months-long learning curve by going with a provider that your engineers are already familiar with. This will generally be AWS, as it has marketed itself toward engineers from the beginning. However, it could be beneficial to survey your staff to see if they have any preferences.

Even with the right know-how in-house, setting up cloud infrastructure can get complicated, so it is often critical to have a strong community to help you out when you get stuck. We recommend actually “trying out” the documentation, forums, and real-world meetups for specific communities before deciding on your provider.

You can do this by finding an isolated component of your application or service and deploying it to a CSP to experience the documentation and process firsthand and see what adaptations may have to be made before you commit to using the provider in production. You can check out the community links for Azure, Google Cloud Platform, and AWS.

Even in cases where the answers you need are available in forums and documentation, it might not make sense for your team to spend hours digging through them. It might be better to hire a professional MSP that already deeply understands the platform and has seen all of your problems before, especially when you’re dealing with larger projects. This can drastically speed up the process of deploying and maintaining your cloud infrastructure and allow your team to focus on their specialties within the business.

If you want to know how to choose a managed service provider that meets your requirements, just search the partner network directories for Azure, Google Cloud Platform, and AWS. You might even choose a CSP because it is partnered with a specific MSP that you’d like to work with. This could include partners that specialize in your industry (like FinTech, EdTech, or InsurTech) or in application stacks that you use, such as PHP (like yours truly ?).

Just note that these directories have a lot of entries and generally favor larger partners, which might not always be a great fit for smaller businesses. Because there are so many, it can also be tough to distinguish between partners, which is why getting real-world referrals from companies like your own is still one of the best ways to find partners.

When might it make sense to choose a cloud service provider besides AWS?

Clearly, we prefer AWS (which is why we’re an AWS MSP), but we’re not completely evangelical. We can think of a few reasons that it might make sense to go with a CSP besides AWS: existing commercial relationships, data gravity, and comfort with existing tools.

An example of an existing commercial relationship is if you have a pre-existing long-term enterprise agreement with Microsoft for other products and it offers you a good deal to credit some of your spend toward Azure (and you’re happy with Azure’s functionality, security, reliability, etc.). In this case, it might make sense to go with Azure. Another example would be if Oracle offered you credit toward Oracle Cloud instead of you having to pay for your Oracle database licenses.

Another consideration is data gravity. This refers to the idea that when you have a lot of data in a particular location, it is more likely to attract surrounding applications to interact with the data, which in turn attracts more data, and so on. A good example of this is if you generate a lot of data from Google Analytics that is natively exported to BigQuery on Google Cloud Platform. Data egress fees can be high, so it would make sense to work on this data from within Google Cloud Platform rather than moving it to another cloud provider in this case.

I briefly mentioned this earlier, but it is also often preferable to stick with tools that your team is already familiar with. If your team is full of .NET developers, that could be a strong argument to choose Azure, even if AWS might have been better for starting from scratch.

So what’s next?

Aside from the reasons we gave to go with an AWS competitor for your cloud service, we think that it’s almost always better to stick with AWS because it has a long history of promoting our values. Based on this track record, we believe in this CSP going forward, which is why we built our business around it. We think you should bet on AWS for the same reasons we did.

Whatever you decide, hopefully, you now have a good idea of how to choose a cloud service provider. If not, feel free to contact us to talk about the right CSP for you.