Press enter or click to view image in full size

A hands-on setup of a production-ready EC2 web server using User Data to automate Nginx installation and startup at launch.

3 min read18 hours ago

–

Introduction

Day 26 of the KodeKloud AWS Challenge focused on bootstrapping infrastructure correctly from day one by using EC2 User Data to deploy a web server automatically.

This is not just about launching an EC2 instance and SSH-ing in to install software. That approach doesn’t scale, doesn’t repeat, and doesn’t survive automation.

Get Kishor Bhairat’s stories in your inbox

Join Medium for free to get updates from this writer.

The goal was clear:

• Launch an EC2 instance named nautilus-ec2
• Use an Ubuntu AMI
• Automatically install and start Nginx at launch
• Make the web server accessible over the internet on port 80

Concept Explanation: EC2 User Data (Why It Matters)

EC2 User Data allows you to run scripts once at instance launch. It’s the foundation of:

• Immutable infrastructure
• Auto Scaling Groups
• Repeatable environments
• Zero-touch provisioning

In Amazon Web Services, User Data is commonly used to:

• Install packages
• Configure services
• Pull application code
• Register instances with load balancers

If you’re manually configuring servers after launch, you’re already behind.

Why This Matters in Real Environments

Using User Data ensures:

• Every instance is configured consistently
• No manual intervention is required
• Servers can be destroyed and recreated safely
• Infrastructure is automation-ready

This is how real teams prepare for scaling — even when starting with a single instance.

Prerequisites / Gotchas

Things engineers often get wrong with User Data:

• Forgetting #!/bin/bash at the top of the script
• Assuming User Data runs on every reboot (it doesn’t)
• Not opening required ports in the security group
• Forgetting to enable or start services
• Debugging User Data too late (check /var/log/cloud-init.log)

User Data failures are silent unless you know where to look.

Hands-On Task: What I Did

1️⃣ Launched the EC2 Instance

• Created an EC2 instance named nautilus-ec2
• Selected an Ubuntu AMI
• Used default instance sizing suitable for a basic web server

Press enter or click to view image in full size

2️⃣ Configured User Data Script

During launch, I added a User Data script that:

• Updated the package index
• Installed Nginx
• Started the Nginx service

#!/bin/bash## Update the packagessudo apt update -y## install the nginx packagessudo apt install nginx -y## Enable and start the servicesudo systemctl enable --now nginx

This ensured the web server was ready immediately after boot.

3️⃣ Configured Security Group

• Allowed inbound HTTP traffic (port 80) from the internet
• Ensured the instance was reachable via browser

Press enter or click to view image in full size

Security groups are part of application availability — not an afterthought.

4️⃣ Verified Web Server Access

• Retrieved the public IP of the EC2 instance
• Accessed it via browser
• Confirmed the default Nginx page was being served

Press enter or click to view image in full size

Result: a fully functional web server with zero manual configuration.

What I Learned / Key Takeaways

• User Data is essential for automation
• Manual server setup doesn’t scale
• Web servers should be ready at launch
• Security groups define availability
• Infrastructure should be disposable, not precious

This is how infrastructure becomes reliable.

Conclusion

Launching an EC2 instance with User Data to install and start Nginx is a baseline DevOps skill.

This challenge reinforced a critical mindset shift: Servers should configure themselves. Humans shouldn’t babysit them.

With this setup, the Nautilus project now has a reproducible web server foundation ready for further deployment stages.

On to the next challenge.

Call to Action

If you’re learning AWS or DevOps through hands-on tasks that reflect real infrastructure practices, follow the journey. Each day builds skills that scale beyond tutorials.