Key takeaway: Segmentation limits what a compromised workload can reach. Without it, the security of your most sensitive service equals the security of your least maintained one.
The Default Is Open
Create a VPC, launch instances, and they can all talk to each other. Security groups default to permitting internal traffic, and internal DNS resolves everything.
That default exists because it makes things work immediately. It also means a compromised marketing microservice can reach the payments database, the internal admin panel and the CI runner — not because anyone granted that access, but because nobody removed it.
Attackers rely on this. The initial foothold is rarely the target; it is whatever was easiest to compromise. Value comes from what that position can reach next.
Segmentation That Reflects Risk
Splitting by environment is necessary and insufficient. Production separated from staging is a good start and does nothing about movement within production.
| Boundary | Blocks |
|---|---|
| Environment (prod/staging/dev) | Test compromise reaching production |
| Tier (web/app/data) | Direct database access from the edge |
| Service or team | Movement between unrelated workloads |
| Sensitivity (regulated data) | Broad access to the highest-value store |
| Egress control | Command-and-control and exfiltration |
Egress restriction is the most underused and one of the most effective. Most workloads need to reach a handful of known destinations. Permitting only those turns a successful compromise into a process that cannot phone home, download tooling, or transmit data out.
It also defeats server-side request forgery structurally, because the forged request has nowhere permitted to go.
Identity-Based Rather Than Address-Based
Address-based rules degrade as infrastructure becomes dynamic. Container addresses change constantly, and rules written against CIDR ranges become either stale or so broad they permit everything.
Identity-based policy expresses intent directly: the orders service may call the inventory service, regardless of where either is running. Service meshes and cloud-native network policy implement this with mutual TLS, which additionally means a workload cannot impersonate another by occupying its address.
The practical advantage is that the policy remains readable. A rule naming two services is reviewable by a person; a rule naming address ranges is not.
Adopting It Incrementally
Attempting comprehensive segmentation at once fails, because nobody knows the actual dependency graph and blocking traffic breaks production.
The workable sequence starts with observation. Enable flow logs and record what actually communicates for several weeks. The resulting graph is invariably surprising and is the only reliable basis for policy.
Then apply policy in permissive mode, logging what would be denied without denying it. Investigate each would-be denial, since some are legitimate dependencies nobody documented and some are exactly what you want to stop.
Enforce around the highest-value assets first. Restricting who can reach the primary customer database delivers more risk reduction than segmenting a dozen low-value services.
The Bottom Line
Enable flow logs to learn the real dependency graph, then enforce identity-based policy starting at your most sensitive data stores. Restrict egress to known destinations, because that single control removes command-and-control, tooling download and exfiltration in one step.
