Cloud Egress Filtering: AWS, Google Cloud and Azure

Most cloud networks still let any workload connect to any address on the internet, so a single compromised container, build runner or stolen credential can send data anywhere and fetch any tool it likes. Cloud defaults lean towards open outbound access: Google Cloud VPC networks have an implied allow egress rule, AWS security groups allow all outbound traffic unless you change them, and Azure makes new virtual networks use private subnets by default only from the API version released after 31 March 2026 (and in the portal), while existing networks and older templates keep default outbound access. Egress filtering closes that gap by allowing workloads to reach only the destinations they need. This guide goes deeper than the Cloud Network Security Guide on outbound control: NAT, FQDN filtering, DNS-layer filtering, egress proxies and Kubernetes egress, with a rollout approach that does not break production. It covers Amazon Web Services (AWS), Google Cloud and Microsoft Azure; providers are listed alphabetically and the order is not a ranking.

Key takeaways

NAT is not a filter. A NAT gateway hides private addresses and blocks unsolicited inbound connections, but it forwards outbound traffic to any destination your routes and firewall rules allow.
Layer DNS, FQDN and proxy controls. DNS filtering stops name resolution, FQDN rules on a firewall check the SNI or Host header, and an explicit proxy can enforce full URLs and workload identity. Each closes gaps the others leave.
Domain rules are only as strong as what they inspect. SNI and Host headers can be set by the client, so pair them with DNS controls and resolved-IP checks, and drop traffic to raw IP addresses.
Start in alert mode with real flow data. Build the allowlist from DNS and flow logs, run it in log-only mode, then enforce per environment with a fast rollback.
Egress control is an identity control too. It limits where a stolen workload credential can be used from and where secrets can be sent, which is why CI runners and AI agents deserve the strictest lists.

Why outbound control matters

Outbound connections are how attacks complete. Malware calls home, attackers download tooling, and stolen data leaves over HTTPS, DNS or cloud storage APIs. MITRE ATT&CK techniques that egress filtering directly constrains include T1567 Exfiltration Over Web Service, T1048 Exfiltration Over Alternative Protocol, T1071.004 Application Layer Protocol: DNS, T1090 Proxy and T1537 Transfer Data to Cloud Account.

The Codecov breach is the clearest example: a modified uploader script ran in customers' CI pipelines and used a single HTTP POST to send the job's environment variables, including secrets, to an attacker-controlled server. Build runners restricted to a short list of required destinations would have blocked or flagged that request. The Data Exfiltration Guide covers detection of exfiltration more broadly.

The building blocks

Control	What it decides on	Strengths	Gaps
Security groups and firewall rules (L3/L4)	Destination IP, port, protocol	Cheap, everywhere, stateful	Cloud services and SaaS change IPs; cannot express domains
NAT gateway	Nothing (translation only)	Stable, known source IPs; no inbound exposure	No filtering; logs show flows, not intent
DNS-layer filtering	Domain name in the DNS query	Blocks resolution of bad or unapproved domains; covers DNS tunnelling	Bypassed by hard-coded IPs or a resolver the filter does not see
FQDN filtering on a firewall	TLS SNI or HTTP Host header; resolved domain for other protocols	Domain allowlists without TLS decryption	Client-supplied names can be forged; path-level rules need TLS inspection
Explicit or next-hop egress proxy	Host, URL, method, headers, workload identity	Full URL control and identity-aware rules; rich logs	Clients must be configured or routed; TLS inspection needs certificate trust
Private endpoints for cloud services	Traffic never leaves the provider network	Removes the need to allow broad provider service ranges	Does not stop access to an attacker's own account on the same service without endpoint policies

Provider controls compared

Amazon Web Services

AWS Network Firewall domain lists: stateful domain list rule groups act as allowlists or denylists. Target type TLS_SNI matches HTTPS by SNI, HTTP_HOST matches HTTP by Host header, and AWS_ROUTE_53_RESOLVED_DOMAIN matches any protocol by the domain the destination IP was resolved for. An allowlist denies other traffic of the listed protocols under default action order. A leading dot (.example.com) covers the domain and its subdomains. AWS notes the firewall matches on SNI or Host rather than IP and does no out-of-band DNS lookups, so it recommends adding IP-based rules or the resolved-domain target where headers might be manipulated. By default HOME_NET is the firewall VPC's CIDR, so traffic from other VPCs arriving through a transit gateway is not filtered by domain rules until you extend it. AWS also advises against combining Reject or Alert domain list groups with Allow groups. More detail is in the AWS Network Firewall guide.
Route 53 Resolver DNS Firewall: filters outbound DNS queries from VPCs that use the Route 53 VPC Resolver, with rule actions ALLOW, BLOCK and ALERT and either your own domain lists or AWS-managed lists. AWS describes both a denylist approach and a deny-all-except-trusted approach, and notes that Network Firewall cannot see these Resolver queries. Used together, Network Firewall can validate that a connection's destination IP was actually returned by the Resolver. AWS Firewall Manager can apply rule group associations across accounts in AWS Organizations.
NAT gateways and security groups: NAT gateways translate addresses for private subnets; filtering comes from security group egress rules, network ACLs and the firewall in the route path.

Google Cloud

Cloud NGFW firewall policies: VPC networks have an implied allow egress rule, which deny egress rules override. Firewall policies support FQDN objects to filter traffic to or from specific domains and geolocation objects to filter external traffic by location; Google notes both may incur Cloud NGFW Standard data processing charges. Egress to external addresses on TCP port 25 is blocked by default. Traffic to the metadata server at 169.254.169.254 is always allowed and not subject to firewall rules.
Secure Web Proxy: a managed egress proxy for HTTP and HTTPS with a default deny-all posture. It runs as an explicit proxy, as a next hop that routing sends traffic to without per-client configuration, or through a Private Service Connect service attachment for multi-VPC designs. Sources can be identified by secure tags, service accounts, IP addresses or mTLS client certificate identities. Hostname and URL rules apply to unencrypted HTTP or when TLS inspection is enabled. Google lists IPv4 only and no HTTP/3 support.
Cloud NAT and Cloud DNS: Cloud NAT is a distributed, software-defined service with no proxy VMs; it accepts only established response traffic inbound, and Google states that outbound access remains subject to egress firewall rules. Manual NAT IP assignment gives partners a known set of source addresses. Cloud DNS response policies let private DNS return chosen records for selected names, for example pointing Google API names at restricted endpoints.

Microsoft Azure

Azure Firewall FQDN filtering: application rules use a transparent proxy and the SNI header for HTTP/S and MSSQL and can distinguish two FQDNs that share an IP address; Microsoft recommends them where possible, with FQDN tags for services such as Azure Backup. Network rules can filter FQDNs for any TCP or UDP protocol (for example NTP, SSH, RDP) but need DNS Proxy enabled, do not support wildcards, and cannot distinguish names sharing an IP. Network rule FQDNs are re-resolved every 15 seconds and old IPs expire 15 minutes after DNS stops returning them.
Azure Firewall Premium: adds outbound and east-west TLS inspection using a customer-provided CA, URL filtering on the full path, web categories matched on the full URL and signature-based IDPS. HTTPS URL filtering requires TLS inspection on the application rule.
Azure DNS security policy: filters and logs DNS queries per virtual network with Allow, Block and Alert actions on domain lists (wildcards allowed, CNAME chains followed) and an optional Microsoft threat intelligence feed. A policy applies to virtual networks in its own region, and each virtual network links to one policy. Microsoft warns that a rule on the root domain can break required Azure services.
Default outbound access and NAT Gateway: VMs without an explicit outbound method have historically received a Microsoft-owned default outbound IP. For API versions released after 31 March 2026, subnets in new virtual networks default to private (defaultOutboundAccess false); existing virtual networks are unchanged. Microsoft recommends an explicit method, with NAT Gateway the default choice, or a firewall reached through a user-defined route.

Availability notes

AWS: Network Firewall and DNS Firewall are separately priced services.
Google Cloud: FQDN and geolocation objects fall under Cloud NGFW Standard pricing; Secure Web Proxy is separately priced and deployed in a host project, not a service project.
Microsoft Azure: TLS inspection, URL filtering and IDPS require the Premium SKU, and the policy SKU must match the firewall SKU.

Reference architectures

Centralised inspection: spoke VPCs or virtual networks route default traffic through a hub with the firewall and NAT (AWS Transit Gateway with Network Firewall, Azure hub with Azure Firewall, Google Cloud with Secure Web Proxy as next hop or Cloud NGFW policies). One policy, one log stream; watch cross-zone data charges and make the hub highly available.
Distributed per-VPC controls: each workload network has its own firewall and NAT. Smaller blast radius and simpler routing, more policy instances to keep consistent; use central policy management (AWS Firewall Manager, Azure Firewall Manager policy, hierarchical firewall policies in Google Cloud).
No internet path at all: for the most sensitive workloads, remove the default route and NAT, use private endpoints for cloud services, and reach approved external destinations only through an explicit proxy. This is the strongest pattern and the easiest to reason about.
Small organisations: start with DNS-layer filtering and a single managed firewall or proxy in front of production; defer per-application URL policies until you have the logs to build them.

Kubernetes and container egress

Pods inherit the node's egress path, so cloud-level controls see the node address, not the workload. Add controls inside the cluster:

NetworkPolicy egress rules: a default-deny egress policy per namespace, then allow cluster DNS and named destinations. The core Kubernetes NetworkPolicy API matches IP blocks, pods and namespaces, not domain names; FQDN policies need a CNI plugin that offers them or an egress gateway.
Egress gateway or proxy: route namespace traffic through a dedicated egress gateway or an explicit proxy so cloud firewalls and proxies can apply identity-aware rules per workload.
Protect the metadata endpoint: block pod access to the instance metadata service unless needed, since it hands out node credentials. See the Kubernetes Security Guide.
AI agents and code runners: sandboxes that run generated code need deny-by-default egress with a short allowlist; see the Agent Egress Control and Network Isolation Guide.

Where identity fits

Egress filtering is a backstop for non-human identity risk. A leaked cloud key used from inside your network can only reach the destinations your egress policy allows, and a malicious dependency that harvests tokens has fewer places to send them. Use private endpoints with endpoint policies so workloads can reach only your own storage accounts and buckets, not any account on the same service, which is the usual route for T1537. Identity-aware proxy rules (service accounts and secure tags in Secure Web Proxy, for example) let you give a build runner and a payments service different allowlists on the same network. See the Kubernetes NHI Security Guide for workload identity design.

Implementation: a phased approach

Turn on visibility: enable DNS query logging and flow logs (VPC Flow Logs on AWS and Google Cloud, virtual network flow logs on Azure) and firewall or proxy logs in alert mode. Collect at least two to four weeks to cover monthly jobs.
Build the inventory: group destinations by workload and owner: cloud provider APIs, package registries, SaaS APIs, partners, update services. Replace provider API traffic with private endpoints where possible.
Close the easy gaps first: block outbound DNS to anything but your resolvers (TCP and UDP 53, and DNS over HTTPS endpoints at the proxy), block SMTP from workloads that do not send mail, and drop direct-to-IP HTTPS where SNI is absent.
Apply DNS filtering: threat intelligence blocklists everywhere, then deny-all-except-trusted for the most sensitive networks.
Enforce FQDN allowlists in alert mode: log what would be blocked for each environment, fix gaps, then switch to enforce, starting with CI runners and production databases, then the rest.
Add the proxy where you need URLs or identity: next-hop or explicit proxy with TLS inspection only where policy needs paths or content, with exclusions for categories that must not be decrypted.
Roll back safely: keep a pre-approved change that switches the rule group or policy back to alert mode; test it in staging. Track every exception with an owner and an expiry date.

Detection and measurement

Alert on: blocked DNS lookups for newly registered or high-entropy domains, unusually long or frequent TXT queries, connections to raw IPs on 443, large outbound transfers from databases or runners, and new destinations from production workloads.
Watch the controls themselves: changes to firewall policies, rule groups, route tables and DNS firewall associations are high-value events. See the DNS Logging and Detection Guide.

Metric	Target
Production workloads behind an enforced egress allowlist	Rising quarter on quarter, 100% for tier 1
Networks where DNS can bypass the filtered resolver	Zero
Allowlist exceptions past their expiry date	Zero
Time from new destination request to approved rule	Short enough that teams do not route around the control
Subnets with implicit or default outbound internet access	Zero

Framework mapping

Framework	Reference	Egress application
NIST SP 800-53 Rev. 5	SC-7, SC-7(5), AC-4, SI-4	Boundary protection, deny by default and allow by exception, information flow enforcement, monitoring outbound traffic
NIST CSF 2.0	PR.IR-01, DE.CM-01	Networks protected from unauthorised use; network monitoring for adverse events
CIS Controls v8.1	Control 13 Network Monitoring and Defense; Control 9 Email and Web Browser Protections (DNS filtering)	Filtering and monitoring traffic flows; DNS filtering services
ISO/IEC 27001:2022	Annex A 8.20 Networks security, 8.22 Segregation of networks, 8.23 Web filtering, 8.12 Data leakage prevention	Controlled network paths and restricted external access
MITRE ATT&CK	T1567, T1048, T1071.004, T1090, T1537	Exfiltration and command and control paths constrained by egress policy

Common failure patterns

Treating NAT as security: private subnets behind a NAT gateway with security groups that allow all outbound traffic; the network looks segmented but anything can leave.
DNS bypass: workloads using public resolvers or DNS over HTTPS directly, so the DNS firewall never sees the queries.
SNI-only trust: allowlisting by SNI without resolved-IP validation or DNS controls, so a client can present an allowed name while connecting to an attacker's IP.
Allowing whole provider ranges: permitting all of a cloud provider's storage endpoints, which also allows uploads to the attacker's own account on the same service.
Uninspected spokes: traffic from peered or transit-attached networks that never reaches the firewall, or is not in its home network definition.
CI runners left open: build systems with full internet access and production secrets, the exact path used in the Codecov breach.

Practitioner checklist

Every subnet has an explicit, documented outbound path; no default or implicit internet access remains.
Security group and firewall egress defaults are deny, with exceptions owned and time-bound.
Only approved resolvers can be used, and DNS-layer filtering with logging is on in every network.
FQDN allowlists are enforced for CI runners, databases and tier 1 workloads, with resolved-IP or DNS validation alongside SNI matching.
Cloud service access uses private endpoints with policies that restrict to your own accounts and resources.
Kubernetes namespaces have default-deny egress NetworkPolicies and pod access to instance metadata is restricted.
Firewall, proxy, DNS and flow logs reach the SIEM, with alerts for policy changes and anomalous egress.
A tested rollback switches enforcement to alert mode within minutes.

Standards and references

Related NHI Mgmt Group resources: Cloud Network Security Guide · NAT and Its Security Implications Guide · Data Exfiltration Guide · DNS Security Guide

Cloud Egress Filtering: Control Outbound Traffic From Cloud Workloads