AWS Pentest Scope Template
What to ask in AWS pentest scoping — accounts, regions, services in scope, AWS-policy-derived rules, IMDSv2 baseline, logging baseline, internal authorisation memo. Aligned to AWS published policy. Free, email-only.
Preview of the document.
- →Account inventory, region inventory, service inventory mapped to the AWS pentest policy
- →Customer-permitted vs. notification-required vs. prohibited service categorisation
- →Internal authorisation memo and SOC notification templates — the artefacts AWS no longer requires but your security committee will
- →IMDSv2 baseline questionnaire — the single highest-leverage AWS configuration item from a pentest perspective
- →Logging baseline — what to verify before fieldwork to make detection findings honest
Section 1. Account inventory
Master / Management account ID, all member account IDs, total account count, AWS Organizations OU structure, accounts explicitly out-of-scope, cross-account roles in use.
Section 3. Services in scope
Customer-permitted services (EC2, ALB, RDS, Lambda, API Gateway, CloudFront, ECS / EKS / Fargate). Notification-required (DDoS sim, DNS zone walking, high-volume SES / Cognito). Prohibited (port flooding, AWS-owned hardware testing, tenant-isolation breach attempts).
Section 5. AWS-policy-derived rules
You must own the resources you test. No DoS without the simulation programme. No DNS zone walking without notification. No testing of AWS-managed infrastructure layers. Bandwidth ceilings apply. Stop on abuse-desk contact. Document the test plan.
Section 6. Internal authorisation
One-page memo signed by exec sponsor + engineering owner of each in-scope account. SOC notification with test windows and tester source IPs. Optional account-team note for significant-scope engagements.
Section 7. IMDSv2 baseline
Total EC2 instance count, instances with IMDSv2 enforced, instances with IMDSv1 still allowed, AMI default, ECS / Lambda metadata exposure. If IMDSv1 is allowed anywhere, expect SSRF -> IMDS -> instance role -> S3 to surface as a critical finding.
Who this is written for.
Platform engineers running AWS-only or AWS-primary environments. CTOs who do not want to forget the internal authorisation step. CISOs scoping cloud-native pentests.
Real public references.
We cite the canonical source so you can verify anything in the document yourself. No fabricated stats, no "industry research says" without a link.
- → AWS Customer Support Penetration Testing Policy · https://www.aws.amazon.com/security/penetration-testing/
- → AICPA (SOC 2 cloud alignment) · https://www.aicpa-cima.com/
- → MeitY (Indian-data-residency overlap) · https://www.meity.gov.in/
We send the document. That is it.
The AWS Pentest Scope Template lands in your inbox the same business day. The request is read by the operator who owns the artefact — not by a marketing system.
No drip after that. No "day-3 nudge", no auto-enrolment in a newsletter, no calendar invite for a discovery call you did not ask for. If you want a 30-minute scoping call, the contact form routes the same way and the call is free.
Want a 30-minute scoping call instead?
The AWS Pentest Scope Template is useful as a working document. If you would rather walk through your specific situation with an operator, the call is free and you get a written summary either way.