Chapter 40: Terraform Real AWS Labs VPC EC2 nginx S3 and IAM Role

40.3 Lab part 3 — EC2 with nginx from user_data

By Ravindra Bagale · Last updated: 25 October 2026

Story. A Netflix-style team never logs in to configure a server by hand; the server configures itself at first boot. user_data passes a script to cloud-init, which runs it as root once. Here it installs nginx and writes a page that shows the instance id. IMDSv2 is required so the metadata service cannot be read with a simple forged request.

resource "aws_instance" "web" {
  ami                    = data.aws_ami.al2023.id
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public["a"].id
  vpc_security_group_ids = [aws_security_group.web.id]
  iam_instance_profile   = aws_iam_instance_profile.web.name

  metadata_options {
    http_tokens = "required"
  }

  # user_data.sh sits next to this file:
  #   #!/bin/bash
  #   dnf install -y nginx
  #   TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
  #   ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
  #   echo "<h1>Badge lab - $ID</h1>" > /usr/share/nginx/html/index.html
  #   systemctl enable --now nginx
  user_data = file("${path.module}/user_data.sh")

  user_data_replace_on_change = true
  tags = { Name = "badge-lab-web" }
}

output "web_url" {
  value = "http://${aws_instance.web.public_dns}"
}

What each line does

• ami = data.aws_ami.al2023.id — The latest Amazon Linux 2023 image from the data source in Chapter 33.
• subnet_id = aws_subnet.public["a"].id — Places the server in public subnet a.
• vpc_security_group_ids = [aws_security_group.web.id] — Applies the HTTP-only group.
• iam_instance_profile = aws_iam_instance_profile.web.name — Gives the server the role from part 4.
• http_tokens = "required" — Forces IMDSv2 for the metadata service.
• user_data = file("${path.module}/user_data.sh") — Reads the boot script from user_data.sh and passes it to cloud-init.
• dnf install -y nginx — Installs nginx.
• TOKEN=$(curl -s -X PUT .../api/token ...) — Gets a short-lived IMDSv2 token.
• ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" .../instance-id) — Reads this instance id with the token.
• echo "h1 Badge lab - $ID" > .../index.html — Writes the home page with an h1 heading.
• systemctl enable --now nginx — Starts nginx now and on every boot.
• user_data_replace_on_change = true — Changing the script replaces the instance so the new script really runs.
• value = "http://${aws_instance.web.public_dns}" — Prints the URL to open.

When it is green.

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Outputs:
web_url = "http://ec2-203-0-113-25.ap-south-1.compute.amazonaws.com"

$ curl -s $(terraform output -raw web_url)
<h1>Badge lab - i-0abc123...</h1>

When it is red.

$ curl -I $(terraform output -raw web_url)
curl: (7) Failed to connect to ec2-203-0-113-25... port 80: Connection refused

Fix. Wait a minute for cloud-init, then check sudo cat /var/log/cloud-init-output.log through Session Manager. If the connection times out instead, the route table or security group is wrong.

What: every term in plain English

• AMI — Amazon Machine Image. The disk template a server boots from, such as Amazon Linux 2023.
• data source — A read-only lookup. data.aws_ami finds the newest AMI id so you never paste one.
• user_data — A script given to the instance at launch. cloud-init runs it once, as root, on first boot.
• cloud-init — The agent inside the image that reads user_data and runs it.
• IMDSv2 — Version 2 of the instance metadata service. Every read needs a short-lived token first.
• user_data_replace_on_change — When true, changing the script replaces the instance, so the new script really runs.
• file() — A Terraform function that reads a file next to your code and returns its text.

Example 1: Write user_data.sh and the AMI lookup

Keeping the boot script in its own file means shellcheck and code review work on it like any other script. That is how a Razorpay platform team keeps boot scripts clean.

1. Create user_data.sh with the lines shown in the lesson comment.
2. Add the AMI data source.
3. Run validate.

# ami.tf
data "aws_ami" "al2023" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["al2023-ami-2023.*-x86_64"]
  }
}

printf '%s\n' '#!/bin/bash' 'dnf install -y nginx' 'systemctl enable --now nginx' > user_data.sh
shellcheck user_data.sh && echo script-ok
terraform validate

Output

script-ok
Success! The configuration is valid.

What it shows: printf writes the file line by line. The full script from the lesson also writes the page with the instance id.

Example 2: Apply and open the page

The proof of a lab is a page in the browser, not a green apply. Always finish with curl.

1. Plan and check 1 to add.
2. Apply.
3. Wait about a minute.
4. Curl the output URL.

terraform apply -auto-approve
sleep 60
curl -s -o /dev/null -w "%{http_code}\n" $(terraform output -raw web_url)
curl -s $(terraform output -raw web_url)

Output

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
200
Badge lab - i-0a1b2c3d4e5f60718

What it shows: HTTP 200 and the instance id prove that cloud-init ran, nginx started and the network path is open.

Example 3: Read the cloud-init log without SSH

When the page does not load, the answer is in the cloud-init log. At HCL support desks, Session Manager is the only way in.

1. Start a Session Manager shell.
2. Read the last lines of the log.
3. Check nginx status.

ID=$(terraform state show aws_instance.web | awk '/^ *id /{print $3; exit}' | tr -d '"')
aws ssm start-session --target $ID
sudo tail -5 /var/log/cloud-init-output.log
systemctl is-active nginx

Output

Complete!
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service
Cloud-init v. 22.2.2 finished at Sun, 25 Oct 2026 07:12:41 +0000. Up 38.20 seconds
active

What it shows: Cloud-init prints the finish time in UTC; that is 12:42 PM IST. If you see an error above that line, the script failed there.

Example 4: Prove IMDSv2 is required

A leaked metadata read was part of a famous bank breach. With http_tokens required, a plain request gets 401.

1. From the Session Manager shell, call metadata without a token.
2. Call it again with a token.

curl -s -o /dev/null -w "%{http_code}\n" http://169.254.169.254/latest/meta-data/instance-id
TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

Output

401
i-0a1b2c3d4e5f60718

What it shows: No token, no data. That one setting closes a whole class of attacks.

Command cheat sheet

Verify: did it work?

1. Page returns 200

   curl -s -o /dev/null -w "%{http_code}" $(terraform output -raw web_url)
   

   Output

   200
   

2. IMDSv2 required

   aws ec2 describe-instances --instance-ids $ID --query "Reservations[0].Instances[0].MetadataOptions.HttpTokens" --output text
   

   Output

   required
   

When it is red 1

Error: creating EC2 Instance: InvalidAMIID.NotFound

Cause. A pasted AMI id from another region.

Fix, step by step

1. Use the data.aws_ami lookup.
2. Plan again.

When it is red 2

curl: (7) Failed to connect ... Connection refused

Cause. The server is up but nginx is not running yet or failed to install.

Fix, step by step

1. Wait one minute.
2. Read cloud-init-output.log.
3. Fix user_data.sh and apply; replace_on_change rebuilds the server.

When it is red 3

TargetNotConnected: i-0a1b... is not connected

Cause. Session Manager cannot reach the instance; the role or the SSM policy is missing.

Fix, step by step

1. Finish part 4 first.
2. Check the instance profile is attached.
3. Wait two minutes for the agent to register.

Cleanup

terraform destroy -auto-approve

Practice tasks

Homework: try at home

Recap

• data.aws_ami finds the latest image.
• user_data runs once at first boot through cloud-init.
• Keep the script in its own file and read it with file().
• IMDSv2 required blocks token-less metadata reads.
• Debug with Session Manager and the cloud-init log.

FAQ

Does user_data run on every reboot?

No, only on first boot by default.

Why replace on change?

Otherwise the script changes in AWS but never runs on the existing server.

Is t3.micro free?

It is in the free tier for new accounts for limited hours. Destroy after the lab.

Can I see user_data later?

Yes in the console or with describe-instance-attribute, so never put secrets in it.

Why not SSH?

No open port and no key file to leak. Session Manager logs every session.

Interview questions

1. How do you configure an EC2 at boot with Terraform?

   Pass a script in user_data; cloud-init runs it on first boot.

2. Why use a data source for the AMI?

   It finds the right current image per region without hard-coding ids.

3. What is IMDSv2 and why require it?

   Token-based metadata access that blocks simple forged requests.

4. How do you rerun user_data?

   Replace the instance, with replace_on_change or apply -replace.

5. Where do you look when user_data fails?

   /var/log/cloud-init-output.log.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards