AWS for Beginners (Part 3): Deep Dive into EC2 — Launch an Amazon Linux Server the Cloud Developer Way

Amazon Linux, SSH, key pairs, User Data — and watching your own server serve a live webpage the moment it boots, without a single manual step.

In Part 2 of this series, we launched a Windows cloud machine via Remote Desktop and saw a real desktop appear on screen. That was a great first confidence builder — now it’s time to go deeper. Check out Part 2 blog if you haven’t read it yet.

[embed]AWS for Beginners (Part 2): Launching Your First Amazon EC2 Virtual Server ☁️ Rent a real computer in the cloud, control it from your laptop, and actually run things on it — no hardware required.medium.com

In the real world, most cloud servers don’t run Windows. They run Linux — it’s faster, lighter, free to run, and nearly every tutorial, framework, and DevOps tool in existence is built with Linux in mind. So in this post, we’re switching gears.

We’ll launch an Amazon Linux instance, understand what makes it special, connect to it via SSH, and use a powerful EC2 feature called User Data to automatically set up and serve a live webpage — all without logging in and running a single command manually. Let’s go. 🐧

Table of Contents

· What is Amazon Linux — and Why Does It Exist? · Which OS Should You Choose? · Key Pairs — The Lock & Key of AWS · Launching Your Amazon Linux Instance · User Data — Let the Server Set Itself Up · Open Your Browser — Your Server is Already Live! · Connecting via SSH · Verify nginx from Inside the Server (Optional) · What’s Next? · Conclusion · Bonus Resources

What is Amazon Linux — and Why Does It Exist?

If you’ve heard of Linux before, you’ve probably heard of Ubuntu, Debian, or Fedora. These are popular Linux “distributions” (distros) — essentially different versions of Linux, each with its own flavor, tools, and package manager.

Amazon Linux is AWS’s own Linux distribution — built from scratch specifically to run on EC2. AWS created it, maintains it, and optimizes it for its cloud environment. It comes pre-installed with AWS-specific tools, runs extremely efficiently on EC2 hardware, and receives security patches directly from Amazon.

💡 Amazon Linux Is Not a General-Purpose OS: You won’t find Amazon Linux on your home PC or laptop — it’s designed purely for cloud servers. Most AWS tutorials and official documentation default to Amazon Linux, which means when you learn on it, you’re learning the “AWS native” way. That’s a real advantage when following along with AWS docs or courses.

Amazon Linux 2023 (AL2023) is a major update over the older Amazon Linux 2, with a modern package manager, better security defaults, and long-term support from AWS. This version is scheduled to reach its End of Life (EOL) on June 30, 2028.

In short, End of Life means the date when AWS will stop providing security patches, bug fixes, and technical assistance for this specific version. It is also important to note that AWS is likely to launch a newer major version (such as AL2025) in the near future to stay current with the latest software ecosystems.

Which OS Should You Choose?

When launching an EC2 instance, you’ll see a long list of AMI options. It can feel overwhelming. Here’s a simple breakdown of the most common ones and when each makes sense:

Choosing a right OS for EC2

For this tutorial and for most of your AWS learning journey, Amazon Linux 2023 is your best friend. It’s free, fast, and AWS assumes you’re using it in most of their documentation.

💡 Amazon Linux 2023 Uses dnf, Not apt: If you’ve ever used Ubuntu, you’re used to apt install. Amazon Linux 2023 uses dnf as its package manager (older AL2 used yum). They do the same job — just a different name. Don't let it trip you up when following other tutorials. sudo dnf install nginx -y is the AL2023 equivalent of sudo apt install nginx -y.

Key Pairs — The Lock & Key of AWS

When you SSH into a Linux server, you don’t use a username and password like you do on a website. Instead, AWS uses a cryptographic key pair — two mathematically linked files that work together like a lock and key.

Key Visuals

💡 Analogy: Think of it like a padlock. The public key is the open padlock mounted on your server’s door. The private key is the only key in the world that opens it — and only you have it. When you try to SSH in, your computer presents the private key, it matches the padlock, and the door opens. Someone with the wrong key (or no key at all) simply cannot get in.

When creating a key pair in AWS, you’ll see two format options:

• .pem — Works natively on Mac and Linux. Also works on Windows 10 and 11 with the built-in SSH client in PowerShell.
• .ppk — Used by PuTTY, an older SSH client for Windows. You can convert a .pem to .ppk using PuTTYgen if needed — but most modern setups don’t require this.

💡 Just Use .pem for Everything: If you’re on Windows 10 or 11, use.pem. Modern Windows ships with a built-in SSH client in PowerShell — no extra software needed. The only reason to use .ppk is if you’re on a very old Windows machine or specifically want PuTTY.

⚠️ You Can Only Download the Key Once: AWS shows you the private key file exactly once — at the moment of creation. If you close the window without downloading, or lose the file later, you cannot retrieve it. Treat it like a physical house key. Store it somewhere safe: a dedicated ~/.ssh/ folder is a good habit.

Launching Your Amazon Linux Instance

The process is very similar to the Windows launch in Part 2. The key differences are the AMI choice, the security group rules, and one extra step at the end — User Data — which is where the magic happens.

1. Go to EC2 → Launch Instance

• Log in to the AWS Console. Search for EC2 in the top bar. Click it. Then click the big orange “Launch Instance” button.

2. Name Your Instance

• Something like my-first-linux-server. Just a label — it helps you find it in the console later.

3. Choose Amazon Linux 2023 AMI

• It’s the very first option on the Quick Start list — “Amazon Linux 2023 AMI”. It should show a Free tier eligible badge. Click Select.
• ✅ If you see “Amazon Linux 2” as well, ignore it. AL2 is older and being phased out. Always go with AL2023.

EC2 -> Launch Instance -> Give Name & Select AMI

4. Instance Type: t2.micro or t3.micro

• 1 vCPU, 1 GB RAM — free, and more than enough for what we’re doing. This is the default.

Choose instance type t2 or t3 micro (Free Tier Eligible)

5. Create a Key Pair

• Click “Create new key pair”. Name it something like linux-key. Choose the RSA type and .pem format. Click Create. A file will download automatically — save it somewhere you'll remember, like your Downloads folder or a dedicated ~/.ssh/ directory.
• 🔑 You’ll need this file to SSH in later. Don’t lose it — it can’t be recovered.

Creating a Key Pair for SSH

6. Security Group — Allow SSH + HTTP

• Under “Network settings”, check the SSH and HTTP rules. AWS automatically adds an SSH rule. Set its source to My IP or Anywhere (It's easier). Both the SSH and HTTP rules will be added.

Security Group Rules

• 💡 SSH (port 22) is your back door — only your IP needs it. HTTP (port 80) is the web door — we’re opening it to everyone, so anyone can visit your webpage via your public IP.

Check the checkbox for SSH and HTTP

7. Storage — Keep Default (8 GB)

• For a Linux instance, 8 GB is fine for learning. Well within your free credit allowance.

Keep Default Settings

8. User Data — The Magic Script ✨

• Scroll all the way down and expand “Advanced details”. At the very bottom, find the “User data” text box. Paste the script from the **next section below** into this field. This script will run automatically the moment your instance boots — installing a web server, fetching your instance metadata, and writing a live HTML page, all before you even connect.
• ⚠️ Don’t click Launch yet — read **Next Section **below first to understand what you’re pasting and why.

Paste User Data Code from Section Below

9. Launch Instance!

• Click the big orange “Launch Instance” button. Head to View Instances and wait for the status to show Running with a ✅ status check. Usually takes 60–90 seconds.

User Data — Let the Server Set Itself Up

Before we look at the script, let’s understand what User Data actually is — because it’s one of the most useful and powerful EC2 features you’ll keep coming back to throughout your cloud career.

💡 Analogy: Imagine you hired someone to set up a new office computer. Instead of sitting next to them and telling them what to do step by step, you leave a printed instruction sheet on the desk: “When you first switch this on — install Chrome, connect to the Wi-Fi, and set the wallpaper.” User Data is exactly that note. Your server reads it the moment it wakes up for the first time and follows every instruction automatically.

User Data is a shell script you attach to an EC2 instance before launch. AWS runs it automatically at first boot, as the root user. You can use it to:

• Install software — nginx, Node.js, Python, Docker, anything
• Write configuration files or custom HTML pages
• Start services so they’re ready before anyone connects
• Pull your app’s latest code from GitHub automatically
• Register the server with a monitoring tool or load balancer
• Configure services to auto-restart every time the instance reboots

💡User Data Runs Once — At First Boot Only: By default, User Data runs exactly once — when the instance first launches. If you stop and restart the instance later, it does not run again. However, because our script uses systemctl enable nginx, nginx will automatically restart on every future reboot — so your webpage stays live even if the server is restarted.

The User Data Script — Paste This

Go back to the launch wizard, scroll to Advanced details → User data, and paste the entire script below:

#!/bin/bash

# This script runs automatically at first boot — no SSH needed

# Step 1: Update all system packages
dnf update -y

# Step 2: Install nginx (a lightweight, fast web server)
dnf install -y nginx

# Step 3: Enable nginx — auto-starts on every future reboot
systemctl enable nginx

# Step 4: Start nginx right now
systemctl start nginx

# Step 5: Fetch this instance's live details from the EC2 Metadata Service
# 169.254.169.254 is a special AWS-internal IP — only reachable from inside EC2
# The TOKEN step is required by IMDSv2 (AWS's secure metadata API)

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

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

AZ=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/availability-zone)

REGION=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/placement/region)

PUBLIC_IP=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/public-ipv4)

# Step 6: Write a custom HTML page using the live instance details

cat > /usr/share/nginx/html/index.html << HTMLEOF
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Hello from EC2!</title>
  <link href="https://fonts.googleapis.com/css2?family=Sora:wght@400;700;800&display=swap" rel="stylesheet" />
  <style>
    * {
      box-sizing: border-box;
      margin: 0;
      padding: 0;
    }

    body {
      background: #0b0f1a;
      color: #e2e8f0;
      font-family: 'Sora', sans-serif;
      min-height: 100vh;
      display: flex;
      align-items: center;
      justify-content: center;
    }

    .card {
      background: #111827;
      border: 1px solid #1f2f4a;
      border-top: 4px solid #34d399;
      border-radius: 16px;
      padding: 48px 40px;
      max-width: 560px;
      width: 90%;
      text-align: center;
    }

    .emoji {
      font-size: 3rem;
      margin-bottom: 16px;
    }

    h1 {
      font-size: 2rem;
      font-weight: 800;
      color: #34d399;
      margin-bottom: 8px;
    }

    .sub {
      color: #7c8fa6;
      font-size: 15px;
      margin-bottom: 32px;
    }

    .info-grid {
      display: grid;
      grid-template-columns: 1fr 1fr;
      gap: 12px;
      margin-bottom: 28px;
    }

    .info-box {
      background: #1a2235;
      border: 1px solid #1f2f4a;
      border-radius: 10px;
      padding: 14px 10px;
    }

    .info-box .lbl {
      font-size: 11px;
      color: #7c8fa6;
      text-transform: uppercase;
      letter-spacing: 0.1em;
      margin-bottom: 4px;
    }

    .info-box .val {
      font-size: 14px;
      font-weight: 700;
      color: #38bdf8;
      word-break: break-all;
    }

    .footer-msg {
      font-size: 13px;
      color: #34d399;
      border-top: 1px solid #1f2f4a;
      padding-top: 20px;
    }
  </style>
</head>
<body>
  <div class="card">
    <div class="emoji">🎉</div>
    <h1>Hello from EC2!</h1>
    <p class="sub">You just served a real webpage from a cloud server you own.</p>

    <div class="info-grid">
      <div class="info-box">
        <div class="lbl">Instance ID</div>
        <div class="val">${INSTANCE_ID}</div>
      </div>
      <div class="info-box">
        <div class="lbl">Region</div>
        <div class="val">${REGION}</div>
      </div>
      <div class="info-box">
        <div class="lbl">Availability Zone</div>
        <div class="val">${AZ}</div>
      </div>
      <div class="info-box">
        <div class="lbl">Public IP</div>
        <div class="val">${PUBLIC_IP}</div>
      </div>
    </div>

    <p class="footer-msg">✅ Served by nginx · Auto-configured via EC2 User Data</p>
  </div>
</body>
</html>
HTMLEOF

💡What is 169.254.169.254?: That’s theEC2 Instance Metadata Service (IMDS) — a special internal IP address that exists only inside AWS. It’s not on the internet and nobody outside your instance can ever reach it. When your server calls this address, AWS responds with that instance’s own details: its ID, region, IP address, and more. The TOKEN step (called IMDSv2) is a security measure AWS introduced to prevent other software on your server from reading your metadata without explicit permission.

Open Your Browser — Your Server is Already Live!

Here’s the satisfying part. While you were reading this post and SSH-ing around, your User Data script was already running in the background at first boot — installing nginx, calling the metadata service, and writing your custom HTML page. You don’t need to do a single thing manually. The server is already serving.

1. Copy Your Public IPv4 Address

• Go to EC2 → Instances → click your instance. In the details panel, find “Public IPv4 address” and copy it. It’ll look something like [http://35.154.103.211](http://35.154.103.211/)

2. Open It in Your Browser

• Open a new browser tab and navigate to http://<YOUR-PUBLIC-IP>. Make sure it's http:// and not https://.

• ⚠️ Your browser may try to redirect to https:// automatically — if that happens, manually type the full http:// address in the address bar and press Enter. We haven't set up SSL yet, so https won't work.

3. 🎉 See Your Page!

• You’ll see the custom dark-themed page — showing your real Instance ID, Region, Availability Zone, and Public IP — all fetched live from the EC2 metadata service at boot time. That data is unique to your instance. Nobody else in the world has that exact page.

🤔 Page Not Loading? Don’t Panic!: If you open the browser immediately after the instance shows “Running”, the User Data script might still be finishing up — it can take60–90 secondsafter the instance is marked running. Wait a moment and refresh. If it still doesn’t load after 2–3 minutes, double-check that your security group has port 80 open with source set to Anywhere (0.0.0.0/0).

💡 Why Does the Page Survive a Restart? Because the User Data script included *systemctl enable nginx. The `enable`* command registers nginx as a system service that starts automatically on every boot — not just the first time. So even if you stop and restart your instance, open the browser with the new public IP and the page will be right there, served immediately. This is exactly how real production servers are configured to auto-recover.

Connecting via SSH

Now, since our website on EC2 is running, let's get inside the EC2 machine via SSH. SSH stands for Secure Shell. It opens a secure, encrypted terminal session into your Linux server — like plugging a keyboard directly into the machine, except you’re doing it over the internet from your laptop.

Before connecting, we need to fix the permissions on your .pem key file. SSH requires that the private key file is readable only by you — it refuses to use it if anyone else could theoretically read it. This is a security measure, not a bug.

On Mac or Linux (Terminal):

# Step 1: Fix the key file permissions (only need to do this once)
chmod 400 ~/Downloads/linux-key.pem

# Step 2: SSH into your instance
# Replace <YOUR-PUBLIC-IP> with the Public IPv4 from your EC2 console
ssh -i ~/Downloads/linux-key.pem ec2-user@<YOUR-PUBLIC-IP>

# Example:
ssh -i ~/Downloads/linux-key.pem ec2-user@54.123.45.67

On Windows (PowerShell):

# No extra software needed — Windows 10/11 ships with a built-in SSH client

ssh -i "C:\Users\YourName\Downloads\Linux Key Pair.pem" ec2-user@<YOUR-PUBLIC-IP>

# Example:
ssh -i "C:\Users\Deepak\Downloads\Linux Key Pair.pem" ec2-user@54.123.45.67

💡 Where to Find Your Public IP: Go to EC2 → Instances → click your instance. In the details panel at the bottom, look for “Public IPv4 address”. Copy that value. Note: if you stop and restart an instance, the public IP changes (Because we did not assign an Elastic IP) — you’ll need to copy the new one each time.

🤔 “Are you sure you want to continue connecting?” — Don’t Panic! The first time you SSH into any new server, you’ll see a fingerprint warning. This is completely normal. Typeyesand press Enter. SSH stores the server’s fingerprint locally so it won’t ask again for the same server.

If everything works, you’ll see the Amazon Linux welcome banner:

Connecting to EC2 via SSH in Windows Powershell

⚠️Important Note: SSH Connection Timeout?

If you’re getting a connection timeout error while using SSH, even after setting everything correctly in AWS (security group, key pair, public IP), the issue might not be AWS at all.

When I tried connecting using my Wi-Fi provider (Deenet), I faced this exact issue (as you can see in the screenshot above) — the connection kept timing out.

Some network providers block port 22 (SSH) for security reasons.

💡 Quick Fix:

• Try switching to a mobile hotspot or a different network

If it works on another network, your setup is correct — it’s just a network restriction.

That prompt — [ec2-user@ip-172-31-45-12 ~]$ — means you are now inside your cloud server. You're controlling a real computer running in an AWS data centre, from your terminal. That feeling never gets old. Now you can run any Linux commands (ls, pwd, mkdir, etc.) on your local Amazon Linux Computer (EC2).

Verify nginx from Inside the Server (Optional)

Since you’re already in, here are a few commands to verify your User Data script ran correctly:

# Check if nginx is running
sudo systemctl status nginx
# Look for: Active: active (running) ✅ = If you're able to see Website on browser, It's running

# Check the HTML file that User Data wrote
cat /usr/share/nginx/html/index.html
# You'll see your custom HTML with the real instance values baked in

# Check the User Data script execution log
sudo cat /var/log/cloud-init-output.log
# This shows everything that ran at boot — great for debugging if something went wrong

# Done? Exit the SSH session
exit

Running Status Check Commands on EC2

⚠️ Don’t Forget to Terminate! Once you’re done, go back to the EC2 dashboard and terminate your instance to avoid any charges. EC2 → Instances → Select → Instance State →Terminate

What’s Next?

You’ve now gone deep into EC2 — you understand Amazon Linux, key pairs, SSH, and User Data. Here’s where you stand in the series:

In Part 4, we go deep on VPC (Virtual Private Cloud) — the networking backbone that everything in AWS sits inside. You’ll learn how to build your own private network from scratch: public and private subnets, internet gateways, route tables, and NAT gateways. It’s where EC2 and AWS networking finally click together.

Conclusion

You just did something most people take weeks to get to. You launched a Linux server in the cloud, connected to it over SSH, and watched your own webpage load in a browser — served by a machine you configured with a script, without a single manual step after clicking Launch.

That’s not just a tutorial exercise. That’s exactly how real servers get deployed in production. User Data, nginx, systemctl enable — these are the building blocks of every cloud-deployed application you’ve ever visited. Now you understand how they work from the inside.

See you in Part 4, where we build the network that makes all of this work properly.

“A server in the cloud is just a computer waiting for you to tell it what to do. The terminal doesn’t care who you are — only that you showed up and typed the right thing”

Bonus Resources

Want to go further? Here are some official resources to bookmark:

Amazon Linux 2023 — Official page for AL2023 — features, support timeline, and migration from AL2.

EC2 User Data Docs — AWS’s official guide to User Data — scripts, cloud-init, and advanced usage.

Instance Metadata Service — Full reference for the EC2 metadata endpoint — everything your instance can learn about itself.

EC2 Key Pairs — Creating, managing, and recovering key pairs in AWS — the complete reference.

SSH Explained — A gentle deep-dive into how SSH works, public/private keys, and secure connections.

nginx Beginner’s Guide — The official nginx intro — configuration, serving files, and basic setup.

[embed]AWS for Beginners: From Zero to Your First Cloud Website 🚀 No jargon. No overwhelm. Just clear explanations, real examples, and a hands-on project to get you started today.medium.com

[embed]AWS for Beginners (Part 2): Launching Your First Amazon EC2 Virtual Server ☁️ Rent a real computer in the cloud, control it from your laptop, and actually run things on it — no hardware required.medium.com