Amazon EC2 User Data and Instance Metadata – SAP-C02 Study Guide

Purpose of This Lesson

Amazon EC2 provides two closely related capabilities for configuring and inspecting instances:

• Instance metadata exposes information about the running instance through a link-local HTTP endpoint.
• User data runs initialization commands when an instance is launched.

Together, they support instance bootstrapping, configuration automation, and runtime discovery. They are also common SAP-C02 exam topics because they involve security controls, launch behavior, and operational tradeoffs.

Key Concepts

EC2 Instance Metadata

Instance metadata is information about the EC2 instance available from within the instance itself. The Instance Metadata Service (IMDS) is accessed through the link-local IPv4 address:

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

Because this address is link-local, it is accessed from the instance rather than through the public internet. Metadata can include information such as:

• AMI ID
• Hostname
• Private IPv4 address
• Public IPv4 address, when one is assigned
• Instance identity information
• Other instance configuration details exposed by the service

For example, a Linux instance can query its private address with a command similar to:

curl http://169.254.169.254/latest/meta-data/local-ipv4

The response is printed directly by curl; it may appear immediately before the shell prompt when the output does not include a trailing newline.

IMDSv1 and IMDSv2

AWS supports two versions of the Instance Metadata Service:

Version	Request model	Security characteristic
IMDSv1	Direct HTTP request	Older model; no session token required
IMDSv2	Session-oriented request	Requires a session token before metadata requests are made

IMDSv2 is the preferred option because it adds a token-based request flow and helps reduce risks associated with unauthorized metadata access, including some types of server-side request forgery (SSRF) exploitation.

A typical IMDSv2 interaction consists of:

1. Requesting a session token from the metadata endpoint.
2. Supplying that token in subsequent metadata requests.
3. Using the token for the duration defined by the token request.

A simplified Linux example is:

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

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

When launching an EC2 instance, metadata access can generally be configured to:

• Allow IMDSv1 and IMDSv2.
• Require IMDSv2 tokens.
• Disable the Instance Metadata Service entirely.

For security-sensitive workloads, requiring IMDSv2 is normally preferable to retaining compatibility with IMDSv1. Disabling metadata completely is stronger still, but only when applications and management processes do not need metadata or instance role credentials obtained through the service.

EC2 User Data

User data is launch-time input supplied to an EC2 instance. It is commonly used as a bootstrap script to perform first-start configuration, such as:

• Installing operating system packages
• Applying updates or patches
• Installing and starting a web server
• Creating configuration files
• Registering the instance with another system

Linux instances commonly use shell scripts or cloud-init-compatible content. Windows instances can use batch files or PowerShell scripts.

A conceptual Linux example is:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl enable httpd
systemctl start httpd

User data can be supplied through the EC2 console or through the AWS CLI. In either case, AWS expects the content to be Base64 encoded at the API level. The console and CLI handle encoding in common workflows, so users generally provide the script content or a file rather than manually encoding it.

The raw user data limit is 16 KB before Base64 encoding. Larger initialization workflows should use user data to invoke a more scalable configuration mechanism, such as retrieving scripts or configuration from Amazon S3, Systems Manager, or another controlled source.

User Data Execution Behavior

The key behavior for exam questions is that user data is intended for the instance’s initial launch and bootstrap process. Editing user data later does not automatically cause the updated script to execute when the instance is stopped and started.

This means user data should not be treated as a general-purpose recurring configuration management system. For repeatable changes after launch, use an appropriate operational tool such as AWS Systems Manager or a configuration management platform.

Combining User Data and Metadata

User data and metadata can be used together. For example, a bootstrap script can query metadata to discover the instance’s private IP address, hostname, or identity information and then use those values to generate configuration.

This creates a dynamic bootstrap process, but scripts should handle metadata access securely. If IMDSv2 is required, the script must obtain and send a session token rather than using unauthenticated IMDSv1 requests.

Exam-Relevant Takeaways

• The EC2 metadata endpoint begins with http://169.254.169.254/latest/.
• Instance metadata is retrieved from inside the EC2 instance.
• IMDSv1 permits direct metadata requests without a token.
• IMDSv2 requires a session token and is the preferred security posture.
• Metadata options can require IMDSv2 or disable metadata access.
• User data is used for instance initialization and bootstrap automation.
• User data supports Linux shell scripts and Windows batch or PowerShell scripts.
• User data is limited to 16 KB in raw form before Base64 encoding.
• Console and CLI workflows commonly handle Base64 encoding automatically.
• Changing user data after launch does not, by itself, rerun the script on a normal stop/start cycle.
• A bootstrap script can query metadata, but it must use the correct IMDS version and request pattern.

Architecture Decision Guide

Requirement	Recommended approach	Reasoning
Discover an instance’s private IPv4 address from inside the instance	Query EC2 instance metadata	The value is available locally without an external control-plane call
Bootstrap a web server during initial launch	Supply user data	A launch-time script can install and start software
Protect metadata from applications that should not make unauthenticated requests	Require IMDSv2	Token-based access improves metadata request security
Workload has no need for metadata or instance role credentials	Consider disabling IMDS	Removes an unnecessary access path, subject to application compatibility
Apply configuration repeatedly across an instance fleet	Use Systems Manager or configuration management	User data is not a recurring configuration engine
Bootstrap logic exceeds 16 KB	Keep a short user-data launcher and retrieve content elsewhere	Avoids the raw user-data size limit
Support older software that only understands IMDSv1	Allow compatibility only when necessary, then plan remediation	IMDSv2-only is safer, but legacy dependencies may require transition planning

Common Exam Traps

• Confusing metadata with user data: Metadata describes the instance; user data is input used to initialize it.
• Assuming metadata is publicly reachable: The standard endpoint is link-local and is intended to be accessed from the instance.
• Forgetting the IMDSv2 token: A direct curl request that works with IMDSv1 will fail when the instance requires IMDSv2 unless a token is obtained and included.
• Assuming edited user data reruns automatically: Changing the field in the console does not itself trigger another execution.
• Ignoring the encoding limit: The 16 KB limit applies before Base64 encoding, not to the larger encoded representation.
• Treating user data as a secrets store: Bootstrap scripts may be inspectable through instance mechanisms. Do not place long-lived secrets directly in user data; use an appropriate secrets or parameter service with IAM controls.
• Disabling IMDS without checking dependencies: Applications may rely on metadata for instance identity or credentials supplied through an attached IAM role.
• Using user data for fleet-wide drift correction: Initial bootstrap is different from ongoing configuration enforcement.

Real-World Engineer Notes

• Prefer IMDSv2-only settings for new workloads unless a documented compatibility requirement prevents it.
• Test bootstrap scripts on the exact operating system and AMI family being used. Package managers, service names, and initialization behavior differ between distributions.
• Make scripts observable. Log installation and configuration steps so failures can be diagnosed through the instance’s system logs or centralized logging.
• Make bootstrap actions as idempotent as practical. Even if the script is intended for first launch, safe reruns simplify replacement, testing, and recovery workflows.
• Keep user data small. Store larger scripts and versioned configuration in a controlled location, and grant the instance only the IAM permissions it needs to retrieve them.
• Treat metadata access as a security boundary. Requiring IMDSv2 helps, but application vulnerabilities and excessive instance-role permissions still need to be addressed.
• If an instance must be rebuilt consistently, prefer immutable replacement through an AMI or an automated image-building pipeline rather than relying on manual edits to an existing instance.

Quick Reference Summary

Item	Summary
Metadata endpoint	http://169.254.169.254/latest/meta-data/
Metadata purpose	Retrieve information about the running EC2 instance
IMDSv1	Direct requests; older and less secure
IMDSv2	Token-required requests; preferred for new deployments
User data purpose	Run initialization code during the instance launch process
Supported script types	Linux shell scripts; Windows batch and PowerShell scripts
Raw user-data limit	16 KB before Base64 encoding
Best ongoing-management tool	Systems Manager or another configuration-management solution

Flashcards

1. Q: What is EC2 instance metadata?

A: Information about the running EC2 instance, retrieved through the Instance Metadata Service.

1. Q: What is the standard IPv4 address for the EC2 metadata service?

A: 169.254.169.254.

1. Q: What is the main difference between IMDSv1 and IMDSv2?

A: IMDSv1 accepts direct requests, while IMDSv2 requires a session token.

1. Q: Which metadata service version is preferred for new deployments?

A: IMDSv2.

1. Q: What is EC2 user data used for?

A: Supplying initialization commands or scripts that configure an instance during launch.

1. Q: Can Windows EC2 instances use user data?

A: Yes. They can use batch scripts or PowerShell scripts.

1. Q: What is the raw EC2 user-data size limit?

A: 16 KB before Base64 encoding.

1. Q: Does editing user data after launch automatically execute the updated script?

A: No. Editing it does not automatically rerun the script on a subsequent stop/start.

1. Q: How can a script retrieve an instance’s private IPv4 address?

A: Query the metadata path latest/meta-data/local-ipv4.

1. Q: What should a script do when IMDSv2 is required?

A: Obtain a metadata session token and include it in subsequent metadata requests.

1. Q: When might IMDS be disabled?

A: When the workload has no requirement for instance metadata or metadata-provided instance-role credentials.

1. Q: What is a better choice than user data for recurring fleet configuration?

A: AWS Systems Manager or another configuration-management platform.

Practice Questions

Question 1

A company launches EC2 instances with a bootstrap script that installs a web server. Security policy requires protection against applications making unauthenticated metadata requests. The application does not require IMDSv1 compatibility. Which configuration best meets the requirement?

A. Enable IMDSv1 only
B. Enable both IMDSv1 and IMDSv2
C. Require IMDSv2 tokens
D. Disable user data

Correct answer: C

Explanation: Requiring IMDSv2 forces metadata clients to obtain and present a session token. User data and metadata are separate features, so disabling user data is unrelated to the metadata security requirement.

Question 2

An engineer edits the user-data script of a stopped EC2 instance and starts the instance again. The updated commands do not run. What is the most likely explanation?

A. User data is limited to Windows instances.
B. User data is evaluated during the initial launch/bootstrap process and does not automatically rerun after editing.
C. User data must be stored in Amazon S3.
D. IMDSv2 prevents user data from executing.

Correct answer: B

Explanation: User data is primarily a first-launch initialization mechanism. Updating the stored value does not itself cause the new script to execute on a normal stop/start operation.

Question 3

A Linux bootstrap script must obtain the instance’s private IPv4 address. The instance is configured to require IMDSv2. Which sequence should the script use?

A. Query local-ipv4 directly without headers.
B. Request an IMDSv2 session token, then include it in the metadata request.
C. Query the public DNS name through Route 53.
D. Read the address from the AMI ID.

Correct answer: B

Explanation: IMDSv2 requires a token before metadata requests can be made. The private IPv4 address is available through the latest/meta-data/local-ipv4 path.

Question 4

A user-data script has grown to 40 KB and must configure newly launched instances. Which design is most appropriate?

A. Continue adding content to user data because Base64 removes the size restriction.
B. Compress the script until it fits and assume the limit applies after encoding.
C. Use a short user-data bootstrapper to retrieve the larger script from a controlled source.
D. Put the script in instance metadata.

Correct answer: C

Explanation: Raw user data is limited to 16 KB before Base64 encoding. A small bootstrap script can retrieve and execute larger, versioned content from an appropriate service, subject to least-privilege IAM permissions.

Question 5

An organization wants to continuously enforce package versions and configuration settings across thousands of EC2 instances. Which solution is a better fit than relying only on user data?

A. Repeatedly edit user data in the EC2 console
B. Use AWS Systems Manager or a configuration-management solution
C. Allow IMDSv1 on every instance
D. Reboot instances on a schedule

Correct answer: B

Explanation: User data is intended for initialization, not ongoing fleet configuration or drift correction. Systems Manager and configuration-management tools are designed for repeatable operational management.