AWS Lab 3:Building a Custom Amazon VPC and Launching a Web Server

Introduction

In this lab, I learned how to build a custom network in Amazon Web Services (AWS) using Amazon Virtual Private Cloud (Amazon VPC). A Virtual Private Cloud (VPC) allows users to create an isolated virtual network where AWS resources such as EC2 instances can be securely deployed.

Unlike launching resources in the default AWS network, creating a custom VPC gives complete control over networking components such as IP address ranges, subnets, route tables, Internet Gateways, NAT Gateways, and security groups.

During this lab, I created a custom VPC, configured both public and private subnets, added routing components, created a security group, and finally launched an Amazon EC2 instance configured as a web server.

Lab Objectives

The objectives of this lab were:

• Create a custom Amazon VPC.
• Configure public and private subnets.
• Understand Internet Gateway and NAT Gateway.
• Configure route tables.
• Create a Security Group.
• Launch an EC2 instance inside the VPC.
• Deploy a simple web server.

Understanding Amazon VPC

Amazon Virtual Private Cloud (Amazon VPC) is a networking service that allows users to create a private and isolated virtual network inside AWS.

A VPC provides complete control over network configuration, including:

• IP address ranges
• Subnets
• Route tables
• Internet Gateways
• NAT Gateways
• Security Groups

Organizations use VPCs to build secure cloud environments while controlling how resources communicate with each other and with the internet.

Understanding the Architecture

Before starting the practical tasks, it is important to understand the architecture used in this lab.

The architecture consists of:

• One Virtual Private Cloud (VPC)
• Two Public Subnets
• Two Private Subnets
• One Internet Gateway
• One NAT Gateway
• Route Tables
• One Security Group
• One Amazon EC2 Web Server

The public subnet allows internet access, while the private subnet keeps resources protected from direct internet access.

Task 1: Creating a Custom VPC

The first task was to create a new Virtual Private Cloud that would serve as the network for all AWS resources used in this lab.

Step 1: Open the Amazon VPC Console

After logging into the AWS Management Console, I searched for VPC using the AWS search bar and opened the Amazon VPC service.

Before creating the VPC, I verified that the selected AWS Region was N. Virginia (us-east-1) because all lab resources needed to be created in the same region.

Step 2: Start Creating a New VPC

From the VPC Dashboard, I clicked Create VPC.

AWS provides two creation methods:

• VPC Only
• VPC and More

For this lab, I selected VPC and More because AWS automatically creates several networking resources required for a functional VPC.

This option saves time by creating multiple components together.

Step 3: Configure the VPC Settings

After selecting VPC and More, I configured the VPC using the following settings:

• Selected VPC and More as the creation option.
• Under Name tag auto-generation, I kept Auto-generate enabled and changed the project name to lab.
• Left the IPv4 CIDR Block as 10.0.0.0/16.
• Set the Number of Availability Zones to 1.
• Kept 1 Public Subnet.
• Kept 1 Private Subnet.
• Expanded the Customize Subnets CIDR Blocks section.
• Changed the Public Subnet CIDR Block to 10.0.0.0/24.
• Changed the Private Subnet CIDR Block to 10.0.1.0/24.
• Selected In 1 AZ for the NAT Gateway.
• Left VPC Endpoints as None.
• Kept both DNS Hostnames and DNS Resolution enabled.

After configuring these settings, I checked the Preview panel on the right side of the page to verify that AWS would create the following resources:

• VPC: lab-vpc
• Public Subnet: lab-subnet-public1-us-east-1a
• Private Subnet: lab-subnet-private1-us-east-1a
• Public Route Table: lab-rtb-public
• Private Route Table: lab-rtb-private1-us-east-1a
• Internet Gateway: lab-igw
• NAT Gateway: lab-nat-public1-us-east-1a

Once I confirmed that all the settings were correct, I clicked Create VPC.

Step 4: View the Created VPC

After clicking Create VPC, AWS started creating all the networking resources based on the configuration I had provided. Since I selected the VPC and More option, AWS automatically created several resources instead of requiring me to configure each one manually.

The NAT Gateway took a few minutes to become available, so I waited until all resources were successfully provisioned before moving to the next step.

Once the creation process was complete, I clicked View VPC to examine the resources that had been created.

Understanding the Resources Created

By selecting VPC and More, AWS automatically created the following networking components:

• One Virtual Private Cloud (VPC)
• One Public Subnet
• One Private Subnet
• One Internet Gateway (IGW)
• One NAT Gateway
• One Public Route Table
• One Private Route Table

These components work together to provide a secure and functional network for deploying AWS resources.

Step 5: Explore the Subnets

After opening the VPC, I selected Subnets from the navigation pane to verify that the required subnets had been created.

I observed that AWS had automatically created two subnets:

• lab-subnet-public1-us-east-1a
• lab-subnet-private1-us-east-1a

Each subnet had the CIDR block that I configured earlier.

Understanding Subnets

A subnet is a smaller network created within a VPC. It divides the VPC into separate sections so that resources can be organized based on their purpose and accessibility.

In this lab:

• Public Subnet (10.0.0.0/24): Used for resources that need direct internet access, such as web servers.
• Private Subnet (10.0.1.0/24): Used for resources that should remain protected from direct internet access, such as databases or backend servers.

Separating resources into public and private subnets improves both security and network management.

Step 6: Explore the Route Tables

Next, I selected Route Tables from the left navigation pane.

AWS had automatically created two route tables:

• lab-rtb-public
• lab-rtb-private1-us-east-1a

These route tables were already associated with their respective subnets.

Understanding Route Tables

A Route Table contains a set of routing rules that determine where network traffic should be sent.

In this VPC:

• The Public Route Table sends internet-bound traffic to the Internet Gateway, allowing resources in the public subnet to communicate directly with the internet.
• The Private Route Table sends internet-bound traffic to the NAT Gateway, allowing resources in the private subnet to access the internet securely without being directly reachable from outside.

This routing configuration helps maintain both connectivity and security.

Step 7: Explore the Internet Gateway

After reviewing the route tables, I selected Internet Gateways from the navigation pane.

I confirmed that an Internet Gateway named lab-igw had been created and attached to the VPC.

Understanding the Internet Gateway

An Internet Gateway (IGW) is a networking component that connects a VPC to the public internet.

It allows resources located in a public subnet to:

• Access websites and internet services.
• Receive incoming requests from users over the internet.

Without an Internet Gateway, resources inside the public subnet would not have internet connectivity.

Step 8: Explore the NAT Gateway

Finally, I selected NAT Gateways from the navigation pane.

I verified that AWS had created a NAT Gateway named lab-nat-public1-us-east-1a.

Understanding the NAT Gateway

A NAT (Network Address Translation) Gateway allows instances located in private subnets to connect to the internet when required, such as for downloading updates or installing software packages.

Unlike an Internet Gateway, a NAT Gateway does not allow inbound connections from the internet, which helps keep private resources secure while still providing outbound internet access.

Task 2: Create Additional Subnets

In this task, I expanded the existing VPC by creating two additional subnets in a second Availability Zone. Using multiple Availability Zones improves the availability and reliability of cloud applications because resources can continue operating even if one Availability Zone experiences an issue.

Step 1: Open the Subnets Page

From the left navigation pane in the VPC console, I selected Subnets.

This page displays all the subnets that currently exist within the VPC.

Step 2: Create the Second Public Subnet

To create another public subnet, I clicked Create subnet.

I then configured the following settings:

• VPC: lab-vpc
• Subnet Name: lab-subnet-public2
• Availability Zone: us-east-1b (Second Availability Zone)
• IPv4 CIDR Block: 10.0.2.0/24

After verifying the configuration, I clicked Create subnet.

The new public subnet was successfully created.

Understanding Availability Zones

An Availability Zone (AZ) is an isolated data center within an AWS Region.

By placing resources in multiple Availability Zones, applications become more reliable because if one Availability Zone becomes unavailable, resources in another Availability Zone can continue serving users.

In this lab:

• First subnet → us-east-1a
• Second subnet → us-east-1b

This is the basic concept behind High Availability in AWS.

Step 3: Create the Second Private Subnet

Next, I created another private subnet by clicking Create subnet again.

I entered the following configuration:

• VPC: lab-vpc
• Subnet Name: lab-subnet-private2
• Availability Zone: us-east-1b
• IPv4 CIDR Block: 10.0.3.0/24

After confirming the settings, I clicked Create subnet.

The second private subnet was created successfully.

Understanding Multiple Subnets

At this stage, my VPC contained four subnets.

SubnetAvailability ZoneTypelab-subnet-public1-us-east-1aus-east-1aPubliclab-subnet-private1-us-east-1aus-east-1aPrivatelab-subnet-public2us-east-1bPubliclab-subnet-private2us-east-1bPrivate

Having both public and private subnets across multiple Availability Zones provides better fault tolerance and makes the network suitable for highly available applications.

Step 4: Configure the Private Route Table

After creating the new subnets, the next step was to configure routing for the new private subnet.

From the left navigation pane, I selected Route Tables.

I chose the lab-rtb-private1-us-east-1a route table.

Under the Routes tab, I observed that the destination 0.0.0.0/0 was already pointing to the NAT Gateway.

This means that any internet-bound traffic from the private subnet is forwarded to the NAT Gateway.

Understanding the Route (0.0.0.0/0)

The route 0.0.0.0/0 is known as the default route.

It represents all IPv4 destinations outside the local network.

Since this route points to the NAT Gateway, any outbound internet traffic from the private subnet first reaches the NAT Gateway, which then forwards it to the internet while keeping the subnet private.

Step 5: Associate the Second Private Subnet

Next, I opened the Subnet Associations tab for the private route table.

I clicked Edit subnet associations.

The first private subnet (lab-subnet-private1-us-east-1a) was already selected.

I also selected:

• lab-subnet-private2

Finally, I clicked Save associations.

Now, both private subnets use the same private route table.

Understanding Subnet Association

A route table does not automatically apply to every subnet.

Each subnet must be associated with a route table so AWS knows how to route its network traffic.

By associating both private subnets with the same private route table, they both follow identical routing rules.

Step 6: Configure the Public Route Table

Next, I selected the lab-rtb-public route table.

Under the Routes tab, I confirmed that the destination 0.0.0.0/0 was pointing to the Internet Gateway (IGW).

This allows internet-bound traffic from public subnets to reach the internet directly.

Understanding Public Route Tables

A public route table directs internet traffic to an Internet Gateway.

Because of this routing rule, resources deployed in public subnets can communicate directly with the internet.

This is why web servers are typically launched in public subnets.

Step 7: Associate the Second Public Subnet

Finally, I selected the Subnet Associations tab for the public route table.

I clicked Edit subnet associations.

The first public subnet was already selected.

I then selected:

• lab-subnet-public2

After confirming the changes, I clicked Save associations.

Now, both public subnets use the same public route table.

Task 3: Create a VPC Security Group

In this task, I created a Security Group that would act as a virtual firewall for my EC2 instance. The purpose of this security group was to allow users to access the web server through HTTP while protecting the instance from unauthorized traffic.

Step 1: Open the Security Groups Page

From the left navigation pane in the VPC console, I selected Security Groups.

This page displays all the security groups associated with the selected VPC.

Step 2: Create a New Security Group

I clicked Create Security Group and entered the following details:

• Security Group Name: Web Security Group
• Description: Enable HTTP access
• VPC: lab-vpc

This security group would later be attached to the EC2 instance that hosts the web server.

Step 3: Configure the Inbound Rule

Next, under the Inbound Rules section, I clicked Add Rule and configured the following:

SettingValueTypeHTTPSourceAnywhere-IPv4DescriptionPermit web requests

After confirming the configuration, I clicked Create Security Group.

The security group was successfully created.

Understanding Security Groups

A Security Group is a virtual firewall that controls the traffic allowed to reach an EC2 instance.

Unlike traditional firewalls, Security Groups are stateful, meaning if inbound traffic is allowed, the corresponding outbound response is automatically allowed.

In this lab, I created a security group that allows HTTP (Port 80) traffic from anywhere so users can access the hosted website.

Common inbound rules include:

ProtocolPortPurposeHTTP80Access websitesHTTPS443Secure website accessSSH22Remote server administration

Task 4: Launch a Web Server Instance

After preparing the network and security settings, the next step was to launch an Amazon EC2 instance inside the newly created VPC.

This EC2 instance would act as a web server.

Step 1: Open the EC2 Console

From the AWS search bar, I searched for EC2 and opened the Amazon EC2 service.

Next, I selected Launch Instance.

Step 2: Configure the Instance Details

I entered the following configuration:

Instance Name: Web Server 1

AMI: Amazon Linux 2023(default)

Instance Type: t2.micro

Key Pair: vockey

The Name helps identify the EC2 instance.

The Amazon Linux 2023 AMI provides the operating system for the instance.

The t2.micro instance type offers a small virtual machine suitable for this lab.

The vockey key pair can be used to securely connect to the instance using SSH if needed.

Understanding the Selected Options

Amazon Machine Image (AMI)

An Amazon Machine Image (AMI) is a pre-configured template that contains the operating system and software required to launch an EC2 instance.

In this lab, I selected Amazon Linux 2023.

Instance Type

The Instance Type determines the CPU, memory, and networking capacity assigned to the virtual machine.

The t2.micro instance is suitable for lightweight workloads and is commonly used for learning and testing.

Key Pair

A Key Pair provides secure authentication when connecting to an EC2 instance using SSH.

Although SSH access was not required in this lab, selecting a key pair is still necessary during instance creation.

Step 3: Configure the Network Settings

Under Network Settings, I clicked Edit and configured the following:

• Network: lab-vpc
• Subnet: lab-subnet-public2
• Auto-assign Public IP: Enable

Under the Firewall (Security Groups) section, I selected:

• Select Existing Security Group

i.e. Web Security Group

This ensures that the EC2 instance is deployed inside the public subnet and is protected by the security group created earlier.

Understanding the Network Configuration

The EC2 instance was launched inside the Public Subnet because it needs to host a website that users can access over the internet.

Enabling a Public IP Address allows the instance to communicate with the internet.

Attaching the Web Security Group allows HTTP traffic to reach the web server while blocking unauthorized connections.

Step 4: Configure the Storage

I kept the default storage configuration provided by AWS.

The root volume used the following settings:

• Storage Type: General Purpose SSD (gp3)
• Size: 8 GiB

Since this lab only hosts a simple web application, no additional storage was required.

Understanding EC2 Storage

Every EC2 instance requires storage for its operating system and application files.

In AWS, this storage is provided using Amazon Elastic Block Store (Amazon EBS) volumes.

The default 8 GiB gp3 volume is sufficient for this web server.

Step 5: Configure User Data

Next, I expanded the Advanced Details section.

Inside the User Data box, I pasted the script provided in the lab guide.

This script automatically installs:

• Apache Web Server
• PHP
• MariaDB packages

It also downloads the lab application and starts the Apache web server.

After reviewing all settings, I clicked Launch Instance.

Understanding User Data

User Data is a script that runs automatically the first time an EC2 instance starts.

Instead of manually installing software after launching the server, AWS executes the script automatically.

In this lab, the script:

• Installed Apache
• Installed PHP
• Installed MariaDB packages
• Downloaded the lab web application
• Started the web server automatically

This process is known as bootstrapping because the instance is configured automatically during startup.

Step 6: Launch the EC2 Instance

After reviewing all the instance configurations, I clicked Launch Instance.

AWS started creating the EC2 instance using the selected configurations. A success message appeared indicating that the instance had been launched successfully.

Next, I clicked View all instances to monitor the status of the newly created instance.

Step 7: Verify the Instance Status

On the Instances page, I located the instance named Web Server 1.

Initially, the instance was in the Pending state while AWS prepared the virtual machine.

I waited until the Status Check column displayed 2/2 checks passed, which confirmed that:

• The EC2 instance was running properly.
• The operating system had started successfully.
• The networking configuration was working correctly.

This process took a few minutes, and I refreshed the page periodically to check the latest status.

Understanding Status Checks

AWS automatically performs Status Checks on every EC2 instance after it is launched.

There are two status checks:

• System Status Check: Verifies that the underlying AWS infrastructure, such as hardware and networking, is functioning properly.
• Instance Status Check: Verifies that the operating system running inside the EC2 instance is functioning correctly.

When both checks display 2/2 checks passed, it indicates that the instance is healthy and ready for use.

Step 8: Access the Web Server

Once the instance was running successfully, I selected Web Server 1 from the Instances page.

From the Details tab, I copied the Public IPv4 DNS value assigned to the instance.

Next, I opened a new browser tab, pasted the copied Public DNS into the address bar, and pressed Enter.

The browser successfully displayed the sample web page containing the AWS logo along with instance metadata, confirming that the Apache web server had been installed and configured successfully.

Understanding Public IPv4 DNS

Every EC2 instance launched in a public subnet with a public IP address receives a Public IPv4 DNS.

This DNS name acts as a public address that users can enter in a web browser to access applications hosted on the EC2 instance.

Instead of remembering an IP address, users can simply use the DNS name provided by AWS.

Understanding the Final Architecture

At the end of this lab, the AWS environment consisted of the following components:

• One Amazon VPC
• Two Public Subnets
• Two Private Subnets
• One Internet Gateway
• One NAT Gateway
• Two Route Tables
• One Security Group
• One Amazon EC2 Instance running an Apache Web Server

These components worked together to provide a secure and scalable cloud network where the web server was accessible from the internet while private resources remained protected.

Key Learning Outcomes

By completing this lab, I gained practical experience in designing and deploying a secure AWS network. The main concepts I learned include:

• Creating a custom Amazon VPC from scratch.
• Configuring public and private subnets within a VPC.
• Understanding how CIDR blocks define IP address ranges.
• Using an Internet Gateway to provide internet access for public resources.
• Using a NAT Gateway to allow private resources to access the internet securely.
• Associating subnets with the appropriate route tables.
• Creating and configuring Security Groups to control network traffic.
• Launching an Amazon EC2 instance inside a custom VPC.
• Using User Data scripts to automatically install and configure software.
• Accessing a hosted web application using the Public IPv4 DNS of an EC2 instance.

Conclusion

In this lab, I successfully built a custom networking environment using Amazon VPC and deployed an EC2 instance configured as a web server. I learned how different networking components, such as subnets, route tables, Internet Gateways, NAT Gateways, and Security Groups, work together to create a secure and well-structured cloud infrastructure.

I also gained hands-on experience in launching an EC2 instance, automating server setup with a User Data script, and verifying the deployment by accessing the web application through its Public IPv4 DNS. This lab provided a strong foundation for understanding AWS networking and demonstrated how cloud resources can be securely deployed and managed within a custom VPC.