CloudCostCompare
ES

Esta página aún no está disponible en Español, así que el texto de abajo está en inglés. Abrir la página en inglés

Guías

AWS vs Azure vs Google Cloud pricing: how bills differ

Por Rohit Athaide · Publicado el 4 nov 2026

Short answer: AWS, Azure and Google Cloud publish list prices for almost the same services, and no one of them is cheaper for everything. The totals differ because each cloud counts different things, bundles different things and charges for different extras. A fair comparison matches the job, the region and the options first, and only then looks at the numbers.

Key points

  • Compare the same job in the same region, not services with similar names.
  • The unit of billing often differs, even when the service is the same.
  • Discounts for commitment follow different rules on each cloud.
  • Data leaving the cloud, logs and backups are separate lines on all three bills.
  • Treat a comparison as a way to find large differences, not as a final answer.

How do AWS, Azure and Google Cloud price the same service?

They use the same basic idea, which is a rate per unit of time, per gigabyte or per request. They differ in the unit and in what is included.

Area What to look for
Virtual machines Own size names, own CPU-to-memory ratios, own definition of a vCPU. See VM instance equivalents and what is a vCPU
Automatic discounts Google applies some usage-based discounts without a contract. AWS and Azure rely more on reservations and savings plans you buy in advance. See commitment discounts compared
Data leaving the cloud All three charge for egress, with different free allowances and tier breaks. See data transfer costs
Managed services The same job, such as a load balancer, is billed by different meters: hours, capacity units, rules, connections
Free offers Some are permanent monthly allowances, some last a year, some are credits. See free tiers explained

Vendor pages hold the exact meters: AWS, Azure and Google Cloud.

How should I compare them fairly?

  1. Pick the same job, not the same name. Compare a layer 7 load balancer with another layer 7 balancer, a managed PostgreSQL with another managed PostgreSQL.
  2. Use the same region group. Prices move with location. Compare Mumbai-area regions with Mumbai-area regions.
  3. Match the options. Same CPU architecture, same memory, same disk type, same availability design.
  4. Include the extras. Data out, backups, monitoring, public IP addresses and support are lines of their own.
  5. Start from list prices. Then think about discounts as a separate step, since they depend on what you commit to.
  6. Say what is missing. If one cloud has no equivalent service, that is a gap, not a zero.

What does a worked example look like?

This example uses made-up round numbers to show the method, not real vendor prices. Suppose a small app needs one server, 100 GB of storage and 500 GB of data out per month.

Line How it is calculated Cloud X (made up) Cloud Y (made up)
Server hours (730) x rate per hour 730 x 0.05 = 36.50 730 x 0.06 = 43.80
Storage GB x rate per GB-month 100 x 0.02 = 2.00 100 x 0.03 = 3.00
Data out (GB - free GB) x rate per GB (500 - 100) x 0.09 = 36.00 (500 - 200) x 0.08 = 24.00
Total 74.50 70.80

Cloud Y has the higher server rate and still comes out lower, because its data out allowance is larger and its rate is lower. The lesson is that one line decides the result, and it is not always the line you looked at first. Replace the made-up rates with the vendors’ list prices from the compare pages, which show every price line with its unit and a link to the vendor’s page.

Which mistakes make comparisons wrong?

  • Matching by service name. A name that sounds alike can be a different product.
  • Comparing a burstable VM with a fixed-performance one. See burstable vs fixed-performance.
  • Leaving out data transfer, which can be the largest line for a web app.
  • Comparing different regions, then blaming the cloud.
  • Comparing list prices on one side with discounted prices on the other.

What can no comparison settle?

List prices ignore your negotiated rates, your credits and your team’s skills. A cloud your team already knows can cost less in practice because mistakes cost less. Support, compliance needs and the services you will add later also count. Read list prices vs what you actually pay before you act on any figure.

Decision checklist

  • Is the job the same on every cloud I am comparing?
  • Are region, size, architecture and availability design matched?
  • Did I include data transfer, storage, logs and backups?
  • Did I compare list prices before discounts?
  • Did I note any service a cloud does not offer as a gap?

Next steps

See the pairings in detail: AWS vs Azure, AWS vs Google Cloud and Azure vs Google Cloud. For a whole workload, use the web app estimator. How we calculate monthly costs explains each step, and how to read a cloud bill helps once the invoices arrive.

Frequently asked questions

Which is cheaper, AWS, Azure or Google Cloud?

None is cheaper for every workload. The answer changes with the service, the region, the size, and the discounts you commit to. Compare the same job in the same region on list prices first, then add discounts as a second step.

Why do the same virtual machine sizes cost different amounts?

Each cloud sets its own hardware, CPU-to-memory ratios and rates, and a vCPU does not mean the same thing everywhere. A size on one cloud rarely matches a size on another exactly.

Do list prices match what I will actually pay?

Rarely. Credits, reservations, savings plans and negotiated enterprise discounts change the final bill, and taxes and currency conversion are added on top.

Is Google Cloud easier to estimate because of automatic discounts?

Some Google Cloud compute usage earns discounts automatically with no contract, which can narrow the gap with committed prices on other clouds. Check the vendor page for which machine families qualify, since the rules change.

How do I compare managed services like load balancers across clouds?

Match them by job and layer, for example a layer 7 HTTP load balancer against another layer 7 balancer. Then read each cloud's billing meters, which are hours, capacity units, rules or data processed, and size them for your traffic.