Penetration Testing in the Public Cloud: Shared Responsibility, Rules and Limits

Moving workloads to the public cloud changes not just operations but testing too. A penetration test in AWS, Azure or Google Cloud follows different rules than in your own data centre — because the infrastructure isn’t yours. Ignore that and you risk, at best, a worthless test and, at worst, a breach of the provider’s terms of use.

Service Models Define the Scope

How far a test may reach depends on the service model:

• IaaS — infrastructure components (servers, storage, networking): the largest testable area
• PaaS — development and runtime environments on the provider’s infrastructure
• SaaS — finished applications: here almost everything is the provider’s responsibility

The Shared Responsibility Model

The shared responsibility model is the key concept. Provider and user share responsibility for security — and the split shifts with the service model. The provider owns physical security, the hypervisor layer and platform compliance. You own configuration, identities, access control, data and everything you operate yourself.

The uncomfortable truth: the overwhelming majority of real cloud incidents arise not from a hacked hyperscaler but from misconfiguration on the customer side — open buckets, over-broad IAM rights, exposed management interfaces.

What’s Different About a Cloud Pentest

• White-box or grey-box is standard, to avoid accidentally accessing other tenants’ data.
• The provider’s terms of use are binding. AWS, Azure and GCP today largely permit testing without prior approval — but notification and adherence to the rules remain mandatory.
• Cloud-specific attack techniques differ from the classic approach: privilege escalation via IAM, metadata services, misconfiguration chains rather than buffer overflows.

The Most Important Conclusion

A cloud pentest is limited to the layers you control — and that’s almost always where the real risk sits. After every migration and every significant change, your own cloud environment should be tested.

How Cloud Cape Helps

We test cloud environments along the shared responsibility model — focused on what you own: IAM, configuration, exposed services and attack paths between cloud resources. Where continuous monitoring makes more sense than a periodic test, we combine it with our Continuous Threat Exposure Management.

Talk to us about Pentesting & Red Teaming — we test exactly the cloud layers that belong to you.