AWS pentest scope: distinguish customer resources from provider systems

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

AWS penetration testing scope should identify the customer-owned resources, permitted activities, and provider rules that apply to the engagement. Ownership of an application does not grant permission to assess AWS infrastructure or unrelated customer environments.

AWS publishes a service-specific testing policy, including activities requiring separate approval. AWS penetration testing policy provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Build an ownership inventory

List accounts, regions, deployed applications, storage resources, APIs, and external dependencies. Assign an owner and an authorizing contact to each. Include resources reached through a shared identity account or a third-party integration. Mark the provider-managed service layer separately from customer configuration and application code. Review the current AWS policy immediately before the engagement because permitted services and activity conditions can change. A scope statement that says only AWS is too broad to control either human-led or agentic assessment.

Walk a synthetic application path

Choose a staging application and a harmless object stored in the same test account. Trace an ordinary user action through the application, execution role, and storage access. The proposed test should evaluate one customer-controlled permission decision, without attempting provider control-plane compromise or interacting with another customer. Keep traffic within an approved request budget. If the intended activity involves a separately controlled category, obtain the required approval first rather than infer permission from the presence of an AWS billing relationship.

Keep authorization evidence usable

The assessment record should name account and resource references, approved activities, testing identities, source locations, dates, contacts, and stop conditions. Protect full account details and credentials in restricted materials. Preserve evidence of which resource actually handled a test, because domain names can route through external services. If an unexpected provider-owned boundary appears, pause that path and follow the relevant disclosure process. An abuse notification should be handled by the designated owner, who can connect the observed traffic to the written scope.

Explain coverage without cloud-wide claims

Report which customer boundaries were examined and which were excluded. A finding in an application role does not establish that AWS itself was compromised. A clean sample does not establish the security of every account or managed service. Retest affected customer configurations and retain an allowed control case. Businesses comparing proposals should ask for a resource-and-activity scope, not just a count of cloud assets. For recurring testing, reconcile inventory changes and provider policy before each authorized run.

A useful assessment artifact

Use a signed scope manifest that separates owned accounts, individual resources, approved action categories, and excluded provider layers. The manifest should be understandable to an operations responder who encounters test traffic without having attended the engagement kickoff.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.