
AWS runs on a shared responsibility model, and most breaches happen on the customer's side of that line. This is the checklist we run when we audit AWS environments: the misconfigurations, the IAM traps, the S3 mistakes people keep making, so you can find them before an attacker does.


What's inside?
Two checklists in one, across 15 device and infrastructure types:
The audit checklist - governance, network management, logging, monitoring, and encryption controls, with dedicated hardening blocks for EC2/VPC/EBS and S3.
The pentest checklist - 40+ attack tests including IAM privilege escalation, credential theft from metadata and KMS, CloudTrail-bypassing enumeration, subdomain takeover, MITM on ELB, and log tampering across regions.
The AWS security service map - every native service worth knowing: GuardDuty, Macie, Security Hub, Inspector, Shield, WAF, KMS, CloudHSM, Secrets Manager, and Detective, grouped by what they actually do.
What you’ll learn
By the end, you'll be able to:
Audit IAM, EC2, S3, VPC, and CloudTrail without missing the misconfigurations that show up in every breach post-mortem.
Spot the specific attack paths pentesters use, like credential theft in metadata, IAM enumeration, KMS abuse, and Route53 hijacking.
Pick the right AWS-native security service for each control gap, instead of buying three third-party tools that do the same thing.
Lock down S3 the way it should have shipped: no public buckets by accident, SSE on, access logging watched.
Walk into your next AWS audit knowing your IAM policies, CloudTrail coverage, and encryption posture will hold up.
Over a million AWS customers, one shared responsibility model, and the same handful of misconfigurations behind almost every breach. Most of them are on this list.
Who’s this for?
Read this if you're a…
Cloud engineer or DevOps lead running production workloads on AWS and want a concrete "what to check" list, not a shared-responsibility diagram.
CTO or Head of Infrastructure who inherited an AWS estate and needs a map of where the risk is hiding.
Security engineer scoping an AWS pentest and wants to know what should actually be in scope.
Founder about to sign a SOC 2 or ISO 27001 engagement and wondering what your AWS setup is about to fail on.