Cloud penetration testing scope is defined by two things: what the shared responsibility model puts in the customer's hands, and what the specific provider's policy permits testing without prior approval. AWS and Azure structure that permission differently: AWS uses a named list of permitted services, while Azure uses a broader rules-of-engagement document that restricts activity type rather than service name. This guide explains both current policies directly, the shared responsibility boundary as a scoping tool, and what UAE enterprises should expect from a genuine cloud penetration test.
Key Takeaways
Before scoping a cloud engagement, these points determine what's actually achievable.
- Neither AWS nor Microsoft requires prior approval for testing most customer-owned resources, though each defines "permitted" differently.
- AWS names specific permitted services directly; anything outside that list needs a request to AWS Support before testing begins.
- Azure's Rules of Engagement permit testing broadly within your own tenant but strictly prohibit specific activities, denial of service and post-exploitation actions particularly, regardless of what's being tested.
- Much of what gets sold as a "cloud penetration test" in the market is actually a configuration review, which is a different and often more appropriate purchase depending on the buyer's actual need.
- The shared responsibility model shifts depending on whether a workload is IaaS, PaaS, or serverless, which is why the same enterprise estate often needs different testing approaches across its cloud footprint.
Understanding both providers' actual policies, not a summary of them, is the difference between a compliant engagement and one that risks breaching provider terms.
Defining the Scope of a Cloud Penetration Test
Buyers commonly ask for "a cloud penetration test" without realising that a substantial part of any cloud environment belongs to the provider and cannot be tested at all, regardless of budget or tester skill. AWS owns and operates the physical infrastructure, hypervisor, and host operating system beneath every managed service; a customer testing "AWS" in any meaningful sense is testing their own configuration and workloads running on top of that infrastructure, never the infrastructure itself.
Our cloud and API penetration testing page covers the general case for cloud testing and the API security angle in more depth; this page focuses specifically on what AWS and Azure each permit, how the shared responsibility boundary defines scope, and how a cloud engagement gets structured in practice for a UAE enterprise.
The Shared Responsibility Model as a Scoping Boundary
What a customer can legitimately test moves depending on the service model in use, and a single enterprise estate typically spans all three models simultaneously, which is exactly why scoping a cloud test is harder than it first appears.
| Layer | IaaS | PaaS | Serverless and SaaS |
| Physical and hypervisor | Provider-owned, not testable | Provider-owned, not testable | Provider-owned, not testable |
| Operating system | Customer-testable | Provider-owned, not testable | Provider-owned, not testable |
| Runtime and platform | Customer-testable | Provider-owned, largely not testable | Provider-owned, not testable |
| Application code | Customer-testable | Customer-testable | Customer-testable |
| Identity and access configuration | Customer-testable | Customer-testable | Customer-testable |
| Data and encryption | Customer-testable | Customer-testable | Customer-testable |
Identity and access configuration and application code stay customer-testable across every model, which is why IAM privilege escalation and application-layer flaws remain the most consistently in-scope findings regardless of which specific services an enterprise runs. As workloads move from IaaS toward serverless, the testable surface shrinks correspondingly, and testing effort should shift toward configuration and identity rather than infrastructure the customer never controlled in the first place.
What AWS and Azure Permit
Both providers publish testing policies directly, and both policies change, so always check the current published policy before scoping rather than relying on a summary; this one included.
- AWS structures permissions around a named list of permitted services that customers may test without prior approval, currently including EC2 instances, WAF, NAT Gateways, and Elastic Load Balancers, RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda and Lambda Edge functions, Lightsail, Elastic Beanstalk, Elastic Container Service, Fargate, OpenSearch Service, FSx, and Transit Gateway. Command and Control testing requires prior approval regardless of the service targeted, and any service not on the permitted list requires working directly with AWS Support before testing begins. Customers are explicitly barred from testing AWS's own infrastructure or services, only their own resources running on top of them, and denial-of-service testing, DNS zone walking, and port or protocol flooding are prohibited entirely.
- Azure takes a different structural approach. Microsoft's Cloud Penetration Testing Rules of Engagement permit fuzzing, port scanning, and vulnerability assessment against a customer's own Azure Virtual Machines, testing of applications and APIs hosted on Azure, assessment of a tenant's own Entra ID configuration, and creating test accounts or trial tenants specifically to demonstrate cross-account or cross-tenant scenarios. Rather than naming permitted services individually, Microsoft's policy restricts specific activities regardless of target: denial-of-service testing is prohibited under all circumstances, and any DDoS resilience testing must run through a Microsoft-approved simulation partner instead. Post-compromise or post-exploitation activity, enumerating internal networks or files, dumping secrets, executing additional code, lateral movement, or pivoting once a vulnerability is confirmed, is strictly prohibited even within an authorised scope; the practical reading is prove the flaw, stop, and report it. Microsoft has not required pre-approval for penetration testing since June 2017, though the Rules of Engagement remain the binding, authoritative document governing what's actually permitted.
This structural difference matters practically. A tester moving between AWS and Azure engagements needs to check permissions by service name on AWS and by activity type on Azure, since the same technique that's routine on an approved AWS service could breach Azure's post-exploitation restriction even against a fully owned resource.
Configuration Review or Penetration Test
A significant share of engagements sold in the market as cloud penetration tests are, on close inspection, configuration reviews, and understanding the difference protects buyers from paying for one while expecting the other. A configuration review examines cloud settings against a known-good baseline, identifying overly permissive IAM policies, publicly exposed storage, or missing encryption, without attempting to actually exploit anything found. A genuine penetration test goes further, attempting real exploitation within the provider's permitted activities to demonstrate actual impact rather than a theoretical misconfiguration.
Neither is inherently superior, and a configuration review is often genuinely the right purchase, particularly for an organisation early in its cloud maturity where the highest-value work is closing obvious gaps rather than proving they're exploitable. The problem isn't configuration reviews themselves; it's buyers paying penetration-testing rates for a review, or assuming a clean review means their environment has been genuinely tested for exploitability when it hasn't.
What a Cloud Penetration Test Typically Finds
Certain finding categories recur consistently across cloud engagements on both providers, reflecting how cloud misconfiguration tends to cluster around a handful of recurring patterns.
- Over-permissive IAM roles and policies, granting broader access than the role genuinely requires.
- Publicly exposed storage, S3 buckets or Azure Storage accounts left accessible without proper access controls.
- Unrestricted security groups and network rules, permitting inbound access broader than the workload needs.
- Exposed management interfaces, administrative endpoints reachable from the public internet.
- Secrets in code or environment variables, credentials and API keys stored insecurely rather than in a dedicated secrets management service.
- Missing logging and monitoring coverage, gaps that mean a genuine compromise could go undetected.
- Privilege escalation paths between accounts or subscriptions, cross-account trust relationships that allow lateral movement an isolated review of a single account would miss.
Overly permissive IAM configuration tends to have the highest real-world impact on this list, since it's often the mechanism that turns an otherwise contained finding into full account or cross-account compromise.
AWS and Azure Engagement Differences
Identity models differ meaningfully between the two platforms: AWS's IAM structures permissions around roles and policies attached to resources, while Azure's Entra ID integrates far more tightly with the broader Microsoft identity ecosystem, meaning an Azure engagement frequently needs to account for Conditional Access policies and hybrid identity configurations that have no direct AWS equivalent. Account and subscription structures also diverge: AWS organises resources through accounts and organisations, Azure through subscriptions and management groups, and privilege escalation paths specific to each structure need testing on their own terms rather than assuming one platform's escalation patterns transfer directly to the other.
Logging services differ too: CloudTrail on AWS versus Azure Monitor and Activity Log on Azure, and a tester needs familiarity with both to properly assess whether an environment would actually detect the activity being tested. Network constructs, VPCs on AWS against Azure Virtual Networks, follow broadly similar concepts but diverge in specific configuration details that matter directly to how a tester approaches network-layer findings on each platform.
Data Residency Constraints on Cloud Testing in the UAE
UAE data residency and sovereignty requirements can restrict where test data, evidence, and reports generated during a cloud engagement may be stored, and this needs to be addressed during scoping rather than discovered after testing concludes. Our
UAE PDPL compliance guide covers the federal data protection framework that shapes these constraints for personal data specifically, and entities operating regulated workloads, financial services or healthcare particularly, should confirm both regions' requirements before evidence collection begins rather than treating it as an afterthought once findings start accumulating.
Scoping a Cloud Test for Your Environment
Several inputs shape a realistic, properly bounded cloud testing scope regardless of which provider is in use.
- Number of accounts or subscriptions in scope, since privilege escalation paths between them are a recurring high-impact finding category.
- Service models in use across the environment, IaaS, PaaS, and serverless, since the testable surface shrinks as workloads move toward serverless.
- Number of applications hosted within the cloud environment specifically.
- Identity provider configuration, particularly where hybrid identity or federated access is in play.
- Whether a non-production environment exists that testing can target instead of live production workloads.
- The compliance driver behind the engagement, whether SOC 2, ISO 27001, or a specific UAE regulatory requirement.
- Whether a configuration review has already been completed, since that changes what a subsequent penetration test should focus on.
For commercial and procurement details on cloud testing pricing within the broader UAE penetration testing market, our enterprise penetration testing guide covers that ground directly.
Thank you. An expert will get in touch shortly 
