Cloud Cost Estimator: Compare the Real Monthly Bill on AWS, Azure, and Google Cloud

A startup compares three cloud pricing pages, picks the lowest hourly rate for a four-vCPU virtual machine, and budgets around it. The first invoice arrives at roughly double the estimate, and the virtual machine turns out to account for well under half of it. Nothing on the pricing page was wrong. The hourly rate is one line in a bill that also contains storage, outbound data transfer, load balancers, NAT gateways, a support plan, and whatever managed services sit next to the VM, and those other lines are where most of the real difference between providers lives.

This calculator is built around that fact. It starts with the VM rate, because that is the number everyone compares first, and then adds the lines that actually decide the total. Every rate on the page is editable, because cloud prices move often enough that a table of fixed numbers would be out of date within a few months. The VM defaults come from published 2026 list prices for a general-purpose 4 vCPU and 16 GB instance on each provider, taken from third-party comparison trackers. The storage, egress, and support defaults are deliberately plain placeholders, and you should replace all of them with the figures from each provider’s own pricing calculator for your region before you rely on the output.

If your real question is which cloud to learn rather than which one is cheapest to run, that is a different decision with different inputs, and it is covered in the cloud certifications comparison on this site.

Estimate Your Monthly Cloud Bill

How to Read the Output

Each card shows the monthly total for one provider and breaks it into compute, storage, egress, flat extras, and support. Two lines deserve a second look. The “vs lowest” line shows how far each provider sits above the cheapest total, which is a more useful number than the percentage difference in VM rate alone. The small note at the bottom of each card shows what share of the bill the VM itself represents, and that figure is the one that most often surprises people. When the VM is 80 percent of the bill, the hourly rate really is the thing to compare. When it drops toward 40 percent, a provider with a slightly cheaper VM and a more expensive network can easily end up costing more overall.

The preset buttons are shortcuts for the discount row, not predictions. The one-year commitment preset applies roughly 37 percent, which is what the one-year committed figures in published 2026 comparisons imply against on-demand pricing for this instance size on all three providers. The Google automatic discount preset applies 30 percent, which is the upper bound of Google’s sustained use discount, and whether you actually receive it depends on the machine family you choose. The spot preset applies 70 percent, a middle value inside the 60 to 90 percent range that all three providers advertise, with the important caveat that spot capacity can be taken back with little warning.

What This Calculator Includes and What It Leaves Out

The calculator covers five things: compute, block storage, internet egress, a flat monthly amount you can use for anything fixed, and a support plan expressed as a percentage of spend. That is enough to model a typical small application running on a handful of virtual machines, and it is deliberately narrow so that each input stays understandable.

It does not model managed databases, serverless functions, container orchestration fees, content delivery networks, monitoring and logging services, per-request charges, Windows or SQL Server licensing, or GPU instances. For most of these you can still get a reasonable estimate by taking the monthly figure from the provider’s own calculator and typing it into the flat extras field. A managed database that costs a known amount per month, for example, belongs in extras, and so does a NAT gateway or a load balancer once you have looked up its hourly and per-gigabyte charges. The goal is not to replace the official calculators, which are far more complete, but to make the comparison between providers honest by forcing the non-VM lines onto the page where they can be seen.

Why Cloud Price Comparisons Disagree With Each Other

Search for a cloud price comparison and you will find articles that name a different winner, sometimes within the same week. That is rarely because anyone made an arithmetic mistake. The three providers use different pricing models, different discount structures, and slightly different billing increments, which makes a true apples-to-apples comparison hard even when everyone is acting in good faith. A comparison that assumes on-demand pricing will favor one provider. One that assumes a one-year commitment will favor another. One that assumes an existing Microsoft Enterprise Agreement or reused Windows and SQL Server licenses will favor Azure, because Azure’s pricing becomes highly competitive when those are factored in, while without license reuse its VM prices sit close to AWS and Google.

Instance equivalence is the second source of disagreement. Matching vCPU count and memory does not match performance. A cost-optimized family on one provider and a current-generation general-purpose family on another can share the same headline specification and behave differently under load, so a lower hourly price sometimes reflects a lower-performing machine rather than a better deal. The third source is scale and account structure. Marketplace purchases and enterprise agreements can count toward spending commitments, which quietly distorts published comparisons for large accounts and makes them a poor guide for a small team paying list price.

Finally, there is date. VM prices change, new instance generations arrive, and regional premiums shift. Any comparison, including this one, is a snapshot, and the useful skill is not memorizing a winner but knowing which lines to check and how to rebuild the comparison yourself in ten minutes.

The Compute Line: What Published List Prices Show

Based on 2026 list pricing compiled by third-party trackers, a general-purpose 4 vCPU and 16 GB instance costs about 20 cents an hour on AWS, a little under 20 cents on Azure, and roughly 13 cents on Google Cloud when billed on demand. Over a standard 730-hour month those rates work out to approximately $147, $140, and $98 per instance. Azure’s figure moves a few cents depending on which processor family you pick, since an AMD-based D4as v5 sits nearer 17 cents an hour in East US than the Intel-based D4s v5 used in the calculator defaults.

For a smaller 2 vCPU and 8 GB instance, the same trackers put AWS and Azure at roughly $30 a month on demand against about $24 on Google. The pattern is consistent: at list price, Google’s compute is the cheapest of the three for comparable general-purpose sizes, AWS and Azure sit close together, and the gap narrows or even closes once commitments, licensing, and everything outside the VM line enter the picture. Treat these figures as illustrative inputs for the calculator rather than a verdict, and confirm each one against the official pricing page before it drives a real decision.

Three Different Discount Philosophies

The three providers reward commitment in different ways, and understanding the difference matters as much as the discount percentage itself. AWS offers Savings Plans and Reserved Instances on one or three year terms, with discounts that reach roughly 72 percent at the top end. Standard Reserved Instances tie you to a specific instance family and region, which gives the deepest discount and the least flexibility. Savings Plans trade a little discount for much more freedom to change instance types, which is usually the better fit for a team whose architecture is still moving.

Azure uses Reserved VM Instances with a similar structure, reaching about 72 percent for a three-year term, and adds the Azure Hybrid Benefit, which lets organizations apply existing Windows Server and SQL Server licenses to Azure VMs and cut the effective price substantially. For a team that already owns those licenses, Hybrid Benefit can matter more than any commitment discount. For a team that does not, it is irrelevant, which is one reason Azure comparisons depend so heavily on who is asking.

Google Cloud takes a different approach. Sustained use discounts are applied automatically when an instance runs for a large part of the month, require no commitment, and reach up to 30 percent, calculated per machine family per region. Eligibility depends on the machine family, and some cost-optimized families are priced low to begin with rather than receiving the automatic discount, so confirm that the exact machine type you plan to use qualifies before counting on it. Google also offers committed use discounts for teams willing to commit in exchange for deeper savings. The practical difference is that AWS and Azure require you to decide, plan, and purchase, while Google gives part of the discount to anyone who simply leaves a machine running.

The Cost of Not Committing

That difference in philosophy has a real dollar consequence for small teams. A team that runs steady workloads on demand and never buys a commitment can leave 20 to 30 percent of its compute spend on the table, according to comparisons aimed at small teams, and on AWS and Azure that outcome is the default unless someone takes action. On Google, part of that saving arrives automatically, which is why Google tends to win simple comparisons for teams that forget or postpone commitment decisions.

The sensible approach is neither to commit on day one nor to postpone forever. Run on demand for a month or two to learn what your steady baseline actually is. Then commit only to the portion of usage you are confident will exist for the full term, and leave spikes, experiments, and anything uncertain on on-demand pricing. Over-committing is a real mistake in the other direction, since an unused commitment is a fixed bill for capacity you are no longer using, and it is easiest to avoid by starting with a small commitment and adding to it as usage proves stable. Use the discount row in the calculator to compare your bill with and without a commitment on the portion of capacity you are sure about.

Spot and Preemptible Instances

All three providers sell spare capacity at a steep discount, commonly 60 to 90 percent below on-demand pricing, in exchange for the right to interrupt your instance when the capacity is needed elsewhere. Published figures for a small VM put spot pricing at roughly $9 a month on AWS, $3 on Azure, and $6 on Google, though spot prices fluctuate and those numbers change often.

The discount is only useful for workloads that can survive being stopped. Batch processing, video encoding, data pipelines, stateless workers pulling from a queue, and CI build runners all fit well. A single production web server, a primary database, or anything that holds state in memory does not. If you run your own CI runners, spot capacity is one of the easiest large savings available, and this comparison of CI/CD tools covers the pipeline setups where interruptible runners make sense. Build the interruption handling first, then enable spot, rather than the other way around.

Utilization Does Not Change the Price

A virtual machine running at 10 percent CPU costs exactly the same as one running at 100 percent. The meter runs on allocated capacity, not on use, which means the cheapest way to cut a cloud bill is often not negotiating a better rate but running a smaller machine, or fewer of them, or running them for fewer hours. VM sizes drift upward over time as applications grow and nobody revisits the original choice, and every provider offers rightsizing recommendations that flag instances using a small fraction of what they were allocated.

Scheduling is the other lever, and it is easy to quantify with the hours field in the calculator. A development or staging environment that only needs to exist during working hours, say ten hours a day on weekdays, runs for roughly 217 hours a month instead of 730, which cuts its compute cost by about 70 percent with no change in rate. Set the hours field to 217 and compare the result with 730 to see the difference for your own setup. Production usually cannot be scheduled this way, but non-production environments almost always can, and they are frequently left running around the clock by default.

Egress: The Line That Dwarfs the Rest

Outbound data transfer is the single most underestimated item on a cloud bill. All three providers charge for traffic leaving their networks to the internet, and for traffic moving between regions, and sometimes between availability zones inside a region. For a data-heavy application, a streaming service, a file-sharing product, or an API returning large payloads, that network bill routinely exceeds the difference between providers’ VM prices, and it can erase a VM saving entirely.

The calculator’s defaults make the point concrete. With two instances, 200 GB of storage each, and 500 GB of monthly egress, the VM is more than 80 percent of the bill on AWS. Raise egress to 5,000 GB and the VM falls to under 40 percent of the same bill, while the egress line grows to $441. The gap between providers on VM price is unchanged in absolute dollars, but it shrinks from about a quarter of the total to about an eighth, because a much larger share of the bill now depends on a network rate that the VM comparison never touched.

Several habits reduce egress without changing providers. Put a content delivery network in front of anything that serves static or cacheable content, so repeated downloads are served from the edge rather than your origin. Compress responses. Keep chatty traffic between services inside one region and, where practical, one availability zone. And be careful with architectures that move large volumes of data between clouds, since egress is the toll you pay in both directions and it is the main reason multi-cloud setups cost more than their VM prices suggest. Allowances for free egress differ by provider and change over time, so the free allowance field in the calculator is editable.

Storage, Snapshots, and the Slow Leak

At small scale, the per-gigabyte price difference between providers is close to irrelevant. Comparisons aimed at small teams put the monthly difference on 500 GB of storage at a dollar or two. What matters far more is waste. Oversized disks that were provisioned generously and never shrunk, snapshots from a project that ended months ago, and data sitting on a premium tier when a cheaper one would do all inflate a bill gradually, and no single line looks alarming enough to investigate.

A periodic storage audit is worth scheduling, quarterly is a reasonable cadence, covering unattached disks, old snapshots, and anything on an expensive storage class that is rarely read. It is dull work with a dependable payoff, and it is one of the few cost activities that does not require understanding any provider’s pricing model in depth.

Support Plans

AWS and Google Cloud generally tie paid support plans to a percentage of monthly spend, usually with a minimum monthly charge, so the cost of support grows as your bill grows. Azure’s support tiers are typically fixed monthly fees instead. Because of that difference, the calculator gives each provider its own support percentage and its own flat extras field. For a percentage-based plan, enter the percentage. For a fixed-fee plan, leave the percentage at zero and type the monthly fee into flat extras. Check each provider’s current plan terms before you do, since tiers and minimums change.

In the base scenario, a 10 percent support charge adds roughly $36 a month to the AWS total and about $26 to the Google total. Whether that is worth paying depends on what an outage costs you. A hobby project can reasonably run on the free tier of support. A revenue-generating application with no on-call engineer is a different calculation, and a rule of thumb that holds up is to buy a plan once the cost of one serious unresolved incident exceeds several months of the plan’s price.

Load Balancers, NAT Gateways, and Managed-Service Premiums

The headline VM price excludes a group of items that are easy to forget and that add up quickly: load balancers, NAT gateways, public IP addresses, and the premium that managed services charge over running the same software yourself. Load balancers and NAT gateways typically carry both an hourly charge and a per-gigabyte processing charge, which means they scale with traffic in a way that a VM does not.

These are the lines to enter into flat extras, using the provider’s own calculator for the exact figure. Before adding a load balancer, it is also worth asking whether you need one yet. A single well-sized instance behind a reverse proxy handles a lot of traffic, and this comparison of load balancing algorithms covers what a balancer actually does and when its cost is justified by the redundancy it buys.

Managed Databases

After compute, a managed database is usually the next largest line. Comparisons built from public pricing calculators put Google’s Cloud SQL roughly 10 to 15 percent below the equivalent AWS offering for standard relational workloads of the same instance size, and for small teams running ad hoc analytics on a few hundred gigabytes, per-query analytics pricing can be hard to beat. DynamoDB’s request-based pricing is often easier to predict for a small team than capacity-based alternatives. None of these numbers are universal, and database cost depends heavily on instance size, storage, backups, high availability, and read replicas, so use the flat extras field with a figure taken directly from the provider’s calculator rather than estimating.

The bigger lever is usually the choice of database itself, since the right engine for the workload decides how large and how expensive the instance has to be. The SQL vs NoSQL comparison on this site covers that decision before any pricing page enters the picture.

Region Choice

Prices vary by region, sometimes noticeably. Australian regions such as Sydney and Melbourne typically carry a small premium over US list prices on all three providers, and the same pattern holds for several other regions. Choosing a region is therefore a cost decision as well as a latency and data residency decision, and it is worth running the calculator with the rates for the two or three regions you are actually considering rather than assuming US East pricing applies everywhere. If your users are concentrated in one geography and nothing requires you to host elsewhere, the cheapest acceptable region near them is usually the right answer.

Free Tiers and Credits

Free tiers and new-account credits are real, and the terms have changed several times across all three providers in recent years, so any specific figure quoted in an article is likely to be out of date. The useful way to treat them is as a head start, not a plan. Credits expire, free allowances cover small amounts of specific services, and a project that fits comfortably inside a free tier during development can produce a surprising first bill the month it exceeds one.

Set a billing alert before deploying anything, and set it at a low threshold. All three providers support budgets and alerts, and a five-minute setup at the start prevents the most common beginner outcome, a large bill discovered only after a forgotten resource ran for weeks. Model your real usage in the calculator at full paid rates, not at free-tier rates, so the transition does not come as a surprise.

A Worked Example With the Calculator’s Defaults

With the defaults on this page, two instances running all month, 200 GB of storage each, and 500 GB of egress with a 100 GB free allowance, the totals come out as follows. The compute lines are $294.34 on AWS, $280.32 on Azure, and $195.64 on Google. Storage adds $32 and egress adds $36 to each, because those two rows use identical placeholder rates across providers.

Three things are worth noticing. First, a commitment discount cuts every total by roughly the same proportion of its compute line, so it changes the absolute bill a great deal and the ranking not at all. Second, the egress-heavy scenario leaves the dollar gap between AWS and Google unchanged at about $98.70, yet that gap falls from roughly 27 percent of the AWS total to under 13 percent, which is the dilution effect described earlier. Third, this example assumes identical egress and storage rates for all three providers, which is a simplification. In reality those rates differ, and substituting your own figures is the most valuable thing you can do with this tool.

A Cost-Control Checklist

• Right-size before you commit. A commitment on an oversized instance locks in the waste.
• Run non-production environments only when they are used, and model the saving with the hours field.
• Commit only to the baseline you are confident will exist, and leave spikes on on-demand pricing.
• Use spot or preemptible capacity for interruptible work such as batch jobs and CI runners.
• Put a CDN in front of cacheable content to reduce egress from your origin.
• Check whether ARM-based instances run your stack. Most PHP, Node, and Python workloads do, and the ARM options on all three providers are typically cheaper for equivalent capacity, but verify native extensions and container images first.
• Audit storage quarterly for unattached disks and stale snapshots.
• Tag resources by project or workload so cost can be tracked per workload, not just per VM.
• Set budgets and billing alerts before the first deployment.
• Re-run this comparison when you change region, instance family, or traffic pattern, because the old answer may no longer hold.

Tracking cost per workload rather than per virtual machine is the habit that makes the rest easier. A VM-level view hides the real drivers of spend, since the same instance can serve several purposes and the expensive part of a workload is often the network or the database sitting beside it.

When a Plain VPS Beats a Hyperscaler

For a small application, none of this complexity may be necessary at all. A single VPS from a conventional host comes with a predictable flat monthly price, bundled bandwidth, and no separate line items for NAT, load balancing, or egress, and for a typical small PHP or Node application that predictability is worth more than the flexibility of a hyperscaler. Two cloud instances plus a load balancer plus a NAT gateway plus a managed database can easily cost several times what a well-chosen VPS would, for an application that never needed autoscaling or global regions.

Hyperscalers earn their price when you need managed services you would otherwise run yourself, autoscaling for unpredictable traffic, compliance certifications, or a footprint across many regions. If you are not sure which side of that line you are on, this comparison of shared hosting, VPS, and cloud walks through the decision, the VPS comparison covers specific options, and the Laravel hosting guide covers the budget end. When scaling does become a real need, vertical scaling is usually the cheaper first move, a point explored in the deployment guide, and container orchestration is a later step, covered in the Docker vs Kubernetes comparison.

Multi-Cloud and the Egress Trap

Running across more than one cloud is sometimes presented as a way to avoid lock-in or to chase the lowest price for each workload. In practice it multiplies the cost lines this article has been describing. Every byte that moves between clouds pays egress on the way out, the operational overhead of two sets of tooling and permissions is real, and the committed discounts you earn on each platform shrink because your spend is split. Multi-cloud makes sense for specific reasons, such as an acquisition that brought a second cloud with it, a regulatory requirement, or one managed service that has no equal elsewhere. It rarely makes sense as a cost strategy for a small team.

Common Mistakes

Comparing only the hourly VM rate is the mistake this whole piece is built around. It produces a clean, confident answer to the wrong question, since the VM is only part of the bill and often a shrinking part as traffic grows.

Treating matching vCPU and memory as matching performance leads to choosing the cheapest instance on paper and discovering under load that it was a different class of machine. Compare price per unit of work you actually care about, not just price per vCPU.

Committing too early or too heavily locks in capacity for an architecture that is still changing, while never committing at all quietly costs a small team 20 to 30 percent of its compute spend. The workable middle is to learn the baseline first and commit to a conservative slice of it.

Leaving development and staging running around the clock is probably the most common source of avoidable spend, since the same environment used for ten hours a day is paid for at 24. And forgetting the unglamorous lines, support, NAT gateways, load balancers, snapshots, and egress, is how a budget that looked comfortable on the pricing page becomes a bill that does not.

Finally, trusting stale numbers causes more bad decisions than any other single habit. A figure from a year-old article, including the defaults in this calculator, may no longer be right. The lasting value of a tool like this one is the structure of the comparison, which stays valid, not the rates inside it, which do not.

Real Scenarios

FAQ