Phần 11: VPC và mạng trên cloud

Sau bài này bạn làm được: vẽ và giải thích diagram VPC ba tầng (public/private/DB); chọn đúng Security Group rule khi instance mới không reach được internet; giải thích tại sao VPC Peering cần CIDR không chồng.

VPC là gì

VPC (Virtual Private Cloud) là mạng ảo cô lập của bạn trong cloud. Bạn toàn quyền kiểm soát CIDR, subnet, routing table, firewall.

VPC: 10.0.0.0/16  (tối đa ~65K địa chỉ)
 │
 ├── Availability Zone A
 │    ├── public subnet:   10.0.1.0/24
 │    ├── private subnet:  10.0.2.0/24
 │    └── db subnet:       10.0.3.0/24
 │
 └── Availability Zone B
      ├── public subnet:   10.0.101.0/24
      ├── private subnet:  10.0.102.0/24
      └── db subnet:       10.0.103.0/24

Dùng nhiều AZ cho high availability — nếu một AZ chết, AZ kia vẫn sống.

Internet Gateway vs NAT Gateway

Internet Gateway (IGW):

Cho phép instance có public IP vào/ra internet trực tiếp (hai chiều).
Gắn vào VPC, không gắn vào subnet.
Subnet có route 0.0.0.0/0 → igw-xxx được gọi là public subnet.

NAT Gateway:

Instance private (chỉ có private IP) ra internet outbound only.
Đặt trong public subnet; instance private subnet route 0.0.0.0/0 → nat-xxx.
Internet không thể khởi tạo kết nối vào instance private.

[Internet]
     │
     ▼
[Internet Gateway]
     │
     ▼
[Public Subnet: 10.0.1.0/24]
  ├── Bastion host (có public IP)
  └── NAT Gateway (dùng Elastic IP)
           │  outbound only
           ▼
[Private Subnet: 10.0.2.0/24]
  ├── App servers (chỉ có private IP)
  └── K8s worker nodes
           │  kết nối DB
           ▼
[DB Subnet: 10.0.3.0/24]
  └── RDS PostgreSQL (không có route ra internet)

Routing table — ai route đến đâu

Mỗi subnet gắn với một routing table:

Public subnet routing table:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	igw-xxx (Internet Gateway)

Private subnet routing table:

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	nat-xxx (NAT Gateway)

DB subnet routing table:

Destination	Target
10.0.0.0/16	local
(không có route ra internet)	—

Security Group vs NACL

	Security Group	NACL
Level	Instance (ENI)	Subnet
Stateful	Có (reply tự động pass)	Không (cần rule inbound + outbound)
Rule	Chỉ ALLOW	ALLOW và DENY
Áp dụng	Khi tạo/gắn EC2, RDS, ENI	Tất cả traffic vào/ra subnet

Security Group thực dụng:

# SG cho app server
Inbound:
  - TCP 443 from 0.0.0.0/0 (HTTPS)
  - TCP 80  from 0.0.0.0/0 (HTTP, redirect)
  - TCP 22  from sg-bastion  (SSH chỉ từ bastion SG)

Outbound:
  - All traffic 0.0.0.0/0 (out mặc định cho outbound)

# SG cho RDS
Inbound:
  - TCP 5432 from sg-app-server (chỉ app server mới vào được)

Outbound:
  - (thường để mặc định: allow all)

Sai lầm phổ biến:

Mở cổng DB ra 0.0.0.0/0 — không bao giờ làm vậy.
Quên outbound rule khi bật “deny all outbound” trong NACL.
SG tham chiếu nhau (SG-A from SG-B) không hoạt động cross-account.

VPC Peering — kết nối hai VPC

Peering cho phép hai VPC nói chuyện qua private IP như thể cùng mạng:

VPC A: 10.0.0.0/16 ←── Peering ───▶ VPC B: 10.1.0.0/16

Yêu cầu:

CIDR không chồng lấp — nếu chồng, peering sẽ fail hoặc routing sai.
Phải thêm route ở cả hai phía routing table.
Security Group phải cho phép traffic từ CIDR của VPC kia.

Lưu ý: Peering không transitive. Nếu A ↔ B và B ↔ C, A không tự reach được C qua B. Cần A ↔ C peering riêng, hoặc dùng Transit Gateway.

Transit Gateway — khi peering không đủ

Với 5+ VPC (prod, staging, data, shared-services, DMZ…), peering thành mạng lưới phẳng N×N — khó quản. Transit Gateway (TGW) đóng vai hub:

         [Transit Gateway]
        /       |        \
    [VPC A]  [VPC B]  [VPC C]  [VPC shared: prod-tools]

Ưu điểm: định tuyến tập trung, route table attach tuỳ ý, hỗ trợ VPN site-to-site và Direct Connect chung; có thể segmentation bằng TGW route table (prod không được gọi dev dù cùng hub).

Chi phí: TGW tính tiền theo giờ mỗi attachment và per-GB traffic — ở quy mô nhỏ (2–3 VPC) peering vẫn rẻ hơn đáng kể. Tính theo $0.05/h/attach + $0.02/GB (AWS us-east-1, 2025) trước khi chọn.

GCP có tương đương là Network Connectivity Center, Azure có Virtual WAN hoặc Azure Route Server.

PrivateLink / Private Service Connect — service private không qua internet

Vấn đề: app trong VPC cần gọi service bên ngoài (RDS ở VPC khác, SaaS, API của partner) mà không đi qua internet dù đích là IP public.

PrivateLink (AWS) / Private Service Connect (GCP) / Private Link (Azure) tạo endpoint trong VPC của bạn dẫn thẳng tới service ở VPC khác qua backbone cloud provider:

[App VPC]
   │ vpce-xxx (VPC Endpoint: privatelink)
   ▼
[Service VPC của Stripe / Snowflake / nội bộ team khác]

Ưu điểm so với peering/TGW:

Không cần nhớ CIDR bên kia; không sợ CIDR trùng.
Traffic một chiều (consumer → provider) — không mở route ngược.
Quyền truy cập quản lý ở mức service resource, không phải IP.

Use case: share database cross-account, expose internal service cho team khác mà không muốn họ reach VPC của bạn.

IPv6 và dual-stack

Nhu cầu IPv6 tăng mạnh từ 2024:

AWS tính phí $0.005/giờ mỗi public IPv4 từ 2/2024 — chi phí EC2 fleet có public IP có thể tăng đáng kể.
Subnet cloud ngày nay hỗ trợ dual-stack (IPv4 + IPv6) hoặc IPv6-only cho EKS/GKE worker.

Khi dùng IPv6-only subnet:

Thay NAT Gateway bằng Egress-only Internet Gateway (AWS) — rẻ hơn nhiều.
Cần kiểm tra toolchain (AMI, agent, library) tương thích IPv6.
Cloud LB (ALB, NLB) hỗ trợ dual-stack; client không có IPv6 vẫn vào qua IPv4 của LB.

Với K8s: cluster mode dual-stack tự gán cả Pod IPv4 và IPv6; NetworkPolicy phải viết cho cả hai family.

Tóm tắt

IGW cho public subnet (vào/ra internet); NAT cho private subnet (chỉ ra).
Thiết kế 3 tầng subnet (public/private/DB) là best practice cơ bản.
Security Group là firewall chính — stateful, dễ dùng; NACL là lớp thêm cho subnet.
VPC Peering cần CIDR không chồng và route ở cả hai phía.

Câu hỏi hay gặp

EC2 private subnet cần `yum/apt` ra internet — thiếu gì sẽ fail?

Trả lời: Route 0.0.0.0/0 tới NAT Gateway (và NAT có route ra IGW), SG/NACL cho phép egress — private subnet không gắn public IP trực tiếp.

Hai VPC cùng CIDR `10.0.0.0/16` — peering được không?

Trả lời: Không peering được (định tuyến chồng). Giải pháp: đổi CIDR một bên, hoặc TGW + network segmentation / tái thiết kế, tùy kiến trúc.

RDS chỉ cho `sg-app` mà app đổi sang `sg-app-v2` — kết nối DB còn không?

Trả lời: Không cho đến khi cập nhật inbound rule RDS (hoặc rule tham chiếu SG mới). SG tham chiếu theo ID SG, đổi SG trên EC2 không tự cập nhật rule phía RDS.

Bài tiếp theo (Giai đoạn IV): Load balancer và health check — sau khi có mạng cloud, LB là cửa ngõ nhận traffic production.