Select Language:

If you’re running an Amazon EKS cluster and want to cut down on data transfer costs between Availability Zones (AZs), there’s a simple trick you can use with Kubernetes Services called Traffic Distribution. This method helps you keep the traffic within the same AZ whenever possible, while still ensuring your application remains highly available.

The best part is that if you don’t plan to use Istio or another service mesh, just sticking with Traffic Distribution through Kubernetes Services is enough. It’s well-documented and straightforward to implement.

Here’s how you can do it:

First, you need to set your service to prefer routing traffic to local endpoints. To accomplish this, add a traffic distribution setting called “PreferClose” to your service configuration. This setting guides traffic to endpoints that are in the same AZ as the client, reducing costly cross-AZ data transfer.

Here’s an example of what your service configuration should look like:

yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:

port: 80
targetPort: 8080
trafficDistribution: PreferClose

Next, make sure each of your nodes is correctly labeled with the zone they belong to. Usually, EKS handles this automatically, but it’s good to check:

bash
kubectl get nodes –show-labels | grep topology.kubernetes.io/zone

Now, you should configure your application deployment in a way that awareness of zones is built-in. This helps Kubernetes to spread your pods across AZs properly. Use topologySpreadConstraints like this in your deployment file:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 6 # For example, 2 pods per AZ
template:
spec:
topologySpreadConstraints:

maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: my-app

In some cases, especially if you expect varying traffic loads in different zones, it’s smart to scale each AZ independently. This means creating separate deployments for each AZ, each with its own Horizontal Pod Autoscaler (HPA). For example, you might have different deployment and HPA configurations for “us-east-1a”, “us-east-1b”, and “us-east-1c”. Each deployment targets a specific zone through a node selector:

yaml

Deployment for us-east-1a

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-us-east-1a
spec:
template:
spec:
nodeSelector:
topology.kubernetes.io/zone: us-east-1a
containers:

name: app
image: my-app:latest
resources:
requests:
cpu: 100m
memory: 128Mi
HPA for us-east-1a
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa-us-east-1a
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app-us-east-1a
minReplicas: 2
maxReplicas: 10
metrics:
type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70

Then, your main service will route traffic to all these zone-specific deployments by matching labels, but it will prefer routing to pods within the same zone thanks to the “PreferClose” setting. Repeat this setup for all your zones.

This method offers several advantages: it costs less by minimizing cross-AZ data transfer, allows each AZ to scale according to its own needs, maintains high availability across zones, and ensures automatic traffic rerouting if local pods go down.

By implementing these steps, you can make your EKS cluster more cost-efficient while keeping your application resilient and responsive across multiple AZs.