# ✅ Day 11 of My Cloud Journey ☁ – AWS VPC Basics: Subnets, IGW & NAT Gateway Explained 🛡️🌐

Today I stepped into the **networking side of AWS** — learning about the backbone of secure and scalable cloud deployments: **Amazon VPC (Virtual Private Cloud)**.

Mastering networking in the cloud is essential for building production-ready, secure, and scalable architectures. Whether it's hosting a secure app, launching a database, or creating a multi-tier application — it all starts with VPC!

---

### 🔍 What is a VPC?

A **Virtual Private Cloud (VPC)** is a logically isolated network inside AWS that you define. You can control:

* IP address ranges (CIDR blocks)
    
* Subnets
    
* Route tables
    
* Internet access
    
* Firewalls
    
* Gateways
    

It’s like having your own **virtual data center** — where you can run resources (like EC2, RDS, Lambda) in a **highly secure and customizable environment**.

---

### 🧩 Core VPC Components I Explored Today:

#### 🔸 **1\. Subnets**

A **subnet** is a segment of a VPC's IP address range where you can place AWS resources. There are two types:

* **Public Subnet** – Connected to the internet via Internet Gateway.
    
* **Private Subnet** – No direct access to the internet (great for databases, backend services).
    

You can split your application architecture:

* Frontend in a **public subnet**
    
* Backend or DB in a **private subnet**
    

#### 🔸 **2\. Internet Gateway (IGW)**

An **Internet Gateway** enables instances in a public subnet to connect to the internet. Without it, your EC2 instances in public subnets cannot access or be accessed from the web.

✅ I attached an IGW to my VPC  
✅ Updated route tables to allow `0.0.0.0/0` access through IGW

#### 🔸 **3\. NAT Gateway**

A **NAT (Network Address Translation) Gateway** allows instances in **private subnets** to **access the internet** (for updates, packages) **without being exposed** to inbound internet traffic.

✅ I placed the NAT Gateway in a public subnet  
✅ Added a route in private subnet’s route table to point `0.0.0.0/0` to the NAT Gateway  
✅ Tested internet access from EC2 in private subnet → Worked perfectly!

---

### 💡 Why Use Public & Private Subnets?

Separating your application tiers into public and private subnets boosts security. For example:

* Web server (NGINX): Public subnet
    
* Database (MySQL/PostgreSQL): Private subnet
    
* Backend service: Private subnet
    
* NAT Gateway: Public subnet
    

This setup is the backbone of **multi-tier architecture**, where each layer is isolated and follows the **principle of least privilege**.

---

### 🛠 Hands-on Tasks I Completed:

1️⃣ Created a **custom VPC** with custom CIDR block  
2️⃣ Added **2 public** and **2 private subnets** across multiple availability zones  
3️⃣ Attached and configured an **Internet Gateway**  
4️⃣ Created a **NAT Gateway** in a public subnet  
5️⃣ Set up **custom route tables**  
6️⃣ Launched **EC2 instances** in both subnet types  
7️⃣ Connected via SSH and tested access/connectivity  
8️⃣ Verified internet access from private subnet via NAT

---

### 🧠 Key Learnings:

✅ How routing works between private/public subnets  
✅ Why NAT Gateway is essential for secure outbound traffic  
✅ How Internet Gateway enables global access to cloud servers  
✅ How to isolate workloads and restrict public access  
✅ Difference between **Security Groups** and **Route Tables**

---

### 🌍 Real-World Use Cases of VPC:

🔹 Host static or dynamic web apps with secure backends  
🔹 Run databases securely without internet exposure  
🔹 Set up secure hybrid networks with VPN or Direct Connect  
🔹 Create multi-tier application environments (frontend, backend, DB)  
🔹 Build isolated test environments or dev/staging infrastructure

---

### 🔐 Best Practices I Noted:

🔐 Keep all **critical services** (e.g., DB, APIs) in private subnets  
🔐 Enable **VPC Flow Logs** for monitoring and troubleshooting  
🔐 Use **IAM roles**, not hardcoded credentials  
🔐 Use **Security Groups** for instance-level security and **NACLs** for subnet-level  
🔐 Avoid assigning public IPs unnecessarily  
🔐 Use **multiple AZs** for high availability

---

### 📌 What’s Next?

🔄 **Tomorrow (Day 12):**  
I’ll dive deeper into:

* **Route Tables**
    
* **Security Groups vs NACLs**
    
* **VPC Peering** — how to connect multiple VPCs together
    

---

### 📸 Want Visuals?

🖼️ I’m also creating a visual diagram of my VPC layout and subnet routing — stay tuned on my LinkedIn!

🔗 **And here's a static portfolio site** I hosted earlier on **S3 + CloudFront** from Day 9:  
👉 [View Project on LinkedIn](https://www.linkedin.com/posts/pratik-das-a47493231_aws-s3-staticwebsite-activity-7341883681529053184-2cfO?utm_source=share&utm_medium=member_desktop)

---

### 🚀 Final Thoughts:

**AWS VPC is the network foundation for everything you build in the cloud.** It connects, isolates, secures, and scales your infrastructure. Without a strong grasp on VPC fundamentals, real-world cloud deployments can become a tangled mess.

This hands-on practice was crucial in understanding how everything works under the hood in cloud networking.

---

### 🏷️ Hashtags:

`#Day11 #30DaysOfCloud #AWS #VPC #Subnets #NATGateway #IGW #CloudNetworking #DevOps #LearnInPublic #Hashnode #TruptiMane #CloudSecurity #AWSBeginner #AmazonWebServices #CloudJourney`