How to enforce IMDSv2 on Amazon EC2 instances
This guide shows how to find EC2 instances that still accept IMDSv1, confirm nothing depends on it, require IMDSv2 on running instances and make it the default for new ones. It is written for AWS administrators who manage EC2 in one account or many.
Before you start
The instance metadata service (IMDS) hands out instance details and temporary role credentials to software on the instance. IMDSv1 answers plain requests, while IMDSv2 requires a session token. Requiring IMDSv2 is the safer setting.
- Permissions to look:
ec2:DescribeInstances,ec2:GetInstanceMetadataDefaultsand CloudWatch read access. - Permissions to change:
ec2:ModifyInstanceMetadataOptionsandec2:ModifyInstanceMetadataDefaults. Your organisation may restrict these with an IAM or service control policy. - Tools: the AWS CLI configured for the account, and the EC2 console.
- Know the risk: AWS warns that applications or agents that use IMDSv1 will break once IMDSv2 is required. Old SDKs, agents and scripts are the usual cause. Containers may need a metadata hop limit of 2.
- Settings are per Region, so plan for every Region you use.
Step by step
Steps 1 and 2 only read information. Steps 3 to 5 change your account and are marked CHANGE.
- Find instances that allow IMDSv1 (read-only). Repeat for each Region:
Every instance listed accepts IMDSv1.aws ec2 describe-instances --region us-east-1 \ --filters "Name=metadata-options.http-tokens,Values=optional" \ --query "Reservations[].Instances[].[InstanceId,Tags[?Key=='Name']|[0].Value]" --output table - Check whether anything still calls IMDSv1 (read-only). In CloudWatch, look at the
MetadataNoTokenmetric in the EC2 namespace for each instance. AWS says an instance whose IMDSv1 usage is zero is ready to require IMDSv2. If it is not zero, update that software to use IMDSv2 first, and re-check. - CHANGE: require IMDSv2 on a running instance. Start with a test instance:
Console: EC2 > Instances > Actions > Instance settings > Modify instance metadata options, then set IMDSv2 to Required. To go back, run the same command withaws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 --http-tokens required --http-endpoint enabled--http-tokens optional. Containers that need it can also use--http-put-response-hop-limit 2. - CHANGE: make IMDSv2 the default for new instances. This does not alter existing instances. Run it in each Region:
Also setaws ec2 modify-instance-metadata-defaults --region us-east-1 --http-tokens required --http-put-response-hop-limit 2HttpTokens=requiredin your launch templates, and use--imds-support v2.0when you register images. Be careful with that last one: AWS says it cannot be undone on an AMI. - CHANGE (optional): enforce it. Once you are sure nothing needs IMDSv1, block launches and changes that would turn it back on:
With enforcement on, launching an instance withaws ec2 modify-instance-metadata-defaults --region us-east-1 --http-tokens required --http-tokens-enforced enabledHttpTokens=optionalfails. For many accounts and Regions, AWS Organizations declarative policies can apply the setting centrally. You can also limit who may call the modify APIs with an IAM or service control policy.
Check it worked
These commands only read.
aws ec2 describe-instances --region us-east-1 \
--filters "Name=metadata-options.http-tokens,Values=optional" \
--query "Reservations[].Instances[].InstanceId" --output text
aws ec2 get-instance-metadata-defaults --region us-east-1
The first command should print nothing. The second should show HttpTokens as required and, if you enforced it, HttpTokensEnforced as enabled. A ManagedBy value of declarative-policy means a central policy owns the setting. Repeat for every Region, and keep an eye on MetadataNoToken staying at zero.
Common mistakes
- Requiring IMDSv2 without checking
MetadataNoToken, which breaks software that still uses IMDSv1. - Believing the account default fixes running instances. It only affects new launches.
- Forgetting that settings are per Region and checking only one.
- Leaving the hop limit at 1 for containerised workloads, so containers cannot reach the metadata service.
- Setting
imds-support v2.0on an AMI whose software is not ready. It cannot be reversed on that AMI. - Turning on enforcement before launch templates and auto scaling groups are fixed, so new launches fail.
How ConfigCobra helps
ConfigCobra is read-only: it never changes your AWS. It reads your accounts through an assume-role connection, and its AWS coverage includes CIS Amazon Web Services Foundations v7.0.0 (70 controls) and CIS AWS Compute Services v2.0.0 (82 controls), 306 controls across the four AWS benchmarks. The related checks below cover the metadata service setting.
The AWS inventory lists resources across the accounts in scope with their security properties. Remediation impact analysis shows the affected resources before you apply a fix, and scheduled scans with drift detection send an email when a control regresses.
Go further
- All guidesAdmin how-tos for Microsoft 365, Azure, Google Cloud and AWS
- Check libraryEvery CIS check, explained
- RemediationSee what a fix changes in your tenant before you apply it, then use the generated script
- Inventory & InsightsEvery user, app, device and resource in one inventory, with built-in risk views
See where your AWS stands
A read-only assessment against the CIS benchmarks, prioritised so you know what to fix first.