AWS Penetration Testing Services: IAM, Data, Workloads and Segmentation

AWS penetration testing services answer one question: if an attacker reached your AWS estate from the internet, or got hold of one set of credentials, how far could they go? We review the configuration of every account in scope, then test by hand which weaknesses chain together into a real path to your data. You get the attack paths, the evidence and the exact policy or setting to change.

This page covers scope, AWS’s testing rules and deliverables. What AWS lets customers test, and what it prohibits, is summarised in the table further down and explained in more depth in our guide to AWS and Azure penetration testing rules; we check the current policy at scoping. AWS testing sits within our wider cloud penetration testing service, alongside Azure penetration testing, Google Cloud and Microsoft 365.

What does an AWS penetration test cover?

Everything on your side of the shared responsibility model that an attacker could use:

How do you test IAM and privilege escalation?

IAM is where most of the work happens, because in AWS an identity with the wrong permission can do more damage than an open port. We map every principal’s effective permissions, then look for routes from a low-privileged identity to a powerful one.

Typical routes include permission to pass a stronger role to a new Lambda function or EC2 instance, to create a new version of a policy or attach one, or to assume a role whose trust policy is wider than intended. Credentials stored in Secrets Manager, Parameter Store, environment variables or CI/CD settings often provide a shortcut.

We then test from realistic starting points agreed at scoping: a leaked developer access key, a compromised build pipeline role, or a web application flaw that exposes instance credentials. Each path is followed to an agreed proof point and no further.

How do you assess S3 and data exposure?

We find every place your data can be read from outside its intended audience. That starts with Block Public Access at account and bucket level, bucket policies that grant access to everyone or to unknown accounts, and legacy ACLs.

It continues beyond S3: RDS and EBS snapshots or AMIs shared publicly or with other accounts, backups and logs stored with weaker controls than the data they contain, objects served through CloudFront without the restrictions you expect, and KMS key policies that let too many identities decrypt. For each exposure we show what is readable and by whom.

How do you test EC2, Lambda and EKS workloads?

We test each compute service for the ways it can hand an attacker credentials or code execution.

• EC2: whether instances require IMDSv2, so an SSRF flaw in a hosted application cannot simply read the instance role’s credentials; secrets in user data; and security groups exposing SSH, RDP or databases.
• Lambda: the permissions of each execution role, secrets in environment variables, function URLs without authentication, and whether untrusted event data can reach code that treats it as trusted.
• EKS: public or private API endpoint, Kubernetes RBAC, how IAM roles are mapped to pods, and whether a compromised pod can reach the node’s credentials or other namespaces.

Applications and APIs running on AWS are tested as part of the same engagement or through API penetration testing, so a flaw in the application layer can be followed into the cloud layer.

How do you test network segmentation for PCI DSS in AWS?

If segmentation keeps systems out of PCI DSS scope, Requirement 11.4.5 of PCI DSS v4.0.1 requires it to be penetration tested at least once every 12 months and after any change to segmentation controls or methods. Service providers must test every six months under Requirement 11.4.6. The test must cover every segmentation method in use and be carried out by a qualified tester who is organisationally independent of the systems being tested.

In AWS that means more than checking security groups. We work from a test host or identity in each out-of-scope VPC or account and confirm it cannot reach the cardholder data environment on any port, whether directly or through VPC peering, Transit Gateway, VPN connections, endpoint services or shared services such as directory and monitoring tools. Because IAM can cross boundaries that no network rule would allow, we also check whether a role in an out-of-scope account can assume its way into the CDE account.

Results are recorded per source segment and destination, with the evidence an assessor needs to confirm the CDE is isolated. How to design that segmentation, and what AWS covers under its own PCI DSS assessment, is explained in our AWS PCI compliance guide. The testing requirements themselves are published in the PCI SSC document library.

Is an AWS security assessment the same as AWS pen testing?

No. An AWS security assessment, or configuration review, tells you what is misconfigured; AWS pentesting tells you what an attacker could do with it. We deliver both, because each finds things the other misses.

AWS’s own tools, such as Amazon Inspector, GuardDuty and Security Hub, are worth running continuously. A test checks how their findings combine, and whether your detection notices an attacker. The NCSC’s penetration testing guidance makes the same point: a test is assurance that your own processes work, not a substitute for them.

What does AWS allow you to test without approval?

AWS lets customers run security assessments and penetration tests of their own resources on a published list of permitted services without asking first. A short list of techniques is banned outright, and covert red team activity needs a request in advance.

This summarises AWS’s own penetration testing policy as published in October 2026. AWS changes the permitted list from time to time, so we check the current version at scoping and plan any Simulated Events request into the timeline.

What do you need from us before an AWS test?

• The AWS account IDs and regions in scope, and an architecture diagram if you have one.
• A read-only role in each account for the configuration review.
• A test identity with the starting permissions agreed for hands-on work.
• Public endpoints, domains and applications in scope.
• A testing window, technical contacts and a decision on whether to tell your monitoring team.
• Written authorisation from whoever owns each account.

Every test follows the five stages of penetration testing: planning and reconnaissance, scanning, gaining access, maintaining access, and analysis and reporting.

What do you get in the AWS penetration test report?

• An executive summary of overall risk and the most important attack paths.
• Each finding with a CVSS-based rating, evidence, the affected resources and the exact policy or setting to change.
• Attack path narratives showing how individual weaknesses combine.
• Configuration review results mapped to the CIS AWS Foundations Benchmark.
• For PCI DSS clients, segmentation test results written to stand as assessment evidence.
• An attestation letter for auditors and customers and, where scoped, a retest of remediated findings with an updated report.

What affects the cost of AWS penetration testing services?

Price depends on the size and shape of the estate, not on your AWS bill:

Our penetration testing cost guide explains how scope drives price, and the penetration testing quote form returns a fixed price.

Why Sovereign Secure

• We are a PCI SSC-approved Qualified Security Assessor (QSA) company, so segmentation and penetration test reports are written to the standard an assessor expects.
• We are ISO 27001 certified, and our reports support Annex A 8.8 evidence.
• Our testers cover cloud, web, API, network, source code and red team work, so a path that leaves AWS can be followed.
• Proposals are fixed-price, and a retest of remediated findings can be built in from the start.

Next step

Tell us how many AWS accounts and regions you run, the main services in use and whether any of it is in PCI DSS scope. We will confirm the scope and send a fixed-price proposal; we aim to reply within one working day.