- 01Default-deny egress is one of the highest-leverage controls available — both for malware C2 prevention and for exfiltration mitigation. The reason most environments do not have it is operational cost.
- 02The model: per-VPC or per-namespace egress proxy, all outbound through the proxy, declarative allowlist per workload in code, log + alert on every denial and every novel allowed destination.
- 03Operational cost is real: weeks of allowlist construction per service, every dependency change is a potential new destination, 'why is my deploy failing?' becomes a top support question, proxy adds latency.
- 04Highest-value first: crown-jewel workloads (PCI, ePHI, source code), agent-running workloads (AI agents that can call arbitrary URLs), and any workload running third-party code. Build the discipline there, then expand outward.
Most cloud workloads have wide-open egress. Default-deny egress is one of the highest-leverage controls available, both for malware command-and-control prevention and for exfiltration mitigation. The reason most environments do not have it is operational cost.
The model
Per-VPC or per-namespace egress proxy. All outbound traffic flows through the proxy. Allowlist of permitted destinations per workload, expressed declaratively in code. Logging and alerting on every denied request and every novel allowed destination.
The operational cost
- 01Initial allowlist construction — weeks of discovery per service
- 02Ongoing maintenance — every dependency change is potentially a new destination
- 03Engineer education — 'why is my deploy failing?' becomes a top support question
- 04Performance — the proxy adds latency; budget for it
Where the value is highest
Crown-jewel workloads (PCI, ePHI, source code), agent-running workloads (AI agents that can call arbitrary URLs), and any workload running third-party code. Build the proxy and discipline there first; expand outward as the team's tolerance for change grows.