Choosing Between AWS and Azure Without the Marketing

Both platforms will run virtual machines, containers, managed databases, object storage, private networks and identity. Both have regions in India. Both have a mature security model, a serious support offering and enough documentation to drown in. For the workloads a normal business runs, neither is missing anything that would stop you.

So a comparison built on features will not settle it. You will find a spreadsheet with hundreds of rows, discover that the two columns are nearly identical, and end up choosing on whichever obscure service happened to be in the list. That is a bad way to make a decision you will live with for ten years.

The decision is settled by three things outside the feature list: what you already run, what your team already knows, and what your software suppliers actually support. Get those three answers and the choice usually makes itself, sometimes in the first meeting.

We work with both. We have no interest in you picking one over the other, and the paragraphs below are written from having had to operate what other people chose.

If your business runs on Windows Server, SQL Server, Active Directory and Microsoft 365, there is real gravity towards Azure. The pull is practical. Your identity already lives in the Microsoft directory, and the platform that plugs straight into it removes an entire category of work: no second directory to synchronise, no separate sign in for staff, no arguing about which system is the source of truth for who works here.

If you already run Linux, containers and open source databases, or you have an existing account with production workloads in it, the same logic points the other way. The cost of moving a working estate for architectural tidiness is nearly always higher than the benefit, and the benefit is usually described rather than measured.

Licence terms matter here too, and they change. Some software you already own can be brought to a cloud platform under existing agreements, and the conditions differ by platform and by contract. Get your reseller to put that in writing for your specific agreement, because a generic answer from a website will not survive an audit.

The businesses with a genuinely free choice are the ones starting something new with no existing estate. That is rarer than the number of platform comparison meetings would suggest.

Whoever is on call at three in the morning has to navigate the console, read the logs, and know where the switch is. That familiarity is worth more than any feature difference, and it is the factor most often ignored because it feels unserious to write on a slide.

Be honest about the size of the gap. Somebody who has run one platform for years can learn the other, and the core concepts carry across. What does not carry across is the accumulated knowledge of where the sharp edges are: which default is dangerous, which limit you will hit, what a particular error message really means. That takes a year of operating, not a course.

Think about hiring as well. In your city, in your salary band, who can you actually recruit and how quickly. If every engineer you have interviewed in the last year has run one of the two, that is a real constraint even if it feels like an accident.

And think about whoever supports you now. If a company already manages your infrastructure, their strength on each platform is a legitimate input. Ask them plainly which one they run more of, and treat a vague answer as an answer.

This is the question that quietly decides more of these projects than architecture ever does. Your accounting system, your production planning software, your payroll platform: each of them has a supported deployment model, and some vendors certify one cloud platform and not the other.

Ask each significant vendor two questions in writing. Which platforms do you support for this product and version. What happens to my support entitlement if I run it somewhere else. The second question is the important one. Plenty of software runs perfectly well in an unsupported configuration right up until the day you need help with a serious fault and the answer is that they cannot assist.

Check the surrounding tools too, not just the big systems. Your backup product, your monitoring, your security tooling, the connector that moves data between two applications. A gap in any of those turns into a small integration project nobody costed.

Where a vendor supports only one platform and that system is central to your business, the decision is effectively made. Save yourself the workshop.

The account and permission models are the real difference, and they shape how you organise everything. One platform separates workloads primarily into accounts grouped under an organisation. The other uses subscriptions arranged under management groups, tied to a directory that most Microsoft customers already have. Both work. They lead to different structures, different naming, and different habits about where a boundary goes.

Networking defaults differ in ways that matter on day one. What exists when you create an empty environment, how routing is set up by default, what is open and what is closed, and how private connections between environments are built. None of these are better or worse in the abstract. They are different enough that an engineer moving across will be wrong about something in the first week.

Support plans are structured differently, and this is worth comparing properly because it is a real recurring cost. Look at what is included at each level, what response commitment you actually get, and whether it is charged as a share of your spend or a fixed fee.

Region choice is worth checking against your own requirements rather than against a global map. What matters is which regions are near your users, which services you need are available in those specific regions, and where your data would sit for backups and for disaster recovery. Service availability by region is not uniform on either platform.

List prices for equivalent machines land close enough that a comparison built on them tells you almost nothing. What actually determines your bill is the shape of your usage, the discounts you can commit to, how your existing licences travel, and how much of the estate ends up on managed services rather than plain machines.

So price your real workload, not a representative one. Take two or three systems you actually run, with their real sizes, their real storage, their real data transfer, and price those on both. Include the support plan. Include the licences. Include a year of growth at the rate you are actually growing.

Then ask your reseller or account team what commitment terms are available for that specific usage. This is where the numbers move, and it is also where they stop being comparable to any published figure.

Do not let a small difference decide it. If the two come out close, which they usually do, the platform your team can operate well is cheaper in every way that matters, because the running cost of a platform includes the time people spend fighting it.

Running on both platforms sounds like sensible insurance and is usually the most expensive decision available to a mid sized business. Every tool has to work in two places. Every network design exists twice. Every engineer has to be competent in two consoles, and every security review covers two sets of defaults.

There are good reasons to end up with both. An acquisition brings one with it. A vendor's software only runs on the other. A specific service is genuinely better for one workload. Those are all fine, and they share a shape: a named workload with a named reason, rather than a policy.

Using both as a bargaining position rarely works out either, because the discounts that matter come from commitment, and commitment is exactly what a split estate cannot offer.

If you do end up with both, pick a primary. Identity, logging, the network design and the security baseline should all be led from one side, with the other treated as an outpost. Two equal platforms means two of everything, permanently.

Write down the three inputs first: your existing estate, your team's real experience, and the written answers from your important vendors. That takes a few days of asking, and it frequently ends the discussion on its own.

If it does not, build the same two workloads on both platforms. Pick one ordinary machine based system and one thing that would use a managed service, give a pair of engineers a week on each, and have them write down what was awkward. Real friction on a real workload beats any evaluation matrix.

Then get the pricing for those exact workloads from both, including support and licensing, and put the two figures side by side with the assumptions listed underneath.

Record the decision and the reasons in one page, and give it a review date a couple of years out. New people will ask why, an account manager will eventually offer you something to move, and a written reason turns those conversations into short ones.