Cloud Penetration Testing: What It Is and What Is Allowed

Cloud penetration testing is frequently scoped as though the cloud were simply someone else's data centre. It is not. The provider secures the infrastructure; you secure your configuration, identities and workloads — and the interesting findings almost always sit on your side of that line.

The shared responsibility model decides scope

Every major provider divides responsibility. They secure the physical infrastructure, the hypervisor and the managed service platform. You are responsible for how you configure services, who can access them, and the security of what you deploy.

That division is not decorative — it defines your legitimate testing scope. Attacking the provider's infrastructure is both out of scope and generally prohibited. Testing your own configuration, identities, workloads and applications is exactly what should be assessed.

What providers permit

Major providers now permit customer-initiated penetration testing against their own resources without prior approval for most common services, subject to published rules.

The constraints are consistent across providers: no denial-of-service or stress testing, no testing of resources you do not own, and restrictions around certain shared or managed services. Some activities still require notification. Because these policies change, the current published policy for your provider should be read at scoping time rather than assumed from a previous engagement — and the relevant rules should be referenced in your rules of engagement.

What actually gets found

• Over-permissioned identities and escalation paths — consistently the highest-impact category.
• Exposed storage — buckets and blobs readable or writable more broadly than intended, still one of the most common findings.
• Metadata service exposure via SSRF — an application flaw that yields workload credentials.
• Overly permissive network rules — management ports open to the internet, or internal ranges permitted far more broadly than necessary.
• Unmanaged and forgotten resources — test environments with production data, or assets left running after a project ended.
• Weak or missing logging — control-plane logging disabled or retained too briefly to investigate.
• Secrets in accessible places — credentials in environment variables, user data scripts, repositories or CI configuration.

Configuration review versus penetration testing

These are complementary and frequently confused. A configuration review reads your cloud environment against a benchmark and reports deviations — broad coverage, systematic, effective at finding drift.

A penetration test attempts to chain findings into real impact: taking that over-permissioned role and demonstrating what it actually reaches. Most organisations benefit from a configuration review first, because it removes the obvious issues cheaply and lets the manual testing focus on paths that require human reasoning.

Scoping a cloud engagement

1. Enumerate the accounts, subscriptions or projects in scope, and confirm ownership of each.
2. Decide whether testing is external only, or includes an assumed-breach starting point with credentials — the latter usually produces far more actionable findings.
3. Read the current provider testing policy and record it in the rules of engagement.
4. Identify managed services in scope and any provider-specific restrictions on them.
5. Agree explicitly that denial-of-service testing is excluded.
6. Establish escalation contacts and a testing window, since cloud alerting may page an on-call engineer at 3am.
7. Confirm whether the application layer is in scope, as cloud infrastructure testing and application testing are different exercises.

Related from TechBiz Security

• Cloud security assessment
• Penetration testing
• Penetration Testing: The Complete Guide

Sources & further reading

• AWS — Penetration Testing policy
• Microsoft — Penetration testing rules of engagement
• NIST SP 800-115 — Technical Guide to Information Security Testing
• CIS Benchmarks

Frequently asked questions