Why Broad Cloud Segmentation Creates a False Sense of Security
Most cloud security architectures start with broad segmentation: separate AWS accounts or Azure subscriptions for dev and production, VPCs and virtual networks that isolate application tiers, security groups and network security groups that control ingress and egress. These are real controls. Account-level isolation is meaningful. Subnet-level separation provides structure.
The problem is that these controls are often where segmentation stops. Once an attacker gains a foothold inside a VPC — via a misconfigured IAM role, a vulnerable public-facing workload, or a compromised developer credential — they can typically move laterally between workloads in the same network segment with minimal restriction. The segmentation that looked adequate on the architecture diagram has almost no internal enforcement.
CyberOne’s network security architecture assessments consistently find the same pattern: strong perimeter controls, flat internal network, wide-open east-west traffic between workloads that have no legitimate reason to communicate.
What Microsegmentation Actually Is
Microsegmentation enforces network policy at the individual workload level — per container, per VM, per service — rather than at the subnet or VPC boundary. Every workload has an explicit policy that defines which other workloads it can initiate or accept connections from, what ports and protocols are allowed, and what behavior is blocked by default. Workloads in the same subnet with no legitimate communication reason can’t reach each other.
The architectural principle is zero trust applied to internal network communications: never assume that traffic inside the network boundary is safe, verify every connection against explicit policy, deny anything that isn’t explicitly permitted.
How Microsegmentation Works in AWS and Azure
In AWS, the primary microsegmentation mechanisms are:
- Security groups: Instance-level virtual firewalls that control inbound and outbound traffic per-EC2 instance or per-Elastic Network Interface. The key is using security group references (allow traffic from this security group, not from this CIDR range) to enforce workload-identity-based policy rather than IP-range policy that breaks when workloads scale.
- VPC endpoint policies: Control which AWS services and which principals can use private endpoints, preventing lateral movement via AWS service APIs.
- AWS Network Firewall: Stateful firewall for VPC-level enforcement with domain filtering and intrusion prevention capabilities.
In Azure:
- Network Security Groups (NSGs): Applied at the subnet or NIC level. NSG rules use Application Security Groups (ASGs) to tag VMs by role and write policy in terms of workload identity rather than IP addresses — the correct approach for dynamic cloud environments where IP addresses change.
- Azure Firewall: Centralized stateful firewall for hub-spoke architectures, with FQDN filtering and threat intelligence-based deny rules.
- Private Link / Private Endpoints: Restrict PaaS service access to specific virtual networks, preventing exposure of storage accounts, databases, and other services to the public internet or unauthorized VNets.
CyberOne’s Zero Trust Architecture implementations use these native cloud controls as the microsegmentation layer, avoiding the need for third-party agents on workloads where native controls are sufficient.
The East-West Traffic Problem in Kubernetes
Container environments add a microsegmentation challenge that VPC-level controls don’t address. In Kubernetes, pods in the same namespace (or across namespaces, depending on your NetworkPolicy configuration) can communicate freely by default. A compromised container can reach any other container in the cluster without traversing a perimeter firewall.
Kubernetes NetworkPolicies enforce ingress and egress policy at the pod level, but they require an explicit allow model — by default, no NetworkPolicies means all traffic is allowed. Getting to a least-privilege network model in a Kubernetes cluster requires inventorying legitimate service-to-service communication, writing NetworkPolicy resources that permit only those flows, and deploying them in a way that doesn’t break application functionality.
Service mesh technologies (Istio, Linkerd, Cilium) extend microsegmentation in Kubernetes with mutual TLS between services (all service-to-service communication encrypted and authenticated), L7 policy enforcement (policy based on HTTP method and path, not just port), and observability into inter-service traffic. For organizations running microservices at scale, service mesh provides the observability needed to write accurate NetworkPolicies in the first place.
Attack Path Reduction: Why Microsegmentation Matters for Breach Containment
The value of microsegmentation becomes concrete in breach scenarios. In a flat cloud environment, an attacker who compromises one workload can typically reach the most sensitive data stores from that initial foothold — there are no internal network controls preventing them from connecting to the production database, the secrets manager, or the data lake. Lateral movement is limited only by the attacker’s knowledge of what’s accessible.
In a microsegmented environment, the compromised workload can only reach what its explicit policy permits. If a web application server is compromised, it can reach the specific database it needs to serve requests — not every database in the environment. Lateral movement requires finding additional vulnerabilities or misconfigurations to break out of the policy boundary, and each hop creates additional opportunity for detection.
CyberOne’s exposure management program includes attack path analysis that maps which vulnerabilities in your environment create viable paths from external access points to high-value targets. Microsegmentation, properly implemented, reduces the number of viable attack paths more than almost any other single control.
Starting Point: Discover Before You Enforce
The most common microsegmentation implementation failure is deploying enforcement without adequate discovery. Organizations write security group rules based on what they think workloads communicate, enforce them, and then find production applications breaking in ways that take weeks to diagnose.
CyberOne’s recommended sequence: audit current security group and NSG configurations to map what’s actually permitted; deploy flow logging (VPC Flow Logs in AWS, NSG Flow Logs in Azure) and analyze traffic patterns to understand what workloads are actually communicating; build microsegmentation policy based on observed traffic, with exceptions documented; deploy in audit/monitoring mode first; enforce after validating no legitimate traffic is blocked. The discovery phase is not optional — enforcement without it causes outages.