AWS Penetration Testing: What You Can and Cannot Test

AWS penetration testing has become a board-level question for UK organisations moving workloads to the cloud, yet it remains widely misunderstood. The platform behaves very differently from a traditional on-premise network, and the rules of engagement are set partly by Amazon and partly by your own architecture. This guide explains what you can and cannot test, how the shared responsibility model shapes scope, and how a CREST-accredited approach turns a cloud audit into actionable risk reduction.

What AWS penetration testing actually covers

AWS penetration testing covers the resources, identities and applications you run inside your own Amazon Web Services accounts, assessed with authorisation. Unlike a generic network test, it focuses on cloud-native attack paths and the chains an attacker uses to escalate from one compromised credential to full account takeover.

Those attack paths include misconfigured Identity and Access Management (IAM) policies, over-permissioned roles, exposed storage and weak network segmentation.

A thorough engagement examines several layers. At the application layer, our testers attack the web and API workloads you host on services such as EC2, ECS, Lambda and API Gateway. At the configuration layer, they review IAM, Security Groups, S3 bucket policies, KMS key usage and logging coverage against the AWS Foundational Security Best Practices. At the identity layer, they trace privilege escalation routes unique to AWS, where a single overly broad iam:PassRole or sts:AssumeRole permission can unravel an entire account.

The aim is not a list of scanner findings, but to demonstrate with evidence how a determined attacker would move through your environment and what they could reach. That distinction separates a credible cloud security test from an automated configuration scan.

The AWS shared responsibility model and what it means for scope

Every AWS penetration testing decision flows from the shared responsibility model. Amazon is responsible for security “of” the cloud: the physical data centres, the hypervisor and the managed service infrastructure. You are responsible for security “in” the cloud: your data, your IAM configuration, your operating systems, your network rules and your application code. A penetration test lawfully covers your side of that line and stops at Amazon’s.

This boundary is the single most important concept to grasp before scoping. It explains why you are free to attack your own EC2 instance but cannot probe the hypervisor it runs on, and why a serverless function’s code and permissions are fair game while the Lambda execution environment itself is off-limits. Mapping your architecture against this model is the first thing our testers do, because it defines both the legal scope and the most valuable targets.

For UK organisations pursuing compliance against frameworks such as ISO 27001 or the Cyber Essentials scheme, this model also clarifies evidence. Auditors increasingly expect to see that you have tested the parts of the cloud you control, rather than relying on Amazon’s certifications to cover configurations you introduced.

What you can test without AWS approval

Under the current AWS customer support policy, customers no longer need permission for most penetration testing of their own resources. You may test the following service categories without prior authorisation, provided the targets belong to your account:

• EC2 instances, NAT Gateways and Elastic Load Balancers you own
• Amazon RDS databases and Amazon Aurora within your environment
• CloudFront distributions you control
• API Gateway endpoints, AWS Lambda functions and Lambda Edge functions
• Amazon Lightsail resources and Elastic Beanstalk environments
• Elastic Container Service workloads

In practice this covers the vast majority of what a real engagement needs to touch. Our testers attack your applications, enumerate IAM permissions, attempt privilege escalation, probe network segmentation and assess detection and response, all without a permission request to Amazon. The one courtesy that still matters is informing AWS in advance of any test likely to generate unusually high traffic, so automated abuse-detection does not throttle a legitimate assessment.

What you cannot test under any circumstances

The prohibited list is short but absolute, and breaching it can result in account suspension. You may not carry out the following against AWS:

• Denial-of-service (DoS) or distributed denial-of-service (DDoS) attacks, or any simulation of them, without enrolling in the AWS DDoS simulation programme
• Port flooding, protocol flooding or request flooding designed to exhaust capacity
• Any testing of AWS-owned infrastructure, the underlying hypervisor, or other customers’ resources
• Testing of services that Amazon has not listed as permitted, without explicit prior approval
• Security testing of third-party managed services running on AWS where you are not the account owner

These restrictions exist because AWS is a multi-tenant platform: an uncontrolled flood or an attack that strays onto shared infrastructure could degrade service for unrelated organisations. A professional test designs around these limits from the outset. Our rules of engagement always document which accounts, regions and services are in scope, signed off before any activity begins, so there is no ambiguity about where the boundary sits.

The most common AWS findings our testers report

Across UK cloud environments, the same weaknesses recur. The findings that most often drive risk include:

• Over-permissioned IAM roles and users. Wildcard policies, unused administrative access and roles that can assume more powerful roles all create silent escalation paths.
• Publicly exposed S3 buckets and snapshots. Misconfigured object permissions and public EBS or RDS snapshots remain a leading cause of UK data exposure incidents.
• Weak credential hygiene. Long-lived access keys embedded in code, EC2 instance metadata reachable by a compromised application, and absent multi-factor authentication on privileged identities.
• Insufficient network segmentation. Overly broad Security Groups and flat VPC designs that let one compromised host reach databases and management interfaces.
• Gaps in logging and detection. CloudTrail not enabled across all regions, GuardDuty disabled, or alerts going nowhere, so an intrusion goes unnoticed.

The instance metadata service deserves special mention. Where IMDSv1 is still enabled, a single server-side request forgery flaw can hand an attacker the temporary credentials of the EC2 role, frequently the first domino in a full account compromise. Demonstrating that exact chain, rather than simply flagging the configuration, is what makes a finding actionable.

How AWS testing fits a wider cloud security programme

AWS testing fits a wider cloud security programme as one component of a broader attack surface, because AWS rarely sits in isolation. Most UK organisations run hybrid estates, with on-premise infrastructure, SaaS platforms and sometimes a second cloud provider, and a meaningful assessment reflects that.

Our cloud penetration testing service assesses AWS, Azure and Google Cloud against the same methodology, so findings are comparable and remediation is coordinated rather than siloed.

Scope also depends on your goal. A pre-launch assurance test looks different from an annual compliance test or a focused IAM review after a re-architecture, so defining that goal early keeps the engagement proportionate. You can review the related assessments on our services overview.

How EJN Labs approaches AWS penetration testing

EJN Labs is a CREST-accredited UK penetration testing firm, and every cloud engagement is delivered by senior and principal testers, never junior staff. We hold Cyber Essentials, Cyber Essentials Plus, ISO 27001 and ISO 9001 certifications, so the way we handle your access keys, evidence and reporting meets the same standards we test you against.

Our process begins with a structured scoping conversation to map your accounts against the shared responsibility model and agree clear rules of engagement. Testing combines manual exploitation with cloud-native tooling, focused on demonstrating real attack chains rather than generating scanner noise. Every engagement includes a free retest once you have remediated, so you can evidence that the issues are genuinely closed. Pricing is fixed and driven by scope complexity measured in tester days, with typical UK day rates of around £1,200 to £1,300; you can see how this works on our penetration testing cost guide. There are no tiered seniority rates.

Frequently Asked Questions

Do I need permission from AWS before a penetration test?

No, for most services you no longer need to request permission from AWS to test your own resources, including EC2, RDS, Lambda, API Gateway and CloudFront. You should still notify AWS in advance of any test likely to generate high traffic volumes.

One firm exception remains. You must never run denial-of-service activity without joining the dedicated AWS DDoS simulation programme.

How much does AWS penetration testing cost in the UK?

AWS penetration testing in the UK costs a set number of tester days at a typical day rate of £1,100 to £1,400, with the total driven by scope complexity. A focused IAM and configuration review needs fewer days than a full assessment of a large multi-account estate.

An estate running several applications sits at the larger end of that scale. We provide a fixed price after scoping, and you can read more on our penetration testing cost guide.

What is the difference between an AWS configuration scan and a penetration test?

A configuration scan lists misconfigurations, a penetration test proves what an attacker can do with them. The scan checks your settings against best-practice baselines, while a penetration test actively exploits the weaknesses it finds to demonstrate real attack chains rather than a checklist of theoretical issues.

Those chains include escalating from a single compromised credential to full account access, which is how the test shows genuine business impact.

Will testing disrupt my live AWS environment?

A professionally scoped AWS test is designed to avoid disruption. We agree rules of engagement in advance, avoid all prohibited activity such as flooding, and can work against staging environments or carefully timed windows for sensitive production systems. Our testers prioritise safe, evidence-led techniques over anything that risks availability.

Does AWS penetration testing support ISO 27001 or Cyber Essentials?

Yes, AWS penetration testing supports both ISO 27001 and the Cyber Essentials scheme. Testing the resources you control in AWS provides the evidence auditors expect for those frameworks, demonstrating that you have assessed the parts of the cloud within your responsibility.

The test also shows you are not relying solely on Amazon’s platform certifications to cover configurations you introduced.

Ready to test your AWS environment?

If you are planning a cloud assessment, a CREST-accredited test gives you defensible evidence and a clear remediation path. Explore our cloud penetration testing service or request a fixed-price quote through our CREST penetration testing quote form, and our team will help you scope an engagement that matches your AWS estate.