Building a Secure and Scalable AWS Network Using VPCs, Subnets, and Routing Controls

Overview

This project involved the design and deployment of an isolated, multi‑VPC network architecture on AWS to enable controlled, secure communication between environments. The goal was to simulate a scalable enterprise network topology, leveraging Amazon VPC, subnet segmentation, and peering to ensure efficient routing and traffic separation.

The Challenge

The task was to create two independent network environments that could operate autonomously while still allowing selective, secure interconnectivity. This setup reflects a common enterprise requirement: multiple business units or workloads needing isolated networks with controlled communication paths for data exchange, migration, or shared services.

The Approach

The solution was structured around AWS’s Virtual Private Cloud service to provision dedicated IP spaces, segment them into public and private subnets, and establish routing controls via VPC peering. Each decision was guided by principles of network isolation, least privilege access, and future scalability.

Tools Used

• AWS Management Console – for provisioning and configuration
• Amazon VPC – for network creation and segmentation

The Execution

1. The process began with creating the first Virtual Private Cloud (VPC‑A) through the AWS VPC Wizard, assigning it the CIDR block 10.10.0.0/16 to provide a large, contiguous private address range suitable for internal workloads.
2. Immediately after, a second VPC (VPC‑B) was provisioned with the CIDR block 10.20.0.0/16, ensuring there was no IP overlap, a prerequisite for successful peering and clean routing between environments.

1. Within VPC‑A, a public subnet was manually created using 10.10.1.0/24, intended to host internet‑facing resources, and a private subnet using 10.10.2.0/24 for workloads requiring isolation from direct internet exposure.

   

2. VPC‑B was similarly segmented, with a public subnet 10.20.1.0/24 for any future external services and a private subnet 10.20.2.0/24 for sensitive systems, aligning both VPCs with a consistent, scalable subnetting model.

   

3. With the core networks established, a VPC peering request was initiated from VPC‑A to VPC‑B through the VPC peering section in the AWS console, a step necessary to open a secure, private path for inter‑VPC traffic.

4. On the VPC‑B side, the pending request was manually accepted, formally establishing the peering connection and allowing each VPC to reference the other’s CIDR block for routing.

   

5. The final configuration step involved modifying route tables: in VPC‑A’s route table, a new entry was added directing all traffic for 10.20.0.0/16 to the peering connection, ensuring requests to VPC‑B could find their destination.