How does IMDSv2 mitigate SSRF-based cloud credential theft, and what defense-in-depth complements it?

The cloud instance metadata service (169.254.169.254) hands out temporary IAM credentials to the instance, making it a prime SSRF target. IMDSv1 answers any GET to that endpoint, so a simple SSRF (fetch('http://169.254.169.254/latest/meta-data/iam/...')) leaks creds. IMDSv2 is session-oriented: the client must first PUT to obtain a short-lived token (requiring a non-trivial header) and include it on subsequent GETs — a header most SSRF primitives can't set, and it also enforces a low IP TTL that blocks simple proxy/redirect pivots. Enforce IMDSv2-only (disable v1) and set the hop limit to 1. Defense-in-depth: allow-list outbound destinations, block link-local/RFC1918 ranges and metadata IPs at the egress/proxy layer, disable unused URL schemes, validate-then-refetch to defeat DNS rebinding, and apply least-privilege IAM so a leaked role is low-value.