Egress and Ingress

In plain words

Think of a building with one front door. Ingress is everyone walking in, and egress is everyone walking out. Security usually watches the people coming in, but a careful building also checks what leaves.

In computing, the door is a network boundary and the edge of your home network, a company's firewall, a cloud account or a Kubernetes cluster. Data entering through that boundary is ingress, and data leaving is egress.

The direction always depends on whose side you're on. When your server calls an API, the request is egress for you and ingress for the API provider. The response travels back the other way, so it's egress for the provider and ingress for you.

How they differ

Ingress and egress in security

Most attention goes to ingress by blocking unwanted connections and only opening the ports a service needs. Egress tends to be left open. Kubernetes is a common example. By default, a pod accepts all incoming connections and can make any outgoing one, until a NetworkPolicy that names Ingress or Egress isolates it.

Leaving egress can be risky too. A compromised server can send stolen data out, which MITRE ATT&CK lists as its own stage of an attack, called exfiltration. It can also connect to an attacker's server for instructions. Egress filtering limits a server to the destinations it actually needs, so both become harder.

Egress also becomes important to secure for servers that fetch URLs for users, such as webhooks, link previews, scrapers and file importers. Without limits, a user can point them at internal addresses, like the cloud metadata service at 169.254.169.254. This is called server-side request forgery, or SSRF. The usual defence blocks private and internal address ranges on the way out, checked against the address the hostname resolves to, not only the text of the URL.

Egress fees in the cloud

Cloud providers charge nothing for data coming in, and charge for most data going out. Moving data between zones and regions costs less than sending it to the internet, but it adds up for chatty services. A NAT gateway, which lets private servers reach the internet, adds its own charge per GB on top.

Egress fees became a competition issue because they make leaving expensive:

• Google Cloud in January 2024, then AWS in March 2024, stopped charging customers for data transferred out when they move to another provider. AWS gives credits for the move, and outside the EU now allows 180 days to complete it.
• The EU Data Act allows providers to charge only their direct costs for switching until 12 January 2027, and bans switching charges, including egress for the switch, from that date.
• The UK Competition and Markets Authority found in July 2025 that egress fees restrict switching and the use of more than one cloud. In March 2026, Amazon and Microsoft set out changes to their egress fees for UK customers, which the regulator is still reviewing.
• Cloudflare R2 object storage charges nothing for egress.

These changes mostly cover leaving a provider.

Kubernetes Ingress

In Kubernetes, Ingress is also the name of an API object. It routes HTTP and HTTPS traffic from outside the cluster to services inside it, with rules based on hostnames and paths, and can handle TLS. It needs an Ingress controller running in the cluster to do the work.

Ways to reduce egress costs

• Serve images, scripts and downloads through a CDN, so repeat requests are answered from its cache.
• Compress responses with gzip or Brotli.
• Keep services that talk to each other a lot in the same zone or region.
• Reach cloud storage through private endpoints instead of a NAT gateway. On AWS, gateway endpoints for S3 and DynamoDB have no extra charge.
• Fetch only what you need.
• Watch the bill by destination.

Limitations

• The labels depend on where you draw the boundary. The same traffic is egress for one team and ingress for another, which confuses reports and budgets.
• Every connection carries traffic both ways. Stateless rules, such as network ACLs on AWS, need the replies allowed too, so blocking egress can break traffic that started as ingress.
• Strict egress allow lists are hard to keep up to date when services call many third-party APIs whose addresses change.
• Prices vary by provider, region and volume, so a rough estimate can be far off for a large or global workload.