EC2 Metadata Endpoint Protection

The metadata endpoint can leak credentials via SSRF. The defenses that close it.

The threat

Server-side request forgery (SSRF) lets an attacker make the server fetch arbitrary URLs. The EC2 metadata endpoint at 169.254.169.254 is the high-value target because it returns IAM credentials, and once an attacker has IAM credentials they have whatever the instance role permits.

• SSRF as the entry point. An attacker makes the server fetch arbitrary URLs; the metadata endpoint is reachable from the server.
• IAM credentials returned. The endpoint returns the instance role’s short-lived credentials; the attacker uses them as their own.
• Production blast radius. Role permissions usually cover S3, DynamoDB, RDS, secrets manager; the compromise is broad.
• Top-three cloud attack pattern. Capital One (2019) and many others; SSRF plus instance metadata is a recurring breach class.

IMDSv2 enforcement

IMDSv2 requires a session token. The caller must first PUT to obtain a token, then GET with the token attached. Most SSRF vectors only support GET, which is what blocks the attack at the protocol layer.

• Token-mediated access. PUT for a token, GET with the token; the two-step requirement is the SSRF block.
• SSRF defeated by default. Most SSRF vectors only support GET; IMDSv2 blocks them at the protocol level.
• Account-level enforcement. Set the default to require IMDSv2 for new instances; existing instances need explicit migration.
• Per-tool compatibility check. Some legacy SDKs and tools assume IMDSv1; update them or accept they cannot run on enforced instances.

Hop limit configuration

The metadata-token-response-hop-limit set to 1 stops containers from reaching the metadata endpoint through the host network because the response cannot traverse the extra hop. The setting specifically blocks containerised SSRF where the container would otherwise impersonate the host.

• hop-limit: 1. Containers cannot reach the metadata endpoint through the host network; the response cannot traverse one hop.
• Containerised SSRF blocked. A container cannot impersonate the host to access metadata; the protection is at the network layer.
• Per-stack verification. Pod identity providers (IRSA) work without raising the limit; verify your stack before enforcing.
• Per-instance default. Standard launch templates set hop-limit-1 by default; new instances inherit.

Network-layer defence

Network-layer defence is belt-and-braces protection. Pod egress policies and VPC security groups block 169.254.169.254 outbound from non-system workloads, and detection on egress attempts surfaces compromise indicators.

• Pod egress policy. Block 169.254.169.254 from non-system pods; even if IMDSv2 fails, the network policy blocks.
• VPC security groups. Deny outbound to instance metadata from non-system pods; defence in depth at the VPC layer.
• Egress logging. Log egress attempts to metadata; spike in attempts is a compromise indicator.
• Per-namespace policy match. Default-deny egress with explicit allow lists; supports the principle of least access at the network layer.

Operating with metadata protection

Operational discipline keeps the protection real. Standard launch templates enforce IMDSv2 and hop-limit-1; quarterly fleet audits surface non-compliant instances; the inventory of legacy IMDSv1 workloads is tracked as a migration backlog rather than indefinite deferral.

• Standard launch templates. IMDSv2 and hop-limit-1 enforced by default; new instances inherit; non-compliant instances flagged in config rules.
• Quarterly fleet audit. IMDSv1-allowed instances surfaced; migrate or document why; the audit closes the loop.
• Legacy IMDSv1 inventory. Old SDKs, third-party agents tracked as migration backlog; each is a project to update or replace.
• Per-team migration cadence. Documented per-quarter migration target; supports steady progress against the legacy backlog.