Instance Metadata Service (IMDS)

The first version of the Instance Metadata Service, IMDSv1, is straightforward. 

Each EC2 instance in AWS has access to a special IP address (169.254.169.254) that hosts metadata about the instance itself. By making simple HTTP GET requests to this address, an application or user can retrieve information like:

• The instance ID and AMI ID
• Availability zone and region
• Network interface details
• IAM role credentials (temporary access keys and tokens)
• Custom user data passed at launch

Here’s a basic example:

curl http://169.254.169.254/latest/meta-data/instance-id

This request returns the unique identifier for the running instance. There are no authentication requirements or rate limits because the metadata service is only accessible from within the instance.

That simplicity is part of what made IMDSv1 widely adopted, but also made it vulnerable. Without any form of request validation, any process running on the instance (or, in some cases, abusing misconfigured applications) could access sensitive metadata. That risk becomes clearer when you understand how attackers exploit it, which we’ll explore next.

The open and unauthenticated design of IMDSv1 creates a clear opportunity for attackers, especially when combined with Server-Side Request Forgery (SSRF) vulnerabilities. 

In an SSRF attack, a malicious actor tricks a vulnerable web application into making internal requests on their behalf. If that application runs inside an EC2 instance, it can be exploited to fetch metadata from IMDS.

Why is this dangerous? One of the most sensitive pieces of data available from IMDS is temporary IAM credentials. These credentials are tied to the instance’s IAM role and can include permission to read from S3 buckets, write to DynamoDB, invoke Lambda functions, or access other cloud services. 

If an attacker gains access to them, they can operate as if they were the EC2 instance and potentially move laterally or exfiltrate data.

Real-world examples

This risk is not hypothetical. Multiple breaches have been linked to SSRF attacks targeting IMDS. In some cases, even containers running on shared hosts could access metadata when isolation was misconfigured.

The problem is made worse because IMDSv1 remains enabled by default in many legacy AMIs and account setups. Security teams may believe their environment is protected while still relying on insecure defaults.

For a deeper look at how these risks play out in real systems, see Severity Matters: IMDSv1 > IMDSv2, which maps the full attack path from misconfigured metadata to credential compromise.

To address the security flaws of IMDSv1, AWS introduced IMDSv2, a more secure version of the metadata service that protects against SSRF and unauthorized access.

IMDSv2 changes how applications access metadata. Instead of allowing direct GET requests, a session-based, token-authenticated process is required. Here’s how it works:

• The instance makes a PUT request to the metadata endpoint to obtain a session token.
• It then includes that token in the headers of a GET request to retrieve metadata.

This simple change adds meaningful protection. External attackers exploiting SSRF vulnerabilities can no longer fetch metadata unless they also find a way to issue a PUT request with custom headers, which is significantly harder in most SSRF scenarios.

Key Improvements in IMDSv2

• Token authentication: Requests without a valid token are rejected.
• Hop limit control: Limits the number of network hops allowed to reach the metadata service. This blocks container escapes or indirect access from neighboring workloads.
• Session TTLs: Tokens can be short-lived, limiting exposure if they are ever compromised.
• Optional enforcement: IMDSv2 can be required at the instance level, preventing fallback to the older version.

While IMDSv2 doesn’t eliminate the need for secure application design, it significantly reduces the attack surface. In many environments, enabling and enforcing IMDSv2 is one of the easiest and most effective steps teams can take to protect cloud resources.

Enabling IMDSv2 is straightforward, but enforcement is key. Simply having it available is not enough. By default, many EC2 instances still allow both IMDSv1 and IMDSv2. To lock down access, you must explicitly require token usage.

Set IMDSv2 as Required

When launching a new EC2 instance, you can configure metadata settings to require IMDSv2. This can be done via the AWS Console, CLI, or Infrastructure as Code tools like Terraform.

AWS CLI example:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-endpoint enabled \
  --http-tokens required \
  --http-put-response-hop-limit 2

Terraform example:

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

This configuration ensures that metadata access requires a valid session token and restricts how far requests can travel through the network stack to reach the service.

Instance vs. Account-Level Defaults

While you can set IMDSv2 requirements at the instance level, AWS also supports setting defaults at the account or organization level using service control policies and launch templates. This is particularly useful in environments with many teams or automated deployments.

If you’re unsure what your current configuration looks like, tools like AWS Config or custom scripts can help audit metadata settings across your fleet. 

Even with these controls available, many environments still struggle with IMDS misconfigurations that are often buried under layers of other cloud findings and inherited defaults. Understanding why these issues persist is just as important as knowing how to fix them.

Despite clear guidance from AWS and security teams, IMDSv1 remains enabled in many cloud environments. This isn’t always due to negligence. In many cases, it comes down to visibility, tooling gaps, or inherited infrastructure.

Some organizations use outdated AMIs that default to IMDSv1 and never enforce a newer policy. Others may assume IMDSv2 is active simply because the platform supports it, unaware that enforcement requires explicit configuration. In fast-moving cloud deployments, these details are easy to overlook, especially when multiple teams are responsible for provisioning and managing resources.

Cloud security platforms (CNAPPs) often flag IMDSv1 as a medium or low-severity misconfiguration, depending on context. If the instance is not publicly accessible or tied to sensitive IAM roles, it may not rise to the top of the alert queue. But that doesn’t mean it lacks risk. In high-volume environments, issues like this can sit unresolved for months, lost among thousands of other findings.

Security teams are often overwhelmed by volume and forced to prioritize only the most urgent alerts. In this kind of environment, solving low-friction issues like IMDSv1 enforcement should be easy, but in practice, it rarely is. 

What helps is not just knowing a misconfiguration exists, but understanding where it lives, what it affects, and how to address it in the broader context of the environment.

Instance Metadata Service is a powerful feature of AWS, but it comes with real security tradeoffs when left in its original form. 

IMDSv1, while simple and widely adopted, opens the door to credential theft and privilege escalation if misused or exposed through SSRF vulnerabilities. IMDSv2 offers a strong defense, but it must be explicitly configured and enforced to be effective.

Security teams should regularly audit metadata settings across their environments, especially in older instances or automated deployments. Enforcing IMDSv2, setting hop limits, and disabling metadata access where it’s not needed are all low-effort, high-impact ways to reduce exposure.

For organizations already juggling thousands of cloud alerts, these misconfigurations can easily fall through the cracks. In some cases, external partners or managed services can help surface and prioritize these types of risks, bringing clarity to an otherwise noisy environment.

Even simple issues can lead to real consequences if ignored. IMDS is one of those details worth getting right.

What is the difference between IMDSv1 and IMDSv2 in AWS?

IMDSv1 uses simple HTTP GET requests and does not require authentication, which makes it vulnerable to attacks like SSRF. IMDSv2 improves security by requiring a session-based token for metadata access and includes additional protections like hop limit controls and token TTLs.

Why is IMDSv1 considered a security risk in cloud environments?

Because IMDSv1 allows any process on an EC2 instance to access metadata, including IAM role credentials, it can be exploited in SSRF attacks. This gives attackers a potential path to escalate privileges or move laterally in the environment.

Is IMDSv2 enabled by default in AWS?

IMDSv2 is available by default but not enforced. Most EC2 instances allow both IMDSv1 and IMDSv2 unless explicitly configured to require token-based access.

How can I check if IMDSv1 is still enabled in my AWS environment?

Use AWS Config, the AWS CLI, or Infrastructure as Code scanning tools to review instance metadata settings. You’ll want to confirm whether http-tokens is set to required and whether fallback to IMDSv1 is disabled.

What role does metadata security play in cloud misconfigurations?

Instance metadata exposure is one of the most common and often overlooked misconfigurations. It’s frequently flagged as medium severity, which means it can sit unresolved despite posing a real risk, especially in environments with SSRF vulnerabilities or overly broad IAM permissions.