Cloud Network Security: Segmentation and Controls

Cloud network security encompasses the policies, technologies, and architectural controls used to isolate, monitor, and govern traffic flows within cloud environments. Segmentation—dividing a network into discrete zones with enforced boundaries—is the structural foundation for limiting lateral movement, enforcing least-privilege access, and containing breach impact. This reference covers the definition and regulatory scope of cloud network segmentation, the mechanism by which controls operate, the principal deployment scenarios, and the decision criteria that distinguish one segmentation approach from another.

Definition and scope

Cloud network segmentation is the deliberate partitioning of cloud infrastructure into logically or physically separated zones such that traffic between zones is subject to explicit policy enforcement. In physical data centers, segmentation relied on VLANs and dedicated hardware firewalls. In cloud environments, segmentation is implemented through software-defined constructs—virtual private clouds (VPCs), subnets, security groups, network access control lists (NACLs), and microsegmentation agents—whose rules are programmable through control-plane APIs.

NIST Special Publication 800-125B, Secure Virtual Network Configuration for Virtual Machine (VM) Protection, provides foundational guidance for segmenting virtualized environments, including isolation of management traffic from tenant workloads. Separately, NIST SP 800-207 defines zero-trust architecture principles, in which network location is explicitly not treated as sufficient for trust—segmentation must be paired with identity and workload verification. The relationship between these two control layers is explored further at Zero Trust Architecture in Cloud Environments.

Regulatory frameworks that mandate segmentation controls include the Payment Card Industry Data Security Standard (PCI DSS), which under Requirement 1 specifies that cardholder data environments must be isolated from out-of-scope systems. HIPAA's Security Rule (45 CFR §164.312) does not prescribe specific segmentation architectures but requires technical safeguards that limit unauthorized access to electronic protected health information (ePHI). FedRAMP authorization, covered in detail at FedRAMP Authorization Overview, maps segmentation requirements to NIST SP 800-53 control families SC (System and Communications Protection) and AC (Access Control).

How it works

Cloud network segmentation operates across three distinct control layers:

1. Perimeter controls — Internet-facing traffic is filtered by cloud-native firewall services (such as AWS Network Firewall, Azure Firewall, or Google Cloud Armor) and web application firewalls (WAFs) before reaching any internal subnet. These controls enforce ingress and egress policies at the VPC or virtual network boundary.

2. Zone-to-zone controls — Within the cloud account or project, subnets are grouped into functional tiers (public-facing, application, data). Security groups or NACLs govern inter-subnet traffic. Rules are stateful in the case of security groups (return traffic is automatically permitted) and stateless in the case of NACLs (both inbound and outbound rules must be explicit).

3. Workload-level microsegmentation — Individual virtual machines, containers, or serverless functions are assigned identity-based policies independent of network address. Microsegmentation agents or service meshes enforce east-west traffic policies at the process or pod level. This is especially relevant in Kubernetes environments, where network policies restrict pod-to-pod communication by namespace, label selector, or port. The container-specific controls in this layer are detailed at Container Security Best Practices.

Traffic inspection between segments typically involves deep packet inspection (DPI), TLS termination for encrypted traffic analysis, and logging to a centralized SIEM. Cloud SIEM and Logging practices govern how segmentation boundary events are captured and correlated.

Common scenarios

Multi-tier web application isolation — The most widely deployed pattern separates public-facing load balancers, application servers, and database instances into three distinct subnets. Only the load balancer subnet accepts port 443 inbound from the internet. The application subnet accepts traffic only from the load balancer security group. The database subnet accepts traffic only on the database port from the application security group.

Regulated data environment isolation — Organizations subject to PCI DSS carve a dedicated VPC or subnet cluster for cardholder data. No direct routing exists between the cardholder data environment and general corporate workloads. All cross-environment communication routes through an inspected transit gateway or dedicated proxy.

Multi-cloud segmentation — Enterprises operating across 2 or more cloud providers use a hub-and-spoke topology in which a centralized inspection VPC or virtual WAN hub terminates all inter-cloud traffic. Each spoke VPC enforces local segmentation independently. This architecture is covered within the Multi-Cloud Security Strategy reference.

Development/staging/production separation — Separate AWS accounts, Azure subscriptions, or GCP projects enforce hard account-level boundaries between environment tiers. This eliminates the risk of misconfigured security group rules creating unintended cross-environment paths. Cloud Misconfigurations and Risks documents how account-level boundaries reduce the blast radius of misconfiguration events.

Decision boundaries

Choosing between segmentation approaches depends on four criteria:

Organizations with monolithic VM workloads and clear subnet boundaries achieve adequate segmentation through native VPC constructs. Organizations running containerized or microservice architectures, where hundreds of workloads share a subnet, require microsegmentation to enforce workload-level boundaries that subnet-based rules cannot achieve.

Identity and Access Management in Cloud Environments intersects directly with segmentation decisions: identity-based policy enforcement complements network segmentation by ensuring that even a workload inside a permitted segment must present valid credentials to access protected resources. Neither control replaces the other; defense-in-depth frameworks such as NIST SP 800-53's SC-7 (Boundary Protection) treat them as complementary layers.

References

• NIST SP 800-125B: Secure Virtual Network Configuration for VM Protection
• NIST SP 800-207: Zero Trust Architecture
• NIST SP 800-53 Rev 5: Security and Privacy Controls (SC-7 Boundary Protection)
• PCI Security Standards Council – PCI DSS Document Library
• 45 CFR §164.312 – HIPAA Technical Safeguards (eCFR)
• FedRAMP – Program Documents and Templates
• Kubernetes Network Policies Documentation