Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon EC2 user data and instance metadata solve two different problems during instance startup:
- User data supplies bootstrap instructions or scripts to an instance when it launches.
- Instance metadata provides information about the running instance, such as its instance ID, hostname, network interfaces, and temporary IAM role credentials.
Together, they allow an instance to configure itself and discover runtime-specific information without hard-coding values into an image or script.
Key Concepts
EC2 user data
User data is data supplied when an EC2 instance is launched. It is commonly used for initial configuration tasks such as:
- Installing operating system packages
- Applying updates or patches
- Installing and configuring a web server
- Writing configuration files
- Starting application services
- Registering the instance with a configuration or service-discovery system
On Linux, user data commonly contains a shell script beginning with a shebang such as #!/bin/bash. On Windows, it can contain PowerShell or other supported initialization commands.
For Linux instances using cloud-init, user data is generally processed during the initial boot. It is not automatically intended to run on every reboot. If a script must run repeatedly, configure that behavior explicitly using cloud-init directives, systemd, or another operating-system mechanism.
User data is not a replacement for a full configuration-management system when instances require complex, repeatable, or ongoing configuration. For larger environments, consider EC2 Image Builder, AWS Systems Manager, CloudFormation, or another automation platform.
EC2 instance metadata
Instance metadata is information available from inside an EC2 instance through the Instance Metadata Service (IMDS). It can provide details such as:
- Instance ID
- AMI ID
- Instance type
- Availability Zone and region-related information
- Local and public network addresses
- Network interface details
- IAM role credentials associated with the instance
A bootstrap script can query metadata at launch time and use the returned values in generated files or application configuration. This avoids embedding instance-specific values in an AMI or user-data script.
The metadata endpoint is available through a link-local address. Modern implementations should use IMDSv2, which requires a session token before metadata requests are made. For example, a Linux script can obtain a token and then query the instance ID:
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/instance-id)
IMDSv2 helps reduce risks associated with unintended metadata access, including some server-side request forgery (SSRF) scenarios. EC2 configuration can require IMDSv2 and can limit or disable metadata access when it is not needed.
Combining user data and metadata
A common pattern is:
- EC2 launches with a user-data script.
- The script installs and starts a service.
- The script queries metadata for the current instance ID or network information.
- The script writes that value into a configuration file or web page.
- The service uses the generated configuration.
For example, a web server can display its own instance ID. This is useful for validating that requests are reaching the expected instance behind a load balancer, although production applications should generally expose a controlled health or diagnostic endpoint rather than raw instance details.
Network access is separate from instance configuration
Installing a web server does not make it reachable from the internet. The network path must also permit access:
- The instance needs a route to the client, usually through an internet gateway for public IPv4 access.
- The security group must allow inbound TCP port 80 for HTTP, or TCP port 443 for HTTPS.
- Network ACLs, routing, DNS, and operating-system firewalls must also be compatible with the traffic flow.
A security group rule for HTTP is independent of the user-data script that installs the web server.
Exam-Relevant Takeaways
- User data is bootstrap input; metadata is runtime instance information. Do not confuse the two.
- User data is supplied at launch and is commonly used for one-time initialization.
- User data can be passed as plain text or uploaded from a file in the EC2 launch workflow.
- A script can use metadata to avoid hard-coding an instance ID, Availability Zone, IP address, or other instance-specific value.
- Prefer IMDSv2 and require it where practical through instance or account-level configuration.
- An IAM role is the appropriate way for instance applications to obtain AWS API credentials. Do not place long-term access keys in user data or AMIs.
- Opening a security group port is required for network access, but it does not install or start the application.
- User data is not a complete substitute for immutable images, Systems Manager, or configuration management in a fleet.
- Treat user data and metadata-derived values as potentially sensitive. User data may be retrievable through instance interfaces and should not contain secrets.
- For scalable architectures, use an Auto Scaling group and a launch template to apply the same bootstrap configuration consistently to replacement instances.
Architecture Decision Guide
| Requirement | Recommended approach | Reason |
|---|---|---|
| Install a small number of packages during initial boot | EC2 user data with cloud-init or PowerShell | Simple launch-time bootstrapping |
| Create an image with repeatable OS and application configuration | EC2 Image Builder or a baked AMI | Faster and more predictable instance startup |
| Apply ongoing configuration or run operational commands | AWS Systems Manager State Manager or Run Command | Supports fleet-wide operations after launch |
| Retrieve the current instance ID from inside an instance | IMDS, preferably IMDSv2 | Avoids hard-coded instance-specific values |
| Give an application permission to call AWS APIs | Attach an IAM role through an instance profile | Provides temporary credentials without embedded keys |
| Configure instances consistently in an Auto Scaling group | Launch template with user data, or a baked AMI plus launch template | Ensures replacement instances receive the required configuration |
| Expose a web service publicly | Public or load-balancer network path plus appropriate security-group rules | Application installation alone does not provide connectivity |
| Store passwords, API keys, or database credentials | AWS Secrets Manager or Systems Manager Parameter Store | Avoids exposing secrets in user data, AMIs, or source code |
Common Exam Traps
- Assuming user data runs continuously: It generally runs during initial boot. Ongoing execution requires explicit configuration.
- Confusing metadata with user data: User data is supplied to the instance; metadata is queried from the instance.
- Using the public IP as a permanent identity: Public IPv4 addresses can change when an instance stops and starts. Use stable identifiers such as an Elastic IP, private DNS strategy, or service discovery when appropriate.
- Forgetting the security group: A web server listening on port 80 remains unreachable if inbound HTTP is not allowed on the relevant security group.
- Allowing HTTP from anywhere without considering HTTPS: Public HTTP may be suitable for a demonstration or redirect endpoint, but sensitive production traffic should use TLS and tightly scoped access where possible.
- Putting credentials in user data: User data is not a secure secret store. Use an IAM role for AWS access and Secrets Manager or Parameter Store for application secrets.
- Using IMDSv1 by default: IMDSv2 is the preferred security posture and may be explicitly required by the exam scenario.
- Expecting user data to repair every future failure: Bootstrap scripts do not automatically provide drift remediation or fleet management.
- Ignoring script failures: A script may partially complete while the instance still appears healthy. Capture logs and use health checks or Systems Manager for operational visibility.
Real-World Engineer Notes
- Make bootstrap scripts idempotent where possible. A script should not corrupt configuration if a command is retried.
- Log user-data execution and inspect cloud-init logs when troubleshooting Linux instances. Common locations include
/var/log/cloud-init.logand/var/log/cloud-init-output.log, depending on the distribution. - Use package repositories, AMIs, and deployment artifacts that are version-pinned where reproducibility matters.
- Avoid long initialization times in an Auto Scaling group. If bootstrapping is substantial, bake more configuration into an AMI or use a deployment workflow that can report readiness.
- Do not expose raw instance metadata through a public web page in a real application. Instance IDs and network details may aid attackers or reveal unnecessary infrastructure information.
- If applications do not need metadata, disable IMDS access or configure the instance to require IMDSv2. Also limit hop count when containers or proxies are involved.
- Terminating test instances prevents unnecessary compute and public IPv4 charges and avoids leaving broad security-group rules in place.
Quick Reference Summary
- User data: Launch-time input used to bootstrap an EC2 instance.
- Metadata: Runtime information available from the instance metadata service.
- IMDSv2: Token-based metadata access mechanism and the preferred security option.
- Typical workflow: Launch instance → run user-data script → query metadata → generate configuration → start service.
- Web access requirements: Correct route, public or load-balancer path, security-group rule, and an application listening on the expected port.
- Secrets: Use IAM roles, Secrets Manager, or Parameter Store—not user data.
- Fleet operations: Prefer launch templates, Auto Scaling, baked AMIs, and Systems Manager for repeatable production automation.
Flashcards
- Q: What is EC2 user data used for?
A: Supplying launch-time bootstrap instructions, such as installing packages and configuring services.
- Q: What is EC2 instance metadata used for?
A: Discovering runtime information about the current instance, such as its instance ID, network details, or IAM role credentials.
- Q: How are user data and metadata different?
A: User data is provided to an instance by the launching mechanism; metadata is queried by the instance from IMDS.
- Q: Which version of the EC2 Instance Metadata Service should new designs prefer?
A: IMDSv2, which uses session tokens for metadata requests.
- Q: Does user data normally run on every reboot?
A: No. It is generally processed during initial boot unless repeat execution is explicitly configured.
- Q: How should an EC2 application obtain AWS API credentials?
A: Through an IAM role attached to the instance profile, using temporary credentials.
- Q: Why might a bootstrap script query the instance ID?
A: To generate instance-specific configuration without hard-coding the value into the AMI or script.
- Q: What else is needed after installing a web server on EC2?
A: A valid network path and security-group rules allowing the required port, such as TCP 80 or 443.
- Q: Where should application secrets be stored?
A: AWS Secrets Manager or Systems Manager Parameter Store, depending on the requirements.
- Q: What AWS feature helps apply the same user-data configuration to replacement instances?
A: An Auto Scaling group using a launch template or launch configuration, with launch templates preferred for modern designs.
Practice Questions
Question 1
A company launches EC2 instances in an Auto Scaling group. Each instance must install a web server during its first boot and generate a configuration file containing its own instance ID. Which solution best meets these requirements?
A. Store the instance ID in the AMI and retrieve it during startup.
B. Use launch-template user data to install the web server and query IMDS for the instance ID.
C. Assign the same Elastic IP address to every instance.
D. Store the instance ID in an S3 object before launching the group.
Correct answer: B
Explanation: User data performs the launch-time installation, while IMDS supplies the instance-specific ID. An AMI cannot contain a unique ID for every future instance, and an Elastic IP cannot be shared by multiple instances.
Question 2
An EC2 instance runs a public web server. The bootstrap script completes successfully, but clients cannot connect over HTTP. Which change is most directly required if the instance has a valid public route through an internet gateway?
A. Add an inbound TCP 80 rule to the instance security group.
B. Enable RDP in the security group.
C. Add the instance ID to the user data.
D. Replace the IAM role with an access key.
Correct answer: A
Explanation: HTTP uses TCP port 80. The application can be installed and running while the security group still blocks inbound traffic.
Question 3
A security review requires that EC2 instances use token-based metadata access and prevents applications from using the older metadata access method. What should the architect configure?
A. Require IMDSv2 for the instances.
B. Disable the instance profile.
C. Put AWS access keys in user data.
D. Allow inbound TCP 169.254.169.254 from the internet.
Correct answer: A
Explanation: Requiring IMDSv2 enforces token-based access to the metadata service. The metadata endpoint is link-local and should never be exposed through internet-facing security-group rules.
Question 4
A team places a database password in EC2 user data so the application can read it during startup. The security team rejects the design because the value could be exposed through instance administration interfaces and logs. What is the best replacement?
A. Encode the password with Base64 in user data.
B. Store the password in the AMI.
C. Store the password in Secrets Manager and allow the instance role to retrieve it.
D. Put the password in the instance tag.
Correct answer: C
Explanation: Secrets Manager provides managed secret storage and access control. The instance role supplies temporary AWS credentials without embedding a long-term secret in user data, an image, or metadata tags.
Question 5
An organization uses a lengthy user-data script to install and configure a large application stack. Instances take several minutes to become ready, and failed bootstrap commands are difficult to diagnose. Which improvement is most appropriate for a production fleet?
A. Replace the script with a larger user-data payload.
B. Bake stable application components into an AMI and use Systems Manager or deployment automation for remaining configuration.
C. Disable security groups during startup.
D. Hard-code the private IP address into the AMI.
Correct answer: B
Explanation: A baked AMI reduces startup work and improves consistency. Systems Manager or a deployment workflow can handle remaining configuration and operational tasks with better visibility than an increasingly complex bootstrap script.