What is microsegmentation? How it works in cloud and Kubernetes environments

Microsegmentation is a security architecture that divides a network into small, isolated segments, down to individual workloads, and applies a separate access policy to each one so that only explicitly allowed connections can occur. In cloud and Kubernetes environments, workloads scale, move and change IP addresses constantly. For that reason, microsegmentation policies attach to identities and attributes such as labels, service accounts, tags and security groups, not to fixed network locations. The goal is to stop an attacker who compromises one pod, VM or function from moving laterally to databases, secrets or control planes. This guide, current as of October 2026, covers enforcement layers across AWS, Azure, GCP and Kubernetes. It also includes sample policies, a rollout plan and the failure modes that derail most projects.

Microsegmentation explained: Zero Trust, east-west traffic and lateral movement

Microsegmentation enforces Zero Trust and least privilege on traffic between workloads, not only at the network edge. CISA’s Zero Trust guidance describes microsegmentation as a networking control that limits connections to a zone or segment, with each segment small enough to contain a single workload or application.

North-south vs. east-west traffic

North-south traffic enters or leaves the environment. Examples include a user calling an API through a load balancer, or a service reaching an external SaaS endpoint. East-west traffic flows between internal workloads. For example, a frontend pod calls an order service, which queries a PostgreSQL instance, which replicates to a standby.

In microservices applications, east-west traffic far outweighs north-south traffic, and perimeter firewalls never inspect it. Attackers get in through a vulnerable container image, a leaked token or a misconfigured service. Once inside, a flat internal network lets them scan and connect freely.

Lateral movement and blast radius

Lateral movement is the stage of an attack where the intruder pivots from the first compromised asset to more valuable ones. Microsegmentation shrinks the blast radius of that first compromise. Suppose an attacker exploits a public-facing web pod whose policy only permits outbound connections to the cart service on TCP 8080. They cannot reach the payments database, the Kubernetes API server or the CI runner subnet without breaking a second control.

Core principles

• ✓Default deny: no workload can talk to another unless a rule allows it.
• ✓Least privilege: each allowed flow specifies source, destination, port and protocol, and ideally the caller’s identity.
• ✓Identity over location: policies follow labels, tags, service accounts or certificates, not IPs that change on every deploy.
• ✓Visibility first: you cannot write correct rules for traffic you have not observed.
• ✓Dynamic adaptation: policies update automatically when workloads scale, reschedule or redeploy.

Microsegmentation vs. perimeter security, VLANs and network segmentation

Perimeter firewalls protect the boundary. VLANs and subnets split the network into broad zones such as “production” or “DMZ”, and everything inside a zone still trusts everything else in it. Microsegmentation enforces policy per workload instead of per network zone.

Traditional segmentation still reduces broadcast domains, separates environments and simplifies routing. It breaks down in the cloud for three reasons:

• ✗Granularity: a subnet holding 200 pods treats all 200 as equally trusted.
• ✗Churn: IP-based ACLs go stale when autoscaling groups and Kubernetes reschedule workloads every few minutes.
• ✗Operational load: VLAN or firewall changes usually require network tickets, which cannot keep pace with daily deploys.

How microsegmentation works in cloud and Kubernetes environments

Teams group workloads by identity, map which groups need to communicate, and enforce allow-list rules at the cloud provider, the host, the Kubernetes CNI or the service mesh. Each layer sees different context, so most cloud-native programs combine two or three.

Cloud workloads in AWS, Azure and GCP

Each hyperscaler has native controls for identity-based rules within a broader cloud network security design:

• AWS: security groups are stateful and can reference other security groups as sources, so db-sg can allow TCP 5432 only from members of app-sg, whatever their IPs. Network ACLs add stateless subnet rules, and security groups for pods extend this to individual EKS pods.
• Azure: Network Security Groups (NSGs) with Application Security Groups (ASGs) support rules such as “web-asg may reach api-asg on 443” instead of NIC addresses. Azure Firewall handles centralized egress and cross-VNet inspection.
• GCP: VPC firewall rules can target service accounts or secure tags, and hierarchical firewall policies apply guardrails at the organization or folder level.

Native controls fall short in four places:

• ✗They do not see pods behind a node IP when the CNI uses SNAT.
• ✗They have no process-level context.
• ✗They use a different policy model on each cloud.
• ✗They cannot express Layer 7 rules such as “allow GET /orders but not DELETE”.

Virtual machines

For VMs, including on-premises and lift-and-shift workloads, an agent programs the OS firewall (iptables or nftables on Linux, Windows Filtering Platform on Windows) from a central policy. Enforcement follows the workload across clouds and data centers, which suits hybrid estates. The cost is deploying the agent and managing its lifecycle.

Containers and Kubernetes

• Namespaces group workloads by team, application or environment and form the first policy boundary.
• Labels and selectors such as app: payments-api or tier: db identify pods, and policies select pods by label, never by IP.
• NetworkPolicy objects define ingress and egress rules for selected pods (see how Kubernetes network policies work).
• CNI plugins enforce those policies. Without a policy-capable CNI such as Calico or Cilium (GKE Dataplane V2 is Cilium-based), the cluster silently ignores NetworkPolicy objects.
• Service accounts give each pod an identity for service meshes and cloud workload identity (EKS Pod Identity or IRSA, GKE Workload Identity, Azure Workload Identity).

Kubernetes enforcement is declarative and travels with the deployment manifest. It is also cluster-scoped, so traffic to a managed RDS database or an external API still needs a cloud-layer or egress control.

Enforcement layers and when to use each

Microsegmentation tools and vendors

Dedicated products include VMware NSX, Illumio Core, Akamai Guardicore Segmentation, Cisco Secure Workload, Zscaler Workload Segmentation, ColorTokens Xshield, Zero Networks Segment and Calico. They combine agent-based, agentless, network-based and identity-based enforcement with flow mapping. Gartner tracks the category as network security microsegmentation.

Observability and telemetry

VPC Flow Logs (AWS and GCP) and VNet flow logs (Azure) record the 5-tuple (source and destination IP, ports and protocol) plus accept or reject. They do not record which pod, container or process generated a flow. Kubernetes labels and asset inventory add identity, and eBPF-based runtime sensors add the process, binary and container behind each connection. Together these signals make policies change-aware. When a deployment adds a dependency, you see the new flow before it hits a deny rule in production.

Microsegmentation policy examples for cloud and Kubernetes

Most policies repeat a few patterns: default deny per namespace, tier-to-tier allow rules, controlled egress, and isolated admin and CI/CD paths. Adapt the snippets below to your own labels and namespaces.

Default-deny for a production namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

The empty podSelector selects every pod in the namespace and blocks all traffic until you add explicit allow rules.

Restrict database access to the application tier

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: postgres-from-api-only
  namespace: payments-prod
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: payments-api
    ports:
    - protocol: TCP
      port: 5432

For a managed database on AWS, the equivalent is an inbound rule on rds-payments-sg that allows TCP 5432 from source sg-payments-api, with no CIDR ranges.

Other common patterns

How to implement microsegmentation step by step

Discover real traffic first, then design, simulate and enforce policies in phases while you measure outcomes. Skipping discovery is the fastest route to a production outage and a rolled-back project.

1. Discover and map traffic. Collect flow logs, Kubernetes metadata and runtime connection data for at least one full business cycle, including month-end batch jobs, to capture rare but legitimate flows.
2. Analyze dependencies. Group workloads into applications and tiers, and identify the shared services that almost everything needs, such as DNS, NTP, logging, identity providers and registries.
3. Classify and prioritize. Start with crown-jewel assets: cardholder data environments, PHI stores, secrets managers, CI/CD systems and cluster control planes.
4. Design policies around identity. Standardize labels (app, tier, env, data-class), tags and service accounts before you write rules, because inconsistent labels produce inconsistent policies.
5. Run in simulation mode. Use audit or staged modes, such as Calico staged policies or Cilium policy audit mode, to see which flows would be denied without blocking them.
6. Enforce in phases. Move one namespace or application at a time from audit to enforce, starting with non-production, then low-risk production services.
7. Handle exceptions formally. Give every exception an owner, a reason and an expiry date, and track it in Git alongside the policy.
8. Monitor continuously. Alert on denied flows that spike after deploys, policies that no longer match any workload, and new flows that bypass expected paths.

Common failure modes

Dark Reading’s analysis of microsegmentation pitfalls matches what platform teams report in practice:

• ✗Over-segmentation: per-pod rules for 3,000 services create more policy than anyone can maintain, so segment by application and tier first.
• ✗Broken dependencies: health checks, service discovery and DNS usually break first during enforcement.
• ✗Policy sprawl: duplicate and orphaned rules pile up across security groups, NSGs and NetworkPolicies when nobody owns cleanup.
• ✗Team friction: security writes policy and platform engineering absorbs the outages. Store policies as code in the application repository and review them in pull requests so both teams share ownership.

Measuring success

For cluster hardening beyond network rules, such as RBAC, Pod Security Standards and admission control, see these Kubernetes security best practices.

Microsegmentation in multi-cloud, hybrid and regulated environments

Multi-cloud and hybrid estates need one consistent policy model, because AWS security groups, Azure NSGs, GCP firewall rules and Kubernetes NetworkPolicies do not share syntax, identity or logging formats. A rule like “only the billing service may reach the billing database” must be written three or four different ways, and drift between those versions creates gaps.

Consistency across VMs, containers and serverless

• Common taxonomy: use the same tag and label keys (app, env, data-class) in every cloud and cluster, then generate provider-specific rules with Terraform or a policy engine.
• VMs and containers: reference cloud-native groups by tag, use host agents where needed, and add a service mesh where Layer 7 or mTLS identity matters.
• Serverless: Lambda, Cloud Functions and Azure Functions have no host to instrument, so segmentation relies on VPC attachment, security groups, private endpoints and tightly scoped IAM roles.
• Cross-environment links: treat VPN, Direct Connect, ExpressRoute and Cloud Interconnect as segment boundaries with explicit allow rules.

Compliance mapping

Document every segment boundary, keep policy history in version control and retain denied-flow logs. Assessors increasingly ask for evidence that segmentation works in practice as well as on paper.

How Upwind supports microsegmentation with runtime context

Upwind shows which workloads actually communicate at runtime, which is the input that discovery, policy design and monitoring depend on. Its eBPF sensors capture network flows, system calls and process activity at the kernel level and correlate them with cloud configuration and IAM context. Teams can then map real dependencies before they enforce default-deny rules. Gartner Peer Insights reviewers rate Upwind 4.8/5 from 88 reviews as of October 2026, and several mention seeing exactly how resources communicate. One limitation is that the sensor does not run on AWS Fargate or on node-less serverless modes that block node-level access.

• ✓Runtime traffic visibility across EKS, GKE, AKS and OKE for Linux and Windows container workloads.
• ✓Agentless discovery of cloud resources, relationships and misconfigurations.
• ✓Threat Stories with timelines and root cause when lateral movement occurs.
• ✓Containment through Microsoft Sentinel playbooks such as container isolation and node quarantine.
• ✓Jira, ServiceNow and PagerDuty integrations that route policy fixes to owners.

Where to start with microsegmentation

Start with one high-value namespace or database tier. Prove the model in audit mode, then expand segment by segment. Effective microsegmentation in cloud and Kubernetes environments depends on three habits. Write policies against identities instead of IPs, observe real traffic before you enforce, and keep policies current as applications change.

FAQ