, , ,

How Cloud Billing Works (and How Bills Explode) (Cloud for Beginners, Part 13)

Cloud bills explode from quiet meters, not the obvious server. Here is how cloud billing really works, the charges that ambush freshers, and a real bill broken down line by line.

Cloud for Beginners · Part 13 of 18
TL;DR
Cloud providers charge you by the second for small units of compute, storage, and network traffic. The sticker prices look tiny. Bills explode not from the server you meant to run but from the quiet meters: data leaving the provider, traffic routed through gateways, and resources you forgot to delete. Learn to read the three meters, set a budget alert on day one, and you will not get ambushed.
Who this is for
A fresher or new IT hire who has heard that cloud is pay-as-you-go but has never seen a real invoice, and wants to understand why the number is what it is before it lands on their desk at work.

Your first cloud bill can arrive looking like a phone bill from a country you never visited. You spun up one small server to practice on, left it running over a long weekend, and the invoice has nine line items you do not recognise. Nothing broke. Nobody made a mistake. That is just how cloud billing works, and most people learn it the expensive way.

This part takes apart a real, small bill so you can see exactly where the money goes, and why the line you worried about is almost never the line that hurts.

You rent the meter, not the box

Think about electricity at home. You do not buy power one appliance at a time. A meter on the wall counts kilowatt-hours, and at the end of the month you pay for whatever flowed through it. Leave a heater on while you are away and the meter does not care that you meant to switch it off. It just counts.

Cloud billing is that same idea pointed at computers. You do not buy a server. You rent a slice of one, and a meter counts the seconds it ran, the gigabytes it stored, and the bytes that moved across the network. Delete the resource and the meter stops. Forget about it and the meter keeps counting, by the hour, every hour, until somebody notices.

That one sentence explains most surprise bills. On-premises, a switched-on server you forgot about costs nothing extra, because the hardware was already paid for. In the cloud, forgetting has a running price tag.

Resource runningMeter ticksper secondLine on invoice
Every charge starts as a meter tick on something that is switched on.

The three meters behind every bill

Strip away the marketing and every provider bills you on three basic meters. AWS, Azure, and Google Cloud use different names and slightly different rates, but the shape is identical.

Compute: time

The seconds your virtual machines, containers, or functions actually run, priced by size. A bigger machine ticks faster. This is the meter most people expect.

Storage: stuff kept

The gigabytes you hold, priced per GB per month, sometimes with a small charge per request on object storage. A disk keeps billing even when the instance attached to it is switched off.

Network: data moved

The bytes that travel, and above all the bytes that leave the provider. This is the meter you cannot see by looking at your resources, and it is where freshers get hurt.

COMPUTEcounts timeper second / hourSTORAGEcounts what you keepper GB / monthNETWORKcounts data movedper GB out
Whatever the provider, the bill rolls up into these three.
MeterWhat it countsRough unitThe trap
ComputeRunning time of VMs, containers, functionsper second or hourLeft on over a weekend
StorageDisks, snapshots, objects keptper GB / monthBills even when the instance is stopped
NetworkData leaving the provider or crossing zonesper GB outInvisible until the invoice arrives
Why this matters in your first job
Nobody hands the new person the production keys in week one. They will hand you the bill investigation. The dev account went up twenty percent this month, can you find out why is a classic first task, because it is low risk and it teaches you the account. If you already know the three meters and the usual zombies, you look sharp before you have shipped a single thing.

Where the bill actually explodes

Egress: the exit toll

Egress is data leaving the provider for the internet. Data coming in is almost always free. Data going out is not. As of 2026, AWS charges about 0.09 dollars per GB for the first tier of internet egress each month, Azure about 0.087 dollars per GB, and Google Cloud about 0.12 dollars per GB on its premium network. AWS and Azure give you the first 100 GB a month free.

Pennies, until you serve video, ship logs to another tool, or copy a database to a second region. A one-time 500 GB transfer out of AWS is roughly 36 dollars after the free slice. Nobody warned you because the price lives in a different part of the console from the button you clicked.

The NAT Gateway tax

If I had to bet on the one line that surprises a beginner, it is the NAT Gateway. A wizard puts it in your network when you ask for a private subnet, and it carries two charges that stack. In a region like US East Ohio it costs about 0.045 dollars per hour just to exist, which is roughly 32 dollars a month before a single byte moves, plus another 0.045 dollars for every GB it processes.

Now add the egress charge on top, because internet-bound traffic pays both. That puts internet traffic through a NAT Gateway at about 0.135 dollars per GB, three times the sticker price you saw on the egress page. Worse, traffic from a private subnet to S3 or DynamoDB runs through it by default and pays the processing fee, even though that data never touches the public internet. The fix exists and it is free: a VPC gateway endpoint for S3 and DynamoDB skips the NAT entirely.

Zombies and IPv4 rent

Since February 2024, AWS charges 0.005 dollars per hour for every public IPv4 address, attached or not, which is about 3.65 dollars a month each. A stopped instance still keeps its disk, and you pay for the disk. An old snapshot, a load balancer from a deleted project, an address nobody released: these zombies sit on almost every team bill. Each one is small. Twenty of them is a real number.

Private instanceNAT Gateway+0.045 / GBInternet+0.09 / GBOne byte to the internet pays both meters: about 0.135 dollars per GB
The same byte can pass two meters before it leaves.
Gotcha
A stopped instance is not a free instance. Stopping halts the compute meter only. The disk, snapshots, allocated addresses, and any gateway keep billing. When you are done with something, delete it, do not just stop it.

A real small bill, broken down

Here is a believable monthly bill for a tiny hobby web app on AWS in a US region, left running all month. Every unit price below is a real 2026 rate. The point is not the total. It is the shape.

Worked example
t3.micro instance on all month (on-demand): about 7.50 dollars
30 GB gp3 disk at 0.08 dollars per GB: 2.40 dollars
1 public IPv4 address at 0.005 dollars per hour: 3.65 dollars
1 NAT Gateway, hourly charge only: about 32 dollars
NAT data processing, 200 GB at 0.045 dollars: 9.00 dollars
Internet egress, 150 GB billable after the free 100 GB: 13.50 dollars
Total: about 68 dollars a month

Look at the share. The server you thought you were paying for is 7.50 dollars, about one ninth of the bill. The NAT Gateway you added with one click, mostly idle, is nearly half. Five sixths of this invoice is network and plumbing, not the thing you actually built.

NAT hour$32Egress$13.50NAT data$9Instance$7.50IPv4$3.65Disk$2.40Dark bar is the thing you built. Red bars are plumbing and network.
The cheapest line is the app. The expensive lines are the ones nobody mentioned.
Real interview question
A teammate says our dev environment costs almost as much as production. Where do you look first?

Strong answer: separate fixed costs from usage costs. Start with always-on resources that do not scale to zero, the NAT Gateways, load balancers, idle databases, unreleased public IPv4 addresses, and orphaned disks and snapshots. Then check data transfer, especially cross-zone and egress. Say you would open Cost Explorer grouped by service and by tag, and set a budget so the next spike pages you instead of surprising you. That answer shows you understand that dev environments leak through fixed costs, not heavy use.

How to not get surprised

Three habits cover most of the risk. Set a budget with an email alert the day you open the account, before you launch anything. Tag every resource with a project name so a bill can be read by purpose instead of by cryptic resource IDs. And delete, do not stop, anything you are finished with.

Now the opinion. The common advice is to put a managed NAT Gateway in front of every private subnet because that is the production pattern. For a learner or a tiny workload, I think that advice is wrong by default. The NAT Gateway is the worst value line on a small bill, because it charges roughly 32 dollars a month whether or not any traffic flows. While you are learning, use free VPC gateway endpoints for S3 and DynamoDB, or skip private subnets entirely, or run a micro instance as a NAT for a tenth of the price. The vendors rarely lead with the fact that the gateway bills you for sitting idle. Architecture diagrams are not free.

Try it yourself
On a free-tier account, open AWS Budgets (or Azure Cost Management, or Google Cloud Budgets) and create a budget of 1 dollar with an alert at 80 percent. Then launch a t3.micro and terminate it a minute later.

How to check: within a day, open Cost Explorer. You should see the budget you made, the EC2 line sitting at or near zero, and maybe a few cents of public IPv4 if the address was held for a while. You just watched a meter start and stop. That muscle memory is worth more than any pricing page.

FAQ

Is the AWS free tier really free?
Mostly, within limits. Accounts created since mid-2025 get up to 200 dollars in credits and a six-month plan that closes when the credits run out or six months pass, whichever comes first. Older accounts use the legacy model with twelve-month and always-free items. Either way you can still be charged for anything outside the limits, like a second IPv4 address or extra storage.

Why am I charged when everything is stopped?
Stopping an instance stops the compute meter only. Disks, snapshots, allocated addresses, and gateways keep billing. Delete what you no longer need rather than leaving it stopped.

What surprises beginners most?
Data egress and NAT Gateway charges. Both are network meters you cannot see by looking at your instances, so they only show up on the invoice.

Can I set a hard spending limit?
Not a true cap. Cloud billing is post-paid, so providers give you budgets with alerts rather than a switch that stops resources. For an automatic stop you build automation that deletes or disables resources when a threshold is hit.

Does this apply to Azure and Google Cloud too?
Yes. The names differ, Azure Cost Management and Google Cloud Budgets, and per-GB rates vary a little, but the three-meter model and the egress trap are the same everywhere.

The list price is rarely the real price

Everything so far used on-demand rates, the price you pay for flexibility and zero commitment. It is also the most expensive way to buy compute. Providers sell the same machines cheaper if you promise to keep using them, and cheaper still if you accept that they can be taken back at short notice. As a fresher you will hear three terms thrown around, so here is what they actually mean.

Commitments: reserved instances and savings plans

If you agree to run a given amount of compute for one or three years, the provider drops the rate, and the advertised discounts run well past half off for the longest terms. Azure calls these reservations, Google Cloud calls them committed use discounts, AWS splits them into reserved instances and savings plans. The trade is simple: you swap flexibility for a lower price. The catch is just as simple. You keep paying for the commitment even if you stop using the machine, so a discount you bought in haste can become a year of paying for nothing.

Spot capacity: cheap but interruptible

Spare capacity sells at a steep discount, often a fraction of the on-demand rate. AWS calls it Spot, Google Cloud calls it Spot or preemptible, Azure calls them spot virtual machines. The deal: the provider can reclaim the machine with a couple of minutes warning when it needs the capacity back. That is fine for batch jobs, video encoding, or test runs that can restart. It is a terrible idea for your database or anything a user is waiting on.

One blunt piece of advice that goes against the FinOps blogs telling everyone to chase discounts: as a learner, do not buy any commitment on your own account. Stay on-demand and free tier. Commitments are a tool for steady production workloads with a year of history behind them, not for an account where you are still figuring out which services you like. The cheapest learning bill is the one you delete at the end of each session.

The takeaway

Cloud billing is not mysterious once you stop looking at the server and start looking at the meters. Three of them, compute, storage, network, and a short list of zombies that bill while you sleep. Read a bill by those categories and you will spot the explosion before it is your name on the report. Set a budget alert today, then go break something small on a free tier and watch the meter move.

Cloud for Beginners · Part 13 of 18
« Previous: Part 12  |  Complete Guide  |  Next: Part 14 »

References

AWS, NAT Gateway pricing
AWS, Public IPv4 address charge
AWS, Free Tier update with up to 200 dollars in credits
AWS, EBS pricing

About The Author


Discover more from Journal of Intelligent Infrastructure – By Dr Pranay Jha

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *

Architect’s Toolkit

About the Author

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

Discover more from Journal of Intelligent Infrastructure - By Dr Pranay Jha

Subscribe now to keep reading and get access to the full archive.

Continue reading