AWS Penetration Test: A Step-by-Step Practical Guide

Your client wants a recent aws penetration test report before procurement signs. Your team has Terraform, a handful of Lambdas, API Gateway in front, an S3 bucket nobody has checked in months, and maybe a Supabase or Firebase-backed mobile flow hanging off the edge of the stack.

That’s a normal place to be. It’s also where a lot of teams make the same mistake. They rush to run tools before they’ve defined what can be tested, what must not be touched, and what matters to the business. In AWS, that gets expensive fast. You can waste days scanning the wrong assets, miss the identity paths that matter, or create noise in production and still end up with a weak report.

A good aws penetration test is disciplined. It starts with policy, moves through scope, attacks the identity and application layers with intent, and ends with evidence your engineers can act on. The strongest tests also cover the blind spot most infrastructure-led guides ignore. Lambda and API Gateway often sit in front of BaaS backends such as Supabase or Firebase, where broken authorisation, exposed keys, weak RPC protections, and flawed data access logic can carry more business risk than a public EC2 service.

Laying the Groundwork for Your AWS Pentest

The panic usually starts with a forwarded email. Sales is close to a deal. The client security questionnaire lands. One line jumps out: provide your latest penetration test for the AWS environment.

The wrong response is to book a test immediately and hope the provider “figures it out”. The right response is to establish the rules of engagement first. That protects your systems, your evidence, and your relationship with AWS.

Know what AWS allows

AWS isn’t a generic hosting provider. You’re testing inside a shared platform, so the provider policy matters.

AWS policy permits penetration testing on customer-controlled services such as EC2, RDS, CloudFront, and Lambda without prior approval, while prohibiting activities like DoS simulations or S3 bucket takeovers. That boundary is what keeps testing focused on assets you own and operate, rather than the underlying AWS platform itself, as outlined in this AWS penetration testing guide.

That one point changes how you plan the entire engagement. If your tester talks casually about stress testing, route hijacks, or proving S3 takeover impact by taking ownership paths, stop there. That isn’t mature testing. That’s poor controls.

Practical rule: If the test plan can’t clearly separate customer-managed assets from AWS-managed infrastructure, the scope isn’t ready.

Write down the testing boundary

Before anyone runs ScoutSuite, Pacu, Prowler, Burp Suite, or a custom script, document four things:

1. Accounts and environments
   List the AWS accounts in scope. Separate production, staging, sandbox, and any inherited client environments.

2. Customer-owned assets
   Name the targets. EC2 workloads, ALBs, CloudFront distributions, API Gateway stages, Lambda functions, RDS instances, S3 buckets, Cognito pools, and web applications.

3. Forbidden actions
   Put prohibited test types in writing. No denial-of-service simulation. No destructive data modification. No bucket takeover attempts. No broad unauthenticated fuzzing against fragile production systems without an agreed window.

4. Business constraints
   Record peak traffic periods, release windows, regulated data zones, and owners for every critical service.

Most failed pentests don’t fail because of tooling. They fail because nobody clarified the line between “prove risk” and “cause an incident”.

Handle approval and coordination properly

Even when AWS doesn’t require prior approval for many service categories, mature teams still coordinate internally like they’re running a live exercise. Security, platform, engineering, support, and leadership should all know:

• What is being tested
• When testing begins
• Who is watching logs and alerts
• Who can stop the test if production impact appears
• What evidence can be collected and retained

If your environment includes edge cases or third-party managed components, your testers should review whether the AWS Simulated Event Form or additional provider coordination is needed. In practice, this is less about bureaucracy and more about proving authorisation and reducing confusion if detections fire.

Use the pentest to show maturity

A strong aws penetration test doesn’t just satisfy procurement. It demonstrates that your team can operate securely under pressure.

That matters because cloud misconfiguration remains a major problem. In the UK, many companies reported at least one cloud security incident in the past year, which is why targeted AWS testing keeps finding issues like misconfigured S3 permissions and overly broad IAM roles before attackers do. That broader context is covered in this practical piece on cloud-based pen testing.

A useful mindset is simple. Don’t treat the pentest as a certificate request. Treat it as an authorised adversary simulation with legal, operational, and technical boundaries.

| Early decision | What works | What fails | |---|---|---| | Policy review | Match test methods to AWS-allowed activity | Assume any “ethical hacking” is permitted | | Stakeholder notice | Tell ops and engineering exactly what’s happening | Let detections surprise your own team | | Scope draft | Name services, apps, accounts, and exclusions | Ask a tester to “check our AWS” | | Proof standards | Use non-destructive validation | Collect risky proof you can’t justify later |

If you get this part right, the rest of the engagement becomes faster and cleaner. If you skip it, every later stage gets harder.

Strategic Scoping for Targets and Risk Assessment

A vague scope burns budget and misses attack paths. “Test our AWS estate” sounds thorough, but in practice it creates three bad outcomes. Testers spend too much time on low-value assets, stakeholders get nervous when scans touch production unexpectedly, and the final report reads like a mixed bag of scanner output.

Good scoping is narrower than people expect and more detailed than they want.

Build a scope document people can use

For a startup running a public web app on AWS, a practical scope document should identify assets by function, not just by technology. I’d want to see the internet-facing app, the API Gateway stages, the Lambda handlers behind sensitive routes, the CloudFront distribution, the S3 buckets used for uploads, the IAM roles attached to compute, and any private resources reachable after an assumed breach.

Add identifiers your testers can work from:

• Hostnames and application URLs for public targets
• AWS account IDs for environment separation
• Named services such as specific APIs, buckets, or Lambda groups
• Authentication context including test users by privilege level
• Out-of-scope systems such as third-party processors or managed SaaS admin portals

That last point matters more than people think. If your mobile app uses Firebase Auth, Supabase storage, Stripe, and a custom AWS API, the engagement needs to state exactly which layer belongs to the pentest and which needs separate authorisation.

Tier assets by risk, not convenience

I’ve seen teams classify targets by “easy to test first”. That’s backwards. Prioritise by business impact and blast radius.

A simple model works well:

| Tier | Example assets | Testing approach | |---|---|---| | Critical | Billing APIs, admin panels, identity roles, production data paths | Manual testing first, controlled windows, high observability | | Important | Customer dashboards, background jobs, internal APIs | Mixed manual and automated testing | | Lower risk | Marketing sites, disposable preview environments | Broader automation, lighter manual review |

This keeps your testers from running aggressive checks against a production RDS-backed path in the middle of the working day just because it was easy to reach.

Don’t scope by AWS service alone. Scope by attack path. A “Lambda issue” often isn’t a Lambda issue. It’s an identity problem, a trust boundary problem, or an authorisation problem.

Use a real attack chain view

A specialist UK bank commissioned a CREST-accredited AWS penetration test and, over a one-week six-phase assessment covering internal and external infrastructure, web apps, builds, configurations, and firewalls, the team uncovered unauthorised access paths to critical systems. That’s a useful reminder that findings often sit between layers, not inside one isolated service.

The reason I like that example is that it reflects how attackers move. They don’t care whether a flaw belongs to “network”, “application”, or “cloud configuration”. They care whether one weakness gets them to the next.

That’s why your scope should include combinations such as:

• Public API to Lambda execution role
• CI runner to deployment credentials
• Support admin panel to internal API methods
• Web app session to BaaS-backed data operations
• CloudFront path handling to origin exposure

Negotiate safe windows before testing starts

Testing windows shouldn’t be an afterthought. The most useful scope docs state when each asset can be hit and with what intensity.

A practical schedule usually looks like this:

• Business hours for low-noise authenticated checks that need support from engineers
• Off-peak windows for broader fuzzing, path brute forcing, and misconfiguration validation
• Change freeze periods when no one wants a pentest touching production
• Immediate pause criteria if latency, queue depth, or error rates move unexpectedly

If your environment supports customer-facing mobile apps and backend-as-a-service integrations, testing windows matter even more. A poorly timed auth bypass check against API Gateway or a noisy function invocation pattern can trigger rate limits, distort telemetry, or confuse on-call responders.

For teams that need a broader planning model, these various cyber security assessments are a useful way to think about where a pentest fits alongside reviews such as architecture assessment, vulnerability management, and compliance validation.

What a strong scope looks like

A strong scope document is specific enough that another tester could pick it up and run the engagement cleanly. It should answer:

• Which assets are being tested
• Which user roles are available
• Which environments are in bounds
• Which activities are restricted
• When testing may occur
• Who signs off on risky actions

That’s the difference between a pentest that finds attack paths and one that produces screenshots with little operational value.

Executing Attacks on Core AWS Services

This is the part people usually mean when they say aws penetration test. The problem is that many teams jump straight into generic scanning and stop there.

That misses the core work. In AWS, the most valuable testing usually sits around identity, storage, metadata access, serverless trust boundaries, and edge routing. For modern stacks, you also need to test where AWS services front a BaaS backend, because API Gateway or Lambda may be the visible entry point while the primary business risk sits in downstream data access rules and exposed service keys.

The AWS Security Agent announcement notes that top AWS tests consistently include S3 flaws, IAM compromises, Lambda backdoors, and CloudFront bypasses, and also points to the need to catch leaked keys and modern application-layer exposure patterns in mobile and backend-heavy stacks via the AWS Security Agent general availability announcement.

IAM and trust relationships

IAM is where many serious AWS compromises begin. Not because IAM is weak, but because teams keep adding exceptions until the policy model stops matching reality.

I start by asking a simple question: if one developer token, CI credential, or instance role is compromised, where can it lead?

Useful attack steps include:

• Enumerate caller identity and attached permissions
  aws sts get-caller-identity
aws iam list-attached-user-policies
aws iam list-attached-role-policies

• Map assume-role opportunities
  Pacu is still useful for surfacing privilege-escalation paths and cross-role trust issues. In manual review, inspect trust policies for broad principals, weak external ID controls, and service roles that humans can indirectly abuse.

• Check for policy wildcards and overlooked actions
  iam:PassRole, sts:AssumeRole, lambda:UpdateFunctionCode, ssm:SendCommand, and permissive secrets access often matter more than long lists of read actions.

What works is chaining permissions into an attack path. What doesn’t work is dumping IAM JSON into a spreadsheet and calling it a pentest.

Field note: The most dangerous IAM flaw often looks harmless in isolation. A role that “only” updates Lambda code or “only” passes another role can be enough to seize the environment.

For internal testing, I also look at inherited access from build systems, support tooling, and temporary operators. AWS estates are full of non-human identities with more power than anyone remembers granting.

S3 and object exposure

S3 testing gets reduced to “is the bucket public?” far too often. That’s entry-level checking.

Effective S3 testing asks deeper questions:

1. Can an unauthenticated or low-privileged user list object names?
2. Can they read sensitive data through direct object access, signed URL misuse, or CloudFront origin exposure?
3. Can they write files that become executable content, poison downstream workflows, or alter reports?
4. Are object versions, logs, build artefacts, or exported configs leaking credentials?

Tactically, I use commands such as:

• aws s3 ls s3://bucket-name --no-sign-request
• aws s3 cp s3://bucket-name/suspected-object - --no-sign-request
• Authenticated checks for bucket policy edge cases and ACL inheritance

Then I correlate findings with application behaviour. A writable upload bucket might be low impact if it’s isolated and never rendered back to users. It becomes serious if CloudFront serves it under the primary application domain or if backend workers trust file contents.

What doesn’t work is reporting every public-read bucket as equally severe. Context matters.

EC2 and metadata abuse

For EC2, the objective isn’t “scan the box and move on”. The objective is to determine whether the instance can be used as a stepping stone.

The classic path is metadata and role abuse. If you gain command execution through an app flaw, an SSRF primitive, or local shell access, the next question is whether you can reach instance metadata and harvest credentials.

Checks typically include:

• Reviewing the application for SSRF entry points
• Validating whether metadata access is possible from the application context
• Looking for cleartext secrets in environment variables, user data, or local config files
• Enumerating role-derived AWS access after foothold

If I have shell or command execution under authorisation, I inspect user data, startup scripts, deployment artefacts, cached credentials, and local configuration used by agents and workers. Teams often protect the perimeter and forget the operational residue on the host.

A second EC2 theme is lateral movement. Once you hold one role, inspect what network access and AWS API access it gives you. Security group overexposure and weak segmentation are often less interesting on paper than in a live chain, where one web instance can suddenly reach internal admin services or private APIs.

Lambda and execution paths

Lambda deserves more attention than it usually gets. Many guides mention it. Fewer test it properly.

The main Lambda questions are:

• Can an attacker invoke it without the expected authorisation?
• Can they influence event data in a way that leads to injection, unsafe deserialisation, or privilege misuse?
• Does the execution role expose a bigger AWS foothold than the function needs?
• Are secrets hardcoded in function code, environment variables, or deployment artefacts?

For Lambda-focused testing, I usually combine application and cloud review:

• Inspect request validation at the entry point, often API Gateway or an event source
• Review the function’s execution role and any downstream calls
• Test for unsafe handling of headers, JSON bodies, path parameters, or file payloads
• Check dependency risk and stale packaged libraries during code-aware review

In event-driven systems, one of the easiest mistakes to miss is trusting the source implicitly. A function that assumes an event came from an internal service may accept attacker-controlled data if the upstream path is weaker than expected.

This is also where modern architecture blind spots appear. A Lambda might be doing light access control before calling Supabase or Firebase with high-privilege credentials. If the function exposes an unguarded route or weak object-level authorisation, the primary impact sits in the downstream data plane. Traditional AWS pentest checklists often stop at the function and never validate whether the backend data rules enforce the intended boundaries.

API Gateway and authorisation bypass

API Gateway can look tidy in diagrams and messy in reality. I’ve repeatedly seen routes with inconsistent auth requirements, undocumented stages, debug methods left exposed, and stale mappings still reachable after a release.

Useful testing patterns include:

• Compare authenticated and unauthenticated responses across routes and methods
• Probe stage-specific endpoints and forgotten versions
• Manipulate path parameters, resource IDs, and method overrides
• Test claims-based access control with multiple user roles
• Examine CORS behaviour for unsafe origin patterns and browser-reachable abuse

This isn’t glamorous work. It’s comparative work. You’re looking for inconsistency.

A healthy API estate behaves predictably. A weak one reveals small differences between routes that tell you where developers bolted on auth after the fact.

CloudFront and origin bypass

CloudFront issues are usually design issues. The interesting question is whether the CDN is your control plane or just a cache in front of something still directly reachable.

Test for:

• Direct origin access that bypasses expected controls
• Differential behaviour across cache keys and headers
• Sensitive files cached or exposed unexpectedly
• Alternate paths to private content through misrouted behaviours

A common mistake is assuming “served through CloudFront” means “protected by CloudFront”. If the origin accepts direct traffic, or if path rules send requests somewhere less protected, the edge isn’t enforcing much.

A practical service-by-service view

| Service | High-value test focus | Typical mistake | |---|---|---| | IAM | Assume-role chains, pass-role abuse, hidden privilege escalation | Reviewing policies without building attack paths | | S3 | Public access, object listing, write abuse, leaked artefacts | Only checking bucket publicity | | EC2 | Metadata access, host secrets, role harvest, lateral movement | Treating host review as generic server scanning | | Lambda | Invocation control, execution role misuse, unsafe event handling | Ignoring downstream data-plane impact | | API Gateway | Auth inconsistency, IDOR-style access, weak route protection | Testing only the happy path | | CloudFront | Origin bypass, cache behaviour, direct access paths | Assuming the CDN is the security control |

What works and what wastes time

What works in real engagements:

• Pair AWS CLI with manual reasoning
• Use Pacu for IAM path discovery, then verify manually
• Review application logic alongside cloud configuration
• Test with multiple user roles
• Prove impact with non-destructive chains

What wastes time:

• Blanket scanner output with no service context
• Treating all public resources as equal severity
• Ignoring temporary credentials and service identities
• Stopping at infrastructure when the business logic sits downstream
• Forgetting that Lambda and API Gateway often front non-AWS backends where the exposure lives

The best aws penetration test behaves like an attacker, but with restraint. It doesn’t just identify a weak setting. It shows how that weak setting becomes access.

Documenting Evidence and Crafting Actionable Reports

A finding that can’t be reproduced is noise. A finding with no business impact is backlog filler. A finding with weak evidence gets challenged, delayed, and often ignored.

That’s why reporting quality matters as much as exploitation quality.

Collect evidence that proves the point

Your evidence should answer four questions without requiring a meeting:

• What was tested
• What exact steps reproduced the issue
• What result confirmed the flaw
• Why the result matters

For cloud findings, screenshots alone are weak. Better evidence includes the exact AWS CLI command used, the request sent, the relevant response fragment, the role or identity context, and a minimal proof of access.

If the issue is a writable bucket, don’t upload sensitive data. Create a benign marker file if permitted. If the issue is unauthorised record access through an API, retrieve only the minimum safe sample needed to prove the boundary failure.

Good evidence is restrained. It proves access without creating clean-up work, regulatory headaches, or arguments about tester judgement.

Write the finding the way engineers and leaders need it

The same flaw needs two different readings. Leadership needs the business risk. Engineers need the reproduction path.

A poor finding usually looks like this:

S3 bucket misconfiguration allows public access. Severity high. Recommend restricting bucket permissions.

It’s technically true and operationally unhelpful.

A stronger version is specific:

The uploads bucket allowed unauthenticated object listing and read access during testing. Using an unsigned request, it was possible to enumerate filenames and retrieve stored customer-submitted files. The issue increases the risk of data exposure and could also reveal internal naming conventions used by downstream processors. Reproduction used non-destructive reads only. Remediation should remove public listing, review object-level access policy, and confirm CloudFront or application-layer controls are not relying on bucket exposure.

That gives the reader a path to action.

Use an evidence structure that scales

For each finding, include a short table like this:

| Element | What to include | |---|---| | Summary | One sentence describing the issue | | Affected asset | Service, endpoint, role, bucket, or function | | Preconditions | Auth level or starting access required | | Reproduction | Ordered steps with commands or requests | | Evidence | Response excerpts, logs, or screenshots | | Impact | Business and technical consequence | | Remediation | Targeted fix, not generic advice |

This structure keeps reports consistent without making every finding read like a template.

External-only reports often miss the underlying problem

One reason evidence quality matters is that pure perimeter testing can understate risk. In cloud contexts, pentesters have breached internal perimeters in most tested UK firms, while external “outside-in” breaches had limited success in one to two week tests, according to these penetration testing statistics.

That shouldn’t be read as “external testing doesn’t matter”. It means limited external windows often don’t reflect how attackers behave after they gain one foothold. Your report needs to make that clear when a finding starts from assumed breach, compromised credentials, or internal role abuse.

Contrast weak and strong reporting

A weak report says:

• Issue exists
• Severity assigned
• Generic remediation attached

A strong report says:

• Starting position used by the tester
• Exact path from access to impact
• Minimum proof collected safely
• Business consequence in plain language
• Fix owner and likely remediation point

If you want a good benchmark for how findings should be structured for both technical and non-technical readers, this guide to pen test reports is worth reviewing before you finalise your own format.

Report for remediation, not applause

The best pentest reports aren’t dramatic. They’re clear.

They identify whether the flaw belongs to platform engineering, application engineering, identity management, or product architecture. They note where a compensating control partly reduces impact. They avoid inflated language. And they make retesting straightforward.

That’s how a report earns trust. Not by sounding severe, but by being hard to dispute and easy to act on.

Implementing Fixes and Building a Continuous Security Loop

A pentest report only improves security if the findings get fixed in the right order. That order rarely matches severity labels perfectly.

A medium-severity issue on an admin API that controls billing, deployment, or customer data often deserves faster action than a technically higher-rated flaw on an isolated asset. Teams that remediate well use severity as one input, not the whole decision.

Prioritise by exploit path and business impact

Start by grouping findings into remediation tracks:

• Immediate containment
  Rotate exposed credentials, remove public access, tighten trust policies, disable unused routes, and add temporary detection where needed.

• Structural fixes
  Refactor IAM roles, narrow resource policies, harden API authorisation, enforce metadata protections, and reduce direct origin exposure.

• Engineering backlog
  Dependency clean-up, safer defaults in IaC, stronger validation logic, and code hygiene issues that matter but don’t need same-day action.

This is also where cloud and application layers need to meet. If API Gateway and Lambda are brokering access to Supabase, Firebase, or another managed backend, your remediation loop should include the data access rules and exposed client secrets behind those calls. Fixing the AWS edge but leaving weak downstream authorisation in place only moves the weakness.

Put fixes into delivery, not into a slide deck

The teams that improve fastest don’t treat remediation as a separate security project. They push findings into normal engineering flow.

That usually means:

1. Create tickets with reproduction steps
2. Assign one technical owner per finding
3. Add acceptance criteria for the fix
4. Retest the exact path that proved the issue
5. Capture the closed-loop evidence

If your tickets only say “harden IAM” or “secure S3”, you’re setting your engineers up to guess. A good remediation ticket names the affected role, policy statement, route, function, or bucket behaviour.

Security debt shrinks when developers can see the failing path, patch it, and verify the result in the same workflow they already use to ship code.

Add repeatable checks to CI and deployment

Point-in-time testing is useful, but drift is constant in AWS. New roles appear. A bucket policy changes. A route gets added without the expected authoriser. A Lambda deployment brings in a stale dependency or new secret handling issue.

That’s why continuous checks matter more than a once-a-year exercise.

Useful places to automate:

• Infrastructure changes with policy checks on IAM, S3, API Gateway, and networking
• Application deployments with authenticated testing against key routes
• Serverless releases with validation of execution roles and exposed handlers
• Mobile and frontend builds with secret and endpoint review before release
• Regression testing after remediation to confirm the original path is gone

For teams formalising that process, this guide to automated pen testing is a practical reference point for turning ad hoc testing into something repeatable.

Use on-demand testing where it fits

Manual pentesting still matters. It finds chains, edge cases, and business logic flaws that template-driven workflows miss. But manual testing alone doesn’t scale well across fast-moving estates.

AWS announced the general availability of a new security agent, offering autonomous multicloud pentesting across AWS, Azure, GCP, and on-premises at reduced costs, in response to the broader cloud incident rate among companies. The key operational shift is frequency. More teams can run testing on demand instead of waiting for a yearly slot.

That doesn’t replace human judgement. It changes where human judgement is best spent. Use automation for breadth, regression, and faster validation. Use manual testing for chained exploitation, architecture abuse, and the awkward edge cases where cloud controls meet application logic.

A mature loop often looks like this:

| Stage | Human-led | Automated | |---|---|---| | Initial deep assessment | Strong fit | Partial fit | | Release-by-release regression | Limited | Strong fit | | Broad portfolio coverage | Expensive manually | Strong fit | | Complex business logic abuse | Strong fit | Limited | | Revalidation after fixes | Useful | Strong fit |

If ransomware resilience is part of your remediation track, these AWS ransomware prevention strategies are worth reviewing alongside your pentest output, especially where backups, immutability, identity hardening, and recovery paths intersect with cloud findings.

The teams that get the most value from an aws penetration test don’t stop at “passed” or “failed”. They build a loop. Test, fix, retest, automate what repeats, and reserve human attention for the paths that still require a skilled attacker mindset.

---

If your stack includes Supabase, Firebase, mobile apps, or modern backend patterns that classic AWS guides often gloss over, AuditYour.App is built for that gap. It helps teams find exposed RLS rules, unprotected RPCs, leaked API keys, hardcoded secrets, and other high-impact issues quickly, whether you need a one-off audit certificate or continuous scanning as part of your release process.