Skip to content
Back to glossary
Cloud Networking

What is Egress?

Egress traffic is the outbound flow from a cluster or cloud to the outside. A major source of hidden costs and security risks on hyperscalers.

What egress traffic is

In the cloud and Kubernetes context, egress denotes any network traffic that leaves a perimeter toward an external recipient: an API call to a third party from a pod, a container-image download, data export to a B2B customer, backup to another cloud, DNS query to the internet. The reverse, ingress, denotes inbound traffic.

For a DevOps team, egress is managed from two independent angles: cost (billed per gigabyte by cloud providers) and security (each outbound flow is a potential data-exfiltration channel).

The financial impact at hyperscalers

Egress is one of the most opaque and volatile costs at AWS, Azure and GCP. Typical orders of magnitude in 2026:

  • Egress from AWS to the internet: 0.09 USD/GB for the first terabytes, decreasing afterwards. The 1st TB is billed around 92 USD; the 10th, around 850 USD.
  • Egress between AWS regions: 0.02 USD/GB, or 20 USD per terabyte.
  • Egress between AZs of the same region: 0.01 USD/GB. Often forgotten, but 1 TB of inter-AZ replication costs 10 USD per month per replicated terabyte.

The cumulative effect can be surprising: a video service that delivers 50 TB/month to users typically pays 4,000 to 5,000 USD/month for egress alone, sometimes more than the compute itself.

That is what drives the rise of alternatives with no egress fees: Cloudflare R2, Hetzner, OVH Storage, and several Swiss clouds including Hikube. On Hikube, internet egress is included in the plans, which makes costs predictable for outbound-heavy workloads (media, IoT, multi-cloud).

The security angle

Every egress flow leaving a cluster is a potential exfiltration channel. An attacker who takes control of a pod (via an application vulnerability) can exfiltrate the database accessible through a POST to an external server. Without egress control, that exfiltration goes unnoticed.

Best practices observed at Hidora:

Egress NetworkPolicies. Restrict all outbound traffic from pods by default, then explicitly allow legitimate destinations (business external API, image registry, internal DNS). Cilium and Calico support this natively.

Egress gateway. Force all outbound traffic through a dedicated node (Istio, Cilium Egress Gateway). This enables audit, logging and L7-policy enforcement (allow only certain domains, certain HTTP methods).

DNS filtering. Block resolution of unauthorised domains. An attacker exfiltrating to evil.example.com is stopped if internal DNS refuses the resolution.

TLS inspection. For the most sensitive environments, decrypt egress traffic and inspect it (DLP). Invasive practice, reserved for regulated sectors.

Egress and multi-cloud architectures

A multi-cloud strategy (workloads spread across AWS, Hikube, Azure) implies inter-cloud egress traffic. Cumulative costs can make a multi-cloud architecture economically unfavourable if poorly designed. Practical recommendations:

  • Keep data close to compute: avoid referencing a Hikube-hosted PostgreSQL database from AWS compute.
  • Async, compressed replication between clouds to limit volume.
  • Measure egress monthly with tags per project/team, integrated into FinOps dashboards.

Related Hidora services

  • Consulting: egress FinOps audit, NetworkPolicy design, cost-controlled multi-cloud architecture.
  • Hikube: Swiss cloud with egress included in plans, an economic alternative to hyperscalers for outbound-heavy workloads.
  • Managed Services: operation of egress controls in production with anomaly alerting.
  • FinOps, Sovereign Cloud, Cilium: associated building blocks.