
A Hard Stop for AWS Free Tier: Kill Spend Before the Bill
AWS has no spending limit button. What exists is Budget Actions stopping EC2 and RDS or applying a deny policy at a threshold. This articles guides you on how to build that guardrail in a study account, step by step.
The most upvoted question in every beginner AWS community is the same one: how do I stop AWS from charging me?
The honest answer is that there is no spending limit button. What exists is a guardrail you assemble yourself and it works well enough for study and lab accounts. This is how to build it.
First, know which account you're in
The current Free Tier has two plans. On the Free plan, your account uses credits and free services for up to six months and doesn't bill beyond that; when credits run out or the window closes, resources are shut down. On the Paid plan, you get normal pay-as-you-go once credits are exhausted.
New accounts get $100 in credits at signup and can earn up to $100 more by completing activities.
The practical implication: if you're on the Paid plan, charges continue after the credits. That's the scenario this guardrail is for. Confirm your plan in the Billing console before anything else.
Layer 1: see it before it hurts
Turn on, in this order:
- Free Tier usage alerts: they fire when you cross 85% of a free limit, before it becomes a charge.
- A near-zero budget: a cost budget of $1 with an alert at 1% of actual spend so, in practice, it pings you on the first cent that escapes the free tier.
- Cost Anomaly Detection: catches the spike no fixed threshold would, like a GPU instance left running over a weekend.
That's monitoring. It prevents nothing. It's the layer you turn on always, including in production accounts.
Layer 2: the actual guardrail (Budget Actions)
Budget Actions is what turns a budget from informative into executive. When the threshold is crossed, AWS Budgets can:
- apply an IAM deny policy to users, groups or roles;
- apply an SCP in the Organization;
- stop specific EC2 or RDS instances.
So you can stop what's burning money, or take away everyone's ability to create new things. For a study account, the combination that works is stop EC2/RDS + deny creation of new resources.
What to prepare
1. A deny policy to apply on breach. Start by restricting what's expensive and not needed to inspect what already exists:
JSON
{"Version": "2012-10-17","Statement": [{"Effect": "Deny","Action": ["ec2:RunInstances","rds:CreateDBInstance","eks:CreateCluster","sagemaker:CreateNotebookInstance"],"Resource": "*"}]}
2. A service role for AWS Budgets with permission to apply policies and stop EC2/RDS. The Billing documentation ships an example permissions policy for exactly this: start from it instead of writing your own.
3. The budget with the action attached, with a threshold and targets. You choose whether the action runs automatically or waits for your approval. In a study account, it is automatic.
The three limits you need to accept
Be realistic about what this is:
- It is not instant. AWS cost data lags by hours. A fast burn can complete entirely before the trigger fires.
- Stopped is not deleted. A stopped EC2 instance still bills for its attached EBS which is around $0.08 per GB-month on gp3. So if the goal is zero, terminate, don't stop.
- It protects against carelessness, not compromise. A leaked access key with broad permissions generates a bill in minutes. The defense for that is different: never use static IAM user keys, use roles with temporary credentials, and enable MFA on the root user.
The build order
In a new account, in this sequence, it takes about 30 minutes:
- MFA on the root account, then never use root again.
- A working user or role with no static keys.
- Free Tier alerts on.
- A $1 budget with an alert.
- The Budgets service role created.
- A Budget Action pointing at the deny policy and at the instances that may be stopped.
Steps 1 and 2 aren't about cost, but they're the ones that prevent the bill no budget guardrail catches in time.
Have you run this setup? Tell me which alert saved you first.
Follow me for more tips! Let's connect!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article