Yes, where your software supports it. AWS says an instance can be set to accept only IMDSv2, which makes IMDSv1 calls fail. IMDSv2 needs a session token obtained with a PUT request, which makes simple request forgery and open proxy tricks much harder. Training hosts run lots of third party code, so the extra step is worth it.
What the metadata service is
Every EC2 instance can query a local address, 169.254.169.254, for details about itself, including the role credentials attached to the instance. Code running on the host, or in a container on it, can usually reach that address. If a notebook, a model server or a pipeline step runs hostile code, or can be tricked into fetching a URL, those credentials are within reach.
AWS documents two methods. IMDSv2 is session oriented. IMDSv1 is a plain request and response. By default, instances accept either or both, so a host you never touched may still allow the older method.
What IMDSv2 changes
Per the AWS documentation:
- You first send a PUT request to get a token, with a time to live from one second up to six hours.
- Every later GET carries that token. When token use is set to required, requests without a valid token get a 401.
- The token is specific to the instance and is rejected elsewhere.
- PUT requests are rejected if they contain an X-Forwarded-For header.
- The PUT response has a hop limit of 1 by default.
That last point matters for containers. A hop limit of 1 can stop a container behind a network hop from getting a token. AWS notes you can raise it for backward compatibility with container services, but a larger hop limit means more places can reach the service. Make that choice on purpose.
Why ML hosts are a good place to start
| Risk on a training host | Why IMDSv2 helps |
|---|---|
| Notebook runs untrusted code | Casual requests without a token fail |
| Pipeline fetches URLs from config | A forged request cannot easily create the token |
| Shared GPU box with many users | Narrower, deliberate access to credentials |
IMDSv2 does not stop code that can run a PUT itself. It raises the bar. The role attached to the instance should also be as small as possible.
Rollout steps
- List instances and note which accept IMDSv1.
- Update SDKs and tools. AWS lists minimum versions for IMDSv2 support, and says to use a supported SDK.
- Set token use to required on a test instance and run a training job.
- Watch for failures in older scripts and containers.
- Make required the default in your launch templates.
- Trim the attached role to the buckets and services the job needs.
See also least privilege for cloud native environments.
Safeguard's asset discovery and policies can help track cloud assets and enforce guardrails, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Will requiring IMDSv2 break old tools?
It can, if they use an SDK too old to support it. Test first and update the SDK.
Is IMDSv2 on by default?
Per AWS, by default you can use either IMDSv1 or IMDSv2, or both. Check your own configuration.
Sources
Last reviewed: 19 October 2026.
