In my EKS cluster, I have a few node groups that cover availability zone A and B. The pods running on the nodes are consumers/producers on various Kafka topics (MSK). There isn't any internal communication between the pods.

I have two brokers for the MSK cluster, one in each availability zone that the pods use.

I am concerned that since the pods can be deployed in either availability zone, I might be unknowingly charged for data that is being transferred between the availability zones as the pod doesn't have a preference to which broker it talks to

To avoid this, I am thinking of having the pod select the broker server to talk to once it has started, and to do this it needs to know what availability zone the underlying node its been deployed on.

I was imagining that it would be possible to have the deployment pull the zone information like any other spec field e.g. https://docs.microsoft.com/en-us/answers/questions/330925/how-can-a-pod-know-which-availability-zone-it-loca.html but that isn't a valid field.

I have tried hitting the ec2 metadata ip address like the link below but since its a pod with its own IP on the node, I assume this mechanism doesn't work. https://www.quora.com/How-do-I-find-out-in-which-availability-zone-a-AWS-EC2-server-is

None of the field listed https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#podspec-v1-core seem to have any field that could identify this.

Is there a way of doing this? Or is there a better way of networking the pods/node groups?

1 Answer 1


The EC2 metadata endpoint has been updated to handle this situation but your current configuration may be preventing it. Have a read here for more: https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-eks-supports-ec2-instance-metadata-service-v2/

Now, newly launched and any updated EKS managed node groups will be configured with a metadata token response hop limit set to 2. For self-managed nodes, CloudFormation templates and eksctl have been updated to launch nodes by default with a hop limit of 2.

Given that you have the hop limit updated, you can use the IMDSv2 endpoint by first getting a token, and passing that through with your request

TOKEN=`curl -X PUT "" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" -v

For availability zone:

curl -H "X-aws-ec2-metadata-token: $TOKEN" -v

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.