What I'm Locking Down Before My First AWS Deployment
Before deploying anything on AWS, I'm securing the account itself: root user, day-to-day identity, and cost guardrails. Here's my checklist, why each item is on it, and the mistakes it prevents.
In my last article, I wrote that budgets and alerts are the first thing I'd set up in any new AWS account. Now I'm about to deploy my first real project on AWS, so it's time to practice what I wrote. This is my checklist before a single resource goes live, and why each item is on it.
At home I'm root on everything, and that's fine: the worst case is rebuilding a VM. In AWS, the worst case is a compromised account or a bill I can't explain. My account is on the paid plan, so nothing stops a forgotten resource from charging me. The guardrails have to come first.
1. Secure the root user, then stop using it
The root user can do anything in the account, and IAM policies can't restrict it. That makes it the most valuable credential I have and the one I should touch the least.
- Enable MFA on root.
- Make sure root has no access keys. There's no good reason for root to make API calls.
- Use root only for the few tasks that actually require it, like account-level settings.
2. Create a day-to-day identity with short-lived credentials
Instead of working as root or creating an IAM user with permanent access keys, I'm going to use IAM Identity Center. I sign in through a portal, and the CLI gets temporary credentials with
aws sso login. If those credentials leak, they expire.Last time I wrote that a single overly broad policy can expose an entire account, so I'll be honest about the tension here: while I'm still building, I'll start with broad permissions, because I don't yet know exactly what my project needs. What makes that acceptable for now is that they're tied to short-lived SSO sessions, not permanent keys. Narrowing them to least privilege is part of the plan, not an afterthought.
Later, my CI pipeline will follow the same principle: GitHub Actions will authenticate to AWS with OIDC instead of stored keys.
3. Set up cost guardrails
- A monthly AWS Budget with email alerts at 50% and 80% of actual spend and at 100% of forecasted spend.
- Cost Anomaly Detection, to catch spending patterns I wouldn't think to set a threshold for.
One thing I had to learn: a budget alert doesn't stop anything. It only tells me something is wrong. Acting on it is still my job. That forgotten NAT Gateway from my last article is exactly what these alerts are for.
The mistakes these guardrails prevent
| Common mistake | Guardrail |
|---|---|
| Root credentials compromised | MFA on root, root not used day to day |
| Access key leaked in a repo | No long-lived keys; temporary SSO credentials |
| Overly broad permissions | Least privilege, narrowed as the project grows |
| A forgotten resource running for weeks | Budget alerts and anomaly detection |
None of these require clever attackers. The leaked access key comes straight from my last article. The other two I mentioned, a public bucket and a security group open to the world, belong to the network and storage layers, so they'll come up once I start building there.
What I'm leaving for later
AWS keeps 90 days of management events in CloudTrail's event history by default, which is enough for now. A dedicated CloudTrail trail, GuardDuty, and CloudWatch alarms will come once there's something running to monitor.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article