Egress Traffic Control in Cloud Environments: A Practical Guide

Egress traffic control in cloud environments means forcing every outbound connection from your workloads through explicit, default-deny rules that permit only known destinations on known ports — because the most damaging cloud incidents are not intrusions that get in, but data that gets out. Attackers who obtain a foothold in a virtual machine, container or serverless function almost immediately try to reach command-and-control infrastructure, move laterally to internal services, or exfiltrate data to external endpoints they control. In cloud environments, where workloads spin up and down automatically and IP addresses change constantly, permissive outbound rules silently widen the blast radius of every other control you own. This guide covers the control layers available on AWS and Azure, the threat behaviors you are defending against, and a deployment order that avoids breaking production.

Why Egress Is the Weak Side

Most cloud security programs concentrate on ingress: who can reach the application, which ports are exposed, which identities can assume roles. But once an attacker is inside, the direction that matters is outbound. MITRE ATT&CK documents exfiltration over web services as a distinct technique (T1567), where adversaries transfer data to legitimate external services such as cloud storage, code repositories or file-sharing platforms precisely because that traffic blends in with normal HTTPS patterns. When outbound access is unrestricted, defenders lose the cheapest interception point available: the network boundary of the subnet or virtual network. Restricting egress does not replace identity controls, workload hardening or secrets management — it removes the assumption that a compromised workload can talk to the entire internet at will, which is exactly the assumption attackers exploit.

Zero trust principles reinforce this posture. NIST Special Publication 800-207, Zero Trust Architecture, published in August 2020, states that enterprises should not trust any network traffic by default, whether it originates inside or outside the perimeter. Applied to cloud networking, that principle translates into a concrete rule: no subnet, namespace or workload gets unrestricted outbound access unless someone explicitly wrote a rule allowing it.

Native Controls Compared

Each major provider offers overlapping but not identical primitives for filtering outbound traffic, and choosing the right mix requires understanding where each one evaluates connections. On AWS, network access control lists allow or deny specific inbound or outbound traffic at the subnet level, while security groups apply stateful filtering at the instance network interface. On Azure, a network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources, evaluated against five-tuple information.

Two platform behaviors deserve attention before you write rules. AWS network ACLs are stateless: allowing inbound traffic to a subnet does not automatically allow the responses to leave, so egress rules must mirror the return path for every permitted flow. Azure is the opposite direction of risk: by default, every network security group ships with a default AllowInternetOutBound rule at priority 65001 that permits all outbound traffic to the Internet service tag, which means an NSG with no custom outbound rules is an open egress door, not a closed one. Closing that door requires custom deny rules at lower priority numbers that override the platform default.

There are also blind spots the native L3/L4 filters cannot see. AWS documents that network ACLs cannot block DNS requests to the Route 53 Resolver, so DNS-based exfiltration channels require Route 53 Resolver DNS Firewall instead of NACL rules. Similarly, NACLs cannot block traffic to the EC2 instance metadata service, which must be constrained at the instance configuration level. Egress control at layer 3/4 constrains where packets can go; it does not inspect what an allowed HTTPS connection carries, which is why destination allow lists need to be paired with DNS filtering, TLS inspection points or egress proxies for high-value environments.

Threats This Blocks

The failure modes that default-deny egress directly interrupts are well characterized. First, command-and-control: post-exploitation frameworks beacon to hardcoded or generated domains, and an allow list of approved SaaS and API endpoints turns that beacon into an auditable failure instead of a silent channel. Second, lateral movement to cloud metadata and management endpoints: restricting outbound reach from application tiers to instance metadata services and cross-account destinations limits what stolen credentials from one workload can reach. Third, exfiltration over web services: if a workload has no business uploading to arbitrary external storage accounts, a destination allow list stops the transfer at the network layer even when endpoint detection missed the initial compromise. Fourth, supply-chain callbacks: compromised dependencies often fetch second-stage payloads from attacker-controlled hosts, and an egress policy scoped to the package registries and mirrors your build actually uses cuts that path.

The pattern pairs naturally with least-privilege identity. Network egress rules answer which destinations a workload can reach; IAM policies answer which actions it can perform once there. Attackers who chain both must defeat two independent control planes, which is the practical definition of defense in depth.

Deployment Procedure

Rolling out egress control without an outage follows a observe, scope, restrict, verify loop. The ordered sequence below has been applied successfully in environments running mixed compute:

1. Observe flows — enable VPC flow logs (AWS) or virtual network flow logs (Azure) and collect 14 to 30 days of outbound traffic per subnet, building the true destination inventory including service IPs behind service tags.
2. Baseline with low priority — in Azure, create outbound allow rules for observed destinations at priority numbers below 65000, then add a deny-all-outbound rule; in AWS, attach a custom NACL with allow rules mirroring observed flows before any deny.
3. Use platform groupings — express destinations with Azure service tags and application security groups, and AWS prefix lists for managed services, so allow lists track provider IP changes without manual edits.
5. Apply allow lists per tier, not per account — start with non-production subnets, measure breakage, then promote rule sets through staging to production with a rollback window.
6. Filter DNS — deploy Route 53 Resolver DNS Firewall or equivalent Azure DNS proxies to block known-malicious and newly-registered domains, closing the channel NACLs cannot see.
7. Alert on denies — route flow log denies to your SIEM; a spike in denied egress from one workload is an early indicator of compromise, not just a configuration error.
8. Review on cadence — reconcile the allow list against new dependencies every sprint; stale allow entries are silent debt.

Two trade-offs are worth naming. Operational overhead is real: every new external dependency becomes a change request, which is why scoped service tags matter more than raw CIDR lists. And layer-4 rules cannot distinguish destinations behind shared CDNs, so an allow entry for a popular SaaS may cover adjacent infrastructure you did not intend to permit — mitigated with SNI-aware proxies or private endpoints for critical services.

Checklist Before Enforcement

• Flow logs collected long enough to cover monthly batch jobs and patch cycles
• Deny rules tested in audit mode or low-priority shadow before hard enforcement
• Rollback procedure documented, including how to re-enable broad egress under incident pressure
• DNS filtering deployed, since name resolution is the most common covert channel
• Metadata service access restricted via instance configuration, not network ACLs
• Internal service communication covered by identity controls such as IAM least privilege implementation and secrets management strategy, so egress rules are one layer among several
• Capacity gating for outbound access to third-party AI services considered, as covered in capability gating as access control

Sources

• AWS — Control subnet traffic with network access control lists
• Microsoft — Azure network security groups overview
• NIST — Special Publication 800-207, Zero Trust Architecture
• MITRE ATT&CK — Exfiltration Over Web Service (T1567)