A team of four runs five Spring Boot services on EKS, which they adopted 'because everyone uses Kubernetes'. The AWS bill doubled in six months; the largest surprise lines are NAT gateway data processing, cross-AZ data transfer, CloudWatch Logs and a long tail of EBS volumes and snapshots. Leadership asks you whether to move platforms and how to control the bill. What do you recommend, and why?

Separate the two questions, because most of the bill is not the platform. Platform: the compute choice should follow the team. For four people and five services, ECS on Fargate removes the cluster, the node groups and the Kubernetes upgrade cycle, keeps the Docker knowledge whole, and gives rolling deployments with health checks; EKS earns its cost when an organisation is standardising on Kubernetes or already has the skills. A move is worth it only if the operational load, not the bill, is the pain, and it should be planned, not reactive. Bill: the named lines are architecture and hygiene. NAT processing falls with VPC endpoints (a gateway endpoint for S3, interface endpoints for ECR and others); cross-AZ transfer falls with zone-aware traffic where it is safe; CloudWatch Logs falls with retention and less noisy logging; orphaned volumes and snapshots fall with tags and a regular sweep. Then tag everything, set a budget alarm, right-size from metrics, and cover the steady baseline with a Savings Plan.