How cloud-native segmentation contains lateral movement across accounts and clouds

What cloud-native segmentation controls

Cloud-native segmentation is not a product — it is a design posture that maps trust boundaries onto infrastructure primitives. In traditional data center architecture, segmentation meant VLANs, firewall rules, and physical separation. In cloud environments, those constructs still exist, but the enforcement surface has shifted: identity, account structure, and policy-as-code now carry as much weight as network topology.

NIST SP 800-53 Rev. 5 includes boundary-protection, access-enforcement, and information-flow controls in the SC control family that can be implemented to reduce unauthorized lateral paths; applying them to lateral-movement containment is an architectural interpretation of those controls, not an explicit mandate in the publication itself (Source: NIST SP 800-53 Rev. 5, Security and Privacy Controls, https://csrc.nist.gov/pubs/sp/800/53/r5/final). Cloud-native implementations operationalize that principle through account boundaries, virtual network controls, trust relationships, and identity-aware policies — each layer stopping movement the layer above it missed.

While general network segmentation frameworks address the foundational theory of containing lateral movement, this piece focuses on real-world cloud implementation: the core cloud-native mechanisms, where they typically break down, and the exact configurations required to make containment effective.

East-west movement is the cloud blast radius problem

When an attacker gains access to a workload or identity in a cloud environment, the immediate question is not whether they can exfiltrate data from that workload — it is how far they can reach from it. East-west movement in cloud environments happens across service APIs, shared IAM roles, VPC peering connections, and cross-account trust policies, not primarily through routed network traffic.

The blast radius of a compromised cloud workload is principally shaped by reachable data-plane and control-plane paths, effective identity and resource authorization, credential exposure, and higher-level governance controls such as SCPs and organization policies. Shrink any of those dimensions, and the attacker's reachable surface contracts. Reduce all of them, and containment becomes structural rather than detective.

This includes API-plane movement: a compromised principal may use cloud APIs to modify security groups, firewall rules, routes, private endpoints, IAM policies, secrets, snapshots, serverless configuration, or Kubernetes control-plane objects without first traversing the target workload's data-plane path. Effective blast-radius analysis must therefore model API permissions, SCP and organization-policy constraints, resource policies, permissions boundaries, session policy, and delegated administration alongside packet reachability.

CSF 2.0 controls PR.IR-01 and PR.AA-05 support logical segmentation and least-privilege access; reducing lateral movement and blast radius is the security interpretation of those outcomes applied here (Source: NIST Cybersecurity Framework CSF 2.0, https://www.nist.gov/cyberframework). In cloud terms, that means treating account boundaries, VPC perimeters, and service-level identity policies as primary containment layers — not firewall logs alone.

Account and subscription boundaries — and what they actually isolate

The strength of an account-level boundary differs materially across cloud providers, and practitioners should not treat them as equivalent.

AWS accounts are strong administrative and security isolation boundaries. AWS Well-Architected guidance explicitly describes accounts as hard boundaries: resources in separate accounts have no data-plane connectivity by default, and no IAM policy in one account can grant access to resources in another without an explicit cross-account trust relationship. This makes AWS accounts the hardest segmentation boundary available on that platform.

Azure subscriptions and Google Cloud projects are primarily management and billing scopes. They do not function as network isolation boundaries in the same way. Google Cloud Shared VPC explicitly allows resources across multiple projects to communicate over a single VPC — project separation alone does not prevent east-west traffic. In both Azure and Google Cloud, effective network isolation depends on VNet or VPC topology, peering configuration, firewall policy, and private-service connectivity, not the subscription or project boundary itself.

Regardless of provider, the routing principle is this: separate VPCs or VNets have no data-plane connectivity unless an explicit connectivity construct — peering, transit gateway, interconnect, VPN — is configured. Account, subscription, or project ownership alone does not create routing. What varies is whether the account object also implies a security boundary or only a management one.

When to use account or project-level isolation: Separate administrative scopes make sense when workloads have meaningfully different data classifications, compliance scopes, or ownership models. A production payment processing environment and a development sandbox sharing a single AWS account creates a gap when developers hold roles with permissions broad enough to reach production resources — even through indirect paths like shared artifact registries or cross-account secrets. On Azure or Google Cloud, achieving equivalent isolation requires explicit network segmentation and IAM scoping even across subscriptions or projects.

Virtual network controls and workload-level filtering

Within a network segment, major cloud providers offer stateful distributed filtering, but they use provider-specific constructs with different scopes, rule models, and defaults: AWS security groups, Azure Network Security Groups (NSGs), and Google VPC firewall rules or firewall policies. The shared principle is that east-west rules must explicitly permit traffic between workloads; the failure modes and default behaviors differ by platform.

The failure mode practitioners encounter most often is rules that permit overly broad source ranges. The meaningful question is not whether a CIDR prefix is /16 or larger — it is whether the source is broader than the documented caller population, particularly when the rule exposes administrative, database, orchestration, or all-protocol access. The right review criteria combine source, destination, port, protocol, whether identity-based alternatives exist, and actual route reachability — not CIDR size alone.

Configuration test: Enumerate inbound rules across your production network segments that expose sensitive workload types — databases, orchestration endpoints, internal APIs — and assess whether the documented caller population justifies the scope of each rule. Flag rules whose source encompasses workloads with no legitimate reason to reach that destination.

For subnet-level controls, the appropriate mechanism is provider-specific:

None of these is a drop-in substitute for the others, and relying on the wrong construct for a given platform can leave expected controls absent.

Broad intra-network rules or permissive default constructs can make east-west movement near-frictionless after compromise, but actual reachability depends on the provider's default network behavior, attached rule sets, host or pod-level controls, routes, and service exposure — not solely on the presence or absence of a security group rule.

DNS, Metadata, and egress paths

A complete segmentation model must account for paths beyond direct workload-to-workload traffic. DNS resolution, metadata service endpoints, NAT and proxy paths, SaaS endpoints, and egress policy all affect what an attacker can discover, reach, and exfiltrate even when east-west ingress is tightly restricted.

Google documents that traffic to the VM metadata server is always allowed by VPC firewall rules. AWS notes that security groups cannot block Route 53 Resolver traffic and requires DNS Firewall for DNS-layer filtering. These paths are relevant to credential theft, command-and-control, and data exfiltration, and they fall outside the scope of standard inbound rule sets.

Cross-account trust as a segmentation boundary

Cross-account role assumption is one of the most common lateral movement paths in cloud environments because it moves through IAM, not the network. An attacker who compromises a workload with permission to assume a role in another account can pivot without touching a firewall rule.

The control here is trust policy scope. Every assumable role carries a trust policy that defines who can assume it — expressed as a principal, with optional conditions. The failure mode is trust policies that specify an entire account as a principal without condition keys, meaning any principal in that account can attempt assumption.

Implementation steps:

The decision between explicit-principal and condition-constrained trust depends on whether the assuming identity is stable. Service accounts and automation roles that rarely change warrant explicit ARN pinning. Human roles that rotate or federate through an IdP may require condition-based constraints instead.

This failure mode is particularly acute for CI/CD pipeline identities, which often hold cross-account deployment permissions and run on infrastructure that receives external code. A compromised automation role with broad assume-role permissions can become a pass for an attacker to enumerate and pivot to every account in the organization.

Private endpoints, service authentication, and resource authorization

Private network connectivity to a managed service does not automatically scope access to the intended resource or replace identity and resource-level controls. Practitioners should explicitly distinguish four separate concerns:

On AWS, VPC endpoint policies supplement rather than replace identity and resource policies; their default can grant full endpoint access to any principal that reaches the endpoint, making explicit endpoint policy scoping a necessary complement to IAM controls. On Azure, Microsoft recommends disabling public network access after validating a private endpoint, enforcing TLS separately, protecting DNS resolution, and enabling NSG controls on the endpoint subnet. Private network path and identity authorization are independent controls and must both be explicitly configured.

Multi-cloud and identity-aware segmentation

When workloads span more than one cloud provider, the segmentation problem changes character. Network-layer controls do not natively extend across cloud boundaries. Interconnect mechanisms — PrivateLink-class private connectivity, dedicated interconnects, VPN overlays — provide private network paths, but private connectivity does not inherently authenticate or authorize individual workload requests. Some endpoint services add principal, resource, or connection authorization, but end-to-end access still depends on IAM, resource policy, and application-layer controls.

Identity-aware segmentation addresses this gap by enforcing policy based on the workload's cryptographic identity — typically a service account token or workload certificate — rather than its network address. A service mesh implementing mutual TLS (mTLS) between workloads can enforce that only an authenticated, authorized service identity reaches a given endpoint, regardless of which cloud the request originates from.

NIST SP 800-207 establishes the conceptual foundation: in a zero trust architecture, network location is not sufficient for access decisions, and identity-defined boundaries replace perimeter assumptions. For practitioners operating across cloud providers, the operational translation is: do not rely on "this traffic comes from our peered network" as an access control. Require the workload to present a verifiable identity claim.

Decision criteria for multi-cloud segmentation approach:

Peering and Transit Connectivity Are Not Uniform

The term "peering" covers significantly different reachability behaviors across providers, and treating it as a uniform construct leads to misconfigured segmentation.

AWS VPC peering, Azure VNet peering, and Google Cloud VPC peering are all non-transitive by default: a peered pair does not automatically extend reachability to a third VPC connected to one of them. However, transit constructs — AWS Transit Gateway, Azure Virtual WAN, Google Cloud Network Connectivity Center with router appliances, and centralized firewalls — create fundamentally different reachability graphs and require separate analysis.

Google Private Service Connect (PSC) interfaces are explicitly transitive in certain configurations, unlike standard PSC endpoints. This distinction is not immediately obvious from the connection type alone.

Practitioners validating peering or transit configurations should verify effective and return routes, propagated prefixes, overlapping CIDR behavior, firewall scope relative to the transit path, and DNS resolution — not only whether a named connection exists. A peering connection established for a single operational purpose can leave a lateral path open long after that use case has ended if routing and filtering are not scoped to the original intent.

What breaks without it

Without appropriate account-level isolation on AWS, a compromised workload in a low-sensitivity environment can reach production through shared roles, shared secrets, or overly permissive peering. On Azure and Google Cloud, the equivalent risk materializes through flat VNet topology, broad IAM scoping across subscriptions or projects, or shared network constructs like Shared VPC.

Without workload-level filtering discipline, east-west movement inside a network segment becomes near-frictionless for an attacker who has compromised one workload — particularly when database or internal API rules accept traffic from broad source ranges rather than named workload identities or specific groups.

Without cross-account trust policy controls, a compromised automation role with broad assume-role permissions becomes a pivot mechanism across every account in the organization. CI/CD pipeline identities are the highest-risk surface for this failure mode.

Without identity-aware segmentation in multi-cloud environments, an attacker who positions themselves on a peered or interconnected network path may reach services that treat network adjacency as implicit trust. Private path and identity authorization must both be explicitly configured — one does not substitute for the other.

Without accounting for API-plane paths, credential endpoints, DNS, and egress, a segmentation model that stops east-west data-plane traffic can still leave an attacker with sufficient discovery, credential access, and exfiltration capability to achieve their objective.

Cloud segmentation control table