EC2 - require Instance Metadata Service Version 2 (IMDSv2)

Instance Metadata Service Version 2 (IMDSv2) is a session-oriented, token-based method for retrieving EC2 instance metadata and temporary IAM credentials, and this policy requires it by setting http_tokens = "required" in the metadata_optionsblock on every aws_instance and aws_launch_template resource. IMDSv1 accepts metadata requests without any token, which makes it a common path for attackers to steal IAM role credentials through server-side request forgery (SSRF). This policy does not change EC2 pricing, but it closes a security gap whose incident response and remediation work routinely costs far more engineer time than the one-line Terraform change required to prevent it.

Policy at a Glance

Why This Policy Matters

How It Helps Reduce Cloud Costs

Requiring IMDSv2 does not lower compute spend directly. It reduces the indirect costs that follow a credential-theft incident: containment, forensic review, key rotation, and any compliance reporting the incident triggers.

Retroactive remediation is more expensive than enforcement at deploy time. A platform engineer who sets http_tokens = "required" in a shared Terraform module spends minutes on the change. The same gap discovered during a security audit or, worse, an active incident can take a security team days to trace and close across an entire fleet.

This is a common source of avoidable security debt. Fleets that grow instance by instance without a shared metadata_options default accumulate IMDSv1-capable instances quietly, and nobody notices until a scanner or an attacker finds one.

Potential Savings

Security teams commonly report that investigating and remediating a single credential-exposure finding takes multiple engineer-hours, and can stretch into multiple engineer-days when the affected instance has already been compromised and requires full IAM key rotation and audit logging review. These figures vary by organization and should be treated as illustrative, not as a guaranteed cost for any specific incident.

Enforcing http_tokens = "required" in a shared launch template or module eliminates this class of finding at the source. A platform team that adds this default and runs Infracost in CI can report zero IMDSv2 findings across all new EC2 deployments, a concrete and trackable metric for engineering leadership.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a non-compliant EC2 instance configuration and the corrected version.

Non-compliant configuration: metadata_options not set, defaults to IMDSv1 allowed.

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  # metadata_options not set, HttpTokens defaults to "optional"
}

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  # metadata_options not set, HttpTokens defaults to "optional"
}

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  # metadata_options not set, HttpTokens defaults to "optional"
}

This configuration defaults to http_tokens = "optional", which means the instance accepts unauthenticated IMDSv1 requests alongside IMDSv2 ones. This is a common source of avoidable attack surface.

Compliant configuration: IMDSv2 required.

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 2
  }
}

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 2
  }
}

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 2
  }
}

Setting http_tokens = "required" ensures the instance only returns metadata, including temporary IAM credentials, in response to requests carrying a valid session token. The same metadata_options block applies to aws_launch_template, which is the relevant resource for instances launched through an Auto Scaling group.

Step-by-Step Fix Instructions

1. Open the Terraform configuration for the affected aws_instance or aws_launch_template resource.

2. Locate the metadata_options block. If it does not exist, add it.

3. Set http_tokens = "required" inside metadata_options.

4. Set http_endpoint = "enabled" alongside it. AWS requires the endpoint to be enabled whenever http_tokens is set.

5. For containerized workloads on ECS or EKS, set http_put_response_hop_limit = 2. The default hop limit of 1 is too low for metadata requests that pass through a container network layer before reaching the application.

6. Run terraform plan to confirm the change applies without replacing the instance.

7. Apply the change. AWS applies updated metadata options to a running instance without a restart.

8. For instances outside Terraform's control, use the AWS CLI: aws ec2 modify-instance-metadata-options --instance-id <instance-id> --http-tokens required --http-endpoint enabled.

9. Add Infracost to your CI/CD pipeline to catch this misconfiguration automatically on future pull requests.

Best Practices

• Set http_tokens = "required" as the org-wide default in shared Terraform modules and launch templates. This removes the need for individual teams to remember the setting on every resource.

• Do not leave http_tokens = "optional" in any environment, including development. Development instances are routinely used as a stepping stone for lateral movement once an attacker gains initial access.

• Set the hop limit deliberately. A hop limit of 1 works for most standalone EC2 instances, but container platforms commonly need 2.

• Review existing instances with the AWS Config rule ec2-imdsv2-check, Infracost, or the AWS CLI query below, since the Status field on a Terraform module change does not tell you which already-running instances still allow IMDSv1.

Tools and Scripts

How does Infracost detect this automatically?

Infracost supports this policy check in its free trial and paid plans. When Infracost runs in CI/CD, it evaluates the http_tokens attribute inside metadata_options on aws_instance and aws_launch_template resources in the Terraform plan. A violation surfaces as a policy finding in the PR comment before the code is merged.

This gives platform engineers a pre-deploy signal instead of a post-deploy security finding. Runtime cost and security posture tools that scan live infrastructure do not catch this at the point where it is cheapest to fix, which is before the change reaches production. Infracost fills that gap at the Terraform plan stage, alongside whatever runtime tooling is already in place.

Infracost enables teams to track policy violation rates over time, which supports the goal of burning down this class of finding incrementally instead of relying on a single audit-driven cleanup.

To find existing EC2 instances that still allow IMDSv1, using the AWS CLI:

aws ec2 describe-instances \
  --filters "Name=metadata-options.http-tokens,Values=optional" \
  --query "Reservations[].Instances[].InstanceId" \
  --output

aws ec2 describe-instances \
  --filters "Name=metadata-options.http-tokens,Values=optional" \
  --query "Reservations[].Instances[].InstanceId" \
  --output

aws ec2 describe-instances \
  --filters "Name=metadata-options.http-tokens,Values=optional" \
  --query "Reservations[].Instances[].InstanceId" \
  --output

Examples of Impact

Platform team enforcing the policy through a shared module: A platform team manages several hundred EC2 instances across three environments. Before this policy, metadata_options was not set in the base module, so every new instance defaulted to http_tokens = "optional". After adding http_tokens = "required" to the shared module and running Infracost in CI, all new deployments are compliant by default, and the team stops receiving new IMDSv2 findings from its periodic security audits.

Remediating an existing fleet: A DevOps engineer runs the AWS CLI query above after a security review and finds several dozen production instances still allowing IMDSv1. The engineer batches the fix through modify-instance-metadata-options for existing instances and updates the shared Terraform module so new instances are compliant from launch. Infracost validates the Terraform change before merge, and the finding count for this control drops to zero going forward.

Considerations and Caveats

• Application compatibility: Some older SDKs and custom scripts call the metadata service without the required token header. Confirm application code supports IMDSv2 before enforcing http_tokens = "required" fleet-wide.

• Hop limit matters for containers: The default hop limit of 1 blocks metadata requests from containerized processes on ECS or EKS. Set http_put_response_hop_limit = 2 for these workloads, or metadata calls will fail after enforcement.

• AMI-level enforcement is permanent: Setting imds-support = "v2.0" on an AMI forces IMDSv2 for every instance launched from it, and this setting cannot be reversed on that AMI. Instance-level metadata_options, by contrast, can be changed at any time.

• Not retroactive by default: Changing the Terraform configuration only affects new instances and instances Terraform manages directly. Existing instances outside Terraform's state need a separate remediation pass.

• No cost impact: This is a security configuration change. It does not affect EC2 pricing, instance type, or billing.

Related Policies and Concepts

• EC2 - consider disabling associate public IP address in launch templates: another EC2 attack-surface reduction policy that targets aws_launch_template, commonly enforced alongside IMDSv2 as part of the same hardening pass.

• KMS - consider enabling automatic key rotation: a related AWS Security Hub-mapped policy that reduces the blast radius of a compromised credential, which is the exact failure mode IMDSv2 is designed to prevent.

• S3 - consider blocking public access for the S3 access points: a similarly Terraform-enforced, Security Hub-mapped hardening control from a different resource type, useful context for teams building out a broader security-baseline policy set.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. Infracost detects EC2 instances and launch templates where http_tokens is missing or set to optional as part of its policy engine. This check is available in the free trial and all paid plans.

Can this policy be customized?

Yes. Teams can set the enforcement level for this check, choosing whether a violation blocks the pull request or only warns the engineer, and can customize the message shown in the PR comment. The default check flags any aws_instance or aws_launch_template without http_tokens = "required".

Does Infracost automatically fix violations?

Infracost identifies and reports IMDSv2 violations at the PR stage, giving engineers the chance to fix the configuration before deployment. It does not apply the fix directly. The fix itself is a one-line Terraform change inside the metadata_optionsblock.

Is this policy cloud-agnostic?

This specific policy targets AWS EC2 and its aws_instance and aws_launch_template Terraform resources. Azure and GCP have their own instance metadata service protections, but the Terraform resource names and attribute paths differ from AWS's metadata_options block.

How often should I review policy compliance?

Teams running Infracost in CI/CD get continuous enforcement on every pull request that touches EC2 or launch template resources. For instances outside IaC, run a periodic audit with the AWS CLI or AWS Config's ec2-imdsv2-check rule to catch anything that predates the policy.

Does enforcing IMDSv2 affect EC2 cost?

No. Setting http_tokens = "required" is a security configuration change. It does not affect the instance type, pricing, or billing of the EC2 instance.