Skip to main content

Command Palette

Search for a command to run...

AWS Network Architecture Deployment Documentation

Attempting to Build AWS Architecture from a Diagram

Updated
4 min read
AWS Network Architecture Deployment Documentation

AWS Network Diagram

The AWS network diagram illustrates the setup of a Virtual Private Cloud (VPC) with public and private subnets in a single Availability Zone (AZ). It includes the creation of EC2 instances, route tables, an Internet Gateway, and a NAT Gateway, ensuring secure communication between the instances within the VPC and external services.

Converting Diagram into AWS Network

Creating Virtual Private Cloud

I configured the IPv4 CIDR block for the VPC as 10.0.0.0/16, which provides 65,536 IP addresses to accommodate the network.

The first VPC is the default VPC.

Creating Subnets

I selected the newly created VPC (new-vpc) for subnet creation.

For the first subnet, I created a PublicSubnet in Availability Zone eu-west-2a, with an IPv4 CIDR block of 10.0.0.0/24 (within the VPC CIDR block).

I will create a PrivateSubnet in the same Availability Zone (AZ) of eu-west-2a. While it's typically recommended to distribute public and private subnets across different AZs for high availability, I will use a single AZ for simplicity in this setup. Since the 10.0.0.0/24 block is already assigned to the PublicSubnet, I will use 10.0.1.0/24 for the PrivateSubnet, which still falls within the VPC's CIDR block.

Launching a Public EC2 Instance

I launched a new EC2 instance called PublicInstance, selecting the default AMI and the t2.micro instance type, which is free-tier eligible.

A new key pair, my-key-pair, was created to allow SSH access to the instance.

I edited the network settings to deploy PublicInstance in the PublicSubnet, assigned a public IP, and used the default security group (PublicSecurityGroup).

Creating an Internet Gateway

An Internet Gateway was created and attached to the VPC to enable internet access for public instances.

Creating Route Tables

The default route table allows communication between Public and Private subnets by default, as indicated by the local route.

Explicit subnet associations are required for both the Public and Private Route Tables.

Here, I associated the PublicSubnet with the PublicRouteTable.

Next, I associated the PrivateSubnet with the PrivateRouteTable.

The route tables have been successfully associated with the respective subnets.

Allowing Route to Internet Gateway

I added a route to the PublicRouteTable with 0.0.0.0/0 targeting the Internet Gateway. This allows PublicInstance to connect to the internet.

Connecting via EC2 Instance Connect

I tested the internet connection by running sudo yum update -y, and it successfully connected, confirming the internet route is working.

Launching a Private EC2 Instance

I launched a new EC2 instance named PrivateInstance with default settings, using the existing my-key-pair key pair for SSH access.

The instance was placed in the PrivateSubnet without a public IP, and the default PrivateSecurityGroup was used.

Using SCP, I uploaded the key pair to PublicInstance to enable SSH access to the PrivateInstance.

The key pair is successfully uploaded to the PublicInstance.

I confirmed that I can access PrivateInstance since traffic is allowed between the two subnets by default. However, the PrivateInstance does not have internet access.

Attempting to run sudo yum update -y on PrivateInstance failed as there is no internet access.

Creating a NAT Gateway

I created a NAT Gateway in the PublicSubnet, which allows instances in private subnets to access the internet without allowing external services to initiate connections. The NAT Gateway was allocated an Elastic IP.

Important: Remember to release Elastic IP addresses once you finish using them, as idle Elastic IP incurs charges.

Adding Route to NAT Gateway

I added a route in the PrivateRouteTable, setting 0.0.0.0/0 as the destination and the newly created NAT Gateway as the target.

This allows PrivateInstance to access the internet through the NAT Gateway, while external services cannot initiate a connection with it.

Conclusion

This AWS setup provides a solid network architecture with proper segmentation between public and private subnets. By leveraging Network Access Control Lists (NACLs), additional security layers are added to restrict or allow traffic at the subnet level, offering more control over inbound and outbound traffic. This ensures a secure and organized VPC setup with controlled access to and from the internet for both public and private resources.