Cloud segmentation is the practice of dividing workloads, services, users, and management paths into security boundaries that limit unnecessary communication. For CompTIA Cloud+ CV0-004 practitioners, the design problem is not simply to create more subnets. A useful boundary must map to workload trust, data sensitivity, administration, and expected traffic so that a compromised component cannot move freely through the environment.
Cloud platforms implement those boundaries through several overlapping controls: virtual networks or VPCs, subnets, route tables, security groups or equivalent stateful firewalls, network ACLs or stateless filters, service endpoints, and workload-level policy. The deeper security objective overlaps with SecurityX CAS-005 because segmentation is a blast-radius control. The architecture should make legitimate application paths explicit while making lateral movement and accidental exposure harder.
Start segmentation with trust boundaries, not IP ranges
Subnetting can create technical boundaries, but the security model should begin with business and application trust. Identify public ingress, application tiers, data stores, management systems, build infrastructure, shared services, and administrative paths. Ask which components must communicate, which flows are one-way, and which systems would create unacceptable impact if compromised.
Use that model to define zones or workload groups before choosing CIDR blocks. Add explicit management and observability paths to the trust model. Administrative interfaces, backup agents, monitoring collectors, and deployment systems often cross application boundaries and can become hidden lateral-movement channels if they receive broader access than production traffic. Two workloads in different subnets may still have identical trust, while two services in the same subnet may need different security policy. Address design should support segmentation, not substitute for it. Keep boundary intent documented alongside the network configuration so future engineers understand why the separation exists.
VPCs and virtual networks establish broad isolation domains
Virtual private clouds and virtual networks usually provide the broadest tenant-controlled network boundary. Separate VPCs can reduce route sharing, policy coupling, and administrative blast radius between environments such as production, development, shared services, and regulated workloads. They also make ownership clearer when different teams control different systems.
Creating many VPCs increases connectivity and governance complexity, so isolation should be balanced with operational cost. Establish naming, ownership, route-advertisement, peering, and logging standards before the number of networks grows. Without those standards, teams can recreate a flat network logically even when the address space looks segmented on paper. The vendor-specific example in AWS VPC networking shows how cloud networks combine subnets, routing, gateways, and security controls, but the design principle is vendor-neutral: use a separate network domain when shared routing or shared administration would create unacceptable trust.
Subnets create routing boundaries, not automatic security
Subnets organize address space and usually determine which route table, gateway, or availability-zone placement applies to a workload. Public and private subnet labels are architectural conventions; a subnet becomes externally reachable only when routing, public addressing, load balancers, or other connectivity actually create that path.
Do not assume a private subnet is safe because it lacks a direct internet route. Private workloads can still reach external services through NAT, proxies, service gateways, or centralized egress. Egress architecture should therefore be part of segmentation: control which destinations are reachable, where traffic is inspected, and which workloads may initiate outbound connections. It may still be reachable from peered networks, transit hubs, VPNs, administrative hosts, serverless connectors, or compromised workloads elsewhere in the cloud estate. Review every inbound and outbound path that crosses the trust boundary. Document expected flows as source, destination, protocol, purpose, and owner. That makes later rule review much easier because operators can distinguish a justified application dependency from an unexplained opening that was added during troubleshooting.
Security groups should express workload intent
Stateful security groups or their equivalents are most useful when they describe the role of the workload rather than a large collection of IP addresses. An application tier might accept HTTPS from a load balancer and connect to a database port on a data tier. A management interface might accept administration only from hardened jump hosts or a trusted identity-aware access path.
Prefer references to workload groups, tags, or service identities when the platform supports them. Avoid policy that depends on labels no team owns or tags users can freely change. If policy engines trust metadata, protect the metadata workflow with least privilege and change logging so a compromised deployment pipeline cannot relabel a workload into a more trusted group. These relationships survive scaling and address changes better than static allowlists. Review outbound rules as carefully as inbound rules; unrestricted egress can give a compromised workload an easy path to command-and-control infrastructure or data-exfiltration destinations.
Network ACLs add coarse stateless control at the subnet edge
Network ACLs or equivalent stateless filters can provide an additional subnet-level boundary. Because they do not track connection state in the same way as stateful workload firewalls, they require explicit treatment of return traffic and ephemeral ports. That makes them useful for broad guardrails but easy to misconfigure when used as the primary application policy. Cloud teams often abbreviate network ACLs as NACLs; the important distinction is that they are subnet-scoped and stateless, unlike stateful workload security groups.
Use subnet ACLs for controls that genuinely belong at that boundary, such as blocking known disallowed network ranges, constraining classes of traffic, or creating a second layer around high-risk segments. Keep the rule set small enough that operators can reason about it. Dense combinations of stateful and stateless policy can create troubleshooting ambiguity when packets are dropped at multiple layers. Keep application-specific authorization closer to the workload so rule intent remains understandable.
Microsegmentation pushes policy closer to workload identity
Microsegmentation reduces reliance on network location by applying policy to smaller workload groups, service identities, namespaces, labels, or application roles. In container and service-mesh environments, pair network policy with service identity so replicas can scale or move nodes without inheriting broad trust from the host subnet. This is especially important when east-west traffic never leaves the virtual cluster network. This is valuable in dense cloud and container environments where many workloads share address space and change frequently.
The principle aligns with zero-trust access in one important way: access is based on explicit policy rather than broad network presence. Microsegmentation is not the same as ZTNA, but both reject the assumption that being “inside” a network should grant wide reachability.
Shared services need controlled connectivity instead of flat peering
DNS, logging, identity, patching, artifact repositories, monitoring, and management services often need to communicate with many workload environments. Connecting every VPC directly to every other VPC can create transitive trust, route complexity, and policy sprawl. A hub, transit, or service-oriented connectivity model can centralize selected shared paths while keeping application networks isolated from each other.
Document which services are intended to be shared and which routes are propagated. Shared DNS, patching, monitoring, and artifact services should not become universal transit points. Enforce source and destination policy at the service edge and monitor unexpected flows that indicate workloads are using shared infrastructure as a bypass around normal segmentation. Route reachability should not automatically grant application access. Combine transit design with security policy so shared infrastructure is reachable only on the ports and identities it actually requires.
Validate segmentation with both flow analysis and testing
Architecture diagrams are not proof that segmentation works. Effective-policy views can differ from source templates because organization-level rules, inherited groups, defaults, and service-managed components may add or override connectivity. Audit the policy that the platform actually enforces, not only the declarations in one team’s repository. Review effective routes, security groups, ACLs, gateways, peering relationships, firewall policy, service endpoints, and inherited organization-level controls. Cloud-native reachability analysis and flow logs can reveal paths that are difficult to see in a static diagram.
Test representative allowed and denied paths using approved validation methods. Include negative tests after failover, autoscaling, and deployment changes because emergency automation can reattach permissive security groups or route tables. Where possible, continuously evaluate desired connectivity with policy tests so a drifted network rule is detected before an incident. Confirm that required application traffic succeeds, that prohibited lateral movement fails, and that denial events are observable. Re-test after major network, identity, and infrastructure-as-code changes because one route or broad security-group update can silently reconnect previously isolated environments.
Treat segmentation as a maintained security architecture
Cloud networks change continuously as teams add services, regions, integrations, and automation. Track segmentation exceptions as technical debt with owners and expiration dates. Temporary broad rules created for migrations or troubleshooting should not survive indefinitely. Review flow logs and denied-traffic patterns to distinguish legitimate new requirements from attempts to normalize overly permissive connectivity. Assign ownership to network domains and policy groups, review unused rules, and remove temporary exceptions. Infrastructure-as-code and policy-as-code can make changes repeatable, but they do not guarantee the design is correct.
Effective cloud segmentation has a measurable outcome: compromise of one workload should not automatically expose unrelated systems. Include recovery scenarios in segmentation reviews as well. Failover networks, temporary disaster-recovery connections, and migration bridges should preserve the same trust boundaries instead of opening broad emergency paths that remain after the event. VPCs, subnets, security groups, ACLs, and microsegmentation each contribute at a different layer. Their value comes from a coherent trust model, not from the number of controls deployed.
Exceptions should have owners and expiry conditions. Temporary peering, broad security-group rules, shared-service routes, or NACL changes often become permanent because the application keeps working and no one revisits the reason they were added. Periodic reachability review should compare intended service flows with actual routes and policies so segmentation remains an architecture rather than a one-time diagram.