AWS EC2 Instance Metadata Service and Important IP Addresses

169.254.169.254 is one of the most important IP addresses to recognise in AWS. It is the IPv4 endpoint for the Amazon EC2 Instance Metadata Service (IMDS), a link-local service that lets software running on an EC2 instance retrieve information about that instance.

The service can provide instance identity, placement, networking details, user data, and temporary credentials for an IAM role attached to the instance. It does not require Internet access because the address is reached from inside the EC2 environment.

This is Part 41 of the AWS Cloud Practitioner Study Notes. The most important exam answer is:

169.254.169.254
→ EC2 Instance Metadata Service (IMDS)
→ Instance information and temporary IAM-role credentials

Why this address is special

169.254.169.254 belongs to the IPv4 link-local range 169.254.0.0/16. Link-local addresses are intended for local communication and are not Internet-routable public addresses.

An EC2 application can send an HTTP request to the address through the instance’s local environment:

EC2 instance
        │
        │ HTTP request
        ▼
169.254.169.254
        │
        ▼
EC2 Instance Metadata Service

No NAT gateway, Internet gateway, or public IP address is required. The address is special to the EC2 platform rather than being a normal host on the VPC subnet.

What is EC2 instance metadata?

Metadata is information about the running EC2 instance. Common categories include:

• Instance ID and instance type
• AMI ID and hostname
• Private and public IPv4 information
• MAC address, subnet, VPC, and security-group information
• Availability Zone and Region
• Attached IAM role information
• Instance identity document

An application, monitoring agent, bootstrap process, or troubleshooting script can use this information to understand where it is running and configure itself accordingly.

Example metadata values might look like:

Instance ID:       i-0123456789abcdef0
Instance type:     t3.medium
Availability Zone: ap-southeast-1a
Private IPv4:      10.0.1.25
Region:            ap-southeast-1

Common metadata endpoints

The metadata path begins with:

http://169.254.169.254/latest/meta-data/

Examples include:

http://169.254.169.254/latest/meta-data/instance-id
http://169.254.169.254/latest/meta-data/ami-id
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-ipv4
http://169.254.169.254/latest/meta-data/placement/

With IMDSv1, a simple request can retrieve a value such as the instance ID:

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

For production workloads, prefer IMDSv2 and configure the instance to require it.

IAM roles and temporary credentials

The most important practical use of IMDS is helping an EC2 application obtain temporary credentials for its attached IAM role.

Suppose a Go or Python application needs to upload objects to S3, write logs, read a secret, or send a message to SQS. Do not place a long-lived access key and secret key in the source code. Attach an IAM role to the EC2 instance instead:

EC2 instance with IAM role
        ↓
Instance Metadata Service
        ↓
Temporary role credentials
        ↓
AWS SDK signs the request
        ↓
S3, SQS, Secrets Manager, or another AWS service

The AWS SDK uses its default credential provider chain and can retrieve the role credentials through IMDS. The application normally does not need to call 169.254.169.254 directly or manually manage the credentials.

A common credential path is:

/latest/meta-data/iam/security-credentials/

The response identifies the role name. A request using that role name returns temporary credential fields such as an access key ID, secret access key, session token, and expiration time. AWS rotates temporary role credentials; they are not equivalent to hardcoded long-lived credentials.

Exam shortcut: an EC2 application needs AWS access without embedded keys → attach an IAM role and let the AWS SDK obtain temporary credentials through IMDS.

IMDSv1 versus IMDSv2

IMDSv1

IMDSv1 uses a direct request to the metadata endpoint. Its simple request model has no session token:

GET metadata endpoint
        ↓
Metadata response

This simplicity creates additional risk if an application has a server-side request forgery (SSRF) vulnerability or another path that allows an attacker to send requests from the instance environment.

IMDSv2

IMDSv2 uses a session-oriented flow. The client first requests a token with an HTTP PUT, then includes that token in subsequent metadata requests:

Request token with PUT
        ↓
Receive session token
        ↓
Send GET request with token
        ↓
Receive metadata

Example:

TOKEN=$(curl -X PUT \
  "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

IMDSv2 adds protection against several metadata-access paths, including some SSRF scenarios. It is not a replacement for fixing the vulnerable application, applying least privilege, or controlling which processes and containers can access metadata.

IMDSv1 → direct GET request
IMDSv2 → token-required session
Recommended → require IMDSv2 when possible

Metadata versus user data

Metadata and user data are both available through the EC2 metadata service, but they have different purposes:

Feature	Metadata	User data
Created by	AWS platform	You or your deployment tool
Contains	Information about the instance	Startup script or custom launch data
Example	Instance ID, Region, IAM role	Install Nginx and start a service
Main purpose	Discover instance identity and environment	Bootstrap the instance
Security note	Accessible to software with instance access	Can also be viewed from the instance

Example user data:

#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx

Think of the difference this way:

Metadata = information about me
User data = instructions supplied to me

Do not store passwords, private keys, or long-lived credentials in user data, metadata-related configuration, or instance tags. Use an appropriate secret-management solution and IAM permissions instead.

Useful production use cases

Discover placement

An application can retrieve its Region and AZ and add them to logs or metrics. In a multi-AZ Auto Scaling group, this helps engineers identify whether failures are concentrated in one AZ.

Add instance identity to monitoring

A monitoring agent can retrieve the instance ID, type, and AZ and attach them to telemetry:

CPUUsage{
  instance_id="i-0123456789abcdef0",
  availability_zone="ap-southeast-1a"
}

Configure reusable images

A single AMI can be launched many times. Each instance can read its own metadata and load the appropriate configuration for its Region, AZ, or identity. This is useful in Auto Scaling groups and multi-AZ deployments.

Retrieve enabled instance tags

EC2 can make enabled instance tags available through IMDS. A bootstrap process could read an Environment=Production tag and load a matching non-secret configuration. Tags are not a secure place for passwords or tokens.

Verify instance identity

The instance identity document, available through the dynamic metadata category, contains signed information such as the instance ID, AWS account ID, Region, AZ, instance type, and AMI ID. A registration service can use it to verify that a machine is an EC2 instance with the expected identity.

Security best practices

For a production EC2 workload:

• Require IMDSv2 and avoid depending on IMDSv1.
• Attach an IAM role with least-privilege permissions.
• Use modern AWS SDKs and keep them updated.
• Never hardcode long-lived AWS credentials.
• Do not put secrets in user data or instance tags.
• Restrict application and container access to metadata where appropriate.
• Disable IMDS when the instance and its software genuinely do not need it.
• Treat a vulnerable application that can reach metadata as a security issue requiring immediate remediation.

IMDS is local, but “local” does not mean automatically safe. Any process with suitable access from inside an instance may be able to request metadata, so application security and workload isolation still matter.

Common exam and interview questions

An EC2 instance needs temporary AWS credentials. Where do they come from?

The instance’s attached IAM role, retrieved through the EC2 Instance Metadata Service.

Which IP address identifies the EC2 metadata service?

169.254.169.254.

Does IMDS require Internet access?

No. It is a local link-local service available from the EC2 environment.

Which metadata version is preferred?

IMDSv2, because it requires a session token and provides stronger protection against several metadata-access attacks.

Where does an application get its instance ID or Region?

From instance metadata.

Where does an EC2 startup script come from?

User data, which is supplied at launch and can also be retrieved through the metadata service.

Final memory map

169.254.169.254
        ↓
EC2 Instance Metadata Service
        ↓
Instance information + user data + IAM-role credentials

IAM role
        ↓
Temporary credentials

IMDSv1
        ↓
Direct GET

IMDSv2
        ↓
Token then GET

The number-one answer to remember is: an EC2 application uses 169.254.169.254 to obtain instance metadata, especially temporary credentials for its attached IAM role, without storing long-lived credentials in the application.

Sources

• Use the Instance Metadata Service to access instance metadata
• Instance metadata categories
• IAM roles for Amazon EC2
• Retrieve instance tags from instance metadata