OpsCanary
kubernetesautoscalingPractitioner

Mastering Zonal Shift Support for EKS Auto Mode and Karpenter

5 min read AWS Containers BlogJul 23, 2026Reviewed for accuracy
Share
PractitionerHands-on experience recommended

Zonal Shift exists to tackle the critical issue of availability during zone failures in Amazon EKS. When an Availability Zone goes down, the last thing you want is for your applications to suffer. Zonal Shift, part of the Amazon Application Recovery Controller (ARC), automates the recovery process, ensuring your applications remain resilient and available even when infrastructure issues arise.

When Zonal Shift is enabled, it automatically cordons affected worker nodes, preventing new pods from being scheduled in the impaired zone. It deregisters IP addresses of pods in that zone from load balancers and removes their endpoints from endpoint slices, effectively cutting off traffic to those pods. Karpenter plays a crucial role here; it detects shifts—whether manual or automatic—by polling the ARC GetManagedResources API every 30 seconds. If a zone is impaired, Karpenter halts provisioning in that zone until service is restored, ensuring that your resources are allocated efficiently and your applications stay responsive.

In production, enabling Zonal Shift requires an EKS Auto Mode cluster and Karpenter version 1.12.0 or higher. You must also configure kubectl and AWS CLI v2. Be aware that forceful terminations, like EC2 Spot interruptions, will still occur. Additionally, enabling Zonal Shift makes your cluster eligible for manual shifts, which adds complexity to your resource management. Always test your configurations in a controlled environment before rolling them out to production to avoid unexpected behavior.

Key takeaways

  • Enable Zonal Shift by setting the --enableZonalShift flag to true on the Karpenter controller.
  • Use the command 'aws eks update-cluster-config --name <cluster-name> --region eu-north-1 --zonal-shift-config enabled=true' to activate Zonal Shift.
  • Implement topologySpreadConstraints in your deployments to optimize pod distribution across zones.

Why it matters

In production, Zonal Shift significantly reduces downtime during zone failures, allowing your applications to maintain high availability and reliability. This is crucial for user satisfaction and operational efficiency.

Code examples

Bash
aws eks update-cluster-config \
  --name <cluster-name> \
  --region eu-north-1 \
  --zonal-shift-config enabled=true
YAML
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: zonal-shift-test
5  namespace: default
6spec:
7  replicas: 9
8  selector:
9    matchLabels:
10      app: zonal-shift-test
11  template:
12    metadata:
13      labels:
14        app: zonal-shift-test
15    spec:
16      topologySpreadConstraints:
17      - maxSkew: 1
18        topologyKey: topology.kubernetes.io/zone
19        whenUnsatisfiable: ScheduleAnyway
20        labelSelector:
21          matchLabels:
22            app: zonal-shift-test
23      containers:
24      - name: nginx
25        image: public.ecr.aws/nginx/nginx:latest
26        resources:
27          requests:
28            cpu: 500m
29            memory: 256Mi
30---
31apiVersion: v1
32kind: Service
33metadata:
34  name: zonal-shift-test
35  namespace: default
36spec:
37  type: LoadBalancer
38  selector:
39    app: zonal-shift-test
40  ports:
41  - port: 80
42    targetPort: 80

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
Better StackSponsor

Unified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.

Try Better Stack free →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.