AWS, Azure or Google Cloud? The Differences That Actually Bite

Most cloud comparisons are a table of three columns and two hundred rows, and they are close to useless. Every row says "yes". All three providers run virtual machines, object storage, managed Postgres and Kubernetes, and all three do it competently. If your workload is a web application with a database behind it, you can build it on any of them and the result will be indistinguishable.

So the feature grid tells you nothing. The decisions that hurt three years later are elsewhere: in identity, in what your data costs to move, and in whether the service you built on will still exist.

Where they genuinely differ

AWS wins on breadth and maturity. It has the most services, the most regions, the deepest documentation, and — the part people underrate when hiring — the largest pool of engineers who have already made your mistakes. If you need something unusual, it probably exists, and someone has already blogged about the sharp edge you are about to hit.

The cost is sprawl. The console is inconsistent because it accreted over two decades, and IAM is genuinely hard. Not "needs a tutorial" hard: policy evaluation across identity policies, resource policies, permission boundaries, service control policies and session policies is a system that engineers get wrong in production, repeatedly. Budget for that.

Azure wins on identity, and this is the single most underweighted factor in the whole decision. If your organisation runs Microsoft 365, you already have Entra ID, and your users, groups and conditional access policies already exist. Choosing Azure means one identity plane instead of two. Choosing anything else means federating, and federation is a permanent, low-grade tax on every access decision you make afterwards.

Azure also has the strongest hybrid story through Arc, and licensing benefits that are real money if you run Windows Server or SQL Server. Against that: service quality is less even than AWS. Some Azure services are excellent, and some feel like they shipped a version early.

Google Cloud wins on data and containers. BigQuery is the one service across all three providers that is genuinely differentiated rather than merely competent — serverless analytics where you do not size, patch or think about a cluster, and the separation of storage from compute is architectural rather than marketing. If your problem is "we have a very large amount of data and questions about it", GCP has the best answer.

GKE is also the best-run managed Kubernetes of the three, which should surprise nobody given where Kubernetes came from.

The thing nobody puts in the comparison table

Google has a record of discontinuing services, and it is not an abstract concern.

Google Cloud IoT Core was shut down on 16 August 2023. It launched in 2017, competed directly with AWS IoT Core and Azure IoT Hub, and was retired with roughly a year's notice. Customers were pointed at third-party partners. Anyone who had built device connectivity on it had to migrate their entire fleet — and fleets in the field are the hardest thing in computing to change, because the devices are on a roof, in a substation, or inside a machine that cannot be taken offline.

The lesson is not "never use Google Cloud". It is that service selection has a vendor-commitment dimension that feature comparisons ignore entirely. Before you build on a managed service, ask how central it is to the provider's business. BigQuery is not going anywhere; it is a pillar. A niche managed service in a market where the provider ranks third is a different risk, and you should price that risk into the decision.

It cuts both ways, though, and this is worth saying because the internet gets it wrong. In February 2024 a system message announced that Azure IoT Central would retire on 31 March 2027. Microsoft retracted it within days, stating the message was sent in error and that Azure product retirements follow a standard notification process with three years' notice. IoT Central is not scheduled for retirement, and its documentation carries no retirement notice — yet you can still find articles confidently describing its 2027 demise.

Check primary sources. Vendor documentation and official retirement notices, not the secondary coverage that outlives its own correction.

Pricing: the model matters more than the rate

Comparing headline compute prices is close to meaningless. The rates are within a few percent, they change, and nobody pays list.

What differs structurally is how each provider discounts and where the surprise costs live.

AWS is the most granular and the most pay-per-use, which is a genuine advantage for spiky workloads and a genuine trap for idle ones. Azure's commercial story runs through enterprise agreements and licence portability — if you hold Windows Server or SQL Server licences, Hybrid Benefit is a real and often large discount that has no equivalent elsewhere. Google applies sustained-use discounts automatically, which is the friendliest default of the three for steady workloads, since you get the discount without negotiating or committing.

The surprise, on all three, is egress. Data in is free. Data out is charged, and it is charged again between regions, and sometimes between availability zones. Architectures that look cheap on a diagram become expensive because someone put the database in one region and the compute in another, or because a chatty service crosses a zone boundary a million times an hour.

One change worth knowing about if you operate in the EU. Under the Data Act — Regulation (EU) 2023/2854 — switching charges are being withdrawn, and from 12 January 2027 providers may not charge for switching, including the data egress associated with it. Until then they may charge, but only the actual direct costs of assisting the switch.

Read that precisely, because it is widely misreported: this abolishes charges for leaving, not your day-to-day egress bill. Serving data to your own users is unaffected. What it changes is the economics of migration — the exit cost that has kept a great many workloads where they are will, for EU customers, drop to zero. If you are weighing a move, the calculation looks materially different after that date than before it.

Lock-in is real, but not where people look

The usual advice is to stay portable by using Kubernetes and avoiding proprietary services. It is half right.

Compute and storage are genuinely portable. A container runs anywhere; object storage APIs are close enough that a rewrite is days, not months. If that were the whole picture, switching would be easy and nobody would feel trapped.

The two things that actually hold you are data gravity and identity.

Data gravity is physics and money. Moving fifty terabytes is not a technical problem, it is a bandwidth and egress-cost problem, and the larger your dataset the more every other decision bends around where it already sits. Identity is worse, because it is invisible. Once your access control, service accounts, secrets and audit trail are expressed in one provider's IAM, that model is embedded in every application, every pipeline and every runbook you own. Translating it is not a migration task; it is a redesign.

So if you want to stay portable, spend the effort there. Keep your identity model expressible in more than one system, know where your data physically is, and be deliberate about which managed services you allow to become load-bearing.

For connected products specifically

This is our own field, so the summary is short and opinionated.

If you are connecting physical devices, you have two viable managed options, not three. AWS IoT Core and Azure IoT Hub both give you device identity with X.509 mutual TLS, MQTT, provisioning at fleet scale, a device state abstraction, and a supported edge runtime — Greengrass and IoT Edge respectively. Both are mature and both are safe choices.

Google Cloud has no equivalent managed service since IoT Core closed. You can absolutely build device connectivity on GCP — Pub/Sub is excellent and there are capable third-party device-management platforms that run on it — but you are assembling it rather than adopting it, and you should go in knowing that.

The choice between AWS and Azure here usually comes down to the same identity question as everything else, plus where the data is going afterwards. If the telemetry ends up in BigQuery, note that you can run devices into AWS or Azure and still land the analytics in Google. Multi-cloud is a legitimate answer for exactly this shape of problem, provided you accept the egress bill and the second identity plane.

How to actually choose

Feature grids will not decide this. A short, honest set of questions will.

1. Where does your identity already live? If the answer is Microsoft 365, the burden of proof is on anything other than Azure.
2. What is the centre of gravity of your workload? Analytics at scale points to Google. Breadth, unusual requirements and hiring depth point to AWS. Windows and enterprise licensing point to Azure.
3. Which managed services will become load-bearing, and how committed is the vendor to each? Ask this specifically about anything niche.
4. Where will your data physically sit, and what does it cost to move? Then check that against your obligations — residency, sector rules, and what your customers' contracts require.
5. Can you hire for it? The best platform your team cannot operate at 3am is the wrong platform.

Then build a real spike. One meaningful workload, deployed properly, with authentication and monitoring wired in, on the two you are seriously considering. Two weeks of that will tell you more than any comparison article, including this one.

Where DevSpark fits

We are an engineering consultancy, not a cloud reseller, and we have no incentive to steer you toward a particular badge. Where we help is the part that is genuinely hard: connecting real hardware to a cloud reliably, at scale, and keeping it connected — device identity and provisioning, protocol and edge design, and getting telemetry into a form your analytics can actually use.

If you are choosing a platform for a connected product, or you inherited one and it is not behaving, that is the conversation we are useful in.

---

This article is general technical information, not procurement or legal advice. Verify service availability, pricing and regulatory obligations against provider documentation and qualified counsel for your own circumstances.