- 新しい順
- 投票が多い順
- コメントが多い順
Looks like AWS fixed this in the latest release of their windows platform 2.11.7
Hello,
Greetings!
Thanks for reaching out. I am from support team and would like to add details regarding your concern. To inform you our internal team is actively working on finding the route cause of this issue with IMDSV2.
They have suggested the workaround to use IMDSV1 for the time being but rest assured they will be back with the root cause and resolution. I may not be in a position to provide you an exact ETA when this issue will get resolved as the team doesn't shares an ETA.
Also i would request others to share their feedbacks here if they are also facing the same issue. You can create a issue on https://github.com/aws/elastic-beanstalk-roadmap/projects/1 for tracking and you will be updated on this, once the issue is addressed.
I hope the above information helps.
Regards!
This does not sound right as IMDSv1 and IMDSv2 are the same service. So if IMDSv1 works then IMDSv2 is (or should) be working. IMDSv2 uses session oriented requests for extra defense-in-depth. More information on the differences is here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html
Have you tried a single, manual IMDSv2 call on the instance to see if that works? If it does, then your software may not be making v2 calls correctly. If the call does not work, then it's likely an instance metadata options setting you need to update.
A common "gotcha" is not having the right hop limit in containerized workloads. By default, the Http-put-response-hop-limit is 1 but you may need to increase to 2 or 3 to get a response to your application.