AWS vs Azure vs Google Cloud Platform: Comprehensive Comparison

Every year around 10 a.m., the IRCTC ticketing website faces the "Tatkal rush" — thousands of passengers all hitting "Book Now" for the same handful of premium-quota seats within the same few seconds. A server room with, say, 50 physical machines is either wildly over-built for the other 23 hours and 59 minutes of the day, or hopelessly under-built for those first ninety seconds. Buying enough physical hardware to survive the spike means paying for idle machines every single day of the year. This is the exact problem that gave rise to cloud computing, and it is why three companies — Amazon, Microsoft, and Google — now rent out computers, storage, and databases to the rest of the world by the second. This chapter compares their three platforms — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) — not as a marketing exercise, but as an engineering decision with real, calculable trade-offs.

From "owning a car" to "calling a cab": the first-principles idea

Think about how you get around the city. If you own a car, you pay a large fixed cost upfront (buying it) plus fixed running costs (insurance, parking) whether you drive it or not. If instead you call a cab only when you need one, you pay per kilometre, scale up instantly when you need three cabs for a family trip, and pay nothing when you don't need one at all. Owning a data centre is like owning the car. Cloud computing is the cab: you rent exactly the computing capacity you need, for exactly as long as you need it, and the provider absorbs the cost of keeping the underlying hardware fleet ready.

Formally, cloud providers sell three layers of "how much you manage yourself," commonly drawn as a stack:

• IaaS (Infrastructure as a Service) — you rent raw virtual machines, storage disks, and networks. You install and patch the operating system yourself. Example: AWS EC2, Azure Virtual Machines, GCP Compute Engine.
• PaaS (Platform as a Service) — the provider manages the operating system and runtime; you just deploy your code. Example: AWS Elastic Beanstalk, Azure App Service, Google App Engine.
• SaaS (Software as a Service) — you use a finished application over the internet and manage nothing. Example: Gmail, Microsoft 365, Google Docs.

This chapter focuses mainly on IaaS and the managed platform services built on top of it, because that is where AWS, Azure, and GCP genuinely compete and where the engineering differences are sharpest.

Three companies, three different starting points

The order in which these platforms were born still shapes how they are built today. Amazon launched S3 (its object storage service) in March 2006 and EC2 (its virtual machine service) in beta that August — Amazon built AWS to rent out the spare capacity of the infrastructure it had already built for its own retail business, and being first gave it roughly a two-year head start over any competitor. Microsoft announced "Windows Azure" in October 2008 and made it commercially available in February 2010, later renaming it "Microsoft Azure" in 2014; Azure's biggest structural advantage is that it was built by the same company that makes Windows Server, Active Directory, and Office, so it integrates tightly with software that most large Indian and global enterprises already run. Google's cloud story starts differently again: Google App Engine (a PaaS product) launched in 2008, but Google's IaaS competitor to EC2 — Compute Engine — didn't reach general availability until December 2013, and the unified "Google Cloud Platform" brand was assembled around that time. Google's advantage is that its cloud runs on the exact same global network and data-handling technology (originally built for Search and YouTube) that gave the world Kubernetes, BigQuery, and TensorFlow.

These historical starting points explain the market today. Independent trackers such as Synergy Research and Canalys have, through the mid-2020s, consistently ranked the three in the same order: AWS first (commonly cited around 30% of worldwide cloud infrastructure spending), Azure second (roughly in the low-to-mid 20s), and Google Cloud third (roughly 10-12%) — with the three together accounting for close to two-thirds of the global market. Treat any single percentage as a snapshot, not a law of physics — market share shifts every quarter — but the relative ordering has held for years because it is anchored in these historical head starts, not in short-term marketing.

Comparing compute: renting the actual "computer"

All three providers sell virtual machines — software-simulated computers carved out of a real physical server — but organise them differently:

• AWS EC2: instance "families" named by letter — T (burstable, cheap, for light/spiky workloads), M (balanced general purpose), C (compute-optimised, more CPU per rupee), R (memory-optimised, for databases and caches).
• Azure Virtual Machines: a near-parallel naming scheme — B-series (burstable), D-series (general purpose), F-series (compute-optimised), E-series (memory-optimised).
• GCP Compute Engine: E2 (cost-optimised, shared-core friendly), N2 (general purpose), C2 (compute-optimised), M-series (memory-optimised) — plus a genuinely unusual option none of the others offer: "custom machine types," where you pick an arbitrary vCPU-and-RAM combination instead of choosing from a fixed catalogue.

The engineering lesson here is not "which name is better" — it's that all three converged on nearly identical categories (burstable / general / compute-heavy / memory-heavy) because those four shapes cover almost every real workload: a college's login portal is bursty, a web server is general purpose, a video-encoding job is compute-heavy, and a database cache is memory-heavy. When three independent companies converge on the same taxonomy, that is strong evidence the taxonomy reflects something true about computing workloads, not just marketing.

Comparing storage: object storage tiers

For storing files (images, videos, backups, logs) rather than running programs, each provider offers an "object storage" service with tiers priced by how quickly you might need the data back:

• AWS S3: Standard (frequent access) → Standard-IA / One Zone-IA (infrequent access, cheaper) → Glacier Instant Retrieval → Glacier Flexible Retrieval → Glacier Deep Archive (cheapest, but retrieval can take hours).
• Azure Blob Storage: Hot → Cool → Cold → Archive.
• Google Cloud Storage: Standard → Nearline → Coldline → Archive.

Notice the pattern: every provider charges less per gigabyte stored as you accept slower or costlier retrieval. This is a genuine trade-off, not an arbitrary pricing trick — keeping data "hot" (instantly available) requires it to sit on fast, expensive drives with spare read capacity standing by; archival data can be compressed onto the cheapest possible media because the provider doesn't need to serve it in milliseconds. A school photo archive you might need once a year belongs in the coldest tier; the textbook PDFs your app serves every second belong in the hottest.

The mathematics of availability: what "99.99% uptime" really costs you

Cloud providers advertise uptime as a Service Level Agreement (SLA) percentage, and it is tempting to glance at "99.9%" versus "99.99%" and assume the difference is trivial — after all, it's just one more 9. It is not trivial, and you can prove this with simple arithmetic. There are 365 × 24 × 60 = 525,600 minutes in a year. Allowed downtime is just (1 − uptime fraction) × 525,600:

def downtime_per_year_minutes(uptime_percent):
    total_minutes = 365 * 24 * 60      # 525600 minutes in a year
    fraction_down = 1 - uptime_percent / 100
    return total_minutes * fraction_down

for u in [99, 99.9, 99.95, 99.99, 99.999]:
    print(u, "percent uptime allows", round(downtime_per_year_minutes(u), 2), "minutes down/year")

Running this by hand for each value gives the table below — one consistent unit per row, converted to whatever unit makes the number easy to picture:

Uptime SLA   Allowed downtime per year
99%          3.65 days
99.9%        8.76 hours
99.95%       4.38 hours
99.99%       52.6 minutes
99.999%      5.26 minutes

So going from 99.9% to 99.99% is a full 10x reduction in allowed downtime — from nearly nine hours a year down to under an hour (52.6 minutes). That single extra "9" is the difference between "the system can be down for most of a working day and still meet its contract" and "the system basically has to work on the first retry, every time." This is precisely why providers charge more for higher-tier SLAs, and why banks, exchanges, and UPI-adjacent payment infrastructure specifically pay for the highest availability tiers rather than the default.

Why regions and Availability Zones exist — and the probability behind them

No single data centre can promise 99.99% uptime on its own — power grids fail, fibre gets cut, cooling systems break. So all three providers physically separate their infrastructure into independent failure domains and let you spread your application across them:

• A Region is a geographic area — for example AWS's ap-south-1 and GCP's asia-south1 both sit in Mumbai; Azure has three Indian regions: Central India (Pune), South India (Chennai), and West India (Mumbai).
• Each Region contains multiple Availability Zones (AZs) — physically separate clusters of data centres within that region, each with its own power supply, cooling, and network connection, but linked by low-latency fibre so your application can treat them as one system.

The probability math behind this design is a direct application of independent events multiplying, the same rule you use for two dice: if a single Availability Zone has a 0.1% (p = 0.001) chance of being unreachable at any given moment, and the three zones fail for genuinely independent reasons, the chance that all three are down simultaneously is p³ = 0.001³ = 10⁻⁹ — about one in a billion. That is how a provider advertising 99.9% uptime per zone can offer a much higher combined SLA (sometimes 99.99% or better) to an application deployed redundantly across three zones: 1 − (1 − 0.999)³ = 1 − 10⁻⁹ = 0.999999999.

Common misconception: "more zones always means near-perfect uptime"

A student who has just learned the p³ calculation above often jumps to "so if I use enough zones or regions, my downtime becomes essentially zero." This is false in practice, and the reason exposes something important about how real systems fail. The p³ calculation assumes the three zones fail for independent reasons — one zone's power transformer blowing has nothing to do with another zone's transformer. But a large share of real outages are correlated, not independent: a buggy software update pushed to every zone at once, a shared DNS or authentication service that all zones depend on, or a networking configuration change that a human engineer applies globally. AWS's us-east-1 region — despite having multiple Availability Zones — has suffered several well-documented multi-hour outages (notably in 2020 and 2021) precisely because the failure was in a shared control-plane component that every zone in the region relied on, not in the physical power or cooling that the AZ design protects against. The lesson: AZs protect you against physical/hardware failure with genuinely strong multiplicative math; they do not protect you against a shared software bug, which is why serious systems also test for "what if my whole cloud provider account has a bad day" by spreading critical workloads across separate regions, or even separate providers.

Managed Kubernetes: EKS vs AKS vs GKE

Kubernetes is an open-source system (originally built at Google, released in 2014) for automatically running, restarting, and scaling containerised applications across many machines. Rather than making customers install and maintain Kubernetes themselves, all three clouds sell a managed version:

• Google Kubernetes Engine (GKE) reached general availability in August 2015 — Google had the natural first-mover advantage here since Google's own engineers built Kubernetes.
• Azure Kubernetes Service (AKS) entered public preview in October 2017 and reached general availability in June 2018.
• Amazon Elastic Kubernetes Service (EKS) was announced in November 2017 and also reached general availability in June 2018 — the same month as AKS.

So while AKS is sometimes casually described as "launched in 2017," that only refers to its preview stage; both AKS and EKS became fully supported, production-ready services in the same month, roughly three years after GKE. That three-year gap is one reason Kubernetes tooling and documentation historically felt most mature on Google Cloud, even though today all three are considered production-grade.

Databases: same job, different philosophies

Each provider offers a managed relational database (so you never have to run apt install postgresql yourself) and at least one NoSQL option for data that doesn't fit neat rows and columns:

• AWS: RDS (managed MySQL/PostgreSQL/etc.) for relational data, DynamoDB for key-value/NoSQL at massive scale, Redshift for data-warehouse analytics.
• Azure: Azure SQL Database (deeply integrated with SQL Server tooling many Indian enterprises already use), Cosmos DB (a multi-model NoSQL database that can speak several different query APIs), Synapse Analytics for data warehousing.
• GCP: Cloud SQL for standard relational needs, Firestore/Bigtable for NoSQL, BigQuery for analytics — and Spanner, a genuinely distinctive product that offers strong global consistency (every reader everywhere sees the same, most up-to-date data) at planet-scale, a combination most distributed databases can't achieve without sacrificing speed.

Spanner is worth pausing on because it directly connects to a concept you'll meet formally later in distributed-systems theory (relevant for GATE-level Computer Science): the CAP theorem, which says a distributed database can't simultaneously guarantee perfect Consistency, Availability, and Partition-tolerance — you must sacrifice one. Spanner's engineering trick is to use extremely precise, GPS- and atomic-clock-synchronised time across Google's data centres to get consistency guarantees that are practically indistinguishable from a single-machine database, even though the data lives on machines spread across continents. That is a genuine, non-trivial piece of distributed-systems engineering, not a marketing claim.

Pricing models: on-demand, reserved, and spot

All three providers offer the same three purchasing strategies, just under different names, and the underlying economics are identical everywhere:

• On-demand / pay-as-you-go: pay per second or per hour with zero commitment. Most flexible, most expensive per hour.
• Reserved / committed-use (AWS: Reserved Instances; Azure: Reserved VM Instances; GCP: Committed Use Discounts): commit to using a certain amount of compute for 1 or 3 years in exchange for a substantial discount, typically in the range of 30-60% depending on the term and payment structure.
• Spot / preemptible pricing (AWS: Spot Instances; Azure: Spot Virtual Machines; GCP: Spot VMs): bid for the provider's genuinely spare, otherwise-idle capacity at steep discounts — often 70-90% off on-demand — with the catch that the provider can reclaim the machine with only a short warning (commonly around two minutes) whenever it needs that capacity back for a paying on-demand customer.

The following numbers are deliberately round and illustrative — real hourly prices change often and vary by region and instance type — but the proportions mirror how all three providers actually structure these three tiers. Suppose a general-purpose virtual machine costs ₹8 per hour on-demand. Running it continuously for a 730-hour month costs ₹5,840. A one-year reserved commitment at a representative 40% discount brings the effective rate to about ₹4.80/hour, or ₹3,504/month — but you are contractually paying for that capacity whether you use it or not. A spot instance at a representative 80% discount costs about ₹1.60/hour, or ₹1,168/month — dramatically cheaper, but the machine can vanish with a couple of minutes' notice. This is why spot/preemptible pricing is used for batch jobs that can checkpoint and resume (rendering video, training a machine-learning model, processing a backlog of exam results) and never for something like a live payment gateway that must never be interrupted mid-transaction.

Choosing between them in practice

There is no universally "best" provider — the right choice depends on constraints outside pure technology. A company already running on Windows Server and Active Directory typically finds Azure cheaper to adopt because of that existing integration. A team that needs the widest catalogue of mature services and the largest hiring pool of experienced engineers usually defaults to AWS, simply because it has the largest install base and the longest history. A team doing heavy data analytics or machine learning, or one that wants Spanner-grade global consistency or Kubernetes support with the deepest institutional experience, often leans toward GCP. In India specifically, all three now operate in-country regions — AWS in Mumbai and Hyderabad, Azure in Mumbai/Pune/Chennai, and GCP in Mumbai and Delhi — largely because Indian data-protection expectations and network latency both favour keeping user data physically close to Indian users rather than routing every request to Singapore or the US.

Where this fits your syllabus

CBSE's Information Technology (Code 402) and Artificial Intelligence (Code 417) curricula both introduce cloud service models (IaaS/PaaS/SaaS) and deployment models (public/private/hybrid) — this chapter's vocabulary maps directly onto that syllabus and onto board-exam short-answer questions asking you to distinguish the three service layers. Beyond boards, the distributed-systems ideas underneath this chapter — independent-failure probability, consistency trade-offs, the CAP theorem — are exactly the foundations that GATE's Computer Science paper and serious Olympiad-level systems questions build on in later years. You don't need to memorise AWS's product catalogue for any of these exams; you need to understand why elastic compute, tiered storage, and multi-zone redundancy exist at all, because that reasoning transfers to any distributed system you'll ever be asked to analyse.

Active recall

1. A system currently guarantees 99.9% uptime. Using the 525,600-minutes-per-year figure, calculate its allowed downtime in hours, then calculate the allowed downtime in minutes if the guarantee is upgraded to 99.99%. By what factor did the allowed downtime shrink?
2. A single Availability Zone has a 99.5% chance of being available at any given moment (p = 0.005 chance of failure). If an application is deployed redundantly across two independent AZs, what is the probability that both are down simultaneously? What is the resulting combined availability percentage?
3. Explain, in your own words, why the p³ calculation for combined AZ availability breaks down during a shared control-plane outage like the ones AWS's us-east-1 region has experienced. What assumption does the calculation rely on that a shared-software-bug failure violates?
4. A batch job that renders 3D animation frames for a student film project can be paused and resumed at any checkpoint without losing work. Which pricing model — on-demand, reserved, or spot/preemptible — is the economically correct choice, and why would that same choice be wrong for a live UPI payment-processing service?
5. Name one managed Kubernetes service from each of the three providers, and state which one reached general availability first, with its year.

Summary

AWS, Azure, and Google Cloud Platform sell the same underlying idea — rented, elastic computing capacity instead of owned hardware — but arrived at it from different starting points (retail infrastructure, enterprise software, and search infrastructure respectively), and that history still shows up in each platform's strengths today. All three organise compute into similar instance-family taxonomies, tier their object storage by access frequency, and physically isolate infrastructure into regions and Availability Zones whose independent-failure math you can calculate directly with basic probability. Uptime SLAs are not marketing fluff — each additional "9" is a precise, computable order-of-magnitude reduction in allowed annual downtime, and the multiplicative math behind multi-zone redundancy is real, provided you remember its independence assumption breaks down for shared software failures. Choosing between the three in practice is a genuine engineering and business decision — existing tooling, team expertise, specific product strengths like Spanner's global consistency, and in India specifically, the physical location of in-country regions — not a question with one universally correct answer.