Ingress & Egress

What are ingress and egress?

Ingress is traffic entering your network or resource; egress is traffic leaving it. The terms are perspectival — one service’s egress is another’s ingress — and they anchor three separate domains that all bill or filter by direction: security rules (security groups define ingress and egress rule sets independently), Kubernetes objects (Ingress controllers route inbound HTTP; NetworkPolicies constrain both directions), and — most consequentially — cloud pricing.

The asymmetry that funds cloud providers

Data into major clouds is free; data out costs roughly $0.09/GB to the internet (less at volume, more in some regions). That asymmetry is strategic — cheap to arrive, expensive to leave — and it silently shapes architecture: serving 100 TB/month of media from EC2 directly costs ~$9,000 in egress alone, which is why CDNs front origins (cheaper per-GB, absorbs the hit at edge), why cross-region replication gets budgeted carefully, and why “multi-cloud” designs that shuttle data between providers pay egress twice. Even internal direction matters: cross-AZ transfer bills ~$0.01/GB each way, so chatty microservices spread across zones generate a steady hum of charges.

Egress as a security control

Most teams filter ingress obsessively and leave egress open — yet data exfiltration, C2 callbacks, and prompt-injection-driven leaks all ride outbound connections. Restricting egress (allowlisted destinations, egress proxies, VPC endpoints instead of open internet) is the underused half of network security, and increasingly mandatory around AI agents.

What people get wrong

• Modeling costs from ingress-side thinking — the bill lives on the way out.
• 0.0.0.0/0 egress everywhere by default, making exfiltration a first-class feature.
• Forgetting NAT stacks on top: private-subnet egress pays NAT processing plus internet egress.

Primary source: AWS — data transfer pricing