2.1. Services - Networking: VPC, subnet, routing, gateway và firewall

Mục lục

• 1. VPC là gì
• 2. Default VPC và custom VPC
• 3. Thực hành: tạo, kiểm tra và xóa VPC
• 4. Subnet
• 5. Thực hành: tạo subnet và chọn Availability Zone
• 6. VPC router và route table
• 7. Thực hành: route table và route
• 8. Internet gateway
• 9. Thực hành: biến private subnet thành public subnet
• 10. NAT gateway
• 11. Thực hành: NAT gateway
• 12. Chọn public subnet hay private subnet
• 13. DNS trong VPC
• 14. Thực hành: hai knob DNS của VPC
• 15. Elastic IP
• 16. Thực hành: Elastic IP
• 17. Firewall stateless và stateful
• 18. NACL và security group
• 19. Cấu trúc rule của security group và NACL
• 20. Thực hành: security group trên EC2 instance
• 21. Thực hành: NACL ở mức subnet

---

1. VPC là gì

Virtual Private Cloud (VPC) là một network segment được cô lập và bảo mật, nằm trong AWS.

Tác dụng chính của VPC là cô lập resource khỏi các resource khác trong cloud. Có hai mức cô lập cần phân biệt:

• Giữa các khách hàng: resource của khách hàng này không nói chuyện được với resource của khách hàng khác.
• Trong cùng một AWS account: nếu một khách hàng triển khai vài application khác nhau và không muốn các application đó nói chuyện với nhau, cách làm là tách chúng ra các VPC riêng.

Lý do cần mức kiểm soát này là để chỉ định được thật chi tiết thiết bị nào được phép nói chuyện với thiết bị nào trong account.

💡 Hình dung: VPC giống một tầng thuê riêng trong cao ốc cho thuê văn phòng. Tòa nhà là phần cứng của AWS, dùng chung với hàng nghìn khách khác. Nhưng tầng đó có cửa riêng, hệ thống dây mạng riêng, danh sách người được vào riêng. Khách tầng dưới không bước sang được, và chính chủ tầng mới quyết định có mở thêm một cửa ra hành lang chung hay không.

VPC trao toàn bộ quyền điều khiển networking trong cloud cho khách hàng, gồm:

• Subnetting: tự chỉ định dải IP address nào được dùng trong cloud.
• Route table: tự quyết định packet đi theo đường nào khi di chuyển trong account.
• Firewall: security group và NACL, quyết định loại traffic nào được vào và ra khỏi môi trường cũng như khỏi từng resource.
• Gateway: tùy biến traffic vào và ra khỏi VPC.

Về bản chất việc này không khác quản một data center vật lý, nơi phải lắp router và switch rồi cấu hình chúng. Khác biệt là AWS đơn giản hóa toàn bộ quy trình, không phải vào command line của router để chạy từng câu lệnh gán IP address.

VPC gắn với đúng một region

Trước khi nói tiếp cần làm rõ hai đơn vị địa lý của AWS, vì gần như mọi quyết định networking trong bài đều dựa vào chúng:

• Region là một vùng địa lý, ví dụ us-east-1 ở Northern Virginia hay ap-southeast-1 ở Singapore. Mỗi region là một hạ tầng tách biệt, có service riêng, giá riêng.
• Availability Zone (AZ) là một hoặc một nhóm data center bên trong một region, cấp điện và kết nối mạng độc lập với các AZ còn lại. Một region thường có từ ba AZ trở lên, đặt cách nhau đủ xa để một sự cố vật lý không hạ cả hai, nhưng đủ gần để đường truyền giữa chúng vẫn có độ trễ thấp. Tên AZ là tên region cộng một chữ cái: us-east-1a, us-east-1b.

Đây là điểm cần nhớ cho kỳ thi Solutions Architect: VPC chỉ thuộc về một region duy nhất. Khi tạo VPC phải chỉ định region. Ví dụ VPC 1 cấu hình ở us-east-1 và VPC 2 cấu hình ở us-east-2 là hai VPC riêng biệt, mỗi cái cô lập trong region của nó. VPC không thể trải qua nhiều hơn một region. Ngược lại, một VPC phủ được mọi AZ trong region của nó, và đó là cách dựng hệ thống chịu lỗi: cùng một VPC, resource rải ra nhiều AZ.

VPC là network boundary

Khi triển khai resource vào một VPC, mặc định resource đó không nói chuyện được với resource trong VPC khác. Chúng tự động bị cô lập.

Muốn cho internet nói chuyện được với resource trong VPC, hoặc muốn hai VPC khác nhau nói chuyện được với nhau, thì phải bật tường minh. Nghĩa là tính cô lập network của VPC tự thân đã mang lại một mức bảo mật sẵn có.

CIDR block của VPC

Mỗi VPC được gán một dải IP address, gọi là CIDR block. CIDR block định nghĩa những IP address mà resource trong VPC được dùng. Một server triển khai vào VPC 1 chỉ lấy được IP address nằm trong CIDR block của VPC 1, không lấy được IP nằm ngoài.

Ký hiệu /16 phía sau địa chỉ là CIDR notation, viết tắt của Classless Inter-Domain Routing. Con số đó đếm xem bao nhiêu bit đầu của địa chỉ bị giữ cố định làm địa chỉ của chính mạng. Một địa chỉ IPv4 có 32 bit, nên 10.0.0.0/16 giữ cố định 16 bit đầu, tức hai số 10.0, và để trống 16 bit sau cho từng thiết bị. Số địa chỉ trong dải là 2 lũy thừa số bit còn trống: 16 bit trống cho 65.536 địa chỉ. Prefix càng lớn thì dải càng nhỏ, nên /28 chỉ còn 4 bit trống, tức 16 địa chỉ.

Hạng mục	Giới hạn
Kích cỡ CIDR block IPv4	từ /16 (65.536 address) tới /28 (16 address)
CIDR block IPv4 thứ hai	tùy chọn, thêm được sau khi VPC đã tạo
Số CIDR block IPv4 trên một VPC	mặc định 5 (tính cả block chính), nâng được tới 50
Kích cỡ CIDR block IPv6	từ /44 tới /60, bước nhảy /4; block do Amazon cấp luôn là /56
Số CIDR block IPv6 trên một VPC	mặc định 5, nâng được tới 50

Không phải dải IPv4 nào cũng dùng được. AWS khuyến nghị lấy từ ba dải private của RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) và chặn hẳn bốn dải 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16 và 224.0.0.0/4. Dải 172.17.0.0/16 thì không bị chặn nhưng nên tránh, vì một số service của AWS dùng sẵn dải đó và sẽ xung đột địa chỉ.

Ví dụ: VPC 1 có CIDR block 192.168.0.0/16, nghĩa là các IP address từ 192.168.0.0 tới 192.168.255.255 khả dụng cho resource triển khai trong VPC 1.

---

2. Default VPC và custom VPC

Có hai loại VPC, phân biệt theo việc ai cấu hình nó.

Default VPC do AWS cấu hình thay cho khách hàng. Mỗi khi tạo một AWS account mới, AWS tự động cấu hình một default VPC, và không chỉ một cái mà một cái trong mỗi region mà account có quyền truy cập: một ở us-east-1, một ở us-east-2, một ở us-west-1, mọi region đều có.

Default VPC đi kèm một mức cấu hình mặc định sẵn, trong đó có tự động cho phép internet connectivity. Mục đích là để người mới tiếp xúc AWS đã có ngay một VPC đơn giản dùng được: chỉ cần dựng một server có internet thì triển khai vào default VPC là xong, mọi thứ hoạt động ngay.

Custom VPC là VPC tự tạo và tự tùy biến toàn bộ cấu hình: CIDR block, các setting, network access, tất cả do người dùng làm.

Cấu hình mặc định của default VPC

Bảng dưới đây nhắc tên bốn thành phần mà các mục sau mới mổ xẻ, nên tạm hiểu như sau cho đủ đọc bảng: subnet là một nhóm nhỏ IP address cắt ra từ dải của VPC và là nơi resource nằm; route table là bảng rule nói cho hệ thống biết packet đi đâu; internet gateway là cửa ra internet của VPC; security group và NACL là hai loại firewall.

Thành phần	Giá trị mặc định
Số lượng	1 default VPC mỗi region
CIDR block IPv4	172.31.0.0/16, luôn luôn là dải này
Số address	65.536
Default subnet	1 subnet /20 (4.096 address) trong mỗi Availability Zone của region
Auto-assign public IPv4 trên default subnet	bật
Internet gateway	1 cái attach vào VPC
Default route	0.0.0.0/0 trỏ về internet gateway, cạnh route 172.31.0.0/16 trỏ về local
Default security group	có. Inbound chỉ allow traffic đến từ resource gán cùng security group đó; outbound allow tất cả
Default NACL	có. Rule 100 allow mọi traffic cả hai chiều, dưới nó là rule * deny mọi traffic
DNS resolution và DNS hostnames	cả hai bật, xem mục 13
DHCP option set	gán sẵn DHCP option set mặc định của account

CIDR block 172.31.0.0/16 áp dụng trên mọi AWS account. Mọi default VPC của mọi khách hàng đều dùng đúng dải này.

Hai dòng cuối của bảng cho thấy một chi tiết dễ bỏ qua: cấu hình mặc định của default security group không mở đường từ internet vào. Nó chỉ cho các resource gán cùng group đó nói chuyện với nhau. Internet access của default VPC đến từ internet gateway và default route, không phải từ security group.

Ví dụ default subnet: Availability Zone 1 được 172.31.16.0/20, Availability Zone 2 được 172.31.32.0/20.

Route 0.0.0.0/0 có nghĩa là mọi address, và nó trỏ về internet gateway. Nhờ vậy resource nào triển khai vào default VPC cũng truy cập được internet, và thiết bị trên internet cũng truy cập được resource trong default VPC.

---

3. Thực hành: tạo, kiểm tra và xóa VPC

Tạo một custom VPC

Bước 1: chọn region. Vì VPC gắn với region nên phải chọn region trước. Ví dụ dùng us-east-1 (Northern Virginia).

Bước 2: vào service VPC. Tra VPC trong search bar của console. Trang mở ra là bảng tóm tắt mọi VPC và resource networking đã triển khai. Ở menu bên trái chọn Your VPCs.

Với một account vừa mở, ở đây sẽ thấy đúng một VPC, và cuộn sang phải sẽ thấy cột xác nhận đó là default VPC.

Bước 3: bấm Create VPC. Có hai lựa chọn ở bước này:

• VPC only: chỉ tạo VPC.
• Lựa chọn mới hơn mà AWS thêm vào: tạo VPC cùng một loạt resource cần thiết khác trong một lần, gồm subnet, route table, internet gateway, NAT gateway, để application lên nhanh nhất có thể.

Chọn VPC only cho gọn.

Bước 4: điền thông tin.

• Name tag: ví dụ demo VPC.
• IPv4 CIDR block: ví dụ 10.0.0.0/16.
• IPv6 CIDR block: tùy chọn. Hai phương án: dùng CIDR block đã sở hữu sẵn, hoặc chọn Amazon-provided IPv6 CIDR block để AWS cấp từ pool address của họ.
• Tenancy: để nguyên.
• Tags: đã có sẵn Name tag vừa đặt, thêm tag khác nếu muốn.

Bấm Create VPC.

Thông tin hiện ra sau khi tạo

Trường	Ý nghĩa
VPC ID	ID của VPC này
State	trạng thái, ở đây là available
DNS hostnames, DNS resolution	hai knob về DNS, xem mục 13
Default VPC	no, vì đây là custom VPC do người dùng tạo
CIDR block	dải vừa chỉ định
IPv6 pool	Amazon provided
IPv6 CIDR block	dải /56 được cấp

Trong VPC, AWS tự động tạo một route table. Cũng có mục network ACL để filter, cho phép hoặc chặn traffic vào subnet.

Phần Resource map ở dưới cho một hình dung trực quan: VPC cùng mọi loại resource bên trong. Lúc này số subnet là 0. Route table hiện ở đây là cái vừa được tạo tự động.

Xóa VPC

Vào Your VPCs, chọn VPC, mở Actions rồi chọn Delete VPC, sau đó gõ chữ delete để xác nhận.

Kiểm tra default VPC trong console

Vào lại trang VPC. Region đang chọn không quan trọng vì cấu hình default VPC giống nhau ở mọi region.

Với một account mới, ở Your VPCs chỉ có một VPC, chính là default VPC:

• State là available.
• CIDR block luôn luôn là 172.31.0.0/16.
• Default VPC là yes.

Để tự xác nhận chuyện mỗi region đều có một default VPC: đổi sang region khác, ví dụ Ohio, rồi vào lại Your VPCs. Vẫn thấy đúng một VPC, vẫn CIDR block 172.31.0.0/16, vẫn là default VPC. Mọi region khác đều cho kết quả như vậy.

Sáu default subnet của một default VPC

Ghi lại VPC ID của default VPC (ví dụ phần cuối là acb5) rồi vào mục Subnets. Ở region Northern Virginia sẽ thấy sáu subnet, tất cả đều gắn với VPC ID vừa ghi.

Lý do có sáu subnet là do số Availability Zone: default VPC tạo một default subnet trong mỗi Availability Zone của region, nên region này có 1a, 1b, 1c, 1d, 1e, 1f là sáu subnet. Trang Resource map của VPC giúp thấy rõ điều này: sáu subnet, mỗi Availability Zone một cái.

Nghĩa là mặc định đã triển khai được resource vào bất kỳ Availability Zone nào trong bất kỳ region nào, chỉ cần dùng default VPC và chọn đúng subnet tương ứng với Availability Zone muốn dùng.

Bấm vào default route table sẽ thấy cả sáu subnet đều gắn với nó. Ngoài ra một internet gateway cũng được tạo sẵn, kèm các route phù hợp, nên internet access có sẵn ngay.

Mở một trong các default subnet sẽ thấy nó cấu hình được để auto-assign a public IPv4 address. Nhờ vậy khi triển khai EC2 instance vào đó, instance tự động nhận public address và kết nối được từ bên ngoài.

Chứng minh bằng một EC2 instance

Vào trang EC2, tạo một instance mới với toàn bộ tùy chọn mặc định: image Amazon Linux, instance type t2.micro, tạo key pair mới (file tự tải về, ví dụ đặt tên AWS Demo), tạo security group cho phép SSH traffic. Phần networking chọn default VPC (nhận ra qua CIDR 172.31.0.0), chọn subnet nếu muốn chỉ định Availability Zone cụ thể như us-east-1b, và bật auto-assign public IP.

Sau khi launch, instance ở trạng thái running và có hai IP: private IP lấy từ subnet, và public IP. SSH vào bằng key pair đã tải:

ssh -i aws-demo.pem ec2-user@<public-ip>
# kết nối thành công, rồi ping ra internet để xác nhận
ping 8.8.8.8

Kết nối thành công và ping được DNS server của Google chứng minh instance có internet access, chỉ nhờ việc triển khai vào default VPC với cấu hình mặc định.

---

4. Subnet

Subnet là một nhóm IP address nằm trong VPC. Resource nằm ở đây, không nằm trực tiếp trong VPC: khi triển khai một EC2 instance hay một server, phải triển khai nó vào một subnet cụ thể.

Subnet gắn với đúng một Availability Zone

Subnet nằm trong một Availability Zone duy nhất. Subnet 1 ở Availability Zone 1 thì resource triển khai vào subnet 1 sẽ nằm ở Availability Zone 1. Subnet 2 ở Availability Zone 2 thì resource triển khai vào subnet 2 nằm ở Availability Zone 2.

Chọn subnet nào thì resource rơi vào Availability Zone của subnet đó. Trong console không có ô nào để gõ trực tiếp tên Availability Zone cho một EC2 instance, nên chọn subnet là cách chỉ định Availability Zone.

Public subnet và private subnet

Subnet có thể được làm public hoặc private để cho phép hay không cho phép truy cập từ bên ngoài:

• Thứ gì không cần internet access thì triển khai vào private subnet.
• Thứ gì cần internet nói chuyện được tới nó, ví dụ một web server hay web application mà người dùng phải truy cập được, thì triển khai vào public subnet.

Việc subnet là public hay private do gateway quyết định, cụ thể là internet gateway và NAT gateway.

CIDR block của subnet

Subnet trong một VPC phải nằm trong CIDR range của VPC đó.

Ví dụ VPC có CIDR range 192.168.0.0/16:

Subnet	Hợp lệ?	Lý do
192.168.10.0/24	Có	nằm trong 192.168.0.0/16
10.100.1.0/24	Không	nằm ngoài CIDR range của VPC, AWS sẽ báo lỗi

Kích cỡ block của subnet phải nằm từ /16 tới /28.

Năm IP address bị reserved trong mỗi subnet

Bốn IP address đầu của một subnet bị reserved và không dùng được, cộng với IP address cuối cùng.

Với ví dụ subnet 192.168.10.0/24:

Address	Dùng cho
192.168.10.0	network address
192.168.10.1	VPC router
192.168.10.2	DNS, tức Route 53 Resolver
192.168.10.3	reserved cho mục đích tương lai
192.168.10.255	broadcast address

Ba address .1 tới .3 là phần AWS giữ lại cho mình. Address .255 bị giữ vì VPC không hỗ trợ broadcast. Năm address này bị trừ ở mọi subnet, nên một subnet /28 chỉ còn 11 address dùng được trên tổng 16. Lúc chia dải cho một subnet nhỏ, con số cần tính là số address trừ 5, không phải số address thô.

Subnet IPv6 cũng mất 5 address đầu và cuối theo cùng quy tắc.

Subnet không được overlap trong cùng VPC

Subnet không được overlap với subnet khác trong cùng một VPC. Chữ "cùng một VPC" là chỗ quan trọng.

Ví dụ một cấu hình không hợp lệ trong cùng một VPC:

• Subnet 1: 10.16.0.0/24
• Subnet 2: 10.16.0.128/25

Hai dải này overlap nhau nên không hợp lệ.

Ngược lại, subnet được overlap với subnet thuộc VPC khác. Hai VPC là hai không gian địa chỉ tách biệt, nên trùng dải cũng không gây xung đột. Ràng buộc chỉ áp trong phạm vi một VPC.

Các tùy chọn khác khi cấu hình subnet

• Định nghĩa một IPv6 CIDR block cắt ra từ block IPv6 của VPC. Prefix cho phép nằm từ /44 tới /64, bước nhảy /4, và console thường để sẵn /64.
• Cấu hình subnet chỉ dùng IPv6, không dùng IPv4.
• Auto-assign public IPv4 hoặc IPv6 address ngoài private address. Mặc định resource triển khai vào subnet chỉ nhận private address. Bật knob này thì ngoài private address nó cũng nhận một public address. Cần bật khi triển khai thứ gì lên public subnet mà cần internet connectivity, ví dụ web server, vì người dùng không gửi request được tới một private address.

Routing giữa các subnet trong cùng VPC

Mặc định subnet nói chuyện được với các subnet khác trong cùng VPC. Không phải cấu hình gì, không phải vào route table định nghĩa gì. Routing trong một VPC là đầy đủ sẵn, mọi subnet thông nhau.

---

5. Thực hành: tạo subnet và chọn Availability Zone

Bước 1: tạo một VPC. Vào VPCs, bấm Create VPC, chọn VPC only, đặt tên Demo VPC, CIDR block 10.0.0.0/16, chọn Amazon-provided IPv6 CIDR block.

Bước 2: tạo subnet thứ nhất. Vào mục Subnets, bấm Create subnet:

• Chọn VPC: chọn custom VPC vừa tạo.
• Name: Subnet one.
• Availability Zone: chọn một AZ cụ thể, ví dụ us-east-1d. Nếu chọn no preference thì AWS tự chọn.
• CIDR block: đây là chỗ dễ sai. CIDR block phải nằm trong CIDR block của VPC. Thử điền 192.168.1.0/24 thì console từ chối với thông báo CIDR address is not within the CIDR address of the VPC, còn 10.0.1.0/24 thì nhận, vì nó nằm gọn trong 10.0.0.0/16.
• IPv6 CIDR block: tùy chọn. Nếu dùng thì phải chỉ định hai chữ số hexadecimal, ví dụ 00. Có thêm tùy chọn làm subnet chỉ dùng IPv6.

Bấm Create subnet, và subnet hiện ra với Availability Zone us-east-1d.

Bước 3: tạo subnet thứ hai. Làm lại tương tự, tên Subnet 2, Availability Zone khác, ví dụ us-east-1a, CIDR block 10.0.5.0/24.

Sau khi tạo xong, bỏ filter đi sẽ thấy cả hai subnet. Danh sách subnet filter được theo VPC để chỉ xem subnet của một VPC cụ thể.

Bước 4: triển khai một server vào subnet đã chọn. Vào Instances, launch instance mới, đặt tên instance one, chọn image bất kỳ, chọn một key pair có sẵn. Ở phần networking:

• VPC: chọn VPC vừa tạo.
• Subnet: lúc này hiện hai subnet. Chọn subnet two để instance rơi vào us-east-1a, hoặc subnet one để rơi vào us-east-1d. Ở đây chọn subnet two.
• Auto-assign public IP: chỉ cần khi subnet đã được cấu hình thành public subnet. Ở đây chưa làm nên không quan trọng.
• Security group: để mặc định.

Bấm Launch Instance rồi quay lại danh sách instance.

Kết quả cần quan sát: instance được triển khai vào subnet có CIDR 10.0.5.0/24, nên private IP của nó phải nằm trong dải đó. Ngay cả khi instance chưa boot xong, private IP đã được gán: ví dụ 10.0.5.113. AWS lấy một address còn trống trong dải của subnet rồi gán cho instance.

Bước 5: dọn dẹp. Xóa instance, rồi vào Demo VPC, chọn Actions và Delete VPC: việc này xóa luôn mọi subnet trong VPC.

Nếu xóa VPC ngay khi instance còn đang trong quá trình shutdown thì AWS báo không xóa được. Chờ thêm vài giây rồi xóa lại. Khi thành công, hộp xác nhận cho biết nó cũng sẽ xóa các subnet.

---

6. VPC router và route table

Mỗi VPC có một VPC router. Router này có một interface trong mỗi subnet của VPC, và interface đó nằm ở address network cộng một của từng subnet.

Ví dụ subnet là 192.168.1.0/24 thì interface của router trong subnet đó là 192.168.1.1.

Nhiệm vụ của router là route traffic giữa các subnet và vào ra khỏi VPC. Giống y như một router vật lý trong data center, AWS cho phép điều khiển router này qua route table, thứ quyết định network traffic được gửi đi đâu.

Route table và route

Route table là một tập rule mà router dùng để forward network traffic. Mỗi rule trong route table gọi là một route.

Cách router của AWS làm việc không khác bất kỳ router truyền thống nào:

1. Router nhìn một packet đang rời khỏi subnet.
2. Nó chỉ xét destination IP của packet.
3. Nó tìm route khớp bằng cách so với cột destination.
4. Khi đã chọn được route, router forward packet tới giá trị ở cột target của route đó.

Cách làm việc này giống nhau cho IPv4 và IPv6, nhưng hai họ địa chỉ được xét độc lập: route IPv4 không ảnh hưởng tới cách chọn route cho packet IPv6 và ngược lại.

💡 Hình dung: VPC router làm việc như một người phân loại bưu kiện ở bưu cục. Người đó không mở gói ra xem bên trong, chỉ đọc địa chỉ người nhận ghi ngoài vỏ, rồi tìm trên giá cái ngăn có nhãn khớp nhất với địa chỉ đó và bỏ gói vào. Route table chính là dãy nhãn dán trên các ngăn, còn cột target là nơi mỗi ngăn dẫn tới.

Khi một packet khớp nhiều route

Có khả năng một packet khớp nhiều hơn một route, ví dụ khi có cả 10.16.0.0/16 và 10.16.1.0/24 thì hai dải này overlap.

Khi có overlap dưới bất kỳ dạng nào, router của AWS chọn rule có prefix length lớn hơn, tức rule cụ thể hơn. Một /16 lớn hơn một /8, nên packet khớp cả /16 và /8 thì /16 được chọn. Tên chính thức của quy tắc này trong tài liệu AWS là longest prefix match, và đây là tầng ưu tiên cao nhất: prefix dài hơn thắng, bất kể route kia thuộc loại gì.

Chỉ khi hai route trùng destination y hệt nhau thì mới cần tới tầng ưu tiên tiếp theo. Route do người dùng tự thêm (gọi là static route, ví dụ route trỏ về internet gateway hay NAT gateway) thắng route mà AWS tự điền vào từ một kết nối VPN (gọi là propagated route). Quy tắc gọn lại thành hai bước: prefix dài hơn thắng trước, trùng prefix thì static thắng propagated.

Cột target

Cột target nói cho VPC router biết phải gửi packet đi đâu. Giá trị local là một khả năng, nhưng target cũng trỏ được tới nhiều thứ khác: một IP address khác, một gateway, một EC2 instance khác, hoặc nhiều loại resource khác.

Local route

Mọi route table đều có đúng một route mặc định, là local route.

Local route khớp toàn bộ traffic phát sinh trong VPC, vì destination prefix của nó chính là CIDR của VPC. Mọi traffic khởi phát trong VPC và nhắm tới một thiết bị khác cùng VPC đều khớp local route này.

Nếu VPC có bật IPv6 thì sẽ có hai local route: một cho IPv4 CIDR block và một cho IPv6 CIDR block. Ví dụ với một VPC mới có CIDR 10.16.0.0/16 và bật IPv6, route table sẽ có đúng hai route.

Quan hệ giữa subnet và route table

Quy tắc	Nội dung
Mỗi subnet gắn với bao nhiêu route table	Đúng một
Mỗi route table gắn được bao nhiêu subnet	Nhiều subnet
Mỗi VPC có bao nhiêu default route table	Một, được tạo tự động khi tạo VPC
Subnet mới gắn vào đâu	Vào default route table, cho tới khi trỏ nó sang route table khác
Số route table trên một VPC	Mặc định 200, tính cả main route table
Số route trên một route table	Mặc định 500 route tự thêm, nâng được tới 1.000; đếm riêng cho IPv4 và IPv6

Traffic rời khỏi một subnet sẽ tuân theo rule trong route table gắn với subnet đó. Hai subnet gắn vào hai route table khác nhau thì traffic của chúng đi theo hai tập rule khác nhau.

Không cần một route table riêng cho mỗi subnet. Lý do thực tế để có nhiều route table là tách rule cho private subnet và public subnet: toàn bộ private subnet gắn vào một private route table, toàn bộ public subnet gắn vào một public route table. Cách chia cụ thể thì tùy nhu cầu.

---

7. Thực hành: route table và route

Phần này chỉ xem route table, xem subnet nào gắn với nó, và xem các route trong đó. Chưa làm được gì nhiều hơn vì chưa học tới các feature cần thiết.

Bước 1: dựng môi trường. Tạo một Demo VPC với CIDR 10.0.0.0/16 và bật IPv6. Tạo hai subnet:

• subnet one: 10.0.1.0/24, kèm IPv6 CIDR block.
• subnet two: 10.0.2.0/24, Availability Zone để AWS tự chọn.

Bước 2: xem main route table. VPC tự động tạo main route table, còn gọi là default route table. Subnet nào được tạo mà không gán route table cụ thể thì tự gắn vào main route table này.

Mở route table đó ra, tab Routes có đúng hai route như lý thuyết đã nêu: một local route cho IPv4 và một local route cho IPv6. Packet nào tới router mà có destination IP nằm trong CIDR block của VPC thì được route locally.

Tab Subnet associations cho thấy: không có explicit subnet association nào, nhưng có hai subnet without explicit associations, chính là subnet one và subnet two. Hai subnet này tự gắn vào đây vì đây là main route table, và chúng thừa hưởng các route trong này.

Bước 3: tạo route table riêng. Vào mục Route Tables, bấm Create route table, đặt tên route table one, chọn VPC demo.

Route table mới chưa có subnet nào. Vào tab Subnet associations, bấm Edit rồi chọn subnet one. Giờ subnet one gắn với route table one, nên traffic từ subnet one tuân theo rule của route table này.

Làm tương tự để tạo route table two cho subnet two nếu muốn mỗi subnet một route table riêng. Về mặt kỹ thuật không cần thiết, gán hết mọi subnet vào một route table vẫn chạy.

Bước 4: thêm route. Trong tab Routes, bấm Edit routes rồi Add route:

• Destination: ví dụ 0.0.0.0/0. Đây là default route, nghĩa là mọi packet. Packet nào không khớp rule nào khác sẽ khớp rule này.
• Target: chọn một internet gateway, một NAT gateway, hoặc local, tùy nhu cầu.

Bấm Save changes.

Bước 5: dọn dẹp. Xóa VPC. Việc này xóa luôn các subnet và route table bên trong.

Khi gỡ lỗi kết nối trong VPC, thứ tự kiểm tra lấy từ đúng cơ chế vừa thấy: packet vào router, router xét destination IP, tìm route có prefix khớp dài nhất, rồi gửi packet theo target của route đó. Nên câu hỏi đầu tiên luôn là subnet này đang gắn vào route table nào, và route table đó có route nào phủ được destination hay không.

---

8. Internet gateway

Mặc định mọi subnet mới tạo là private subnet, nghĩa là thiết bị trong subnet không nói chuyện được với internet, và ngược lại. Để biến subnet thành public phải dùng internet gateway.

Đặc tính của internet gateway

Đặc tính	Nội dung
Attach vào đâu	Vào VPC
Phạm vi	Region-resilient: AWS mô tả nó là thành phần scale ngang, dự phòng sẵn và sẵn sàng cao, phủ toàn bộ Availability Zone trong region
Số internet gateway trên một VPC	Tối đa 1
Một internet gateway attach được mấy VPC	Tối đa 1 tại một thời điểm
Số internet gateway trên một region	Mặc định 5, tăng theo quota số VPC trên region
Họ địa chỉ hỗ trợ	Cả IPv4 và IPv6
Chi phí	Bản thân internet gateway miễn phí, phần tính tiền là lưu lượng data transfer của instance đi qua nó

VPC không có internet gateway attach vào thì mọi subnet trong VPC đó đều là private. Vì internet gateway là region-resilient, không cần triển khai một cái cho mỗi Availability Zone.

Với IPv4, internet gateway còn làm thêm một việc: nó thực hiện NAT một-đối-một giữa public IP và private IP của instance. NAT viết tắt của Network Address Translation, nghĩa là sửa trường địa chỉ trong header của packet. Cơ chế này được mổ kỹ ở phần ngay dưới. Với IPv6 thì không có bước dịch nào, vì địa chỉ IPv6 vốn đã là địa chỉ public toàn cầu.

Có một biến thể đáng biết kèm theo: egress-only internet gateway. Nó cũng attach vào VPC, cũng tối đa một cái, nhưng chỉ cho traffic IPv6 đi ra và không cho internet khởi tạo kết nối vào. Đây là cách làm private subnet IPv6 có đường ra internet mà vẫn kín chiều vào.

Bốn bước biến private subnet thành public subnet

Chỉ tạo internet gateway là chưa đủ. Trình tự đầy đủ:

1. Tạo internet gateway.
2. Attach nó vào VPC.
3. Tạo một custom route table, trong đó cấu hình một default route trỏ về internet gateway. Default route này có nghĩa: packet nào không khớp route nào khác thì gửi về internet gateway, vì không khớp route cụ thể hơn thì khả năng nó đi ra internet.
4. Gắn subnet muốn biến thành public vào route table đó.

Xong bước 4, mọi resource trong subnet đó có internet access và subnet trở thành public subnet.

Public IP hoạt động ra sao

Resource triển khai lên public subnet mặc định chỉ nhận private IP. Phải bật một knob riêng để nó nhận thêm public IP, nếu không thiết bị trên internet không truy cập được vào resource.

Khi bật knob đó, public IP được associate với private IP. Ví dụ private IP là 192.168.1.1 và public IP là 1.1.1.1.

Điểm then chốt: bản thân resource không biết gì về public IP của nó. Đăng nhập vào console hay CLI của EC2 instance thì chỉ thấy private IP.

Luồng traffic khi ai đó trên internet muốn nói chuyện với server:

1. Họ gửi request tới public IP.
2. AWS dịch địa chỉ đó và forward tới private IP tương ứng.
3. Packet đến EC2 instance.

AWS trừu tượng hóa public IP khỏi resource, nên resource chỉ biết private IP.

Vì public IP được liên kết với một private IP cụ thể, nếu resource có nhiều interface thì mỗi interface có thể có public IP riêng, liên kết với private IP của chính interface đó. Nhờ liên kết này AWS biết request tới public IP nào thì forward vào private IP nào.

---

9. Thực hành: biến private subnet thành public subnet

Phần này làm từ đầu: tạo VPC, tạo subnet, triển khai EC2 instance, xác nhận không truy cập được, rồi attach internet gateway và sửa route table để truy cập được.

Bước 1: tạo VPC và subnet. Vào trang VPC, Create VPC, chọn VPC only, CIDR 10.0.0.0/16. Tạo subnet với Availability Zone để mặc định, CIDR 10.0.1.0/24.

Bước 2: triển khai EC2 instance. Vào trang EC2, Launch Instance:

• Name: MyPublicServer.
• Image: Amazon Linux.
• Instance type: t2.micro. Free tier của EC2 cho 750 giờ mỗi tháng trong 12 tháng đầu, áp cho t2.micro hoặc t3.micro; region nào không có t2.micro thì loại được tính free tier là t3.micro.
• Key pair: dùng cái đã tạo sẵn để có thể truy cập server.
• Network settings: chọn VPC vừa tạo, chọn subnet duy nhất có trong đó, và ở auto-assign public IP chọn Enable để instance nhận public IP.
• Security group: tạo mới. Security group mặc định cho phép SSH traffic, tức TCP port 22, từ 0.0.0.0/0 nghĩa là từ mọi IP address. Thêm một rule nữa cho ICMP để có thể ping, cũng từ mọi IP address.

Bấm Launch.

Bước 3: xác nhận chưa truy cập được. Instance ở trạng thái running, status check đang initializing, và đã có public IP address. Copy public IP đó rồi thử từ máy cá nhân:

ping <public-ip>
# Request timed out, treo không phản hồi

ssh -i aws-demo.pem ec2-user@<public-ip>
# cũng treo, không kết nối được

Cả hai đều thất bại, và đây là kết quả đúng như dự kiến: subnet vừa tạo mặc định là private subnet, không có internet access, nên dù instance có public IP vẫn không route tới được.

Bước 4: tạo và attach internet gateway. Về trang VPC, vào mục Internet Gateways. Cái đang có sẵn ở đó thuộc default VPC. Bấm Create internet gateway, đặt tên my internet gateway.

Sau khi tạo, mở Actions và chọn Attach to VPC, chọn VPC vừa tạo.

Bước 5: xác nhận vẫn chưa đủ. Chạy lại lệnh ping thì vẫn thất bại. Nguyên nhân: router của AWS chưa biết phải gửi traffic nhắm ra internet về phía internet gateway.

Kiểm tra bằng cách vào subnet, mở tab Route Table: chỉ có local route, không có default route.

Bước 6: tạo route table có default route. Có hai cách: sửa thẳng default route table, hoặc tạo một route table mới rồi gán subnet vào. Ở đây chọn cách thứ hai để giữ nguyên default route table.

1. Create route table, tên Public route table, chọn demo VPC.
2. Gán subnet vào route table này, để subnet dùng các route ở đây.
3. Edit routes, thêm một route:
   • Destination 0.0.0.0/0, nghĩa là mọi traffic không khớp rule nào đã có sẽ khớp rule này.
   • Target: chọn internet gateway, hệ thống liệt kê các internet gateway khả dụng, chọn cái vừa tạo.
4. Save changes.

Bước 7: xác nhận. Giả định NACL và security group đã cho phép traffic cần thiết, lúc này phải truy cập được:

ping <public-ip>
# giờ ping thành công

Khi một instance có public IP mà vẫn không ping được, ba chỗ cần soi theo đúng thứ tự này: internet gateway đã tồn tại chưa, nó đã attach vào đúng VPC chưa, và subnet đang gắn vào route table nào có default route trỏ về internet gateway đó hay không. Thiếu bất kỳ mắt nào trong ba mắt thì public IP chỉ là một con số không dẫn tới đâu.

---

10. NAT gateway

Vấn đề cần giải

Có một server trong private subnet, và server này cần internet access để tải update cùng security patch.

Cách đã biết là attach internet gateway vào VPC, tạo route trỏ về internet gateway, biến subnet thành public. Nhưng làm vậy thì server rơi vào public subnet, nghĩa là mở ra toàn bộ internet, thiết bị nào cũng nói chuyện được với nó.

Vậy nếu server này là server nội bộ, chỉ các team nội bộ được truy cập, và không được mở ra internet thì sao? Yêu cầu thực sự là:

• Server khởi tạo được connection ra internet.
• Internet không bao giờ khởi tạo được connection vào server.

NAT gateway là service giải đúng bài toán một chiều này.

Tên của nó nói rõ cơ chế: NAT viết tắt của Network Address Translation, nghĩa là sửa trường địa chỉ trong header của packet. Server private gửi packet ra với source address là private IP của nó, ví dụ 10.0.1.50, mà địa chỉ đó không tồn tại trên internet nên không ai trả lời về được. NAT gateway nhận packet, thay source address bằng địa chỉ public của chính nó, rồi ghi nhớ cặp "ai vừa gửi, gửi tới đâu" vào một bảng dịch. Phản hồi từ internet quay về địa chỉ public đó, NAT gateway tra bảng, dịch destination address trở lại thành 10.0.1.50 rồi chuyển vào trong. Vì bảng dịch chỉ có entry khi server private chủ động gửi ra trước, một packet tự dưng từ internet đi vào sẽ không khớp entry nào và bị bỏ.

💡 Hình dung: NAT gateway giống người đi chợ hộ cho cả xóm. Người trong xóm không ra mặt ngoài chợ, chỉ nhờ mua rồi nhận hàng về. Người bán hàng chỉ biết đúng một khách là người đi chợ, nên có muốn tìm vào nhà ai trong xóm cũng không có địa chỉ mà tìm. Chiều mua thông suốt, chiều ngược lại thì tắc, và mức bảo vệ cần có nằm đúng ở chỗ đó.

NAT gateway không thay thế internet gateway

Một ngộ nhận thường gặp là NAT gateway là phương án thay thế cho internet gateway, dùng cái này hoặc cái kia. Không phải vậy: dùng NAT gateway thì vẫn cần internet gateway, vì bản thân NAT gateway phải có internet access.

Trình tự dựng NAT gateway

1. Cấu hình internet gateway và attach vào VPC.
2. Tạo một public subnet, có default route trỏ về internet gateway.
3. Triển khai NAT gateway vào public subnet đó. Có thể hình dung NAT gateway như một server đang chạy trên public subnet: nó là thiết bị public, có internet access đầy đủ, và internet trả traffic về được cho nó.
4. Cấu hình routing để thiết bị trong private subnet có default route trỏ về NAT gateway.

Luồng packet

Packet đi từ private subnet theo thứ tự:

1. Server trong private subnet gửi packet tới NAT gateway.
2. NAT gateway nằm trên public subnet nên forward được tiếp.
3. Packet ra internet gateway, rồi ra internet.

Chiều ngược lại không khởi tạo được: server không có public IP nên internet không nói chuyện trực tiếp với nó được.

Đặc tính của NAT gateway

Đặc tính	Nội dung
Loại service	Managed service: chỉ cần triển khai, AWS quản phần còn lại
Phạm vi resilient	Availability Zone, không phải region, với NAT gateway ở chế độ zonal (chế độ mặc định, xem phần dưới)
IP sử dụng	Elastic IP, bắt buộc với NAT gateway loại public
Protocol hỗ trợ	TCP, UDP và ICMP, không có protocol nào khác
Họ địa chỉ	Dùng được cho cả IPv4 và IPv6. Với IPv6 nó làm NAT64, đi kèm DNS64 trên Route 53 Resolver, để workload IPv6 gọi được tới service chỉ có IPv4
Billing	Theo giờ chạy cộng theo mỗi gigabyte dữ liệu xử lý
Bandwidth	Hỗ trợ 5 Gbps, tự scale lên tới 100 Gbps
Packet rate	Xử lý 1 triệu packet mỗi giây, tự scale lên 10 triệu; vượt mức đó thì packet bị drop
Số connection đồng thời	55.000 connection tới mỗi destination duy nhất trên mỗi IPv4 address, nên gắn thêm address là cách nâng trần này
Port dùng cho NAT	Dải 1024-65535, cần biết khi viết rule NACL cho subnet chứa NAT gateway
Security group	Không gán được security group lên NAT gateway. Việc siết traffic làm ở security group của instance, hoặc ở NACL của subnet

NAT gateway có hai connectivity type, chọn lúc tạo và không đổi được sau đó:

• Public (mặc định): nằm trên public subnet, phải gắn Elastic IP, route traffic ra internet qua internet gateway. Đây là loại dùng cho tình huống server private cần tải update.
• Private: không gắn Elastic IP, và không dùng để ra internet. Nó dành cho việc cho private subnet nói chuyện sang VPC khác hoặc sang data center riêng qua kết nối VPN, mà vẫn giữ nguyên tính chất một chiều. Attach internet gateway vào VPC thì vẫn được, nhưng nếu route traffic từ private NAT gateway sang internet gateway thì internet gateway sẽ drop traffic đó.

Phạm vi chịu lỗi: zonal và regional

Khác biệt quan trọng so với internet gateway: NAT gateway ở chế độ zonal không region-resilient. Nó được triển khai vào một subnet, nên gắn với một Availability Zone. AWS có dự phòng sẵn bên trong Availability Zone đó, nhưng Availability Zone sập thì mất NAT gateway.

Muốn có redundancy theo cách kinh điển thì triển khai NAT gateway vào nhiều Availability Zone, rồi cho private subnet ở mỗi Availability Zone trỏ về NAT gateway cùng Availability Zone với nó. Khi một Availability Zone lỗi thì chỉ phần resource trong đó mất đường ra, phần còn lại vẫn chạy.

AWS bổ sung thêm một chế độ thứ hai là regional NAT gateway, chọn ở ô Availability mode lúc tạo. Chế độ này không cần chỉ định subnet và không cần public subnet để chứa nó: một NAT gateway ID duy nhất tự mở rộng và thu lại theo các Availability Zone đang có network interface, nên mọi private subnet trong VPC dùng chung một route entry. Nó cũng nâng trần địa chỉ lên 32 IP mỗi Availability Zone, so với 8 của chế độ zonal. Giới hạn cần nhớ: regional NAT gateway không hỗ trợ private NAT, nên nhu cầu private connectivity vẫn phải dùng chế độ zonal. Việc mở rộng sang một Availability Zone mới có thể mất tới 60 phút, trong thời gian đó traffic được xử lý chéo zone.

Với chế độ zonal, route table của private subnet cần một default route trỏ về NAT gateway, mà NAT gateway lại nằm ở subnet khác, chính là public subnet.

---

11. Thực hành: NAT gateway

Mục tiêu: EC2 instance có internet access, nhưng chỉ khi connection do phía AWS khởi tạo. Internet không khởi tạo được connection vào instance.

Bước 1: tạo VPC và private subnet. Create VPC, CIDR 10.0.0.0/16, không cần IPv6. Tạo subnet tên Private Subnet, CIDR 10.0.1.0/24.

Bước 2: triển khai EC2 instance vào private subnet. Launch instance, tên PrivateServer, image Amazon Linux mặc định. Ở network settings: chọn VPC demo, chọn Private Subnet, không bật public IP. Dùng security group mới mặc định.

Lý do không cần public IP: ý tưởng của NAT gateway là server này là server private, nó có internet access qua NAT gateway nhưng không cần public IP cho việc đó.

Sau khi launch, kiểm tra instance: không có public IP address. Nghĩa là không truy cập được vào nó, trừ khi đã VPN vào VPC hoặc có một kết nối nào khác vào VPC, vì đây là private instance.

Bước 3: tạo internet gateway và public subnet. Trước khi triển khai NAT gateway phải có internet gateway attach vào VPC, vì NAT gateway phải nằm trên public subnet mà public subnet lại cần internet gateway.

1. Vào Internet Gateway, create một cái tên My internet gateway, rồi attach vào VPC.
2. Tạo subnet tên public subnet, Availability Zone không quan trọng, CIDR 10.0.2.0/24.

Bước 4: tạo hai route table. Một cho public subnet, một cho private subnet, để route hai bên khác nhau: private subnet có default route tới NAT gateway, public subnet có default route tới internet gateway.

Vào Route Tables, tạo Public Route Table và Private Route Table, cả hai chọn VPC demo. Filter theo VPC sẽ thấy ba route table, cái thứ ba là default route table được tạo tự động.

Cấu hình public route table:

1. Thêm route: destination default route, target là internet gateway. Save.
2. Subnet associations: chọn Public subnet. Save association.

Cấu hình private route table: gán Private subnet vào. Phần route tới NAT gateway để sau, vì NAT gateway chưa tồn tại.

Bước 5: tạo NAT gateway. Vào NAT Gateways, bấm Create NAT gateway:

• Name: my NAT Gateway.
• Subnet: chọn public subnet. Đây là điểm bắt buộc.
• Elastic IP: bấm Allocate Elastic IP để tạo một Elastic IP, nhờ đó NAT gateway có một IP cố định không đổi.
• Connectivity type: để Public, vì mục tiêu ở đây là ra internet.
• Các setting tùy chọn khác để nguyên.

Bấm Create, và NAT gateway ban đầu ở trạng thái pending trong vài phút trước khi chuyển sang available.

Bước 6: thêm route tới NAT gateway. Về Route Tables, mở Private Route Table, vào tab Routes, bấm Edit routes, Add route: destination là default route, target là NAT Gateway vừa tạo, rồi Save changes.

Bước 7: quan sát vấn đề resilience. Mở NAT gateway ra xem subnet của nó: ví dụ subnet đó nằm ở us-east-1b.

Đây là chỗ cần nhớ: NAT gateway không resilient ở mức VPC, chỉ resilient trong một Availability Zone. Availability Zone chứa subnet của NAT gateway sập thì mất NAT gateway, và mọi server, bất kể nằm ở Availability Zone nào, đều mất internet access.

Trong môi trường thật nên triển khai nhiều NAT gateway ở nhiều Availability Zone khác nhau: thêm một cái ở us-east-1a hoặc us-east-1c làm NAT gateway dự phòng. Sau đó cấu hình routing theo ý muốn, ví dụ server ở us-east-1a luôn đi qua NAT gateway ở us-east-1a, server ở us-east-1b đi qua NAT gateway ở us-east-1b, và khi một cái sập thì fail over sang Availability Zone khác.

Cách thứ hai cho đúng vấn đề này là chọn Availability mode là Regional ngay lúc tạo. Khi đó không phải chỉ định subnet, không phải nhân bản NAT gateway theo từng Availability Zone, và mọi private route table dùng chung một NAT gateway ID. Trừ khi cần private NAT, đây là lựa chọn gọn hơn cho một thiết kế mới.

---

12. Chọn public subnet hay private subnet

Một application trên AWS dùng được cả hai loại subnet cùng lúc. Câu hỏi để quyết định cho từng subnet chỉ có một:

💡 Thiết bị trên internet có cần tương tác được với resource triển khai trên subnet này không? Có thì subnet là public. Không thì subnet là private.

Ví dụ 1: web server đơn giản

Web server phải nằm trên public subnet, vì người dùng trên internet cần tương tác với website.

Ví dụ 2: web application có database

• Web server: public subnet, như trên.
• Database: private subnet. Thông thường không nên phơi database ra cho người dùng hay ra internet, vì nó chứa thông tin nhạy cảm. Xét từ góc nhìn của database, chỉ web server mới cần nói chuyện với nó.

Luồng truy cập trở thành: người dùng nói chuyện với web server trên public subnet, rồi web server nói chuyện sang private subnet để tới database. Nhờ vậy database được bảo vệ khỏi người dùng cuối: họ luôn phải đi qua web server, và web server có sẵn code đã định nghĩa trước để tương tác với database một cách an toàn.

Ví dụ 3: AWS như phần mở rộng của data center riêng

Một use case phổ biến của cloud là dùng AWS làm phần mở rộng cho data center riêng. Khi đó triển khai toàn bộ resource vào private subnet và dùng VPN để nối data center với các resource trên AWS. VPN viết tắt của Virtual Private Network, một đường hầm mã hóa chạy trên internet công cộng nhưng hai đầu nhìn nhau như cùng một mạng nội bộ, nên traffic giữa data center và VPC không bao giờ phơi ra ngoài.

Vì đây là phần mở rộng của một data center riêng, không cần làm các subnet này public: data center riêng vốn để chứa server, resource và thiết bị không cần internet access.

Ba điểm chốt lại cho mỗi subnet

• Resource trong public subnet: truy cập được tới và từ internet.
• Resource trong private subnet: không truy cập được từ internet.
• Gateway là thứ quyết định một subnet là public hay private.

Khi thiết kế một hệ thống mới, cách làm an toàn là đặt mặc định mọi subnet ở trạng thái private, rồi mở ra public đúng những subnet có resource mà người ngoài phải gọi tới được. Mở thêm thì dễ, thu lại một subnet đã phơi ra thì không.

---

13. DNS trong VPC

DNS, viết tắt của Domain Name System, là cơ chế dịch một cái tên dễ đọc thành IP address tương ứng. Không có DNS thì mọi kết nối phải gõ số, và đổi địa chỉ của một server là phải sửa mọi nơi đang gọi tới nó. Trong VPC, AWS dựng sẵn một DNS server để giải quyết việc này mà không cần tự cài gì.

Khi resource như EC2 instance được triển khai vào subnet, nó nhận một private IP address. Chuyện này đúng với cả private subnet và public subnet.

Mặc định mọi private IP address gán cho EC2 instance đều nhận một DNS name. DNS name đó có IP address nhúng ngay trong tên.

Ví dụ một server triển khai trên public subnet, nhận IP 10.0.100.10. AWS cũng gán cho nó một domain name có 10-0-100-10 nằm trong tên. Resource khác muốn nói chuyện với instance này thì gửi tới 10.0.100.10, hoặc gửi tới domain name đó, đều được.

Điểm cần nhớ: mặc định này chỉ áp dụng cho private IP address. Public IP không tự có DNS name.

Hai cách tới DNS server của AWS

Để resolve các DNS entry này, server phải query DNS server của AWS. Tên chính thức của nó trong tài liệu AWS là Route 53 Resolver, còn hai tên gọi khác hay gặp là Amazon DNS server và AmazonProvidedDNS. Nó được dựng sẵn trong từng Availability Zone của region, không phải một instance mà khách hàng tự quản.

AWS cho ba đường vào:

Cách	Address
Address cố định dùng chung, IPv4	169.254.169.253
Address cố định dùng chung, IPv6	fd00:ec2::253
Address thứ hai của VPC CIDR block	VPC 10.10.0.0/16 thì DNS server ở 10.10.0.2

Address thứ hai trong CIDR block của VPC luôn là đường tới DNS server. VPC 10.20.0.0/16 thì DNS server ở 10.20.0.2. Với VPC có nhiều CIDR block thì address này nằm trong CIDR block chính, không phải trong block phụ. Mọi resource đều truy cập được 169.254.169.253, kể cả subnet chỉ dùng IPv6, miễn AmazonProvidedDNS còn là nameserver trong DHCP option set.

Ba chi tiết đi kèm nên nhớ:

• Không filter được bằng firewall. Security group và NACL đều không chặn được traffic tới Route 53 Resolver. Muốn lọc DNS query thì phải dùng Route 53 Resolver DNS Firewall.
• Giới hạn 1.024 packet mỗi giây trên mỗi network interface cho toàn bộ traffic tới các địa chỉ link-local. Hạn mức này tính gộp DNS query, request lấy instance metadata và request đồng bộ thời gian, và không nâng được.
• Route 53 Resolver chỉ trả lời recursive query.

Hai knob DNS của custom VPC

Khi tạo một custom VPC có hai knob ảnh hưởng tới cách DNS làm việc.

enableDnsHostnames: quyết định VPC có hỗ trợ gán public DNS hostname cho các instance có public IP address hay không. Trong console nó hiện ra với tên DNS hostnames.

• Mặc định private IP có DNS entry, public IP không có.
• Muốn public IP address cũng có domain name thì phải bật knob này. Sửa được cả sau khi VPC đã tạo, qua Actions rồi Edit VPC settings.
• Giá trị mặc định của attribute này là false, trừ khi VPC là default VPC.
• Instance nhận public DNS hostname khi nó có public IPv4 address hoặc một Elastic IP.

enableDnsSupport: quyết định VPC có hỗ trợ DNS resolution qua DNS server do Amazon cung cấp hay không. Trong console nó hiện ra với tên DNS resolution.

• Giá trị mặc định của attribute này là true, cho cả default VPC và custom VPC.
• Attribute này ở true thì query tới DNS server của Amazon thành công.
• Không bật knob này thì không có DNS resolution nào cả, không thể giao tiếp bằng các domain name mà AWS cấp.

Hai knob này không độc lập với nhau như vẻ ngoài của chúng. Quy tắc chính xác là:

• Cả hai ở true: instance có public IP nhận đúng public DNS hostname, và Route 53 Resolver resolve được các private DNS hostname do Amazon cấp.
• Chỉ cần một trong hai ở false: instance có public IP không nhận public DNS hostname, và Route 53 Resolver cũng thôi resolve private DNS hostname do Amazon cấp. Lúc đó instance chỉ còn private hostname theo domain name tự khai trong DHCP option set, và việc resolve hostname đó là việc của DNS server riêng.
• Dùng private hosted zone của Route 53, hoặc private DNS cho interface VPC endpoint, thì bắt buộc cả hai phải ở true.

---

14. Thực hành: hai knob DNS của VPC

Môi trường: một custom VPC chưa sửa setting nào, đã attach internet gateway nên có public subnet. Mọi custom VPC mới tạo đều có cùng cấu hình DNS này.

Xem hai knob: chọn VPC, mở Actions rồi Edit VPC settings. Ở đó có:

• Enable DNS resolution: cho phép dùng DNS server để resolve hostname.
• Enable DNS hostnames: khi instance có public IP address, cấp cho public IP đó một domain name.

Phần một: enable DNS hostnames

Để Enable DNS hostnames ở trạng thái disabled, bấm Cancel.

Vào EC2, launch một instance tên DNS Demo, giữ các tùy chọn mặc định, chọn một key pair có sẵn. Đổi VPC sang VPC đang xét, bật auto-assign public IP. Thêm một rule cho ICMP từ 0.0.0.0/0 để có thể ping. Launch.

Sau khi instance lên, xem các IP address của nó:

• Có public IP address.
• Có private IP address, và private IP này có DNS name. Nghĩa là server khác trong VPC gửi request tới tên đó sẽ resolve về đúng server này.
• Không có public IPv4 DNS name. Cột đó trống vì enableDnsHostnames đang ở false.

Bật knob lên: Actions → Edit VPC settings → bật Enable DNS hostnames → Save. Refresh lại trang instance thì cột public IPv4 DNS giờ có một DNS name. Từ đây người dùng và application truy cập được public IP address qua DNS name đó. Kiểm tra bằng ping:

ping <public-dns-name>
# resolve về đúng public IP, ví dụ 35.173.226.213

Phần hai: enable DNS resolution

Kết nối vào instance rồi kiểm tra DNS server mà nó đang dùng:

ssh -i <key>.pem ec2-user@<public-ip>

cat /etc/resolv.conf
# nameserver 10.0.0.2

VPC có CIDR 10.0.0.0/16 nên DNS server của AWS ở address thứ hai, tức 10.0.0.2, và đó đúng là nameserver mà hệ thống đang dùng.

Thử resolve một domain name:

nslookup google.com
# resolve thành công nhờ DNS server của AWS

Việc này chạy được chỉ vì Enable DNS resolution đang bật trong cấu hình VPC.

Giờ tắt knob đó đi và Save. Việc này làm AWS không trả lời bất kỳ DNS request nào từ các instance đang chạy trong VPC. Thử lại với một domain name khác:

nslookup youtube.com
# thất bại

Lý do: instance vẫn gửi DNS request tới 10.0.0.2, nhưng AWS giờ được cấu hình để không trả lời.

Nếu đã tắt knob này thì phải trỏ sang một DNS server khác, ví dụ DNS công khai của Google là 8.8.8.8, hoặc một DNS server nội bộ trong AWS, hoặc bất kỳ DNS server nào khác mà EC2 instance truy cập được.

Hai tùy chọn này cần nắm cho kỳ thi Solutions Architect, vì đề có thể hỏi về cả hai.

---

15. Elastic IP

Vấn đề cần giải

EC2 instance triển khai lên public subnet nhận một public IP, ví dụ 1.1.1.1. Vấn đề là public IP đó không được reserve cho instance. Nó không thuộc sở hữu của ai. Instance reboot xong, khi lên lại có thể nhận một IP address hoàn toàn khác.

Hệ quả cho application: người dùng cuối phải tự biết cách cập nhật IP address mới của back-end server, điều này không chấp nhận được.

Elastic IP là gì

Elastic IP address là một static IPv4 address. Cơ chế gồm hai bước:

1. Allocate một IP address vào account. Khi đã allocate, IP đó được reserve cho account, không ai khác lấy được, và nó thuộc về account chừng nào còn được allocate.
2. Associate Elastic IP đó với một server.

Khi đã associate với một EC2 instance, instance đó luôn giữ IP address ấy, chừng nào IP còn được reserve trong account và còn associate với instance. Instance reboot hay bị chuyển sang physical host khác cũng không đổi IP.

Lợi thế khi bảo trì

Elastic IP cho phép gán một cấu hình network cố định lên một interface cụ thể, kèm security group của EC2 instance.

Ứng dụng thực tế: cần bảo trì một EC2 instance thì disassociate Elastic IP khỏi instance đó và associate sang một server khác đang chạy cùng application. Người dùng lập tức được trỏ sang server mới, trong khi server cũ được bảo trì. Thao tác chỉ là chuyển cái IP.

Pricing

Chính sách tính phí ở đây đã đổi và cần đọc kỹ, vì nhiều tài liệu cũ vẫn ghi theo quy tắc trước đó. Từ 1-2-2024, AWS tính phí mọi public IPv4 address, bất kể nó đang gắn vào resource hay đang để không. Không còn trường hợp Elastic IP miễn phí khi đang dùng.

Trường hợp	Chi phí
Một Elastic IP associate với một instance đang chạy	0,005 USD mỗi giờ, trước 1-2-2024 là miễn phí
Public IPv4 address do AWS tự cấp cho instance	0,005 USD mỗi giờ
Elastic IP thứ hai trở lên associate với cùng instance đó	0,005 USD mỗi giờ cho mỗi IP, mức này không đổi
Elastic IP đã reserve nhưng không associate với instance nào	0,005 USD mỗi giờ, mức này không đổi
Address tự mang vào AWS qua BYOIP	Không bị tính phí public IPv4

Free tier của EC2 bù lại một phần: 750 giờ dùng public IPv4 mỗi tháng, chỉ trong 12 tháng đầu của account.

Hệ quả thực tế cho một account học tập: một Elastic IP để quên, dù đang gắn vào instance đang chạy, vẫn phát sinh khoảng 3,6 USD mỗi tháng. Nên phần dọn dẹp ở cuối mỗi bài thực hành không còn là thao tác cho gọn mà là thao tác cần làm.

Các điểm cần lưu ý

• Elastic IP gắn với một region, không chuyển sang region khác được. Vì vậy nó chỉ associate được với EC2 instance trong cùng region đó.
• Elastic IP chỉ có IPv4. AWS không cấp Elastic IP cho IPv6, vì địa chỉ IPv6 vốn đã là địa chỉ public toàn cầu và không cần lớp dịch này.
• Mỗi account mặc định được 5 Elastic IP mỗi region, nâng được qua Service Quotas. Lý do AWS đặt trần thấp là IPv4 public đang là tài nguyên khan hiếm.
• Elastic IP lấy từ pool IPv4 address của Amazon, hoặc từ một custom IPv4 address pool mà khách hàng tự mang vào AWS account của mình. Address mang vào không tính vào trần 5 cái ở trên.
• Để dùng: allocate trước, rồi associate với instance hoặc với network interface.
• Associate Elastic IP lên một instance đang có public IP do AWS cấp thì public IP cũ bị trả lại pool của Amazon và không lấy lại được. Nó cũng không chuyển đổi thành Elastic IP.
• Khi allocate, có một setting là network border group, tức phạm vi mà AWS quảng bá dải address đó ra ngoài. Để trống thì AWS lấy nguyên region làm phạm vi.

---

16. Thực hành: Elastic IP

Môi trường chuẩn bị trước: một VPC, một subnet, một internet gateway đã attach, subnet đã được làm public, và một server tên My Server triển khai trên public subnet đó. Server có một public IP address.

Phần một: public IP thường không cố định

Ghi lại public IP hiện tại, ví dụ 52.90.159.117.

Vào Instance state và Stop instance, chờ vài phút cho dừng hẳn. Khi đã stop, quan sát: không còn public IP address nào.

Giờ Start instance. Instance chuyển sang pending, chờ vài phút cho boot xong. Khi lên lại, public IP là một address khác, ví dụ bắt đầu bằng 3, không còn là 52.90.159.117.

Đây là điểm cần thấy rõ: public IP cấp cho server không cố định. Chỉ giữ được address đó chừng nào server còn chạy. Server tắt rồi reboot là nhận public IP khác.

Hệ quả: nếu người dùng đang trỏ tới một IP cụ thể mà server reboot thì họ phải được cập nhật địa chỉ mới, nghĩa là phải sửa code hoặc phải có một cơ chế cập nhật nào khác. Elastic IP tồn tại để cắt bỏ đúng lớp việc đó.

Phần hai: allocate và associate Elastic IP

Trong EC2 dashboard, cuộn xuống mục Elastic IPs, bấm Allocate Elastic IP address:

• Border group: để mặc định.
• Nguồn: chọn Amazon pool of IPv4 address.
• Bấm Allocate.

Elastic IP được cấp, ví dụ 35.173.92.86. Address này giờ reserve cho account: chừng nào còn reserve thì không khách hàng nào khác lấy được nó.

Tiếp theo associate nó vào instance: mở Actions → Associate Elastic IP address:

• Chọn associate với instance hoặc với network interface, ở đây chọn instance.
• Chọn instance muốn gán.
• Nếu instance có nhiều private IP address thì phải chỉ định associate với private IP nào. Một server có nhiều interface, mỗi interface một private IP khác nhau, nên phải nói rõ gán vào cái nào. Ở đây chỉ có một nên chọn luôn.
• Bấm Associate.

Về mục Instances và refresh: public IP address của instance giờ chính là 35.173.92.86, tức Elastic IP. Kiểm tra kết nối:

ping 35.173.92.86
# phản hồi đầy đủ, reachability tốt

Phần ba: xác nhận IP giữ nguyên qua reboot

Vào Instance state, Stop instance, chờ dừng hẳn, rồi Start instance.

Khi server lên lại, public IP vẫn đúng address cũ, chính là Elastic IP. Elastic IP giữ nguyên qua reboot, nên không còn phải lo chuyện IP address đổi.

Phần bốn: dọn dẹp, và thứ tự bắt buộc

Để không bị tính phí cho Elastic IP, cần disassociate rồi mới release. Chỉ disassociate thôi thì chưa đủ: address vẫn còn reserve trong account nên vẫn bị tính 0,005 USD mỗi giờ. Phí chỉ dừng sau bước release.

Thử release trước khi disassociate sẽ nhận lỗi The following address cannot be released because they are associated.

Thứ tự đúng:

1. Chọn Elastic IP, mở Actions, chọn Disassociate Elastic IP address. Mục này có lúc chưa hiện, ví dụ khi server đang trong quá trình shutdown hoặc đang làm việc gì khác; chờ một lúc sẽ hiện.
2. Sau khi disassociate, chọn Release Elastic IP address.

Xong bước 2, address đó không còn reserve trong account nữa.

---

17. Firewall stateless và stateful

Security group và NACL đều hoạt động như firewall. Để hiểu hai feature này cần hiểu trước firewall và các loại firewall.

Firewall làm gì

Tình huống: một web server listen trên port 443, chờ client gửi HTTPS request. Client gửi request trên port 443, server gửi response lại.

Mục đích của firewall là theo dõi traffic và chỉ cho phép traffic được một tập rule định trước cho phép. Rule của firewall chia thành hai hướng:

• Inbound rule: theo dõi connection đi vào web server hay resource cần bảo vệ.
• Outbound rule: bảo vệ traffic rời khỏi web server đi tới client hoặc tới bất kỳ đâu.

Có hai loại firewall: stateless và stateful.

💡 Hình dung: hai loại firewall này giống hai người bảo vệ cùng đứng ở một cổng. Người thứ nhất không có sổ sách, chỉ đọc đúng tờ nội quy dán trên tường mỗi lần có người đi qua; khách vừa được cho vào, mười giây sau đi ra lại bị chặn vì nội quy không có dòng nào cho phép đi ra. Người thứ hai mang theo một quyển sổ và ghi lại từng lượt khách đã cho vào; khách đó quay ra thì không cần tra nội quy nữa, vì sổ đã có tên. Người thứ nhất là firewall stateless, người thứ hai là firewall stateful.

Firewall stateless

Để thấy khác biệt, dễ nhất là xem cách cấu hình.

Tình huống 1: client gọi vào web server ở port 443.

Hướng	Rule cần có
Inbound	Allow traffic vào port 443
Outbound	Allow traffic đi tới dải ephemeral port 1024-65535

Lý do cần rule outbound: cách TCP làm việc là khi client gửi request tới server, destination port là 443 còn source port là một ephemeral port ngẫu nhiên. Nên ở chiều ngược lại, destination chính là dải ephemeral port đó, và phải allow nó.

Dải ephemeral port cụ thể do phía khởi tạo kết nối chọn, nên nó phụ thuộc hệ điều hành của client, không phải một con số cố định:

Phía khởi tạo	Dải port
Kernel Linux, gồm cả Amazon Linux	32768-61000
Windows Server 2008 trở lên	49152-65535
Elastic Load Balancing	1024-65535
NAT gateway	1024-65535
AWS Lambda	1024-65535

Vì một web server công khai nhận request từ đủ loại client, cách làm thực tế là mở cả dải 1024-65535 rồi thêm rule deny cho những port cần chặn, và đặt rule deny ở số nhỏ hơn để nó được xét trước.

Tình huống 2: web server tự gọi ra một update server ở port 80 để lấy update cho các library và package.

Hướng	Rule cần có
Outbound	Allow traffic đi tới port 80, vì request do server khởi tạo
Inbound	Allow traffic từ dải ephemeral port về

Điểm cốt lõi của firewall stateless: phải cấu hình cả inbound và outbound. Firewall stateless không có trí thông minh nào, nó không theo dõi connection. Nó chỉ xét inbound rule và outbound rule một cách tách biệt.

Firewall stateful

Cùng tình huống web server listen port 443, client gửi request trên port 443.

Tình huống 1:

Hướng	Rule cần có
Inbound	Allow traffic vào port 443, giống stateless
Outbound	Không cần rule

Lý do: firewall stateful đủ thông minh để hiểu request nào và response nào thuộc cùng một connection. Nó theo dõi TCP session, nhận ra "đây là request, kia là response của request đó". Request đã được firewall stateful cho phép thì response tự động được cho phép.

Tình huống 2: web server gọi ra update server ở port 80.

Hướng	Rule cần có
Outbound	Allow traffic tới port 80
Inbound	Không cần rule

Firewall stateful hiểu response ở chiều inbound là response của request outbound đã được phép, nên tự cho phép.

Quy tắc cần mang theo khi viết rule: với firewall stateful, chỉ cần allow traffic cho request gốc, response theo sau tự động được cho phép. Với firewall stateless, mỗi chiều là một bài toán riêng và chiều nào cũng phải có rule của nó.

---

18. NACL và security group

AWS cung cấp hai loại firewall, tương ứng hai loại ở trên.

Network Access Control List (NACL)

Đặc tính	Nội dung
Phạm vi	Filter traffic vào và ra khỏi một subnet
Mỗi subnet	Đều có một NACL quyết định traffic nào được vào và ra
Traffic trong subnet	Không bị filter: hai server cùng subnet luôn nói chuyện được với nhau
Loại firewall	Stateless
Hệ quả	Phải đặt rule cho cả inbound và outbound

Security group

Đặc tính	Nội dung
Phạm vi	Firewall cho từng resource riêng lẻ
Áp vào đâu	EC2 instance, load balancer, RDS instance, ENI, và các network object khác
Loại firewall	Stateful
Hệ quả	Chỉ cần allow request, ở chiều nào cũng vậy, response tự động được allow

ENI trong dòng trên viết tắt của Elastic Network Interface, tức card mạng ảo của một resource trong VPC. Mỗi EC2 instance có ít nhất một ENI, và private IP address của instance thực ra được gán lên ENI chứ không lên instance. Nói chính xác thì security group gắn vào ENI, nên gắn security group lên instance chỉ là cách gọi tắt của việc gắn nó lên ENI chính của instance đó.

Cả security group và NACL đều không phát sinh phí riêng.

Nhắc lại khác biệt cốt lõi

• NACL theo dõi traffic vào và ra khỏi subnet, là firewall stateless, nên traffic phải được allow ở cả hai chiều ingress và egress.
• Security group là firewall riêng cho từng resource, là firewall stateful, nên chỉ cần allow request ở chiều của nó, response tự động được allow.

---

19. Cấu trúc rule của security group và NACL

Rule của security group

Trong console, security group có một mục inbound rules và một mục outbound rules. Hai mục quản lý độc lập nhau nhưng cấu trúc rule giống nhau 100%, nên cách cấu hình outbound rule không khác inbound rule chút nào.

Các cột của một rule:

Cột	Ý nghĩa
Name	Tên gợi nhớ cho rule. Tùy chọn, để trống được
Rule ID	Định danh duy nhất của rule đó
IP version	IPv4 hoặc IPv6, quyết định rule áp cho loại traffic nào
Type, Protocol, Port range	Ba cột làm việc cùng nhau, xem bên dưới
Source (inbound) hoặc Destination (outbound)	Từ hoặc tới IP address nào
Description	Mô tả mục đích của rule, cho người quản trị sau này đọc lại

Về ba cột Type, Protocol, Port range: đặt Type là HTTP thì AWS tự hiểu HTTP là protocol dựa trên TCP và listen trên port 80, nên tự điền luôn protocol và port. Chỉ cần nói là HTTP.

Muốn dùng một port không thuộc nhóm well-known thì đặt Type là custom TCP, rồi tự chỉ định protocol là TCP và tự điền port range. Port range nhận một port đơn như 200, hoặc một dải như 200-300 để khớp cả 100 port.

Về cột Source: giá trị 0.0.0.0/0 nghĩa là mọi IP address. Muốn giới hạn thì đổi source thành IP cụ thể, ví dụ 1.1.1.1 để chỉ cho phép HTTP traffic từ đúng address đó.

Ví dụ hai rule:

Rule	IP version	Type	Protocol	Port range	Source
1	IPv4	HTTP	TCP	80	0.0.0.0/0
2	IPv4	Custom TCP	TCP	200	1.1.1.1

Rule 2 chỉ khớp traffic đến từ 1.1.1.1 trên port 200.

Outbound rule mặc định của một security group: Type là All traffic, nên không quan trọng là TCP, UDP hay ICMP, tất cả đều khớp; protocol là tất cả, port range là tất cả, destination là mọi IP address.

Ba quy tắc của security group

1. Không có rule nào thì block tất cả. Không rule nghĩa là không cho phép gì.
2. Mọi rule của security group đều là allow. Thêm một rule là đang cho phép một loại traffic. Không có tùy chọn deny, không viết được rule chặn một loại traffic. Cơ chế là implicit deny rồi allow từng luồng traffic cần thiết.
3. Mặc định security group có outbound rule allow toàn bộ outbound traffic. Rule này xóa được. Nếu đề thi hỏi thì câu trả lời là: mặc định security group cho phép toàn bộ outbound traffic.

Rule của NACL

Rule của NACL khác security group ở hai điểm.

Thứ nhất là rule number. Mỗi rule có một số, và rule được xử lý theo thứ tự số đó. Số nhỏ hơn được xử lý trước. Ví dụ rule 70 trước, rồi rule 80, rồi rule 90, và cuối cùng là default catch-all rule ở dưới cùng.

Thứ hai là có cả allow và deny. Rule của NACL chỉ định tường minh là deny hay allow một luồng. Đây là khác biệt chính so với security group.

Các cột còn lại của NACL giống security group: Type, Protocol, Port range, Source.

Gán nhiều security group lên một resource

Một resource gán được nhiều security group. Khi đó rule của các security group được merge lại với nhau.

Ví dụ:

Security group	Rule
web	allow port 80, allow port 443
management	allow port 3389, allow port 22

Gán cả hai lên một instance thì instance có một tập rule cuối cùng là tổ hợp của web và management, tức cả bốn port.

Quan hệ giữa subnet và NACL

Quy tắc	Nội dung
Mỗi subnet trong VPC	Phải được associate với một network ACL
Một network ACL	Associate được với nhiều subnet
Một subnet	Chỉ associate được với một network ACL tại một thời điểm

Traffic mà NACL không filter

Phần này không cần học thuộc, nêu ra cho đủ. Network ACL không filter traffic đi tới và đi từ các thứ sau:

• Amazon domain name service.
• Amazon dynamic host configuration protocol, tức traffic DHCP.
• Amazon EC2 instance metadata, các metadata endpoint.
• License activation cho các Windows instance.
• Amazon time sync service.
• Các IP address reserved mà default VPC router dùng.

Mọi loại traffic trên tự động được cho đi qua.

---

20. Thực hành: security group trên EC2 instance

Tạo một EC2 instance để gán security group vào. Tên Server One, image Linux mặc định, networking dùng một VPC đã có sẵn.

Tại phần cấu hình security group có hai lựa chọn: dùng một security group đã có, hoặc tạo mới. Ở đây tạo mới rồi sửa sau.

💡 Cấu hình security group cho mọi resource khác, dù là load balancer hay gì khác, đều theo đúng quy trình này. Tất cả dùng cùng một loại security group. Nghĩa là một security group vừa áp được cho EC2 instance, vừa áp được cho load balancer, vừa áp được cho resource hay service khác.

Security group mới mặc định có một rule: allow SSH traffic, protocol TCP. SSH là protocol dùng để kết nối vào server, nên muốn truy cập được server thì phải allow SSH.

Về cột Type:

• Chọn một well-known port như SSH thì AWS tự điền protocol và port.
• Đổi sang HTTP thì port tự cập nhật sang port của HTTP.
• Chọn custom TCP thì tự chỉ định port.
• Cần UDP thì chọn custom UDP rồi chỉ định port.

Ở đây giữ SSH.

Về cột Source, tức từ IP address nào được phép SSH: mặc định là anywhere, tức 0.0.0.0/0, nghĩa là bất kỳ IP address nào cũng SSH được vào server. Thường thì không muốn như vậy, mà chỉ muốn cho phép một dải cụ thể, ví dụ IP address của văn phòng chính của tổ chức.

💡 Nguồn dùng để soạn mục này bị cắt ở đúng chỗ này, nên phần còn lại của demo security group không có trong nguồn. Phần thực hành NACL ở mục 21 nối tiếp ngay sau đó và còn đầy đủ.

---

21. Thực hành: NACL ở mức subnet

Nhắc lại hai khác biệt đang được kiểm chứng ở đây: security group là stateful còn NACL là stateless, và NACL hoạt động ở mức subnet, filter những gì vào và ra khỏi một subnet, thay vì tập trung vào những gì vào và ra khỏi một resource.

Bước 1: vô hiệu hóa security group để không nhiễu kết quả

Để quan sát đúng tác dụng của NACL, cần làm cho security group không chặn gì.

Vào EC2 instances, kiểm tra security group của cả hai server. Ở đây server one có web server security group, còn server two ban đầu trông như không có security group nào, refresh lại thì thấy nó có hai.

Với từng server: Security → Change security groups → bỏ các security group hiện có → chỉ để lại Web Server Security Group. Làm cho cả hai server. Mục đích là chỉ còn đúng một security group để dễ kiểm soát.

Sau đó mở security group đó ra và sửa thành allow all:

• Inbound rules: xóa hai rule đang có, thêm một rule allow all traffic từ mọi IP address.
• Outbound rules: allow tất cả.

Giờ security group gần như không làm gì cả, đúng mục tiêu đặt ra.

Bước 2: xác định subnet và NACL tương ứng

Vào Instances, chọn server one, vào tab Networking để xem subnet của nó. Làm tương tự với server two. Cả hai cùng nằm trên một subnet, ví dụ subnet có ID kết thúc là a1683.

Về trang VPC, vào Security → Network ACLs. Chọn ACL của VPC đang xét. Đây là ACL mặc định được tạo cùng VPC, nhận ra qua cột Default: yes. Tab subnet associations xác nhận nó gắn với đúng subnet a1683, tức subnet chứa hai EC2 instance.

Bước 3: đọc rule mặc định của NACL

Tab Inbound rules có:

Rule number	Type	Protocol	Port range	Source	Allow/Deny
100	All traffic	All	All	0.0.0.0/0	Allow
*	All traffic	All	All	0.0.0.0/0	Deny

Rule được xét từ trên xuống, nên thứ tự quan trọng. Rule 100 khớp mọi thứ nên rule deny bên dưới không bao giờ được chạm tới.

Xác nhận trạng thái ban đầu: SSH vào server được, và refresh trang web thì website vẫn truy cập được.

Bước 4: chỉ allow SSH, quan sát hệ quả ở mức subnet

Sửa rule 100 thành: chỉ allow SSH, từ mọi IP address, action là Allow. Save changes.

Giờ dù security group allow toàn bộ traffic, NACL chỉ allow inbound SSH, mọi thứ khác rơi xuống rule deny ở dòng thứ hai.

Kiểm chứng:

• SSH vào server one: được.
• SSH vào server two bằng IP của nó: cũng được.

Đây là bằng chứng NACL hoạt động ở mức subnet chứ không phải mức resource: một thay đổi NACL áp lên cả hai instance vì chúng cùng subnet.

• Refresh trang web của server one: treo, không truy cập được.
• Refresh trang web của server two: cũng không được.

Cả hai bị chặn vì cùng subnet.

Bước 5: thêm rule cho HTTP và HTTPS

Vào Add new rule, với rule number là số lớn hơn 100 để được xét sau rule đầu:

Rule number	Nội dung
110	Allow HTTP
120	Allow HTTPS

Save changes. Giờ inbound rules có ba rule: allow SSH, HTTP, HTTPS. Refresh trang web: chạy được, và cũng chạy được cho server kia vì NACL ở mức subnet.

Bước 6: chứng minh NACL là stateless

Website của server two chưa chạy vì chưa cài NGINX trên đó. Thử cài:

sudo yum install nginx
# lệnh treo, không tải được package

Vì sao không cài được? Phân tích:

1. Server gửi request outbound ra internet để tải package. Xem outbound rules của NACL: đang allow tất cả. Chiều này không vấn đề.
2. Nhưng khi package được tải về, traffic đi vào, nên nó phải khớp một inbound rule. Inbound rules hiện chỉ allow SSH, HTTP, HTTPS. Response của việc tải package không nằm trong ba cái đó, nên bị deny.

Tính stateless lộ ra đúng ở chỗ này: khác security group, NACL không stateful, nên phải allow tường minh ở inbound ngay cả khi đã allow ở outbound.

Sửa tạm: thêm rule number 130 allow all traffic ở inbound. Lệnh cài package hoàn tất ngay sau khi save.

Đây là minh chứng trực tiếp: với NACL luôn phải allow ở cả hai chiều, còn với security group chỉ cần allow ở một chiều.

Khởi động NGINX rồi kiểm tra:

sudo systemctl start nginx

Trang web của server two giờ truy cập được. Sau đó xóa rule 130 allow all đi vì không cần nữa. Refresh lại cả hai trang web: vẫn chạy bình thường, vì HTTP và HTTPS đã có rule riêng.

Bước 7: dùng deny rule của NACL

Điểm cuối cần thấy: khác security group, NACL cho phép cả allow và deny, nên linh hoạt hơn.

Tình huống: muốn allow SSH từ mọi nơi trừ một dải address cụ thể, ví dụ từ một region nào đó.

Cách làm: giữ rule allow SSH từ mọi nơi, rồi thêm một rule với rule number nhỏ hơn để nó được xét trước, ví dụ rule 90:

Rule number	Type	Source	Allow/Deny
90	SSH	1.0.0.0/24	Deny
100	SSH	0.0.0.0/0	Allow

Danh sách sắp theo rule number, console tự sắp giúp. Cách xét từ trên xuống:

• SSH traffic từ 1.0.0.0/24: khớp rule 90, bị deny.
• SSH traffic từ bất kỳ đâu khác: không khớp rule 90, đi xuống rule 100, được allow.

Điểm cần nhớ cho kỳ thi: NACL cho phép cả allow và deny, còn security group chỉ cho phép allow.

---

Nguồn tham khảo

Nguồn gốc: Khóa "AWS Solutions Architect Associate Certification", chương "2. Services - Networking", nền tảng KodeKloud. Giảng viên: Sanjeev Thiagarajan. Nội dung bài viết được diễn giải lại bằng tiếng Việt và tổ chức theo cấu trúc riêng, không sao chép nguyên văn bài giảng.

Tên resource trong các phần thực hành (Demo VPC, subnet one, server two...) là tên ví dụ chung, đặt lại thế nào cũng được.

Fact-check:

• AWS tính phí mọi public IPv4 address từ 01/02/2024, mức 0,005 USD mỗi giờ, áp cho cả address đang gắn vào resource đang chạy và Elastic IP đang để không; address tự mang vào qua BYOIP không bị tính phí — 2026-10-29, New AWS Public IPv4 Address Charge
• Trước 01/02/2024, public IPv4 address đang sử dụng (gồm Elastic IP gắn vào resource trong VPC, Global Accelerator và Site-to-Site VPN tunnel) không bị tính phí; Elastic IP thứ hai trên instance đang chạy và Elastic IP idle đã ở mức 0,005 USD mỗi giờ từ trước — 2026-10-29, New AWS Public IPv4 Address Charge
• Free Tier của EC2 gồm 750 giờ dùng public IPv4 address mỗi tháng, chỉ trong 12 tháng đầu, hiệu lực từ 01/02/2024 — 2026-10-29, New AWS Public IPv4 Address Charge
• Elastic IP bị tính phí bất kể đang gắn vào resource hay đang idle trong account — 2026-10-29, Elastic IP addresses
• Elastic IP là static IPv4 address, chỉ dùng trong một region, lấy từ pool IPv4 của Amazon hoặc từ custom IPv4 address pool mang vào account; AWS không hỗ trợ Elastic IP cho IPv6 — 2026-10-29, Elastic IP addresses
• Trần mặc định là 5 Elastic IP mỗi region mỗi account, nâng được qua Service Quotas; address mang vào qua BYOIP không tính vào trần này — 2026-10-29, Elastic IP addresses
• Associate Elastic IP lên instance đang có public IPv4 address thì address cũ bị trả lại pool của Amazon, không lấy lại được và không chuyển đổi thành Elastic IP; khi allocate có thể đặt network border group, để trống thì phạm vi là toàn bộ region — 2026-10-29, Elastic IP addresses
• Default VPC có IPv4 CIDR block 172.31.0.0/16 cho 65.536 address, một default subnet /20 (4.096 address) trong mỗi Availability Zone, một internet gateway attach vào VPC, route 0.0.0.0/0 trỏ về internet gateway cạnh route 172.31.0.0/16 trỏ về local, một default security group, một default network ACL và DHCP option set mặc định của account — 2026-10-29, Default VPC components
• Default VPC tồn tại ở mỗi AWS Region, kèm public subnet trong mỗi Availability Zone và setting bật DNS resolution — 2026-10-29, Default VPCs
• IPv4 CIDR block của VPC cho phép từ /16 (65.536 address) tới /28 (16 address); mặc định 5 IPv4 CIDR block mỗi VPC tính cả block chính, nâng được tới 50 — 2026-10-29, VPC CIDR blocks
• Không gán được cho VPC các dải 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16 và 224.0.0.0/4; dải 172.17.0.0/16 nên tránh vì một số service của AWS dùng sẵn — 2026-10-29, VPC CIDR blocks
• IPv6 CIDR block của VPC nhận kích cỡ từ /44 tới /60 theo bước /4, tối đa 5 block mỗi VPC (nâng được tới 50); block do Amazon cấp là /56 — 2026-10-29, VPC CIDR blocks
• IPv4 CIDR block của subnet cho phép từ /28 tới /16 — 2026-10-29, Subnet CIDR blocks
• Mỗi subnet mất 5 địa chỉ: 4 địa chỉ đầu và địa chỉ cuối. Với 10.0.0.0/24 đó là .0 network address, .1 VPC router, .2 Route 53 Resolver (base của dải VPC cộng hai), .3 reserved cho tương lai, .255 broadcast address (VPC không hỗ trợ broadcast) — 2026-10-29, Subnet CIDR blocks
• IPv6 CIDR block của subnet nhận prefix từ /44 tới /64 theo bước /4, và cũng mất 4 địa chỉ đầu cùng địa chỉ cuối — 2026-10-29, Subnet CIDR blocks
• Route 53 Resolver (còn gọi là Amazon DNS server hoặc AmazonProvidedDNS) được dựng trong từng Availability Zone và truy cập được ở 169.254.169.253 (IPv4), fd00:ec2::253 (IPv6), và ở địa chỉ base của IPv4 CIDR block chính của VPC cộng hai, ví dụ 10.0.0.2 với VPC 10.0.0.0/16 — 2026-10-29, Understanding Amazon DNS
• Attribute enableDnsHostnames quyết định VPC có gán public DNS hostname cho instance có public IP address hay không, mặc định false trừ khi VPC là default VPC; attribute enableDnsSupport quyết định VPC có DNS resolution qua DNS server của Amazon hay không, mặc định true — 2026-10-29, Understanding Amazon DNS
• Chỉ cần một trong hai attribute DNS ở false thì instance có public IP address không nhận public DNS hostname và Route 53 Resolver cũng không resolve được private DNS hostname do Amazon cấp; private hosted zone của Route 53 và private DNS cho interface VPC endpoint đòi cả hai attribute ở true — 2026-10-29, Understanding Amazon DNS
• Instance nhận public DNS hostname khi có public IPv4 address hoặc Elastic IP, với điều kiện cả hai attribute DNS của VPC đang bật — 2026-10-29, Understanding Amazon DNS
• Security group và network ACL không filter được traffic tới hoặc từ Amazon DNS server; Route 53 Resolver chỉ hỗ trợ recursive query; giới hạn 1.024 packet mỗi giây mỗi network interface tính gộp DNS query, request IMDS, request NTP và Windows licensing, không nâng được — 2026-10-29, Understanding Amazon DNS
• Trong console, hai attribute này hiện với tên DNS hostnames và DNS resolution, sửa qua Actions rồi Edit VPC settings — 2026-10-29, View and update DNS attributes for your VPC
• Internet gateway là thành phần scale ngang, dự phòng sẵn và sẵn sàng cao, hỗ trợ cả IPv4 và IPv6; với IPv4 nó thực hiện NAT một-đối-một giữa public address và private address của instance — 2026-10-29, Enable internet access for a VPC using an internet gateway
• Subnet gắn vào route table có route tới internet gateway là public subnet, không có route đó là private subnet; bản thân internet gateway miễn phí, phần tính tiền là data transfer của EC2 instance đi qua nó — 2026-10-29, Enable internet access for a VPC using an internet gateway
• Mỗi VPC chỉ attach được một internet gateway tại một thời điểm, và một egress-only internet gateway tại một thời điểm; mặc định 5 internet gateway và 5 egress-only internet gateway mỗi region — 2026-10-29, Amazon VPC quotas
• NAT gateway hỗ trợ ba protocol TCP, UDP và ICMP; dùng port 1024-65535; mỗi IPv4 address chịu 55.000 connection đồng thời tới mỗi destination duy nhất, gắn tối đa 8 IPv4 address để nâng trần; không gán được security group lên NAT gateway — 2026-10-29, NAT gateway basics
• NAT gateway dùng được cho cả traffic IPv4 và IPv6; với IPv6 nó thực hiện NAT64, kết hợp DNS64 trên Route 53 Resolver, để workload IPv6 gọi tới resource chỉ có IPv4. Egress-only internet gateway là phương án khác cho outbound-only qua IPv6 — 2026-10-29, NAT gateways
• NAT gateway loại public phải nằm trên public subnet và phải associate một Elastic IP lúc tạo, rồi route traffic ra internet gateway; NAT gateway loại private không associate được Elastic IP và chỉ dùng để tới VPC khác hoặc mạng on-premises, nếu route nó sang internet gateway thì internet gateway drop traffic — 2026-10-29, NAT gateways
• Phí NAT gateway tính theo giờ chạy cộng theo mỗi gigabyte dữ liệu xử lý — 2026-10-29, Amazon VPC Pricing
• NAT gateway hỗ trợ 5 Gbps bandwidth và tự scale tới 100 Gbps, xử lý 1 triệu packet mỗi giây và tự scale tới 10 triệu, vượt mức đó thì packet bị drop; MTU tối đa 8500 byte — 2026-10-29, NAT gateway basics
• Mỗi NAT gateway được tạo trong một Availability Zone cụ thể và có dự phòng trong phạm vi zone đó; resource ở nhiều Availability Zone dùng chung một NAT gateway thì mất internet access khi Availability Zone của NAT gateway sập, nên AWS khuyến nghị tạo một NAT gateway mỗi Availability Zone và route theo zone — 2026-10-29, NAT gateway basics
• Regional NAT gateway (chọn ở Availability mode) tự mở rộng và thu lại theo các Availability Zone đang có network interface, không cần public subnet để chứa, dùng chung một NAT gateway ID cho mọi Availability Zone, hỗ trợ tới 32 IP address mỗi Availability Zone so với 8 của chế độ zonal, nhưng không hỗ trợ private NAT; việc mở rộng sang một Availability Zone mới có thể mất tới 60 phút — 2026-10-29, Regional NAT gateways for automatic multi-AZ expansion
• Mặc định 5 NAT gateway mỗi Availability Zone và 2 Elastic IP mỗi public NAT gateway, nâng được tới 8 — 2026-10-29, Amazon VPC quotas
• Route table chọn route theo longest prefix match, tức route khớp cụ thể nhất; khi hai route trùng destination thì static route (internet gateway, NAT gateway, network interface, instance ID, gateway VPC endpoint, transit gateway, VPC peering, Gateway Load Balancer endpoint) thắng propagated route từ virtual private gateway; route IPv4 và route IPv6 được xét độc lập — 2026-10-29, How route priority works
• Main route table tự sinh cùng VPC và điều khiển routing cho mọi subnet chưa associate tường minh với route table khác; local route là route mặc định cho giao tiếp trong VPC, và VPC có cả IPv4 lẫn IPv6 thì có một local route cho mỗi họ địa chỉ; một subnet chỉ associate được với một route table — 2026-10-29, Route table concepts
• Target của local route thay được sang một network interface và restore lại về local được; VPC có nhiều CIDR block thì route table có một local route cho mỗi CIDR block — 2026-10-29, Replace or restore the target for a local route
• Mặc định 200 route table mỗi VPC tính cả main route table, 500 route tự thêm mỗi route table (nâng được tới 1.000, đếm riêng IPv4 và IPv6) và 200 subnet mỗi VPC — 2026-10-29, Amazon VPC quotas
• Security group là stateful: request gửi ra từ instance thì response được vào bất kể inbound rule, và response cho inbound traffic đã được allow thì được ra bất kể outbound rule — 2026-10-29, Control traffic to your AWS resources using security groups
• Default security group có một inbound rule allow traffic đến từ mọi resource gán cùng security group đó, và outbound rule allow toàn bộ traffic IPv4 (0.0.0.0/0), cộng thêm rule cho IPv6 (::/0) nếu VPC có IPv6 CIDR block; rule của default security group sửa được nhưng bản thân nó không xóa được — 2026-10-29, Default security groups for your VPCs
• Mặc định 60 rule mỗi chiều cho một security group, đếm riêng inbound và outbound cũng như riêng IPv4 và IPv6; 5 security group mỗi network interface, nâng được tới 16, với ràng buộc số rule nhân số security group không vượt 1.000; 2.500 security group mỗi region — 2026-10-29, Amazon VPC quotas
• Security group không filter traffic tới hoặc từ Amazon DNS, DHCP, EC2 instance metadata, ECS task metadata endpoint, license activation của Windows instance, Amazon Time Sync Service và các IP address reserved mà default VPC router dùng; dùng security group không phát sinh phí — 2026-10-29, Control traffic to your AWS resources using security groups
• Network ACL là stateless: thông tin về traffic đã gửi hoặc nhận không được lưu, nên response cho traffic đã allow không tự động được allow — 2026-10-29, Control subnet traffic with network access control lists
• Mỗi rule của network ACL mang số từ 1 tới 32766 và có thể là allow hoặc deny; rule được xét từ số nhỏ nhất trở lên, khớp rule nào thì áp rule đó và dừng, không xét tiếp. Rule được xét khi traffic vào và ra khỏi subnet, không xét với traffic route trong cùng subnet — 2026-10-29, Control subnet traffic with network access control lists
• Mỗi subnet phải associate với một network ACL, không chỉ định thì tự gắn vào default network ACL; một network ACL associate được với nhiều subnet nhưng một subnet chỉ associate được với một network ACL tại một thời điểm — 2026-10-29, Control subnet traffic with network access control lists
• Default network ACL cho mọi traffic đi vào và ra: rule 100 allow mọi traffic IPv4 (và rule 101 cho IPv6 nếu VPC có IPv6 CIDR block), dưới đó là rule * deny mọi traffic; rule số * không xóa được — 2026-10-29, Default network ACL for a VPC
• Network ACL tự tạo chỉ có sẵn rule * deny ở cả hai chiều, nên deny toàn bộ traffic cho tới khi thêm rule; mỗi rule thêm vào phải có rule tương ứng ở chiều kia cho response traffic — 2026-10-29, Custom network ACLs for your VPC
• Dải ephemeral port do phía khởi tạo kết nối chọn: kernel Linux (gồm Amazon Linux) dùng 32768-61000, Windows Server 2008 trở lên dùng 49152-65535, Elastic Load Balancing, NAT gateway và AWS Lambda dùng 1024-65535; thực tế mở cả dải 1024-65535 rồi đặt rule deny ở số nhỏ hơn cho các port cần chặn — 2026-10-29, Custom network ACLs for your VPC
• Mặc định 20 rule mỗi network ACL, đếm riêng inbound và outbound, nâng được tới 40 mỗi chiều; 200 network ACL mỗi VPC; dùng network ACL không phát sinh phí — 2026-10-29, Amazon VPC quotas
• Network ACL không chặn được DNS request tới Route 53 Resolver (địa chỉ VPC cộng hai hoặc AmazonProvidedDNS) và không chặn được traffic tới Instance Metadata Service; muốn lọc DNS thì dùng Route 53 Resolver DNS Firewall — 2026-10-29, Control subnet traffic with network access control lists
• Free Tier cũ của EC2: 750 giờ mỗi tháng cho t2.micro hoặc t3.micro tùy region, trong 12 tháng, số giờ chia chung cho mọi region — 2026-10-29, Legacy AWS Free Tier FAQs
• Không xác minh được: phát biểu "local route không xóa được" dưới dạng một câu tường minh trong tài liệu AWS. Tài liệu chỉ nêu local route là route mặc định cho giao tiếp trong VPC và target của nó thay được rồi restore lại được; thân bài không dùng phát biểu này — 2026-10-29, Replace or restore the target for a local route
• Không xác minh được: danh sách cụ thể các region không có t2.micro (nơi loại được tính free tier là t3.micro). AWS nêu loại instance đủ điều kiện phụ thuộc region nhưng không công bố danh sách region — 2026-10-29, Legacy AWS Free Tier FAQs
• Không xác minh được: con số sáu Availability Zone của region us-east-1 trong phần thực hành. Số Availability Zone mỗi region đổi theo thời gian và theo từng account, nên con số này giữ theo nguồn gốc — 2026-10-29, Regions and Zones