---
title: AWS Instance Metadata Service v1 (IMDSv1) should not be used
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > AWS Instance Metadata Service v1
  (IMDSv1) should not be used
---

# AWS Instance Metadata Service v1 (IMDSv1) should not be used
 
## Security recommendation{% #security-recommendation %}

| Impact | Remediation complexity | Severity | Recommended value                                                       |
| ------ | ---------------------- | -------- | ----------------------------------------------------------------------- |
| 4      | 3                      | 3        | Workloads should use IMDSv2 exclusively to access AWS instance metadata |

The AWS Instance Metadata Service version 1 (IMDSv1) is a request/response protocol that does not require session tokens. It is susceptible to server-side request forgery (SSRF) attacks, which can be abused to retrieve the EC2 instance profile credentials. IMDSv2 mitigates this risk by requiring a session-oriented token-based protocol. All workloads should use IMDSv2 exclusively.

## Compliance{% #compliance %}

- Restrict access to instance metadata to IMDSv2 ([found in CIS AWS Foundations Benchmark](https://www.cisecurity.org/cis-benchmarks))

## Documentation{% #documentation %}

The EC2 Instance Metadata Service (IMDS) is reachable from any process on an EC2 instance (or any container running on it) at the link-local address `169.254.169.254`. IMDS exposes instance metadata, including the temporary credentials attached to the instance profile. These credentials can be used to authenticate to AWS APIs with the permissions of the instance role.

IMDSv1 uses simple, unauthenticated `GET` requests, which makes it trivially exploitable through SSRF vulnerabilities in workloads exposed to the network: an attacker who can coerce a vulnerable process into making an outbound HTTP request can retrieve the instance credentials and pivot into the AWS account.

IMDSv2 mitigates this class of attack by requiring callers to first obtain a session token via a `PUT` request that includes a TTL hop limit. SSRF flaws that only allow `GET` requests are unable to obtain the session token, and therefore cannot retrieve the credentials.

This finding is raised when the Workload Protection agent observes a process on the host (or in a container running on the host) accessing the EC2 metadata service using the IMDSv1 protocol. Findings are scoped to the host, since IMDSv2 enforcement is an instance-level configuration.

## Remediation{% #remediation %}

### Prerequisites{% #prerequisites %}

You must have:

- Access to the AWS console or AWS CLI with permissions to modify EC2 instance metadata options
- Knowledge of the applications running on the instance and the AWS SDK / IMDS client libraries they use
- Agent v7.60 or newer for Workload Protection IMDS monitoring

### Step-by-step guide{% #step-by-step-guide %}

#### Step 1: Identify the process making IMDSv1 requests{% #step-1-identify-the-process-making-imdsv1-requests %}

Use the agent event details to identify which process is calling IMDSv1, on which host, and from which container (if any).

In the Workload Protection event details, look at:

- `process.file.name` and `process.file.path` — the executable making the IMDSv1 call
- `process.ancestors` — the call chain leading to the request
- `container.id` / `container.name` — the originating container, if any
- `host` — the EC2 instance hosting the workload

On the host itself, you can also correlate against network logs:

```bash
# Recent connections to the IMDS endpoint
sudo ss -tnp | grep 169.254.169.254

# Live capture of IMDS traffic
sudo tcpdump -i any -n host 169.254.169.254

# Process tree for further context
ps -ef --forest
```

#### Step 2: Update the application to use IMDSv2{% #step-2-update-the-application-to-use-imdsv2 %}

For applications using the AWS SDK, upgrade to a recent SDK version that uses IMDSv2 by default and ensure the SDK is configured to use it:

- AWS SDK for Go v2, AWS SDK for Java v2, AWS SDK for Python (boto3) >= 1.20, AWS SDK for JavaScript v3, AWS SDK for Rust, etc., all use IMDSv2 by default.
- If your application uses raw HTTP calls to the metadata endpoint, update it to first request a session token:

```bash
# Request an IMDSv2 session token (valid for up to 6 hours)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Use the token on subsequent metadata requests
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/
```

#### Step 3: Enforce IMDSv2 on the EC2 instance{% #step-3-enforce-imdsv2-on-the-ec2-instance %}

Once all workloads on the instance support IMDSv2, enforce it at the instance level so that IMDSv1 requests are rejected by AWS.

```bash
# Require IMDSv2 (HttpTokens=required) and keep the default hop limit
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled
```

For Auto Scaling groups, update the launch template:

```bash
aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version "\$Latest" \
  --launch-template-data '{"MetadataOptions":{"HttpTokens":"required","HttpEndpoint":"enabled"}}'
```

For Terraform-managed instances, set `metadata_options` on the `aws_instance` or `aws_launch_template` resource:

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

#### Step 4: Prevent regression{% #step-4-prevent-regression %}

- Set the account-level default to require IMDSv2 for new instances:

```bash
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-endpoint enabled
```

- Add a guardrail (AWS Config rule, SCP, or CSPM policy) to flag any instance launched with `HttpTokens=optional`.
- Continue to monitor this finding in Workload Protection — re-emergence indicates a new workload or rolled-back configuration.