AWS vs Azure vs Google Cloud pen test rules

AWS vs Azure vs Google Cloud penetration testing rules: which set to plan around

The provider rules set the outer boundary of any cloud penetration test, so they should be read before the scope, tooling or tester is chosen. The three providers differ most on advance approval, on the services a tester may touch without asking, and on the tests they prohibit outright. AWS is the most prescriptive of the three in the material supplied. It lets customers run security assessments or penetration tests without prior approval against a listed set of services, including EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate, while testing that includes command and control needs prior approval. A team whose workloads sit mainly on AWS should map each system against that list first, because a component outside it changes the approval path and the schedule.

The two-week notice matters most when the exercise is a simulated event rather than a standard test. AWS requires a request at least 2 weeks ahead for red, blue or purple team testing and simulated phishing, so a red team plan with a fixed start date needs that lead time built into the calendar. AWS also prohibits DNS zone walking, denial of service, port, protocol or request flooding and S3 bucket or subdomain takeover, which removes several techniques a tester might otherwise use. Microsoft's Cloud penetration testing rules of engagement ban DDoS under all circumstances, phishing or social engineering of Microsoft employees, access to data or tenants the tester does not own, and network-intensive fuzzing. They also require vulnerabilities found in Microsoft services to be reported to MSRC. Azure-specific service lists and notice terms must be confirmed on Microsoft's page before the plan is fixed.

Google Cloud takes the most permissive position on notice, since customers do not need to notify Google before testing their own Google Cloud infrastructure. That does not remove limits. Tests must follow the Acceptable Use Policy and Terms of Service, and they must affect only the customer's own projects, so a tester who reaches a shared or third-party project has crossed the boundary. Provider permission also does not settle what is in scope for a configuration review. Under the AWS shared responsibility model, customer security depends on the services chosen and covers settings such as data, operating systems and firewall configuration, and the same division of labor applies in practice across providers. Combine provider rules with a red team plan when the exercise must simulate an adversary across identity, endpoints and people. Add a separate configuration review when the question is whether accounts match a benchmark. Confirm notice terms in writing with each provider before scheduling.

How the AWS, Azure and Google Cloud penetration testing rules compare

This table compares the three providers' published testing rules on approval, permitted services, prohibited activities, simulated events and reporting. Read each row as what the provider states publicly, then confirm the cells marked for verification before you scope a test, because the policies differ in form as well as content.

Rule	AWS	Azure (Microsoft Cloud rules of engagement)	Google Cloud
Prior approval	No prior approval needed for security assessments or penetration tests against the listed services, such as EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate. Command and control testing needs prior approval.	Microsoft publishes rules of engagement that testers must follow. Confirm in the current document whether any service or test type needs a separate request.	No notice to Google is needed before testing your own Google Cloud infrastructure. Tests must follow the Acceptable Use Policy and Terms of Service.
Permitted services	Testing is permitted without approval against the services AWS lists on its policy page. Services not on that list need checking before testing.	The rules describe testing of Microsoft cloud services in general. Verify each Azure service you plan to test against the current rules, because coverage is not a per-service list in the supplied material.	Permitted scope is your own projects. Tests must affect only resources in the projects you own.
Denial of service and flooding	Prohibited: denial of service and port, protocol or request flooding.	Prohibited under all circumstances: DDoS attacks.	Not addressed as a separate rule in the supplied material. Confirm with Google how load or stress testing is treated under the Acceptable Use Policy.
DNS zone walking and subdomain or bucket takeover	Prohibited: DNS zone walking and S3 bucket or subdomain takeover.	Not stated in the supplied rules. Confirm with Microsoft before testing DNS or domain-related behavior.	Not stated in the supplied material. Confirm with Google before testing DNS enumeration or storage takeover paths.
Fuzzing and intrusive testing	Not covered in the supplied AWS facts. Confirm with AWS before running intensive fuzzing against managed services.	Prohibited: network-intensive fuzzing.	Not covered in the supplied material. Confirm acceptable limits with Google under the Acceptable Use Policy.
Social engineering and phishing	Simulated phishing needs a request at least 2 weeks ahead, as part of simulated events such as red, blue or purple team testing.	Prohibited: phishing or social engineering of Microsoft employees.	No notice needed for infrastructure tests. Social engineering of Google staff is not covered in the supplied material, so confirm before planning it.
Accessing other tenants or data	Testing must stay within resources you own. Confirm the boundary for shared or third-party-managed services with AWS.	Prohibited: accessing data or tenants the tester does not own.	Tests must affect only your own projects.
Red team and simulated event notice	A request at least 2 weeks ahead is required for simulated events such as red, blue or purple team testing.	Not stated in the supplied rules. Confirm with Microsoft whether red team exercises need separate notice.	Not stated in the supplied material. Confirm with Google whether any red team activity needs notice beyond the standard policy.
Reporting duties	Not covered in the supplied AWS facts. Confirm with AWS what must be reported and how.	Vulnerabilities found in Microsoft services must be reported to MSRC.	Not covered in the supplied material. Confirm the disclosure route with Google before testing.

What each provider expects from you before and during a test

AWS separates the work it allows without asking from the work that needs a request. Security assessments and penetration tests against a published list of services can start without prior approval, but some activity, such as command and control testing, needs approval first. Because the policy is written around named services and specific techniques, the scope of your target services matters as much as the test method.

Services without prior approval: The published list includes EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate. Confirm the list on the policy page before scope is agreed, because a service that is not on it may need a different route.
Command and control needs approval: Any test that includes command and control infrastructure requires prior approval from AWS, so plan that request before the test window opens.
Two weeks for simulated events: Red, blue and purple team exercises and simulated phishing need a request at least 2 weeks ahead of the event.
Prohibited activities: DNS zone walking, denial of service, port, protocol or request flooding, and S3 bucket or subdomain takeover are not permitted in customer testing, so remove them from attack chains and runbooks.

Before scheduling, check the current service list and request timing against your test window, and confirm that no step in the plan involves flooding, zone walking or bucket takeover.

Which prohibited activities catch cloud testers out

Each provider restricts a different set of test activities, and the ones that catch testers out are often routine techniques used on the wrong target. The cards below cover the activities named in the supplied provider rules, the safer in-scope alternative for each, and what to confirm in writing before work starts.

Denial of service and flooding

Any test that generates volume can cross the line. AWS prohibits denial of service and port, protocol or request flooding in customer testing, and Microsoft prohibits DDoS attacks under all circumstances. A load or stress test run to find a rate limit can look identical to a flood. Use low-rate, bounded checks that confirm a control exists without measuring its breaking point, and confirm in writing whether any load testing is permitted at all.

DNS zone walking and subdomain takeover

Enumerating DNS records and claiming dangling subdomains are both prohibited on AWS. Zone walking and S3 bucket or subdomain takeover are excluded from customer testing, even though they feel like routine reconnaissance. A safer route is to list the subdomains the client owns and check for dangling records as a configuration finding, without registering or claiming any resource. Confirm which hostnames and buckets are in scope and whether the client wants takeover risk reported as a finding only.

Social engineering of provider staff

Phishing or pretexting Microsoft employees is off limits, even in a red team exercise. Microsoft's rules of engagement prohibit phishing or social engineering of its staff. Red team scenarios that rely on people often target the client's staff instead, which is allowed only if the client has authorized it and the scenario stays inside its own organization. Ask for written confirmation that no provider personnel are in the scenario, and that any simulated phishing against the client's own staff is agreed separately.

Network-intensive fuzzing

Fuzzing at high volume against a shared provider endpoint can affect other tenants. Microsoft's rules prohibit network-intensive fuzzing. A tester who points a broad fuzzer at a managed service may generate load that the provider treats as an attack, even when the intent is only to find parsing bugs. Limit fuzzing to the client's own application code running in the client's own environment, and confirm with the provider's current rules whether any fuzzing against platform endpoints is permitted.

Accessing data or tenants you do not own

Pivoting from a test account into another tenant or project is the most common project-boundary failure. Microsoft prohibits accessing data or tenants the tester does not own, and Google Cloud requires that tests affect only the customer's own projects. A credential found during testing may grant reach into a neighboring account, a shared service or a third-party tenant. Stop at the boundary, record the path without using it, and confirm in writing the exact accounts, subscriptions and projects in scope before any credentials are used.

How to plan a cloud penetration test within provider rules

This sequence turns each provider's published testing policy into a written scope that the tester, the account owner and the provider's rules all agree on before any traffic is sent. It ends with a rules of engagement record that shows which activities are allowed, which need notice or approval, and who receives the findings.

Confirm providers, accounts and projects in scope
The engagement owner lists every cloud provider, AWS account, Azure subscription and Google Cloud project that the test may touch, and names the person who has authority to approve each one. Shared or inherited environments, such as a landing zone or a third-party managed tenant, are flagged for separate sign-off. The output is a signed inventory that shows which resources belong to the client and which do not. Confirm the list with the account owner before testing begins.
Map each target service to provider status
The tester maps every target service against the provider's published policy. AWS publishes a list of services that customers may assess without prior approval, including EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate, so any service outside that list needs a closer read of the policy before it is scoped. Microsoft and Google Cloud publish rules that apply across their services, so the tester records which rules apply to each target. The output is a service-by-service table with the policy source and status for each row.
Flag activities that need approval or notice
The engagement owner reviews the planned techniques and marks any that need prior approval or advance notice. Under AWS policy, testing that includes command and control needs prior approval, and simulated events such as red, blue or purple team exercises and simulated phishing require a request at least 2 weeks ahead. Google Cloud states that customers do not need to notify Google before testing their own infrastructure, so the tester should confirm that its own notice obligations are met through the Acceptable Use Policy and Terms of Service. The output is a flagged list of techniques with the approval or notice route for each.
Write prohibited activities into the rules of engagement
The engagement owner and the tester record every prohibited activity in the rules of engagement so that they bind the test team. AWS prohibits DNS zone walking, denial of service, port, protocol or request flooding and S3 bucket or subdomain takeover. Microsoft prohibits DDoS attacks under all circumstances, phishing or social engineering of Microsoft employees, access to data or tenants the tester does not own, and network-intensive fuzzing. Google Cloud requires that tests affect only the customer's own projects. The output is a prohibited-activities section that the tester signs before the first scan.
Agree reporting routes for findings
The engagement owner and tester agree who receives findings, how they are classified and where vulnerabilities in provider-owned services go. Microsoft requires vulnerabilities found in its services to be reported to MSRC, so the tester must separate those findings from client configuration issues that the client fixes directly. The route for AWS or Google Cloud platform issues should follow each provider's own disclosure process, which the team should confirm before the test. The output is a reporting matrix with owners, channels and deadlines agreed in writing.
Record decisions in the NIST rules of engagement template
The engagement owner captures the scope, approvals, notice dates, prohibited activities and reporting routes in the rules of engagement template in Appendix B of NIST SP 800-115, then gets sign-off from the client and the tester. The template is a reference structure, not a provider approval, so a completed record does not replace a provider's policy or its approval process. Keep the signed record with the statement of work so that auditors and provider support can see what was agreed and when. Confirm any provider-specific requirement directly with the provider before testing starts.

What provider rules cover and what a penetration test still has to prove

Provider rules of engagement decide which services you may test and which attacks are off limits. They say nothing about whether your configuration, identities or detections are sound, so a compliant test is one input among several.

Rules set permission, not soundness

AWS, Microsoft and Google Cloud publish what a customer may test without asking first, but a permitted test does not validate the environment behind it. A tester who stays inside the rules can finish with no findings while a misconfigured storage bucket or an over-privileged role remains in place. Ask the provider's rules and your test scope side by side, and record which services fall outside the permitted list so they are not silently untested.

Customer owns configuration

Under the AWS shared responsibility model, AWS secures the cloud itself, while the customer secures what runs in it. That customer share depends on the services chosen and covers data, operating system and firewall settings. A penetration test that never reaches these settings cannot tell you whether they were set correctly, so confirm with your provider which configuration items your scope includes.

Detections need separate proof

A provider approving your test does not show that your monitoring would have caught it. CIS Safeguard 18.4 asks you to validate security measures after each test so that detections cover the techniques the testers used. Plan a step where the security operations team reviews the alerts generated during the engagement, and document which techniques produced no alert.

Identity gaps the policy-bound attacker misses

A tester working within provider rules may not reach identity paths such as overly broad roles, stale access keys or federated trust that expands access. These are often the most consequential cloud findings. Ask the provider for a test scope that names identity and access management explicitly, and confirm whether the tester may attempt privilege escalation within your own accounts.

Combine testing with configuration review

NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. A cloud configuration review checks account settings against benchmarks across every resource, while a penetration test proves which weaknesses are exploitable. Use the review to cover breadth and the test to cover depth, and schedule both against the same cloud accounts.

What you should expect to receive from a cloud penetration test

This table lists what a cloud penetration test file should contain under each provider's rules, from signed scope and service lists to provider notices and vulnerability reporting routes. Read each row as a request to the tester before work starts, and treat items marked to confirm as open questions for the provider or tester. The main takeaway: only Microsoft's supplied rules name a specific reporting route for flaws in provider services, so ask every provider for its route in writing.

Deliverable	AWS	Azure (Microsoft)	Google Cloud
Signed rules of engagement	Written scope that cites AWS's published penetration testing policy and the services tested. Confirm whether your contract requires a signed copy.	Written scope that cites Microsoft's cloud rules of engagement. Confirm the tester has signed acceptance before work starts.	Written scope limited to your own projects, since Google requires tests to affect only those. Confirm acceptance terms with the tester.
Services or resources tested	Named list checked against AWS's permitted services, such as EC2, RDS, Lambda, and ECS and Fargate. Flag any service not on the list.	Per-resource list of Azure services and tenants in scope. Confirm in writing that no tenant or data outside your ownership is included.	List of projects and resources in scope, confirmed as yours. Confirm how shared or third-party projects are excluded.
Evidence of activities run	Timestamped log of test activity. Command and control activity needs prior AWS approval, so the log should show it separately.	Log of activities, including any network-intensive fuzzing, so you can check it stayed within Microsoft's rules.	Log of actions by project, showing traffic and changes stayed within your own projects. Confirm log retention with the tester.
Prohibited-activity confirmation	Written statement that no DNS zone walking, flooding, or S3 bucket or subdomain takeover was attempted.	Written statement that no DDoS, phishing or social engineering of Microsoft staff, or access to tenants not owned, occurred.	Written statement that the Acceptable Use Policy and Terms of Service were followed. Confirm any further limits in the scope.
Validated findings	Each finding with reproduction steps and evidence the tester confirmed it manually. Scanner output alone is not a penetration test result.	Each finding with reproduction steps, severity method and evidence it was validated. Confirm the severity scale before testing.	Each finding with reproduction steps and evidence of validation. Confirm whether findings separate customer settings from provider-side issues.
Record of provider notice or approval	Copy of any AWS approval, and of the request for simulated events such as red team exercises, sent at least 2 weeks ahead.	Confirm whether any Microsoft notice applies to your scope. Keep a dated copy of the rules version you tested against.	No notice to Google is required for your own infrastructure. Keep a dated scope record showing the targets were your projects.
Reporting route for flaws in provider services	Confirm with AWS how to report a flaw in an AWS-owned service. Report it separately from customer findings.	Vulnerabilities found in Microsoft services must be reported to MSRC. Ask the tester to confirm this step in writing.	Confirm with Google the route for a flaw in a Google-owned service before testing begins.
Responsibility split in the report	Findings sorted by the shared responsibility model, separating customer configuration from AWS-managed controls.	Findings tagged by owner, so customer identity and configuration issues are not mixed with Microsoft service flaws.	Findings tagged as customer project issues or Google-managed platform items, with the owner confirmed by the tester.

What drives the cost and effort of a cloud test under provider rules

A cloud penetration test under provider rules costs more in preparation than in the test itself. The cards below separate the one-time approval and rules of engagement work from the items that recur with each retest, new service or simulated event, so you can ask for a quote that shows both.

Accounts, subscriptions and projects in scope

Each AWS account, Azure subscription or Google Cloud project in scope adds identity mapping, environment access, and separate evidence collection. Confirm whether the quote prices per account or per workload, and whether shared services such as central logging or a shared network sit inside the scope. Ask which of your tenants or projects the tester must not touch, since Microsoft's rules bar access to tenants the tester does not own.

Services needing prior approval or notice

AWS allows assessments without prior approval against a listed set of services, but testing that includes command and control needs prior approval. Google Cloud does not require notice for testing your own infrastructure, though tests must stay within your own projects. Ask the provider to list which services and techniques in your plan fall into each category, because the approval route decides how much waiting the schedule absorbs.

Provider lead time for simulated events

AWS asks for a request at least 2 weeks ahead for simulated events such as red, blue or purple team testing and simulated phishing. That lead time is a scheduling cost: it pushes the start date and can force a second exercise window if a team change lands in the meantime. Ask the quote to show the date the request goes to the provider and the buffer assumed before testing begins.

Writing the rules of engagement

The rules of engagement set the permitted techniques, time windows, contacts and stop conditions. This is largely one-time work, but it must be revised whenever a provider rule changes or a new service joins scope. Ask whether the provider's prohibited list, including DoS, flooding and S3 bucket or subdomain takeover on AWS, is written into the document, and who signs it on your side.

Reporting findings in provider services

Findings in a provider's own services carry extra reporting duties. Microsoft requires vulnerabilities found in its services to be reported to MSRC, so the report needs a separate section and a handoff step that someone on your team owns. Ask the quote to state whether reporting to the provider is included, and who writes the disclosure text.

Recurring retests and repeated exercises

Retests, new services and repeated simulated events recur, and each one can trigger a new approval, notice or lead-time window. Plan the annual cycle as a series of scoped events rather than one contract. Ask the quote to separate the first engagement from each later retest and to name which changes would reopen the approval work.

Do cloud penetration testing rules need provider approval before a test?

Do I need approval from AWS before I penetration test my workloads?

Not for the services AWS lists in its penetration testing policy. AWS lets customers run security assessments or penetration tests without prior approval against that listed set, which includes EC2, RDS, CloudFront, API Gateway, Lambda, ECS and Fargate. Testing that includes command and control needs prior approval, and the prohibited activities still apply, including denial of service, DNS zone walking, port or request flooding, and S3 bucket or subdomain takeover. Check the current list on AWS's penetration testing page before scoping, because a service missing from the list changes the answer.

Does Google Cloud need to be told before we test our projects?

No. Google Cloud states that customers do not need to notify Google before penetration testing their own Google Cloud infrastructure. You still have to follow the Acceptable Use Policy and Terms of Service, and every test must affect only your own projects. Testing that reaches beyond your projects, such as third-party tenants or shared services you do not own, falls outside that allowance and needs a different plan. Confirm the current wording on Google's notification guidance before the engagement starts.

Does Microsoft require notice before an Azure penetration test?

Microsoft publishes rules of engagement for cloud penetration testing, and those rules prohibit DDoS attacks under all circumstances, phishing or social engineering of Microsoft employees, access to data or tenants the tester does not own, and network-intensive fuzzing. The rules also require vulnerabilities found in Microsoft services to be reported to MSRC. Whether a separate notice step applies to your own Azure resources is not covered by the supplied material, so confirm it against the current Microsoft rules of engagement and with your Microsoft account team before you schedule anything.

How far ahead do I need to request a red team or phishing exercise on AWS?

AWS requires a request at least 2 weeks ahead for simulated events such as red, blue or purple team testing and simulated phishing. That lead time is the only fixed figure in the AWS policy, and it applies on top of the approval rules for command and control. Build it into the schedule before any other step, because the request has to be in before the exercise window is locked. For Azure and Google Cloud, ask the provider directly what lead time applies to red team or phishing work, since the supplied material does not give one.

What do we need to give the testing team before work starts?

Prepare the inputs that let the provider rules and your own change process be checked before any traffic is sent. Typically this includes:

The named cloud accounts, subscriptions or projects in scope, with owners
A written scope listing services, environments and prohibited activities
A named point of contact on your side and an escalation path
Test credentials or access level for each role, and where they are issued
An agreed testing window and a stop procedure if production is affected

The provider notice or approval step applies to each named service, so the scope document is the evidence you will need if a provider asks what was tested.

Can our own team run a cloud penetration test without an outside firm?

Yes, within the rules. Your own staff can test your own environment, but the provider policies still bind them, so the prohibited activities and any approval conditions apply exactly as they would to an outside tester. Internal teams often lack independence from the systems they built, and the supplied material notes that penetration testing is an essentially manual process, so a qualified internal team needs documented method, skill and reporting. Your compliance or assessor may ask who performed the test, so record the tester's role and experience in the report.

What drives the cost and timeline of a cloud penetration test?

The main drivers are the number of accounts, subscriptions or projects, the number of services in scope, and whether the test includes red team, phishing or command and control activity. Each of those adds planning, provider lead time and reporting. Other cost drivers are the rules gathering, the access model you choose, how many rounds of retesting you need after fixes, and whether you run the test once or as a recurring program. Ask any provider for a quote that breaks out the scope, deliverables, retest rounds and any provider notice work, because that makes the quotes comparable. DeployOpen does not publish a price list. Quotes follow from a written scope that is agreed before work starts.

Must one penetration test cover AWS, Azure and Google Cloud together?

No. Each provider sets its own rules, so a multi-cloud estate can be tested in one engagement or in separate ones, depending on what you need to learn. A single engagement is useful when attack paths cross providers, for example identity federation or shared networks, but it means checking every provider's rules before the work begins. Separate tests keep each provider's approval and notice steps simple to document. Either way, the written scope should name each provider, account set and rule set that applies.

How DeployOpen scopes and runs cloud penetration tests within provider rules

DeployOpen plans, tests and documents cloud penetration tests inside the client's own cloud accounts, so each provider's testing policy becomes part of the written scope from the start. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which provider, accounts, subscriptions and projects are in the written scope before any test begins.
Map each planned technique against that provider's current testing policy and note which services need prior approval or notice.
Record excluded activities, such as denial of service and social engineering of provider staff, so the rules of engagement are unambiguous.

How we build

Prepare the test environment and tester access so that testing touches only the client's own accounts and projects.
Agree in writing how simulated events such as red team exercises or simulated phishing are requested and approved with the provider.
Keep logs of tester activity and time windows so the client can match test traffic against its monitoring alerts.

How we hand over

Deliver a written report that separates confirmed findings from items that need further validation by the client.
Document every test performed, the services covered and any provider-facing reports, such as vulnerabilities in provider services, that were filed.
Walk the client's engineers and security leads through remediation priorities and retest scope before the engagement closes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement, if the client wants it.
Review provider testing policies again when they change, and tell the client which written scope items the change affects.
Confirm with the client's own provider account team and legal counsel any policy question that the written scope does not answer.

AWS vs Azure vs Google Cloud penetration testing rules