Context
The EC2 Instance Metadata Service provides instance information and can deliver temporary role credentials to software on an instance. IMDSv2 requires a session token before metadata requests. Requiring it improves the request boundary, but older clients and container network paths need verification before fleet-wide enforcement.
Inventory consumers without exposing credentials
Record instance IDs, AMIs, launch templates, metadata options, application SDKs, agents and container environments. Identify workloads that legitimately need metadata and those that should use a separate workload identity. Obtain read-only configuration and CloudWatch access.
Do not retrieve or display role-credential documents for troubleshooting. Configuration, usage metrics and controlled application identity checks can establish the issue without exposing temporary access keys. Include boot-time agents and scheduled jobs in the inventory, not only the main web process.
1. Find remaining tokenless callers
Inspect instances whose HttpTokens option is optional and review MetadataNoToken usage over a representative workload period. AWS recommends identifying and updating software that still uses IMDSv1 before requiring IMDSv2. A quiet metric during an idle hour does not prove a monthly maintenance job is compatible.
Compare software versions and metadata client implementation. Upgrade through the normal image or package process and test startup, role refresh and scheduled work. Keep the source of the caller identifiable so the team corrects an outdated agent rather than repeatedly relaxing the instance setting.
2. Test container reachability separately
Read the instance's metadata endpoint state and token response hop limit. Container networking can introduce an extra hop that differs from a host process's path. AWS recommends a hop limit of two for common container environments, but the intended exposure and actual topology still need review.
Test from a controlled container with the same networking mode as the workload. Compare host and container behavior without printing tokens or credential contents. A host-side success does not establish that a container can complete the token exchange.
3. Check existing instances and future launches
| Evidence | Likely cause | Next action |
|---|---|---|
| Tokenless calls remain | Software still depends on IMDSv1 | Identify and update the caller |
| Host succeeds, container fails | Container-path or hop-limit difference | Review networking and metadata options |
| Existing instance works, replacement fails | Launch configuration differs | Inspect AMI and template settings |
| Failures begin when tokens become required | Compatibility gap | Review rejected-call metrics and software |
An explicitly illustrative scenario: a metrics agent works on the host, while a containerized batch worker loses role access after IMDSv2 becomes required. The team confirms the worker's supported SDK and compares the token path from both environments. It corrects the reviewed container hop configuration in a test launch template and verifies the worker identity. Re-enabling IMDSv1 for the whole fleet would leave the cause unresolved.
Verify enforcement and maintain the image contract
Require IMDSv2 first on a representative test instance after compatibility checks. Verify application behavior, startup tasks and credential refresh. Monitor MetadataNoTokenRejected for attempted tokenless calls after enforcement and correlate them with workload failures.
Update launch templates and relevant account or AMI defaults through the approved infrastructure workflow. Verify an actual replacement instance because several configuration sources can influence launch options.
The SOP should name metadata consumers, image owners, intended endpoint exposure and rollout gates. Review metadata behavior after agent, SDK or network changes. Preserve an explicit workload-identity design for containers so the instance role does not become an unexplained shared permission source.
Explore Clouvenix cloud security for implementation and operational handover.
Technical reference
IMDSv2 migration, new-instance configuration, and metadata options explain the controls.