> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ahmadraza.in/llms.txt
> Use this file to discover all available pages before exploring further.

# 3 Layer VPC

# **Production-Grade 3-Layer AWS VPC Blueprint – Mumbai (ap-south-1)**

This guide provides a **full production-ready blueprint** for a **3-layer custom AWS VPC** architecture in **ap-south-1 (Mumbai)**. It follows best practices for **high availability, security, and scalability**, leveraging **three Availability Zones (AZs)** for resilience against single-AZ failures.

The architecture separates **Web, Application, and Data layers** into distinct subnets, ensuring **layered security, efficient routing, and scalability**.

***

## **1. VPC and Subnet Planning**

A **large /16 CIDR block** is recommended for the VPC to accommodate future growth. Each subnet should be allocated a **/24 block**, providing 251 usable IPs per subnet.

**AWS Region:** ap-south-1 (Mumbai)
**Availability Zones:** ap-south-1a, ap-south-1b, ap-south-1c
**VPC CIDR Block:** `10.10.0.0/16`

### **Subnet Allocation Table**

| Layer                 | Subnet Type | AZ          | CIDR Block    | Usable IPs | Primary Function                        |
| --------------------- | ----------- | ----------- | ------------- | ---------- | --------------------------------------- |
| **Web Tier (Public)** | Public      | ap-south-1a | 10.10.1.0/24  | 251        | ALB, NAT, Bastion Host                  |
|                       | Public      | ap-south-1b | 10.10.2.0/24  | 251        | ALB, NAT                                |
|                       | Public      | ap-south-1c | 10.10.3.0/24  | 251        | ALB, NAT                                |
| **Application Tier**  | Private     | ap-south-1a | 10.10.10.0/24 | 251        | EC2, EKS Nodes, Internal Load Balancers |
|                       | Private     | ap-south-1b | 10.10.11.0/24 | 251        | EC2, EKS Nodes, Internal Load Balancers |
|                       | Private     | ap-south-1c | 10.10.12.0/24 | 251        | EC2, EKS Nodes, Internal Load Balancers |
| **Data Tier**         | Private     | ap-south-1a | 10.10.20.0/24 | 251        | RDS, ElastiCache, EFS, S3 VPC Endpoints |
|                       | Private     | ap-south-1b | 10.10.21.0/24 | 251        | RDS Standby/Read Replica, Storage       |
|                       | Private     | ap-south-1c | 10.10.22.0/24 | 251        | RDS Read Replica, Storage               |

***

## **2. Core VPC Components**

### **2.1 Create the VPC**

* Create a new VPC in **ap-south-1** with CIDR `10.10.0.0/16`.
* **Enable DNS hostnames and DNS resolution** for internal service discovery.

### **2.2 Create Subnets**

* Create **9 subnets** across 3 AZs, as per the table above.
* Enable **auto-assign public IPv4 addresses** for the **Web Tier subnets** for NAT Gateways and Bastion Hosts.

### **2.3 Internet Gateway (IGW)**

* Create an **Internet Gateway** and attach it to the VPC.
* This enables public internet access for the **Web Tier**.

### **2.4 NAT Gateways**

* Deploy **one NAT Gateway per AZ** for high availability and to avoid cross-AZ data transfer costs.
* Allocate **3 Elastic IPs**, one for each NAT Gateway in **Web Tier subnets**:

  * 10.10.1.0/24 → AZ1 NAT
  * 10.10.2.0/24 → AZ2 NAT
  * 10.10.3.0/24 → AZ3 NAT

### **2.5 Route Tables**

* Define routes for **public and private subnets**:

| Route Table      | Associated Subnets   | Default Route (`0.0.0.0/0`) |
| ---------------- | -------------------- | --------------------------- |
| Public RT        | Web Tier (all AZs)   | Internet Gateway (IGW)      |
| Private RT-AZ-1a | App & Data Tier (1a) | NAT Gateway AZ-1a           |
| Private RT-AZ-1b | App & Data Tier (1b) | NAT Gateway AZ-1b           |
| Private RT-AZ-1c | App & Data Tier (1c) | NAT Gateway AZ-1c           |

**Setup Steps:**

1. **Public RT:** Attach to all Web Tier subnets. Add route to IGW.
2. **Private RTs:** Create three, one per AZ. Add default route to NAT Gateway in the same AZ. Associate each with corresponding App/Data Tier subnets.

***

## **3. Resource Deployment & Traffic Flow**

| Layer                | Resources                                       | Connectivity                                                     | Security Focus                                                                        |
| -------------------- | ----------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| **Web Tier**         | Internet-facing ALB, NAT, Bastion Host          | Inbound: Internet → ALB; Outbound: Direct → IGW                  | Security Groups: Allow HTTP/HTTPS from Internet, SSH to Bastion only from trusted IPs |
| **Application Tier** | EC2, EKS nodes, Internal ALB/NLB, CI/CD agents  | Inbound: From Web Tier ALB; Outbound: NAT Gateway                | SG: Allow inbound from Web Tier only; deny public ingress                             |
| **Data Tier**        | RDS Multi-AZ, ElastiCache, EFS/S3 VPC Endpoints | Inbound: From App Tier only; Outbound: NAT Gateway (if required) | SG: Allow inbound only from App Tier; no public IPs or internet access                |

### **Key Production Configurations**

* **Load Balancers:**

  * **Internet-facing ALB:** Placed in Web Tier subnets, routes traffic to App Tier instances.
  * **Internal ALB (optional):** For microservice-to-microservice communication in App Tier.
* **Databases (RDS):**

  * Use all Data Tier subnets for **DB Subnet Group**.
  * Enable **Multi-AZ deployment**. Set **Public accessibility = No**.
* **Security Groups & NACLs:**

  * Implement **SGs per tier**. Web → App → DB flow.
  * Use **NACLs** as a stateless, redundant firewall layer.
* **VPC Endpoints:**

  * Add **S3/DynamoDB Gateway Endpoints** and **ECR/CloudWatch Interface Endpoints** to reduce NAT traffic and improve security.
* **Administration:**

  * Use a single **Bastion Host** or **AWS Systems Manager Session Manager** in Web Tier for secure access to private subnets.
  * Restrict SSH/RDP access to trusted IP ranges only.

***

✅ This setup ensures **high availability**, **tiered security**, and **scalable architecture**, ready for **production workloads**, **EKS clusters**, **multi-AZ RDS**, and **secure internet connectivity**.

***