Build a Secure AWS VPC with Public and Private Subnets

In this hands-on AWS networking project, I created a custom Virtual Private Cloud (VPC) with public and private subnets, an Internet Gateway, route tables, and security groups. I also deployed EC2 instances to demonstrate secure connectivity between a public web server and a private application server.

Charan Teja

Published Oct 4, 2026

Last modified Oct 4, 2026

Architecture diagram

Replace your current architecture code block with this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
                         Internet
                            |
                    Internet Gateway
                            |
              Public Route Table
              0.0.0.0/0 → IGW
                            |
     ------------------------------------------------
     |               charan-vpc                     |
     |               10.0.0.0/16                    |
     |                                              |
     |  Public Subnet: 10.0.1.0/24                  |
     |  ┌────────────────────────────────────────┐  |
     |  | EC2 Web Server                         |  |
     |  | Public IPv4 enabled                    |  |
     |  | Security Group: web-server-sg          |  |
     |  | HTTP: 80 from 0.0.0.0/0                |  |
     |  | SSH: 22 from My IP only                |  |
     |  └────────────────────────────────────────┘  |
     |                    |                         |
     |                    | Private VPC traffic     |
     |                    v                         |
     |  Private Subnet: 10.0.2.0/24                 |
     |  ┌────────────────────────────────────────┐  |
     |  | EC2 Private Application Server         |  |
     |  | No public IPv4 address                 |  |
     |  | Security Group: private-server-sg      |  |
     |  | SSH: 22 only from web-server-sg        |  |
     |  └────────────────────────────────────────┘  |
     |                                              |
     ------------------------------------------------

Important corrections

1. Fix the Apache commands

Your current code block appears broken because the editor separated commands into individual tokens. Use this exact block for Amazon Linux 2023:

1
2
3
4
sudo dnf update -y
sudo dnf install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd

Then create the page:

1
echo "<h1>VPC Project: Public Web Server is Running</h1>" | sudo tee /var/www/html/index.html

Check whether Apache is running:

1
sudo systemctl status httpd

2. Correct the private-server SSH test

This command works only when the .pem private key file is actually copied to the public EC2 instance:

1
ssh -i my-key.pem ec2-user@10.0.2.x

But copying private keys between servers is not recommended. For a better portfolio project, write this instead:

For production environments, avoid copying private key files to a bastion or web server. Use AWS Systems Manager Session Manager, EC2 Instance Connect Endpoint, or a hardened bastion host with restricted access.

For your beginner demo, you can test internal connectivity without SSH:

1
ping 10.0.2.x

Or, if SSH must be demonstrated, explain clearly that it is a learning-only test and remove the key file after testing.

3. Explain the private route table correctly

Your sentence is almost correct but can be stronger:

The private route table contains the default local route for communication inside the VPC. It has no 0.0.0.0/0 route to an Internet Gateway, so workloads in the private subnet cannot initiate or receive direct internet traffic. In a production design, a NAT Gateway in a public subnet could be added to allow private instances to download updates without accepting inbound connections from the internet.

AWS notes that a VPC needs related resources—including subnets, route tables, and gateways—before you can deploy resources in it.

Improved article sections

Paste these sections toward the end of your AWS Builder article.

What I learned

This project helped me understand that a “public subnet” is not created by name alone. A subnet is considered public when its route table includes a route to an Internet Gateway and the workload has a public IPv4 address or another valid path for internet communication.I also learned that security groups and route tables solve different problems:* Route tables decide where network traffic is sent.
Security groups decide which traffic is allowed to reach an EC2 instance.
An Internet Gateway provides a path between the VPC and the internet.
Private subnets protect internal servers by removing direct public addressing and internet-facing routes.

Validation checklist

I verified the deployment using the following checklist:* Confirmed that charan-vpc was created with CIDR block 10.0.0.0/16.
Confirmed that the public subnet was associated with charan-public-rt.
Confirmed that charan-public-rt included 0.0.0.0/0 pointing to charan-igw.
Confirmed that the public EC2 instance received a public IPv4 address.
Confirmed that the Apache test page opened using the public IPv4 address of the web server.
Confirmed that SSH access to the web server was restricted to my own public IP address.
Confirmed that the private EC2 instance did not receive a public IPv4 address.
Confirmed that the private server’s security group allowed SSH only from web-server-sg.

Future enhancements

To evolve this project into a production-style architecture, I would:* Add a NAT Gateway so private instances can access package repositories and updates without being directly reachable from the internet.
Create subnets in at least two Availability Zones for higher availability.
Add an Application Load Balancer in public subnets.
Move the application server into private subnets behind the load balancer.
Deploy Amazon RDS in private database subnets.
Enable VPC Flow Logs and send them to Amazon CloudWatch Logs for network monitoring and troubleshooting.
Manage the whole infrastructure using Terraform, AWS CloudFormation, or AWS CDK.
Use AWS Systems Manager Session Manager instead of opening inbound SSH access.

Tags to select

Use up to five relevant tags:

Amazon VPC
AWS Networking
Amazon EC2
Cloud Security
AWS Projects

Cover image idea

Create or upload a simple 1200 × 675 image showing:

1
Internet → Internet Gateway → Public Subnet → Private Subnet

Use AWS-style icons for VPC, EC2, Internet Gateway, and security groups. Avoid placing lots of text on the image, because Builder Center recommends minimal text in cover images.

Publishing checklist

Use the corrected Apache code blocks.
Ensure there are no actual public IP addresses, AWS account IDs, private key contents, or screenshots exposing credentials.
Use real screenshots of your VPC resource map, route tables, EC2 instances, and successful Apache page if you have them.
Make clear which parts you personally deployed and tested.
Delete EC2 instances, Internet Gateway, route tables, subnets, and the VPC after testing to avoid charges.
Add a final line such as: “This project was built and tested by me as part of my AWS cloud networking learning journey.”

Your selected design—one custom VPC, a public subnet, a private subnet, Internet Gateway, custom route tables, security groups, and two EC2 instances—is a very good beginner-to-intermediate AWS portfolio project because it shows practical networking, security, and deployment understanding.

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article