On this page
Moving workloads to the cloud? We test your accounts, subscriptions and projects end to end, from the internet-facing edge to the IAM paths behind it.
Cloud breaches rarely start with an exotic exploit. They start with a key committed to a repository, a storage bucket someone made public “for a minute”, or a role that was given admin rights because the right permissions were hard to work out. A good cloud pentest looks for exactly those things, and then shows how far an attacker could get with them.
The shared responsibility model, in one paragraph
The provider secures the physical data centres, the hypervisors and the managed service platforms. You secure what you build and configure: identities, roles, network rules, storage permissions, operating systems on virtual machines, containers, application code and data. A cloud penetration test covers your side of that line. You never test the provider’s own infrastructure, and you never touch other customers.
What AWS, Microsoft and Google allow
- AWS
- No prior approval for permitted services. DoS, flooding, Route 53 zone walking and subdomain or S3 bucket takeover are prohibited. Red team, phishing and C2 activities need a Simulated Events form at least two weeks ahead.
- Microsoft Azure
- No pre-approval or notification. Follow the Microsoft Cloud Penetration Testing Rules of Engagement, stay inside your own tenant, and do not run DoS tests.
- Google Cloud
- No need to contact Google. Testing must comply with the Acceptable Use Policy and Terms of Service and affect only your own projects.
AWS
AWS publishes a list of services you can test without asking first. It includes EC2, NAT gateways and Elastic Load Balancing, RDS and Aurora, CloudFront, API Gateway, AppSync, Lambda and Lambda@Edge, Lightsail, Elastic Beanstalk, ECS and Fargate, OpenSearch Service, FSx, Transit Gateway and Global Accelerator.
AWS prohibits denial-of-service and simulated DoS attacks, port, protocol and request flooding (including login and API request flooding), DNS zone walking, hijacking and pharming through Route 53, and S3 bucket or subdomain takeover. DDoS simulations and stress tests have their own policies. Covert red team exercises, command-and-control hosting, simulated phishing and malware testing need a Simulated Events request submitted at least two weeks before the start date.
Microsoft Azure
Microsoft dropped its pre-approval requirement years ago. You do not need to notify Microsoft, but your testing must follow the Microsoft Cloud Penetration Testing Rules of Engagement. In short: test only your own tenant and resources, no denial-of-service testing, no attacks on other tenants, no social engineering of Microsoft staff. DDoS resilience is tested through Microsoft-approved simulation partners, not by your pentest provider.
Google Cloud
Google states that customers do not need to contact it before testing their own Google Cloud infrastructure. The testing must comply with Google Cloud’s Acceptable Use Policy and Terms of Service, and must only affect your own projects.
SaaS is different
These rules cover infrastructure and platform services you run. Testing a third-party SaaS product (your CRM, your email platform) needs that vendor’s permission. Test your own configuration of it, such as SSO, sharing settings and API tokens, rather than the vendor’s platform.
What a cloud penetration test should cover
Identity and access
Over-permissive roles, privilege escalation paths, long-lived access keys, unused admin accounts, weak MFA and cross-account trust that is broader than intended.
Storage and data
Public or cross-account access to S3 buckets, Azure Blob containers and Cloud Storage, unencrypted snapshots and database backups shared too widely.
Network exposure
Security groups and firewall rules exposing SSH, RDP, databases and admin panels to the internet, and flat internal networks.
Compute and containers
Instance metadata abuse through SSRF, container escapes, Kubernetes RBAC on EKS, AKS and GKE, and exposed dashboards.
Serverless and APIs
Lambda and Cloud Functions with broad execution roles, API Gateway authorisation gaps and secrets in environment variables.
Detection and logging
Whether CloudTrail, Azure Activity Logs and Cloud Audit Logs are on everywhere, retained, and would actually catch the attack path we used.
The attack paths we see most often
- SSRF to the metadata service. A web feature that fetches URLs is tricked into calling the instance metadata endpoint and returns temporary credentials. On AWS, enforcing IMDSv2 closes the easy version of this.
- A leaked key with too much power. An access key in a public repository, a mobile app or a CI log, attached to a user or role that can do far more than it needs.
- Privilege escalation through IAM. A role that can create or modify policies, pass roles to new compute, or update a function’s code, which is often enough to become admin.
- Public storage. A bucket or container opened for a quick file share and never closed, holding backups, exports or logs with personal data.
- Exposed management interfaces. Databases, Kubernetes dashboards and admin consoles reachable from the internet because a rule allowed 0.0.0.0/0.
Small details matter too. Our walkthrough on removing the server header from an AWS load balancer is a good example of the hardening findings that come up alongside the big ones.
Configuration review vs penetration test
| Configuration review | Penetration test | |
|---|---|---|
| Question it answers | Are settings in line with a benchmark? | What could an attacker actually reach? |
| Method | Read-only access, automated checks against CIS or provider benchmarks, manual review | Exploitation from the outside and from an assumed-breach foothold |
| Typical output | List of misconfigurations by severity | Attack paths, evidence and business impact |
| Best for | Broad coverage and hygiene | Proving real risk and prioritising fixes |
The strongest engagements combine both: a read-only review across every account for coverage, then targeted exploitation of the paths that matter.
How to scope a cloud pentest
- List accounts, subscriptions and projects. Include production, staging and any “temporary” accounts that still hold data.
- Choose the starting points. External only, assumed breach (for example a low-privilege user or a compromised workload), or both.
- Provide read-only access for the review. A security-audit role on AWS, Reader and Security Reader on Azure, or Viewer and Security Reviewer on Google Cloud.
- Agree the rules of engagement. Test windows, prohibited actions, contacts and how to stop the test if something breaks.
- File provider requests where needed. For example the AWS Simulated Events form for red team or phishing activities.
- Plan the retest. Book it before testing starts so the fix-and-verify step does not slip.
If you operate in Saudi Arabia, the NCA’s cloud controls add their own expectations; see our guide to NCA CCC cloud cybersecurity controls testing.
How Summit tests cloud environments
Summit’s cloud security assessment combines a read-only configuration review across AWS, Azure and Google Cloud with hands-on exploitation of the attack paths that matter. We test the applications and APIs you host in the cloud, the network exposure around them, and the identity layer that ties it together. Every finding comes with evidence, a fix written for your platform and a retest.
Find the path before an attacker does
Tell us which clouds and accounts you run. We will scope the test, follow each provider’s rules and show you exactly how far an attacker could get. Get a quote.
Related reading: AI and LLM application security testing · Types of penetration testing · API penetration testing checklist
Frequently asked questions
Do I need permission from AWS to run a penetration test?
Not for the services on AWS's permitted list, which includes EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS and Fargate, among others. Denial of service, flooding, Route 53 zone walking and subdomain or S3 bucket takeover are prohibited, and red team, phishing and C2 activities need a Simulated Events request at least two weeks in advance.
Do I need to notify Microsoft before testing Azure?
No. Microsoft no longer requires pre-approval or notification, but testing must follow the Microsoft Cloud Penetration Testing Rules of Engagement. You may only test your own tenant and resources, and denial-of-service testing is not allowed.
Do I need to notify Google before testing Google Cloud?
No. Google says customers do not need to contact it before testing their own Google Cloud projects, as long as the testing follows the Acceptable Use Policy and Terms of Service and only affects your own projects.
What is the difference between a cloud penetration test and a cloud configuration review?
A configuration review checks settings against a benchmark such as CIS. A penetration test goes further and tries to exploit weaknesses, chaining issues such as an exposed service, a leaked key and an over-permissive role to show what an attacker could actually reach.
What do cloud penetration tests usually find?
Over-permissive IAM roles and privilege escalation paths, long-lived access keys, publicly readable storage, exposed management ports and databases, server-side request forgery to the metadata service, secrets in code or environment variables, and gaps in logging.
How long does a cloud penetration test take?
A single account or subscription with a handful of applications typically takes one to two weeks. Multi-account organisations, Kubernetes clusters and hybrid networks take longer.
