AWS penetration testing: what you may test, and what gets you banned

Short answer: AWS permits customer security testing of eight service categories — including EC2, RDS, Lambda, API Gateway and CloudFront — without prior approval, on resources you own. Denial of service, and anything touching another tenant or AWS's own infrastructure, remains forbidden and requires a separate process. Your customer's permission is still mandatory: AWS's policy is not authorisation to test somebody else's account.

Cloud engagements fail on scope more often than on skill. The technical work is not exotic; the difficulty is knowing which half of the environment you are allowed to touch, and who has to sign for it.

The shared responsibility model, as a scoping tool

The model is usually drawn as a marketing diagram. Treat it instead as the line that separates your engagement from a criminal offence.

AWS is responsible for the cloud — hypervisors, physical hosts, the network fabric, the managed service internals. None of it is yours to test. Attempting to escape a hypervisor or attack a control plane endpoint is out of scope in every engagement, always.

The customer is responsible for what is in the cloud — IAM policies, security groups, S3 configuration, the software on their instances, their Lambda code, their secrets management. That is your entire scope, and it is where essentially all real cloud breaches happen.

Say this to a client during scoping and it saves an argument later: you are not testing AWS. You are testing what they built on it.

What AWS allows without asking

AWS publishes a customer support policy for penetration testing. Under it, customers and their authorised testers may assess these service categories on their own resources without prior approval:

• EC2 instances, NAT gateways and Elastic Load Balancers
• RDS
• CloudFront
• Aurora
• API Gateway
• AWS Lambda and Lambda Edge functions
• Amazon Lightsail resources
• Elastic Beanstalk environments

Still prohibited outright: denial of service and simulated denial of service, request flooding of any kind, protocol flooding, and anything targeting resources you do not own. Certain events — large-scale simulations, network stress testing, red team exercises against your own account at scale — go through a separate authorisation form rather than being simply allowed.

Two clarifications people get wrong constantly:

AWS's permission is not the customer's permission. The policy tells you AWS will not intervene. It says nothing about your legal right to test that account, which comes from a signed engagement document with whoever owns it. Both are required.

Shared or managed services are shared. Testing a managed database's underlying platform, or anything that could affect another tenant, is out regardless of who owns the instance.

Where cloud engagements actually find things

Four paths account for most findings, and none of them are exotic exploits.

IAM privilege escalation. The dominant cloud attack surface. A role that can pass another role, a policy with a wildcard, a user permitted to create access keys for someone else, a trust relationship pointing at an account nobody remembers. Dozens of documented escalation paths exist, all built from legitimate permissions, and every one of them is a configuration decision rather than a bug.

SSRF into the instance metadata service. A server-side request forgery in an application running on EC2 becomes credential theft the moment it can reach the metadata endpoint. IMDSv2 mitigates it and plenty of estates still run v1 on older instances. This is the clearest example of a web vulnerability becoming an infrastructure compromise, and it is why Web Hacking and AWS Penetration Testing belong on the same shelf.

Storage exposure. Public buckets are rarer than they were, and their replacements are not: overly broad bucket policies, presigned URLs with long lifetimes, snapshots shared publicly, and objects readable by every principal in the organisation.

Secrets in the wrong place. Environment variables, user data scripts, container images, CI/CD variables, and repositories. Almost every cloud engagement finds at least one long-lived access key that should have been a role.

How a cloud engagement differs from a network one

	Traditional internal test	Cloud assessment
Primary target	Hosts and services	Identity and configuration
Main tool	Scanner and exploitation framework	API calls and policy analysis
Escalation	Local privilege, then lateral movement	Role assumption and policy abuse
Evidence	Shells and screenshots	API responses, policy documents, CloudTrail entries
Biggest risk to the client	Crashing a fragile service	Changing something in production by accident

That last row deserves emphasis. In a cloud account, an action does not just probe — it can create, modify or delete real resources, and the client's infrastructure-as-code will fight you over it. Read-only credentials for the review phase, explicit written approval before anything that writes, and a note in the report of every change made and reverted.

Multi-cloud, briefly

Azure and Entra ID have their own logic — consent phishing, device code flows, managed identities, hybrid trust with on-premise Active Directory — and their own testing policy. The concepts transfer; the specifics do not, which is why Azure Penetration Testing exists separately from the AWS material and why Cloud Penetration Fundamentals covers the scoping model common to all of them before either.

If your background is internal networks, the shortest bridge is the identity layer: cloud escalation is Active Directory escalation with different vocabulary. Someone comfortable with Active Directory attacks already thinks in trust relationships and delegated permissions, which is exactly the muscle a cloud engagement uses.

A scoping checklist for cloud work

Before the first API call:

1. Account identifiers, listed explicitly. Not "the production environment".
2. Which services are in scope, and whether any fall outside AWS's permitted list.
3. Read-only or read-write, and what triggers the switch.
4. Who owns each account. Subsidiaries and acquisitions frequently mean the signatory does not control everything you were pointed at.
5. Third-party integrations — a SaaS platform holding a role in the account belongs to somebody else, and their consent was never given.
6. The stop condition and the emergency contact.
7. What happens to the credentials you were issued, and when they are revoked.

The general principles behind that list — and what makes authorisation valid at all — are in where to practise hacking legally.

Frequently asked questions

Do I need permission from AWS to run a penetration test?

Not for the eight permitted service categories — including EC2, RDS, Lambda, API Gateway, CloudFront and Elastic Beanstalk — on resources you own. Denial of service, request flooding and anything affecting other tenants or AWS infrastructure remain prohibited, and some large-scale exercises need a separate authorisation form.

Is AWS’s policy enough to test a client’s account?

No. AWS’s policy only means AWS will not intervene. Your legal authorisation comes from a signed engagement document with whoever controls the account, and both are required. Testing a third party’s AWS environment on the strength of AWS’s published policy alone is unauthorised access. What authorisation must contain.

What is the most common finding in a cloud penetration test?

IAM misconfiguration leading to privilege escalation — a role that can pass another role, a wildcard in a policy, or a trust relationship nobody reviewed. It outranks vulnerable software because cloud compromise is usually a chain of legitimate permissions rather than an exploit.

What is IMDS SSRF?

A server-side request forgery in an application on EC2 that reaches the instance metadata service and retrieves the instance’s temporary credentials. It converts a web vulnerability into infrastructure access. IMDSv2 largely prevents it, but older instances still run version one. See the AWS penetration testing course.

Can you test managed services like RDS or Lambda?

You can test your own resources on the permitted list, which includes RDS and Lambda — meaning your configuration, your code and your access controls. You cannot test the managed platform underneath them, which belongs to AWS and is shared with other customers.

Do I need to know AWS deeply before testing it?

You need the identity model — IAM policies, roles, trust relationships, assumption chains — more than you need service breadth. Someone who understands Active Directory delegation learns cloud escalation quickly, because it is the same reasoning about who may act as whom.

Where to go next

Start with the scoping model, then the account internals: Cloud Penetration Fundamentals covers how to plan and run a cloud assessment safely, AWS Penetration Testing covers IAM escalation, metadata abuse and cross-account pivots, and Azure Penetration Testing covers the other half of most estates.