AWS Security Cards: A Free Reference for 75 AWS Services
A free, open-source set of 75 AWS service security cards. Each one covers attack vectors, misconfigurations, enumeration and defense commands, and good-vs-bad policies, in Markdown, HTML, and PDF.
AWS Security Cards: A Free Reference for 75 AWS Services
When you are reviewing an AWS service for the first time, or trying to harden one you already run, the same questions come up every time. How does an attacker actually abuse this service? What are the misconfigurations that lead to a breach? Which CLI commands let me check my own exposure? What does a good resource policy look like next to a bad one?
The answers exist, but they are scattered across documentation, breach write-ups, conference talks, and blog posts. You end up rebuilding the same mental checklist for every service.
AWS Security Cards is an attempt to put that checklist in one place. It is a free, open-source set of 75 security reference cards, one per AWS service, each following the same structure so you always know where to look.
What it is
Each card covers a single AWS service and is built from the same eleven sections:
- Service Overview, how the service works, with notes that matter to an attacker
- Risk Assessment, a numeric score with a short justification
- Attack Vectors, the known techniques and exploitation paths
- Common Misconfigurations, the mistakes that lead to breaches
- Enumeration Commands, AWS CLI commands for assessment
- Privilege Escalation, how access gets escalated
- Persistence Techniques, how access is maintained
- Detection Indicators, what to watch for in logs and monitoring
- Exploitation Commands, practical commands for authorized testing
- Policy Examples, good versus bad policies side by side
- Defense Recommendations, hardening steps with CLI examples
The point of the fixed structure is speed. Once you have read two or three cards, you know exactly where the enumeration commands are, where the defenses are, and where the policy comparisons are. You stop hunting and start reading.
What it covers
The set spans 75 services across identity, compute, storage, databases, networking, containers, data and analytics, monitoring, and the AWS security services themselves. Every card carries a risk score so you can triage where to spend attention first.
The highest-scored services are the ones you would expect to sit at the top of a blast radius:
- AWS IAM, STS, Organizations, Secrets Manager, IAM Identity Center, and Control Tower all score 9.5
- Redshift scores 9.2
- EC2, S3, EKS, RDS, CodeBuild and CodePipeline, Directory Service, Glue, Route 53, Backup, and CloudFormation score 9.0
The scores are a starting point for prioritization, not a verdict. A 6.0 service wired into a 9.5 identity service is still a real problem. The cards give you the per-service view; you bring the context of how they connect in your environment.
IAM and S3, two of the most attacked services in any account, each get the same full treatment:
A concrete example: EC2
To make this less abstract, here is what the EC2 card actually contains.
The overview leads with the single most important EC2 attack vector: credential theft from the Instance Metadata Service via SSRF. This is the path behind the Capital One breach. IMDSv1 answers a simple GET request to
169.254.169.254 and hands back IAM role credentials. IMDSv2 requires a session token first, which blocks most SSRF attempts.The enumeration section gives you the commands to check your own posture, for example listing instances and security groups, and finding snapshots you may have made public:
1
2
aws ec2 describe-snapshots \
--owner-ids self --query 'Snapshots[?Public]'The policy section puts a dangerous security group next to a safe one. Open SSH to the world:
1
2
3
4
5
6
7
8
{
"IpPermissions": [{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"IpRanges": [{"CidrIp": "0.0.0.0/0"}]
}]
}Versus SSH reachable only from a bastion security group:
1
2
3
4
5
6
7
8
{
"IpPermissions": [{
"IpProtocol": "tcp",
"FromPort": 22,
"ToPort": 22,
"UserIdGroupPairs": [{ "GroupId": "sg-bastion" }]
}]
}And the defense section ends with the commands that close the gaps, such as enforcing IMDSv2:
1
2
aws ec2 modify-instance-metadata-options \
--instance-id i-xxx --http-tokens requiredEvery one of the 75 cards follows this same arc, from how the service is attacked to exactly how you lock it down.
Three formats
Each card ships in three formats so it fits how you actually work:
- Markdown, readable directly on GitHub, easy to search and to contribute to
- HTML, standalone dark-themed pages you open in any browser
- PDF, print-ready, with embedded images and AWS icons, easy to share with a team
The Markdown is the source of truth and the easiest place to suggest a fix. The PDFs are handy for onboarding, internal wikis, or a printed reference next to your desk.
How I use it
A few patterns where this has been genuinely useful:
- Service reviews. Before adopting a new service, read its card end to end. You walk in already knowing the common misconfigurations and the detection events to wire up.
- Hardening passes. Run the enumeration commands from a card against an account to see where you stand, then apply the defense commands.
- Learning. The good-versus-bad policy comparisons teach the shape of a correct policy faster than prose does.
- Team onboarding. Hand a new engineer the PDF for a service they are about to own.
A word on intent
These cards include offensive content: attack vectors, enumeration, privilege escalation, persistence, and exploitation commands. That is deliberate. You cannot defend a service you do not understand how to attack, and detection engineering depends on knowing what the attack looks like in the logs.
The project is explicit about this. The material is for authorized security testing and education only: legitimate assessments, CTF competitions, and defensive research. Get authorization before you test anything. The exploitation commands are there so you can validate your own defenses and recognize the corresponding CloudTrail events, not so you can point them at infrastructure you do not own.
It is open source, and it is a work in progress
AWS Security Cards is open source and built in the open. Seventy-five services is a strong start, but AWS is much larger than that, and every card can be sharpened as services change. Contributions are welcome, whether that is a correction, a new attack vector, a better defense example, or a card for a service that is not covered yet.
If it saves you time, the most useful things you can do are simple: use it, star the repository so others can find it, and open an issue or a pull request when you spot something to improve.
Repository: github.com/TocConsulting/aws-security-cards
The techniques described are for authorized security testing and educational purposes only. Always obtain proper authorization before testing.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article