AWS VPC: Securely Subnetting with Private & Public Environments

My mission was to configure architecture for my team in a way that offered a private instance in a private subnet accessible to my team only.

First I went to VPCs in the AWS VPC Dashboard and selected create VPC (Image 1). I named the VPC “Private_VPC_LUIT,” and configured the CIDR to 10.0.0.0/16. Image 2 illustrates successful creation.

Image 1

Image 2

Next I created a public & private subnet. Images 3 to 6 shows the public subnet being made. The private subnet was the same process, still inside Private_VPC_LUIT, but with a CIDR of 10.0.2.0/24.

Image 3

Image 4

Image 5

Image 6 (confirmation of both subnets being created)

Now that the subnets were in place, I wanted to launch an EC2 instance in the private subnet with only a private IP address. Also I then wanted to create a bastion host in the public subnet with a public IP address. Lastly I wanted to successfully connect the private instance from the bastion host in the VPC. Below were the steps that brought all the interconnected together.

I created an internet gateway (Image 7)

Image 7

The new internet gateway was then attached to the VPC (Image 8).

Image 8

Then I created two new Route Tables, one for each subnet. Image 9 shows both were created (they are selected in blue).

Image 9

I then needed to edit the route tables to add the appropriate paths for each subnet. I clicked “Edit Routes” to add the paths suitable for each subnet, and added the internet gateway to the public route table only. NOTE: Avoid adding the internet gateway to the private subnet — the private subnet’s route table should only include SSH access from the public subnet, because the communication is meant to be internal (Image 10–12)

Image 10: Adding the internet gateway to the public route table

Image 11: Edit the subnet for the public subnet to be associated with the public route table

Image 12: Associating the private route table with the public subnet

I then needed to correctly configure my Network ACLs, which can be done in the Security section of the VPC Dashboard (Image 13 & 14)

Image 13: Creating Network Access Control List

Image 14: Opening SSH for the Private NACL

Then to complete the NACLs I ensured that I associated them with their respective subnets (Image 15 & 16)

Image 15: Ensuring Association of Private NACL to Private Subnet

Image 16: Ensuring Association of Public NACL to Public Subnet

Next, I wanted to enable the public subnet to communicate with the private subnet by creating a NAT Gateway from the NAT Gateways section of the VPC Dashboard (Image 17).

Image 17

I then allocated an Elastic IP Address (Image 18), then associated it accordingly, and Image 19 shows confirmation.

Image 18: EIP allocated successfully

Image 19: Confirmation of association

Security Groups then needs configuring. Again from the VPC Dashboard, I went to Security Groups under Security in the same section as NACLs. Note: Inbound and outbound rules are meant to mirror the rules for the route tables and NACL’s. Image 20 & 21 show the respective Security Groups.

Image 20: Security Group for the Bastion Group.

Image 21: Security Group for the Private Group.

It was now time to involve the actual EC2 instance (Image 22–25)

Image 22: Chose t2.micro

Image 23: Note the yellow box where I selected our VPC, and chose the public subnet.

Image 24: Review Instance & Launch

Image 25: Choose a private key and check the acknowledgement box which in this screenshot is unchecked

Then using the EC2 wizard I created the instance for the Private subnet. Note that for the only Port 22 shall be open as we are SSH’ing privately (Image 26)

Image 26

At this point the instances were running and the architecture was in place. Thanks for reading!