Why cost control comes before code
In Level 1 you opened an account and chose between the Free plan and the Paid plan. Before you build anything, you need a smoke alarm. In AWS that alarm is AWS Budgets. You give it a monthly amount and it emails you when your spend gets close to that amount, goes over it, or is forecast to go over it.
The main thing experience teaches here: AWS bills you for what you leave running, not for what you use. A load balancer you forgot about costs the same at 3 a.m. with no visitors as it does at noon. Most surprise bills come from that kind of idle, hourly-billed resource, not from traffic spikes.
Gotcha: a budget is an alarm, not a spending cap. AWS Budgets updates up to three times a day, usually 8–12 hours apart, and billing data itself runs behind actual usage. You can be over your threshold before the email arrives. Budgets warn you. Only deleting resources stops the charges.
Walkthrough 1: a monthly cost budget with email alerts
Creating budgets and getting their alerts costs nothing. The only paid part is budget actions, which can do things like apply an IAM policy automatically. Your first two action-enabled budgets each month are free, and each one after that costs $0.10 a day. You don't need actions for this course.
- Open the Billing and Cost Management console and choose Budgets → Create budget.
- Choose Use a template (simplified).
- Pick Monthly cost budget. The other common choice, Zero spend budget, emails you as soon as your spending goes past the Free Tier limits. It's a good second budget to add.
- Enter a name such as
course-monthly, an amount such as $20, and your email address. - Choose Create budget.
The template sets up three notifications for you:
| Alert | Fires when |
|---|---|
| Actual 85% | Real spend reaches $17 |
| Actual 100% | Real spend reaches $20 |
| Forecast 100% | AWS predicts the month will end at or above $20 |
The forecast alert is the useful early warning, because it fires before the money has been spent. One catch: forecasts need some usage history first, so a brand-new account may not get forecast alerts straight away.
Under Template settings → JSON you can download what you just built. Read it once, because it shows exactly what a budget is made of:
{
"Budget": {
"BudgetName": "course-monthly",
"BudgetLimit": { "Amount": "20", "Unit": "USD" }, // the monthly amount
"TimeUnit": "MONTHLY", // resets on the 1st
"BudgetType": "COST" // dollars, not usage hours
},
"NotificationsWithSubscribers": [
{
"Notification": {
"NotificationType": "FORECASTED", // ACTUAL = already spent
"ComparisonOperator": "GREATER_THAN",
"Threshold": 100,
"ThresholdType": "PERCENTAGE" // 100% of $20
},
"Subscribers": [
{ "SubscriptionType": "EMAIL", "Address": "you@example.com" }
]
}
// ...plus the ACTUAL 85% and ACTUAL 100% entries
]
}
Best practice: send alerts to an address you actually read, or to a shared list. An alert that lands in a mailbox nobody checks does nothing.
If you're on the Free plan, the credits checklist on your account home page includes setting up a cost budget with AWS Budgets, and completing it earns $20 in credits.
Walkthrough 2: reading the Billing console
Three pages answer the question "how am I doing?":
- Home (Billing and Cost Management): month-to-date cost and a forecast for the month. Check this every time you finish a lesson.
- Credits: your remaining credit balance and when it expires. On the Free plan, the account closes six months after you open it or when the credits run out, whichever comes first. AWS also emails you when 50%, 25% and 10% of your credits remain.
- Free Tier: your usage measured against each service's free limits, so you can see which service is eating into them.
Gotcha: credits hide spending. A month-to-date bill of $0.00 can still mean you used $14 of credits. Look at usage, not just the amount owed. In the advanced budget workflow you can choose which charge types count toward the budget.
Walkthrough 3: estimating the course app
The AWS Pricing Calculator comes in two versions. The public site at calculator.aws needs no account and gives you a shareable link. The in-console version saves estimates to your account and can import your past usage. Use either.
Over this course the app grows into a container service, a small PostgreSQL database, S3 storage, a secret or two, logs and a load balancer. Add each piece to an estimate, using one Region throughout. A worked example with N. Virginia (us-east-1) hourly rates shows where the money goes:
Item Rate x 730 h/month
--------------------------- ------------------- -------------
Application Load Balancer $0.0225/h + LCUs ~ $16.43
NAT gateway $0.045/h + $0.045/GB ~ $32.85
Public IPv4 address (each) $0.005/h ~ $3.65
Secrets Manager secret $0.40/month ~ $0.40
Database instance pick size in calc (read it off)
Three lessons stand out:
- Hourly items dominate. A NAT gateway alone costs more than the whole $20 budget, before it has processed a single byte. Later lessons design around it.
- Requests and storage are cheap at this scale. For a learning app, S3, secrets and logs are usually a few cents.
- The database and anything that is "always on" are the parts to watch. You'll delete them at the end of every lesson.
Trade-off: the calculator only estimates what you tell it about. It can't warn you about a resource you forgot to include, which is exactly why you also set up the budget.
Check it works
Open Budgets. You should see course-monthly with three alerts, and the confirmation email AWS sends when you add an email subscriber. Nothing here costs money, so there's nothing to remove. Leave the budget running for the whole course.
Key takeaways
- Set up a monthly cost budget before you build anything. Monitoring and alerts are free.
- Use alerts at actual 85%, actual 100% and forecast 100%. The forecast alert gives the earliest warning.
- Budgets warn you. They don't stop spending, and they can run hours behind.
- Check Home, Credits and Free Tier in the Billing console. Remember that credits can hide real usage.
- In your estimate, hourly resources (load balancer, NAT gateway, database, public IPv4) cost the most, not requests.