Secure a Brand-New AWS Account in 30 Minutes (Almost Free)
An 8-step checklist from a cybersecurity student to lock down a new AWS account before you build anything: MFA, IAM Identity Center, budgets, CloudTrail, S3 Block Public Access, Access Analyzer, GuardDuty and Security Hub, with the cost traps to avoid.
Series: Security Student Series (1 article)
- 1Secure a Brand-New AWS Account in 30 Minutes (Almost Free) This article
A leaked AWS access key on GitHub can be found by automated scanners within minutes. Not days. Minutes.
That is why the first 30 minutes of a new AWS account matter more than the first 30 days. Most people spin up resources first and think about security later. This checklist flips that order.
I'm a cybersecurity student, and this is the exact order I follow now when I open a fresh account for labs. Almost everything here is free or has a free trial. A few services can generate costs if you forget them, and I flag those clearly. Pricing and trials change, so always check the AWS pricing page for each service.
Part of my "Security Student Series". Start with the 5 questions I ask before fixing any Security Hub finding .
The 8 steps
1. Lock down the root user with MFA (5 min)
The root user can do everything, including closing the account. Enable MFA right away (a passkey or authenticator app), use a long unique password, and never create access keys for root.
Why it matters: if root is compromised, nothing else you configure matters.
2. Stop using root: create an admin with IAM Identity Center (7 min)
Enable IAM Identity Center, create your own user, assign it administrator permissions on your account, and turn on MFA for it. From now on, sign in with this user and keep root locked away for the rare tasks that truly need it.
Why it matters: doing daily work as root is like browsing the web as a system administrator.
3. Set a budget alert (3 min)
In AWS Budgets, create a small monthly budget (or a zero-spend budget) and send alerts to an email you read. Also turn on Cost Anomaly Detection.
Why it matters: a leaked key or a forgotten resource often shows up as a surprise bill before anything else.
4. Turn on CloudTrail (3 min)
Event history is on by default, but it only covers the last 90 days. Create a multi-Region trail that delivers logs to an S3 bucket so you keep a long-term record of who did what. The first copy of management events is free; you pay only for the S3 storage.
Why it matters: without logs, you cannot investigate anything.
5. Enable S3 Block Public Access for the whole account (2 min)
New buckets already block public access by default, but turning it on at the account level makes sure nobody (including future you) disables it by mistake on a single bucket.
Why it matters: it's the cheapest protection against the classic "public bucket" leak.
6. Enable IAM Access Analyzer (2 min)
Create an analyzer for external access. It flags resources (buckets, roles, KMS keys) shared outside your account. It is regional, so create one in each Region you use. The unused access analyzer is a separate, paid feature, so you can skip it for now.
Why it matters: it catches accidental sharing you did not know you created.
7. Start the GuardDuty and Security Hub trials (5 min)
GuardDuty watches for suspicious activity such as unusual API calls, crypto mining and compromised credentials. Security Hub (now split into Security Hub and Security Hub CSPM, depending on what you enable) aggregates findings and checks your account against best practices. Both offer free trials, so you can see what they find in your own account.
Cost trap: these are free only during the trial (30 days). Security Hub's posture checks rely on AWS Config, which is billed per item recorded. Set a calendar reminder for day 25 to review the Billing page and disable what you do not need.
Why it matters: this is your detection layer. And remember: triage findings, do not try to fix everything at once.
8. Add security contacts (3 min)
In Account settings, fill in the alternate contacts (billing, operations, security) with an email you actually read.
Why it matters: AWS uses these contacts to warn you about abuse or compromise.
Quick reference
| # | Step | Protects against | Cost note | Time |
|---|---|---|---|---|
| 1 | Root MFA | Account takeover | Free | 5 min |
| 2 | Identity Center admin | Overuse of root | Free | 7 min |
| 3 | Budgets + anomaly detection | Surprise bills | Free tier | 3 min |
| 4 | CloudTrail | No audit trail | S3 storage only | 3 min |
| 5 | S3 Block Public Access | Data exposure | Free | 2 min |
| 6 | Access Analyzer (external) | Accidental sharing | Free | 2 min |
| 7 | GuardDuty + Security Hub | Undetected threats | Trial, then paid | 5 min |
| 8 | Security contacts | Missed AWS warnings | Free | 3 min |
Common mistakes to avoid
- Creating access keys for root "just to test something"
- Putting keys in code or in a GitHub repo
- Skipping MFA because "it's just a lab account"
- Enabling services and never looking at the findings
- Forgetting to disable trials you no longer need
Final thoughts
None of this is advanced. It's a habit. If you do these 8 steps first, every project you build afterward starts on solid ground, and you will know where to look when something goes wrong.
Which of these did you skip when you created your first AWS account? Tell me in the comments. If I missed something important, I'll add it to the list.
Series: Security Student Series (1 article)
- 1Secure a Brand-New AWS Account in 30 Minutes (Almost Free) This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article