Multi-Cloud VAPT: Comparing AWS, Azure, and GCP Attack Surface

Multi-cloud deployment has moved from niche to mainstream. A recent industry survey found that over 80% of enterprises operate in more than one public cloud, and the majority run production workloads in at least two. VAPT programmes that were built for single-cloud environments frequently underweight the attack surface introduced by multi-cloud architectures — particularly the cross-cloud lateral movement paths that emerge when identity, network, and workload boundaries span providers. This document compares the attack surfaces of the three major public clouds and describes the multi-cloud-specific considerations for defensive VAPT.

Identity Models Compared

AWS IAM, Azure RBAC with Entra ID, and Google Cloud IAM address the same fundamental problem — controlling who can perform what actions on which resources — with materially different models. AWS uses policies that attach to principals and can also attach to resources via resource-based policies. Azure uses role assignments that connect principals to roles at specific scopes. GCP uses IAM bindings that connect principals to roles at specific resources, with policy inheritance following the resource hierarchy.

The differences matter for assessment approach. AWS assessments enumerate identity policies (both attached and inline), resource policies, and permission boundaries, then analyse effective permissions through the policy evaluation logic. Azure assessments enumerate role assignments at every scope (management group, subscription, resource group, resource) and consider both built-in and custom role definitions. GCP assessments enumerate IAM bindings and consider inheritance from the organisation, folder, project, and resource levels.

Cross-cloud identity integration adds a layer of complexity that single-cloud assessment does not consider. Workload identity federation between GCP and AWS, cross-cloud SSO via Entra ID, and third-party identity providers spanning multiple clouds all produce identity flow patterns that VAPT must consider. A compromise in one cloud can potentially extend to other clouds via federation trust relationships that were configured for legitimate reasons but expand the blast radius of single-cloud incidents.

Metadata Endpoints and Workload Identity

All three providers expose metadata endpoints that provide instance identity to workloads. AWS uses the well-known 169.254.169.254 address with IMDSv1/v2 protocols. Azure uses the same address with a different protocol requiring a specific header for token requests. GCP uses metadata.google.internal (which resolves to a similar link-local address) with header requirements to prevent SSRF exploitation.

The default hardening posture differs across providers. AWS made IMDSv2 the default for new instances in 2023 but does not enforce it for legacy instances. Azure requires the specific header for token requests by default, providing baseline SSRF protection. GCP requires the Metadata-Flavor header, also providing baseline SSRF protection. Assessments should verify not just that hardening is enabled but that legacy exceptions are enumerated and addressed.

Kubernetes workload identity — GKE Workload Identity, AKS Workload Identity, IRSA on EKS — provides identity to pods without exposing the underlying node's metadata endpoint. Assessments of Kubernetes-hosted workloads should verify workload identity is used rather than the pod inheriting the node's identity. Inheriting node identity is a common misconfiguration that provides pods with substantially broader permissions than the workload actually needs.

Container Platform Differences

Managed Kubernetes services — EKS, AKS, GKE — share a common Kubernetes API surface but differ in the integration with underlying cloud identity and networking. EKS uses IRSA (IAM Roles for Service Accounts) to map Kubernetes service accounts to AWS IAM roles. AKS uses Azure AD workload identity to similar effect. GKE uses Workload Identity with GCP service accounts. Assessments must consider both the Kubernetes RBAC surface and the cloud identity surface that Kubernetes workloads access via the integration.

Node auto-scaling, node upgrade automation, and control plane management differ across providers in ways that affect the attack surface. EKS provides less automated control plane management than AKS and GKE, requiring more explicit configuration but providing more direct customer control. AKS and GKE provide more automation but occasionally introduce vulnerabilities via the automation itself — misconfigurations in the automation platform can affect many customer clusters simultaneously. Assessments should consider the provider-specific automation as part of the platform's attack surface.

Managed database services present another cross-cloud comparison area. RDS, Azure SQL, and Cloud SQL each have distinct networking models, authentication mechanisms, and access control patterns. Assessments should evaluate each against provider-specific best practices rather than applying a common template — the specific hardening actions and the specific evidence of hardening differ enough across providers that a common template underweights each provider's specific concerns.

Networking and Connectivity Models

AWS VPCs, Azure VNets, and GCP VPCs share the concept of isolated virtual networks but differ substantially in the details. AWS VPCs are region-scoped with subnet-level availability zone binding. Azure VNets are region-scoped with subnet-level availability zone options. GCP VPCs are global with region-scoped subnets — a model that permits routing between regions without explicit peering. The differences affect how network segmentation should be designed and how VAPT should validate segmentation.

Cross-cloud connectivity is typically achieved through cloud interconnect services (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) or through VPN connections between cloud environments. The interconnection points are potential lateral movement paths that require explicit assessment. A compromise in one cloud that reaches an interconnect point can potentially extend to the connected cloud, particularly if the interconnect terminates in a hub network with broad connectivity to workload networks.

Egress control differs across providers. AWS NAT gateways, Azure NAT gateways, and GCP Cloud NAT all provide egress translation, but the mechanisms for restricting egress to specific destinations differ. Egress restrictions are important both for compliance (particularly PCI DSS Requirement 1.3.4) and for limiting the impact of workload compromise. Assessments should validate egress restrictions per provider rather than assuming common patterns.

Cross-Cloud Lateral Movement Patterns

Cross-cloud lateral movement typically occurs through one of three paths: identity federation that permits credentials from one cloud to access another, network connectivity that permits traffic from one cloud to reach another's services, or shared data stores that are accessed from both clouds. Assessments should enumerate each of these paths and evaluate whether the effective controls prevent unauthorised traversal.

Identity federation for legitimate operational reasons (SSO for administrators, workload identity federation for cross-cloud service integration) frequently expands the blast radius of identity compromise across cloud boundaries. Assessments should map the identity federation topology and evaluate what permissions are granted to federated identities in each cloud. Federated identities frequently have broader permissions than would be granted to native identities because operational teams are less familiar with cross-cloud permission implications.

Shared data stores — data lakes accessed from multiple clouds, cross-cloud analytics platforms, unified logging systems — represent both a legitimate architectural pattern and a potential lateral movement path. Assessments should evaluate access controls on shared data stores against the specific identities that access them from each cloud. Weakly controlled shared data stores frequently permit lateral movement between clouds even when direct identity and network controls are strong.

Unified Assessment Approach

A defensive multi-cloud VAPT programme uses a unified methodology with provider-specific implementations. The methodology covers the same categories of concern — identity and access, network and connectivity, workload security, data storage, logging and monitoring — across all providers. The specific tests, tools, and evidence differ per provider, but the categorical coverage is consistent. This unified approach produces evidence that maps cleanly to control frameworks (SOC 2, ISO 27001, PCI DSS) that do not distinguish by cloud provider.

Cross-cloud findings — findings that emerge only from considering interactions between clouds — deserve distinct reporting. A finding that identifies a cross-cloud lateral movement path is different from a finding within a single cloud and typically requires remediation attention from multiple teams. The reporting structure should distinguish single-cloud findings from cross-cloud findings so that the appropriate remediation ownership is clear.

Continuous multi-cloud VAPT platforms have become the practical mechanism for maintaining ongoing coverage across cloud providers. Point-in-time assessments of multi-cloud environments miss the interaction effects between changes in different clouds; continuous assessment integrated with each cloud's infrastructure-as-code pipeline catches drift immediately and produces the evidence base that compliance frameworks and internal risk management both require. Multi-cloud environments benefit disproportionately from continuous approaches because the complexity of coordinating point-in-time assessments across providers is substantially higher than in single-cloud environments.