Enforce IMDSv2 on EC2

Enabling IMDSv2 costs nothing on the AWS bill. There is no per-call charge, no extra service, no rate-card impact. The only cost is the migration effort: verifying that the software on each instance is new enough to use the updated protocol, flipping a configuration flag, and updating launch sources, work that for a modern fleet is hours, not weeks. Much of it, the move from deprecated launch configurations to launch templates, was already needed for other reasons.

The risk side is where the attention belongs. The exposure from an IMDSv1-permissive instance is bounded by what the attached IAM role can do, which for production workloads often means access to S3 buckets, secrets, or the ability to spin up resources. The Capital One breach in 2019 was a direct IMDSv1 exploit and cost over 270 million dollars in fines and remediation. The relevant question for the risk register is not how likely an SSRF is on a given instance, but what the blast radius is if there is one, so prioritise the highest-privilege fleets first.

The insurance maths is one-sided: a one-time, zero-recurring-cost engineering effort against an open-ended, hard-to-detect credential-theft path. Track the count of HIGH EC2.8 findings on production instances as an open liability line until it reaches zero and the launch sources are updated so it stays there.

Anita is the finance partner for the platform team at the same fintech. Security Hub hands her EC2.8 across 47 production instances and AutoScaling.3 across three launch configurations, all still permitting IMDSv1. Her first move is not to ask what remediation costs, because she already knows IMDSv2 is free on the AWS bill: no per-call charge, no extra service, no rate-card impact. Her question is which of these fleets turns a single application bug into a balance-sheet event, because the exposure is bounded by what the attached IAM role can reach, not by the instance itself.

She asks the team to rank each flagged fleet by the privilege of its instance profile. The fleet whose role can read customer S3 buckets and decrypt KMS keys goes to the top of her risk register; the legacy batch boxes with a narrow role sit lower. She frames the migration as a one-time, non-recurring labour line rather than an open backlog item, and she requires the launch-source update to be in scope so the fix is permanent rather than reopening with every new instance. Her output for the risk pack is one sentence: the remediation is zero recurring cost, the reference data point is the Capital One breach at over 270 million dollars, and we sequence it by IAM blast radius, not by fleet name.

The cost structure is unusual: remediation has zero incremental AWS spend, because IMDSv2 is not a paid feature. The cost is purely engineering labour, an inventory run, a compatibility check, the flag flip and the launch-source update, which for a modern fleet measures in hours. From a cost-of-risk perspective, leaving high-privilege fleets on IMDSv1 is an uninsured position you can close with a bounded, one-time budget.

The exposure is bounded by what the attached IAM role can reach, so the right risk-register entry is per fleet: N production instances where an application bug exposes access to X, ranked by role privilege. The Capital One breach is the reference data point at over 270 million dollars. The finance role is to approve the migration as a one-time, non-recurring investment, require the launch-source update to be in scope so the fix is permanent, and track the open liability until the count reaches zero and stays there.

Every EC2 server has a built-in endpoint that returns its cloud credentials to code running on it. The legacy version, IMDSv1, requires no authentication, so any application vulnerability that can make an outbound HTTP request can silently steal those credentials. The Capital One breach, 106 million customer records and over 270 million dollars in consequences, followed exactly this path. The report marks the running-instance control HIGH severity.

The fix is a single configuration flag, and it costs nothing on the cloud bill. The only work is verifying that software is modern enough for the updated protocol and updating the launch sources so new instances are born compliant. This belongs on the executive radar not because it is complicated, but because the consequence of ignoring it is disproportionately large relative to the effort.

The leadership question is whether every production instance has this enforced by policy rather than by accident, with the highest-privilege fleets at the front of the queue and the launch sources updated so the setting can never silently reopen.

After the board read yet another incident report where an application bug let an attacker fetch an instance's cloud credentials, the CEO asked a single question at the next risk review: could that happen to us, and how would we know? The honest answer was that on every IMDSv1-permissive fleet it could, and the first signal would be the exfiltration itself, because credential theft over the metadata service leaves nothing in the cost report to notice. The wall of EC2.8 findings was the visible symptom of that gap, and the Capital One breach, 106 million records down a single IMDSv1 call, was the textbook case.

The leadership response was to treat IMDSv2 as a standard enforced by infrastructure rather than a backlog of findings patched one at a time. The highest-privilege fleets were remediated first, launch sources were migrated to launch templates with the handshake required, an account-level default was set so new instances were born compliant, and a Service Control Policy denied launching without IMDSv2. Six months on, the question changed from could that happen to us to are new instances born compliant by default, and the answer was yes by infrastructure rather than by good behaviour. That born-compliant confirmation, not the point-in-time count, is the signal that belongs on a governance review.

These controls translate to a single board-level question: could an application bug on one of our servers silently hand an attacker the keys to our data? With IMDSv1 permissive, the honest answer for every flagged fleet is yes, and the Capital One breach is the textbook case, an application vulnerability that could make the right HTTP request, and 106 million records walked out for free.

What makes this unusual is that the fix has no ongoing cost; the only investment is the migration that was already needed because launch configurations are deprecated. The leadership question is therefore not whether it is worth the cost, but whether the highest-risk fleets are remediated first and whether new instances are born compliant by default. After an incident, the narrative we knew it was permissive, the fix was free, and we deprioritised it does not survive a post-mortem.