<p>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: <a href="https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-eks-supports-ec2-instance-metadata-service-v2/" rel="nofollow noreferrer">https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-eks-supports-ec2-instance-metadata-service-v2/</a></p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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</p>
<pre class="lang-bash prettyprint-override"><code>TOKEN=`curl -X PUT &quot;http://169.254.169.254/latest/api/token&quot; -H &quot;X-aws-ec2-metadata-token-ttl-seconds: 21600&quot;`
curl -H &quot;X-aws-ec2-metadata-token: $TOKEN&quot; -v http://169.254.169.254/latest/meta-data/
</code></pre>
<p>For availability zone:</p>
<pre class="lang-bash prettyprint-override"><code>curl -H &quot;X-aws-ec2-metadata-token: $TOKEN&quot; -v http://169.254.169.254/latest/meta-data/placement/availability-zone/
</code></pre>

CC BY-SA 4.0
2022-05-30T15:29:15.600Z
2022-05-30T15:29:15.600Z
hi im Bacon
<p>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.</p>
<p>I have two brokers for the MSK cluster, one in each availability zone that the pods use.</p>
<p><strong>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</strong></p>
<p>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.</p>
<p>I was imagining that it would be possible to have the deployment pull the zone information like any other spec field e.g. <a href="https://docs.microsoft.com/en-us/answers/questions/330925/how-can-a-pod-know-which-availability-zone-it-loca.html" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/answers/questions/330925/how-can-a-pod-know-which-availability-zone-it-loca.html</a> but that isn't a valid field.</p>
<p>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. <a href="https://www.quora.com/How-do-I-find-out-in-which-availability-zone-a-AWS-EC2-server-is" rel="nofollow noreferrer">https://www.quora.com/How-do-I-find-out-in-which-availability-zone-a-AWS-EC2-server-is</a></p>
<p>None of the field listed <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#podspec-v1-core" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#podspec-v1-core</a> seem to have any field that could identify this.</p>
<p>Is there a way of doing this? Or is there a better way of networking the pods/node groups?</p>

<kubernetes><amazon-web-services><eks><kafka>
EKS - Get availability zone of pod deployment from pod
hi im Bacon
# EKS - Get availability zone of pod deployment from pod

(Asked by: username_0 on 2022-05-27)

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?

**Tags:** kubernetes, amazon-web-services, eks, kafka


---

## 1 answers

### Answer by username_0 on 2022-05-30. Score: 1 | Accepted answer

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 "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/

For availability zone:
curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/placement/availability-zone/


---

