Is EKS worth it when network costs get this high?

Start by separating the EKS management charge from the networking bill. Cross-zone traffic is not unique to managed Kubernetes, and a multi-zone layout can generate plenty of it if services frequently call endpoints in another zone.

Look at the busiest traffic paths and how workloads are placed. Node pool configuration and topology-aware routing can help keep some traffic local. Check the availability and capacity consequences before concentrating replicas in one zone, though. Lower transfer costs are not much comfort if a zone failure takes out the service.

For NAT, figure out which workloads are sending traffic through the gateway and where it's going before replacing anything. A self-managed NAT instance is one alternative, but you take on its maintenance and lose the managed gateway's vendor support. Compare the savings against the availability and operational work you need.

Dedicated hardware can be a good deal, but compare the whole setup, not just a server price against a cloud bill. Include networking, power, failure recovery, upgrades and on-call coverage. Also decide whether you actually need the same redundancy in both options. You might be willing to accept less availability for a much lower cost.

Running Kubernetes yourself is more work, but that doesn't automatically make it more expensive. The answer depends on the workload, team and scale.

There's a middle option too. Compare other managed Kubernetes providers and their transfer pricing before assuming the choice is EKS or operating everything yourself. Price the traffic patterns you actually have, not just the advertised node rates.

Also worth asking whether these workloads need Kubernetes at all. If they're simple and fairly stable, a simpler deployment setup on dedicated machines might remove both cluster overhead and some complexity. If you rely heavily on Kubernetes features, switching platforms is a bigger tradeoff.