Tổng quan ở mức "biết là gì, dùng khi nào" về mạng riêng ảo VPC: subnet, Internet Gateway, NAT, Security Group, NACL, VPC Peering, VPC Endpoint, VPN và Direct Connect — đủ cho kỳ thi Cloud Practitioner.
VPC (Virtual Private Cloud) là một trong những chủ đề "sâu và rộng" nhất của AWS — nó được học kỹ trong các chứng chỉ nâng cao hơn như AWS Certified Solutions Architect Associate hoặc AWS Certified SysOps Administrator, nơi bạn phải biết cách thiết kế, tính toán CIDR, cấu hình routing chi tiết. Ở cấp độ Cloud Practitioner, đề thi thường chỉ có khoảng 1-2 câu liên quan đến VPC, và mục tiêu chỉ là hiểu ở mức khái niệm: VPC dùng để làm gì, các thành phần chính tên là gì và vai trò của chúng, không cần biết cách tính subnet mask hay thiết kế mạng phức tạp.
Trong chương này, chúng ta sẽ đi qua các khái niệm cốt lõi: VPC, Subnet, Internet Gateway, NAT Gateway, Security Group, Network ACL, VPC Flow Logs, VPC Peering, VPC Endpoint, Site-to-Site VPN, Direct Connect và Transit Gateway. Mỗi phần chỉ cần hiểu ở mức "đây là gì, giải quyết vấn đề gì" — không cần đi sâu vào cấu hình.
Trước khi nói về VPC, cần hiểu sơ lược về địa chỉ IP vì đây là "ngôn ngữ" mà mạng máy tính dùng để định danh và định tuyến.
IPv4 là chuẩn địa chỉ IP phổ biến nhất, với không gian địa chỉ giới hạn khoảng 4.3 tỷ địa chỉ — con số này nghe lớn nhưng đã gần cạn kiệt trên toàn cầu do số lượng thiết bị kết nối Internet tăng vượt bậc. IPv4 chia thành hai loại:
192.168.1.1). Khác với Public IP, địa chỉ Private IPv4 của EC2 instance được giữ cố định dù bạn có stop/start instance bao nhiêu lần.Elastic IP (EIP) là một địa chỉ Public IPv4 cố định mà bạn có thể "gắn" vào EC2 instance và giữ nguyên dù instance bị stop/start hoặc thậm chí đổi sang instance khác. Điều này hữu ích khi bạn cần một địa chỉ IP không đổi để cấu hình DNS hoặc whitelist ở phía đối tác.
IPv6 được sinh ra để giải quyết vấn đề cạn kiệt địa chỉ của IPv4, với không gian địa chỉ khổng lồ (đủ dùng cho rất lâu về sau). Trong AWS, một điểm khác biệt quan trọng: mọi địa chỉ IPv6 đều là địa chỉ public — không có khái niệm "private range" như IPv4. Việc sử dụng IPv6 trên AWS là miễn phí (không bị tính phí như Public IPv4).
VPC (Virtual Private Cloud) là một mạng riêng ảo, biệt lập, mà bạn tự định nghĩa để triển khai các tài nguyên AWS của mình (EC2, RDS, v.v.) vào đó. Có thể hình dung VPC như một "tòa nhà văn phòng riêng" mà bạn thuê trong một khu công nghệ (Region) — bên trong tòa nhà đó, bạn tự quyết định cách chia phòng, ai được ra vào phòng nào. VPC là tài nguyên ở cấp Region — một VPC có thể trải rộng qua nhiều Availability Zone trong Region đó.
Subnet cho phép bạn phân chia (partition) mạng bên trong VPC thành các "phân vùng" nhỏ hơn. Khác với VPC, Subnet là tài nguyên gắn với một Availability Zone cụ thể — nghĩa là khi tạo subnet, bạn phải chỉ định nó thuộc AZ nào.
Việc một subnet là "public" hay "private", và việc các subnet có giao tiếp được với nhau hay với Internet hay không, được quyết định bởi Route Table — bảng định tuyến gắn với subnet, quy định traffic từ subnet đó sẽ đi đến đâu.
10.0.0.0/16 trải trên một Region gồm 2 Availability Zone. Mỗi AZ có một Public subnet (chứa web server, load balancer) và một Private subnet (chứa database). Người dùng Internet chỉ chạm được vào Public subnet; database trong Private subnet hoàn toàn "ẩn" khỏi Internet, chỉ nhận traffic từ web server nội bộ.Internet Gateway (IGW) là thành phần được gắn ở cấp VPC, cho phép các tài nguyên bên trong VPC kết nối ra Internet (và ngược lại, cho phép traffic từ Internet đi vào). Một VPC muốn có khả năng giao tiếp Internet thì phải có Internet Gateway. Các Public Subnet có route (trong Route Table) chỉ tới Internet Gateway — đó chính là lý do khiến chúng "public".
Vấn đề đặt ra: nếu một máy chủ nằm trong Private Subnet (ví dụ application server nội bộ) vẫn cần tải cập nhật phần mềm hoặc gọi API ra ngoài Internet, nhưng bản thân nó không được phép nhận kết nối từ Internet vào (để bảo mật) thì phải làm sao? Đây là lúc NAT Gateway (hoặc NAT Instance) phát huy tác dụng.
Cả hai đều cho phép instance trong Private Subnet chủ động kết nối ra Internet (ví dụ tải update, gọi API bên ngoài) nhưng Internet không thể chủ động kết nối vào instance đó — đúng như nguyên tắc NAT (Network Address Translation): che giấu địa chỉ private phía sau một địa chỉ public dùng chung, chỉ cho traffic đi một chiều khởi tạo từ bên trong ra ngoài.
Đây là một trong những cặp khái niệm dễ gây nhầm lẫn nhất khi mới học AWS, vì cả hai đều đóng vai trò "tường lửa" (firewall) nhưng hoạt động ở cấp độ khác nhau và có cơ chế khác nhau.
NACL là một tường lửa kiểm soát traffic ra/vào ở cấp độ Subnet — nghĩa là quy tắc của NACL áp dụng cho mọi tài nguyên nằm trong subnet đó. NACL có thể có cả quy tắc ALLOW (cho phép) và DENY (từ chối) — đây là điểm khác biệt lớn so với Security Group. Các quy tắc trong NACL chỉ dựa trên địa chỉ IP (không thể tham chiếu tới Security Group khác).
Security Group là tường lửa kiểm soát traffic ra/vào ở cấp độ EC2 instance (chính xác hơn là ở cấp Elastic Network Interface — ENI). Security Group chỉ có thể có quy tắc ALLOW — không có DENY (mặc định mọi traffic không nằm trong danh sách ALLOW đều bị từ chối ngầm). Quy tắc của Security Group có thể tham chiếu tới địa chỉ IP hoặc một Security Group khác (rất hữu ích khi muốn "chỉ cho phép các instance thuộc SG-A truy cập vào SG-B").
| Tiêu chí | Network ACL (NACL) | Security Group |
|---|---|---|
| Phạm vi áp dụng | Cấp Subnet — ảnh hưởng mọi instance trong subnet | Cấp EC2 instance / ENI — ảnh hưởng riêng từng instance |
| Loại quy tắc | Có cả ALLOW và DENY | Chỉ có ALLOW (ngầm định DENY những gì không được liệt kê) |
| Trạng thái (stateful/stateless) | Stateless — traffic đi (outbound) và traffic về (inbound) được đánh giá độc lập, phải khai báo rule cho cả hai chiều | Stateful — nếu traffic đi ra được cho phép, traffic phản hồi tương ứng tự động được cho phép, không cần khai báo rule chiều ngược lại |
| Cách đánh giá rule | Đánh giá theo thứ tự số rule (rule number), từ nhỏ đến lớn, dừng lại ở rule đầu tiên khớp | Tất cả các rule được đánh giá cùng lúc trước khi quyết định cho phép traffic |
| Tham chiếu | Chỉ bằng địa chỉ IP | Địa chỉ IP hoặc Security Group khác |
VPC Flow Logs là tính năng ghi lại thông tin về các traffic IP đi vào/ra khỏi các network interface trong VPC của bạn. Có thể bật Flow Logs ở ba cấp độ: VPC Flow Logs (toàn bộ VPC), Subnet Flow Logs (một subnet cụ thể), hoặc Elastic Network Interface (ENI) Flow Logs (một network interface cụ thể).
Flow Logs giúp bạn giám sát và xử lý sự cố kết nối (troubleshooting connectivity issues), ví dụ: traffic từ subnet đi ra Internet có bị chặn không, traffic giữa hai subnet có thông suốt không, traffic từ Internet vào subnet có bị từ chối không. Ngoài các EC2 instance, Flow Logs còn có thể ghi lại thông tin traffic của các network interface được AWS quản lý, ví dụ của Elastic Load Balancer, ElastiCache, RDS, Aurora.
Dữ liệu Flow Logs có thể được gửi tới nhiều đích khác nhau để lưu trữ và phân tích: Amazon S3, CloudWatch Logs, hoặc Amazon Data Firehose (để xử lý near-real-time).
VPC Peering cho phép kết nối hai VPC với nhau một cách riêng tư (private), sử dụng chính hạ tầng mạng nội bộ của AWS — nghĩa là traffic giữa hai VPC không đi qua Internet công cộng. Sau khi peering, hai VPC hoạt động như thể chúng là một mạng duy nhất: instance ở VPC này có thể giao tiếp trực tiếp với instance ở VPC kia bằng địa chỉ IP private.
Điều kiện quan trọng: hai VPC muốn peering với nhau không được có CIDR (dải địa chỉ IP) trùng nhau — nếu trùng, việc định tuyến sẽ không rõ ràng nên AWS không cho phép tạo kết nối peering.
Thông thường, khi một EC2 instance trong VPC của bạn muốn gọi tới một dịch vụ AWS khác (ví dụ S3), traffic đó phải đi ra khỏi VPC, qua Internet Gateway hoặc NAT Gateway, rồi tới endpoint public của dịch vụ đó — dù cả hai đều là tài nguyên AWS. VPC Endpoint giải quyết vấn đề này: nó cho phép bạn kết nối tới các dịch vụ AWS thông qua mạng riêng nội bộ của AWS, thay vì đi qua mạng Internet công cộng — mang lại bảo mật cao hơn (traffic không lộ ra ngoài) và độ trễ thấp hơn.
Có hai loại VPC Endpoint:
AWS PrivateLink là cách an toàn và có khả năng mở rộng tốt nhất để phơi bày (expose) một dịch vụ của bạn cho hàng nghìn VPC khác sử dụng — mà không cần thiết lập VPC Peering, Internet Gateway, NAT, hay cấu hình Route Table phức tạp. Về kiến trúc, phía cung cấp dịch vụ (Service VPC) cần có một Network Load Balancer, còn phía khách hàng (Customer VPC) sẽ có một ENI đóng vai trò điểm vào riêng tư tới dịch vụ đó.
Nhiều tổ chức không chuyển 100% hạ tầng lên AWS ngay mà vận hành theo mô hình hybrid — vừa có hệ thống on-premises (tại trung tâm dữ liệu riêng) vừa có hệ thống trên AWS. Để hai bên giao tiếp an toàn, AWS cung cấp một số giải pháp kết nối.
Site-to-Site VPN kết nối hạ tầng VPN on-premises của bạn với AWS. Kết nối này được tự động mã hóa, nhưng traffic vẫn đi qua Internet công cộng (chỉ là đã được đóng gói và mã hóa an toàn qua đường hầm VPN). Về kiến trúc: phía on-premises cần có Customer Gateway (CGW) — đại diện cho thiết bị/kết nối phía khách hàng; phía AWS cần có Virtual Private Gateway (VGW) — đại diện cho phía AWS trong kết nối VPN.
Direct Connect thiết lập một kết nối vật lý riêng (physical connection) giữa trung tâm dữ liệu on-premises và AWS. Khác với VPN, kết nối này đi qua một mạng riêng (private network), không qua Internet công cộng — vì vậy nó riêng tư, bảo mật và nhanh, ổn định hơn đáng kể so với VPN. Đánh đổi là việc thiết lập Direct Connect mất khá nhiều thời gian, thường tối thiểu khoảng một tháng, vì cần triển khai đường truyền vật lý thực tế.
Khác với Site-to-Site VPN (kết nối hai mạng với nhau), Client VPN cho phép một máy tính cá nhân kết nối vào mạng private của AWS (và cả on-premises nếu được cấu hình) bằng phần mềm OpenVPN. Sau khi kết nối, máy của bạn có thể truy cập tới các EC2 instance qua địa chỉ IP private, giống như đang ngồi ngay trong mạng VPC riêng đó. Client VPN cũng đi qua Internet công cộng.
| Giải pháp | Kết nối gì với gì | Đi qua đâu | Đặc điểm |
|---|---|---|---|
| Site-to-Site VPN | Mạng on-premises ↔ AWS | Internet công cộng (đã mã hóa) | Thiết lập nhanh, chi phí thấp |
| Direct Connect | Trung tâm dữ liệu on-premises ↔ AWS | Mạng riêng vật lý | Nhanh, ổn định, bảo mật cao, thiết lập chậm (~1 tháng+) |
| Client VPN | Một máy tính cá nhân ↔ VPC/on-premises | Internet công cộng | Dùng phần mềm OpenVPN, cho nhân viên làm việc từ xa |
Như đã nói ở phần VPC Peering, nếu một tổ chức có hàng chục hoặc hàng trăm VPC cần giao tiếp với nhau (và cả với mạng on-premises), việc tạo từng cặp VPC Peering riêng lẻ sẽ trở nên cực kỳ phức tạp để quản lý (số lượng kết nối tăng theo cấp bậc hai so với số VPC). Transit Gateway giải quyết bài toán này bằng mô hình hub-and-spoke (hình sao): mọi VPC và kết nối on-premises chỉ cần kết nối tới một Transit Gateway trung tâm duy nhất, và Transit Gateway sẽ đảm nhận việc định tuyến traffic giữa tất cả các bên — mang tính bắc cầu (transitive), khác với VPC Peering.
Transit Gateway hoạt động tốt cùng với Direct Connect Gateway và các kết nối VPN, cho phép một kiến trúc mạng tập trung, dễ quản lý ở quy mô hàng nghìn VPC và kết nối on-premises.