Cloud penetration testing looks different from a standard network test. The risk sits in identity and access management, not firewalls. AWS, Microsoft Azure, and Google Cloud all let you test your resources without asking first. However, you just must stay inside their published rules.
Cloud penetration testing exists because of a split some teams only learn about the hard way.
AWS (Amazon Web Services), Azure, and GCP (Google Cloud Platform) secure the physical infrastructure and the core managed services running underneath your workloads. You're still responsible for how you configure identity, storage, and network access on top of that. That's the part a traditional network test was never built to catch.
Our cloud audit work starts from that split, not from a generic checklist. Below is how we structure a cloud engagement and what AWS, Azure, and GCP let you test.
How Cloud Penetration Testing Differs From Network Testing
A traditional network penetration test maps what's reachable from outside a perimeter. Then it tests firewalls, exposed ports, and gateway devices.
Cloud environments don't work that way. AWS, Azure, and Google Cloud each operate on a shared responsibility model. The provider secures the physical data centres, the hypervisor, and the core managed services.
You own everything you configure on top of that. That usually means IAM (Identity and Access Management) roles, storage bucket permissions, network security groups, and how your services trust each other.
Most cloud breaches don't start with a firewall failure. They start with a role that has more access than it needs, or a storage bucket left open by default. Sometimes it's just a credential that ends up somewhere it shouldn't.
Cloud penetration testing is built to find those gaps before someone else does.
How a Cloud Pentest Is Structured
The phases look familiar on paper: scoping, reconnaissance, exploitation, and reporting. What differs is where the depth goes.
- Scoping defines which accounts, subscriptions, or projects are in play and which services inside them matter most.
- Recon maps the environment. IAM roles and policies, storage configuration, network topology, and how services trust each other.
- Exploitation is where a cloud penetration tester tries to move from a low-privilege foothold to something important. That means chaining permissions that look reasonable on their own into a path that shouldn't exist.
Take a standard developer role as an example. A scanner checks that role and sees it can't touch the production database directly. It marks the role as safe and moves on. But the same role might also have permission to modify an EC2 instance profile. That single extra permission lets someone attach a far more privileged role to a server they already control, sidestepping the database restriction.
Nothing about either permission looks dangerous on its own. Only someone tracing how they connect will catch it. Spotting it takes a person working through how the pieces connect.
- Reporting closes the loop with what was found, how it was reached, and what to fix first.
Our cloud audits run as white-box engagements for this reason. A static checklist doesn't hold up across three providers, each with its own permission model and its own edge cases.
How SSRF Turns Into Stolen Cloud Credentials
Every major cloud provider runs an instance metadata service. It's a small internal API (Application Programming Interface) that hands a virtual machine its own configuration data, including temporary IAM credentials tied to that specific instance. It's meant to be reachable only from inside the instance itself.
If an application on that instance has an SSRF (server-side request forgery) flaw, an attacker can get it to make that internal request on their behalf. The app fetches the credentials and hands them over. From there, the attacker can use the credentials from their machine to reach whatever that instance's role is allowed to touch.
This is why the version of the metadata service is crucial during testing.
Older instance metadata (AWS calls its version IMDSv1) answers simple requests with no extra checks, which makes it an easy target for SSRF. The newer version, IMDSv2, requires a session token fetched through a separate request first. Most basic SSRF flaws can only trigger a simple request. They can't complete that extra step, so IMDSv2 shuts down a large share of these attacks before they start.
Testing checks two things:
- Whether an app exposes this path at all, and
- Whether the account enforces the newer, safer version rather than just supporting it.
The same chaining logic shows up in storage. A storage bucket can be locked down correctly on paper. But if the app reading from that bucket has an SSRF flaw, the request to the bucket comes from inside your infrastructure.
The bucket's permissions were never built to question that. This is the kind of gap that only shows up once a pentester links the app's flaw to what it's allowed to reach. It's a big part of why this work stays manual rather than automated.
Testing Serverless Functions
Serverless setups, like AWS Lambda or Azure Functions, run your code without you managing a server underneath it. That's convenient, but it changes what needs testing. These functions run on event triggers. So if an attacker can manipulate the data that triggers one, they can influence what that function does.
Say a function processes an uploaded file without properly checking its contents first. An attacker can use that entry point to inject commands the function was never meant to run.
Cloud pentesting also reviews the permissions given to the function itself. A function built to read one file sometimes ends up with a role that can delete an entire storage bucket. It's easier to grant broad access than to scope it precisely, so that's what happens by default.
Catching that kind of over-permissioned function stops one compromised piece of code from reaching far beyond its job.
What AWS Permits Without Prior Approval
AWS lets you test your resources across a defined list of permitted services without asking first. That list covers the services most engagements touch, including:
- EC2 instances
- RDS databases
- CloudFront
- Lambda functions
- Load balancers
A few things stay off-limits regardless. That means denial-of-service attempts and DNS zone walking or hijacking through Route 53. It also rules out any attempt at S3 bucket or subdomain takeover.
Covert red-team activity or Command and Control tooling needs sign-off first. AWS requires a Simulated Events form submitted at least two weeks ahead of the test. Anything outside the permitted list needs a conversation with AWS Support first.
What Microsoft Azure Permits Without Prior Approval
Microsoft hasn’t required pre-approval for pentesting on Azure resources since June 2017. Notification is optional, but every test still has to follow Microsoft's Cloud Unified Penetration Testing Rules of Engagement.
Third parties running the test on your behalf must have your written authorisation, as stated in your service agreement. Microsoft won't grant that authorisation on your behalf.
DDoS testing is prohibited outright. Cloud pentesters also can't touch credentials that aren't theirs, even ones leaked publicly. Azure also runs automated abuse detection, so a fully authorised test may be flagged. Keeping your authorisation documentation on hand can clear this up quickly if it happens.
What Google Cloud Permits Without Prior Approval
Google doesn't require notification before you test your own GCP projects.
You must still follow the Cloud Platform Acceptable Use Policy and Terms of Service. Your testing also has to stay inside projects you own, rather than touching other customers' environments.
If a test turns up a genuine vulnerability in Google's infrastructure, rather than you configuring it, stop. Report it through Google's Vulnerability Reward Program instead of continuing to probe it.
Reporting, Retesting, and What’s Often Combined With a Cloud Audit
Reporting and retest timelines depend on scope. What matters more than a fixed schedule is that findings get prioritised by real exploitability, not a generic severity label. Retesting happens once fixes are in place, rather than on a fixed calendar.
A cloud engagement is rarely a standalone activity. If your cloud infrastructure sits behind a web application, testing the two together gives testers a clearer picture. The same applies to a code audit. Reviewing the source code alongside the infrastructure catches issues that are hard to find from either angle by itself.
Get Your Cloud Environment Reviewed by Someone Who Knows Where to Look
Our cloud audits are white-box from the start. We build each one around your actual environment, not a generic checklist run against AWS, Azure, or GCP in isolation. We map the permission paths, misconfigurations, and trust relationships that matter for your setup. Then we give you a report you can use right away.
Book Your Cloud Audit Consultation
Common Questions About Cloud Penetration Testing
Does a Cloud Pentest Cover the Applications Running in the Cloud or Just the Infrastructure?
On its own, a cloud audit covers the infrastructure layer: IAM, storage, networking, and configuration. The application code and logic running on top of that infrastructure need a separate test. That's why cloud and web app testing get scoped together so often.
What Happens if My Cloud Pentest Trips a Provider's Abuse Detection?
- AWS forwards any abuse reports it receives straight to you, so you can respond with your authorisation details.
- Azure runs automated abuse detection and can interrupt activity mid-test, even when it's fully authorised. Keep your documentation accessible throughout the engagement.
- Google's policy is simpler. As long as you stay inside your own projects and follow the Acceptable Use Policy, this shouldn't come up.
Does Cloud Penetration Testing Cover Kubernetes and Containers?
It does, as long as they are part of your environment. That includes managed services like EKS on AWS, AKS on Azure, and GKE on Google Cloud. Testing looks at cluster role bindings (RBAC), pod security settings, and how the cluster ties back into your broader IAM setup. It sits inside the same review as the rest of a cloud audit. It doesn't need a separate engagement.
Can I Test a Multi-Cloud Setup in One Engagement?
You can, though the scoping call needs to account for each provider separately. AWS, Azure, and GCP each have their own permission rules and prohibited activities. The methodology stays consistent across providers. The paperwork and permitted-activity list don't.
Will Testing Cause Downtime for Our Live Applications?
It shouldn't. Testing windows are agreed during scoping, so nothing runs against production without your knowledge. If a cloud penetration tester finds an attack path that could genuinely break something live, we don't just run it to see what happens. We document the risk and talk it through with your team before attempting anything that could cause damage.
How Do You Test Managed Services Like RDS or Azure SQL if You Can't Touch the Underlying Servers?
We test what you control, not what the provider controls. For a managed database or similar service, that means the access controls, the network rules around it, and how your applications authenticate to it. The provider handles patching and physical security for the service itself, so that part sits outside the test. What's yours to configure is what we test.
Scope a Cloud Pentest Around What Your Environment Looks Like
No two cloud environments are built the same way, so we don't run the same test twice. A free scoping call tells us which accounts, services, and providers are in play. From there, we build the engagement around your actual architecture.
Start Your Cloud Scoping Call
Want to Read More?
- Ready to move from reactive defence to proactive security? Read about how Cloud Threat Hunting can help you identify hidden threats before they compromise your environment.
- If you aren't sure where your cloud vulnerabilities lie, learn about Cloud Security Assessments to make sure your infrastructure isn't exposing critical data.
- Infrastructure is only half the battle. To secure your apps from the inside out, see how our Code Audit methods are ready to help.
