Deploy a Linux Web Server on EC2

Launch an EC2 instance, install Nginx, and serve a custom webpage on AWS.

Introduction

30 Second Summary

Every website you visit lives on a server somewhere. When you type a URL into your browser, a computer in a data center receives your request and sends back the page. Cloud Engineers are the people who set up, secure, and maintain those servers.

In this project, you will launch your own Linux server on AWS, connect to it remotely, and deploy a custom web page that anyone in the world can visit by typing your server's IP address into their browser.

What You'll Build

By the end of this project, you will have a live web server on the public internet that you built entirely from the command line. You will be able to give someone the IP address, they open it in their browser, and your custom page loads.

By the end of this project, you'll have:

A running EC2 instance you can SSH into any time from your Windows terminal, just like a Cloud Engineer remoting into a production server.
A fully configured Nginx web server responding to HTTP requests from anywhere in the world.
A custom HTML page you wrote and deployed, visible to anyone who has your server's public IP address.
Hands-on experience diagnosing and fixing a real AWS networking issue (security groups blocking traffic) the same way professionals do it in production.
Secret Mission: Set up a second virtual host on Nginx that serves a different page on a custom port, proving you can manage multi-service configurations.

Are there any prerequisites?

You need an AWS account and a Windows PC with PowerShell. No prior Linux experience is required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your Cloud Engineering path.

Set Up Your Local SSH Client and Launch an EC2 Instance

Everything you do as a Cloud Engineer on remote servers starts with one connection. You need a way to reach your cloud server from your Windows machine, and that means two things: an SSH client on your local PC, and a running server in the cloud to connect to.

Without a working SSH client and a properly configured EC2 instance, you cannot practice any Linux skills remotely. In this step, you will verify your SSH tool, create a secure key pair, launch your first Amazon Linux server, and connect to it.

In this step, get ready to:

Verify that OpenSSH is installed on your Windows machine.
Create a key pair and launch an Amazon Linux 2023 EC2 instance.
Connect to the instance via SSH from PowerShell.

Verify OpenSSH on your Windows machine

SSH is the tool Cloud Engineers use to securely connect to remote Linux servers. Windows 10 and 11 include an OpenSSH client as an optional feature. Let's confirm it is ready.

Press the Windows key to open your search bar.
Type PowerShell and press Enter to open it.
Check if OpenSSH is installed by running this command:

ssh

Look at the output in your terminal.

✔️ I see usage information

You should see a block of text starting with usage: ssh followed by a list of options. This means OpenSSH is already installed and ready to use.

Skip ahead to the next substep.

ⓧ Command not recognized

If PowerShell says the command is not recognized, you need to install the OpenSSH Client feature. Follow these steps:

Open Settings on your Windows machine.
Select Apps, then Optional Features.
Click Add a feature (or View features on newer Windows versions).
Search for OpenSSH Client and select Install.
Wait for the installation to complete.

Alternatively, install it from PowerShell (run as Administrator) with this command:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Close and reopen PowerShell after installation.
Run ssh again to confirm you now see the usage information.

Still not seeing usage information?

Make sure you closed and reopened PowerShell after installation. If the issue persists, restart your PC and try again.

help me troubleshoot why OpenSSH is not working on my Windows machine

Create a key pair and launch an EC2 instance

A key pair is how AWS verifies your identity when you SSH into a server. You create the pair in AWS, download the private key file to your PC, and AWS places the public key on your instance.

Open your browser and go to the AWS Management Console at https://console.aws.amazon.com.
Sign in to your AWS account.
In the search bar at the top, type EC2 and select EC2 from the results.
In the left sidebar, under Network & Security, click Key Pairs.
Click Create key pair in the top right.

A dialog appears asking for key pair details.

For Name, enter a memorable name like my-ec2-key.
For Key pair type, keep the default (RSA).
For Private key file format, select .pem.
Click Create key pair.

Your browser automatically downloads a .pem file. This is your private key. Remember the download location (usually your Downloads folder).

What is a .pem file?

The .pem file is your private key. It proves your identity when you connect to the server. Anyone with this file can access your instance, so treat it like a password and never share it.

AWS only lets you download this file once. If you lose it, you will need to create a new key pair.

Now launch the instance. This is the actual cloud server you will connect to.

In the left sidebar, click Instances.
Click Launch instances at the top right.

The launch instance wizard opens. Configure it with these settings:

Under Name and tags, enter my-linux-server in the Name field.
Under Application and OS Images, click Quick Start and select Amazon Linux. The default AMI should be Amazon Linux 2023 and marked Free tier eligible.
Under Instance type, search for and select t4g.small. It is covered by the T4g free trial.
Under Key pair (login), select the key pair you just created (my-ec2-key or whatever name you chose).
Under Network settings, keep the defaults. The wizard creates a security group that allows SSH (port 22) from anywhere.
In the Summary panel on the right, click Launch instance.

A success banner confirms your instance is launching.

Click the instance ID link in the success banner to open the Instances page.
Wait for the Instance state column to show Running. This takes about 30 seconds.

Why t4g.small?

The T4g free trial gives all AWS customers 750 free hours per month of t4g.small until December 31, 2026. This means your instance costs nothing for this project.

The t4g instance type uses AWS Graviton processors (ARM architecture). Amazon Linux 2023 runs natively on ARM, so everything works seamlessly.

Connect to your instance via SSH

Your server is running in the cloud. Time to connect to it from your Windows machine using the private key you downloaded.

On the Instances page, select your instance by clicking its checkbox.
In the details panel below, find the Public IPv4 address field. Copy this IP address.

Switch back to your PowerShell window. Connect to your instance by running this command:

ssh -i [[PEMPATH="C:\Users\YourName\Downloads\my-ec2-key.pem"]] ec2-user@[[EC2_PUBLIC_IP="your instance's public IPv4 address"]]

What does this command do?

ssh is the command to open a secure remote connection.
-i tells SSH which private key file to use for authentication.
ec2-user is the default username on Amazon Linux instances.
The IP address is the public address of your cloud server.

SSH will ask you to verify the host fingerprint since this is your first connection.

When you see the prompt asking if you want to continue connecting, type yes and press Enter.

Before you look at the result, think about what you expect to see. Do you think the connection will succeed? What would a successful connection look like?

You should now see the Amazon Linux 2023 welcome banner and a prompt ending with [ec2-user ~]$. You are connected to your Linux server in the cloud.

Seeing a permissions error about your key file?

If you see a warning containing "UNPROTECTED PRIVATE KEY FILE" or "Permissions are too open", it means other users on your PC can read your key file. Fix this by running these commands in PowerShell (replace the path with your actual .pem file path):

icacls.exe C:\Users\YourName\Downloads\my-ec2-key.pem /reset
icacls.exe C:\Users\YourName\Downloads\my-ec2-key.pem /GRANT:R "$($env:USERNAME):(R)"
icacls.exe C:\Users\YourName\Downloads\my-ec2-key.pem /inheritance:r

These commands reset permissions, grant only your user read access, and remove inherited permissions. After running them, try your ssh command again.

help me fix file permission errors when connecting via SSH on Windows

Connection timed out?

Double-check that you copied the correct public IPv4 address from the EC2 console. Make sure your instance state shows Running and that its status checks have passed (2/2 checks).

help me troubleshoot my SSH connection to EC2

You now have a live Linux server in the cloud and a secure SSH connection from your Windows machine. Next up, you will explore the Linux file system and learn the navigation commands every Cloud Engineer uses daily.

Explore the Linux File System and Learn Navigation

You're connected to your EC2 instance and sitting at the command line. Now it's time to learn how to find your way around this Linux server.

Every task you do as a Cloud Engineer starts with knowing where you are and where things live. Configuration files, application logs, and web content all live in specific directories. Without navigation skills, you cannot find any of them.

In this step, get ready to:

Explore key directories on the server.
Create and move files from the command line.
Set file permissions with chmod.

Explore key directories on the server

A Linux server organizes everything into a tree of directories starting at / (the root). Knowing which directories hold what saves you time every day.

Confirm your current location by running this command:

pwd

You should see /home/ec2-user. This is your home directory on the server.

See all the top-level directories on the server by running:

ls /

You should see a list of directories including bin, etc, home, tmp, usr, and var.

What are these directories?

/etc holds system configuration files. When you install software and need to change its settings, this is where you look.

/var/log stores log files. When something breaks, you check here for error messages.

/tmp is for temporary files that get cleaned up automatically. Programs use it for scratch space.

Explore the configuration directory by running:

cd /etc
ls

You should see a long list of configuration files and folders. Later in this project, you will edit the nginx configuration file that lives here.

Check the logs directory by running:

cd /var/log
ls

You should see files like messages and cloud-init.log. These record what happened on the server since it booted.

Take a quick look at the temporary files directory, then return to your home directory by running:

cd /tmp
ls
cd ~

The /tmp directory may be empty or have a few system-generated files. Running cd ~ brings you back to your home directory.

Lost track of where you are?

Run pwd at any time to see your current location. Then use cd ~ to jump back home.

help me get back to my home directory on this EC2 instance

Create a directory and file

Cloud Engineers create directories and files from the command line constantly. Let's practice the basic workflow of creating, reading, and moving files.

Create a new project directory and a file inside it by running these commands:

mkdir ~/my-project
echo "Hello from $(hostname)" > ~/my-project/my-info.txt

What do these commands do?

mkdir ~/my-project creates a new directory called my-project inside your home folder. The ~ symbol is a shortcut that always means "my home directory".

echo "Hello from $(hostname)" prints a greeting that includes your server's name. The > symbol redirects that text into a new file instead of printing it on screen.

Read the file you just created using cat by running:

cat ~/my-project/my-info.txt

You should see something like Hello from ip-172-31-xx-xx.ec2.internal (your instance's hostname will be different).

Try reading the same file with head by running:

head ~/my-project/my-info.txt

The head command shows the first 10 lines of a file. For a one-line file like this, the output looks the same as cat. On larger log files, head helps you peek at just the beginning.

Try the interactive reader less by running:

less ~/my-project/my-info.txt

Exiting less

The less command takes over your terminal for scrolling through long files. Press q to exit and return to your normal prompt.

Move the file from my-project up to your home directory by running:

mv ~/my-project/my-info.txt ~/my-info.txt

Confirm the file moved successfully by running:

ls ~/my-info.txt

You should see /home/ec2-user/my-info.txt listed. The file now lives directly in your home directory.

Seeing "No such file or directory"?

Make sure you ran the mkdir and echo commands from the earlier step. If you skipped those, run them again now before trying the mv command.

help me figure out why my file is missing on this Linux server

Set file permissions with chmod

Linux controls who can read, write, or execute every file. This is how servers keep sensitive data safe. A misconfigured permission is one of the most common causes of "403 Forbidden" errors on web servers.

Check the current permissions on your file by running:

ls -la ~/my-info.txt

You should see a line starting with -rw-r--r--. This is the permission string.

How do I read the permission string?

The string -rw-r--r-- breaks into three groups after the first dash: rw- (owner can read and write), r-- (group can only read), r-- (everyone else can only read).

Right now, anyone on this server can read your file. That is fine for a greeting, but would be dangerous for a file containing passwords or API keys.

Lock the file down so only you (the owner) can read and write it by running:

chmod 600 ~/my-info.txt

What does 600 mean?

The number 600 means: 6 (read + write) for the owner, 0 (nothing) for the group, 0 (nothing) for everyone else. Only ec2-user can access this file now.

Verify the permissions changed by running:

ls -la ~/my-info.txt

The permission string should now show -rw-------. The r-- sections for group and others are gone, replaced by dashes.

Before you run the final check, what do you think cat /home/ec2-user/my-info.txt will show? Will it still work after changing permissions?

Confirm you can still read the file by running:

cat /home/ec2-user/my-info.txt

You should see your greeting text (Hello from ...). The file is still readable because you are the owner, and 600 gives the owner read permission.

Seeing "Permission denied"?

If you accidentally set permissions to 000 instead of 600, even the owner loses access. Fix it by running chmod 600 ~/my-info.txt again.

help me fix file permissions on my EC2 instance

You can navigate the file system, create files, and control who can access them. Next up, you'll install your first piece of software on this server using Linux's package manager.

Install and Start Nginx Using dnf and systemctl

You can navigate the Linux file system, create files, and control permissions. Now it is time to put this server to work by installing software on it.

Package management and service control are the two most common tasks in Linux administration. In this step, you will install Nginx (a web server) using the dnf package manager and control it with systemctl. This is the exact workflow you will repeat hundreds of times as a Cloud Engineer for any piece of software.

In this step, get ready to:

Update all system packages to their latest versions.
Install Nginx from the Amazon Linux 2023 repository.
Start and enable the Nginx service so it runs now and on every reboot.

Update system packages

Before installing new software, it is good practice to update existing packages. This ensures you get the latest security patches and that dependency versions are current.

Update all installed packages by running this command:

sudo dnf upgrade -y

What does this command do?

sudo runs the command with administrator (root) privileges. Package management requires elevated access.
dnf upgrade tells the DNF package manager to check every installed package for a newer version and install it.
-y automatically answers "yes" to all prompts so you do not have to confirm each update manually.

You will see a list of packages scroll by as they are downloaded and installed. This may take a minute or two depending on how many updates are available.

Seeing a network error?

If dnf cannot reach the package repositories, check that your EC2 instance has internet access. The default VPC setup provides this automatically, but if your instance is in a private subnet you will need a NAT gateway.

help me troubleshoot dnf network errors on my EC2 instance

Install Nginx

Amazon Linux 2023 provides Nginx in its default repositories. You do not need to add any extra sources.

Install Nginx by running this command:

sudo dnf install -y nginx

What does this command do?

dnf install downloads and installs a package from the repository. Watch the output closely. You will see dnf resolve dependencies automatically. It figures out which other packages Nginx needs and installs them too.

This automatic dependency resolution is one of the main reasons package managers exist. Without it, you would have to track down and install each dependency by hand.

Confirm the installation succeeded. Look for Complete! at the end of the terminal output.

Seeing "No match for argument: nginx"?

This means the package name was not found. Double check you typed nginx in all lowercase with no typos. Amazon Linux 2023 includes Nginx in its default repositories, so no extra configuration is needed.

help me fix a dnf package not found error

Start and enable the Nginx service

Installing Nginx puts the files on disk, but it does not start the web server. Linux uses systemd to manage services. You interact with systemd through the systemctl command.

Start the Nginx service by running:

sudo systemctl start nginx

Enable Nginx to start automatically on every reboot by running:

sudo systemctl enable nginx

What is the difference between start and enable?

start launches the service right now. If you reboot the server without enabling the service, it will not come back up on its own.

enable tells systemd to launch the service automatically every time the server boots. You almost always want both.

Before you check the status, what do you think systemctl status will show you? Think about what a running service looks like versus a stopped one.

Check that Nginx is running by running:

sudo systemctl status nginx

You should see active (running) in green text near the top of the output. This confirms the Nginx process is alive and listening for connections.

Status shows "inactive" or "failed"?

If the status is not active (running), try running sudo systemctl start nginx again and check for error messages. A common cause is a syntax error in the Nginx config. Run sudo nginx -t to test the configuration file for errors.

help me fix Nginx not starting on Amazon Linux

Test Nginx locally with curl

The service is running, but does it actually serve a web page? You can test this from inside the server using curl, a command-line tool that fetches URLs.

Before you run the next command, what do you expect to see? Nginx is running and listening on port 80. What should happen when you request the localhost URL?

Test that Nginx responds to HTTP requests by running:

curl http://localhost

You should see raw HTML in your terminal that includes the heading "Welcome to nginx!" and the text "If you see this page, the nginx web server is successfully installed and working."

What just happened?

curl sent an HTTP request to port 80 on your own server (localhost). Nginx received the request and returned its default welcome page. This confirms the full chain is working: the service is running, listening on port 80, and serving HTML.

The HTML you see is the default page from /usr/share/nginx/html/index.html. You will replace this file with your own content in a later step.

Seeing "Connection refused"?

This means nothing is listening on port 80. Run sudo systemctl status nginx to confirm the service is active. If it stopped, start it again with sudo systemctl start nginx.

help me troubleshoot curl connection refused on localhost

Nginx is installed, running, and serving pages locally. Next up, you will try to access your server from your own browser on Windows. But will it work? There is one more piece of the puzzle between your browser and this server.

Troubleshoot Access by Fixing the Security Group

In the last step, you proved Nginx is alive and responding. Running curl http://localhost returned a full HTML page right there on the server.

Time to see that page from the outside world. You'll open your server's public IP in your Windows browser and find out whether the rest of the internet can reach what you built.

In this step, get ready to:

Attempt to access your Nginx server from your Windows browser.
Diagnose why the connection times out.
Fix the AWS security group to allow HTTP traffic.

Try to access your server from your browser

Nginx is running on your instance and responding to local requests. Before you try the next step, what do you think will happen when you paste your server's public IP into your Windows browser?

Switch to your Windows machine and open your web browser.
Paste the following URL into your browser's address bar, replacing the placeholder with your instance's public IP from the EC2 console:

http://[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

Wait about 10-15 seconds and watch what happens.

The page never loads. Your browser eventually shows a timeout error. This is the designed obstacle for this step, and it is the exact problem Cloud Engineers troubleshoot regularly in production.

Why does it time out?

Your instance's security group acts as a virtual firewall. Right now it only has one inbound rule: SSH on port 22. That rule is what let you connect with your terminal.

HTTP traffic uses port 80. Because no rule allows port 80, AWS silently drops all HTTP packets before they ever reach Nginx. The server is fine. The network is blocking you.

Add an HTTP rule to your security group

You need to tell AWS to let HTTP traffic through. You do this by adding an inbound rule to your instance's security group.

Switch to the AWS Management Console in your browser and navigate to the EC2 service.
In the left navigation pane, click Instances.
Select your running instance by clicking its checkbox.
In the details pane at the bottom, click the Security tab.
Under Security groups, click the security group name link (it starts with sg-).

This opens the security group's detail page where you can manage its rules.

Click Edit inbound rules.
Click Add rule.
In the Type dropdown, select HTTP. This auto-fills port 80 and TCP for you.
In the Source dropdown, select Anywhere-IPv4 (0.0.0.0/0).
Click Save rules.

What did you just do?

You told AWS to allow any IPv4 address on the internet to send HTTP requests to your instance on port 80. The security group applies instantly to all associated instances.

Security groups are stateful. Because you allowed inbound HTTP, the response traffic flows back automatically without needing a separate outbound rule.

Verify the page loads publicly

The rule is saved. Before you refresh your browser, what do you think will happen this time?

Switch back to the browser tab where the page timed out.
Refresh the page (or paste the URL again):

http://[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

The Nginx default welcome page now appears. You just diagnosed and fixed a real cloud networking access issue.

Still seeing a timeout?

Double-check that you selected HTTP (not HTTPS) as the rule type. HTTPS uses port 443, not 80.
Confirm the source is Anywhere-IPv4 (0.0.0.0/0). A restricted source IP will block your home network.
Make sure you clicked Save rules after adding the rule. Unsaved changes do not take effect.
Verify Nginx is still running by switching to your SSH terminal and running sudo systemctl status nginx.

help me figure out why my EC2 instance still won't load in the browser after adding an HTTP security group rule

You've proven you can diagnose and fix a networking issue on live cloud infrastructure. Next up, you'll replace the default Nginx page with your own custom HTML.

Deploy a Custom Web Page and Manage File Ownership

Your Nginx welcome page is live on the public internet. You diagnosed a real networking issue and fixed it by updating the security group. Now it's time to replace that default page with your own content.

Deploying custom content teaches you how Linux file ownership and the web server's document root interact. Getting ownership wrong is a common source of "403 Forbidden" errors in production, so you'll pay close attention to who owns the files Nginx serves.

In this step, get ready to:

Find where Nginx stores the files it serves (the document root).
Deploy a custom HTML page with your name on it.
Verify file ownership and see your page live on the internet.

Find the Nginx document root

Nginx needs to know which folder on disk contains the files it serves to visitors. This folder is called the document root. You need to find it before you can replace the default page with your own.

Search the Nginx configuration file for the document root by running this command:

cat /etc/nginx/nginx.conf | grep root

You should see a line containing root /usr/share/nginx/html; in the output. This tells Nginx to serve files from the /usr/share/nginx/html directory.

List the contents of the document root to see what is currently there by running:

ls -la /usr/share/nginx/html/

You should see the default index.html file and possibly other default Nginx files. Notice the ownership columns showing root root on each file.

Why is root the owner?

The /usr/share/nginx/html directory is owned by the root user because it was created by the dnf package manager during installation. Only privileged users (using sudo) can write files here.

This is a security feature. It prevents non-privileged processes from modifying web content without explicit permission.

Create your custom HTML page

You'll use sudo tee to write a new file into the document root. Because the directory is owned by root, a regular echo > file command would fail with a permission denied error.

Create your custom page by running this command:

sudo tee /usr/share/nginx/html/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>My First Cloud Server</title>
</head>
<body>
    <h1>My First Cloud Server</h1>
    <p>Deployed by [[YOURNAME="your name"]] on Amazon Linux 2023</p>
    <p>This page is served by Nginx on AWS EC2.</p>
</body>
</html>
EOF

What does this command do?

sudo tee runs the tee command with root privileges, letting you write to a file that only root can modify. The << 'EOF' part is called a heredoc. It sends everything between the two EOF markers as input to the command.

You'll see the HTML content echoed back to your terminal. That's normal. It confirms the file was written.

Verify the file ownership by running:

ls -la /usr/share/nginx/html/index.html

You should see root root in the ownership columns, confirming the file was created with root privileges.

Seeing "Permission denied"?

Make sure you included sudo at the start of the tee command. Without it, your ec2-user account does not have permission to write to the /usr/share/nginx/html/ directory.

help me fix a permission denied error when writing to the Nginx document root

Verify your page is live on the internet

Your custom HTML file is now sitting in the document root. Nginx is already running and serving files from that directory. Before you check, what do you expect to see when you refresh your browser?

Switch to your Windows browser.
Refresh the page at http://your EC2 public IP.

Your custom page now appears with the heading "My First Cloud Server" and your name. You have deployed content to a Linux web server on AWS.

Still seeing the Nginx welcome page?

Your browser may be showing a cached version of the old page. Try a hard refresh with Ctrl+Shift+R to bypass the cache.

If you still see the default page, confirm your file is in the right place by running curl http://localhost on the instance. If your custom HTML appears there, the file is correct and the issue is browser caching.

help me troubleshoot why my custom HTML page is not appearing in the browser

Secret mission

Serve a Second Site on a Custom Port

Real Cloud Engineers manage multiple services on the same server. In this bonus challenge, you will configure a second Nginx virtual host on port 8080 with its own document root, security group rule, and HTML page. This combines every skill from the project into one task.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The T4g free trial covers 750 hours per month of t4g.small until December 31, 2026, so your instance is not costing you anything right now.

Cost warning

The T4g free trial ends on December 31, 2026. After that date, a running t4g.small instance costs approximately $0.0168/hour (varies by region). If you plan to leave the instance running long-term, set a calendar reminder to stop or terminate it before the trial expires.

Resources you used:

1x EC2 instance (t4g.small) covered by T4g free trial (750 hrs/month until Dec 31, 2026).
1x EBS volume (8 GB gp3, attached to the instance).
1x Security group with inbound rules for SSH, HTTP, and port 8080.
1x Key pair (PEM format, stored in EC2 console and as a local file on your PC).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep practicing Linux commands on your server.

The T4g free trial covers one t4g.small running 24/7 at no charge, as long as you stay within the 750 hours/month aggregate across all regions.
Your security group, key pair, and EBS volume have no additional charges while the trial is active.
You can reconnect any time by opening PowerShell and running your SSH command with the same public IP (or the new one if you stopped and restarted the instance).

Pause - I'll come back to this later

Shut down the instance to free up compute resources. Your EBS volume and data persist so you can restart later.

In the EC2 console, select your instance.
Click **Instance state**, then **Stop instance**.
Confirm by clicking **Stop**.
While stopped, compute is free. The 8 GB EBS volume persists at minimal cost (covered under the AWS Free Tier storage allowance for the first 12 months of your account).
To resume, select the instance and choose **Instance state**, then **Start instance**. Note that the public IP address changes on restart unless you have an Elastic IP attached.

Delete - I don't want to use this again

Remove all project resources permanently. Do this if you are done and want zero risk of any charges after the free trial ends.

In the EC2 console, select your instance.
Click **Instance state**, then **Terminate instance**.
Confirm by clicking **Terminate**. The EBS volume is deleted automatically when the instance terminates (default behavior).
In the navigation pane, choose **Security Groups**. Select your security group and choose **Actions**, then **Delete security groups**. Enter Delete in the confirmation field and choose **Delete**. If the security group is the default one created by the launch wizard, you cannot delete it. That is fine. It has no cost.
In the navigation pane, choose **Key Pairs**. Select your key pair and choose **Actions**, then **Delete**. Enter Delete in the confirmation field and choose **Delete**.
On your Windows PC, delete the local .pem file you downloaded. Open File Explorer, navigate to where you saved the file, right-click it, and select **Delete**.

Nice Work!

You just deployed a live web server on AWS infrastructure entirely from the Linux command line. Your custom page is sitting on the public internet right now, served by Nginx on an EC2 instance you launched, connected to, and configured yourself.

Here's what you learned:

Launched an Amazon Linux 2023 EC2 instance and connected to it over SSH from Windows PowerShell.
Installed and managed Nginx using dnf for package management and systemctl for service control.
Diagnosed a real cloud networking issue by fixing a security group to allow HTTP traffic, then deployed a custom HTML page to the public internet.
Secret Mission: Configured a second Nginx virtual host on a custom port with its own security group rule, proving you can manage multi-service configurations on a single server.

Ready to quiz yourself?