Amazon VPC – Mạng riêng trên AWS

1. Bức tranh toàn cảnh một VPC

Đây là chương dài nhất của kỳ thi, nên trước khi đi vào từng thành phần, hãy nhìn một lần cái sơ đồ tổng mà slide mở đầu bằng. Trong một Region, bạn có một VPC; bên trong VPC là các Availability Zone, mỗi AZ chứa Public Subnet và Private Subnet. Traffic đi ra Internet qua Internet Gateway, được Router và Route Table dẫn đường; máy trong private subnet ra Internet nhờ NAT Gateway. Việc chặn/mở cổng có hai lớp: Security Group ở mức instance và NACL ở mức subnet.

Ra bên ngoài VPC, sơ đồ đó còn có: VPC Peering Connections để nối hai VPC, VPC Endpoint để đi tới S3, Amazon DynamoDB và CloudWatch mà không cần Internet, VPC Flow Logs để ghi lại lưu lượng, rồi hai đường nối về Corporate Data Center: một S2S VPN Connection (qua VPN Gateway + Customer Gateway) và một Direct Connect Connection qua DX Location. Cuối cùng, Transit Gateway là cái trung tâm nối tất cả những thứ đó lại với nhau.

Mọi mục dưới đây là một mảnh của chính sơ đồ này. Nếu bị rối, hãy quay lại đoạn trên và định vị xem thành phần đang học nằm ở đâu.

2. Hiểu CIDR – nền tảng của mọi thứ

CIDR (Classless Inter-Domain Routing) là một phương pháp cấp phát địa chỉ IP. Bạn sẽ gặp nó trong rule của Security Group và trong networking của AWS nói chung, vì nó là cách để định nghĩa một dải địa chỉ IP.

Bạn đã thấy hai trường hợp cực đoan: WW.XX.YY.ZZ/32 nghĩa là đúng một IP, còn 0.0.0.0/0 nghĩa là tất cả IP. Nhưng CIDR cho phép định nghĩa mọi mức ở giữa: 192.168.0.0/26 là dải 192.168.0.0 – 192.168.0.63, tức 64 địa chỉ.

Một CIDR gồm hai thành phần:

Base IP — một IP nằm trong dải, dạng XX.XX.XX.XX. Ví dụ: 10.0.0.0, 192.168.0.0.
Subnet Mask — định nghĩa bao nhiêu bit trong IP được phép thay đổi. Ví dụ /0, /24, /32. Subnet mask viết được theo hai dạng:

Dạng ngắn	Dạng đầy đủ
`/8`	`255.0.0.0`
`/16`	`255.255.0.0`
`/24`	`255.255.255.0`
`/32`	`255.255.255.255`

Subnet Mask quyết định kích thước dải

Về bản chất, Subnet Mask cho phép một phần của IP bên dưới nhận thêm các giá trị kế tiếp tính từ Base IP. Số địa chỉ luôn là một lũy thừa của 2:

CIDR	Số IP	Dải địa chỉ
`192.168.0.0/32`	1	`192.168.0.0`
`192.168.0.0/31`	2	`192.168.0.0` → `192.168.0.1`
`192.168.0.0/30`	4	`192.168.0.0` → `192.168.0.3`
`192.168.0.0/29`	8	`192.168.0.0` → `192.168.0.7`
`192.168.0.0/28`	16	`192.168.0.0` → `192.168.0.15`
`192.168.0.0/27`	32	`192.168.0.0` → `192.168.0.31`
`192.168.0.0/26`	64	`192.168.0.0` → `192.168.0.63`
`192.168.0.0/25`	128	`192.168.0.0` → `192.168.0.127`
`192.168.0.0/24`	256	`192.168.0.0` → `192.168.0.255`
`192.168.0.0/16`	65.536	`192.168.0.0` → `192.168.255.255`
`192.168.0.0/0`	Tất cả	`0.0.0.0` → `255.255.255.255`

Slide còn cho một mẹo nhớ rất nhanh, dựa trên việc một IPv4 có 4 octet:

/32 — không octet nào được thay đổi.
/24 — octet cuối được thay đổi.
/16 — 2 octet cuối được thay đổi.
/8 — 3 octet cuối được thay đổi.
/0 — tất cả octet được thay đổi.

Bài tập nhỏ để tự kiểm tra

CIDR	Kết quả
`192.168.0.0/24`	`192.168.0.0 – 192.168.0.255` (256 IP)
`192.168.0.0/16`	`192.168.0.0 – 192.168.255.255` (65.536 IP)
`134.56.78.123/32`	Đúng một IP: `134.56.78.123`
`0.0.0.0/0`	Tất cả IP

Khi không chắc, slide gợi ý dùng trang https://www.ipaddressguide.com/cidr để tính nhanh dải địa chỉ của một CIDR. Trong phòng thi thì không có công cụ, nên mẹo “octet nào được thay đổi” ở trên là thứ đáng học thuộc.

Public IP so với Private IP (IPv4)

IANA (Internet Assigned Numbers Authority) đã dành riêng một số block IPv4 cho mục đích private (LAN), phần còn lại là public (Internet). Private IP chỉ được phép nằm trong ba dải sau:

Dải private	CIDR	Ghi chú của slide
`10.0.0.0 – 10.255.255.255`	`10.0.0.0/8`	Dùng trong các mạng lớn
`172.16.0.0 – 172.31.255.255`	`172.16.0.0/12`	Default VPC của AWS nằm trong dải này
`192.168.0.0 – 192.168.255.255`	`192.168.0.0/16`	Ví dụ: mạng gia đình

Toàn bộ địa chỉ còn lại trên Internet là Public.

3. VPC và Subnet

VPC = Virtual Private Cloud — mạng riêng của bạn trong một Region. Mọi AWS account mới đều có một default VPC; EC2 instance mới sẽ được launch vào default VPC nếu bạn không chỉ định subnet. Default VPC có sẵn kết nối Internet và mọi EC2 instance trong đó đều có public IPv4 address, kèm theo một public DNS name và một private DNS name dạng IPv4.

Khi tự tạo VPC, các giới hạn sau hay bị hỏi:

Bạn có thể có nhiều VPC trong một AWS region — tối đa 5 mỗi region, và đây là soft limit (xin tăng được).
Tối đa 5 CIDR cho mỗi VPC. Với mỗi CIDR:
- Kích thước nhỏ nhất là /28 (16 địa chỉ IP).
- Kích thước lớn nhất là /16 (65.536 địa chỉ IP).
Vì VPC là mạng private, chỉ các dải Private IPv4 ở bảng trên được phép.
CIDR của VPC KHÔNG được trùng lặp (overlap) với các mạng khác của bạn, ví dụ mạng của công ty.

Subnet và 5 địa chỉ IP bị AWS giữ lại

Subnet là phần chia nhỏ của VPC và gắn với một AZ; bạn định nghĩa CIDR riêng cho nó. Điều cần nhớ nhất: AWS giữ lại 5 địa chỉ IP trong mỗi subnet — 4 địa chỉ đầu và 1 địa chỉ cuối. Năm địa chỉ này không dùng được và không gán được cho EC2 instance.

Với CIDR block 10.0.0.0/24, năm địa chỉ đó là:

Địa chỉ	Vai trò
`10.0.0.0`	Network Address
`10.0.0.1`	AWS giữ cho VPC router
`10.0.0.2`	AWS giữ để mapping tới Amazon-provided DNS
`10.0.0.3`	AWS giữ cho mục đích tương lai
`10.0.0.255`	Network Broadcast Address — AWS không hỗ trợ broadcast trong VPC nên địa chỉ này bị giữ lại

4. Internet Gateway và Route Table

Internet Gateway (IGW) cho phép các resource trong VPC (ví dụ EC2 instance) kết nối ra Internet. Nó scale theo chiều ngang, highly available và redundant — bạn không phải lo về kích thước hay dự phòng cho nó.

IGW phải được tạo riêng, tách khỏi VPC.
Một VPC chỉ gắn được với một IGW và ngược lại — quan hệ một–một.
Và đây là điểm bẫy: bản thân Internet Gateway KHÔNG tự cho phép truy cập Internet. Route table cũng phải được sửa!

Route table là thứ nói cho Router của VPC biết gói tin đi đâu. Một subnet trở thành public subnet đúng khi route table gắn với nó có một route trỏ ra IGW; nếu không có route đó, subnet vẫn là private dù IGW đã được attach vào VPC.

Vì vậy “đã tạo và attach Internet Gateway nhưng EC2 vẫn không ra được Internet” là một tình huống kinh điển trong đề thi, và đáp án gần như luôn là thiếu route trong Route Table, chứ không phải thiếu IGW.

5. Bastion Host

Bạn có thể dùng một Bastion Host để SSH vào các EC2 instance nằm trong private subnet. Ý tưởng: bastion nằm ở public subnet, và nó có kết nối tới tất cả các private subnet còn lại. Người dùng SSH vào bastion, rồi từ bastion SSH tiếp vào máy private — nhờ vậy các máy private không cần public IP nào cả.

Cấu hình Security Group phải đúng đôi:

Security Group của Bastion Host phải cho phép inbound từ Internet trên port 22, và chỉ từ một CIDR bị giới hạn — ví dụ public CIDR của công ty bạn.
Security Group của các EC2 Instance phải cho phép Security Group của Bastion Host, hoặc private IP của Bastion Host.

Trong diagram, hai security group được đặt tên BastionHost-SG và LinuxInstance-SG, và có đúng hai mũi tên SSH: từ Users vào bastion, rồi từ bastion vào instance trong private subnet.

6. NAT Instance

NAT = Network Address Translation. Slide gắn thẳng nhãn “outdated, but still at the exam” cho NAT Instance — công nghệ đã cũ nhưng vẫn ra thi, nên vẫn phải học.

NAT Instance cho phép EC2 instance trong private subnet kết nối ra Internet. Các điều kiện bắt buộc:

Phải được launch trong một public subnet.
Phải tắt setting Source / destination Check của EC2 — vì NAT instance phải nhận và gửi gói tin với IP không phải của nó.
Phải gắn một Elastic IP.
Route Table phải được cấu hình để đẩy traffic từ các private subnet sang NAT Instance.

Diagram minh họa việc dịch địa chỉ rất rõ. Máy private có IP 10.0.0.20, NAT Instance có EIP 12.34.56.78, server đích trên Internet có IP 50.60.4.10. Bốn chặng của gói tin:

Chặng	Source	Destination
Máy private → NAT	`10.0.0.20`	`50.60.4.10`
NAT → Internet	`12.34.56.78`	`50.60.4.10`
Internet → NAT	`50.60.4.10`	`12.34.56.78`
NAT → máy private	`50.60.4.10`	`10.0.0.20`

Đó chính là “translation”: NAT thay source IP private bằng IP public của mình khi đi ra, và làm ngược lại khi gói trả về.

Những hạn chế của NAT Instance

Có AMI Amazon Linux được cấu hình sẵn cho mục đích này, nhưng nó đã kết thúc standard support từ ngày 31/12/2020.
Không highly available / resilient sẵn. Muốn có thì bạn phải tự tạo một ASG multi-AZ cộng với user-data script resilient.
Băng thông Internet phụ thuộc vào EC2 instance type.
Bạn phải tự quản lý Security Group và rule:
- Inbound: cho phép traffic HTTP / HTTPS đến từ các Private Subnet; cho phép SSH từ mạng nhà bạn (truy cập này đi qua Internet Gateway).
- Outbound: cho phép traffic HTTP / HTTPS ra Internet.

7. NAT Gateway

NAT Gateway là bản NAT do AWS quản lý, với băng thông cao hơn, high availability, và không cần administration. Bạn trả tiền theo giờ sử dụng và theo băng thông.

NATGW được tạo trong một Availability Zone cụ thể và dùng một Elastic IP.
Không dùng được bởi EC2 instance nằm trong cùng subnet với nó — chỉ các subnet khác dùng được.
Bắt buộc phải có IGW, đường đi là: Private Subnet ⇒ NATGW ⇒ IGW.
5 Gbps băng thông, tự động scale lên tới 100 Gbps.
Không có Security Group nào phải quản lý / cần thiết.

High Availability cho NAT Gateway

NAT Gateway chỉ resilient trong phạm vi một Availability Zone.
Muốn fault-tolerance thì phải tạo nhiều NAT Gateway ở nhiều AZ.
Và đây là lý luận đáng nhớ: không cần cross-AZ failover, vì nếu một AZ sập thì AZ đó cũng chẳng cần NAT nữa.

Diagram vẽ hai AZ (AZ-A và AZ-B), mỗi AZ có một public subnet chứa NAT Gateway riêng và một private subnet chứa EC2 instance; hai đường NAT độc lập cùng đi qua Router ra Internet Gateway.

NAT Gateway so với NAT Instance

Tiêu chí	NAT Gateway	NAT Instance
Availability	Highly available trong một AZ (muốn thêm thì tạo ở AZ khác)	Dùng script để quản lý failover giữa các instance
Bandwidth	Lên tới 100 Gbps	Phụ thuộc EC2 instance type
Maintenance	Managed by AWS	Bạn tự quản lý (software, OS patch…)
Cost	Theo giờ và theo lượng dữ liệu truyền	Theo giờ, theo EC2 instance type và size, cộng chi phí network

Bảng gốc trong slide còn so sánh thêm bốn tiêu chí nữa (Public IPv4, Private IPv4, Security Groups, và “dùng làm Bastion Host được không”). Riêng phần Security Group thì các slide khác đã nói rõ: NAT Gateway không có Security Group nào để quản lý, còn NAT Instance thì bạn phải tự quản lý cả inbound và outbound rule.

8. Security Group và NACL

Đây là hai lớp firewall của VPC, và việc phân biệt chúng là một trong những chủ đề ra thi nhiều nhất của cả chương.

Gói tin đi qua hai lớp theo thứ tự nào

Với incoming request đi vào một EC2 instance trong subnet, thứ tự là: NACL Inbound Rules → SG Inbound Rules → tới instance. Khi instance trả lời, chiều ra đi qua NACL Outbound Rules và đây là điểm mấu chốt: Security Group là stateful nên outbound của response được cho phép tự động, còn NACL là stateless nên rule outbound vẫn được đánh giá.

Với outgoing request phát ra từ instance thì đối xứng: SG Outbound Rules → NACL Outbound Rules → ra ngoài; gói trả về đi qua NACL Inbound Rules (stateless, phải có rule) trong khi SG cho phép inbound tự động (stateful).

Network Access Control List (NACL)

NACL hoạt động như một firewall kiểm soát traffic đi vào và đi ra khỏi subnet. Mỗi subnet có một NACL; subnet mới được gán Default NACL.

Bạn định nghĩa NACL Rules theo các quy tắc sau:

Mỗi rule có một số từ 1 đến 32766; số càng nhỏ thì độ ưu tiên càng cao.
Rule khớp đầu tiên sẽ quyết định kết quả. Ví dụ: nếu bạn định nghĩa #100 ALLOW 10.0.0.10/32 và #200 DENY 10.0.0.10/32 thì IP đó được cho phép, vì 100 ưu tiên cao hơn 200.
Rule cuối cùng là dấu hoa thị * và nó deny request khi không rule nào khớp.
AWS khuyến nghị thêm rule theo bước nhảy 100 để sau này còn chỗ chèn.
NACL mới tạo sẽ deny mọi thứ.
NACL là cách rất tốt để chặn một IP address cụ thể ở mức subnet — điều mà Security Group không làm được vì nó chỉ có allow rule.

Default NACL

Default NACL chấp nhận mọi thứ inbound/outbound với các subnet mà nó được associate. Slide cảnh báo: KHÔNG sửa Default NACL, hãy tạo custom NACL thay thế.

Đây là nội dung Default NACL của một VPC hỗ trợ IPv4:

Chiều	Rule #	Type	Protocol	Port Range	Source / Destination	Allow/Deny
Inbound	100	All IPv4 Traffic	All	All	`0.0.0.0/0`	ALLOW
Inbound	`*`	All IPv4 Traffic	All	All	`0.0.0.0/0`	DENY
Outbound	100	All IPv4 Traffic	All	All	`0.0.0.0/0`	ALLOW
Outbound	`*`	All IPv4 Traffic	All	All	`0.0.0.0/0`	DENY

Ephemeral Ports

Vì NACL là stateless, bạn buộc phải hiểu ephemeral port mới cấu hình đúng được. Để hai endpoint thiết lập một kết nối, chúng phải dùng port: client kết nối tới một port đã định, và chờ response trên một ephemeral port.

Các hệ điều hành khác nhau dùng dải port khác nhau, hai ví dụ trong slide:

Hệ điều hành	Dải ephemeral port
IANA & MS Windows 10	`49152 – 65535`
Nhiều Linux Kernel	`32768 – 60999`

Diagram minh họa: Web Server ở 55.66.77.88 với fixed port 443; client ở 11.22.33.44 với ephemeral port 50105. Gói request có Dest. IP 55.66.77.88, Dest. Port 443, Src. IP 11.22.33.44, Src. Port 50105. Gói response đảo lại hoàn toàn: Src. IP 55.66.77.88, Src. Port 443, Dest. IP 11.22.33.44, Dest. Port 50105.

NACL với ephemeral port — kiến trúc hai tầng

Slide lấy ví dụ một VPC có Web Subnet (Public) chứa Web Tier và DB Subnet (Private) chứa DB Instance ở Port 3306. Bốn rule cần thiết, chia cho hai NACL:

NACL	Rule cần có
Web-NACL	Allow Outbound TCP trên port 3306 tới DB Subnet CIDR
Web-NACL	Allow Inbound TCP trên port 1024-65535 từ DB Subnet CIDR
DB-NACL	Allow Inbound TCP trên port 3306 từ Web Subnet CIDR
DB-NACL	Allow Outbound TCP trên port 1024-65535 tới Web Subnet CIDR

Hai rule với dải 1024-65535 chính là đường về cho response — thứ mà Security Group sẽ tự lo, còn NACL thì không.

Khi hệ thống có nhiều AZ (Web Subnet A/B và DB Subnet A/B, mỗi DB Subnet một DB Instance), nguyên tắc mở rộng là: tạo NACL rule cho CIDR của từng subnet đích. Số rule nhân lên theo số subnet, đó cũng là lý do NACL bị coi là khó bảo trì hơn Security Group.

Security Group so với NACL

Security Group	NACL
Hoạt động ở mức instance	Hoạt động ở mức subnet
Chỉ hỗ trợ allow rule	Hỗ trợ cả allow rule và deny rule
Stateful: return traffic được cho phép tự động, bất kể rule là gì	Stateless: return traffic phải được rule cho phép tường minh (nhớ ephemeral port)
Tất cả rule được đánh giá trước khi quyết định cho traffic đi qua	Rule được đánh giá theo thứ tự (số nhỏ đến số lớn), khớp đầu tiên thắng
Áp dụng cho một EC2 instance khi có người chỉ định	Tự động áp dụng cho mọi EC2 instance trong subnet mà nó được associate

9. VPC Peering

VPC Peering cho phép kết nối riêng tư hai VPC bằng mạng của AWS, khiến chúng hoạt động như thể đang ở trong cùng một mạng. Ba điều bắt buộc phải nhớ:

Không được có CIDR trùng lặp (overlapping) giữa hai VPC.
VPC Peering connection KHÔNG có tính transitive — phải thiết lập cho từng cặp VPC cần nói chuyện với nhau. Nếu A peer B và B peer C thì A không tự động tới được C; bạn phải tạo thêm peering A–C. Diagram vẽ đúng ba VPC A/B/C với ba peering connection.
Bạn phải cập nhật route table trong subnet của từng VPC để EC2 instance hai bên liên lạc được.

Hai điểm “good to know” rất hay ra thi:

Bạn tạo được VPC Peering connection giữa các VPC ở các AWS account / region khác nhau.
Bạn tham chiếu được một security group ở VPC đã peer — cách này hoạt động cross-account nhưng phải cùng region.

10. VPC Endpoints (AWS PrivateLink)

Mọi dịch vụ AWS đều được expose công khai qua một public URL. Điều đó có nghĩa là mặc định, EC2 instance trong private subnet muốn gọi SNS hay S3 thì phải đi ra Internet — cần NAT Gateway và IGW, tốn tiền và mở rộng bề mặt tấn công.

VPC Endpoints (được vận hành bởi AWS PrivateLink) giải quyết đúng việc đó: cho phép bạn kết nối tới các dịch vụ AWS qua mạng private thay vì qua public Internet.

Chúng redundant và scale theo chiều ngang.
Chúng loại bỏ nhu cầu về IGW, NATGW… để truy cập AWS Services.
Khi gặp sự cố, slide chỉ đúng hai chỗ cần kiểm tra:
- DNS Setting Resolution trong VPC của bạn.
- Route Tables.

Hai loại Endpoint

	Interface Endpoints	Gateway Endpoints
Cơ chế	Được vận hành bởi PrivateLink; provision một ENI (private IP address) làm điểm vào, phải gắn Security Group	Provision một gateway và phải được dùng làm target trong route table; không dùng security group
Dịch vụ hỗ trợ	Hầu hết các dịch vụ AWS	Chỉ S3 và DynamoDB
Giá	$ theo giờ + $ theo GB dữ liệu được xử lý	Miễn phí

Gateway hay Interface Endpoint cho S3?

Gateway gần như luôn là lựa chọn được ưu tiên trong đề thi.
Chi phí: Gateway miễn phí, interface endpoint có phí.
Interface Endpoint được ưu tiên khi cần truy cập từ on-premises (qua Site to Site VPN hoặc Direct Connect), từ một VPC khác, hoặc từ một region khác.

Ví dụ: Lambda trong VPC truy cập DynamoDB

DynamoDB là một public service của AWS, nên có hai cách cho một Lambda function nằm trong VPC gọi nó:

Option 1: truy cập qua public internet. Vì Lambda đang ở trong VPC, nó cần một NAT Gateway ở public subnet và một internet gateway.
Option 2 (tốt hơn và miễn phí): truy cập qua mạng private của VPC. Deploy một VPC Gateway endpoint cho DynamoDB và sửa Route Tables.

AWS PrivateLink / VPC Endpoint Services và ClassicLink

Slide tổng kết của chương nhắc thêm hai thứ nằm cùng họ:

AWS PrivateLink / VPC Endpoint Services — kết nối dịch vụ một cách riêng tư từ VPC dịch vụ của bạn sang VPC của khách hàng. Nó không cần VPC Peering, không cần public Internet, không cần NAT Gateway, không cần Route Tables, và phải được dùng cùng Network Load Balancer & ENI.
ClassicLink — kết nối các EC2 instance EC2-Classic một cách riêng tư vào VPC của bạn.

11. VPC Flow Logs

VPC Flow Logs ghi lại thông tin về IP traffic đi vào các interface của bạn, ở ba mức:

VPC Flow Logs
Subnet Flow Logs
Elastic Network Interface (ENI) Flow Logs

Công dụng chính là monitor và troubleshoot các vấn đề kết nối. Dữ liệu flow log đi được tới S3, CloudWatch Logs, và Kinesis Data Firehose. Một điểm rất hay ra thi: nó ghi được thông tin network từ cả các interface do AWS quản lý — ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway…

Cú pháp của một dòng flow log

Một record gồm các field sau, theo đúng thứ tự trong slide:

version account-id interface-id srcaddr dstaddr srcport dstport
protocol packets bytes start end action log-status

Trong đó những field đáng quan tâm nhất:

srcaddr và dstaddr — giúp nhận diện IP có vấn đề.
srcport và dstport — giúp nhận diện port có vấn đề.
action — thành công hay thất bại của request do Security Group / NACL.

Flow log dùng được để phân tích pattern sử dụng hoặc hành vi độc hại (malicious behavior), và bạn query nó bằng Athena trên S3 hoặc bằng CloudWatch Logs Insights (xem thêm Monitoring & Audit).

Dùng Flow Logs để debug Security Group và NACL

Đây là bảng suy luận mà slide gói lại thành một câu: hãy nhìn field ACTION.

Chiều request	Hiện tượng	Nguyên nhân
Incoming	Inbound REJECT	NACL hoặc SG
Incoming	Inbound ACCEPT, Outbound REJECT	NACL
Outgoing	Outbound REJECT	NACL hoặc SG
Outgoing	Outbound ACCEPT, Inbound REJECT	NACL

Lý do rất logic: nếu chiều đi đã ACCEPT mà chiều về bị REJECT thì Security Group đã stateful nên không thể là nó — chỉ còn NACL stateless.

Ba kiến trúc phân tích Flow Logs

Slide vẽ ba đường ống, mỗi cái cho một mục đích khác nhau:

VPC Flow Logs → CloudWatch Logs → Metric Filter → CW Alarm → Amazon SNS — bắt các sự kiện như SSH, RDP… rồi gửi Alert.
VPC Flow Logs → CloudWatch Logs → CloudWatch Contributor Insights — tìm ra Top-10 IP addresses.
VPC Flow Logs → S3 Bucket → Amazon Athena → Amazon QuickSight — phân tích và trực quan hóa lượng lớn log.

12. AWS Site-to-Site VPN

Site-to-Site VPN nối Corporate Data Center của bạn với VPC qua public Internet nhưng được mã hóa. Nó cần đúng hai đầu:

Virtual Private Gateway (VGW)
- Là VPN concentrator ở phía AWS của kết nối VPN.
- VGW được tạo và attach vào VPC mà bạn muốn tạo Site-to-Site VPN connection từ đó.
- Có thể custom ASN (Autonomous System Number).
Customer Gateway (CGW)
- Là software application hoặc thiết bị vật lý ở phía khách hàng của kết nối VPN.

Những chi tiết cấu hình hay ra thi

Customer Gateway Device (on-premises) dùng IP nào?
- Public IP address route được trên Internet của thiết bị Customer Gateway.
- Nếu nó nằm sau một NAT device có bật NAT traversal (NAT-T), hãy dùng public IP của NAT device.
Bước quan trọng: bật Route Propagation cho Virtual Private Gateway trong route table được associate với các subnet của bạn.
Nếu bạn cần ping EC2 instance từ on-premises, hãy thêm protocol ICMP vào inbound của Security Group. Ping không chạy bằng TCP nên rule TCP thông thường không đủ.

AWS VPN CloudHub

AWS VPN CloudHub cung cấp kết nối an toàn giữa nhiều site, dùng khi bạn có nhiều VPN connection. Nó là một mô hình hub-and-spoke chi phí thấp cho kết nối mạng chính hoặc dự phòng giữa các địa điểm khác nhau (chỉ VPN).

Nó là một kết nối VPN nên vẫn đi qua public Internet.
Cách thiết lập: nối nhiều VPN connection vào cùng một VGW, thiết lập dynamic routing và cấu hình route table.

Diagram cho thấy ba Customer Network, mỗi mạng có một Customer Gateway, tất cả cùng nối vào một Virtual Private Gateway (VGW) của VPC — và nhờ đó các site cũng nói chuyện được với nhau qua cái hub đó.

13. AWS Direct Connect (DX)

Direct Connect cung cấp một kết nối private riêng (dedicated) từ một mạng ở xa tới VPC của bạn — không đi qua public Internet chút nào.

Kết nối dedicated phải được thiết lập giữa data center của bạn và các AWS Direct Connect location.
Bạn cần thiết lập một Virtual Private Gateway trên VPC — giống Site-to-Site VPN.
Truy cập được cả public resource (S3) và private resource (EC2) trên cùng một kết nối.
Hỗ trợ cả IPv4 và IPv6.

Use case theo slide:

Tăng bandwidth throughput — khi làm việc với tập dữ liệu lớn, và chi phí thấp hơn.
Trải nghiệm mạng nhất quán hơn — cho các ứng dụng dùng real-time data feed.
Môi trường Hybrid (on-premise + cloud).

Về mặt vật lý, diagram mô tả chuỗi: Corporate data center → Customer router/firewall → cage của khách hàng hoặc partner tại AWS Direct Connect Location → AWS Direct Connect Endpoint trong AWS Cage → vào Region. Trên kết nối đó có hai VLAN: một Private virtual interface đi tới Virtual Private Gateway rồi vào private subnet chứa EC2 instance, và một Public virtual interface đi tới Amazon S3 / Amazon Glacier.

Direct Connect Gateway

Nếu bạn muốn thiết lập một Direct Connect tới một hoặc nhiều VPC ở nhiều region khác nhau (cùng một account), bạn phải dùng Direct Connect Gateway.

Diagram: một Customer network với một AWS Direct Connect connection đi vào Direct Connect Gateway, từ đó có các Private virtual interface đi tới VPC 10.0.0.0/16 ở region us-east-1 và VPC 172.16.0.0/16 ở region us-west-1.

Các loại kết nối

Loại	Dung lượng	Cách đặt
Dedicated Connections	1 Gbps, 10 Gbps và 100 Gbps	Một port ethernet vật lý dành riêng cho một khách hàng. Request gửi tới AWS trước, sau đó AWS Direct Connect Partners hoàn tất
Hosted Connections	50 Mbps, 500 Mbps, tới 10 Gbps	Request kết nối được gửi qua AWS Direct Connect Partners. Dung lượng thêm/bớt được theo nhu cầu (on demand). Các mức 1, 2, 5, 10 Gbps có ở một số AWS Direct Connect Partners nhất định

Lead time thường dài hơn 1 tháng để thiết lập một kết nối mới — con số này rất hay được dùng trong các câu hỏi về migration gấp (so sánh với Disaster Recovery & Migrations).

Mã hóa trên Direct Connect

Dữ liệu in transit KHÔNG được mã hóa, nhưng là private.
AWS Direct Connect + VPN tạo ra một kết nối private được mã hóa IPsec.
Cách này tốt cho một lớp bảo mật bổ sung, nhưng phức tạp hơn một chút khi triển khai.

Resiliency cho Direct Connect

Slide đưa hai mức kiến trúc:

High Resiliency for Critical Workloads — một kết nối tại nhiều location: corporate data center nối tới AWS Direct Connect Location 1 và Location 2.
Maximum Resiliency for Critical Workloads — đạt được bằng các kết nối riêng biệt kết thúc trên các thiết bị riêng biệt tại nhiều hơn một location.

Site-to-Site VPN làm đường backup

Trong trường hợp Direct Connect hỏng, bạn có hai lựa chọn: thiết lập một kết nối Direct Connect backup (đắt), hoặc một Site-to-Site VPN connection. Diagram vẽ Direct Connect là Primary Connection và Site-to-Site VPN là Backup Connection giữa Corporate DC và VPC.

14. Transit Gateway

Khi hệ thống lớn dần, slide cho thấy network topology trở nên rất phức tạp: một mớ VPC nối nhau bằng VPC Peering Connection chồng chéo, cộng thêm nhiều VPN Connection tới Customer Gateway và một Direct Connect Gateway. Số kết nối tăng theo bình phương số VPC, và VPC Peering thì không transitive.

Transit Gateway là câu trả lời: nó cho phép transitive peering giữa hàng nghìn VPC và on-premises, theo mô hình hub-and-spoke (hình sao).

Nó là một regional resource, nhưng làm việc được cross-region.
Share cross-account được bằng Resource Access Manager (RAM).
Bạn peer được các Transit Gateway với nhau giữa các region.
Route Tables: giới hạn VPC nào được nói chuyện với VPC nào.
Hoạt động cùng Direct Connect Gateway và VPN connection.
Hỗ trợ IP Multicast — và slide nhấn mạnh không dịch vụ AWS nào khác hỗ trợ điều này.

Site-to-Site VPN ECMP

ECMP = Equal-cost multi-path routing, một chiến lược routing cho phép forward một packet qua nhiều best path. Use case: tạo nhiều Site-to-Site VPN connection để tăng băng thông kết nối tới AWS.

Diagram: một AWS Transit Gateway có bốn VPC attachment cho bốn VPC, cộng một VPN attachment đi tới corporate data center 172.16.0.0/16.

Throughput khi dùng ECMP

Đây là bảng số liệu đáng nhớ, so sánh VPN đi vào VGW với VPN đi vào Transit Gateway:

Kiểu kết nối	Throughput
VPN to virtual private gateway — 1 VPN connection (2 tunnels)	1,25 Gbps
VPN to transit gateway — 1x, 2 tunnel được dùng	2,5 Gbps (ECMP)
VPN to transit gateway — 2x	5,0 Gbps (ECMP)
VPN to transit gateway — 3x	7,5 Gbps (ECMP)

Đổi lại, Transit Gateway có chi phí theo GB dữ liệu được TGW xử lý (per GB of TGW processed data).

Transit Gateway cũng là cách để nhiều account dùng chung một Direct Connect. Theo diagram: Corporate data center → Customer router/firewall → AWS Direct Connect endpoint tại DX Location → một Transit VIF VLAN → Direct Connect Gateway (nằm ở Account 1) → Transit Gateway → các VPC ở Account 2. Bạn dùng AWS Resource Access Manager để share Transit Gateway với các account khác.

15. VPC – Traffic Mirroring

Traffic Mirroring cho phép bạn capture và inspect network traffic trong VPC, rồi route traffic đó tới các security appliance do bạn tự quản lý. Nói cách khác, đây là cách sao một bản copy lưu lượng để đưa đi phân tích mà không chen vào đường đi thật.

Capture from (Source) — các ENI.
Capture to (Targets) — một ENI hoặc một Network Load Balancer.
Capture toàn bộ packet hoặc chỉ những packet bạn quan tâm (tùy chọn: truncate packet).
Source và Target ở cùng VPC hoặc khác VPC đều được (qua VPC Peering).
Use case: content inspection, threat monitoring, troubleshooting…

Diagram cho thấy hai source (Source A, Source B) có inbound & outbound traffic, được Traffic Mirroring (có filter traffic, tùy chọn) đẩy tới một Network Load Balancer đứng trước một Auto Scaling group gồm các EC2 instance chạy Security Appliance.

16. IPv6 trong VPC

IPv4 được thiết kế để cung cấp 4,3 tỷ địa chỉ và sắp cạn. IPv6 là kế nhiệm của IPv4, được thiết kế để cung cấp khoảng 3,4 × 10³⁸ địa chỉ IP duy nhất.

Điểm khác biệt quan trọng nhất với AWS: mọi địa chỉ IPv6 trong AWS đều là public và route được trên Internet — không có dải private.

Định dạng là 8 nhóm hexadecimal, mỗi nhóm từ 0000 đến ffff, ví dụ:

2001:db8:3333:4444:5555:6666:7777:8888
2001:db8:3333:4444:cccc:dddd:eeee:ffff

Cách viết rút gọn bằng :::

Cách viết	Ý nghĩa
`::`	Cả 8 segment đều bằng 0
`2001:db8::`	6 segment cuối bằng 0
`::1234:5678`	6 segment đầu bằng 0
`2001:db8::1234:5678`	4 segment giữa bằng 0

IPv6 trong VPC hoạt động thế nào

IPv4 không thể bị tắt cho VPC và subnet của bạn — đây là câu quan trọng nhất của mục này.
Bạn bật được IPv6 (chúng là public IP address) để hoạt động ở chế độ dual-stack.
EC2 instance của bạn sẽ nhận được ít nhất một private internal IPv4 và một public IPv6.
Chúng liên lạc ra internet được bằng IPv4 hoặc IPv6, qua Internet Gateway.

Ví dụ trong diagram: một EC2 Instance có Private IP 10.0.0.5 và IPv6 2001:db8::ff00:42:8329, đi ra Internet qua Internet Gateway theo cả hai họ địa chỉ.

Troubleshooting IPv4 khi đã bật IPv6

Vì IPv4 không tắt được cho VPC và subnet, nên nếu bạn không launch được EC2 instance trong subnet thì:

Không phải vì nó không lấy được IPv6 — không gian IPv6 rất lớn.
Mà là vì không còn IPv4 khả dụng trong subnet của bạn.
Giải pháp: tạo một IPv4 CIDR mới trong subnet.

Diagram minh họa một VPC đã có 10.0.0.0/24 dùng gần hết (10.0.0.35) và IPv6 2001:db8:1234:5678::/56 còn thừa mứa; người dùng tạo thêm CIDR 192.168.0.0/24 và launch được tiếp (192.168.0.10, 192.168.0.15).

Egress-only Internet Gateway

Egress-only Internet Gateway chỉ dùng cho IPv6 — nó tương tự NAT Gateway nhưng dành cho IPv6.

Nó cho phép instance trong VPC tạo kết nối đi ra (outbound) qua IPv6, đồng thời ngăn Internet khởi tạo một kết nối IPv6 vào instance của bạn.
Bạn phải cập nhật Route Tables.

Lý do nó tồn tại: vì mọi IPv6 trong AWS đều là public, một instance ở private subnet có IPv6 sẽ bị Internet gọi vào được — egress-only IGW chặn đúng chiều đó. Diagram nói rõ: qua Internet Gateway thì khởi tạo kết nối được từ cả hai phía, còn qua Egress-only Internet Gateway thì không khởi tạo được kết nối từ Internet.

IPv6 Routing — hai route table mẫu

Slide cuối phần IPv6 đưa ra một ví dụ hoàn chỉnh. VPC có IPv4 10.0.0.0/16 và IPv6 2001:db8:1234:1a00::/56; public subnet là 10.0.0.0/24 + 2001:db8:1234:1a00::/64, private subnet là 10.0.1.0/24 + 2001:db8:1234:1a02::/64. Public subnet chứa Web server (private IPv4 10.0.0.5, EIP 198.51.100.1, IPv6 2001:db8:1234:1a00::123) và NAT Gateway (IPv4); private subnet chứa Server (private IPv4 10.0.1.5, IPv6 2001:db8:1234:1a02::456).

Route Table của Public Subnet:

Destination	Target
`10.0.0.0/16`	`local`
`2001:db8:1234:1a00::/56`	`local`
`0.0.0.0/0`	`igw-id`
`::/0`	`igw-id`

Route Table của Private Subnet:

Destination	Target
`10.0.0.0/16`	`local`
`2001:db8:1234:1a00::/56`	`local`
`0.0.0.0/0`	`nat-gateway-id`
`::/0`	`eigw-id`

17. Dựng một VPC ba tầng theo từng bước

Phần hands-on của chương được slide trình bày như một sơ đồ lớn dần sau mỗi bài — mỗi bước thêm đúng một thành phần vào cùng một bức tranh. Đây là thứ tự đó, và nó cũng là thứ tự hợp lý để tự dựng lại trong console:

VPC — bắt đầu với một Region trống và tạo VPC (chọn CIDR không trùng với mạng khác của bạn).
Subnets — trong một Availability Zone, thêm Public Subnet và Private Subnet.
Internet Gateway — tạo riêng, rồi attach vào VPC.
Route Tables — thêm Router + Route Table trỏ ra IGW cho public subnet, rồi launch Public EC2 Instance có Security Group và kiểm tra nó ra được Internet.
NAT Instance — thêm một NAT Instance kèm EIP vào public subnet, cùng một Route Table riêng cho private subnet trỏ vào nó, để Private EC2 Instance ra được Internet.
NAT Gateway — thay NAT Instance bằng NAT Gateway do AWS quản lý, giữ nguyên ý tưởng route table.
NACLs — thêm NACL cho cả public subnet và private subnet, làm lớp firewall thứ hai bên cạnh Security Group.
VPC Peering — thêm VPC Peering Connections để nối sang VPC khác.
VPC Endpoints — thêm VPC Endpoint để private subnet đi tới S3, Amazon DynamoDB và CloudWatch mà không cần Internet.
VPC Flow Logs — bật flow log trên VPC để có dữ liệu troubleshoot.
Site-to-Site VPN — thêm VPN Gateway phía AWS, Customer Gateway phía Corporate Data Center, và S2S VPN Connection giữa hai đầu.
Direct Connect và Transit Gateway — cuối cùng là DX Location với Direct Connect Connection, và Transit Gateway làm hub cho toàn bộ VPN và DX.

Đến bước 12 thì bức tranh đúng bằng sơ đồ tổng ở mục 1 — cả chương là một vòng khép kín.

18. Chi phí network trên AWS

Networking là một trong những khoản chi phí dễ bị bỏ sót nhất, và slide gói nó lại thành một hình đơn giản, tính theo GB:

Đường truyền	Giá
Traffic đi vào (ingress)	Miễn phí
Trong cùng một AZ, dùng private IP	Miễn phí
Giữa hai AZ trong cùng region, dùng private IP	$0,01
Dùng Public IP / Elastic IP	$0,02
Inter-region (giữa hai Region)	$0,02

Hai lời khuyên rút ra trực tiếp từ bảng:

Dùng Private IP thay vì Public IP để tiết kiệm đáng kể và có network performance tốt hơn.
Dùng cùng một AZ để tiết kiệm tối đa — nhưng đổi lại là mất high availability. Đây là một trade-off có thật, không phải “best practice” tuyệt đối.

Giảm chi phí egress traffic

Egress traffic là traffic đi ra (từ AWS ra ngoài).
Ingress traffic là traffic đi vào — từ ngoài vào AWS, thường miễn phí.
Nguyên tắc: cố gắng giữ càng nhiều internet traffic trong AWS càng tốt để giảm chi phí.
Direct Connect location được co-located trong cùng AWS Region sẽ cho chi phí egress network thấp hơn.

Slide minh họa bằng một ví dụ rất dễ nhớ: một DB Query 100 MB trả về Query Results 50 KB. Nếu Application nằm trong AWS cùng với Database, chỉ 50 KB kết quả phải đi ra ngoài — egress cost được giảm tối đa. Nếu Application nằm ở corporate data center và Database ở AWS, thì chính 100 MB query đó phải chạy qua lại — egress cost cao. Bài học: đặt compute cạnh dữ liệu.

Giá S3 Data Transfer (phân tích cho USA)

Đường truyền	Giá mỗi GB
S3 ingress	Miễn phí
S3 ra Internet	$0,09
S3 Transfer Acceleration	cộng thêm $0,04 đến $0,08 trên giá Data Transfer; đổi lại thời gian truyền nhanh hơn 50% đến 500%
S3 tới CloudFront	$0,00
CloudFront ra Internet	$0,085 — hơi rẻ hơn S3, lại có khả năng caching (giảm latency) và giảm chi phí S3 Requests (rẻ hơn 7 lần với CloudFront)
S3 Cross Region Replication	$0,02

Đây chính là một trong những lý do kiến trúc “S3 + CloudFront” xuất hiện khắp nơi — xem thêm CloudFront & Global Accelerator.

NAT Gateway so với Gateway VPC Endpoint về giá

Slide dựng một VPC 10.0.0.0/16 ở us-east-1 với hai private subnet cùng muốn đọc S3 Bucket: Private subnet 1 (10.0.0.0/24) đi qua NAT Gateway rồi Internet Gateway, Private subnet 2 (10.0.1.0/24) đi qua VPC Endpoint. Route table của subnet đi qua NAT có 10.0.0.0/16 → Local và 0.0.0.0/0 → igw-id; route table của subnet dùng endpoint có 10.0.0.0/16 → Local và pl-id của Amazon S3 → vpce-id.

Đường đi	Chi phí
NAT Gateway	$0,045 / giờ
NAT Gateway data processed	$0,045 / GB
Data transfer out tới S3 (cross-region)	$0,09
Data transfer out tới S3 (same-region)	$0,00
Gateway Endpoint	Không có chi phí cho việc sử dụng
Data transfer in/out qua endpoint (same-region)	$0,01

Đặt hai cột giá cạnh nhau là thấy ngay khoảng cách: đường qua NAT Gateway trả cả phí giờ và $0,045 cho mỗi GB được xử lý, trong khi bản thân Gateway Endpoint không tốn phí sử dụng và chỉ còn $0,01 mỗi GB in/out cùng region. Đây chính là lý do slide nói Gateway Endpoint “gần như luôn được ưu tiên” ở phần trên.

19. Bảo vệ mạng và AWS Network Firewall

Tính tới đây, để bảo vệ mạng trên AWS bạn đã có:

Network Access Control Lists (NACLs)
Amazon VPC security groups
AWS WAF — bảo vệ chống lại các malicious request
AWS Shield & AWS Shield Advanced
AWS Firewall Manager — để quản lý chúng xuyên nhiều account

Chi tiết về ba dịch vụ cuối nằm ở chương Security & Encryption. Nhưng câu hỏi còn lại là: nếu muốn bảo vệ toàn bộ VPC theo cách tinh vi hơn thì dùng gì?

AWS Network Firewall

AWS Network Firewall bảo vệ toàn bộ Amazon VPC của bạn, với bảo vệ từ Layer 3 tới Layer 7. Nó inspect được theo mọi chiều:

VPC tới VPC traffic
Outbound ra internet
Inbound từ internet
Tới / từ Direct Connect & Site-to-Site VPN

Hai chi tiết kiến trúc đáng nhớ:

Bên trong, AWS Network Firewall dùng AWS Gateway Load Balancer.
Rule quản lý tập trung cross-account được bằng AWS Firewall Manager để áp lên nhiều VPC.

Fine Grained Controls

Network Firewall hỗ trợ hàng nghìn rule, với các kiểu kiểm soát sau:

IP & port — ví dụ: filter hàng chục nghìn IP.
Protocol — ví dụ: block protocol SMB cho outbound communication.
Stateful domain list rule groups — chỉ cho phép outbound traffic tới *.mycorp.com hoặc tới repo phần mềm của third-party.
Pattern matching tổng quát bằng regex.
Traffic filtering: Allow, drop, hoặc alert cho traffic khớp rule.
Active flow inspection để bảo vệ trước các network threat với khả năng intrusion-prevention — giống Gateway Load Balancer, nhưng toàn bộ do AWS quản lý.
Gửi log của các rule match tới Amazon S3, CloudWatch Logs, Kinesis Data Firehose.

Tóm tắt nhanh

Chủ đề	Cần nhớ
CIDR	Base IP + Subnet Mask. Mẹo octet: `/32` không đổi octet nào, `/24` đổi octet cuối, `/16` đổi 2 octet cuối, `/8` đổi 3 octet cuối, `/0` đổi tất cả
Dải Private IP	`10.0.0.0/8`, `172.16.0.0/12` (nơi default VPC của AWS nằm), `192.168.0.0/16`
Giới hạn VPC	5 VPC / region (soft limit), 5 CIDR / VPC, mỗi CIDR từ `/28` đến `/16`, không overlap với mạng khác của bạn
Subnet	AWS giữ 5 IP (4 đầu + 1 cuối). Cần 29 IP dùng được thì phải chọn `/26`, không phải `/27`
Internet Gateway	Một VPC ↔ một IGW, scale ngang và HA sẵn, nhưng phải sửa Route Table mới ra được Internet
Bastion Host	Ở public subnet, SG cho phép port 22 từ một CIDR giới hạn; SG của máy private cho phép SG của bastion
NAT Instance	Public subnet, tắt `Source / destination Check`, cần Elastic IP, tự quản SG, không HA sẵn (cần ASG multi-AZ), băng thông theo instance type, AMI hết standard support 31/12/2020
NAT Gateway	Managed, 5 Gbps tự scale tới 100 Gbps, dùng EIP, cần IGW, không dùng được từ chính subnet của nó, không có SG, HA trong một AZ → tạo một cái ở mỗi AZ
NACL	Stateless, mức subnet, có deny rule, rule số 1–32766 (số nhỏ thắng, khớp đầu tiên thắng, `` deny), NACL mới deny hết, đừng sửa Default NACL*
Security Group	Stateful, mức instance, chỉ allow rule, đánh giá tất cả rule
Ephemeral ports	IANA và Windows 10 `49152–65535`, nhiều Linux kernel `32768–60999`; với NACL, đường về cần rule cho dải `1024-65535`
VPC Peering	Không overlap CIDR, không transitive, sửa route table cả hai bên; cross-account và cross-region được; tham chiếu SG của VPC đã peer chỉ hoạt động trong cùng region
VPC Endpoint	Interface (ENI + Security Group, hầu hết dịch vụ, tính theo giờ + GB) vs Gateway (target trong route table, chỉ S3 và DynamoDB, miễn phí). Đề thi ưu tiên Gateway cho S3; chọn Interface khi cần truy cập từ on-premises, VPC khác hoặc region khác. Lỗi thì kiểm tra DNS Resolution và Route Tables
PrivateLink	Phơi dịch vụ từ VPC của bạn sang VPC khách hàng bằng Network Load Balancer và ENI — không peering, không Internet, không NAT, không route table
VPC Flow Logs	Mức VPC / Subnet / ENI, ghi cả ACCEPT và REJECT, đích S3, CloudWatch Logs, Kinesis Data Firehose, bắt được cả interface của ELB, RDS, ElastiCache, Redshift, WorkSpaces, NATGW, Transit Gateway; query bằng Athena hoặc CloudWatch Logs Insights. Chiều đi ACCEPT mà chiều về REJECT → NACL
Site-to-Site VPN	VGW phía AWS (custom ASN được) + CGW phía khách hàng; dùng public IP của NAT device nếu có NAT-T; bật Route Propagation; muốn ping thì mở ICMP. VPN CloudHub = hub-and-spoke nhiều VPN trên cùng một VGW, đi qua public Internet
Direct Connect	Private nhưng không mã hóa (muốn mã hóa → DX + VPN); Dedicated 1/10/100 Gbps, Hosted 50 Mbps–10 Gbps on demand; lead time hơn 1 tháng; Direct Connect Gateway cho nhiều VPC ở nhiều region trong cùng account; backup bằng Site-to-Site VPN
Transit Gateway	Transitive peering hub-and-spoke cho hàng nghìn VPC, VPN và DX; regional nhưng peer cross-region được; share bằng RAM; route table quyết định VPC nào nói với VPC nào; dịch vụ AWS duy nhất hỗ trợ IP Multicast. ECMP: VGW 1,25 Gbps, TGW 2,5 / 5,0 / 7,5 Gbps với 1x / 2x / 3x
Traffic Mirroring	Source là ENI, target là ENI hoặc NLB, cùng VPC hoặc VPC đã peer, lọc và truncate packet được
IPv6	Mọi IPv6 trên AWS là public; IPv4 không tắt được; không launch được instance là do hết IPv4, cách chữa là thêm IPv4 CIDR. Egress-only Internet Gateway là bản IPv6 của NAT Gateway, chỉ cho outbound, route `::/0 → eigw-id`
Chi phí network	Ingress miễn phí, cùng AZ qua private IP miễn phí, cross-AZ private IP $0,01/GB, public hoặc Elastic IP $0,02/GB, inter-region $0,02/GB; S3 ra Internet $0,09/GB so với CloudFront $0,085/GB; Gateway Endpoint miễn phí so với NAT Gateway $0,045/giờ + $0,045/GB
AWS Network Firewall	Bảo vệ cả VPC, Layer 3 tới 7, mọi chiều kể cả VPC-to-VPC và DX/VPN; bên trong dùng Gateway Load Balancer; quản lý cross-account bằng Firewall Manager; log ra S3 / CloudWatch Logs / Kinesis Data Firehose