AWS penetration testing assesses the security you are responsible for under the shared responsibility model — your IAM, S3, EC2, Lambda and account configuration — not the AWS platform itself. AWS lets customers test a defined list of permitted services without prior approval; only C2, simulated phishing, malware and covert red-team activity need the AWS simulated-events request, and DDoS simulation runs through AWS's separate DDoS Test Partner program. The highest-impact findings are consistently IAM privilege escalation (dangerous permission combinations that reach account takeover) and IMDS credential theft (older IMDSv1 leaking EC2 role credentials via SSRF). We test manually, map findings to CIS AWS Foundations Benchmark v5.0, and include a retest.
// 01 What is AWS penetration testing?
AWS penetration testing is a manual security assessment of your Amazon Web Services environment — your identities, storage, compute and configuration — to find the ways an attacker could escalate from a small foothold to control of your account or your data. It is distinct from a general application test because the AWS control plane, its identity model and its managed services introduce attack paths that only exist in the cloud: a single over-permissive IAM policy or an exposed metadata service can matter more than any application bug.
Crucially, an AWS test is scoped by the shared responsibility model. You are responsible for security in the cloud — how you configure IAM, S3, EC2 and the rest — and AWS is responsible for security of the cloud, the underlying infrastructure. A penetration test assesses your half. Testing the AWS platform itself, or other tenants, is both out of scope and prohibited.
// 02 AWS's penetration testing policy: what's allowed
A common worry is whether you need AWS's permission. For the vast majority of testing, you do not. AWS explicitly welcomes customers to assess their own infrastructure without prior approval for a defined list of permitted services — EC2, RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda, Lightsail, Elastic Beanstalk, ECS, Fargate and others. A handful of higher-risk activities are the exception and require authorisation first.
| Activity | AWS requirement |
|---|---|
| Testing permitted services (EC2, RDS, Lambda, API Gateway…) | No prior approval |
| Command-and-control (C2) hosting | Simulated Events form |
| Simulated phishing, malware testing | Simulated Events form |
| Covert red / blue / purple team | Simulated Events form |
| DDoS simulation | AWS DDoS Test Partner program |
| Testing other tenants or AWS infrastructure | Prohibited |
We handle these policy requirements as part of scoping, so your engagement stays fully within AWS's rules of engagement without you having to navigate the forms.
// 03 What we test in an AWS environment
We focus on the AWS-specific attack surface that generic tools miss — the identity and configuration layer where cloud breaches actually happen.
Identity & privilege escalation
Dangerous permission combinations (PassRole, policy-version, AssumeRole chaining), over-privileged and unused roles, and paths from low-privilege access to account control.
Storage exposure
Public or misconfigured buckets, weak bucket policies and ACLs, unauthenticated listing, and data exfiltration paths.
Compute & metadata
IMDS credential theft via SSRF (IMDSv1 vs IMDSv2), exposed management, and instance-role abuse.
Trust & serverless
Over-broad AssumeRole trust, confused-deputy gaps (missing ExternalId), Lambda misconfiguration and secrets in code or user-data.
// 04 Common AWS findings
IAM privilege escalation to account takeover
A low-privileged identity with a dangerous permission (such as PassRole plus a service launch, or CreatePolicyVersion) escalates to full administrative control.
IMDSv1 credential theft via SSRF
An application SSRF reaches the instance metadata service on an EC2 host still running IMDSv1, stealing the instance role's credentials. Enforcing IMDSv2 closes it.
Publicly exposed S3 bucket
Sensitive data readable, or worse writable, by anyone — a recurring source of large cloud breaches.
Over-broad cross-account trust
An AssumeRole trust policy that lets an external account assume a privileged role, often without an ExternalId condition.
// 05 Standards we test against
We map every AWS engagement to recognised baselines so findings translate into concrete configuration fixes and compliance evidence.
CIS AWS Foundations Benchmark v5.0: the config baseline — enforce IMDSv2, no root access keys, least-privilege IAM, CloudTrail enabled, S3 not public, and more.
AWS Well-Architected Security Pillar: AWS's own security design principles.
MITRE ATT&CK Cloud (IaaS) matrix: we map findings to cloud attacker techniques so your defenders can act on them.
Compliance: findings mapped to PCI DSS, SOC 2, ISO 27001 and the GCC frameworks where relevant — see our requirements finder.
// 06 Frequently asked questions
Do I need AWS's approval?
Not for most testing. AWS permits testing of a defined list of services without prior approval. Only C2, simulated phishing, malware and covert red-team activity need the simulated-events form; DDoS simulation goes through AWS's DDoS Test Partner program.
What does it cover?
IAM privilege escalation, S3 misconfiguration, IMDS credential theft, over-permissive roles, Lambda, exposed management, secrets and cross-account trust — your configuration and workloads, not AWS infrastructure.
Most common serious finding?
IAM privilege escalation and IMDSv1 credential theft. Enforcing IMDSv2 and least-privilege IAM are the highest-impact fixes.
Can you test AWS's infrastructure?
No — that's AWS's responsibility under the shared responsibility model, and testing the platform or other tenants is prohibited.
// 07 References
- AWS Customer Support Policy for Penetration Testing (permitted services, simulated events); AWS DDoS Simulation Testing policy.
- CIS Amazon Web Services Foundations Benchmark v5.0; AWS Well-Architected Framework (Security Pillar); MITRE ATT&CK Cloud matrix.