Basic AWS Network Architecture Deployment
Attempting to Build AWS Architecture from a Diagram
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
The IPv4 CIDR block for the VPC was configured as 10.0.0.0/16, which provides 65,536 IP addresses to accommodate the network.
The first VPC shown is the default VPC.
Creating Subnets
The newly created VPC (new-vpc) was selected for subnet creation.
For the first subnet, a PublicSubnet was created in Availability Zone eu-west-2a, with an IPv4 CIDR block of 10.0.0.0/24 (within the VPC CIDR block).
A PrivateSubnet was created 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, a single AZ was used here for simplicity. Since the 10.0.0.0/24 block was already assigned to the PublicSubnet, 10.0.1.0/24 was used for the PrivateSubnet, which still falls within the VPC's CIDR block.
Launching a Public EC2 Instance
A new EC2 instance called PublicInstance was launched, using 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.
The network settings were edited to deploy PublicInstance in the PublicSubnet, assign a public IP, and use 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, the PublicSubnet was associated with the PublicRouteTable.
Next, the PrivateSubnet was associated with the PrivateRouteTable.
The route tables have been successfully associated with the respective subnets.
Allowing Route to Internet Gateway
A route was added 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
The internet connection was tested by running sudo yum update -y, which succeeded, confirming the internet route was working.
Launching a Private EC2 Instance
A new EC2 instance named PrivateInstance was launched 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, using the default PrivateSecurityGroup.
Using SCP, the key pair was uploaded to PublicInstance to enable SSH access to the PrivateInstance.
The key pair was successfully uploaded to the PublicInstance.
Access to PrivateInstance was confirmed, 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, since there is no internet access.
Creating a NAT Gateway
A NAT Gateway was created in the PublicSubnet, allowing instances in private subnets to access the internet without allowing external services to initiate connections. The NAT Gateway was allocated an Elastic IP.
Adding Route to NAT Gateway
A route was added 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 organised VPC setup with controlled access to and from the internet for both public and private resources.
