AWS penetration testing: what gets tested, what AWS policy allows and what is your responsibility
By Kike Gandia · Co-Founder & CEO, OSCP
An AWS penetration test is not about scanning your instances' public IPs. In the cloud the perimeter is identity and configuration: who can call which API, with which permissions and from where. Before starting, three things need to be clear: which part of security is AWS's responsibility and which is yours, what can be tested without asking and what AWS policy prohibits, and which areas a well-scoped test covers. This guide walks through them, with AWS's current policy, how it compares with Azure and Google Cloud, the most exploited IAM privilege escalation paths and how to prepare the account.
What an AWS penetration test is and how it differs from a traditional one
In a classic infrastructure test, the targets are machines and network services. In AWS there is another plane, and it is usually the decisive one: the control plane, the AWS API used to create, modify and read every resource. Anyone who obtains credentials with enough permissions does not need to exploit a server: they can simply ask the API to hand over the data, create a user or change a policy.
That is why an AWS penetration test is scoped in three layers:
- What is exposed to the internet: EC2 instances, load balancers, API Gateway, CloudFront, S3 buckets, Lambda function URLs, publicly reachable databases and subdomains pointing to resources in the account.
- The account and its identities: users, roles, policies, cross-account trust, federation with identity providers and CI/CD pipelines, and each service's configuration.
- The workloads: the applications, functions and containers running in the account, which are often the way in to everything above.
The three are connected. The most common pattern for a serious AWS incident starts in a vulnerable application, continues with the credentials of the role assigned to it and ends in data or in control of the account. A test that looks at only one layer does not see that chain.
The shared responsibility model: what AWS does and what is yours
AWS sums it up in a formula: AWS is responsible for security “of” the cloud and the customer for security “in” the cloud. AWS protects the infrastructure that runs all its services: data centres, hardware, networking and the virtualisation layer. What you configure on top is yours, and how much depends on the type of service:
| Service type | Examples | AWS takes care of | Yours |
|---|---|---|---|
| Infrastructure | EC2, VPC, EBS volumes | Hardware, physical network, hypervisor | Operating system, patching, security groups, applications, data and identities |
| Abstracted services | S3, DynamoDB, Lambda | Infrastructure, operating system and platform | Data, encryption, access policies, IAM permissions and service configuration |
In practice, four things are always yours on every service: who has access and with which permissions, which data you store and how you encrypt it, what you expose to the internet and what you log so an attack can be detected. Those are exactly the areas an AWS penetration test reviews.
A common misunderstanding is assuming that, because a service is managed, secure configuration comes built in. AWS has hardened some defaults —since April 2023 new S3 buckets are created with Block Public Access enabled and ACLs disabled— but it does not change the configuration of what already exists or stop anyone loosening it later. If a bucket becomes public because of a badly written policy, that is the customer's responsibility.
The AWS penetration testing policy: what you can and cannot test
AWS lets customers run penetration tests on their own infrastructure without prior approval for a list of services. As of October 2026 they are: EC2 (including WAF, NAT Gateway and Elastic Load Balancing), RDS, Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx, Transit Gateway, Bedrock AgentCore and Global Accelerator. The list changes over time, so it is checked for every engagement.
| Category | What it covers | What to do |
|---|---|---|
| Allowed without approval | Testing your resources on the listed services, within your account | Document scope and dates internally |
| Always requires prior approval | Any testing that includes command and control (C2) infrastructure | Request it from AWS before starting |
| Simulated events | Red, blue or purple team exercises, simulated phishing, malware testing and network performance testing | Simulated events form in the support console, at least two weeks in advance |
| DDoS testing | Distributed denial of service simulations | Only through a pre-approved AWS partner and on resources protected by AWS Shield Advanced |
| Prohibited | Route 53 hosted zone walking, DNS hijacking or pharming via Route 53, DoS and DDoS (including simulated ones outside its dedicated policy), port, protocol or request flooding, S3 bucket takeover and subdomain takeover | Not done, even within the agreed scope |
Nor can you assess AWS's own infrastructure or its services as such: the object of the test is your resources. If a vulnerability in an AWS service turns up during the test, it is reported to AWS's security team.
Two prohibitions have practical consequences for scope. Because bucket and subdomain takeover are not allowed, if the tester finds a DNS record pointing to a bucket that no longer exists, they document it as a finding with its evidence but do not claim it to prove the point. And the ban on request flooding means agreeing how an API's usage limits will be tested without exceeding what AWS considers an attack.
What about Azure and Google Cloud?
The other two major providers have policies that are similar in essence —no notice needed to test your own resources— and different in the details:
| Provider | Do you need to notify them? | Main restrictions |
|---|---|---|
| AWS | No, for the listed services; yes for C2 testing and simulated events | No DoS, no flooding, no Route 53 zone walking, no bucket or subdomain takeover |
| Microsoft Azure | No since 15 June 2017, but its rules of engagement must be followed | No denial of service testing, no using credentials that are not yours even if leaked, no fuzzing that generates excessive traffic, no phishing of Microsoft employees and no post-exploitation beyond proof of concept |
| Google Cloud | No: Google states you are not required to contact it | Follow the acceptable use policy and terms of service, and make sure tests only affect your own projects |
In multi-cloud environments, the test scope should capture each provider's rules separately. And in all three cases the policies change: the prudent approach is to review them when defining scope and record the version consulted.
What an AWS penetration test reviews
The exact scope depends on the starting assumption, but a full test of an AWS account covers these areas:
| Area | What is looked for |
|---|---|
| IAM | Users with long-lived access keys, root account in use or without MFA, wildcard policies, privilege escalation paths, roles assumable from other accounts without conditions, federation with GitHub Actions or other providers with overly broad conditions |
| S3 | Publicly accessible buckets or objects, policies granting access to any AWS account, long-lived presigned URLs, sensitive data in test buckets |
| EC2 and the metadata service | Instances accepting IMDSv1, secrets in user data, security groups open to the internet, publicly shared AMIs or snapshots |
| Lambda and serverless | Secrets in environment variables, over-privileged execution roles, unauthenticated function URLs, injection through the events the function processes |
| API Gateway | Endpoints without an authorizer, permissive resource policies, missing usage limits |
| Network | Security groups with 0.0.0.0/0 on admin or database ports, VPC peering and connections broader than needed |
| Databases | Publicly accessible RDS instances, shared snapshots, encryption disabled |
| Secrets | Who can read Secrets Manager and Parameter Store, secrets in code or in the pipeline |
| Logging and detection | CloudTrail in every region and protected against deletion, GuardDuty enabled and, above all, whether anyone reacts to its alerts |
| Organisation | Service control policies (SCPs), use of the management account for workloads, accounts outside the organisation |
The specific mistakes in each area and how to fix them are in the guide to the most common cloud misconfigurations.
IAM privilege escalation: the core of the test
The question that best sums up an AWS penetration test is: if an attacker compromises this identity, can they become an administrator? Often the answer is yes, even if the identity has no administrator policy, because some combinations of permissions let it grant itself more. Rhino Security Labs documented twenty-one IAM escalation methods in 2018 and extended the list later; they are still the basis of any review. Some examples:
| Permissions | What they allow |
|---|---|
| iam:CreatePolicyVersion | Creating a new version of a policy already attached to it, with administrator permissions, and setting it as default |
| iam:AttachUserPolicy or iam:PutUserPolicy | Attaching a managed policy to itself or writing an inline policy with whatever permissions it wants |
| iam:CreateAccessKey on another user | Creating access keys for a more privileged user and acting as them |
| iam:UpdateAssumeRolePolicy and sts:AssumeRole | Changing a privileged role's trust policy so it can assume it |
| iam:PassRole, lambda:CreateFunction and lambda:InvokeFunction | Creating a function with a more privileged role and invoking it to run code with its permissions |
| iam:PassRole and ec2:RunInstances | Launching an instance with a privileged role and retrieving its credentials from inside |
The last three examples explain why iam:PassRole is one of the most scrutinised permissions: it grants no privileges by itself, but it lets you hand a role to a service that then acts with it.
The defences are well known, though not always applied: least privilege in policies, permission boundaries for roles that create other roles, organisation SCPs that block the most dangerous actions outside admin roles, and regular review of unused permissions with IAM Access Analyzer. The penetration test checks whether, with all that in place, any path remains.
Black box, white box or assumed breach
The approach determines what can be found. In AWS it is common to combine several:
| Approach | Starting point | What it answers | Limitation |
|---|---|---|---|
| External black box | Only the company name and its domains | What an attacker sees from the internet: buckets, endpoints, dangling subdomains, exposed services | Does not see internal configuration or escalation paths |
| Configuration white box | A read-only role over the accounts | What is misconfigured across every service and region | Does not prove what is exploitable |
| Assumed breach | A low-privilege identity or a compromised workload | How far an attacker who already has a foothold can get | Depends on choosing the starting assumption well |
For the configuration part a read-only role is enough; AWS offers managed policies designed for it, such as SecurityAudit or ViewOnlyAccess. For the offensive part you also need a test identity with deliberately limited permissions that realistically represents what an attacker could steal: a developer's keys, an exposed function's role or the pipeline's credentials.
On production: most of the work in an AWS penetration test is read-only enumeration and does not affect the service. Tests that modify resources —creating a policy version, launching a function— are agreed in advance, done with tagged resources and rolled back afterwards. Destructive tests are not part of a normal penetration test.
Common tools
Tools speed up the work, but none replaces analysing chains. The most widely used, with their status as of October 2026:
| Tool | What it is used for | Status |
|---|---|---|
| Prowler | Configuration review against good practice and frameworks such as CIS, on AWS and other providers | Open source, very actively developed |
| ScoutSuite (NCC Group) | Multi-cloud configuration review | Open source, little activity since 2024 |
| Pacu (Rhino Security Labs) | AWS exploitation framework, including IAM escalation path detection | Open source, active |
| CloudFox (Bishop Fox) | Attack path enumeration: which secrets, roles and entry points exist | Open source, active |
| PMapper (NCC Group) | IAM permission graph to find escalation paths | Unmaintained since 2022 |
| IAM Access Analyzer | External access, unused permissions and policy validation | Native AWS service |
The output of these tools is the starting point. The work of the test is deciding which findings combine, verifying it in a controlled way and measuring whether detection —CloudTrail, GuardDuty, the SOC— reacts while it happens.
How to prepare the account and what you should receive
An hour or two of preparation avoids most problems during the test:
- Define scope in writing: accounts, regions, services and environments included and excluded, starting assumptions and dates.
- Review AWS's current policy and, if the exercise includes phishing, C2 or red team testing, submit the simulated events form in advance.
- Create the test identities: the read-only audit role and the low-privilege test identity, with an expiry.
- Decide what happens with detection: whether the security team is told or whether the exercise also measures their response, and who can stop it.
- Confirm CloudTrail is enabled in every in-scope region: without it, detection cannot be assessed and what was done cannot be reconstructed.
- Name a technical contact available during the testing window.
At the end, the deliverable should include the attack chains demonstrated with evidence, each finding with its impact in your context and a specific fix, the mapping to the CIS AWS Foundations Benchmark or the framework you use, and a retest after remediation. If your company serves the Spanish public sector, it is also worth checking the configuration against the CCN-STIC 887 series of AWS guides published by Spain's National Cryptologic Centre.
FAQ
Do you need AWS permission to run a penetration test?
For the services covered by its policy, no: AWS lets you test your own resources without prior approval. You do need to request approval for any testing involving command and control (C2) infrastructure and, through the simulated events form, for red team exercises, simulated phishing or malware testing. DDoS testing can only be done through a pre-approved partner.
What is prohibited in an AWS penetration test?
Route 53 hosted zone walking, DNS hijacking and pharming via Route 53, any denial of service outside its dedicated policy, port, protocol or request flooding, and S3 bucket or subdomain takeover. Nor can you attack AWS's own infrastructure or services.
If we are attacked because of a misconfiguration, is AWS responsible?
No. Under the shared responsibility model, AWS is accountable for the security of the infrastructure that runs its services; configuration, identities and permissions, data and its encryption are the customer's responsibility. A public bucket or an over-privileged role is a customer-side failure.
Can the test be run against the production account?
Yes, and that is usually the most useful option, because that is where the real permissions and data are. Most tests are read-only. Those that create or modify resources are agreed beforehand, done with identified resources and rolled back afterwards; destructive tests are not part of a normal penetration test.
Does an AWS penetration test include the applications running in the account?
It depends on the scope, and it should be a conscious decision. Many incidents start in an application —an SSRF, an injection— and continue in the account using its role's credentials. If the application is out of scope, at least the assumption that the workload is compromised should be included.
Which secure AWS configuration guides apply under Spain's ENS?
Spain's National Cryptologic Centre (CCN) publishes the CCN-STIC 887 series for AWS, including the specific compliance profile and secure configuration guides. For companies serving the Spanish public sector they are the natural reference to check configuration against, alongside the CIS Benchmarks.
Related service
cloud penetration testing on AWS, Azure and Google Cloud
Related content
- The most common cloud misconfigurations
- CSPM vs cloud penetration testing
- Kubernetes security, including EKS
- CI/CD pipeline pentesting
- From Workspace to GCP: escalation in the Google ecosystem
- How much a penetration test costs