Egress & exfiltration paths
Egress control is about what your workloads can reach on the way out, not what the internet can reach on the way in. Nearly every cloud network is provisioned with unrestricted outbound by default: an AWS security group, an Azure NSG, and a GCP VPC firewall all allow a resource to open a connection to any destination on the internet unless someone deliberately narrows it. That default is convenient for engineers and equally convenient for an attacker, because a compromised instance, a leaked function, or a malicious dependency uses the same open path to phone home and to move data out. This sub-topic examines outbound as a first-class control surface: whether destinations are constrained to a known allowlist, whether provider services are reached over private links instead of the public internet, and whether DNS and flow telemetry would surface an anomalous outbound flow before it became a breach notification.
Overview
What this check looks like in practice
Outbound traffic gets far less attention than inbound, yet it is the path stolen data and command-and-control channels use to leave. Most cloud environments allow unrestricted egress by default, so a compromised workload can reach any destination on the internet without triggering a control. We assess whether outbound is constrained to known destinations and whether cloud provider services are reached over private paths rather than the public internet.
Why it matters
To an attacker, egress is the exit — data theft, ransomware key exchange, and command-and-control beaconing all depend on a workload being able to reach an external destination, and unrestricted outbound means none of it trips a control. Exfiltration rarely looks dramatic on the wire: it often rides ordinary HTTPS to a cloud storage bucket, or is tunneled through DNS queries to a lookalike domain, precisely because those channels are usually left open and unmonitored. Auditors and cyber insurers increasingly treat outbound filtering as a required control rather than a nicety, because it is one of the few mechanisms that limits damage after the initial compromise has already happened. A single interface endpoint or FQDN allowlist can be the difference between an isolated incident and a full data-loss event, which is why egress findings map directly to PCI-DSS outbound firewall requirements, NIST CSF data-security and detection controls, and ISO 27001 network security controls.
What we assess
What we look for
- Workloads with unrestricted outbound (0.0.0.0/0 and ::/0) that in practice only need a handful of destinations such as an update repository or a payment API
- Absence of any egress inspection point — no proxy, no next-generation firewall, and no FQDN or domain allowlist constraining where traffic can go
- Provider service traffic (object storage, databases, secrets, queues) routed over the public internet via NAT instead of private endpoints or private service access
- Sensitive or regulated workloads placed in subnets with a direct route to an internet or NAT gateway and no forced-tunneling to an inspection layer
- DNS resolution left unfiltered, with no DNS firewall or query logging to catch domain-generation-algorithm lookups or DNS-tunneling exfiltration
- Missing VPC/VNet flow logs, or flow logs collected but never analyzed for volumetric spikes or connections to unfamiliar destinations
- No data-perimeter control (such as a VPC Service Controls perimeter or an equivalent identity/resource boundary) preventing authorized credentials from copying data to storage in an attacker-controlled project or account
- Threat-intelligence-based outbound filtering disabled, so known command-and-control and malware endpoints remain reachable from production
Across your clouds
AWS, Azure & Google Cloud
AWS
Egress is governed by stateful security group outbound rules and stateless network ACLs, with NAT gateways and egress-only internet gateways carrying traffic out. Tightening it means replacing broad NAT egress with VPC gateway endpoints (S3, DynamoDB) and interface endpoints (the latter via PrivateLink) for AWS services, adding AWS Network Firewall with Suricata rules or domain allowlists plus Route 53 Resolver DNS Firewall for name-based filtering, and using GuardDuty and VPC Flow Logs to surface beaconing and known-bad destinations.
Azure
Outbound is shaped by NSG rules, user-defined routes that force-tunnel traffic to Azure Firewall, and the retirement of default outbound access for new deployments. Azure Firewall enforces FQDN-based application rules, threat-intelligence filtering, and IDPS, while Private Endpoints and Private Link keep PaaS traffic (Storage, SQL, Key Vault) off the public internet; VNet flow logs and Azure DNS security policy query logging (or Azure Firewall DNS proxy) provide the outbound telemetry.
Google Cloud
VPC firewall rules and hierarchical firewall policies default to allowing all egress, with Cloud NAT providing outbound reach. Constraining it means FQDN-based Cloud NGFW policies or Secure Web Proxy for allowlisting, Private Google Access and Private Service Connect to keep Google API traffic private, and — critically for exfiltration — VPC Service Controls perimeters that stop valid credentials from moving data to unauthorized projects, backed by VPC Flow Logs and Cloud DNS query logging.
Example finding
Production database subnet has unrestricted egress and reaches storage over the public internet
Risk: A workload holding regulated data can open an outbound connection to any destination on the internet, and its calls to object storage traverse a NAT gateway over the public path rather than a private endpoint. If the workload or its credentials are compromised, data can be copied to an attacker-controlled bucket over ordinary HTTPS with no allowlist to block it and no inspection point to notice — a textbook exfiltration channel that leaves only a NAT log entry.
Fix: Restrict the subnet's egress to an explicit destination allowlist, route provider-service traffic through private endpoints so it never touches the public internet, and place an inspection point (a next-generation firewall or proxy with FQDN filtering) in the outbound path. Where the platform supports it, add a data-perimeter control so credentials cannot write to storage outside your own accounts or projects.
Remediation
How to close it
- 1 Baseline current outbound behavior from flow logs and DNS logs to learn the destinations each workload legitimately needs before you start restricting — build the allowlist from evidence, not guesswork.
- 2 Replace public-internet paths to provider services with private connectivity: VPC/interface endpoints on AWS, Private Endpoints on Azure, and Private Google Access or Private Service Connect on GCP, so storage, database, and secrets traffic never leaves the provider backbone.
- 3 Introduce an egress inspection point — AWS Network Firewall, Azure Firewall, or GCP Cloud NGFW/Secure Web Proxy — and force outbound traffic through it with route tables or user-defined routes.
- 4 Convert broad outbound rules to explicit FQDN or CIDR allowlists per workload tier, and enable threat-intelligence-based filtering so known command-and-control and malware endpoints are blocked by default.
- 5 Turn on DNS firewalling and query logging to catch DNS tunneling and domain-generation-algorithm lookups, and wire volumetric and new-destination alerts off flow logs into the team that would actually respond.
- 6 For regulated data, add a data-perimeter control such as a GCP VPC Service Controls perimeter (or the equivalent identity and resource-boundary conditions on AWS and Azure) so valid credentials cannot move data to storage outside your authorized accounts or projects.
Questions
Isn't blocking inbound enough — why lock down outbound too?
Inbound controls stop the initial intrusion, but they do nothing once an attacker is already inside or once a credential leaks. Egress control is the layer that limits damage after that point: it is what keeps a compromised workload from beaconing to command-and-control or copying data to an external destination. Defense in depth means controlling both directions, and outbound is the one most environments leave wide open.
Why does routing traffic to storage and databases over private endpoints matter so much?
Provider service traffic — to object storage, managed databases, secrets managers, and queues — is the most common exfiltration channel precisely because it looks legitimate. Routing it over private endpoints keeps it on the provider's backbone instead of the public internet, which both removes an attacker's easy exit and lets you deny general internet egress without breaking the services your workloads actually depend on. It is usually the highest-leverage first step in tightening egress.
Will restricting egress break our applications?
It can if you restrict blind, which is why the safe path is to baseline real outbound behavior from flow and DNS logs first, build an allowlist from what workloads actually contact, and roll out in monitor-then-enforce mode. This is a read-only health check, so we identify where egress is unconstrained and hand you the destination inventory and a staged plan — we do not change any rules in your environment.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
