[AWS] Chương 4: Virtual Private Cloud (VPC)

Trong môi trường truyền thống (On-premise), để thiết lập kết nối giữa các thiết bị, bạn phải cấu hình thủ công các thiết bị vật lý như Router, Switch để tạo mạng LAN. Với AWS, quá trình này được đơn giản hóa tối đa thông qua Amazon VPC (Virtual Private Cloud), cho phép bạn khởi tạo một mạng ảo riêng biệt chỉ với vài thao tác click chuột.

Để quản lý dải địa chỉ IP trong mạng, chúng ta sử dụng ký hiệu CIDR (Classless Inter-Domain Routing). Một địa chỉ IPv4 bao gồm 32 bit, chia thành 4 nhóm (octet), mỗi nhóm 8 bit.

Subnet Mask giúp xác định phạm vi của một mạng dựa trên hai phần:

Phần Mạng (Network): Các bit bị “khóa” cố định, xác định định danh của mạng đó.
Phần Máy chủ (Host): Các bit còn lại được phép thay đổi để gán cho các thiết bị (EC2, RDS,…) trong mạng.

Ví dụ cụ thể: 192.168.0.0/24

Ký hiệu /24: Nghĩa là 24 bit đầu tiên (3 octet đầu: 192.168.0) là cố định.
Số lượng IP khả dụng: Tính theo công thức $2^{32-n}$. Với n=24, ta có $2^8 = 256$ địa chỉ IP.

Ví dụ: IP mạng LAN

Trong kiến trúc mạng, IP được chia thành hai loại chính để đảm bảo an ninh và tiết kiệm tài nguyên:

Private IP (IP Nội bộ) chỉ được sử dụng để giao tiếp trong mạng nội bộ (mạng gia đình, mạng công ty hoặc bên trong VPC). Các dải IP tiêu chuẩn bao gồm:

10.0.0.0/8: Dùng cho các mạng doanh nghiệp quy mô lớn.
172.16.0.0/12: Dải IP mặc định thường dùng trong AWS VPC.
192.168.0.0/16: Dùng cho mạng gia đình hoặc văn phòng nhỏ.

Public IP (IP Công cộng) là các địa chỉ IP độc nhất trên toàn thế giới, cho phép thiết bị có thể được tìm thấy và truy cập trực tiếp từ Internet.

VPC (Virtual Private Cloud) là một mạng ảo dành riêng cho tài khoản AWS của bạn, được cách ly logic với các mạng ảo khác trên đám mây AWS.

Phạm vi: Một VPC nằm trong một Region duy nhất và có thể trải dài trên nhiều AZ trong cùng Region.
Giới hạn: Mặc định mỗi Region bạn có thể tạo tối đa 5 VPC (đây là giới hạn mềm, có thể yêu cầu AWS nâng hạn mức).
Kích thước CIDR:
- Nhỏ nhất: /28 (16 địa chỉ IP).
- Lớn nhất: /16 (65.536 địa chỉ IP).
Dải CIDR: VPC cũng là private network nên dải CIDR của nó cũng cần nằm trong các dải của private network.
Lưu ý quan trọng: Dải CIDR của VPC không được phép chồng lấn (overlap) với các mạng khác mà bạn định kết nối tới (như mạng On-premise qua VPN hoặc VPC khác qua Peering).

Khi bạn tạo tài khoản AWS, hệ thống tự động tạo một Default VPC (VPC Mặc định) ở mỗi Region để bạn có thể triển khai tài nguyên ngay lập tức.

Các Instance EC2 khi khởi tạo sẽ mặc định nằm trong VPC này nếu không có chỉ định khác.
Tự động gán Public IPv4 và DNS cho các instance.
Sẵn sàng kết nối Internet (Internet-ready).

Trong bất kỳ Subnet nào bạn tạo ra trên AWS, luôn có 5 địa chỉ IP bị hệ thống chiếm giữ và bạn không thể gán chúng cho các tài nguyên như EC2 hay RDS. Việc hiểu rõ mục đích của từng IP này rất quan trọng để tránh sai sót khi thiết kế hạ tầng.

Giả sử ta có Subnet với dải CIDR là 10.0.0.0/24:

10.0.0.0 – Network Address: Đây là địa chỉ định danh của mạng. Trong định tuyến tiêu chuẩn, địa chỉ này đại diện cho chính phân đoạn mạng đó và không bao giờ được gán cho thiết bị đầu cuối.
10.0.0.1 – VPC Router: Được AWS sử dụng làm địa chỉ Default Gateway cho Subnet. Mọi lưu lượng dữ liệu muốn đi ra ngoài Subnet (sang Subnet khác hoặc ra Internet) đều phải đi qua “cửa ngõ” này.
10.0.0.2 – Amazon Provided DNS: Đây là địa chỉ của máy chủ DNS nội bộ của AWS (thường được gọi là AmazonRoute53Resolver). Nó giúp phân giải các tên miền nội bộ trong VPC và tên miền công cộng ra Internet.
10.0.0.3 – Reserved by AWS: Địa chỉ này hiện đang được AWS giữ lại để phục vụ cho các tính năng hoặc dịch vụ mới phát triển trong tương lai.
10.0.0.255 – Network Broadcast Address: Trong mạng vật lý truyền thống, địa chỉ cuối cùng dùng để gửi gói tin đến tất cả thiết bị trong mạng (Broadcast). Tuy nhiên, VPC là mạng ảo hóa và không hỗ trợ Broadcast, do đó địa chỉ này bị vô hiệu hóa và dự phòng.

Mẹo thi cử (Exam Tip): Khi đề bài yêu cầu số lượng máy chủ cụ thể, bạn luôn phải lấy tổng số IP của Subnet mask trừ đi 5 rồi mới so sánh.

Cần 29 IP ⇒ Chọn /27 (32 IP) là sai vì 32 – 5 = 27 (thiếu).

Cần 29 IP ⇒ Phải chọn /26 (64 IP) vì 64 – 5 = 59 (đủ).

Subnet cũng có CIDR range riêng và CIDR range của nó phải nằm trong range của VPC

Việc chia nhỏ VPC thành các Subnet giúp tăng cường tính bảo mật bằng cách cô lập các thành phần của ứng dụng.

Public Subnet (Subnet Công cộng)

Đặc điểm: Có bảng định tuyến (Route Table) trỏ lưu lượng đến Internet Gateway (IGW).
Sử dụng cho: Các tài nguyên cần “mặt tiền” để giao tiếp với người dùng bên ngoài như:
- Web Servers: Nơi tiếp nhận yêu cầu HTTP/HTTPS.
- Application Load Balancers (ALB): Điều phối lưu lượng đến các server phía sau.
- Bastion Hosts (Jump Server): Máy chủ trung gian để admin SSH vào các máy nội bộ.

Private Subnet (Subnet Riêng tư)

Đặc điểm: Không có đường đi trực tiếp ra Internet Gateway. Các tài nguyên ở đây chỉ có Private IP.
Sử dụng cho: Các thành phần nhạy cảm, cần bảo vệ nghiêm ngặt:
- Database Servers (RDS, MongoDB): Tránh việc hacker có thể scan thấy IP từ Internet.
- Backend Applications: Các logic xử lý nội bộ không cần tiếp xúc trực tiếp với người dùng.
- Cache layers (Redis, Memcached).

Internet Gateway là một thành phần phần mềm được quản lý bởi AWS, đóng vai trò là “cửa ngõ” duy nhất để VPC của bạn giao tiếp với Internet bên ngoài.

Khả năng mở rộng: Nó có khả năng tự động mở rộng theo chiều ngang (scale horizontally), đảm bảo tính sẵn sàng cao (highly available) và có cơ chế dự phòng (redundant). Bạn không cần lo lắng về băng thông hay sự cố vật lý của Gateway này.
Tính kết nối:
- IGW không được tạo tự động cùng VPC (ngoại trừ Default VPC). Bạn phải tạo thủ công và thực hiện thao tác Attach to VPC.
- Mối quan hệ 1-1: Một VPC chỉ có thể gắn với duy nhất một IGW tại một thời điểm, và ngược lại, một IGW cũng chỉ thuộc về một VPC.
Cơ chế hoạt động: Bản thân IGW chỉ là một cái cổng. Để dữ liệu thực sự chảy qua nó, bạn bắt buộc phải cấu hình Route Table (bảng định tuyến) để chỉ đường cho các gói tin đi đến IGW.
Lưu ý: Chỉ tạo ra IGW là chưa đủ. Để một Subnet thực sự trở thành “Public Subnet”, bạn phải thêm một dòng trong Route Table của Subnet đó:
- Destination: 0.0.0.0/0 (Tất cả lưu lượng)
- Target: igw-xxxxxxxx (ID của Internet Gateway bạn vừa tạo)

Route Table chứa một tập hợp các quy tắc (được gọi là Routes), dùng để xác định lưu lượng mạng từ Subnet hoặc Gateway của bạn sẽ được điều hướng đi đâu. Hãy tưởng tượng nó như một “biển báo chỉ đường” tại các ngã tư trong mạng ảo của bạn.

Khi bạn tạo một VPC, AWS tự động tạo ra một Main Route Table.
Mặc định, mọi Subnet mới tạo ra mà không được gán cho một Route Table cụ thể nào thì sẽ tự động sử dụng Main Route Table này.
Best Practice: Các chuyên gia AWS khuyên không nên chỉnh sửa trực tiếp Main Route Table cho mục đích truy cập Internet. Thay vào đó, hãy để nó ở chế độ riêng tư (Private) và tạo các Custom Route Table cho từng mục đích cụ thể.

Để thiết lập một môi trường mạng hoạt động được trên AWS, chúng ta thực hiện theo các bước sau:

Tạo VPC: Xác định dải địa chỉ IP tổng quát (ví dụ: 10.0.0.0/16).
Tạo Subnets: Chia nhỏ VPC thành các phân đoạn mạng.
- Ví dụ: 10.0.1.0/24 cho Public Subnet và 10.0.2.0/24 cho Private Subnet.
- Lưu ý: CIDR của Subnet phải nằm trong phạm vi CIDR của VPC.
Tạo EC2 Instance: Khởi tạo server, chọn đúng VPC và Public Subnet đã tạo ở bước trên để thử nghiệm kết nối.
Tạo và gắn Internet Gateway (IGW): Tạo IGW trên Console, sau đó chọn “Attach to VPC” để liên kết nó với VPC của bạn.
Cấu hình Route Table (Quan trọng nhất):
- Public Route Table:
  - Tạo một Route Table mới đặt tên là Public-RT.
  - Thêm một dòng Route: Destination: 0.0.0.0/0 (đại diện cho mọi địa chỉ trên Internet) | Target: Chọn Internet Gateway vừa tạo.
  - Subnet Association: Gán (associate) Public Subnet vào Route Table này. Lúc này, Subnet mới chính thức trở thành “Public”.
- Private Route Table:
  - Tạo một Route Table mới đặt tên là Private-RT.
  - Giữ nguyên mặc định (chỉ có route local để các server trong VPC thấy nhau).
  - Subnet Association: Gán Private Subnet vào Route Table này.
Kiểm tra kết nối: Sử dụng Public IP của EC2 để SSH hoặc truy cập web. Nếu các bước trên đúng, bạn sẽ kết nối thành công từ máy tính cá nhân vào EC2 thông qua Internet.

Trong một kiến trúc mạng chuẩn trên AWS, các tài nguyên quan trọng như Database hoặc Backend thường được đặt trong Private Subnet để đảm bảo an ninh. Vì không có Internet Gateway, các EC2 instance này hoàn toàn “cô lập” với thế giới bên ngoài.

Câu hỏi đặt ra là: Làm thế nào để người quản trị (Admin) có thể truy cập vào các máy chủ này để bảo trì hoặc cấu hình khi chúng không có Public IP và không thể kết nối trực tiếp từ Internet?

Bastion Host là một máy chủ EC2 đặc biệt nằm trong Public Subnet. Nó đóng vai trò như một “trạm trung chuyển” an toàn. Người quản trị sẽ SSH vào Bastion Host trước, sau đó từ Bastion Host mới thực hiện kết nối nội bộ đến các máy chủ trong Private Subnet.

Để đảm bảo Bastion Host không trở thành điểm yếu bảo mật, bạn cần cấu hình Security Group (SG) cực kỳ chặt chẽ:

Đối với Bastion Host (Nằm ở Public Subnet)

Inbound Rules: Chỉ cho phép truy cập cổng 22 (SSH) cho Linux hoặc 3389 (RDP) cho Windows.
Nguồn (Source): Tuyệt đối không để 0.0.0.0/0. Bạn nên giới hạn chỉ cho phép địa chỉ Public IP cụ thể của bạn hoặc dải IP của mạng nội bộ công ty.

Đối với Private EC2 Instances (Nằm ở Private Subnet)

Inbound Rules: Cho phép truy cập cổng 22 hoặc 3389.
Nguồn (Source): Đây là điểm mấu chốt về bảo mật. Bạn có hai lựa chọn:
- Theo Private IP: Chỉ cho phép duy nhất IP nội bộ của Bastion Host.
- Theo Security Group (Khuyên dùng): Cấu hình nguồn là ID của Security Group thuộc Bastion Host. Điều này linh hoạt hơn vì nếu bạn thay đổi Bastion Host, quy tắc vẫn sẽ tự động áp dụng cho bất kỳ máy nào thuộc nhóm bảo mật đó.

Để hiểu về NAT Gateway, trước tiên chúng ta cần làm rõ khái niệm cơ bản nhất về NAT (Network Address Translation – Biên dịch địa chỉ mạng).

Private Subnet là một mạng nội bộ. Các EC2 Instances bên trong có Private IP nhưng không có Public IP ra ngoài Internet.

NAT giống như một tổng đài viên, khi một EC2 instance muốn gọi ra ngoài (Update/Patch/Get), NAT sẽ dùng Public IP của NAT Gateway để thực hiện. Từ bên ngoài internet, chỉ thấy Public IP của NAT Gateway, không biết chủ của request là ai, và cũng không thể chủ động gọi tới Private IP của EC2.

Lưu ý: NAT Gateway là stateful, nghĩa là khi đã cho phép EC2 gửi request ra ngoài, nó cũng cho phép response của request đó quay lại EC2. NAT Gateway chỉ chặn các request chủ động inbound từ internet vào EC2.

Mặc dù chúng ta đã có Bastion Host để Admin “nhảy” vào quản trị, nhưng bản thân các EC2 trong Private Subnet vẫn hoàn toàn bị ngắt kết nối với Internet. Điều này gây ra khó khăn khi:

Hệ điều hành cần tải bản vá lỗi (Security Patches).
Ứng dụng cần tải thư viện từ GitHub hoặc Docker Hub.
Server cần kết nối với các API bên ngoài (ví dụ: Google Maps API, Stripe).

NAT Gateway giải quyết vấn đề này: Cho phép dữ liệu đi từ trong ra ngoài (Outbound) nhưng chặn đứng mọi nỗ lực truy cập từ ngoài vào trong (Inbound).

Đây là dịch vụ được AWS quản lý hoàn toàn (Managed Service), giúp bạn rảnh tay khỏi việc quản trị hệ thống:

Băng thông cực lớn: Khởi điểm từ 5 Gbps và tự động mở rộng lên tới 45 Gbps. Bạn không cần lo lắng về việc nghẽn mạng khi có nhiều server cùng update một lúc.
Tính sẵn sàng cao (High Availability): AWS tự đảm bảo hạ tầng cho NAT Gateway luôn chạy. Tuy nhiên, lưu ý rằng NAT Gateway được tạo trong một Availability Zone (AZ) cụ thể bằng cách sử dụng Elastic IP. Nếu AZ đó gặp sự cố, NAT Gateway cũng sẽ bị ảnh hưởng.
Yêu cầu bắt buộc:
- Phải được đặt ở một Public Subnet.
- Phải gắn với một địa chỉ Elastic IP (IP tĩnh công cộng).
- Phải có một Internet Gateway (IGW) để NAT Gateway có thể đẩy dữ liệu ra ngoài.
Quản lý đơn giản: Không cần cấu hình Security Group cho chính NAT Gateway. Nó tự động cho phép lưu lượng đi qua dựa trên quy tắc định tuyến.
Chi phí: Bạn trả tiền theo giờ sử dụng và lượng dữ liệu (GB) truyền qua Gateway.

Để NAT Gateway hoạt động, luồng đi của dữ liệu sẽ như sau:

Private Subnet → NAT Gateway (nằm ở Public Subnet) → Internet Gateway → Internet

Cách cấu hình Route Table:

Tại Private Subnet: Bạn thêm một dòng Route với Destination: 0.0.0.0/0 và Target: là nat-gateway-id.
Tại Public Subnet (nơi đặt NAT GW): Phải có Route trỏ về igw-id (như đã học ở bài trước).

Lưu ý quan trọng: Bạn không thể đặt NAT Gateway vào cùng một Subnet với các EC2 muốn dùng nó. NAT Gateway phải nằm ở “phía ngoài” (Public Subnet) để có thể nhìn thấy Internet Gateway.

Mặc dù NAT Gateway là một dịch vụ được AWS quản lý và có khả năng chống chịu lỗi tốt trong nội bộ một Availability Zone (AZ), nhưng nó không có tính năng tự động dự phòng xuyên qua các AZ khác nhau.

Hạn chế của đơn AZ: Nếu bạn chỉ tạo một NAT Gateway tại AZ-A và AZ này gặp sự cố, tất cả các tài nguyên ở các AZ khác (AZ-B, AZ-C) mà đang sử dụng NAT Gateway này cũng sẽ mất kết nối Internet hoàn toàn.
Giải pháp (Best Practice): Để đảm bảo hệ thống không có “điểm yếu duy nhất” (Single Point of Failure), bạn nên tạo nhiều NAT Gateway tại nhiều AZ khác nhau.
- Mỗi Private Subnet ở một AZ sẽ trỏ đường truyền ra Internet tới NAT Gateway nằm ở cùng AZ đó.
- Nguyên tắc: Nếu một AZ bị sập, các instance trong đó cũng sẽ ngừng hoạt động, nên chúng ta không cần lo lắng về việc chuyển đổi dự phòng (failover) NAT sang AZ khác. Các AZ còn lại vẫn sẽ hoạt động bình thường với NAT Gateway riêng của chúng.

Trước khi NAT Gateway ra đời, người dùng AWS phải tự thiết lập một máy chủ EC2 thông thường để làm nhiệm vụ NAT (gọi là NAT Instance). Luồng cũ sẽ là: Private EC2 Instance → NAT Instance → Internet Gateway

Dưới đây là bảng so sánh giúp bạn hiểu tại sao NAT Gateway hiện nay là lựa chọn ưu tiên:

Đặc điểm	NAT Gateway (Khuyên dùng)	NAT Instance (Cũ)
Tính sẵn sàng (Availability)	Rất cao trong một AZ. Cần tạo thêm ở AZ khác để dự phòng toàn diện.	Thấp. Phải tự viết script để quản lý việc chuyển đổi dự phòng (failover).
Băng thông (Bandwidth)	Tự động mở rộng lên đến 45 Gbps.	Phụ thuộc hoàn toàn vào cấu hình (Type) của EC2 Instance.
Bảo trì (Maintenance)	AWS quản lý hoàn toàn. Bạn không cần vá lỗi OS hay cài đặt phần mềm.	Bạn tự quản lý. Phải tự cài đặt, cập nhật hệ điều hành và các bản vá bảo mật.
Chi phí	Trả theo giờ và lượng dữ liệu truyền qua (GB).	Trả theo giờ cho EC2 Instance, kích cỡ máy và phí lưu lượng mạng.
Public IPv4	Có	Có
Private IPv4	Có	Có
Security Groups	Không cần quản lý Security Group cho NAT Gateway.	Bắt buộc phải cấu hình Security Group để kiểm soát lưu lượng.
Sử dụng để làm Bastion Host	Chỉ dùng để NAT. Không thể dùng làm Bastion Host.	Có thể dùng kết hợp làm Bastion Host để tiết kiệm chi phí.

Trong AWS VPC, bảo mật được thiết lập theo mô hình “phòng thủ chiều sâu” (Defense in Depth) với hai lớp tường lửa chính: Security Groups và Network ACLs. Điểm khác biệt cốt lõi nằm ở cơ chế Stateful (Lưu trạng thái) và Stateless (Không lưu trạng thái).

Cơ chế Stateful vs Stateless:

Stateful (Security Groups): Nếu bạn cho phép một luồng dữ liệu đi vào (Inbound), hệ thống sẽ tự động ghi nhớ và cho phép luồng dữ liệu phản hồi (Response) đi ra mà không cần kiểm tra quy tắc Outbound. Ngược lại, nếu bạn mở Outbound, luồng phản hồi đi vào cũng mặc định được phép.
Stateless (NACLs): Hệ thống không ghi nhớ trạng thái kết nối. Bạn phải cấu hình tường lửa cho cả hai chiều một cách độc lập. Nếu chỉ cho phép Inbound mà quên cấu hình Outbound, dữ liệu phản hồi sẽ bị chặn ngay tại cửa ngõ Subnet.

Về việc Inbound và Outbound:

Trong cấu hình Firewall (SG hay NACL), thông số Port Range luôn ám chỉ Port của phía nhận (Destination Port) đối với chiều dữ liệu đang xét.
Ví dụ, port 65535 máy A gọi port 80 máy B:
- Máy 1: Inbound gồm 65535, Outbound gồm 80
- Máy 2: Inbound gồm 80, Outbound gồm 65535

Khái niệm: Security Group là một “virtual firewall” hoạt động ở cấp độ instance (EC2, ENI, RDS…). Nó kiểm soát traffic đi vào (inbound) và đi ra (outbound) của tài nguyên.

Thuộc tính	Mô tả
Cấp độ áp dụng	Instance (EC2, ENI, RDS, Lambda trong VPC,…)
Stateful/Stateless	Stateful (tự động cho phép response)
Loại rule	Chỉ có ALLOW
Thứ tự rule	Không có thứ tự, không có priority
Cách evaluate	Chỉ cần match 1 rule ALLOW là được phép
Mặc định inbound	Deny tất cả
Mặc định outbound	Allow tất cả
Gắn tài nguyên	Có thể gắn nhiều SG cho một instance

Use case phổ biến

Mở port HTTP/HTTPS cho web server
Chỉ cho phép SSH từ IP cụ thể
Cho phép app server truy cập DB

Khái niệm: NACL là firewall ở cấp subnet, kiểm soát traffic đi vào và đi ra subnet.

Đặc điểm:

Một Subnet chỉ có thể được gán với một NACL. Tuy nhiên, một NACL có thể gán cho nhiều Subnet khác nhau.
Các Subnet mới sẽ được gán cho Default NACL. Default NACL ALLOW mọi thứ đi vào/ra khỏi subnet. Không nên chỉnh sửa Default NACL, thay vào đó, hãy tạo ra các custom NACL khác.

NACL được tạo mới sẽ DENY mọi thứ (khác với Default NACL – cho phép mọi thứ)
NACL Rules:
- Mỗi rule đều có một số thứ tự. Số càng nhỏ thì càng ưu tiên.
- Rule nào match trước thì sẽ quyết định kết quả.
- Rule cuối cùng là rule mặc định – DENY toàn bộ (*)
- AWS khuyến nghị đánh số cách nhau 100. Mục đích là để dễ dàng chèn rule mới khi chỉnh sửa.

Tại sao ta nên dùng NACL để block IPs chứ không nên dùng Security Group

IPs nên được block ở cấp subnet, thay vì cấp instance vì ta có thể có rất nhiều instance và việc thủ công sửa Security Group cho từng instance sẽ tốn kha khá thời gian.

Tips: Khi có câu hỏi, nếu cần block một vài IP address, nên dùng NACL hay SG> → Chọn NACL

Thuộc tính	Mô tả
Cấp độ áp dụng	Subnet
Stateful/Stateless	Stateless (inbound/outbound phải cấu hình riêng)
Loại rule	ALLOW và DENY
Thứ tự rule	Có (1–32766), số nhỏ ưu tiên cao
Cách evaluate	Rule đầu tiên match sẽ quyết định
Rule mặc định cuối	“*” → deny tất cả
Mặc định	Default NACL: allow all; Custom NACL: deny all
Gắn tài nguyên	1 subnet chỉ có 1 NACL, nhưng 1 NACL có thể dùng cho nhiều subnet

Use case phổ biến

Chặn IP cụ thể ở cấp subnet
Tạo lớp bảo vệ bổ sung ngoài Security Group
Kiểm soát traffic chi tiết với allow/deny

Tiêu chí	Security Group	NACL
Cấp độ	Instance	Subnet
Stateful	Có	Không
Rule	Chỉ ALLOW	ALLOW và DENY
Thứ tự rule	Không	Có (ưu tiên theo số)
Cách xử lý	Match bất kỳ rule ALLOW	Match rule đầu tiên
Response traffic	Tự động được phép	Phải cấu hình riêng
Gắn tài nguyên	Nhiều SG / instance	1 NACL / subnet
Mức sử dụng	Dùng chính	Dùng bổ sung

Trường hợp 1: Request đi từ ngoài VÀO (Inbound)

NACL (Inbound Rules): Kiểm tra đầu tiên. Nếu cấu hình Allow, request đi tiếp.
Security Group (Inbound Rules): Kiểm tra lớp thứ hai. Nếu Allow, request tới được Instance.
Response đi ra:
- Tại SG: Do tính chất Stateful, phản hồi được đi ra tự động (bỏ qua SG Outbound Rules).
- Tại NACL: Do tính chất Stateless, phản hồi bắt buộc phải khớp với một quy tắc Allow trong NACL Outbound Rules thì mới ra ngoài được.

Trường hợp 2: Request đi từ trong RA (Outbound)

Security Group (Outbound Rules): Kiểm tra xem Instance có được phép gửi yêu cầu ra ngoài không.
NACL (Outbound Rules): Kiểm tra lớp tiếp theo tại cửa ngõ Subnet.
Response đi vào:
- Tại NACL: Phải kiểm tra NACL Inbound Rules (Stateless).
- Tại SG: Tự động cho phép đi vào vì request gốc đã được SG Outbound cho phép (Stateful).

Để 2 endpoint (client, server) kết nối với nhau, chúng sẽ cần sử dụng Port:

Khi một client kết nối tới port 80 của Web Server, nó sẽ cần sử dụng một port ngẫu nhiên (thường từ 1024-65535) để nhận phản hồi.
Port ở phía client đó được gọi là Ephemeral Port.
Với mỗi hệ điều hành khác nhau ở phía client, ta sẽ có các Emphemeral Port Range khác nhau:
- IANA và MS Windows 10: 49152 – 65535
- Linux: 32768 – 60999
Vì vậy, ở phía server, bạn không chỉ phải mở port 80 Inbound, mà còn phải mở dải port Ephemeral ở phần Outbound trong NACL để server có thể gửi trả dữ liệu cho client. Đây là lỗi phổ biến nhất khiến hệ thống không thể truy cập dù đã mở port dịch vụ.

Ví dụ Back-end Instance cần gọi tới port 3306 DB Instance:

Đối với NACL của Back-end Instance:
- Outbound: 3306 để gọi DB Instance
- Inbound: 1024-65535 để nhận response từ DB Instance
Đối với NACL của DB Instance:
- Outbound: 1024-65535 để trả về kết quả cho Back-end Instance
- Inbound: 3306 để nhận request từ Back-end Instance

VPC Peering là một kết nối mạng giữa hai VPC, cho phép bạn điều hướng lưu lượng dữ liệu giữa chúng bằng các địa chỉ IPv4 hoặc IPv6 nội bộ (Private).

Thay vì phải đi vòng qua Internet công cộng (vừa chậm vừa tốn kém), dữ liệu sẽ di chuyển hoàn toàn trên hạ tầng mạng xương sống (Backbone) bảo mật và tốc độ cao của AWS. Điều này làm cho các tài nguyên ở hai VPC khác nhau hoạt động như thể chúng đang nằm trong cùng một mạng nội bộ.

Để thiết lập VPC Peering thành công, bạn cần nắm vững các nguyên tắc sau:

Không chồng lấn CIDR (No Overlapping CIDR): Đây là điều kiện tiên quyết. Hai VPC muốn kết nối với nhau bắt buộc phải có dải địa chỉ IP khác nhau. Nếu cả hai đều dùng 10.0.0.0/16, AWS sẽ không thể biết phải gửi gói tin đến đâu.
Không có tính bắc cầu (No Transitive Peering): Đây là đặc điểm cực kỳ quan trọng trong các bài thi AWS.
- Nếu VPC A kết nối với VPC B, và VPC B kết nối với VPC C, thì VPC A không thể kết nối với VPC C.
- Để A thấy C, bạn phải thiết lập một kết nối Peering trực tiếp giữa A và C.
Cấu hình Route Table: Việc tạo kết nối Peering chỉ là bước “cắm dây”. Bạn phải thủ công cập nhật Route Table ở cả hai VPC để chỉ định rằng lưu lượng hướng tới dải IP của VPC đối diện phải đi qua Peering Connection ID.

Kết nối đa tài khoản và đa vùng (Cross-Account & Cross-Region): * Bạn có thể kết nối VPC của mình với VPC của một tài khoản AWS khác.
- Bạn có thể kết nối các VPC nằm ở các Region khác nhau (ví dụ: Singapore nối với Tokyo).
Cơ chế chấp nhận: Khi thiết lập Peering giữa hai tài khoản, một bên sẽ gửi yêu cầu (Request) và bên còn lại phải nhấn Accept thì kết nối mới được hình thành.
Tham chiếu Security Group (SG Reference):
Trong cùng một Region (ngay cả khi khác Account), bạn có thể cấu hình Security Group của VPC A cho phép truy cập từ một Security Group ID cụ thể của VPC B.
Điều này giúp quản lý bảo mật linh hoạt hơn thay vì phải nhập thủ công từng dải IP.

Thông thường, các dịch vụ Serverless như Amazon S3 hay DynamoDB nằm ngoài VPC của bạn (Public AWS Network). Để một EC2 trong Private Subnet truy cập các dịch vụ này, dữ liệu thường phải đi qua Internet (thông qua NAT Gateway và Internet Gateway), điều này làm phát sinh chi phí truyền tải dữ liệu (Data Transfer) và tiềm ẩn rủi ro bảo mật.

VPC Endpoints ra đời để giải quyết vấn đề này, cho phép bạn kết nối VPC của mình với các dịch vụ AWS được hỗ trợ mà không cần thông qua Internet Gateway, thiết bị NAT, kết nối VPN hay AWS Direct Connect.

Đây là loại Endpoint linh hoạt nhất nhưng có tính phí.

Cơ chế hoạt động: AWS sẽ tạo ra một Elastic Network Interface (ENI) với một địa chỉ Private IP từ dải IP của Subnet bạn chọn. ENI này đóng vai trò là “điểm nhập” (Entry point) để các request đi vào mạng lưới dịch vụ của AWS.
Bảo mật: Vì là một Network Interface, bạn bắt buộc phải gắn Security Group cho nó để kiểm soát lưu lượng.
Khả năng hỗ trợ: Hỗ trợ hầu hết các dịch vụ AWS (SQS, SNS, CloudWatch, Kinesis,…) và các dịch vụ bên thứ ba trên AWS Marketplace.
Chi phí: Tính phí theo giờ duy trì Endpoint và lượng dữ liệu (GB) xử lý.

Đây là giải pháp chuyên biệt, hiệu quả và đặc biệt là miễn phí.

Cơ chế hoạt động: Thay vì tạo ENI, nó hoạt động như một Target trong Route Table của bạn (tương tự như cách bạn trỏ tới Internet Gateway).
Bảo mật: Không sử dụng Security Group. Thay vào đó, bạn sử dụng Endpoint Policies (chính sách IAM gắn trực tiếp vào Endpoint) để kiểm soát quyền truy cập.
Khả năng hỗ trợ: Chỉ hỗ trợ duy nhất hai dịch vụ: Amazon S3 và Amazon DynamoDB.
Chi phí: Hoàn toàn miễn phí.

Hãy ghi nhớ bảng so sánh sau để tối ưu hóa kiến trúc:

Đặc điểm	Interface Endpoint	Gateway Endpoint
Dịch vụ hỗ trợ	Hầu hết AWS Services (SNS, SQS,…)	Chỉ S3 và DynamoDB
Cơ chế	Cấp Private IP (ENI)	Thêm Route vào Route Table
Chi phí	Có phí (Giờ + GB)	Miễn phí
Bảo mật	Sử dụng Security Group	Sử dụng Endpoint Policy

Chiến lược chọn lựa (Exam Tips):

Nếu đề bài yêu cầu truy cập S3 hoặc DynamoDB một cách kinh tế nhất: Chọn Gateway Endpoint.

Nếu đề bài yêu cầu truy cập các dịch vụ khác (như SNS, SQS, Kinesis): Chọn Interface Endpoint.

Cần truy cập S3 từ mạng On-premise (qua Direct Connect/VPN để kết nối với VPC): Chọn Interface Endpoint.

Route Table trong VPC: Chỉ có tác dụng điều hướng các gói tin phát sinh từ bên trong Subnet đó.

Khi một gói tin đi từ On-premise tới, nó đi qua VPN/DX Gateway. Tại đây, AWS sẽ nhìn vào địa chỉ đích, là một S3 Gateway Endpoint.

S3 Gateway Endpoint bản chất nó không phải là một địa chỉ IP cụ thể mà là một thực thể logic gắn vào Route Table, nhưng gói tin này không bị chi phối bởi Route table nên nó không thể tìm thấy lối đi đến Gateway Endpoint.

Cần truy cập từ EC2 của VPC khác: Chọn Interface Endpoint (Peering không hỗ trợ bắc cầu qua Gateway Endpoint)

Lưu ý riêng cho S3: S3 là dịch vụ duy nhất hỗ trợ cả hai loại. Tuy nhiên, Gateway Endpoint vẫn là lựa chọn ưu tiên hàng đầu nếu bạn chỉ thao tác trong nội bộ VPC để tiết kiệm chi phí.

Khi bạn cấu hình một hàm AWS Lambda chạy bên trong một VPC (thường để truy cập các tài nguyên nội bộ như RDS, ElastiCache), hàm này sẽ mất khả năng truy cập Internet mặc định. Do DynamoDB là một dịch vụ nằm ngoài VPC (Public Service), chúng ta cần các giải pháp đặc biệt để Lambda có thể “nói chuyện” được với cơ sở dữ liệu này.

Cách 1 – Kết nối thông qua Public Internet (Chi phí cao): Đây là cách tiếp cận truyền thống khi muốn một tài nguyên trong Private Subnet đi ra ngoài Internet.

Cơ chế: Lambda (trong Private Subnet) → NAT Gateway (trong Public Subnet) → Internet Gateway → DynamoDB Public Endpoint.

Ưu điểm: Thiết lập quen thuộc, có thể dùng chung NAT Gateway cho các nhu cầu truy cập Internet khác.

Nhược điểm:

Chi phí: Tốn phí duy trì NAT Gateway hàng giờ và phí truyền tải dữ liệu (Data Transfer) theo GB.

Hiệu suất: Dữ liệu phải đi vòng qua nhiều chặng trung gian trên môi trường Internet.

Cách 2 – Sử dụng VPC Gateway Endpoint (Tối ưu nhất): Đây là giải pháp được AWS khuyến nghị (Best Practice) vì tính bảo mật và hiệu quả kinh tế.

Cơ chế: Bạn tạo một Gateway Endpoint cho DynamoDB ngay trong VPC của mình.

Thực hiện:

Tạo Gateway Endpoint cho dịch vụ com.amazonaws.[region].dynamodb.

Chọn Route Table gắn liền với Subnet chứa Lambda.

AWS sẽ tự động thêm một dòng định tuyến: Đích là dải IP của DynamoDB (Prefix List) và Target là vpce-xxxxxx.

Ưu điểm:

Miễn phí: Không tốn phí khởi tạo hay phí truyền tải dữ liệu qua Endpoint.

Bảo mật: Dữ liệu chạy hoàn toàn trên mạng lưới nội bộ của AWS, không bao giờ rời khỏi hạ tầng đám mây để ra Internet.

Tốc độ: Độ trễ thấp hơn so với đi qua NAT Gateway.

VPC Flow Logs là một tính năng cho phép bạn ghi lại (capture) thông tin về lưu lượng IP đi vào và đi ra khỏi các giao diện mạng (Network Interfaces) trong VPC của bạn. Hãy coi nó như một hệ thống “camera giám sát” ghi lại mọi biến động của các gói tin trong mạng.

Bạn có thể kích hoạt Flow Logs ở ba cấp độ khác nhau:

VPC Flow Logs: Ghi lại toàn bộ lưu lượng của tất cả các thành phần trong VPC.
Subnet Flow Logs: Chỉ ghi lại lưu lượng trong một Subnet cụ thể.
Elastic Network Interface (ENI) Flow Logs: Ghi lại chi tiết cho một giao diện mạng cụ thể (ví dụ: của một EC2 instance).

Ngoài ra, Flow Logs còn ghi lại thông tin từ các dịch vụ được AWS quản lý như: Elastic Load Balancer (ELB), RDS, ElastiCache, Redshift, NAT Gateway, và Transit Gateway.

Cấu trúc:

version: Phiên bản format của flow log (hiện thường là 2).
account-id: ID của AWS account sở hữu resource.
interface-id: ID của Elastic Network Interface (ENI) gắn với EC2, ALB, NAT Gateway, v.v.→ Đây là “điểm” mà traffic đi qua.
srcaddr (source address): IP nguồn gửi request.
dstaddr (destination address): IP đích nhận request.
srcport (source port): Port phía client (thường là port random).
dstport (destination port): Port phía server (ví dụ: 22 = SSH, 80 = HTTP, 443 = HTTPS).
protocol: Giao thức mạng:
- 6 = TCP
- 17 = UDP
- 1 = ICMP
packets: Số lượng packet truyền trong flow này.
bytes: Tổng số byte dữ liệu đã truyền.
start: Thời điểm bắt đầu flow (Unix timestamp).
end: Thời điểm kết thúc flow (Unix timestamp).
action: Kết quả:
- ACCEPT: traffic được cho phép (qua Security Group / NACL)
- REJECT: bị chặn
log-status: Trạng thái log:
- OK: log ghi bình thường
- NODATA: không có traffic

Một bản ghi Flow Log chứa các thông tin giúp bạn giải mã “ai đã làm gì” trong mạng:

srcaddr & dstaddr: Địa chỉ IP nguồn và đích. Giúp xác định các máy chủ đang giao tiếp với nhau.
srcport & dstport: Cổng nguồn và cổng đích. Giúp xác định ứng dụng hoặc dịch vụ nào đang được sử dụng (ví dụ: port 80/443 là Web).
Protocol: Giao thức mạng (TCP, UDP, ICMP,…).
Action: Trạng thái của gói tin:
- ACCEPT: Lưu lượng được cho phép bởi Security Group và NACL.
- REJECT: Lưu lượng bị chặn bởi Security Group hoặc NACL. Đây là chìa khóa để xử lý sự cố kết nối.

Dữ liệu Flow Logs sau khi thu thập có thể được gửi đến hai nơi chính:

S3 Bucket: Phù hợp để lưu trữ lâu dài và phân tích chuyên sâu bằng Amazon Athena (sử dụng SQL để truy vấn logs).
CloudWatch Logs: Phù hợp để theo dõi thời gian thực, thiết lập cảnh báo (Alarms) và phân tích nhanh bằng CloudWatch Logs Insights.

Gỡ lỗi kết nối (Troubleshooting): Nếu bạn không thể kết nối tới EC2, hãy kiểm tra Flow Logs. Nếu thấy REJECT, nghĩa là Security Group hoặc NACL của bạn đang chặn lưu lượng đó.
Giám sát an ninh: Phát hiện các hành vi bất thường (malicious behavior), ví dụ: một IP lạ liên tục quét các cổng (port scanning) của hệ thống.
Tối ưu hóa chi phí: Phân tích lượng dữ liệu truyền tải giữa các AZ hoặc ra Internet để tìm cách giảm chi phí NAT Gateway.

Cách để troubleshoot cho SG và NACL issue:

Giả sử là incoming request:

Inbound REJECT → NACL hoặc SG

Inbound ACCEPT, Outbound REJECT → NACL (Stateless)

Giả sử là outgoing request:

Outbound REJECT → NACL hoặc SG

Outbound ACCEPT, Inbound REJECT → NACL (Stateless)

1. Phân tích realtime với CloudWatch Logs + Contributor Insights

Luồng: VPC Flow Logs → CloudWatch Logs → CloudWatch Contributor Insights → Top-N (IP, port,…)
Mô tả:
- Flow Logs được đẩy trực tiếp vào CloudWatch Logs.
- Sử dụng Contributor Insights để phân tích log theo thời gian thực.
- Tự động tổng hợp các “top talkers” như:
  - Top IP truy cập nhiều nhất
  - Top port được sử dụng
  - Top nguồn gây traffic bất thường
Use case:
- Phát hiện bất thường nhanh (DDoS nhẹ, scan port)
- Debug network issue realtime
- Không cần query thủ công
Đặc điểm:
- Gần realtime
- Không cần ETL
- Chi phí CloudWatch có thể cao nếu log lớn

2. Monitoring & Alerting với CloudWatch Alarm + SNS

Luồng: VPC Flow Logs → CloudWatch Logs → Metric Filter → CloudWatch Alarm → SNS
Mô tả:
- Tạo Metric Filter từ log (ví dụ: detect SSH, RDP, traffic bị reject…)
- Convert log thành metric
- Dùng CloudWatch Alarm để trigger khi vượt threshold
- Gửi cảnh báo qua SNS (email, Slack, webhook…)
Ví dụ:
- Có nhiều kết nối SSH (port 22) từ IP lạ
- Tăng đột biến traffic bị REJECT
- RDP access từ internet
Use case:
- Security monitoring
- Compliance / audit
- Alert tự động
Đặc điểm:
- Gần realtime
- Chủ động cảnh báo
- Cần define rule trước (không linh hoạt bằng query)

3. Phân tích batch với S3 + Athena + QuickSight

Luồng: VPC Flow Logs → S3 → Athena → QuickSight
Mô tả:
- Flow Logs được lưu vào S3 (chi phí rẻ, lưu trữ dài hạn)
- Dùng Athena để query bằng SQL
- Dùng QuickSight để visualize dashboard
Use case:
- Phân tích lịch sử traffic
- Audit / forensic
- Cost optimization (xem traffic pattern)
- Report cho business / security team
Đặc điểm:
- Không realtime (batch)
- Linh hoạt query (SQL)
- Chi phí thấp hơn CloudWatch khi data lớn

Khi doanh nghiệp muốn mở rộng hạ tầng từ văn phòng (On-premises) lên đám mây (AWS), việc thiết lập một đường truyền bảo mật và ổn định là yếu tố sống còn. Có hai giải pháp chính để thực hiện việc này: Site-to-Site VPN và Direct Connect.

Đây là cách nhanh nhất và kinh tế nhất để kết nối mạng nội bộ của bạn với AWS thông qua môi trường Internet.

Các thành phần cần thiết:

Virtual Private Gateway (VGW): “Cổng chào” nằm ở phía VPC của AWS.
Customer Gateway (CGW): Thiết bị phần cứng hoặc phần mềm (Router/Firewall) nằm ở phía mạng On-premises của bạn.
VPN Tunnel: VPN sẽ thiết lập 2 đường ống (tunnels) được mã hóa để truyền dữ liệu một cách bảo mật xuyên qua Internet công cộng.

Mẹo thi cử (Exam Tips):

VPC to VPC: Sử dụng VPC Peering.

Corporate Data Center to VPC: Sử dụng Site-to-Site VPN (nếu cần triển khai nhanh và chi phí thấp).

Khác với VPN đi qua Internet, Direct Connect cung cấp một kết nối vật lý riêng biệt (Dedicated), trực tiếp từ trung tâm dữ liệu của bạn đến AWS.

Đặc điểm nổi bật:

Hiệu năng: Tăng băng thông (throughput), giảm độ trễ (latency) và mang lại trải nghiệm mạng cực kỳ ổn định.
Bảo mật: Dữ liệu không đi qua Internet công cộng.
Khả năng truy cập: Cho phép truy cập cả tài nguyên Public (S3, DynamoDB) và Private (EC2) trên cùng một đường truyền.

Các loại kết nối Direct Connect:

Dedicated Connections:
- Cung cấp các mức băng thông cực lớn: 1 Gbps, 10 Gbps, 100 Gbps.
- Bạn sở hữu riêng một cổng Ethernet vật lý.
- Phù hợp cho các tập đoàn lớn với nhu cầu truyền tải dữ liệu khổng lồ.
- Request sẽ tới AWS trước, sau đó hoàn thành ở AWS Direct Connect Partners
Hosted Connections:
- Băng thông linh hoạt hơn: Từ 50 Mbps, 500 Mbps đến 10 Gbps.
- Kết nối thông qua các đối tác của AWS (Direct Connect Partners).
- Có thể tăng hoặc giảm dung lượng theo nhu cầu thực tế.
- 1, 2, 5, 10 Gbps available at select AWS Direct Connect Partners

Lưu ý về chi phí và thời gian:

Chi phí: Rất tốn kém (bao gồm phí cổng, phí truyền tải dữ liệu và phí thuê đường dây vật lý).
Thời gian: Việc kéo cáp vật lý thường mất rất nhiều thời gian (có thể lên đến 30 ngày hoặc hơn).

Mẹo thi cử (Exam Tips):

Khi đề bài yêu cầu tốc độ cao và ổn định nhất, nhưng không quan tâm đến thời gian triển khai lâu hay chi phí đắt đỏ: Hãy chọn Direct Connect.

Nếu cần kết nối ngay lập tức (trong vòng vài giờ/ngày) với chi phí thấp: Hãy chọn VPN.

Backup Connection: Trong trường hợp Direct Connect fails, ta có thể cài đặt một back-up Direct Connect (đắt đỏ) hoặc Site-to-Site VPN connection.

[AWS] Chương 4: Virtual Private Cloud (VPC)

1. Kiến thức cơ bản

1.1. Khái niệm về CIDR và Subnet Mask

1.2. Phân biệt Public IP và Private IP (IPv4)

1.3. Đặc điểm của Amazon VPC

2. Subnet

2.1. Tổng quan về Subnet

2.2. Phân loại Subnet trong thực tế

3. Internet Gateway (IGW)

4. Route Table (Bảng định tuyến)

4.1. Route Table là gì?

4.2. Main Route Table

5. Quy trình cấu hình VPC, Subnet, IGW

6. Bastion Hosts: Máy chủ nhảy (Jump Server)

6.1. Bối cảnh và Thách thức

6.2. Giải pháp: Bastion Host

6.3. Các quy tắc cấu hình quan trọng (Security Best Practices)

7. NAT Gateway: Cầu nối một chiều cho Private Subnet

7.1. NAT là gì?

7.2. Tại sao cần NAT Gateway trong AWS?

7.3. Đặc điểm kỹ thuật của AWS NAT Gateway

7.4. Cách thức hoạt động và Định tuyến (Route)

7.5. NAT Gateway với High Availability

7.6. NAT Gateway vs NAT Instance

8. Security Groups và NACLs (Network Access Control Lists)

8.1. Kiến thức nền

8.2. Security Group (SG)

8.3. Network ACL (NACL)

8.4. So sánh Security Group vs NACL

8.5. Ví dụ về luồng đi của dữ liệu (Traffic Flow)

8.6. Phân tích về Ephemeral Ports (Cổng tạm thời)

9. VPC Peering

9.1. VPC Peering là gì?

9.2. Các quy tắc và Đặc điểm quan trọng

9.3. Thông tin bổ trợ (Good to know)

10. VPC Endpoints (AWS PrivateLink)

10.1. Interface Endpoints (Powered by PrivateLink)

10.2. Gateway Endpoints

10.3. Bảng so sánh và Mẹo thi cử (Exam Tips)

11. VPC Flow Logs

11.1. Giới thiệu

11.2. Cấu trúc và Các trường thông tin quan trọng

11.3. Lưu trữ và Phân tích dữ liệu

11.4. Các trường hợp sử dụng thực tế

11.5. Một số kiến trúc phổ biến

12. Kết nối Hybrid Cloud: AWS Site-to-Site VPN & Direct Connect

12.1. AWS Site-to-Site VPN

12.2. AWS Direct Connect (DX)

Top bài viết trong tháng

Chuyên mục

Danh mục

Bài viết mới nhất

Bài viết mới

Liên hệ với chúng tôi

Đến HBLAB và phát triển cùng nhau nhé!

Trụ sở Việt Nam

Văn phòng Nhật Bản

Văn phòng Hàn Quốc

Văn phòng Singapore

Đăng ký nhận thông tin mới

FORM ỨNG TUYỂN