Most AWS accounts don’t get breached because of some exotic zero-day. They get breached - or hit with a surprise bill - because of boring, fixable misconfigurations that nobody owned: a public S3 bucket, a long-lived access key, a security group open to 0.0.0.0/0, CloudTrail that was never turned on.
This is the checklist I actually run when I audit a client’s AWS account. Work through it honestly. Every box you can’t tick is a risk, a surprise bill, or a 2 a.m. incident waiting to happen. Most teams can get through it in an afternoon.
Want the printable version? Grab the free 30-point AWS Security Checklist PDF - no call required.
1. Identity & access (IAM)
Identity is the new perimeter. This is where most real incidents start.
- Root account has MFA enabled and is not used for day-to-day work.
- No long-lived IAM access keys older than 90 days. Rotate or kill them.
- Humans log in through SSO / IAM Identity Center, not shared IAM users.
- No IAM policy grants
Action: "*"onResource: "*"to a human or app that doesn’t truly need it. - Unused IAM users, roles, and keys are removed (anything idle 90+ days).
- Cross-account and third-party roles use an
ExternalIdand least-privilege scoping.
If you do nothing else this week, fix root MFA and any access key older than 90 days.
2. Network exposure
The fastest way to get popped is to leave a door open to the entire internet.
- No security group opens SSH (22) or RDP (3389) to
0.0.0.0/0. - Databases (RDS, ElastiCache) are not publicly accessible.
- S3 Block Public Access is ON at the account level.
- No S3 bucket is unintentionally public - check both bucket policy and object ACLs.
- Default VPC security groups deny all inbound traffic.
3. Data protection
- EBS volumes and RDS instances are encrypted at rest with KMS.
- S3 default encryption is enforced on every bucket.
- Versioning + lifecycle policies protect buckets holding critical data.
- Secrets live in Secrets Manager or SSM Parameter Store - never in code, env files, or AMIs.
- RDS automated backups are on, and you’ve actually tested a restore in the last 90 days. A backup you’ve never restored is a hope, not a backup.
4. Logging, detection & monitoring
You can’t respond to what you can’t see.
- CloudTrail is enabled in all regions, logging to a locked-down S3 bucket.
- GuardDuty is enabled in every active region.
- AWS Config is recording resource changes.
- Billing and anomaly alerts are wired to a human (email or Slack), not just sitting in a dashboard nobody opens.
- CloudWatch alarms fire on root login, IAM changes, and security-group edits.
5. Resilience & incident readiness
- A written, tested incident runbook exists - who does what, in what order.
- Critical workloads span at least two Availability Zones.
- Infrastructure is defined as code (Terraform / CDK), not click-ops you can’t reproduce.
- Deletion protection is on for production databases and critical resources.
- An off-account or off-region backup copy exists - the kind ransomware can’t reach.
6. Cost as a security signal
Runaway cost is often the first visible symptom of something wrong - crypto-mining from a leaked key, or just drift nobody is watching.
- No idle or oversized EC2/RDS, and no unattached EBS quietly burning money.
- Savings Plans / Reserved capacity reviewed for steady-state workloads.
- A tagging strategy lets you attribute cost to a team or product.
- A monthly cost + security review actually happens - not just exists on paper.
What to do with your results
Tally the boxes you couldn’t check. That list, roughly in the order above, is your prioritized remediation backlog. IAM and public exposure issues come first - they’re the ones attackers find with automated scanners within hours.
If you’d rather not run this alone - or you want the issues actually fixed, not just found - that’s exactly what my AWS Complete Security Audit does: I walk every item above on your real account, deliver a prioritized findings report, and back it with a simple guarantee. If I don’t find at least three critical issues worth more than my fee, you pay nothing.