Guides

AWS Security Best Practices Checklist

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

AWS security best practices for beginners are a defensive checklist: protect the root user, enforce MFA and least privilege on IAM, turn on CloudTrail and a detector such as GuardDuty, lock down storage and security groups, and watch spend. This guide is a practical checklist — not an exploit walkthrough.

Identity → Logging → Detection → Network/Data hygiene → Money alarms
Root daily use = career-limiting shortcut
No CloudTrail = flying blind

What do I need before this guide?

• An AWS account you own (free tier practice is fine).
• Prior reads: Create IAM user with MFA, Cloud IAM least privilege, What is cloud security?.
• Optional: Security group vs NACL.

What does the checklist look like?

Educational warning: every step below is for your account or a named lab. Do not apply deny-all experiments on a shared company account without approval — you can lock teams out.

Real incident themes (public, high level)

Capital One (2019): public analyses emphasised cloud identity, metadata and misconfiguration themes — scope roles tightly and monitor unusual API use.

Leaked access keys: countless public incidents start with an AKIA… key committed to GitHub. Rotate immediately, prefer roles, alert on CreateAccessKey.

Crypto-mining surprise bills: stolen keys or open instances burn money overnight — budgets are a security control, not only finance.

Care-take bullets:

1. MFA on root and every human console user.
2. No long-lived keys unless unavoidable — then rotate and scope.
3. CloudTrail always on; alert if someone stops it.
4. Block public S3 unless a written exception exists.
5. Billing alarms in the same week you create the account.

Red Team vs Blue Team (awareness only)

Stages only — no exploit steps.

How do I apply the AWS checklist step by step?

Step 1 — Root and break-glass

1. Sign in as root only to set MFA and account contacts.
2. Store MFA backup codes offline; never share root password in chat.
3. Do not create root access keys.
4. Create a monitored break-glass process for emergencies.

Step 2 — Human identity

1. Prefer IAM Identity Center (SSO) if you have multiple accounts.
2. Or create an IAM user in an Admins group with MFA — use that daily.
3. Developers get deploy permission sets, not AdministratorAccess forever.
4. Remove users the same week they leave the project.

Step 3 — Workload identity

1. Attach roles to EC2 / ECS / Lambda instead of embedding keys.
2. Scope Action and Resource to what the app needs (least privilege guide).
3. Use OIDC from CI to assume roles when you can.
4. Delete unused access keys; age them out on a schedule.

Step 4 — Visibility

1. Enable CloudTrail in all regions; send to a dedicated log bucket.
2. Turn on log file validation.
3. Enable GuardDuty in the account (and members if you use Organizations).
4. Later: AWS Config rules for public buckets / open SG; Security Hub summary.

Step 5 — Data and network

1. S3: Block Public Access account setting ON.
2. Default encryption on buckets; careful with ACLs.
3. Security groups: web 80/443 only where needed; SSH from My IP or Session Manager.
4. RDS / data stores: private subnets, no public accessibility flag for learning apps that do not need it.

Step 6 — Money and hygiene

1. Create a zero-spend or monthly budget with email alerts.
2. Turn on free-tier usage alerts.
3. Tag resources with owner; delete forgotten labs weekly.
4. Snapshot important volumes; test one restore.

Quick vocabulary

1. CloudTrail — AWS API and console activity history for investigations.
2. GuardDuty — managed threat detection using AWS logs and intel.
3. Block Public Access — account/bucket controls that stop accidental public S3.
4. Security Hub — aggregated security findings (optional next step after GuardDuty/Config).
5. Break-glass — rare, monitored emergency admin path.

Priority order if you only have one evening

1. Root MFA + stop daily root.
2. IAM user/SSO with MFA.
3. CloudTrail on.
4. S3 Block Public Access.
5. Budget alarm.
6. GuardDuty on.
7. Tighten one overly open security group.

Account and Organizations notes

1. If you later use AWS Organizations, prefer an org-level CloudTrail.
2. Separate log archive / security tooling accounts when the team grows.
3. SCPs can block disabling security services — advanced, but know the idea exists.
4. For one personal account, the single-account checklist above is enough to start.
5. Never share root or admin passwords into WhatsApp for “quick help”.

Care-take — weekly AWS hygiene

1. Root unused; MFA still enrolled.
2. No unexpected IAM users or keys.
3. GuardDuty findings triage queue not ignored for weeks.
4. No new public buckets without review.
5. Budget email still arrives on a test threshold.
6. CloudTrail still delivering (check the trail status).

How do I fix common AWS security mistakes?

Ghabru naka 😅 — these are the usual ones: