Deploy a Web Server on EC2 in a Custom VPC

Build a custom VPC from scratch and deploy a live Apache web server on EC2.

Introduction

30 Second Summary

Every website you visit lives on a server connected to the internet through a carefully configured network. Cloud engineers build these networks from scratch every day.

In this project, you will create your own isolated network inside AWS and deploy a live web server that anyone can visit from their browser.

What You'll Build

A custom virtual network in AWS with a public subnet, internet gateway, route table, security group, and a running EC2 instance serving a live web page.

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

A custom VPC with its own IP address range, a public subnet, and full internet connectivity built from scratch.
A running EC2 instance with Apache installed, serving a styled web page you can access from any browser.
A clear understanding of how security groups, route tables, and internet gateways work together to make a server reachable from the outside world.
Secret Mission: Add a private subnet and launch a second EC2 instance that can only be reached from within the VPC.

Are there any prerequisites?

You need an AWS account (free tier or paid). Everything else happens in your browser using the AWS Management Console and EC2 Instance Connect. No local installations required.

Create Your Custom VPC

Every resource you launch in AWS needs a network to live in. A VPC is your own isolated network inside the AWS cloud, where you control the IP addresses, routing, and security.

In this step, you'll create a custom VPC from scratch using the AWS Management Console. You'll configure its IP address range and enable DNS hostnames so that instances inside your VPC can be reached by name.

In this step, get ready to:

Navigate to the VPC Console and create a new VPC.
Enable DNS hostnames so your instances get public DNS names.
Verify your VPC is configured correctly.

Navigate to the VPC Console and create a new VPC

Sign in to the AWS Management Console at console.aws.amazon.com.
Click the search bar at the top of the page.
Type VPC and select VPC from the results.
Click Create VPC.
Under Resources to create, select VPC only.
For Name tag, enter my-cloud-vpc.
For IPv4 CIDR block, make sure IPv4 CIDR manual input is selected and enter 10.0.0.0/16.
Leave IPv6 CIDR block set to No IPv6 CIDR block.
Leave Tenancy set to Default.
Click Create VPC.

You should see a green success banner at the top of the page confirming your VPC was created.

What is a VPC?

A VPC (Virtual Private Cloud) is your own private section of the AWS cloud. Think of it as a building you own. You decide the floor plan, who gets in, and how rooms connect to each other.

Nothing can enter or leave your VPC unless you explicitly allow it. Over the next few steps, you'll add the doors, hallways, and security guards that make your VPC usable.

Why 'VPC only' instead of 'VPC and more'?

The VPC and more option auto-creates subnets, route tables, an internet gateway, and even NAT gateways for you. That is convenient for production, but it hides how every component connects.

By choosing VPC only, you'll build each piece yourself. That hands-on practice is the entire goal of this project.

You set your VPC's CIDR block to 10.0.0.0/16. This is the IP address range your VPC owns.

What is a CIDR block?

A CIDR block defines a range of IP addresses. The /16 part means the first 16 bits of the address are fixed (10.0), and the remaining 16 bits are yours to use. That gives your VPC about 65,000 IP addresses.

Later, you'll carve out a smaller range (10.0.1.0/24) for a subnet inside this VPC. The subnet's range fits neatly within the VPC's larger range.

Enable DNS hostnames for your VPC

By default, EC2 instances launched in a custom VPC do not get public DNS names. You need to turn on DNS hostnames so your web server will be reachable by a human-readable address.

On the VPC details page, confirm that my-cloud-vpc is selected.
Click Actions in the top right area.
Select Edit VPC settings.
Under DNS settings, check the box for Enable DNS hostnames.
Click Save.

Why enable DNS hostnames?

Without this setting, your EC2 instances only get a raw IP address like 54.123.45.67. With DNS hostnames enabled, each instance also gets a DNS name like ec2-54-123-45-67.compute-1.amazonaws.com. Many AWS features depend on these DNS names to work correctly.

Don't see the DNS hostnames option?

Make sure you selected my-cloud-vpc before clicking Actions. If you are viewing the default VPC (the one AWS created automatically), the settings page looks different.

Help me find the DNS hostnames setting for my VPC.

Verify your VPC settings

Before moving on, confirm everything is set up correctly.

In the left navigation of the VPC Console, click Your VPCs.
Find my-cloud-vpc in the list and select it.
Confirm the IPv4 CIDR shows 10.0.0.0/16.
Confirm DNS hostnames shows Enabled.

You might also notice that AWS automatically created a main route table and a default network ACL for your VPC. These appear in the VPC details panel.

What are route tables and network ACLs?

A route table is a set of rules that tells traffic where to go. The main route table AWS just created only has a single "local" route, meaning resources inside the VPC can talk to each other but nothing can reach the internet yet.

A network ACL is a firewall at the subnet level that controls what traffic is allowed in and out. The default one allows everything. You'll build a custom route table in the next step to connect your VPC to the internet.

Your custom VPC is ready. Next up, you'll create a public subnet and an internet gateway to give your VPC a path to the outside world.

Build the Public Subnet and Internet Gateway

Your my-cloud-vpc is created, but right now it is completely isolated. There is no path connecting your VPC to the public internet.

In this step, you will build three networking components that open your VPC to the outside world. Each piece plays a specific role in getting internet traffic to and from your future web server.

In this step, get ready to:

Create a public subnet inside your VPC.
Attach an internet gateway to connect your VPC to the internet.
Build a custom route table that directs traffic through the gateway.

Create a public subnet

A subnet is a smaller network inside your VPC where you place cloud resources like servers. You need at least one subnet before you can launch anything.

In the VPC Console left navigation, click Subnets.
Click Create subnet.
Under VPC ID, select my-cloud-vpc.
Under Subnet name, enter my-public-subnet.
Under Availability Zone, choose the first option listed (for example, us-east-1a).
Under IPv4 subnet CIDR block, enter 10.0.1.0/24.
Click Create subnet.

What is a CIDR block?

A CIDR block defines a range of IP addresses. Your VPC uses 10.0.0.0/16, which gives it over 65,000 addresses.

Your subnet's 10.0.1.0/24 carves out a smaller slice of 256 addresses within that range. Think of the VPC as a building and the subnet as one floor inside it.

Now you need to make sure any server launched in this subnet automatically gets a public IP address.

Select my-public-subnet from the subnets list.
Click Actions, then Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Why enable auto-assign public IPv4?

By default, instances launched in a custom VPC subnet do not get a public IP address. Enabling this setting ensures every instance you launch in my-public-subnet automatically receives a public IP that people on the internet can use to reach it.

You should see my-public-subnet in your subnets list with the CIDR block 10.0.1.0/24 and auto-assign public IPv4 set to Yes.

Don't see your VPC in the dropdown?

Make sure you are in the same AWS Region where you created my-cloud-vpc. Check the Region selector in the top-right corner of the AWS Console.

Help me find my VPC in the subnet creation dropdown

Create and attach an internet gateway

Your subnet exists, but it still cannot reach the internet. An internet gateway is the component that connects your VPC to the public internet. Without one, traffic has nowhere to go.

In the VPC Console left navigation, click Internet gateways.
Click Create internet gateway.
Under Name tag, enter my-cloud-igw.
Click Create internet gateway.

The gateway is created, but it is not connected to your VPC yet. You need to attach it.

Click Actions, then Attach to VPC.
Select my-cloud-vpc.
Click Attach internet gateway.

The state should now show Attached next to my-cloud-igw. Your VPC now has a door to the internet, but traffic does not know to use it yet.

What does an internet gateway do?

An internet gateway is a horizontally scaled, redundant VPC component that allows communication between your VPC and the public internet. It handles the network address translation for instances that have public IP addresses.

Creating and attaching the gateway is only the first half. You also need a route table rule that tells traffic to flow through it. That is the next substep.

Attach to VPC option is grayed out?

An internet gateway can only be attached to one VPC at a time. If the option is grayed out, the gateway may already be attached. Check the State column in the internet gateways list to confirm.

Help me attach my internet gateway to my VPC

Create a custom route table and route traffic to the internet

A route table contains rules that determine where network traffic goes. Right now, your subnet uses the VPC's main route table, which only has a local route for traffic within the VPC. You need a custom route table that also sends internet-bound traffic to your gateway.

In the VPC Console left navigation, click Route tables.
Click Create route table.
Under Name, enter my-public-rt.
Under VPC, select my-cloud-vpc.
Click Create route table.

Your route table is created, but it only has the default local route. You need to add a route that sends internet-bound traffic to your internet gateway.

Select my-public-rt and go to the Routes tab.
Click Edit routes.
Click Add route.
Under Destination, enter 0.0.0.0/0.
Under Target, select Internet Gateway, then choose my-cloud-igw.
Click Save changes.

What does the 0.0.0.0/0 route do?

The destination 0.0.0.0/0 means "all IP addresses." This route tells your VPC: any traffic that is not headed for a local address inside the VPC should be sent to the internet gateway.

Your route table now has two routes. The local route (10.0.0.0/16) keeps traffic between VPC resources internal. The internet route (0.0.0.0/0) sends everything else out through the gateway.

The route table has the right rules, but it is not connected to your subnet yet. You need to associate it so that my-public-subnet uses this custom route table instead of the VPC's main route table.

Go to the Subnet associations tab.
Click Edit subnet associations.
Check the box next to my-public-subnet.
Click Save associations.

Why does this association matter?

Subnets without an explicit route table association use the VPC's main route table, which only has the local route. By associating my-public-subnet with my-public-rt, you give it a route to the internet gateway.

This is what makes a subnet "public." A public subnet has a route to an internet gateway. A private subnet does not.

Verify your work by selecting my-public-rt in the route tables list. The Routes tab should show two routes: 10.0.0.0/16 targeting local and 0.0.0.0/0 targeting my-cloud-igw.

The Subnet associations tab should show my-public-subnet listed as an explicit association.

Route not showing up?

Make sure you clicked Save changes after adding the route. If you navigated away before saving, the route was not persisted. Go back to the Routes tab, click Edit routes, and add the 0.0.0.0/0 route again.

Help me troubleshoot my route table configuration

Your network infrastructure is fully wired. Traffic can now flow from the internet, through your gateway, and into your public subnet. Next, you will configure a security group to control who can access your server, then launch an EC2 instance inside your new subnet.

Configure Security and Launch the EC2 Instance

Your network infrastructure is complete. You have a custom VPC with a public subnet, an internet gateway, and a route table that directs traffic to the internet.

Now you need to decide who is allowed to talk to your server and then launch the server itself. A security group defines exactly which traffic can reach your instance. An EC2 instance is the virtual server that will run your website inside that network.

In this step, get ready to:

Create a security group that allows web traffic and SSH access.
Launch an EC2 instance inside your custom VPC.
Verify the instance is running and note its public IP address.

Create a security group

Your VPC and subnet control where your instance lives. A security group controls what traffic can reach it. You need two inbound rules: one for web browsers to view your site, and one for you to connect to the server's terminal.

Search for EC2 in the AWS Console search bar at the top.
Select EC2 from the results.
In the left navigation under Network & Security, click Security Groups.
Click Create security group.
Enter my-web-sg in the Security group name field.
Enter Allow HTTP and SSH in the Description field.
In the VPC dropdown, remove the default VPC by clicking the X next to it.
Select my-cloud-vpc from the dropdown.

Now add the inbound rules that control who can access your instance:

Scroll down to Inbound rules and click Add rule.
Set Type to SSH.
Set Source to My IP.
Click Add rule again to add a second rule.
Set Type to HTTP.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Leave the Outbound rules section as the default (all traffic allowed).
Click Create security group.

You should see a success banner and your my-web-sg security group listed with both inbound rules.

What is a security group?

A security group is a virtual firewall that wraps around your EC2 instance. It only has allow rules. Any traffic that does not match a rule is automatically blocked.

Security groups are also stateful. If you allow inbound HTTP traffic, the response to that request is automatically allowed outbound. You do not need to create a matching outbound rule.

Why restrict SSH to your IP?

The SSH rule uses My IP as the source, which limits terminal access to your current IP address. Opening SSH to 0.0.0.0/0 would let anyone on the internet attempt to connect to your server. HTTP is open to all because you want the whole world to see your website.

Don't see my-cloud-vpc in the dropdown?

Make sure you removed the default VPC from the dropdown first by clicking the X next to it. Your custom VPC should then appear in the list.

Also confirm you are in the same AWS region where you created your VPC. Check the region selector in the top-right corner of the console.

Help me find my custom VPC when creating a security group.

Launch an EC2 instance inside your custom VPC

Your network is built and your firewall rules are in place. Now you will launch the virtual server that will sit inside this network. An AMI (Amazon Machine Image) determines the operating system and software your instance starts with.

In the EC2 Console left navigation, click Instances.
Click Launch instances.
Enter my-web-server in the Name field.
Under Application and OS Images, confirm that Amazon Linux 2023 AMI is selected. It should be the default and marked Free tier eligible.
Under Instance type, select t2.micro (Free tier eligible). If t2.micro is not available, select t3.micro instead.
Under Key pair (login), select Proceed without a key pair from the dropdown.

Why no key pair?

A key pair is normally used to SSH into your instance from a local terminal. You will use EC2 Instance Connect instead, which provides a browser-based terminal with zero local setup. No key pair file needed.

Now configure the network settings to place your instance inside the VPC you built:

Under Network settings, click Edit.
Change VPC to my-cloud-vpc.
Change Subnet to my-public-subnet.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Select existing security group.
Choose my-web-sg from the list.
Click Launch instance.

You should see a success message confirming that your instance is launching.

What is an AMI?

An AMI (Amazon Machine Image) is a template that contains the operating system, pre-installed software, and configuration your instance starts with. Amazon Linux 2023 is a lightweight Linux distribution maintained by AWS.

You can think of an AMI as a snapshot of a computer. When you launch an instance from it, you get a running copy of that snapshot.

Free tier instance types

Which instance type is free depends on when you created your AWS account. Accounts created before July 2025 get t2.micro free for 12 months (750 hours/month). Accounts created after July 2025 get t3.micro for 6 months or until credits are used.

Either option works for this project. Look for the Free tier eligible label next to the instance type.

Seeing an error when launching?

Make sure you clicked Edit under Network settings before changing the VPC. If you did not click Edit, the fields will not be editable.

If the subnet dropdown does not show my-public-subnet, confirm that you selected my-cloud-vpc as the VPC first. The subnet list filters based on the selected VPC.

Help me troubleshoot my EC2 instance launch.

Verify the instance is running

Your instance is launching, but it takes a minute or two for AWS to fully boot it and run health checks. You need to confirm it is healthy before moving on.

In the EC2 Console left navigation, click Instances.
Find your my-web-server instance in the list.
Wait for the Instance state column to show Running.
Wait for the Status check column to show 2/2 checks passed. This may take 1-2 minutes.
Click on your my-web-server instance to open its details.
Find the Public IPv4 address in the instance summary. Copy this address and save it somewhere. You will use it to access your web server in the next step.

Why does my instance have a public IP?

Your instance received a public IP address because you enabled Auto-assign public IP on your subnet in the previous step. Without that setting, your instance would only have a private IP and would be unreachable from the internet.

Instance stuck on Initializing?

Status checks can take up to 2 minutes. Click the refresh icon in the top-right of the instances table to update the status.

If the status check shows 1/2 checks passed for more than 5 minutes, the instance may have a networking issue. Confirm that your VPC, subnet, internet gateway, and route table are all configured correctly from the previous steps.

Help me troubleshoot my EC2 instance status checks.

Your server is live inside the network you built from scratch. Next up, you will install a web server on it and deploy a custom web page that anyone can visit.

Install Apache and Deploy Your Web Page

Your custom VPC, subnet, internet gateway, route table, and security group are all wired together. Your EC2 instance is running and waiting for instructions.

Right now, the instance is a blank server with no web software installed. In this step, you'll connect to it through your browser and install Apache to serve a live web page to the world.

In this step, get ready to:

Connect to your EC2 instance through a browser-based terminal.
Install and start the Apache web server.
Deploy a custom HTML page and view it live in your browser.

Connect to your instance using EC2 Instance Connect

Your instance is running, but you need a way to send it commands. EC2 Instance Connect gives you a browser-based terminal with zero local setup required.

In the AWS Console, search for EC2 in the top search bar and select the EC2 service.
In the left navigation, click Instances.
Select your my-web-server instance by checking its box.
Click the Connect button at the top of the page.
On the Connect to instance page, choose the EC2 Instance Connect tab.
Leave the username as ec2-user.
Click Connect.

A new browser tab opens with a terminal. You should see a command prompt ending with $.

What is EC2 Instance Connect?

EC2 Instance Connect is an AWS feature that lets you SSH into your instance directly from your browser. It works with Amazon Linux 2023 out of the box.

Since your instance is in a public subnet with port 22 open, the connection goes through without any local SSH client or key pair.

Connection failed?

Make sure your instance's status shows Running with 2/2 checks passed. If checks haven't passed yet, wait another minute and try again.
Verify that my-web-sg has an inbound rule for SSH (port 22). EC2 Instance Connect needs this port open.
Why can't I connect to my EC2 instance using EC2 Instance Connect?

Install and start Apache

Apache httpd is one of the most widely used web servers in the world. It listens for incoming HTTP requests on port 80 and serves web pages in response.

Install and start Apache by running these commands in your EC2 Instance Connect terminal:

sudo dnf update -y
sudo dnf install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd

What do these commands do?

sudo dnf update -y updates all installed packages to their latest versions. The -y flag auto-confirms every prompt.
sudo dnf install -y httpd installs the Apache HTTP Server. dnf is the package manager on Amazon Linux 2023.
sudo systemctl start httpd starts the Apache service immediately.
sudo systemctl enable httpd tells the system to start Apache automatically if the instance ever reboots.

Verify Apache is running by running this command:

sudo systemctl status httpd

You should see active (running) in green text. This confirms Apache is ready to serve web pages.

Not seeing "active (running)"?

Double-check that you ran sudo systemctl start httpd (not just the install command). Installing a package does not start it automatically.
If you see "not found", make sure you typed httpd correctly.
Apache httpd is not showing as active after I ran the start command. What should I check?

Deploy your custom web page

Apache serves files from the /var/www/html/ directory by default. You'll replace the default page with your own HTML.

Create your custom web page by running this command in the terminal:

sudo bash -c 'cat > /var/www/html/index.html << EOF
<!DOCTYPE html>
<html>
<head>
    <title>My Cloud Server</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            min-height: 100vh;
            margin: 0;
            background: linear-gradient(135deg, #232f3e, #ff9900);
            color: white;
        }
        .container {
            text-align: center;
            padding: 40px;
            background: rgba(0,0,0,0.3);
            border-radius: 16px;
        }
        h1 { font-size: 2.5em; margin-bottom: 10px; }
        p { font-size: 1.2em; opacity: 0.9; }
    </style>
</head>
<body>
    <div class="container">
        <h1>Hello from my Custom VPC!</h1>
        <p>This server is running inside a VPC I built from scratch.</p>
        <p>Served by Apache on Amazon Linux 2023</p>
    </div>
</body>
</html>
EOF'

What does this command do?

sudo bash -c '...' runs the entire command as the root user. You need root permissions to write files to /var/www/html/.
cat > /var/www/html/index.html << EOF uses a heredoc to write everything between the two EOF markers into index.html.
The HTML creates a centered page with an orange gradient background, the heading "Hello from my Custom VPC!", and two lines describing the server.

Open a new browser tab.
In the address bar, navigate to your instance's public IP using this URL format:

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

You should see your custom page with an orange-to-dark gradient background, the heading "Hello from my Custom VPC!", and two lines of text describing the server.

Page not loading?

Make sure you're using http:// (not https://). Apache is serving plain HTTP on port 80.
Check that my-web-sg still has the HTTP inbound rule allowing port 80 from 0.0.0.0/0.
If you need to find your Public IPv4 address again, go to the EC2 Console, click Instances, and select my-web-server. The public IP is listed in the instance details panel.
If you see the default Apache test page instead of your custom page, the heredoc command may not have completed successfully. Run cat /var/www/html/index.html in your terminal to check the file contents.
I can't see my custom web page when I visit my EC2 instance's public IP. What should I check?

✔️ Awesome, I've got everything!

You're all set. Your web page is live and accessible from any browser in the world.

ⓧ I'd like to double check the full code

Here is the full index.html that should be deployed to /var/www/html/index.html on your instance.

<!DOCTYPE html>
<html>
<head>
    <title>My Cloud Server</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            display: flex;
            justify-content: center;
            align-items: center;
            min-height: 100vh;
            margin: 0;
            background: linear-gradient(135deg, #232f3e, #ff9900);
            color: white;
        }
        .container {
            text-align: center;
            padding: 40px;
            background: rgba(0,0,0,0.3);
            border-radius: 16px;
        }
        h1 { font-size: 2.5em; margin-bottom: 10px; }
        p { font-size: 1.2em; opacity: 0.9; }
    </style>
</head>
<body>
    <div class="container">
        <h1>Hello from my Custom VPC!</h1>
        <p>This server is running inside a VPC I built from scratch.</p>
        <p>Served by Apache on Amazon Linux 2023</p>
    </div>
</body>
</html>

Your web server is live and accessible from anywhere in the world. Next up, you'll trace the full network path to understand exactly how traffic flows from the internet to your instance and back.

Trace the Network Path

Your web page is live, accessible from any browser in the world. But how does a request from the internet actually find its way to your EC2 instance inside your VPC?

In this step, you'll trace the full path that traffic takes from the internet to your server. You'll also prove that your security group actively controls access by temporarily blocking HTTP traffic and watching the effect in real time.

In this step, get ready to:

Verify the route table connects your subnet to the internet gateway.
Test security group behavior by removing and re-adding an HTTP firewall rule.

Verify the complete network path

Every time someone visits your website, their request travels through several networking components. The route table is the piece that tells traffic where to go next.

Search for VPC in the AWS Console search bar and open the VPC service.
In the left navigation, click Route tables.
Select my-public-rt from the list.
Click the Routes tab in the details panel below.

You should see two routes listed in the table.

What do these two routes mean?

The local route (10.0.0.0/16 targeting local) allows all resources inside your VPC to communicate with each other.

The internet route (0.0.0.0/0 targeting my-cloud-igw) sends all other traffic to your internet gateway. This is the route that makes your subnet public.

Click the Subnet associations tab.
Confirm that my-public-subnet appears in the Explicit subnet associations section.

This confirms the full path. Internet traffic hits your internet gateway, the route table directs it into my-public-subnet, and your EC2 instance receives it there.

Test security group behavior

You've verified the networking path. Now there's one more layer to test. Your security group acts as a firewall that decides which traffic is allowed to actually reach your instance.

To prove this, you'll remove the HTTP rule, watch your website stop loading, then add it back and watch it recover.

Search for EC2 in the AWS Console search bar and open the EC2 service.
In the left navigation, click Instances.
Select your my-web-server instance.
Click the Security tab in the details panel below.

You should see my-web-sg listed as the security group. The inbound rules show SSH on port 22 (restricted to your IP) and HTTP on port 80 (open to all).

Click the security group link for my-web-sg to open its details page.
Click Edit inbound rules.
Find the HTTP rule (port 80) and click Delete on that row.
Click Save rules.

Your website will stop loading

This is expected. You just removed the rule that allows HTTP traffic to reach your instance. Without it, the security group blocks all incoming web requests.

Open the browser tab where your website was loading.
Refresh the page.

The page should time out or fail to load. The security group is now actively blocking all HTTP traffic to your instance.

Now add the rule back to restore access.

Go back to the my-web-sg security group page in the AWS Console.
Click Edit inbound rules.
Click Add rule.
Set Type to HTTP.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Click Save rules.

Go back to your website browser tab.
Refresh the page.

Your custom page should load again with the orange gradient and the heading "Hello from my Custom VPC!" visible.

What did this prove?

Security groups actively filter every incoming packet in real time. They are not passive labels on your instance.

The moment you removed the HTTP rule, your web server became unreachable on port 80. Adding it back restored access immediately. Only explicitly allowed traffic gets through.

Still seeing a timeout after re-adding the rule?

Make sure you set the Source to Anywhere-IPv4 (0.0.0.0/0), not My IP.
Confirm you clicked Save rules after adding the HTTP rule back.
Try a hard refresh with Cmd+Shift+R (macOS) or Ctrl+Shift+R (Windows) to bypass your browser cache.
Why is my website still timing out after re-adding the HTTP rule?

Secret mission

Add a Private Subnet with a Second EC2 Instance

Your VPC has a public subnet where anyone on the internet can reach your web server. But in real cloud architectures, most resources live in private subnets, hidden from the outside world. Can you build a private subnet and prove that an instance inside it is truly isolated?

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your VPC, subnets, internet gateway, route table, and security groups are all free. The only resource that can incur charges is your EC2 instance.

Cost warning

Your my-web-server EC2 instance is free-tier eligible, but leaving it running beyond your free tier limits will result in charges.

Accounts created before July 2025 get 750 hours/month of t2.micro for 12 months. Accounts created after July 2025 get t3.micro or similar instances for 6 months or until credits are used. If you are unsure, stop or terminate your instance to avoid any charges.

Resources you used:

1 VPC (my-cloud-vpc) - no cost.
1 public subnet (my-public-subnet) - no cost.
1 internet gateway (my-cloud-igw) - no cost.
1 route table (my-public-rt) - no cost.
1 security group (my-web-sg) - no cost.
1 EC2 instance (my-web-server) - free tier eligible, charges apply if left running beyond free tier limits.
Secret Mission only: 1 private subnet (my-private-subnet), 1 security group (my-private-sg), and 1 EC2 instance (my-private-server).

Keep everything running

No action needed. Choose this if you are still actively building or want your website to stay live.

Your website remains accessible at your instance's public IP address.
Your EC2 instance will consume free tier hours (750 hours/month for t2.micro on pre-July 2025 accounts, or credits on newer accounts).
Monitor your usage in the AWS Billing Console to make sure you stay within free tier limits.

Pause - I'll come back to this later

Stop your EC2 instance to pause compute charges while keeping your entire setup intact. You can start it again anytime.

Go to the EC2 Console and select Instances in the left navigation.
Select your my-web-server instance.
Click Instance state, then Stop instance.
If you completed the Secret Mission, also stop my-private-server.
Your VPC, subnet, internet gateway, route table, and security groups remain in place at no cost.
When you start the instance again, it will get a new public IP address. The EBS volume attached to your instance has a small ongoing cost, but it is also free tier eligible.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order carefully because some resources depend on others.

Go to the EC2 Console, select my-web-server, click Instance state, then Terminate instance.
If you completed the Secret Mission, also terminate my-private-server.
Wait for both instances to show "Terminated" in the Instance state column.
Go to Security Groups under Network & Security in the EC2 left navigation. Delete my-web-sg (and my-private-sg if you created it).
Go to the VPC Console. Under Subnets, delete my-public-subnet (and my-private-subnet if you created it).
Under Internet gateways, select my-cloud-igw, click Actions, then Detach from VPC. Then delete the internet gateway.
Under Route tables, delete my-public-rt. Do not delete the main route table (AWS removes it automatically with the VPC).
Under Your VPCs, select my-cloud-vpc and delete it. This removes the VPC and its default network ACL.

Once everything is deleted, no further charges will apply.

Mission accomplished

That's a Wrap!

Nice work! You just built a production-style AWS network from the ground up and deployed a live web server inside it.

You've learned how to:

Built a custom VPC with a public subnet, internet gateway, and custom route table to create a fully connected network from scratch.
Configured a security group to control exactly who can reach your server on which ports. Proved it actively blocks unauthorized traffic by toggling an HTTP rule.
Launched an EC2 instance running Apache on Amazon Linux 2023 and deployed a custom web page accessible from anywhere in the world.
Secret Mission: Added a private subnet and proved that instances inside it are isolated from the internet, reachable only from within the VPC.

Ready to quiz yourself?