AWS vs Azure – what's the difference?

Cloud services have something to offer almost every kind of business. In fact, if you believe Amazon's hype, we're heading for a world where companies of all sizes run entirely on remote servers. Microsoft – perhaps understandably, given its roots – treads a little more cautiously, focusing on hybrid architectures, but either way, it seems certain that the cloud is integral to the future of business.

The challenge is, it's not always easy to tell which company's cloud platform will be the best fit for a particular role in a particular organisation. That's partly because the different providers make broadly the same promises, enabling you to deploy computing services almost on a whim, and scale them up and down as needed with minimal management. 

But while the fundamentals might seem identical, as soon as you start to look in depth at the two biggest platforms – those being, without question, Amazon and Microsoft – you run into nuances and differences of philosophy that can have an enormous impact on either the service or the customer. 

How did we get here?

Only around 15 years ago most corporations were built largely on in-house hardware. This was a big expense: the entire capital footprint of a standard server, including all the lifetime costs right down to the ground rent for the rack in which the server would hide, could easily come to something like £250,000. And after all that investment, most server CPUs spent the vast majority of their time sitting idle.

Then came the virtualization revolution, which allowed businesses to work their IT investments harder by running a dozen virtual servers on the same piece of iron. The response was undeniable: I don't think it's an exaggeration to say that virtualization was adopted more quickly than any other new technology in the history of computing. And it didn't just work for on-premises hardware; it was the perfect fit for cloud services, supporting the growing web and mobile app marketplaces. 

Amazon was quick to seize the opportunity, launching its Elastic Compute Cloud (EC2) service in March 2006. Microsoft followed up with Azure in February 2010. You might think that a four-year delay would put Microsoft at a huge competitive disadvantage, but at the outset, there wasn't much of a sense of competition – or if there was, then it was more between Amazon and traditional virtualization solutions. In the end, VMWare put together its own cloud product, but it's still not what the company is best known for. 

In fact, the timing of Microsoft's entry into the market was perfect. Following the credit crunch, businesses that had previously been cautious about migrating into the cloud became a lot more receptive to the sales pitch of "elastic computing", and paying only a modest monthly fee for the resources they actually used. There were few other challengers: Google didn't get into general-purpose cloud computing until quite a few years later, while Akamai took little interest in small, commercial operations – as it continues to do. 

That's not to say that Azure was an instant hit. While Amazon saw meteoric growth in the early 2010s, Microsoft was held back by technical limitations. Most notably, while Amazon had strong Linux support from day one, Azure launched as a Windows-only service, and took more than half a decade to mature into something more OS-agnostic. That eventually changed in around 2018 when it was announced that Azure was now running fully on Windows Server 2012, supplying the exact same services as your in-house servers – including full Linux environments.

AWS vs Azure: Does it really matter?

That historical recap may seem academic, but it very much shapes the different services you can buy today. Amazon's approach has always relied on a very neutral hypervisor and data center-scale network layer. If you want to run a Windows server on their platform, that's fine – although some of the more advanced configurations (like server-to-server VPN tunnels within a Windows domain) might take a few updates and a bit of head-scratching to get working. The overall philosophy is one of a clean virtual architecture, which to all intents and purposes replicates physical hardware.

The Azure model is more akin to deploying virtual Windows servers and standard services, rather than setting up a generic black box. If you're building a hybrid environment where virtual servers interoperate with real ones that may well be what you want. However, it muddies the water when it comes to management and orchestration, as the resources of the virtual machine won't square with those of the physical machine – and if you're interested in dynamic scalability you'll really want to keep an eye on both.

The best choice of cloud service can therefore depend on your own technical history and habits. To be clear, you'd be pushed to find a job you absolutely could only do on one platform or the other. But if you're accustomed to using remote Linux-based servers with lots of config files and obscure system security provisions then you'll feel right at home with Amazon -- whereas if you're a Windows shop, with wizards dominating your day-to-day activity and lots of scripting to join your various paid-for components into a coherent, singular service then you're likely to be more comfortable with Azure.

AWS vs Azure: Costs

The two big cloud services don't just embody different architectural philosophies – they have different approaches to pricing. Unfortunately, making sense of these isn't as easy as comparing two flat monthly fees, as it depends not only on the specific services you use, but how heavily you use them. What's more, pricing can vary, sometimes aggressively, in reaction to market conditions you can neither see nor negotiate with.

Still, for a rough and ready estimate, Amazon offers a pricing calculator at https://calculator.aws, while Microsoft's is at https://azure.microsoft.com/en-gb/pricing/calculator/. And you don't normally need to dig too deep to find out about pricing fluctuations, as both companies tend to keep the chatter in front of you all the time, along with all sorts of special bundles and deals. Amazon perhaps has a slight bias toward special deals on lumps of flat-rated hosting time and space, whereas Azure tends to talk up rapid-deployment solutions for specific jobs, such as AI-scanning your entire data lake for trends in your customer base. 

Overall, managing your budget can be a little more complicated with Azure, as it involves a wider menu of bolt-on components and capabilities. This isn't necessarily a bad thing: if you want to run a few Windows machines in a private role, linked back to your company office as a neat way of backing up your Active Directory config and data, and maybe a few important files too, Azure can help you every step of the way. It'll probably work out very cost-effective at first too, because Microsoft sugars the initial pill by giving away lots of free time and free services to new relationships. When the next contract renewal comes up, however, things may get interesting.

Amazon offers a simpler service and a simpler pricing model – and while it does offer modular components, these don't always require you to spin up a complete VM. This makes it good value if you just want something like a static website or a cheap and cheerful email configuration.

Do pause however to consider whether all your functions need to live in the cloud at all. Cloud repatriation has been a big topic in the past few years, with companies bringing services back in-house after realizing they were paying significant cloud fees for things they could happily have continued running themselves. This was particularly easy to fall for in the early days when Amazon still presented itself largely as an online bookshop: since a lot of company credit cards don't limit spending on books, a lot of services were quietly moved into the cloud without explicit discussion or authorization. 

That's been less the case with Azure, perhaps because it tends to deal with bigger corporate customers who negotiate a fixed-price contract right from the get-go. That of course follows on naturally from its long history of partner and reseller-oriented business, which Amazon never had. 

Containers, VMs and kubernetes

There's a lot of room in the cloud philosophy for different server usage patterns – and for different hosting models. The least virtual part of the cloud is concerned with serving up web pages and data, rather than doing lots of arcane computing. A lightweight web presence without too many customizations, shopping carts, blog engines and so forth is ideally suited to containerization, rather than full-on virtualization.

Container technologies have in general become a hot topic in the last few years, with the main platforms being Docker, Butler and Kubernetes – Greek for the guy who steers the boat. The big idea is, rather than spinning up a complete virtual computer for each service you want to run, containers package up only the components that are needed to do a specific task. For many scenarios – such as a web server farm – these containers can be largely clones of one another, and any number of isolated containers can be run within a single operating system instance. It's a huge increase in efficiency that could slash the running costs of your site, while retaining the possibility of scaling up if demand increases.

As well as saving resources, a container-based approach helps the orchestrator manage demand and system health. Even estimating load is complicated with a traditional hypervisor, since it requires you to peer inside the virtual machine and monitor each individual virtual CPU – whereas discrete containers are much easier to keep an eye on.

If you want to take a containerized approach to your own software stack, that can be another differentiator between Amazon and Azure. The former happily lets you implement your own containers within the black-box VM model, but Microsoft is well ahead here, with a wealth of services designed to help you integrate containerized apps into your workflow.

Don't jump too hastily, though. For a small business, switching from full VMs to containers probably won't yield much benefit, simply because your traffic is unlikely to experience huge spikes in demand that need an instant scale-up in response. If a regular VM approach works out cheaper for the average month, it's probably worth sticking with that: add-on services will increase your ongoing costs, while the benefit may materialize only occasionally, or never.

A word of warning

There's a final caveat that applies to both AWS and Azure: one of the big attractions of cloud hosting is that it generally provides a degree of resilience that you won't get from an old tower server in the corner of the office. However, there's no intelligent way for the host operator to back up your VMs – after all, your data and processes are normally kept private from the cloud operator, so it can't possibly tell when's a good (or bad) time to start a backup. For similar reasons, you can expect little help with general system health. It's down to you to work out whether your virtual machines are running stably, without configuration errors or infections – and to be prepared to take action as needed.

This means that any cloud migration budget needs to include the right mix of VM support features, storage (both local and remote), and any needed additions to regular system components. This is another area where Azure will particularly appeal to Windows specialists, as it carries across the DFS and FRS data-protection features from the regular Windows Server platform. However, Amazon has its own AWS Backup service too, which works across the company's whole range of cloud services and includes support for Windows and VMware VMs.