# AWS Penetration Testing: Scope, Steps, and Reporting

_Learn how AWS penetration testing validates exploitable weaknesses in workloads, IAM, and configurations, then turns findings into fixes engineers can ship. _

## What is AWS pen testing?

AWS penetration testing is an authorized security assessment that identifies and validates exploitable weaknesses in applications, workloads, and configurations hosted on Amazon Web Services. Testers examine how an attacker could gain access, expand permissions, or reach sensitive resources within an agreed scope.

The result should explain which weaknesses are exploitable, what an attacker could accomplish, and how to fix the underlying problems. The distinction between [vulnerability assessments and penetration testing](https://www.wiz.io/academy/vulnerability-management/vulnerability-assessments-vs-penetration-testing) lies in the evidence they provide: A configuration scan identifies potential issues, while a penetration test investigates whether those issues create an exploitable attack path.

An AWS assessment might begin with an exposed application and follow its connections to a workload identity or database. This makes cloud architecture part of the investigation: The significance of an application vulnerability often depends on the permissions and resources behind it.

## Why is AWS penetration testing important?

AWS secures the infrastructure that operates its cloud services, while customers retain responsibilities for their applications, data, access controls, and service configurations. Those responsibilities vary by service. Penetration testing helps evaluate the controls your organization manages under this [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).

The practical benefits include:

- **Validating access boundaries:** Determine whether a user, application, or workload can reach resources beyond its intended permissions.
- **Understanding combined impact:** Investigate whether an application flaw becomes more serious when paired with an overprivileged role or exposed data.
- **Prioritizing remediation:** Give engineering teams evidence of reachable resources and business impact, alongside the changes needed to break the attack path.
- **Checking defensive visibility:** Confirm whether the assessment produces the logs and alerts your security team expects.

These results help teams decide what to fix first. An exposed test service and an exposed production service may share a vulnerability, but the permissions, data, and dependencies behind them can make their consequences very different.

## What can be pen tested in AWS?

Focus the assessment on your workloads and configurations. The examples below distinguish what a tester might examine from the service and activity restrictions that govern the engagement.



| Service or resource | What to assess | Permission requirements and limits |
| --- | --- | --- |
| EC2 workloads | Exposed services, host weaknesses, and application behavior | Permitted-service example; target customer-controlled resources. |
| RDS and Aurora workloads | Database access controls and reachable endpoints | Permitted-service examples; exclude underlying AWS infrastructure. |
| Lambda, API Gateway, and ECS workloads | Application authorization, workload permissions, and deployment configuration | Permitted-service examples; API Gateway cannot host outbound penetration testing. |
| Services outside the permitted list | Proposed activities involving other services, including S3 or IAM | Coordinate the proposed testing with AWS Support or your account representative. |

Customer authorization remains necessary. Command-and-control (C2) testing, covert adversarial simulations, simulated phishing, and malware testing require advance AWS coordination. Restrictions include DoS/DDoS attacks, flooding, Route 53 DNS abuse, S3 bucket takeover, and subdomain takeover. Bedrock AgentCore also can’t host outbound penetration testing. Check the complete[ AWS penetration testing policy](https://aws.amazon.com/security/penetration-testing/) when defining your scope.

DDoS simulations follow a separate policy with requirements for testing providers, eligible resources, and traffic limits. They should be planned as a distinct activity under the[ AWS DDoS simulation testing policy](https://aws.amazon.com/security/ddos-simulation-testing/).

## Types of AWS pen testing

The testing approach determines how much information and access the tester receives at the start.

- **Black-box testing:** The tester receives little or no internal information. This approach examines what an outside attacker can discover and reach through exposed applications and services.
- **Gray-box testing:** The tester receives limited information or access, such as an application account or a restricted AWS identity. This helps evaluate authorization boundaries and what could happen after an initial compromise.
- **White-box testing:** The tester receives extensive visibility into architecture, source code, configurations, and relevant identities. This supports a detailed investigation of security assumptions and permission relationships.

These testing approaches can be combined within one engagement. For example, a team might begin with external discovery, then provide limited credentials to investigate access boundaries.

Choose the approach around a specific question: What can an external attacker reach? What can a compromised identity do? Or, where does the architecture permit unintended access?

## How to pen test on AWS

An AWS penetration test should follow a defined process, with evidence collected at each stage. The workflow below connects cloud discovery and technical validation to findings that engineering teams can act on.

### 1. Define scope and authorization

Document the AWS accounts, regions, applications, resources, and identities covered by the assessment. Record who approved the work, the testing window, permitted techniques, and explicit exclusions.

Define how testers will handle sensitive data, which changes they may make, and when testing must stop. For a multi-account environment, identify the specific account boundaries: Access to one workload doesn’t automatically bring every connected account into scope.

Agree on communication with the defensive team. Identify a contact for unexpected behavior and establish how analysts will distinguish authorized activity from a separate incident. This coordination also creates an opportunity to evaluate whether expected security signals appear during testing.

### 2. Discover assets and establish the starting identity

Map the approved attack surface, including exposed applications, API endpoints, compute workloads, and relevant network paths. Where credentials are provided, document the starting identity and its intended access.

For credentialed testing, aws sts get-caller-identity identifies the calling AWS account and principal. Record that identity before interpreting permission checks or resource access. The[ AWS command reference](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html) describes the returned account, user ID, and ARN.

Build an inventory that connects resources to their owners and purpose. A useful discovery record explains which assets are reachable, which identities interact with them, and where sensitive data or administrative capabilities may sit.

### 3. Identify vulnerabilities and configuration weaknesses

Combine application testing with a review of the cloud configuration that supports the application. Examine authentication and authorization behavior, exposed services, workload permissions, and access to secrets or data.

For IAM review, prioritize overly broad permissions, permissive trust relationships, and roles whose privileges exceed the workload’s needs. Review network exposure alongside identity permissions: an accessible endpoint and a powerful workload role can create a more consequential path together.

Use automated findings to guide investigation. Record what each check establishes and what still needs validation. This prevents a failed configuration check from becoming an unsupported claim of compromise.

### 4. Validate exploitability and business impact

Test specific hypotheses within the agreed scope. Establish the conditions needed for exploitation, demonstrate the minimum evidence necessary, and document the resources or privileges that become reachable.

#### IAM privilege escalation

Review iam:PassRole separately from sts:AssumeRole. PassRole permits a principal to assign a role to an AWS service. When combined with control over that service and a suitable role trust relationship, excessive permissions can enable execution with greater privileges. AssumeRole returns temporary role credentials when the trust policy and applicable authorization requirements permit access.[ AWS PassRole guidance](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) and[ AssumeRole documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) explain the distinction.

For evidence collection, PassRole is a permission rather than an API call. Inspect the service operation that received the role, such as a function-creation event, because there is no standalone PassRole CloudTrail event.

#### SSRF and instance metadata

A server-side request forgery vulnerability can become an identity exposure if the application can reach EC2 instance metadata and obtain usable workload credentials.

Inspect the instance’s effective [metadata configuration](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_InstanceMetadataOptionsRequest.html). Setting HttpTokens to required enforces IMDSv2 and disables IMDSv1; optional allows either version. Requiring IMDSv2 reduces common metadata-abuse paths, while the application’s SSRF weakness still requires remediation.

If credentials are obtained during an authorized test, record the principal and credential expiration. The approved engagement determines when testing is authorized; credential expiration only limits how long those credentials remain valid.

For example, an SSRF vulnerability could expose an EC2 workload’s credentials. If that workload’s role can read a designated S3 test object, those credentials may allow access to it. Within the approved testing scope, document each step:

1. The application behavior that exposes metadata access
1. The workload identity reached through that behavior
1. The resource access permitted to that identity
1. The evidence demonstrating access and its potential impact

Use an agreed test object or another minimal proof wherever possible. Identify which control changes would break the path, such as fixing the application behavior or narrowing the workload’s permissions.

### 5. Report findings with reproducible evidence

Each finding should identify the affected assets, prerequisites, reproduction steps, evidence, business impact, and recommended remediation. Explain how the observed behavior differs from the intended access model.

Answer four questions:

- Which principal did the initial exposure lead to?
- Which resources could that principal access?
- Which permissions or configurations expanded the impact?
- What evidence supports each step?

Correlate test records with available cloud logs. CloudTrail Event History provides the previous 90 days of management events for each region. It doesn’t include S3 object data events; configure the appropriate data-event logging in a trail or event data store before relying on it for assessment evidence.[ CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) and[ data-event logging](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) have different coverage.

Assign an owner and a remediation priority to each finding. Distinguish confirmed access from impact inferred through configuration review, and identify any assessment limitations.

### 6. Remediate, clean up, and retest

Fix the conditions that enabled the attack path. Depending on the finding, this may involve application changes, narrower permissions, tighter network access, or changes to how credentials and secrets are handled.

Remove test resources and temporary access created during the engagement, following the agreed cleanup procedure. Retain evidence according to the engagement’s handling requirements.

Retest the original path after remediation and record the outcome. Confirm that the fix blocks the demonstrated behavior and check related resources for the same underlying configuration pattern.

## Difference Between Traditional Pentesting & AWS Pentesting

Traditional and AWS penetration tests share the same objective: validate exploitable weaknesses and explain their impact. AWS adds cloud service boundaries, API-driven operations, and identity relationships to the assessment.

| Dimension | Traditional infrastructure testing | AWS penetration testing |
| --- | --- | --- |
| Discovery | Hosts, ports, network services, and applications | Those same surfaces plus cloud resources, service APIs, and identity relationships |
| Access analysis | Local accounts, directory permissions, and application roles | Application access plus IAM policies, role trust, and workload identities |
| Scope definition | Approved systems, networks, and applications | Approved accounts, regions, resources, services, and activities |
| Evidence | Application logs, host logs, network observations, and test output | Those sources plus CloudTrail and service-specific logs where configured |
| Remediation | Software, host configuration, application logic, and network controls | Those measures plus cloud permissions, resource policies, and deployment configuration |

Cloud testing still requires application and network expertise. The additional task is tracing how a weakness interacts with the identities and resources around it.

## How Wiz supports AWS penetration testing

An AWS penetration test produces evidence about the environment at the time of assessment. As applications and cloud configurations change, teams also need ways to validate new exposures and manage findings through remediation.

Wiz supports this work through application testing and a shared workflow for assessment results.

### Wiz Red Agent: Continuously validate application and API risks

[Wiz Red Agent](https://www.wiz.io/blog/wiz-red-agent-is-ga) continuously tests applications and APIs to uncover exploitable weaknesses, including business logic flaws and authorization bypasses. It uses information about application behavior and the surrounding environment to guide its investigation.

Its capabilities include discovering API endpoints, validating application weaknesses, and assessing the access associated with exposed secrets. Verified findings include execution evidence and reproduction steps that help teams investigate and act on the results.

For applications running on AWS, this provides ongoing validation alongside the broader cloud assessment. Define the engagement’s coverage separately, including any IAM, infrastructure, or other testing that the organization requires.

### Wiz Penetration Test Findings: Connect results to cloud context

[Wiz Penetration Test Findings](https://www.wiz.io/blog/wiz-pen-test-findings-is-now-ga) centralizes results from external assessments, internal red teams, bug bounty programs, and AI testing. It can turn uploaded PDF reports into structured findings containing details such as severity, evidence, reproduction steps, and affected assets.

Connecting these findings to the [Wiz Security Graph](https://www.wiz.io/blog/wiz-security-graph-enhances-cloud-incident-response) helps teams evaluate exposure, privileges, sensitive data, and related attack paths. Ownership and status tracking support the work of prioritizing findings and following remediation.

This gives teams a way to connect a tester’s evidence to the resources and people responsible for fixing the issue.

See how application testing and contextualized findings can support your AWS security program. [Get a Wiz demo](https://www.wiz.io/demo).

## FAQs

Retest a finding after its remediation is deployed, using the original reproduction steps within an approved testing window. Check whether the demonstrated path is closed and whether related resources share the same weakness. Significant application, permission, or architecture changes may also justify another assessment.

---

[View on wiz.io](https://www.wiz.io/academy/vulnerability-management/aws-penetration-testing)