Cloud Pen Test Basics: AWS, Azure and Google Cloud Rules

On 18 October 2026 the AWS penetration testing page lists the services customers may test without prior approval, among them EC2, RDS, Aurora, CloudFront, API Gateway, AppSync, Lambda, Elastic Beanstalk, ECS and Fargate. It also names activities you may never perform, and anything outside the list means contacting AWS Support or your account representative.

Enterprise customers increasingly ask whether your cloud environment, not just your application, has been tested. Before you agree to that, know the rules of the platform you run on.

What's affected

Teams hosting on a public cloud who are about to scope a test that includes infrastructure. The three big providers handle it differently:

• AWS allows testing of your own resources on the listed services without approval. Prohibited: DNS zone walking, hijacking and pharming through Route 53, DoS and DDoS including simulated ones, port, protocol and request flooding, and S3 bucket and subdomain takeover. Tests that include command and control need prior approval. Red, blue and purple team exercises, simulated phishing and malware testing require a Simulated Events form submitted at least two weeks ahead.
• Microsoft encourages testing of your own tenant and assets but prohibits DoS, social engineering and post exploitation actions, and forbids testing other customers' data or using credentials you do not own.
• Google Cloud says you do not need to notify it, as long as testing follows its acceptable use policy and affects only your own projects.

The PCI Security Standards Council guidance adds a scoping principle: where a service agreement requires third party approval, get it first, and do not include the provider's own infrastructure in the scope. Test what you manage, build or use.

How to check if you're exposed

Run three quick checks yourself before the engagement. They find the findings a tester would otherwise bill hours to report.

# 1. Any security group open to the whole internet?
aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].[GroupId,GroupName]' --output table

# 2. Is public access blocked on a given bucket?
aws s3api get-public-access-block --bucket my-example-bucket

# 3. Is MFA enabled for the root account?
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

Read each result against intent. An open security group on port 443 for a load balancer is normal. The same rule on a database port is not.

What to do now

1. Decide whether the test covers the application only, or also your cloud configuration. Write it into the scope.
2. Read your provider's current policy page and attach the relevant lines to the rules of engagement.
3. Create a dedicated test account or sandbox that mirrors production, and give the tester least privilege read access for a configuration review.
4. List services in use and compare them with the provider's no approval list. Anything else needs approval first.
5. Ban the prohibited activities in writing, especially request flooding. A tester hammering your login endpoint is request flooding as AWS defines it.
6. Rotate any credentials you hand over, and remove access when testing ends.

How to avoid this trap

• Do not accept a tester's generic template without checking it against the provider policy.
• Do not scope the provider's own services. Customers are not permitted to assess AWS infrastructure itself.
• Do not assume the policy is permanent. These pages change, so check the date you sign.
• Do not forget subdomains. Takeover testing is prohibited on AWS, but abandoned DNS records are a real risk you should clean up yourself.

Why it matters

The shared responsibility split decides what a cloud test means. The provider secures its platform and you secure your configuration: identities, network rules, storage permissions and the applications you deploy. A cloud test for a small company is mostly a configuration review plus application testing, and the policy pages tell you where the lines are.

Try it yourself

Run the three CLI checks above in your own account and write down any result you cannot explain. Each unexplained line is a question for your first cloud review.

Quick check

Sources

• AWS Penetration Testing policy
• Microsoft Cloud Penetration Testing Rules of Engagement
• Google Cloud penetration testing policy
• PCI Security Standards Council, Information Supplement: Penetration Testing Guidance v1.1 (September 2017)