AWS penetration testing: Definition, Policy Tools, and process

Amazon Web Services (AWS) is a cloud-computing platform offered by Amazon, which provides cloud services such as computing power, storage, databases, networking, and automated intelligence. AWS replaces data centres, builds applications, and offers pay-as-you-go. The unique features of AWS are scalability, global infrastructure, security, cost-effectiveness, and flexibility.

AWS penetration testing involves a planned attempt to breach a firm’s Amazon Web Services (AWS) cloud infrastructure and assets, aiming to detect vulnerable security flaws, misconfigurations, and compliance failures. Not everyone can perform AWS penetration testing, as it operates under a shared responsibility model. AWS penetration testing is important because of shared responsibility compliance, identifying misconfigurations, meeting regulatory requirements, and proactive risk mitigation. 

AWS penetration testing operates under a clear policy framework that defines permitted activities and prohibits actions that could harm shared infrastructure or other customers. According to a 2023 study by Engstrom et al., titled “Automated Security Assessments of Amazon Web Services Environments,” the AWS pentesting policy includes customer responsibility, permitted testing activities, scope and planning, and identity and access management policies. The permitted services of AWS penetration testing are Amazon EC2 instances (and their associated applications), Amazon RDS (Relational Database Service) instances, Amazon API Gateway and Lambda functions (serverless), and Amazon S3 (Simple Storage Service) buckets. 

The prohibited services of AWS pentesting include denial of service, protocol flooding, and DNS zone walking. The main tools for AWS penetration testing include Pacu, ScoutSuite, CloudMapper, Burp Suite, OWASP ZAP, AWS CLI, IAM Policy Simulator, AWS Config, and Nmap. The AWS penetration testing process is a structured approach that includes defining scope, mapping, configuration review, vulnerability analysis, exploitation, and remediation.

What is AWS penetration testing?

AWS penetration testing is a security assessment that targets a company’s assets, applications, and configurations within the Amazon Web Services (AWS) cloud environment. The term “penetration testing on AWS” is correct, as the target of the attack is your company’s deployed assets within your AWS account. According to 2025 research by Pabitra Kumar Sahoo titled “AWS penetration testing: a comprehensive guide,” pentesting on AWS aims to identify misconfigured S3 buckets, exploit vulnerable web applications running on EC2 instances, and escalate privileges using weak IAM roles. 

The other names of AWS penetration testing are AWS security assessment and AWS infrastructure penetration testing. AWS penetration testing involves Identity and Access Management (IAM), Storage and Data Services (S3, RDS, EBS), Network and Compute (VPC, EC2, Security Groups), and Application and Serverless Workloads. 

AWS penetration testing combines both automated and manual methods to improve accuracy and efficiency, according to a 2024 study by Jyotirmoy Sarkar titled “AWS Penetration Testing: Automated as well as Manual Approach.” The AWS automated tools help in rapid discovery and configuration review, and baseline scanning. The manual testing helps with exploitation, validation, complex flaws, and chain attacks. 

What you should know about the AWS Shared Responsibility Model?

The AWS Shared Responsibility Model defines the division of security obligations between AWS and the customer. This model is fundamental to understanding what can and cannot be tested during AWS penetration testing.

AWS Responsibility (Security “of” the Cloud)

AWS secures the underlying infrastructure, including physical data centres, hardware, networking, and the hypervisor layer. Customers cannot test these components.

Customer Responsibility (Security “in” the Cloud)

Customers secure their data, applications, identity configurations, operating systems, network settings, and firewall rules. These components are the focus of AWS penetration testing.The division varies by service type:

• IaaS (EC2): Customers manage operating systems, applications, security groups, and data
• PaaS (RDS, Elastic Beanstalk): Customers manage applications, data, and access controls; AWS manages patching and infrastructure
• SaaS (S3, Lambda): Customers manage data, access policies, and function code; AWS manages runtime and infrastructure

Understanding this model determines which AWS resources fall within the penetration testing scope and helps testers focus on customer-controlled security configurations.

Does AWS permit penetration testing?

Yes, AWS permits penetration testing on customer-owned assets and configurations within specific rules and regulations. Any AWS customer or third-party security tester hired by the customer can perform penetration testing by following AWS guidelines regarding permitted and prohibited activities.

Organisations that offer AWS penetration testing services must ensure that all testing activities align with AWS policies and do not impact other customers or the broader AWS infrastructure.

AWS allows security testing on certain customer services without prior approval, although a simulated event form must be submitted. The services that do not require prior approval include Amazon EC2 instances, Amazon RDS, Amazon S3, Amazon CloudFront, and Amazon VPC. However, certain activities require special approval or are strictly prohibited, including denial-of-service (DoS) attacks, protocol flooding, DNS zone walking, and other disruptive testing techniques.

How does AWS penetration testing work?

AWS penetration testing detects security flaws (IAM, S3 and RDS, EC2 and serverless, and logging flaws) that come from customer configurations and actions. The goal of AWS penetration testing is to validate the shared responsibility model, identify and remediate misconfigurations, ensure regulatory compliance, and assess business risk, according to 2025 research by Ahmed M. Arafat titled “AWS Penetration Testing Guide: Techniques & Methodology.”  The purpose of AWS penetration testing is to verify the controls and configurations, to find and fix the errors, to satisfy the requirements of regulatory bodies, and to demonstrate the potential impact of an exploited vulnerability.

What is AWS’s penetration testing policy?

The AWS Penetration Testing Policy defines the rules, scope, and prohibitions for customers or their hired third parties performing security assessments on resources hosted in the Amazon Web Services cloud. 

According to 2018 research by Reka Szabo titled “Penetration testing of AWS-based environments,” the instructions from AWS specify two different ways for testing, such as testing with approval and without approval. One way of testing AWS penetration testing is without prior approval. The other way of testing requires prior approval, including red/blue/purple team testing, DDoS simulation testing, and malware testing. 

The permitted services of AWS penetration testing are Amazon EC2 instances, Amazon RDS, Amazon S3, Amazon CloudFront, and VPC to perform security tests on them. The prohibited activities of AWS penetration testing that require special approval are denial of service, protocol flooding, multi-tenant attacks, DNS zone walking, and special approval. The prohibited activities violate the AWS Acceptable Use Policy and affect other AWS customers, and approval needs to be granted through the simulated event form.

Which AWS services are permitted for penetration testing under the AWS policy?

The authorisation of AWS penetration testing is based on the Shared Responsibility Model, focusing on the customer’s “Security in the Cloud.” Permitted Services of AWS penetration testing (for security assessment and penetration testing) are the particular Amazon Web Services resources (EC2 instances, S3 buckets, and IAM roles). The permitted services of AWS Pen Testing hire a security vendor to target a security assessment without submitting a formal Simulated Event Form to AWS.

Listed below are the AWS services that are permitted for penetration testing under the AWS policy.

1. Amazon EC2 (Elastic Compute Cloud): Amazon EC2 is a virtual server (VS) for running applications that scan the OS, assess the application code running, and check for misconfigured security groups and firewall rules.
2. Amazon RDS (Relational Database Service): Amazon RDS is a managed relational database instance (MySQL or PostgreSQL). It checks connection security, ensures data is encrypted, and verifies tight security group access to the database endpoint.
3. Amazon S3 (Simple Storage Service): Amazon S3 is an object storage for data lakes, backups, and static content. It tests bucket policies for unauthorised public access, checks for write/read permissions, and verifies encryption is enforced. 
4. Amazon CloudFront: Amazon CloudFront is a content delivery network (CDN) service. It tests the configuration of the customer’s distribution, origin access controls, and security headers. It prohibits DNS zone walking or hijacking.
5. Amazon API Gateway:  Amazon API Gateway is a managed service for creating, publishing, and securing APIs. It tests the security of the API endpoints, authentication methods, and associated Lambda function code.
6. AWS Lambda: AWS Lambda is a serverless computing function. It tests the function code for vulnerabilities and ensures the IAM execution role follows the principle of least privilege.
7. VPC Components (Virtual Private Cloud): VPC components are a core virtual network for your cloud resources, including ELBs (Elastic Load Balancers) and NAT Gateways. It focuses on testing network segmentation, routing, and the rules defined in Network Access Control Lists (NACLs).
8. AWS IAM (Identity and Access Management): AWS IAM manages access to AWS services and resources. It audits IAM policies for over-privileging, checking for MFA enforcement, and testing role trust policies for potential privilege escalation.
9. Amazon WAF (Web Application Firewall): Amazon WAF is a service that helps protect web applications from common exploits. It tests the customer’s WAF rules to ensure they are effective at blocking common web attack vectors (XSS (Cross-Site Scripting) or SQLi).
10. Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service): Container orchestration services that run Docker containers and Kubernetes workloads. Penetration testing assesses container image security, cluster configurations, pod security policies, network policies, RBAC settings, and service mesh configurations. Testing includes evaluating whether containers can escape to access host resources or other containers.
11. Amazon ECR (Elastic Container Registry): Container image registry service. Testing verifies that images are scanned for vulnerabilities, access policies prevent unauthorised image pulls, and no sensitive data is embedded in container images.

What penetration testing activities are prohibited under AWS policy?

The AWS penetration testing prohibited activities are actions that testers are forbidden from performing against their customer-owned resources. These activities include large-scale traffic generation and attacks designed to affect the availability and fundamental security of the AWS platform.

Listed below are the 8 AWS penetration testing prohibited activities. 

1. DNS zone walking: DNS zone walking is prohibited because it exposes AWS infrastructure details and violates the privacy of other customers on the platform. DNS zone walking collects confidential information regarding internal infrastructure, private IP addresses, and secretive subdomains.
2. DNS hijacking: DNS hijacking is prohibited because it compromises AWS’s DNS infrastructure and disrupts services for multiple customers. DNS hijacking allows the attacker to redirect the domain to a different IP address, potentially gaining unauthorised control over Route 53-hosted zones or associated AWS resources.
3. Protocol flooding: Protocol flooding is prohibited because it overwhelms AWS network resources and impacts the broader platform stability. Protocol flooding exploits defects in network protocols by sending malformed packets to destroy the connection system.
4. Request flooding: Request flooding is prohibited because high-volume requests consume shared AWS resources and degrade performance for other tenants. Request flooding overwhelms the application’s sources, such as the database, CPU, and memory, causing the service to crash.
5. S3 bucket takeover: S3 bucket takeover is prohibited because it compromises AWS’s service integrity and damages customer trust across the platform. An S3 bucket takeover is a security vulnerability where a hacker takes control of an organisation’s subdomain that can lead to malware distribution, phishing, and reputational damage.
6. DNS pharming: DNS pharming is prohibited because it manipulates critical AWS DNS services that other customers depend on for their operations. DNS pharming is a particular type of DNS attack where the hacker changes the DNS records to redirect users to the wrong websites.
7. Denial of Service (DoS) and Distributed Denial of Service (DDoS): Both actual and simulated DoS/DDoS attacks are prohibited because they degrade service availability for other AWS customers sharing the same infrastructure. Simulated attacks also trigger AWS’s automated defences and disrupt legitimate traffic patterns. AWS prohibits any testing activity designed to assess availability, attack resilience, whether using real attack traffic or simulation tools. Organisations requiring DoS/DDoS resilience testing must submit an AWS Simulated Event Form and receive explicit approval before conducting such assessments.

What is the scope of AWS penetration testing?

The scope of AWS penetration testing defines which AWS accounts, services, resources, and configurations are authorised for testing. A comprehensive AWS penetration testing scope document includes the following components:

AWS accounts and regions in scope:

• AWS Account IDs authorised for testing
• AWS regions where testing is permitted
• Cross-account relationships to be assessed

AWS services and resources in scope:

• EC2 instances (specify instance IDs or tags)
• S3 buckets (specify bucket names)
• RDS databases (specify database identifiers)
• Lambda functions (specify function ARNs)
• API Gateway endpoints (specify API IDs)
• IAM roles, users, and policies
• VPC configurations, security groups, and NACLs

Testing methodology:

• Black-box testing (no AWS credentials provided)
• Grey-box testing (limited IAM credentials provided)
• White-box testing (administrative access and documentation provided)

Exclusions and boundaries:

• AWS infrastructure components (always excluded per AWS policy)
• Production databases containing live customer data (if applicable)
• Third-party integrations requiring separate authorisation
• Specific services excluded by client request

Evidence and reporting requirements:

• Screenshot and log capture permissions
• Sensitive data handling procedures
• Proof-of-concept demonstration limits

Clear scope definition ensures testing activities remain within authorised boundaries and deliver actionable findings aligned with business risk priorities.

What tools are used to perform AWS penetration testing?

AWS penetration testing tools are specialised software applications and frameworks used to automate the discovery, auditing, and exploitation within a specific Amazon Web Services environment.

Listed below are the 6 tools that provide comprehensive support for penetration testing on AWS. 

1. Pacu: Pacu is an open-source AWS exploitation framework maintained by Rhino Security Labs. It allows testers to run modules that target the attack vendor, such as backdooring IAM users and exploiting weak Lambda functions. Pacu stores data in an SQLite database to reduce redundant AWS API queries. Pacu is the primary tool for offensive simulation to demonstrate the impact of a vulnerability. Pacu is highly specialised for AWS exploitation and focuses on the most dangerous cloud attack types (IAM abuse). Pacu requires a base level of compromise (initial credentials) to be effective, and it can be complex for beginners.
2. Prowler: Prowler is a command-line tool that performs security assessments, audits, and compliance checks (CIS (Centre for Internet Security) Benchmarks, HIPAA, and GDPR) by reviewing hundreds of security best practices. Prowler focuses on configuration review and continuous monitoring for cloud environments. Prowler excels at the vulnerability analysis phase and identifies misconfigurations and policy non-compliance across hundreds of services. It provides the audit baseline for the tester to prioritise manual checks. Prowler includes excellent coverage of industry standards, and it is fast, agentless and generates detailed, actionable reports. Prowler is focused on audit, not on exploitation, which contains false positives that require manual validation.
3. ScoutSuite: ScoutSuite has multi-cloud support and can examine AWS, Azure, and GCP. It provides a highly visual and simplified view of the entire attack surface. ScoutSuite is excellent for non-technical stakeholders and for quickly zeroing in on high-risk areas like exposed S3 buckets or overly permissive security groups. ScoutSuite offers highly intuitive visual reports, cross-cloud compatibility, and easy-to-use deployment. ScoutSuite is a continuous automated audit that has less focus on active exploitation than Pacu and misses custom logic flaws.
4. AWS Inspector: AWS Inspector is a commercial AWS service that scans EC2 instances for flaws and checks for deviations from security best practices. AWS Inspector is important for continuous monitoring and automating the discovery of vulnerabilities in the host operating system and application layer on EC2. AWS Inspector does native integration with AWS services and automated assessment for EC2 instances. The AWS Inspector is AWS native, automated, and continuous and has comprehensive reports. The AWS Inspector has a limited scope, is a paid service, and is less flexible. 
5. Burp Suite: Burp Suite is used for web application security testing on applications hosted on services like Amazon EC2 or AWS Lambda. Burp Suite is essential for finding flaws like SQL injection, XSS, and broken access control in the customer’s application layer. Burp Suite is an intercepting proxy for traffic analysis, an integrated scanner, and specialised tools for manual and automated web app testing.
6. Nmap: Nmap is used for network discovery and port scanning to identify active devices, open ports, and services in the customer’s defined network space, such as EC2 instances and associated load balancers. Nmap is crucial for the initial reconnaissance phase. Nmap is a highly versatile and reliable network scanning utility and an extensive Nmap scripting engine (NSE) for advanced discovery.

According to Amazon policies, one must not use any security testing tool or service that performs Denial-of-Service (DoS) attacks or simulations of such against any AWS asset.

What penetration testing tools are prohibited from use in AWS?

AWS does not prohibit specific penetration testing tools by name. AWS restricts any tool that performs certain activities or contains capabilities that violate its security testing policy. A tool is considered prohibited if it creates, determines the existence of, or demonstrates a Denial of Service (DoS) condition in any manner, whether actual or simulated.

Prohibited penetration testing tools on AWS are any security testing applications, scripts, or utilities that execute activities banned under AWS policy. These tools generate excessive traffic, manipulate DNS infrastructure, flood network protocols, or simulate availability attacks that could impact shared AWS resources and other customers.

Based on Cyphere’s research, the tools listed below violate AWS’s penetration testing policy and cannot be used on their cloud infrastructure.

1. LOIC (Low Orbit Ion Cannon): LOIC generates high volumes of TCP, UDP, or HTTP traffic to overwhelm target systems. Using LOIC against AWS assets clearly falls under Denial of Service and request flooding. AWS prohibits Denial of Service and request flooding activities. The tool has no meaningful way to disable its flooding behaviour. LOIC should not be used for AWS testing..
2. HOIC (High Orbit Ion Cannon): HOIC launches coordinated HTTP flooding attacks in a distributed fashion. Its sole purpose is to create HTTP request flooding and application-layer DoS conditions. The test and attack behaviours cannot be separated. AWS prohibits HOIC because using it directly violates the no-DoS policy.
3. Slowloris: Slowloris performs slow HTTP header attacks by opening many connections. It keeps these connections half-open to exhaust the web server’s connection pool. This directly maps to prohibited application-layer DoS attacks on AWS. Slowloris has no safe non-DoS mode. It should not be part of an authorised AWS penetration test.
4. SlowHTTPTest: SlowHTTPTest emulates several low-bandwidth application-layer DoS techniques. These include slow headers, slow POST, and slow read attacks. The techniques intentionally degrade availability through protocol abuse. AWS prohibits DoS simulations and protocol flooding activities. The DoS simulation features cannot be completely disabled in a practical way. Running SlowHTTPTest against AWS workloads contravenes the prohibition on DoS simulations.
5. HULK (HTTP Unbearable Load King): HULK sends large volumes of randomised HTTP requests that bypass caches. These requests directly hit origin servers. This behaviour falls squarely within request flooding and HTTP-based DoS on AWS. HULK is specifically engineered to create the unbearable load. It offers no granular, safe testing mode. HULK should be excluded from AWS testing toolchains.
6. R.U.D.Y. (R-U-Dead-Yet?): R.U.D.Y. performs slow HTTP POST attacks by sending web form data extremely slowly. This keeps connections open and starves the server of resources. The attack maps directly to AWS-prohibited application-layer DoS and resource exhaustion. R.U.D.Y. has no non-DoS assessment mode. It is inappropriate for use against AWS workloads.
7. Hping3 (in flooding modes): Hping3 is a powerful packet-crafting tool with legitimate uses such as firewall rule validation. It can also perform SYN, UDP, and ICMP flooding for network-layer DoS. Any use of Hping3 that generates sustained high-rate traffic falls into port flooding and protocol flooding. AWS forbids these activities. Only carefully rate-limited, non-flooding use is compatible with the AWS policy. Flooding options like –flood or high-pps loops must not be used.
8. Masscan (at aggressive scan rates): Masscan is an extremely fast port scanner capable of sending millions of packets per second. At or near maximum speed, it creates DoS-like conditions and port flooding. This contravenes AWS’s ban on volumetric and flooding-style tests. Masscan should either be avoided or strictly rate-limited on AWS. High-throughput or Internet-wide style scans are not acceptable for in-scope testing.
9. Aggressive DNS Enumeration / Zone-Walking Suites (e.g., dnsenum, dnsrecon, Fierce): Tools like dnsenum, dnsrecon, and Fierce automate DNS brute forcing and large-scale record enumeration. They attempt zone-transfer operations against the target DNS infrastructure. AWS explicitly prohibits DNS zone walking. Using these tools against AWS-managed D, NS, like Amazon Route 53, amounts to this prohibited activity. Unauthorised zone transfers and exhaustive enumeration fall outside permitted testing. DNS hijacking or pharming attempts via AWS-hosted zones are also forbidden.
10. Subdomain & S3 Bucket Takeover Scanners (e.g., subjack, subzy, S3Scanner): Tools like subjack, subzy, and S3Scanner detect dangling DNS records and unclaimed S3 buckets. Some tools automatically exploit these vulnerabilities. Running them in takeover modes against AWS resources aligns with AWS-prohibited activities. AWS specifically prohibits Subdomain Takeover and S3 bucket takeover. These tools may be used only in non-exploit, detection-only configurations. Any attempt to claim or abuse identified resources violates AWS testing policy.

How to perform penetration testing on AWS?

Listed below is the process to perform penetration testing on AWS.

1. Obtain AWS Penetration Testing Authorisation: Obtaining AWS penetration testing authorisation validates the entire assessment that ensures adherence to AWS policies and prevents service disruptions. This step determines if prior approval is necessary based on the AWS Penetration Testing Policy. Prior approval is needed for common customer-owned services (EC2, S3, RDS, Lambda, and API Gateway). The AWS Simulated Event Form (for restricted activities) and the creation of a formal Internal Rules of Engagement (ROE) document for all standard tests are the primary tools in this step. This step defines the exact source IP addresses, time windows, and emergency contact details in the ROE. Obtaining AWS pentesting includes Target AWS Account IDs and Tester Source IP ranges. The output of this step is the AWS Authorisation Confirmation or the Signed Internal Rules of Engagement (ROE). This step is a legal and operational safeguard for prohibited tests and leads to immediate account suspension by the AWS Security team. Emergency stop procedures must be understood to ensure there are clear emergency stop procedures before testing begins. It should include contacts, stop conditions, rollback procedures, AWS support escalation and communication protocols.
2. Define Target Cloud Infrastructure Scope: Defining the target cloud infrastructure scope establishes the explicit boundaries of the assessment, ensuring testing is effective and legally authorised. The testers work with the client to identify all in-scope assets, including specific AWS Account IDs, regions, VPCs, subnets, and resource identifiers (EC2 instance IDs, Lambda function ARNs (Amazon Resource Name), and public-facing API endpoints). This step uses tools like the AWS Console and AWS CLI (using commands like describe-instances and list-buckets) to verify resource names and topology. Testers confirm that the client has excluded unsupported EC2 instance types (T1.micro or M1.small) from network scanning, as per AWS recommendations. Defining the target cloud infrastructure scope inputs are client network diagrams and initial AWS access credentials. The output of this step is a signed scope document listing every authorised resource and the type of test (black, grey, and white box).
3. Establish Segregated Testing Environment: Establishing a segregated testing environment isolates testing activities from the production infrastructure, which avoids unintended operational impact. This step is performed with a security jump host provisioned within a non-production VPC or subnet. This host is configured with the necessary testing tools and granted an IAM role to access the target environment via the AWS API. The tools used in the step are AWS EC2 for the jump host, AWS IAM for credential management, and AWS Security Groups for network isolation. The principle of least privilege is necessary for the testing role, and it possesses the permissions strictly required for the test methodology. All activity on the jump host must be logged. Input consists of temporary IAM credentials or a role-assumption ARN and the tester’s SSH key. Establishing a segregated testing environment is a test Jumphost EC2 instance with a confirmed, externally routable source IP address.
4. Enumerate AWS Service Attack Surface: Enumerating the AWS service attack surface is the cloud reconnaissance phase that uses authorised API calls to map the deployment settings. The process begins with external information gathering and ends with internal API-based enumeration. The authorised credentials list all active services, resources, and their public exposure status. This step is designed to build a complete inventory of assets (hardware, software, cloud, and virtual). The tools used in this step are CloudFox, Prowler, ScoutSuite, and Nmap. Testers must avoid aggressive network scanning or port flooding to prevent AWS throttling or triggering security alarms. Enumerating the AWS service attack surface is the initial AWS access key or the assumed IAM role. The output of enumerating the AWS service attack surface is an Asset Inventory List (IPs, S3 names, and API endpoints) and an Initial Audit Report detailing immediate public exposures. This step finds misconfigured resources before attempting exploitation. Reconnaissance activities align with MITRE ATT&CK for Cloud Initial Access (TA0001) and Discovery (TA0007) tactics, including Cloud Service Discovery (T1526) and Cloud Infrastructure Discovery (T1580).
5. Assess IAM Roles and Policies: Assessing IAM roles and policies is the foundation of cloud security. Every IAM user, group, role, and policy is audited for adherence to the principle of minimal access. This step checks for policies with wildcards, verifies that Multi-Factor Authentication (MFA) is enabled for privileged users, and checks for unused access keys. The tools used in this step are Prowler and ScoutSuite for performing policy analysis and checking against CIS benchmarks. The policies allow cross-account access and policies that grant permissions to modify other IAM entities. Assessing IAM roles and policies is a dump of the raw IAM policy documents. The output of assessing IAM roles and policies is a list of overprivileged IAM entities, missing MFA, and any exposed credentials. A single unrestricted role grants an attacker complete control over the test environment. 
6. Test S3 Bucket Access Controls: Testing S3 bucket access controls is a frequent source of data breaches, making bucket access testing a high-priority step. Testing is performed both externally and internally and does not grant unwanted access to other AWS accounts and users. The tools used in this step are S3Scanner for external testing, Prowler for configuration checks, and the AWS CLI for unauthorised operations. The primary focus of testing S3 bucket access controls is on the account-level and bucket-level Block Public Access settings. Testers ensure sensitive data is not being uploaded without encryption. The input of testing S3 bucket access controls is the list of discovered S3 bucket names. Testing S3 bucket access controls involves a list of publicly accessible or writable S3 buckets and any identified buckets storing unencrypted sensitive data. Data leakage occurs when an access control policy is mistakenly configured to allow public read access, exposing documents, backups, or source code. S3 bucket enumeration and access testing map to MITRE ATT&CK Collection (TA0009), specifically Data from Cloud Storage Object (T1530).
7. Evaluate EC2 Security Configurations: Evaluating EC2 security configurations focuses on the security posture of the virtual servers themselves. The assessment reviews the instance’s OS patching status, checks the configuration of the Instance Metadata Service (IMDS), and scrutinises the EC2’s User Data field for embedded secrets. The tools used in the step are AWS Inspector for vulnerability scanning, CloudFox, and standard OS enumeration tools. Evaluating EC2 security configurations finds IMDSv1 exposure, unpatched operating systems, and any hardcoded secrets found in metadata or configuration files. This test checks the customer’s patching and hardening efforts.
8. Analyse VPC Network Security Groups: Analysing VPC network security groups ensures proper segmentation and minimal public exposure. Security Group (SG) and Network ACL (NACL) rules are manually and automatically audited for overly permissive ingress and egress rules. The goal of Analysing VPC network security groups is to identify if any critical services (databases, internal caches, or management ports) are exposed to the public internet and unnecessarily broad internal IP ranges. The tools used in the step are Prowler and ScoutSuite for auditing SG rules against best practices and manual review through the AWS Console/CLI for rule validation. This step focuses on database security groups and allows traffic from the designated application security groups. Analysing VPC network security groups includes data consisting of VPC IDs, security group definitions, and network ACL rules. Analysing VPC network security groups is a list of overly permissive security groups (SSH/RDP) and confirmed insecure network pathways between trusted and untrusted network segments.
9. Review CloudTrail Logging Mechanisms: Reviewing CloudTrail logging mechanisms is the forensic record of all API activity, as its integrity is critical for detection and incident response. This step verifies that CloudTrail is enabled in all regions and is set to log both management and data events. It confirms that the logs are stored in a secure S3 bucket that is encrypted and protected against tampering. The tools used in this step are Prowler and ScoutSuite for configuration validation and the AWS CLI for checking the log S3 bucket policy. The test checks the permissions of the compromised testing role to see if an attacker could disable, delete, or stop logging to simulate an attempt at covering tracks. The input for reviewing CloudTrail logging mechanisms is the CloudTrail configuration details. Reviewing CloudTrail logging mechanisms finds a disabled trail, a lack of log file integrity validation, or confirmation of overly permissive access to the log storage bucket.
10. Exploit AWS Service Misconfigurations: Exploiting AWS service misconfigurations turns discovered configuration flaws into proven security risks. This step confirms misconfigurations from the auditing phases to gain access or extract sensitive data. This step retrieves exposed API keys from public configuration files and leverages a simple vulnerability (XSS) to trigger an IMDSv1 credential. The tools used in this step are Pacu, Burp Suite, and targeted AWS CLI commands. Exploitation is strictly time-boxed, and if the attempt is successful, the tester must document the Proof-of-Concept (PoC) and immediately stop the exploit to avoid unnecessary impact. Exploiting AWS service misconfigurations is a list of confirmed configuration weaknesses (exposed keys, IMDSv1 access). The output of exploiting AWS service misconfigurations is a formal Proof-of-Concept (PoC), which shows confirmed data leakage and unauthorised resource allocation. This step validates the real-world effects of the audit results. Exploitation of AWS misconfigurations aligns with MITRE ATT&CK Initial Access (TA0001) via Exploit Public-Facing Application (T1190) and Valid Accounts: Cloud Accounts (T1078.004).
11. Validate Privilege Escalation Paths: Validating privilege escalation paths is critical where an attacker seeks to expand their limited initial access. This step starts from the low-privilege access gained in the exploitation step. The tools used in the steps are Pacu, CloudMapper, and Prowler. Pen testers should be methodical and focus on the documented AWS IAM privilege escalation vectors. The specialised tools analyse IAM permissions and identify non-obvious ways to increase privileges. This step proves the existence of the path but does not maintain the full privilege for long. Validating privilege escalation paths is the compromised low-privilege IAM role/user credentials. The output of validating privilege escalation paths is a list of confirmed privilege escalation paths that show how a limited user can gain highly privileged access. Finding and fixing these paths is critical for preventing a full compromise. IAM privilege escalation testing corresponds to MITRE ATT&CK Privilege Escalation (TA0004), including techniques such as Account Manipulation (T1098) and Abuse Elevation Control Mechanism (T1548).
12. Document Vulnerabilities and Remediation Steps: Documenting vulnerabilities and remediating steps synthesises all technical findings into an actionable report for the client. This step compiles all findings, such as technical description, detailed proof-of-concept (PoC), business impact and risk rating (using CVSS (Common Vulnerability Scoring System) or CVS-Cloud), and remediation steps. The tools used in this step are Report Generation Software and the final AWS CLI/Console outputs used in the PoC to support evidence. Remediation advice should be specific and must align with AWS Security Best Practices. Results are prioritised based on risk severity. Documenting vulnerabilities and remediating steps is PoC data, audit logs, and technical findings. The output of documenting vulnerabilities and remediating steps is the penetration test report, such as the executive summary, detailed reports, and a remediation plan.

How much does it cost to perform AWS penetration testing?

The cost to perform AWS penetration testing ranges from £3,000 to £20,000+. The average cost to perform AWS pentesting is £800 to £2500 per day. The small and simple AWS pentesting costs £3,000–£7,000, and the complex environments cost £7,000–£15,000. Complex, highly regulated AWS environments typically cost £15,000 to £20,000+ due to extended scope, compliance documentation requirements, and specialised expertise needed for financial services, healthcare, or government workloads.

Some factors that affect the cost of AWS penetration are scope and complexity, testing method, expertise required, timeline, and remediation. AWS penetration testing requires thorough testing, which is important for robust cloud security and regulatory compliance.

How much time does it take to perform AWS penetration testing?

AWS penetration tests take a few days to several weeks, which depends on the scope and complexity of the environment. The small environments take up to 3 to 7 days, and medium to large environments take up to 1 to 3 weeks. 

AWS pentesting is time-consuming and resource-intensive because of expert-driven processes and the complexity of cloud-specific vulnerabilities, according to a 2019 study by AL-Ahmad titled “Systematic Literature Review on Penetration Testing for Mobile Cloud Computing Applications.” 

Automated tools speed up some phases (planning, execution, and reporting), which go from days to weeks. The environment of testing includes the architecture’s size and types of AWS services (Lambda functions, IAM configurations, RDS, and S3) being tested. The type of test, depth of testing, and prior authorisation from AWS influence the timeline of AWS penetration testing.

What are the AWS penetration testing guidelines to follow?

AWS penetration testing guidelines are defined by the AWS Acceptable Use Policy and the Shared Responsibility Model to test the security of their applications and configurations in the cloud. 

Listed below are the AWS penetration testing guidelines to follow. 

• Obtain Pre-Authorisation for Restricted Services: Submit a penetration testing request through the AWS Vulnerability/Penetration Testing Request Form for testing EC2 instances, NAT Gateways, and Elastic Load Balancers at rates exceeding standard thresholds. Authorisation is no longer required for most AWS services, including RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, and Elastic Beanstalk. Specify exact testing dates, target IP ranges, source IPs, and expected traffic patterns in your request.
• Define Clear Testing Scope and Boundaries: Document all AWS accounts, regions, and specific resource IDs to be tested. Identify which services fall under your responsibility per the Shared Responsibility Model. Exclude any resources outside your ownership or control. Obtain written permission from application owners and stakeholders. Create a comprehensive asset inventory including VPCs, subnets, security groups, and associated resources.
• Implement Rate Limiting and Traffic Controls: Configure testing tools to respect AWS service limits and avoid triggering automatic protections. Limit port scanning to reasonable rates (typically 1000-5000 packets per second maximum). Space out vulnerability scans across different time periods. Monitor AWS CloudWatch metrics during testing to ensure you are not affecting service performance. Use throttling mechanisms in automated scanning tools.
• Follow the Shared Responsibility Model: Test only components within your responsibility, including guest operating systems, applications, security group configurations, IAM policies, and data encryption. Do not attempt to test AWS infrastructure, hypervisor, physical facilities, or global network. Focus testing on misconfigurations in S3 bucket policies, overly permissive IAM roles, exposed RDS databases, and weak security group rules.
• Use Authenticated and Privilege-Level Testing: Conduct tests from both unauthenticated external perspectives and authenticated internal user roles. Test privilege escalation paths between different IAM roles and policies. Verify least privilege implementation across all accounts. Test cross-account access permissions and resource sharing configurations. Validate multi-factor authentication enforcement.
• Execute Application-Layer Security Testing: Focus on OWASP Top 10 vulnerabilities, including SQL injection, cross-site scripting, broken authentication, and security misconfigurations. Test API endpoints exposed through API Gateway for authentication bypass and injection flaws. Verify proper input validation and output encoding. Test serverless functions for code injection and insecure dependencies.
• Validate Cloud-Specific Vulnerabilities: Test for publicly exposed S3 buckets with sensitive data. Verify encryption at rest and in transit for all data stores. Test for metadata service vulnerabilities (IMDSv1 vs IMDSv2). Check for hardcoded credentials in Lambda functions and EC2 instances. Verify proper secrets management using AWS Secrets Manager or Parameter Store.
• Maintain Comprehensive Documentation: Record all testing activities with timestamps, source IPs, and target resources. Document each vulnerability with severity rating, reproduction steps, and proof-of-concept evidence. Include screenshots and command outputs for technical findings. Separate findings by criticality level (Critical, High, Medium, Low). Provide specific AWS resource ARNs for affected components.
• Coordinate Testing Schedule and Communication: Notify AWS support and internal stakeholders of testing dates and times. Schedule testing during low-traffic periods to minimise business impact. Establish emergency contact procedures for unexpected service disruptions. Provide regular status updates during extended testing engagements. Coordinate with AWS Support for bandwidth-intensive tests.
• Adhere to Legal and Ethical Requirements: Comply with all applicable laws, including the Computer Fraud and Abuse Act (CFAA). Follow AWS Acceptable Use Policy and Customer Agreement terms. Respect intellectual property and confidentiality obligations. Do not access data belonging to other AWS customers. Maintain professional ethics and responsible disclosure practices.
• Deliver Actionable Remediation Guidance: Provide specific AWS-native remediation steps using AWS Config rules, Security Hub findings, and GuardDuty detections. Include IAM policy corrections with exact JSON policy documents. Recommend specific security group rule modifications. Suggest AWS-managed services for security improvements. Prioritise findings based on exploitability and business impact.
• Conduct Post-Testing Verification: Confirm all testing traffic has ceased and no persistent access mechanisms remain. Remove any test accounts, SSH keys, or temporary credentials created during testing. Verify no testing tools or scripts are running on the tested instances. Document lessons learned and testing methodology improvements. Schedule follow-up validation testing after remediation.

What are the UK Legal Considerations for AWS Penetration Testing?

UK organisations conducting AWS penetration testing must consider several legal frameworks:

• Computer Misuse Act 1990: Unauthorised access to computer systems is a criminal offence under UK law. Written authorisation from the AWS account owner is essential before testing begins. The Letter of Authorisation should clearly define the scope, permitted activities, testing dates and originating IP addresses.
• Data Protection Act 2018 and UK GDPR: Any personal data accessed or observed during testing must be handled in compliance with data protection requirements. Pentesting reports should avoid including actual personal data; sanitised examples or metadata should be used instead.
• NIS Regulations 2018: Operators of essential services using AWS must ensure security testing supports compliance with NIS requirements for network and information system security.
• FCA Requirements: Financial services organisations using AWS should ensure penetration testing aligns with FCA expectations for operational resilience and third-party risk management.
• NHS Data Security and Protection Toolkit: Healthcare organisations using AWS must demonstrate appropriate security controls. AWS penetration testing provides evidence for DSPT compliance assertions. Engaging CREST-accredited providers ensures testing follows recognised UK professional standards and methodologies.