Cloud & DevOps
ConceptBeginner 18 min· Cloud · 12 of 16

Cloud costs, free tiers and avoiding surprise bills

Understand how cloud billing works, what free tiers really include, the common ways beginners get surprise bills, and a day-one routine of budgets, alerts, clean-up and key safety. Includes how real teams lower costs.

Every year students and beginners post the same story: "I followed a tutorial, forgot to delete a server and got a bill I cannot pay." Cloud billing is pay as you go, which is wonderful when you are careful and painful when you are not. This lesson explains how the bills are made up, how free tiers really work, and a short routine that protects you.

You will not need an account to read it, but the routine is meant to be done on the day you create one.

How cloud billing works

You are charged for resources while they exist or run, not only while you use them. A virtual machine that sits idle all night still bills per hour (or per second). A database you forgot is billed every hour. Think of a taxi with the meter running even when you are shopping.

Most charges come from four meters:

What you pay for

MeterExampleBeginner trap
Compute timeEC2 / VM / Kubernetes nodes billed per hour or secondLeaving a machine running; managed Kubernetes nodes
StorageDisks, S3 / Blob buckets, snapshotsOld snapshots and unattached disks keep billing
Data transferTraffic leaving the cloud to the internet or another regionSurprise from a popular file or a chatty app
Managed servicesDatabases, load balancers, NAT gateways, search clustersMany bill every hour even with zero traffic

Data coming into a cloud is usually free; data going out is billed. Private traffic inside one zone is cheaper than traffic across zones or regions. Exact prices vary by region and change, so use the provider's pricing page and calculator rather than a number from a blog.

Free tiers: what they really are

Each big provider offers something free for learners, but the shape differs and changes. Check the official page before you rely on it. At the time of writing (2026):

AWS: new accounts get a free plan with credits and a time limit instead of the old twelve-month model. When the credits or time run out the account must be upgraded to a paid plan or services stop. A few services also have small always-free allowances. Azure: new accounts usually get a credit for a limited period plus some services free for twelve months and some always free. Google Cloud: a trial credit for a limited period, plus an always-free tier for selected products with monthly limits.

Three rules apply to all of them. The free allowance covers specific services up to specific limits: outside them you pay. Credits and trials end, and after that the same resources start billing. And a free tier is per account, so a second account does not stretch it and breaks the provider's terms.

Old tutorials mislead

Never assume a service is free because you saw 'free' in a video. Open the official free tier page for your provider, find the exact service and the limit (for example, which instance type and how many hours), and write it down. Free-tier rules were changed by AWS in 2025, which is why older tutorials can be wrong.

The usual ways people get surprised

Common causes of surprise bills

  1. A virtual machine or Kubernetes cluster left running after a tutorial.
  2. A managed database kept 'for later'. These bill around the clock.
  3. A NAT gateway or load balancer created by a template. Both have an hourly charge.
  4. An Elastic IP or public IPv4 address that is not attached to anything.
  5. Large unattached disks and old snapshots.
  6. Public buckets or APIs found by bots, leading to huge data transfer or request counts.
  7. Leaked access keys used by attackers to start expensive machines (crypto mining). This is the most expensive surprise.
  8. Logs growing forever, or a loop in serverless code that triggers itself.

Notice the leaked key. Security and cost are linked: a key pushed to a public GitHub repository can be found by automated scanners within minutes. Never commit keys, and keep them in environment variables or a secrets manager.

The protection routine: do it on day one

A safe learning routine

  1. 1Create a budget with email alerts as soon as the account exists. In AWS this is under Billing, Budgets. Set a small monthly amount (for example the most you would be happy to lose, in rupees) and alerts at around 50%, 80% and 100% of it. Azure has Cost Management budgets and Google Cloud has Billing budgets and alerts.
  2. 2Remember that budgets alert; they do not stop spending by themselves. Check your email, and keep your phone number and email current on the account.
  3. 3Secure the account: turn on multi-factor authentication (MFA) for the root or owner login, do not use root for daily work, and create an IAM user or SSO identity with only the permissions you need.
  4. 4Use the billing dashboard (AWS Cost Explorer, Azure Cost analysis, Google Cloud Reports) once a week while learning to see which service is costing.
  5. 5Tag or name every practice resource with a project name, so you can find and delete it.
  6. 6At the end of every session, run a clean-up pass: stop or delete machines, delete databases, release IP addresses, delete load balancers and NAT gateways, empty and delete buckets. If you used Terraform, run terraform destroy.
  7. 7Once a month, check every region, not only your usual one. Resources in a region you forgot still bill.

Cheapest practice

Prefer the learning ladder: run things locally first (Docker, kind, LocalStack-style emulators), use serverless that scales to zero for cloud practice, and avoid always-on managed services until you need them.

Designing for lower cost in real projects

Companies care about cost too, and engineers who can reduce a bill are valued. The usual levers:

Right-size. Most servers are bigger than needed. Check CPU and memory graphs and choose a smaller instance.

Turn things off. Development and test environments do not need to run at night or on weekends. Scheduling them off cuts their compute bill a lot.

Pick the right pricing model. On-demand is flexible and most expensive. Commitments (savings plans, reserved instances) give a discount if you promise steady use for a period. Spot or preemptible capacity is cheaper but can be taken away at short notice, so it suits batch work that can restart.

Use storage tiers and lifecycle rules. Move rarely read objects to cheaper classes and delete temporary files after some days.

Mind data transfer. Keep services that talk a lot in the same region and zone, and use a CDN for popular static files.

Tag everything. Without tags you cannot tell which team or project caused a charge. Doing this well is called FinOps: engineering, finance and product sharing responsibility for cloud spend.

Estimating before you build

Every provider has a pricing calculator (AWS Pricing Calculator, Azure pricing calculator, Google Cloud pricing calculator). List the resources, the hours per month and the data transfer, and read the total. Do this for the Brew & Bean website: a static site on object storage with a CDN will cost a very small amount, while the same site on a managed Kubernetes cluster with a load balancer and database will cost far more even with no customers. Choosing the simplest architecture is the biggest saving.

Prompt · Estimate my cloud bill
You are a cloud cost advisor. I am planning to run [describe your app, e.g. a FastAPI backend with a Postgres database and a React frontend] on [AWS / Azure / Google Cloud] in the [region] region for [expected users or traffic].

1. List every billable resource I would need, including easy-to-forget ones such as load balancers, NAT gateways, public IPs, logs and data transfer.
2. For each, name the pricing dimension (per hour, per GB, per request).
3. Suggest the cheapest architecture that still meets my needs and say what I give up.
4. Do not quote prices from memory. Tell me exactly what to enter in the official pricing calculator.

What to expect: A good answer lists resources and pricing dimensions and sends you to the official calculator instead of inventing numbers. Check any specific price it states against the provider's page.

How this comes up in interviews

Questions you may hear: How would you reduce a cloud bill by 30%? (find the top services in the cost report, right-size, remove idle resources, schedule non-production, use commitments or spot where suitable, tune storage and transfer.) What is the difference between on-demand, reserved and spot? How do you stop developers creating expensive resources? (budgets and alerts, tagging policies, limited IAM permissions, infrastructure as code with review.) Tell me about a time something cost more than expected. If you can say 'I set a budget alert on day one and caught a forgotten NAT gateway', that is a strong answer.

Try it: Do a cost audit

Open the billing or cost dashboard of any cloud account you have (or of the practice account you create). Write down: the three services with the highest cost, any resources that exist but you are not using, and whether a budget alert exists. Then create a budget with alerts at 50%, 80% and 100%.

Key takeaways

  1. Cloud resources bill while they exist, not only while you use them; storage, IPs, load balancers and managed databases bill even when idle.
  2. Free tiers and trial credits are limited to specific services and end after a period. They change often, so read the official page.
  3. On day one: set a budget with alerts, enable MFA, avoid the root account and never commit access keys.
  4. Alerts do not stop spending. Delete practice resources after every session and check all regions.
  5. To reduce real bills: right-size, switch off idle environments, choose the right pricing model, use storage tiers and tag everything.
  6. The simplest architecture is usually the cheapest.

Check yourself

Finishing the quiz marks the lesson as done.

1. You stop a virtual machine but leave its large disk and a reserved public IP. What happens?

2. What does a cloud budget alert do?

3. Which is the most dangerous and expensive beginner mistake?

4. Why are free tier tutorials sometimes wrong?

5. Which workload is best suited to cheaper spot or preemptible capacity?

Saved on this device. Create a free account to keep it on every device.

Practise this with Sam

A real mock interview, out loud, with an honest scorecard. Free to start.

Start free