What is AWS penetration testing?
AWS penetration testing is the assessment of an AWS account, meaning the IAM identities that control it, the S3 buckets and RDS instances that hold your data, the VPC networking around them and the EC2 and Lambda workloads inside, to find the weaknesses an attacker could use and confirm which of them are genuinely reachable.
It is a different exercise to testing a data centre. In AWS the control plane is an API, so the shortest path to your data is usually an IAM role with a wildcard action or a bucket policy nobody has read since launch, not an unpatched service. Under the shared responsibility model AWS secures the cloud itself and you secure what you put in it, so testing targets your configuration and your workloads, never AWS infrastructure.
AWS publishes a customer support policy for penetration testing that permits customers to test many customer-operated services without requesting prior approval, while some activity still needs authorisation. That policy changes over time, so check the current version before you scope an engagement and keep everything inside your signed Rules of Engagement.
- What gets assessed. IAM roles and policies, S3 bucket policies and public access blocks, security groups and NACLs, CloudTrail, KMS, EC2 instance metadata, Lambda execution roles and RDS exposure.
- What never gets touched. AWS-operated infrastructure: the hypervisor, physical facilities and the internals of managed services are outside scope by design.
- How PentestOps runs it. An agentless, read-only account review through AWS APIs, paired with active testing of the applications and endpoints you host.
Why AWS accounts drift out of shape
AWS makes it easy to build, and just as easy to accumulate risk. An IAM role picks up a wildcard policy to unblock a deployment and keeps it. Public access block is switched off on one S3 bucket for a partner integration and never switched back. A security group is widened to the whole internet during an incident. An EC2 instance from an old launch template still accepts IMDSv1. A Lambda function inherits an execution role far broader than the single job it does.
None of these decisions is visible to traditional network scanning, and every one of them is exactly what attackers look for first. CloudTrail will have recorded each change, but only if a trail is enabled in every region and somebody is reading it.
The result is drift: a widening gap between the architecture you designed and the account you actually run. Closing that gap needs a review that reads the account itself, not just the traffic in front of it.
What the AWS security review covers
PentestOps connects to your AWS account with read-only credentials and reviews IAM, S3, VPC networking, logging, key management and workload configuration against provider baselines and CIS Benchmarks for AWS. The review runs on the same audit engine that performs 800+ automated checks across AWS, Azure, GCP and M365.
Nothing is installed in your account, and the review can be re-run whenever the environment changes.
| Review domain | What we assess | Typical findings |
|---|---|---|
| IAM | Users, roles, policies, trust relationships and credential hygiene | Wildcard actions in attached policies, unused privileged roles, long-lived access keys, weak MFA coverage on privileged identities |
| S3 and data at rest | Bucket policies, ACLs, public access blocks and encryption settings | Buckets readable by anyone, public access block disabled at account or bucket level, unencrypted objects, broad cross-account access |
| Network | Security groups, network ACLs, VPC ingress and internet-facing services | SSH or RDP open to the whole internet, management ports exposed by a rule nobody owns, NACLs that do not back up the security group intent |
| Logging and keys | CloudTrail coverage and KMS key configuration | Regions with no trail, log file validation off, key rotation not enabled, over-permissive key policies |
| Compute and data services | EC2 instance metadata configuration, Lambda execution roles and RDS exposure | Instances still accepting IMDSv1, execution roles far broader than the function needs, publicly accessible database instances |
Why IMDSv1 and IMDSv2 keep coming up
The EC2 instance metadata service hands temporary credentials for the instance role to anything that can make a request from the instance. Under IMDSv1 a single server-side request forgery bug in an application on that host can be enough to retrieve them. IMDSv2 requires a session token and honours a hop limit, which raises the bar considerably. The review flags instances that still permit IMDSv1 so the exposure is visible before somebody finds the SSRF.
How it works
AWS engagements follow the same seven-phase methodology as every PentestOps assessment. From onboarding to verified fix:
- Onboard the account. Add read-only AWS credentials, typically a dedicated IAM role or user carrying a read-only policy. Each AWS account counts as one asset.
- Verify scope. The platform confirms access and ties all activity to your signed Rules of Engagement.
- Run the review. Automated checks assess IAM, S3, security groups and NACLs, CloudTrail, KMS, EC2 instance metadata, Lambda execution roles and RDS exposure, on demand or on a schedule.
- Prioritise. Findings are scored with CVSS v3.1, flagged for known exploit availability and prioritised against CISA KEV.
- Report and remediate. Compliance-mapped reports in PDF, CSV and JSON/API with per-finding remediation guidance.
- Re-test. Re-run the review after fixes and compare scans to confirm remediation held.
Test the workloads, not just the account
An account review tells you how AWS is configured. It cannot tell you whether the application on that EC2 instance, behind that load balancer or in front of that RDS instance withstands an attack. PentestOps is built to do both from one platform:
- External network penetration testing maps and probes your public AWS footprint with 24+ external recon modules.
- Web application penetration testing and API testing cover OWASP Top 10 and API Top 10 risks in the apps you host, with a live finding stream over WebSocket.
- Agentless Kubernetes security testing audits EKS through a read-only kubeconfig with no DaemonSet to install. On Fargate, where host-level pods are not permitted, node-level checks route through the cloud configuration audit instead.
- Safe automated exploitation validates what is genuinely exploitable, gated by per-tenant Rules of Engagement with scope enforcement. Proof, not guesswork.
Prioritisation, evidence and reporting
Findings are correlated against the CVE database, scored with CVSS v3.1, checked for known exploit availability and prioritised against CISA KEV, with false-positive reduction so engineers spend their time on real risk.
Reports map findings to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes, and export in multiple formats including PDF, CSV and JSON/API. AI-generated executive summaries are written for the board; technical detail and evidence sit underneath for engineers.
Findings are retained for 3 years on Professional and up to 7 years on Enterprise plans, with 365-day audit logs.
Why PentestOps for AWS security
Point tools watch AWS configuration. PentestOps folds the account review into a full penetration testing programme, so posture findings and exploit-validated findings land in the same report with the same prioritisation.
- One subscription covers AWS posture plus external, internal, web, API and identity testing. Running multi-cloud? See cloud penetration testing for AWS, Azure, GCP and M365 together.
- Asset-wise pricing: each AWS account is one asset with unlimited scans within fair use. Live plan details on the pricing page.
- Agentless and read-only: nothing to deploy into your account, nothing to clean up.
- Self-hosted AI by default: scan data is analysed on infrastructure operated by Extranet Systems, not sent to third-party model providers.
- Australian-built and operated. The platform is hosted in Australia and customer data is stored in Australia.
- Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified, independently audited by Atom Assurances.