How to Migrate an EC2 Fleet to IMDSv2 Without Breaking Applications

Retrospective: this article looks back at events from November 2019, written in 2026 with the benefit of hindsight.

IMDSv2 protects instance credentials from SSRF attacks, but enforcing it across a large EC2 fleet can break older applications if done carelessly. Here is a safe migration approach.

Step 1: Measure IMDSv1 usage

Use the CloudWatch metric MetadataNoToken per instance. Non-zero values mean something on the instance is still calling the metadata service without a token. Instances with zero usage over two weeks are safe to enforce.

Step 2: Find the callers

On instances still using IMDSv1, identify the process:

• Update AWS SDKs and the AWS CLI to current versions — they support IMDSv2 automatically.
• Update third-party agents (monitoring, backup, security).
• Update custom scripts that call http://169.254.169.254 directly to obtain a token first.

The AWS-provided IMDS packet analyzer tool can help identify processes making IMDSv1 calls.

Step 3: Enforce in waves

Start with non-production, then production by application. Set HttpTokens=required on existing instances and update launch templates, Auto Scaling groups and AMIs so replacements are also enforced.

Step 4: Set account defaults

Configure the EC2 account-level default for instance metadata options to require IMDSv2 for new instances in each region.

Step 5: Prevent regressions

• IAM or SCP condition requiring ec2:MetadataHttpTokens to be required on RunInstances.
• Security Hub control EC2.8 monitoring compliance.

Containers

If containers on EC2 need instance metadata, set the hop limit to 2. Better: give containers their own roles (ECS task roles, EKS Pod Identity) and block metadata access from pods.

Verify

MetadataNoToken at zero across the fleet and EC2.8 passing in every account.