Network controls when the network is not yours
Network controls will not stop the most common cloud compromise, because a valid credential used against a public API endpoint never touches your network at all. Buying segmentation as a defence against that is a category error. What segmentation still does, and does well, is limit where an intruder can go once inside a workload, remove the discovery step that makes lateral movement cheap, and constrain the routes data can leave by. Those are worth having, provided you know which problem you are solving.
What does segmentation actually buy you in the cloud?
Containment after a workload compromise, which is a narrower claim than the one usually made for it and still valuable. If an application server is exploited, the questions that determine how bad the day becomes are what else it can reach, whether it can reach the database directly, whether it can scan the subnet, and whether it can open an outbound connection to anywhere. Those are all network answers, and they are the difference between one compromised service and an estate-wide incident.
It also removes reconnaissance. In a flat network, an intruder enumerates and finds the interesting hosts in minutes. In a segmented one, they see the two things the workload was allowed to talk to, and further movement requires new information they do not have. This is why segmentation still pays off even though it does not address the credential path.
What it does not do is protect the control plane, protect against a stolen key used from an attacker's own machine, or make an over-permissive identity safe. Keep the claims separate when you justify the work: a segmentation project sold as defence against credential theft will be judged to have failed.
Why does the on-premises firewall model not transfer?
Because there is no chokepoint, addresses are ephemeral, and most of the traffic you care about never passes a device you control. In a datacentre you place a firewall between zones and every packet crosses it. In a cloud account, filtering is enforced per interface by the platform, east-west traffic goes directly between workloads, and managed services answer on shared endpoints whose addresses change and are shared between customers.
That defeats rules written in addresses. An allowlist of instance addresses is stale after the next scaling event, and an allowlist for a managed service is either impossibly broad or wrong by tomorrow. The mechanism that works instead is naming the source and destination by identity: rules that reference another security group, a tag, or the provider's own service labels, so the rule survives the machine being replaced.
The second adjustment is that appliance thinking imposes a cost the architecture does not require. Forcing all traffic through a virtual appliance to reproduce the old topology creates a bottleneck, a single point of failure and an expensive per-gigabyte charge, and typically to inspect traffic that is encrypted anyway. Use the platform's own per-interface filtering as the default, and reserve appliances for the specific inspection they are genuinely needed for.
| Control | What it filters | What it is good for | Where it falls short |
|---|---|---|---|
| Security group or network security group | Traffic per interface, by port and source | The primary segmentation control, identity-referenced rules | No visibility into content, and easy to leave wide |
| Subnet-level access list | Traffic entering or leaving a subnet | A coarse backstop that a workload owner cannot edit | Stateless on some providers, awkward for return traffic |
| Private endpoint for a managed service | Where the service is reachable from | Keeping database and storage traffic off the internet | Per-endpoint cost, and DNS has to resolve correctly |
| Egress proxy or firewall with domain filtering | Outbound destinations by name | Restricting where data can be sent | Needs to be unavoidable, or workloads route around it |
| Web application firewall | Inbound HTTP requests | Blunting common injection and scanning traffic | Bypassed entirely if the origin is directly reachable |
| Service mesh with mutual TLS | Service-to-service calls, by workload identity | Segmentation that survives address changes | Real operational weight, and a new control plane to secure |
| Flow logs | Nothing, they observe | Detection, and proving what talked to what | No payload, and volume costs add up quickly |
Why is egress the difficult direction?
Because both data theft and remote control use outbound connections on ports you have to allow, and default cloud configurations let a workload reach anything. Inbound filtering gets attention because it is intuitive and because scanners test it. Outbound is where an actual incident progresses: a compromised workload downloads tooling, connects to a controller, and pushes your data to a storage account belonging to somebody else, all over ordinary encrypted web traffic.
Address-based control does not help here, because the destination is a hostname behind an addressing scheme you do not control. The options are a proxy that all traffic must pass, name-based filtering that reads the requested host during connection setup, or reducing the need for internet access at all. The last is the cheapest and most reliable: private endpoints for provider services mean the workloads holding your data do not need a route to the internet, so you can deny it outright.
Do not forget name resolution as a channel. Data can be encoded into queries and answered by a server the attacker controls, and this route is frequently open in estates that have carefully filtered everything else. If you constrain egress, force workloads onto your own resolvers and log the queries, which is a cheap and genuinely useful detection source.
What about the instance metadata service?
It is the most reliably exploited network-adjacent weakness in cloud, and it deserves its own paragraph in every design review. Workloads obtain their cloud credentials from a link-local metadata endpoint that requires no authentication beyond being on the machine. Any bug that makes the workload fetch a URL of an attacker's choosing, the class known as server-side request forgery, can therefore make it fetch its own credentials and return them in a response.
The mitigations are specific and quick. Require the session-oriented version of the metadata service, which is token based rather than signed: the caller issues a PUT to the token endpoint carrying a time-to-live header, receives a session token, and presents that token in a header on every subsequent read. What defeats simple forgery is the need for a PUT and a custom header, not any signing of the request, because a bug that only fetches an attacker-supplied URL produces neither. Set the network hop limit so a response cannot be relayed onward through a proxy or container network. Disable the endpoint entirely on workloads that do not need cloud credentials. Each of these is a per-instance setting, and each can be enforced from above with organisation policy so a new workload cannot arrive without them.
In a container platform the same problem needs handling at the pod level, because the node's metadata endpoint is reachable from pods by default in a naive setup. Block that path at the network layer and give pods their own identities through the platform's workload identity mechanism, so a compromised container gets its own narrow credential rather than the node's, which is usually much broader.
What is the minimum worth implementing?
Four things, in this order. Private endpoints for your data services, so nothing holding sensitive data is reachable from the internet and nothing needs an internet route to reach it. Security group rules that reference other groups rather than addresses, so segmentation survives autoscaling. A default denial on outbound traffic in the accounts that hold data, with an explicit list of permitted destinations. And flow logs on the subnets containing those data services, retained somewhere the account cannot delete.
Deliberately not on the list: inspecting encrypted traffic between your own services, and reproducing a datacentre zone model with virtual appliances. Both are expensive, both add failure modes, and neither is where the marginal risk sits. They become reasonable when a regulator asks for them, and not before.
Also resist the temptation to segment by environment name alone. Development accounts that can reach production data stores are extremely common and undo the entire exercise, and the reason is usually a convenience rule added during a migration. Segment by what the data is worth, then check that the boundary holds in the direction that matters.
What can you test this week?
From inside a running production workload, try to reach an arbitrary internet host. If that succeeds, exfiltration is unconstrained, and it is the highest-value gap on this page. Then try to reach the metadata endpoint and retrieve credentials, and check which version of the service is enforced and what the hop limit is. Both tests take minutes and both usually surprise somebody.
Next, test whether your managed databases and storage endpoints answer from outside your network at all, from a machine with no relationship to your estate. A private network configuration and a publicly reachable endpoint coexist more often than teams expect, because the endpoint setting and the network configuration are separate controls and only one of them gets reviewed.
Finally, pick two workloads with no business relationship and check whether one can open a connection to the other. The answer tells you whether you have segmentation or a diagram of one, and it is worth repeating after every migration, because flat connectivity is usually introduced as a temporary measure during one.
Common questions
- Does network segmentation still matter if identity is the perimeter?
- Yes, but for a specific purpose. It does nothing against a stolen credential used from the attacker's own machine, because that request goes to a public API endpoint and never enters your network. What it does is contain a compromised workload: it limits what that workload can reach, removes the reconnaissance step, and constrains the routes data can leave by. Justify it on containment, not on credential theft.
- Why do IP allowlists not work well in cloud environments?
- Because addresses are ephemeral and managed services answer on shared endpoints that change and are used by other customers. A list of instance addresses is stale after the next scaling event, and a list for a managed service is either far too broad or wrong tomorrow. Write rules that reference identity instead: another security group, a resource tag, or the provider's own service labels.
- Why is egress filtering more important than inbound in the cloud?
- Because incidents progress outbound. A compromised workload downloads tooling, contacts a controller and pushes data to storage the attacker owns, all over ordinary encrypted web traffic that default configurations permit. Inbound filtering gets attention because it is intuitive and easy to test. The most reliable egress control is removing the need for internet access at all, using private endpoints for provider services and then denying outbound traffic.
- What is the instance metadata service risk?
- Workloads collect their cloud credentials from a link-local metadata endpoint that authenticates nothing beyond being on the machine. A server-side request forgery bug can make the application fetch that endpoint and return the credentials in a response. Mitigate by requiring the session-oriented version of the service, which makes the caller obtain a session token with a PUT and then send it as a header on each read, a combination forgery cannot produce; by setting the network hop limit to prevent relaying; and by disabling the endpoint on workloads that need no cloud credentials.
- Do we need a virtual firewall appliance in the cloud?
- Usually not as the primary control. Platform filtering is enforced per interface, so there is no chokepoint every packet must cross, and forcing traffic through an appliance creates a bottleneck, a failure point and per-gigabyte charges, often to inspect traffic that is encrypted anyway. Appliances make sense for a specific inspection or compliance requirement, layered on top of platform controls rather than replacing them.
- Can DNS be used to steal data from a cloud environment?
- Yes. Data can be encoded into resolution queries and answered by a server the attacker controls, and this route is often left open in estates that have otherwise restricted outbound traffic. If you constrain egress, also force workloads to use your own resolvers and log the queries. Resolution logs are one of the cheapest useful detection sources in a cloud account.
