EC2 IMDSv2 Enforcement

IMDSv1 is vulnerable to SSRF; IMDSv2 closes the gap. The enforcement and the migration.

Why

The EC2 Instance Metadata Service is the endpoint instances use to discover information about themselves: instance ID, region, attached IAM role credentials. The original protocol (IMDSv1) was vulnerable to a specific attack class: server-side request forgery (SSRF) in application code could return IAM credentials to attackers. IMDSv2 closes that vulnerability by requiring a session token; enforcing IMDSv2 across the fleet is one of the highest-leverage security improvements available.

What the vulnerability looks like:

• IMDSv1 returns credentials to anyone who can make a GET request.: An attacker who finds an SSRF vulnerability in application code can use it to query the metadata service. The metadata service returns IAM role credentials. The attacker now has the instance's IAM permissions.
• SSRF in app code is the attack path.: SSRF is one of the most common application vulnerabilities. Code that fetches URLs based on user input (image proxies, link previews, webhook handlers) is particularly vulnerable. The vulnerability is the entry point; IMDSv1 is the privilege escalation.
• IMDSv2 requires a session token.: IMDSv2 changes the protocol: clients must first PUT to obtain a session token, then use the token in subsequent requests. The session token cannot be obtained via a simple GET request.
• Blocking the SSRF path.: Most SSRF attack patterns produce GET requests; PUT requests are typically not exploitable through the same vulnerability. The session token requirement breaks the standard SSRF exploitation pattern.
• Capital One breach is the canonical example.: The 2019 Capital One breach used exactly this pattern: SSRF in a web application leveraged IMDSv1 to obtain IAM role credentials. The breach affected over 100 million customers. IMDSv2 directly closes this attack path.

The why is straightforward: IMDSv2 closes a specific, well-understood, exploited-in-the-wild attack class. Enforcing it is one of the easiest security wins in any AWS environment.

Enforce

Enforcement is a configuration change. The mechanics are simple; the discipline is in applying them across the entire fleet and preventing regressions.

• Account-level setting: IMDSv2 required for new instances.: The account-level default for IMDSv2 enforcement makes it the default for new instances. New instances cannot launch with IMDSv1 enabled unless explicitly overridden. The default closes the gap for new workloads.
• Existing instances: replace or update via launch template.: Existing instances need explicit migration. The fastest path is to update the launch template (or launch configuration) to require IMDSv2 and let the auto-scaling group rotate instances. New instances launch with IMDSv2; old instances terminate as part of the rotation.
• Block IMDSv1 at the network level if possible.: Some teams add a network-level block (security group, host firewall) that prevents IMDSv1 specifically. The defense-in-depth approach catches misconfiguration even if the EC2-level setting drifts.
• Audit periodically.: The team audits the fleet periodically to find instances with IMDSv1 still enabled. Tools like AWS Config rules can flag non-compliant instances; the audit produces a remediation queue.
• Detect new IMDSv1 use.: CloudTrail and VPC flow logs can detect IMDSv1 usage patterns (specifically, the absence of session token PUT requests preceding metadata GETs). The detection catches both legacy code paths and accidental regressions.

Enforcement is the discipline that turns IMDSv2 from a feature into the actual operational reality.

Test

The transition to IMDSv2 is mostly painless because modern AWS SDKs handle the protocol transparently. Some legacy code paths need updates; the testing phase catches them before they cause production issues.

• Verify apps work without IMDSv1.: The team tests applications against an IMDSv2-only configuration in non-production. Most modern code works without changes; some legacy paths produce errors that need fixing.
• Some legacy SDKs need updates.: SDKs prior to specific versions do not support IMDSv2. The team identifies the legacy SDKs and updates them. The updates are usually small (version bumps); the impact is significant (compatible with IMDSv2 enforcement).
• Test in non-prod.: Non-production environments enforce IMDSv2 first. The team observes for failures, identifies affected workloads, fixes them. Production enforcement follows after non-prod is clean.
• Identify the laggards.: Some workloads have hard dependencies on IMDSv1 patterns (older bash scripts that hit the metadata endpoint directly, custom-built tools that predate IMDSv2). The laggards are inventoried; the migration plan addresses each.
• Update systematically.: Each laggard gets a fix: SDK update, code change, replacement of the legacy path. The migration is tracked through to completion. Once all laggards are updated, fleet-wide enforcement is safe.

Instance metadata v2 enforcement is one of the highest-leverage AWS security improvements available. Nova AI Ops integrates with EC2 inventory and CloudTrail data, surfaces instances still allowing IMDSv1, and produces the migration-tracking report that the security team uses to drive remediation.