AWS & Azure Cloud Infrastructure Penetration Testing: What Is Included in the Scope

Cloud infrastructure penetration testing for Amazon Web Services (AWS) or Microsoft Azure is a controlled security assessment that evaluates the real resilience of your cloud environment from an attacker’s perspective — strictly within an agreed scope and rules of engagement.

In most real-world cases, the goal is not to “hack everything,” but to identify high-impact risks such as:

• misconfigurations,

• excessive permissions,

• leaked secrets,

• insecure CI/CD pipelines,

• vulnerable cloud services,

that could ultimately lead to account takeover, data breaches, or full cloud compromise.

What Is Scope in AWS / Azure Penetration Testing and Why It Is Important

In AWS and Azure penetration testing, scope defines the exact boundaries of the assessment: which cloud accounts or subscriptions, tenants, regions, environments, services, applications, and attack techniques are allowed to be tested. Anything not explicitly listed in the scope is considered out of scope and must not be touched during the engagement.

Clearly defining scope is especially important in cloud environments such as Amazon Web Services and Microsoft Azure because cloud resources are highly dynamic, tightly interconnected, and directly linked to business operations and costs. Without a fixed scope, it becomes unclear what was actually tested, which findings are relevant, and whether the results can be reliably reproduced.

A well-defined scope also prevents unintended consequences. In the cloud, aggressive scanning, misused APIs, or uncontrolled exploitation can trigger auto-scaling, increase cloud bills, or cause service disruptions. Scope limits testing to safe and agreed scenarios, reducing operational and financial risks.

From a legal and governance perspective, scope is equally critical. Cloud platforms follow a shared responsibility model, where not all components belong to the customer. Proper scope definition ensures that testing is limited to customer-owned resources and does not affect the cloud provider, shared infrastructure, or third-party SaaS services.

Finally, scope directly impacts the value of the penetration test. A vague or overly narrow scope often results in shallow findings focused only on public exposure. A well-defined scope enables realistic attack simulations, identification of privilege escalation paths, and meaningful remediation recommendations that reflect how a real attacker would compromise a cloud environment.

What Is Typically Included in AWS / Azure Cloud Pentest Scope

1. Identity and Access Management: IAM / Entra ID

This is almost always the most critical part of a cloud penetration test.Most cloud breaches start with identity abuse, not network exploitation.

Included in scope:

AWS

• IAM users, roles, and policies

• Trust relationships and cross-account access

• Permissions boundaries and SCPs (AWS Organizations)

Azure

• Microsoft Entra ID (Azure AD)

• Azure RBAC roles

• PIM / PAM configurations

• Conditional Access policies

• Service principals and managed identities

Security checks

• Over-permissioned roles

• Privilege escalation paths

• Dangerous permission combinations

• MFA, password policies, legacy authentication

• Console, API, CLI, federation (SSO), third-party IdPs

Outcome:You get a clear, human-readable map of who can do what, how admin access could be obtained, and exact remediation steps.

2. Secrets and Key Management: Secrets Manager, KMS, Key Vault

Improper secret handling is one of the most common cloud breach causes.

Included in scope:

AWS

• Secrets Manager / SSM Parameter Store

• Encryption settings, access policies, rotation

• Access logging and monitoring

Azure

• Key Vault access policies or RBAC

• Network rules, Private Endpoints

• Soft delete and purge protection

Both

• KMS / Azure Key Management permissions

• Who can decrypt and rotate keys

• Use of customer-managed keys (CMK)

• Secret leakage in:

  • CI/CD pipelines,

  • repositories,

  • container images,

  • environment variables

• Token leaks (GitHub, GitLab, Azure DevOps, Jenkins)

3. Network and Segmentation: VPC / VNet

The goal is to understand whether an attacker can move laterally inside your cloud.

AWS

• VPC, Subnets, Route Tables

• Internet / NAT Gateways

• NACLs and Security Groups

• VPC Peering, Transit Gateway

• VPN / Direct Connect

• PrivateLink (VPC Endpoints)

Azure

• VNets and Subnets

• NSGs / ASGs

• UDRs

• VPN / ExpressRoute

• Private Link / Private Endpoints

• Azure Firewall

Security checks

• Open management ports (SSH, RDP)

• 0.0.0.0/0 exposure

• Weak prod/dev segmentation

• Lateral movement paths

• Metadata service (IMDS) exposure and SSRF risks

4. Public Attack Surface: Internet-Exposed Resources

Attackers always start from what is publicly reachable.

Included in scope:

• Public IPs and endpoints

  • Load Balancers

  • Application Gateway

  • API Gateway

  • CDN (CloudFront, Front Door)

Storage

• AWS S3: public ACLs, bucket policies, presigned URLs

• Azure Storage: blob containers, SAS tokens, account keys

Managed services

• AWS RDS, OpenSearch, Redis

• Azure SQL, Cosmos DB, Redis

Edge security

• WAF, Front Door, rate limits, geo rules

• Cloudflare (if applicable)

5. Containers and Kubernetes

If you run microservices, this is a separate high-risk domain.

Scope may include:

• Kubernetes RBAC

• Service accounts and managed identities

• Network policies

• Admission controllers

• API server exposure

• kubeconfig leakage

• etcd access risks (if relevant)

Containers

• Vulnerable base images

• Secrets inside image layers

• Registry access (ECR / ACR)

• Runtime risks:

  • privileged containers

  • hostPath mounts

  • dangerous Linux capabilities

6. Serverless: AWS Lambda / Azure Functions

What is tested:

• IAM / identity permissions for functions

• Event triggers and chained executions

• Injection risks via payloads

• Environment variable leaks

• Network access to private subnets

• Pivoting from serverless to internal resources

7. CI/CD and Infrastructure as Code

This is where one leaked token can equal full cloud takeover.

Included in scope:

• GitHub Actions, Azure DevOps, GitLab CI, Jenkins

• Token scopes and service connections

• Secret handling in pipelines

• Terraform / CloudFormation / Bicep templates

• Hardcoded secrets

• Insecure defaults (open networks, public storage)

• Artifact integrity and supply-chain risks

8. Logging and Detection Capabilities

A pentest also checks whether your team would see the attack.

AWS

• CloudTrail

• AWS Config

• GuardDuty

Azure

• Activity Logs

• Defender for Cloud

• Microsoft Sentinel

Checks

• Is auditing enabled?

• Are alerts configured for risky actions?

• Are logs protected from deletion or tampering?

• Retention and immutability settings

What Is Usually Excluded from Scope

Unless explicitly agreed otherwise:

• DoS, stress, or load testing

• Attacks on the cloud provider itself

• Multi-tenant infrastructure attacks

• Third-party SaaS testing without permission

• Social engineering and phishing

• Destructive production actions (data deletion, encryption)

  • Only controlled proof-of-concepts are allowed

What Should Be Defined Before Testing (SOW / Rules of Engagement)

Account Boundaries

• AWS Accounts

• Azure Subscriptions

• Management Groups

• Entra ID tenant

Regions and Environments

• Production / staging / development

• Specific regions (e.g. eu-central-1, westeurope)

Services in Scope

• IAM / Entra ID

• VPC / VNet

• Storage

• Kubernetes

• Databases

• Serverless

• WAF

Access Level

• Black-box (No access. Testing is done as an external attacker using only publicly available endpoints and exposed resources)

• Grey-box (Limited access. Read-only or low-privileged credentials that simulate a leaked account or token)

• White-box (Full access. Detailed permissions, architecture, and IaC are provided for deep security analysis)

Methods and Restrictions

• Forbidden techniques (DoS/stress testing, brute-force MFA, destructive actions, mass aggressive scanning, attacks on cloud provider or third-party services)

• Testing windows

• Stop-test procedure

• Escalation contacts

Deliverables

• Risk-based report

• Proofs of concept

• Remediation roadmap

• Retest after fixes

A proper AWS/Azure cloud penetration test scope includes: identity, secrets, networking, public exposure, containers, serverless, CI/CD, and logging.

Only this combination answers the real question:

Can an attacker take control of your cloud — and how exactly would they do it?

FAQ

Can AWS/Azure be tested without access? Yes, but only the public attack surface. The most critical risks usually require at least grey-box access.

What is more important: network or IAM? In the cloud, IAM / Entra ID is usually more critical. With enough permissions, network controls can often be bypassed via APIs.

Is Terraform / Bicep analysis included? Often yes, but it’s best defined explicitly as IaC security review, either inside the pentest or as a separate module.