EC2 Can Now Tell You Where IMDSv1 Is Still Enabled

An EC2 instance can make no tokenless metadata requests all week and still allow them tomorrow. That distinction makes an IMDSv2 migration surprisingly easy to declare finished too early. AWS's new ImdsV1Enabled CloudWatch metric gives you a configuration signal to put beside your usage graphs. You can use it to find the remaining exceptions, test one workload at a time, and catch settings that drift back.

AWS announced the metric on November 5, 2026, with availability in every AWS Region and no additional charge for the metric itself. It does not migrate instances for you. The useful change is that your migration dashboard can now answer whether IMDSv1 is still permitted, even when applications happen not to be using it.

Prerequisites

• AWS CLI v2 configured for the account and Region you want to inspect.
• Permission to describe EC2 instances and read CloudWatch metrics.
• A staging instance that represents the application, agents, and scheduled jobs you run in production.
• A workload owner available before you change metadata settings. The inventory commands below are read-only; the final change command is not.

Three signals, three different questions

AWS's IMDSv2 transition guide defines the new metric as 1 when HTTP tokens are optional and 0 when they are required. Unlike the request counters, it is emitted from configuration rather than metadata access.

Signal	Question it answers	How to use it
ImdsV1Enabled	Does this instance still allow tokenless access?	Find configuration exceptions.
MetadataNoToken	Did a tokenless request succeed?	Find callers that need migration.
MetadataNoTokenRejected	Was a tokenless request rejected after enforcement?	Investigate compatibility problems.

The two request metrics count successful tokenless calls and rejected attempts respectively; the EC2 metrics reference documents both. A quiet request counter does not tell you which configuration is in place.

Consider a backup task that runs once a month. A five-day observation window might never execute it. My recommendation is to keep an explicit exception list with an owner, the workload's longest relevant execution cycle, and the next test date. That makes a migration gap actionable instead of turning it into another permanently yellow dashboard.

Build an inventory before changing anything

Start with one account and Region. This example lists running and stopped instances whose metadata options still make tokens optional:

aws ec2 describe-instances \
  --region eu-west-1 \
  --filters \
    Name=instance-state-name,Values=running,stopped \
    Name=metadata-options.http-tokens,Values=optional \
  --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name,Endpoint:MetadataOptions.HttpEndpoint,Tokens:MetadataOptions.HttpTokens,HopLimit:MetadataOptions.HttpPutResponseHopLimit}' \
  --output table \
  --no-cli-pager

The DescribeInstances API supports these filters and returns the metadata options. Keep the endpoint column: HttpEndpoint=disabled is a separate state, not proof of a working IMDSv2 migration. Record those instances separately rather than enabling metadata access just to make every row look alike.

Repeat the inventory for the accounts and Regions in your actual scope. An empty result in one Region is not a fleet-wide result. Include stopped instances in your review because they can return to service later.

Then discover the metric series available to your caller:

aws cloudwatch list-metrics \
  --region eu-west-1 \
  --metric-name ImdsV1Enabled \
  --output json \
  --no-cli-pager

This command lists series and their dimensions, not current values. Use the returned series in CloudWatch to inspect datapoints. AWS documents that ListMetrics can take up to 15 minutes to show a new metric, and it omits series that have not reported in two weeks. An empty response is therefore a reason to check account, Region, visibility, and instance configuration, not a green migration result.

Test the workload, then require IMDSv2

Choose one representative staging instance and run its real lifecycle: bootstrapping, service restart, deployment, scheduled maintenance, and credentials refresh. Include monitoring and backup agents. For containers, test from inside the container as well as from the host.

AWS notes that a metadata response hop limit of 1 can cause problems in container environments. Do not change hop limits across the fleet just because a host-level test passed; investigate the affected network path separately.

Once the workload is ready, replace the example ID and apply the token requirement to that instance:

aws ec2 modify-instance-metadata-options \
  --region eu-west-1 \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --no-cli-pager

The modify command can return pending for a running instance. Verify that the setting reaches applied:

aws ec2 describe-instances \
  --region eu-west-1 \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].MetadataOptions' \
  --output json \
  --no-cli-pager

Expect HttpTokens to be required and State to be applied. The commands here are examples, not a transcript from a production account.

Keep replacement instances from undoing the work

Changing one running instance leaves a second question: what happens when Auto Scaling replaces it? Update the launch configuration your fleet actually uses, then launch a replacement in staging and inspect its effective metadata options.

AWS's configuration precedence rules put explicit launch settings ahead of account defaults, then AMI settings. Account defaults also do not rewrite existing instances. Review the launch template version your Auto Scaling group selects rather than assuming a newly edited template is already in use.

For the rollout, keep two views side by side: configuration exceptions and application health. Use MetadataNoToken during preparation and MetadataNoTokenRejected after enforcement. Keep missing telemetry visibly unknown, and assign each remaining exception an owner.

The useful finishing condition is specific: the intended instances require tokens, representative workloads still work, and replacement instances inherit the same setting. The new metric makes the configuration part easier to watch continuously.