Ngôn ngữ hiển thị:
ChatBot AINgôn ngữ hiển thị:
ChatBot AIHồi mới học AWS, mình đã từng deploy một ứng dụng Node.js với RDS MySQL. Tất cả chạy ngon lành, khách hàng dùng được, mình vui lắm. Cho đến một ngày, mình chạy thử một port scanner thì... database port 3306 của mình mở toác ra ngoài Internet. Bất kỳ ai cũng có thể thử brute-force vào đó. Lạnh cả người. Đó là lúc mình bắt đầu học nghiêm túc về VPC Subnets.
Hãy tưởng tượng VPC (Virtual Private Cloud) của bạn là một tòa nhà văn phòng. Trong tòa nhà đó, bạn có hai khu vực:
Public Subnet giống như tầng trệt có lễ tân — ai từ ngoài đường cũng có thể bước vào, gặp nhân viên lễ tân, gửi thư, nhận hàng. Đây là nơi bạn đặt những thứ cần giao tiếp trực tiếp với Internet: web server, load balancer, bastion host.
Private Subnet giống như các tầng văn phòng bên trên — khách bên ngoài không thể tự lên đó được. Chỉ nhân viên nội bộ (hoặc người được lễ tân dẫn lên) mới vào được. Đây là nơi bạn đặt database, backend service, bất kỳ thứ gì không cần expose ra Internet.
Sự khác biệt kỹ thuật cốt lõi nằm ở Route Table: Public Subnet có route 0.0.0.0/0 trỏ tới Internet Gateway (IGW), còn Private Subnet thì không. Đơn giản vậy thôi, nhưng ý nghĩa bảo mật khổng lồ.
Hiểu lý thuyết rồi, nhưng áp dụng vào thực tế thế nào? Đây là các use case điển hình:
Mình sẽ hướng dẫn bạn tạo một VPC chuẩn với 2 loại subnet trong cùng một Availability Zone. Trong production, bạn nên nhân đôi cho ít nhất 2 AZ để high availability.
Bước 1: Tạo VPC
Vào AWS Console → VPC → Create VPC. Điền:
my-app-vpc10.0.0.0/16 (cho phép tới 65,536 địa chỉ IP)Bước 2: Tạo Public Subnet
VPC → Subnets → Create Subnet:
my-app-vpcpublic-subnet-1aap-southeast-1a10.0.1.0/24 (256 địa chỉ)Sau khi tạo xong, chọn subnet → Actions → Edit subnet settings → tick Enable auto-assign public IPv4 address. Bước này quan trọng — instance trong public subnet mới tự nhận public IP.
Bước 3: Tạo Private Subnet
private-subnet-1aap-southeast-1a10.0.2.0/24Không enable auto-assign public IP cho private subnet.
Bước 4: Tạo và gắn Internet Gateway
VPC → Internet Gateways → Create IGW → đặt tên my-app-igw → Attach to VPC → chọn my-app-vpc.
Bước 5: Cấu hình Route Table cho Public Subnet
VPC → Route Tables → Create route table:
public-rtmy-app-vpcChọn public-rt → tab Routes → Edit routes → Add route:
0.0.0.0/0my-app-igwSau đó → tab Subnet associations → Edit → chọn public-subnet-1a.
Bước 6: NAT Gateway cho Private Subnet (nếu cần)
Private Subnet không có đường ra Internet, nhưng đôi khi instance bên trong cần download package, gọi API bên ngoài. Lúc đó dùng NAT Gateway:
VPC → NAT Gateways → Create NAT Gateway:
Tạo Route Table riêng cho private subnet (private-rt), thêm route 0.0.0.0/0 → NAT Gateway, rồi associate với private-subnet-1a.
Mẹo xương máu: NAT Gateway tính phí theo giờ (~$0.045/giờ ở Singapore region) cộng thêm phí data transfer. Nếu bạn chỉ cần private instance download package lúc setup, hãy tạo NAT Gateway tạm, xong việc thì xóa đi. Quên xóa là mất ~$32/tháng cho một NAT Gateway chạy không.
Sau vài năm làm việc với VPC, đây là những lỗi mình thấy nhiều nhất:
Lỗi 1: Đặt database trong Public Subnet. Nhiều người làm vậy cho "tiện debug", rồi quên mất. Database không bao giờ cần public IP. Nếu cần kết nối từ máy local để debug, dùng SSH tunnel qua bastion host hoặc AWS Systems Manager Session Manager — không cần mở port 3306/5432 ra Internet.
Lỗi 2: Security Group quá rộng trên Private Subnet. Để subnet là private chưa đủ. Bạn còn cần Security Group của RDS chỉ chấp nhận kết nối từ Security Group của EC2 application, không phải từ 0.0.0.0/0. Hai lớp bảo vệ tốt hơn một.
Lỗi 3: Dùng chung một Route Table cho cả public và private subnet. Mình thấy người mới hay nhầm điều này. Main route table của VPC thường không có route IGW — tốt. Nhưng nếu bạn "tiện tay" gắn cả hai subnet vào public-rt thì private subnet của bạn thực ra đã public rồi đấy.
Q: Instance trong Private Subnet có thể gọi AWS services như S3, DynamoDB không?A: Có, nhưng có 2 cách. Cách 1: qua NAT Gateway (traffic ra Internet rồi vào lại AWS — tốn phí data transfer). Cách 2 tốt hơn: dùng VPC Endpoint — kết nối thẳng từ VPC tới service AWS mà không qua Internet, rẻ hơn và nhanh hơn. Với S3 và DynamoDB, dùng Gateway Endpoint miễn phí. Với các service khác dùng Interface Endpoint (có phí nhỏ).
Q: Tôi có thể có bao nhiêu subnet trong một VPC?A: Mặc định AWS cho tối đa 200 subnet/VPC. Trong thực tế kiến trúc chuẩn thường dùng: 1 public + 1 private/AZ, nhân với số AZ. Ví dụ Singapore region có 3 AZ → 6 subnet tối thiểu. Nên tạo sẵn đủ AZ từ đầu vì resize CIDR sau này rất phức tạp.
Q: NAT Gateway vs NAT Instance: cái nào tốt hơn?A: NAT Gateway của AWS managed hoàn toàn, tự scale, không cần patch. NAT Instance là EC2 tự cài, rẻ hơn (t3.nano ~$3/tháng vs NAT Gateway ~$32/tháng) nhưng bạn phải tự quản lý, tự scale, có single point of failure. Cho production workload quan trọng: NAT Gateway. Cho môi trường dev/test tiết kiệm chi phí: NAT Instance hoặc xóa đi khi không dùng.
Public Subnet và Private Subnet không chỉ là khái niệm lý thuyết trong AWS exam. Đây là nền tảng của mọi kiến trúc cloud production nghiêm túc. Mình đã từng thấy startups bị pentest xong phát hiện database expose ra Internet từ ngày đầu launch — chi phí để fix không chỉ là kỹ thuật, mà còn là niềm tin của khách hàng.
Khi bạn đã nắm vững subnet, bước tiếp theo là đi sâu vào Security Groups và Network ACLs — hai lớp tường lửa bổ sung cho nhau trong VPC. Mình sẽ viết chi tiết về chủ đề đó trong bài tới của series AWS này.
