ChatBot AI

Hồi mới học AWS, mình deploy một con EC2 chạy web, hí hửng nghĩ xong việc. Đến khi thêm database thì mentor hỏi: "Mày để RDS trong Public Subnet à? Ai cũng vào được đó!" — lúc đó mới ngớ ra. Mình đã để database hở ra ngoài Internet mà không hay. Đó là bài học đắt giá về AWS VPC mà mình muốn chia sẻ lại để bạn không mắc sai lầm tương tự.

AWS VPC là gì? Giải thích theo kiểu "tòa nhà văn phòng"

Hãy tưởng tượng AWS là một khu đô thị khổng lồ, mỗi khách hàng thuê một tòa nhà riêng — đó chính là VPC (Virtual Private Cloud). Bên trong tòa nhà đó, bạn toàn quyền quyết định: phòng nào để khách vào (Public Subnet), phòng nào chỉ nhân viên nội bộ được vào (Private Subnet), cửa bảo vệ kiểm soát ai ra vào (Security Group), và hệ thống khóa cửa tầng mạng (Network ACL).

Về mặt kỹ thuật, VPC là một mạng ảo riêng biệt được định nghĩa trong AWS, hoàn toàn tách biệt với các khách hàng khác dù cùng dùng chung phần cứng vật lý. Bạn tự định nghĩa dải IP (CIDR block, ví dụ 10.0.0.0/16), tự chia subnet, tự cấu hình routing và firewall.

Tại sao cần VPC? Vì mặc định, mọi resource trong cùng một VPC đều có thể "nói chuyện" với nhau qua mạng nội bộ với độ trễ cực thấp và không tốn phí transfer. Trong khi đó, traffic ra ngoài Internet thì tốn tiền và có rủi ro bảo mật. VPC giúp bạn kiểm soát chính xác resource nào được phép ra Internet, resource nào chỉ ở trong nội bộ.

Các thành phần cốt lõi của VPC bạn bắt buộc phải biết

Khi làm việc với VPC, bạn sẽ gặp đi gặp lại những thứ này:

CIDR Block: Dải địa chỉ IP của VPC. Thường dùng 10.0.0.0/16 cho phép tạo tối đa 65,536 địa chỉ IP. Chọn một lần rất khó thay đổi sau — hãy chọn rộng ngay từ đầu.
Subnet: Chia nhỏ VPC thành các vùng con. Public Subnet có thể truy cập Internet trực tiếp; Private Subnet thì không. Mỗi Subnet nằm trong một Availability Zone cụ thể.
Internet Gateway (IGW): "Cổng chính" nối VPC ra Internet. Một VPC chỉ có tối đa 1 IGW. Public Subnet cần route table trỏ về IGW mới ra được Internet.
NAT Gateway: Cho phép resource trong Private Subnet chủ động gọi ra Internet (ví dụ: download package) mà không để Internet gọi ngược vào. Tốn tiền theo giờ và theo dung lượng — đây là nguồn "đốt tiền" phổ biến.
Route Table: Bảng định tuyến quyết định traffic đi đâu. Public Subnet có route 0.0.0.0/0 → IGW; Private Subnet có route 0.0.0.0/0 → NAT Gateway.
Security Group: Firewall ở tầng instance (stateful). Bạn định nghĩa rule Inbound/Outbound. Mặc định chặn tất cả Inbound, cho phép tất cả Outbound.
Network ACL (NACL): Firewall ở tầng Subnet (stateless). Ít dùng hơn Security Group nhưng hiệu quả khi cần chặn IP cụ thể trên toàn Subnet.

Kiến trúc VPC chuẩn cho ứng dụng production

Kiến trúc AWS VPC với Public và Private Subnet

Một kiến trúc VPC "chuẩn chỉnh" cho web app thường trông như sau: VPC với CIDR 10.0.0.0/16, triển khai trên 2 Availability Zone để đảm bảo High Availability.

Tầng Public (DMZ) — gồm các Public Subnet 10.0.1.0/24 và 10.0.2.0/24: Đặt Application Load Balancer, Bastion Host (jump server để SSH vào private), và NAT Gateway. Những thứ này cần tiếp xúc trực tiếp với Internet.

Tầng Application (Private) — gồm Private Subnet 10.0.3.0/24 và 10.0.4.0/24: Đặt EC2 chạy backend API. Không có địa chỉ IP public. Ra Internet qua NAT Gateway. Chỉ nhận traffic từ Load Balancer.

Tầng Data (Isolated) — gồm Database Subnet 10.0.5.0/24 và 10.0.6.0/24: Đặt RDS, ElastiCache. Không có route ra Internet dù qua NAT. Chỉ app server mới được kết nối vào.

Mẹo thực chiến: Tạo riêng một "DB Subnet Group" trong AWS RDS chỉ gồm các Database Subnet. Điều này ép RDS chỉ được deploy vào vùng isolated, tránh tình trạng vô tình để DB vào Public Subnet.

Tạo VPC từ A-Z trên AWS Console

AWS cung cấp wizard "VPC and more" giúp tạo toàn bộ cấu trúc trong vài phút:

Vào VPC → Your VPCs → Create VPC. Chọn "VPC and more" (không phải "VPC only"). Điền CIDR 10.0.0.0/16, chọn 2 AZ, 2 Public Subnet, 2 Private Subnet, 1 NAT Gateway (per AZ hoặc In 1 AZ để tiết kiệm chi phí dev). AWS sẽ tự tạo Route Tables và gắn đúng cho từng Subnet.

Sau khi tạo VPC, việc gắn Security Group cho EC2:

# Tạo Security Group cho web server
# Inbound: port 80/443 từ 0.0.0.0/0 (public web)
# Inbound: port 22 chỉ từ IP của bạn (SSH)
# Outbound: All traffic (mặc định)

# Tạo Security Group cho database
# Inbound: port 3306 chỉ từ Security Group của web server
# Outbound: All traffic

Lưu ý: Security Group reference nhau theo ID, không theo IP — đây là tính năng mạnh nhất. Khi web server scale up/down, rule database tự động áp dụng cho instance mới mà không cần sửa.

Cạm bẫy phổ biến: NAT Gateway tính tiền $0.045/giờ + $0.045/GB data. Với môi trường dev không cần HA, dùng 1 NAT Gateway cho cả 2 AZ thay vì 2 NAT Gateway — tiết kiệm ~$33/tháng.

5 sai lầm VPC kinh điển mà dev hay mắc

Sau nhiều năm làm AWS, đây là những lỗi mình gặp nhiều nhất:

Để RDS trong Public Subnet: Database cần Internet để giao tiếp với app? Không — app và DB trong cùng VPC giao tiếp qua IP nội bộ. Database không bao giờ cần Public Subnet.
CIDR quá nhỏ: Dùng /24 (256 IP) cho VPC production rồi sau mở rộng không được, phải tạo lại từ đầu. Luôn dùng ít nhất /16.
Mở Security Group 0.0.0.0/0 cho SSH/RDP: Port 22 mở toàn cầu bị scanner tấn công liên tục. Dùng Bastion Host hoặc AWS Systems Manager Session Manager.
Quên xóa NAT Gateway khi không dùng: NAT Gateway tính tiền ngay cả khi không có traffic. Môi trường dev/staging nên xóa NAT Gateway khi về cuối ngày.
Không dùng VPC Flow Logs: Khi có sự cố bảo mật, bạn cần biết traffic nào đã đi qua. Enable VPC Flow Logs gửi về CloudWatch Logs — chi phí thấp nhưng giá trị forensics cao.

FAQ — Những câu hỏi thực tế nhất về VPC

Q: VPC mặc định (Default VPC) có dùng được cho production không?
A: Không nên. Default VPC có tất cả Subnet là Public và dùng CIDR cố định 172.31.0.0/16. Bạn không kiểm soát được cấu trúc, và nếu vô tình xóa Default VPC thì khó restore. Luôn tạo VPC riêng cho mọi project production.

Q: VPC Peering là gì? Khi nào cần dùng?
A: VPC Peering cho phép 2 VPC "nhìn thấy" nhau như một mạng nội bộ dù ở khác Region hoặc khác Account. Dùng khi bạn cần microservice ở VPC A gọi database ở VPC B mà không qua Internet. Nhược điểm: không transitive — A peer B, B peer C, nhưng A không nói chuyện được C. Nếu cần nhiều VPC kết nối nhau, dùng AWS Transit Gateway.

Q: Tốn bao nhiêu tiền để tạo một VPC?
A: Tạo VPC, Subnet, Route Table, Internet Gateway — miễn phí hoàn toàn. Chi phí phát sinh từ: NAT Gateway ($0.045/giờ + $0.045/GB), VPC Peering data transfer ($0.01/GB inter-AZ), và VPC Flow Logs (CloudWatch Logs ingestion). Một VPC production điển hình với 2 NAT Gateway tốn khoảng $65-70/tháng chỉ riêng NAT.

VPC không phải tùy chọn — đó là nền móng

Mỗi lần setup VPC đúng từ đầu, bạn đang đầu tư vào sự yên tâm lâu dài. Không có bài toán "phá tường sau" nào dễ hơn "xây tường ngay từ đầu" trong cloud architecture. Khi bạn đã hiểu VPC, mọi service AWS khác — từ ECS đến EKS đến Lambda VPC — đều trở nên rõ ràng hơn vì chúng đều sống trong cùng một mô hình mạng này.

Bài tiếp theo mình sẽ đi sâu vào Public Subnet và Private Subnet: cách phân chia, cách routing cụ thể, và kiến trúc "3-tier" hoàn chỉnh cho ứng dụng web production. Nếu bài này hữu ích, hãy bookmark lại — bạn sẽ cần tra cứu khi bắt đầu config VPC thực tế.