AWS Free Tier: What Actually Costs Money
The AWS free tier is only free if you keep an eye on it. There is no drama here. No horror story. Just a simple reality: AWS will happily keep charging you if you leave things running, and the console will not stop you. The free tier gives you room to learn, experiment, and build, but it does not replace paying attention.
This post is not a lecture and it is not a warning label. It is simply the way I check a new AWS account when I want to stay inside the free tier. The steps are basic, but they work because they force you to look at what is actually running instead of assuming nothing is happening.
I cannot verify these steps from this blog repo. Treat this as a walkthrough you can run in your own AWS account.
What this post is actually about
On paper, the AWS free tier is a list of monthly allowances. In practice, it is a system that only stays free if you regularly confirm what is active. Most surprise bills come from one of two things: resources left running, or no cost alerts. This guide focuses on fixing both of those.
What actually costs money in the free tier
On paper, the AWS free tier sounds generous. In practice, a few specific services are responsible for almost every surprise bill. I like to keep a simple mental model of what is truly "dangerous" if left running, what is usually safe, and what only costs money when you move data around. A table makes this clearer than a long explanation.
| Service | Free tier allowance | What actually causes charges | Why people get surprised |
|---|---|---|---|
| EC2 | 750 hours per month of t2.micro or t3.micro (first 12 months) | Running an instance outside free tier size, or running 24/7 for months | People forget instances are still running after testing |
| RDS | 750 hours per month of db.t2.micro or db.t3.micro (first 12 months) | Leaving a database running continuously | Databases feel "small" but charge every hour |
| S3 | 5 GB standard storage | Storing large files or keeping old test data | Storage accumulates quietly over time |
| Lambda | 1 million requests per month | High request volume or long execution time | Rare for beginners, but possible in loops |
| Data Transfer | Limited free outbound data | Downloading large files or heavy frontend traffic | Bandwidth is easy to forget to measure |
This table is not meant to be perfect or exhaustive. It is just the handful of services that matter most when you are learning. If you watch EC2, RDS, and S3, you already avoid most free tier mistakes.
Before you start
All you need is an AWS account with access to the Billing console and an email address that can receive alerts. That is it. No CLI, no automation, no infrastructure-as-code. Just the console.
Once you have that, the workflow is always the same. First, you look at what is running. Then you add a small cost alarm so you are never surprised. Finally, you glance at the cost explorer so you know where money is actually going.
Step 1: Audit what is currently running
The first thing I do in any AWS account is look for resources that can quietly cost money if left on. EC2 and RDS are the most common culprits, so I start there.
Open the AWS Console and go to EC2. Click Instances. If anything is running and you do not actively need it, stop it. Do not overthink it. If you are not using it right now, it does not need to be running.
Then go to RDS. Click Databases. If you have a database sitting there from a test project you forgot about, delete it. RDS charges hourly, and free tier allowances are easy to burn through if you leave a database alive for weeks.
This step sounds simple, but it matters because most free tier surprises come from forgetting that something is still alive in the background. When you finish this step, you should be able to say, with confidence, “I know exactly what is currently running in this account.”
If you notice resources that keep reappearing after you stop them, check whether you created an auto scaling group or scheduled start/stop rule. Those will bring instances back even when you think you shut them down.
Step 2: Create a small budget alert
Once I know what is running, the next thing I do is add a tiny cost alarm. This is the safety net that catches mistakes.
Go to the AWS Console, open Billing, then Budgets, and create a new budget. Choose a cost budget, set the amount to something small like $5, and attach an email alert. This does not stop charges. It simply tells you early that something is happening.
The reason I like a very small budget is that it gives you time to react. If a resource starts charging unexpectedly, you get a warning before it turns into a real bill. It is cheap insurance, and it takes less than a minute to set up.
After creating the budget, check that it appears in the Budgets list. That confirmation matters, because without an alert you are relying entirely on memory to notice costs.
If the Budgets page is unavailable, you may need to enable Billing access for your IAM user in the account settings. That is a one-time account setup step.
Step 3: Look at Cost Explorer
Even with alerts in place, I still like to glance at Cost Explorer. This is where you see which services are actually generating charges.
Open the AWS Console, go to Cost Explorer, set the time range to the last seven days, and group the view by Service. You will get a simple chart showing where money is going.
Most of the time in a fresh free tier account, this chart will be almost empty. That is good. If something shows up that you do not recognize, that is your signal to go back and find what is running.
If Cost Explorer is not enabled, the console will ask you to enable it. Do that once, and it will start collecting data going forward.
How I verify that everything is safe
When I finish these three steps, I want to be able to answer three questions without guessing. Do I know what resources are currently running. Do I have a cost alert that will email me if something starts charging. And can I see which services are generating costs.
If the answer to all three is yes, then I know I am operating inside the free tier with guardrails in place. Nothing fancy. Just visibility and early warning.
Common ways people get surprised
Most surprise bills come from the same patterns. Leaving an EC2 instance running for days after testing. Forgetting an RDS database exists. Spinning up a resource in a different region and never looking at it again. Or never creating a budget alert and assuming the free tier will “just work.”
None of these are advanced mistakes. They are simple oversights. This checklist exists to prevent exactly that.
Quick symptom-to-cause reference
When something does go wrong, it usually follows very predictable patterns. Instead of guessing, I like to keep a simple reference in my head for what to check first.
| Symptom | Likely cause | First thing to check |
|---|---|---|
| Monthly cost suddenly appears | EC2 instance still running | EC2 → Instances page |
| Bill keeps growing slowly | RDS database left alive | RDS → Databases page |
| Small but steady charges | Old files in S3 | S3 bucket storage size |
| Unexpected regional charges | Resource created in another region | Region selector in console |
| No alerts before a bill | No budget alert configured | Billing → Budgets |
This keeps troubleshooting simple. Look at the symptom, check the first obvious place, and you usually find the answer in minutes, not hours.
Closing
The AWS free tier is useful, but it is not magic. It rewards people who look at their account and punishes people who assume nothing is happening.
If you take five minutes to audit running resources, add a small budget alert, and glance at Cost Explorer, you remove almost all of the risk. That is the entire point of this guide.
No hype. No fear. Just staying aware of what is actually running in your account.