2.2. Services - Networking: load balancer, kết nối hybrid, CDN và Route 53

Mục lục

• 1. Elastic Load Balancer
• 2. Thực hành: dựng Application Load Balancer cho hai web server
• 3. VPN: kết nối site-to-site qua IPsec
• 4. Direct Connect
• 5. VPC peering
• 6. Thực hành: dựng VPC peering giữa hai VPC
• 7. Transit Gateway
• 8. PrivateLink và VPC endpoint
• 9. CloudFront
• 10. Thực hành: CloudFront với S3 làm origin
• 11. Chạy code tại edge location
• 12. Global Accelerator
• 13. Route 53
• 14. Thực hành: đăng ký domain và tạo DNS record trong Route 53
• 15. Route 53 Application Recovery Controller

---

1. Elastic Load Balancer

Vấn đề cần giải

Hình dung một web application triển khai trên đúng một EC2 instance. Instance đó có IP là 1.1.1.1, và người dùng cuối truy cập application bằng cách gửi request tới chính IP address đó.

Điểm yếu lộ ra ngay: nếu EC2 instance sập thì application sập hoàn toàn với toàn bộ người dùng. Cách xử lý thông thường là triển khai application lên nhiều EC2 instance để có dự phòng, lý tưởng nhất là rải các instance ra các Availability Zone khác nhau để application chịu được sự cố mất một Availability Zone.

Giả sử có ba server cùng chạy application. Lúc này nảy ra vấn đề mới: mỗi server có một public IP khác nhau. Server thứ nhất là 3.3.3.3, server ban đầu là 1.1.1.1, server còn lại là 2.2.2.2. Người dùng phải gửi request tới IP address nào? 1.1.1.1, 2.2.2.2, hay 3.3.3.3?

Một phương án thô sơ là để người dùng gửi request tới 1.1.1.1, và khi server đó sập thì thông báo cho họ chuyển sang 2.2.2.2. Về mặt kỹ thuật làm được, nhưng đây là một thiết kế tệ. Lý do:

• Người dùng cuối, tức client, không bao giờ nên phải tự đổi qua đổi lại giữa các IP address. Họ cần đúng một IP address, hoặc đúng một domain, để gửi request tới.
• Họ không nên phải biết kiến trúc back-end của application, cũng không nên phải biết IP address của từng EC2 instance.
• Với một hệ thống phục vụ hàng trăm triệu người dùng, số EC2 instance có thể là năm mươi, thậm chí một trăm. Không thể trông đợi người dùng nhớ hết các IP address đó.

Load balancer là gì

Thay vì để người dùng cuối biết IP của mọi server, cách làm là đặt một thiết bị ngồi trước các EC2 instance, thiết bị đó có IP address riêng của nó. Người dùng cuối gửi request tới IP address của thiết bị này, và thiết bị sẽ load-balance các request đó xuống từng EC2 instance.

Thiết bị ngồi trước các EC2 instance như vậy gọi là load balancer. Lợi ích của cách làm này là IP duy nhất mà người dùng cuối cần biết là IP của load balancer, họ không bao giờ cần biết các IP còn lại. Load balancer là thiết bị duy nhất mà người dùng cuối giao tiếp với, và nó hoạt động gần như một lớp trừu tượng che toàn bộ các back-end server phía sau.

💡 Hình dung: load balancer giống quầy tiếp nhận duy nhất của một tòa nhà nhiều phòng ban. Khách tới chỉ cần biết địa chỉ tòa nhà và nói việc cần làm, quầy tiếp nhận tự biết chuyển sang phòng nào đang rảnh. Phòng ban có thể tăng từ ba lên năm mươi, có phòng tạm nghỉ để sửa chữa, nhưng địa chỉ mà khách cần nhớ không đổi.

Elastic Load Balancer là service load balancer của AWS. AWS cung cấp load balancer dựng sẵn để load-balance traffic tới rất nhiều loại resource khác nhau bên trong AWS.

Ba loại load balancer

AWS có tổng cộng ba loại load balancer:

Loại	Viết tắt thường gặp	Tầng hoạt động	Protocol
Classic Load Balancer	CLB	tầng cũ, không khuyến nghị dùng	hạn chế
Application Load Balancer	ALB	application layer, tức layer 7	HTTP, HTTPS, WebSockets
Network Load Balancer	NLB	layer 4	TCP, UDP

Classic Load Balancer

Đây là load balancer đầu tiên AWS giới thiệu. Như mọi thứ thuộc thế hệ đầu, nó thường không phải phương án tốt nhất về sau, và AWS đã có các bản triển khai tốt hơn. Vì vậy không khuyến nghị dùng Classic Load Balancer. Trừ trường hợp còn cấu hình hoặc application legacy đang chạy trên nó, một project mới sẽ không bao giờ dùng tới Classic Load Balancer.

Classic Load Balancer có nhiều feature bị hạn chế, và một trong các hạn chế đó liên quan tới SSL. Giả sử có một load balancer đang load-balance traffic cho hai application khác nhau (load balancer hoàn toàn làm được việc load-balance cho hai application khác nhau). App một cần một SSL certificate, app hai có thể cần một SSL certificate khác. Với Classic Load Balancer thì không làm được: nó chỉ hỗ trợ một SSL certificate cho mỗi Classic Load Balancer, nên không load-balance được qua nhiều app cùng lúc theo cách đó.

Lựa chọn đúng là dùng Application Load Balancer hoặc Network Load Balancer.

Application Load Balancer

Application Load Balancer phục vụ các application dạng web. Nó làm việc với HTTP, HTTPS và WebSockets. Điểm cần nhớ: nếu application dùng một protocol khác thì không dùng được Application Load Balancer, vì nó dành riêng cho web application.

Điều quan trọng nhất cần hiểu là Application Load Balancer hoạt động ở application layer. Nhờ vậy nó forward được dựa trên rất nhiều parameter khác nhau trong một HTTP request:

• Điều kiện theo URL path.
• Host domain của request.
• Các HTTP field khác nhau: method của HTTP request, query parameter, IP.

Ngoài ra nó hỗ trợ nhiều feature riêng của HTTP và HTTPS:

• Thực hiện HTTP redirect.
• Trả về custom HTTP response.
• Thực hiện health check ở mức application, tức kiểm tra sức khỏe của chính application đang chạy trên một EC2 instance hoặc resource khác. Nếu resource hoặc application đó không khỏe theo bất kỳ nghĩa nào, Application Load Balancer bảo đảm không forward request tới instance đang gặp sự cố đó.

Luồng traffic qua Application Load Balancer:

Khi client gửi request tới Application Load Balancer bằng bất kỳ protocol nào, HTTP hoặc HTTPS với TLS, điểm quan trọng cần hiểu là HTTP và HTTPS luôn được terminate trên Application Load Balancer. Hệ quả kéo theo:

1. Người dùng gửi request tới Application Load Balancer, và request được terminate tại đó.
2. Nếu dùng SSL thì traffic được encrypt tới đúng điểm này, rồi Application Load Balancer decrypt nó.
3. Vì HTTPS terminate trên Application Load Balancer, SSL certificate nằm trên Application Load Balancer.
4. Từ đó Application Load Balancer gửi request xuống EC2 instance bằng HTTP, nghĩa là đoạn từ load balancer tới EC2 instance là traffic không được encrypt.

Có thể lập luận rằng đoạn từ load balancer tới EC2 instance nằm trong AWS nên cũng khá an toàn. Nhưng nếu vẫn muốn encrypt đoạn đó, cách làm là dùng HTTPS để giao tiếp giữa load balancer và EC2 instance. Khi đó phải bảo đảm trên EC2 instance có một SSL certificate (chính certificate đó hoặc một certificate khác), và việc quản lý certificate đó thuộc trách nhiệm của người triển khai. Làm vậy thì traffic được encrypt thật.

Network Load Balancer

Khác với Application Load Balancer hoạt động ở mức layer 7, Network Load Balancer hoạt động ở mức layer 4. Nó làm việc dựa trên TCP và UDP, không hiểu HTTP, cũng không hiểu HTTPS.

Hệ quả: Network Load Balancer là lựa chọn cho mọi application không dựa trên HTTP hoặc HTTPS. Các đặc tính khác:

• Nhanh hơn hẳn Application Load Balancer, nên xử lý được nhiều traffic hơn, nhiều request hơn.
• Health check chỉ dựa trên ICMP và kết nối TCP.
• Network Load Balancer forward thẳng kết nối TCP xuống EC2 instance. Không có gì bị terminate trên Network Load Balancer như ở Application Load Balancer. TCP session hình thành giữa client và EC2 instance, còn load balancer chỉ đóng vai một người trung gian im lặng.

Luồng traffic qua Network Load Balancer:

1. Client khởi tạo một session TCP hoặc UDP.
2. Network Load Balancer forward session đó dựa trên chính session TCP hoặc UDP ấy. Client không hình thành session với Network Load Balancer, load balancer chỉ forward hoặc đóng vai proxy tới các EC2 instance.
3. Nếu muốn dùng HTTPS và muốn traffic được encrypt thì SSL certificate phải nằm trên các EC2 instance. Khi đó traffic được encrypt end to end, vì session là giữa client và EC2 instance, còn Network Load Balancer chỉ làm trung gian.

Load balancer node và cách chọn Availability Zone

Phần này nói về cách Elastic Load Balancer thực sự hoạt động và cách cấu hình nó.

Giả sử có một Virtual Private Cloud, trong VPC đó có hai Availability Zone là Availability Zone A và Availability Zone B, và mục tiêu là load-balance traffic tới resource ở cả hai Availability Zone.

Khi triển khai Elastic Load Balancer, wizard cấu hình sẽ hỏi muốn load-balance traffic tới những Availability Zone nào. Cách chỉ định là chọn các subnet cụ thể để triển khai load balancer lên đó. Điểm cần nhớ: có resource vật lý thật được triển khai khi dùng load balancer, nên phải chọn một subnet trong mỗi Availability Zone muốn route traffic tới. Nghĩa là phải tạo một subnet trong mỗi Availability Zone muốn load-balance traffic tới.

Khi các subnet đó được chọn, AWS triển khai cái gọi là load balancer node. Chính các node này chịu trách nhiệm load-balance traffic. Sau khi node được triển khai lên subnet đã chỉ định, nó load-balance được traffic tới bất kỳ subnet khác, hoặc cả chính subnet đó, bên trong cùng Availability Zone ấy.

Khi người dùng muốn gửi traffic tới một trong các EC2 instance, cơ chế là:

1. Elastic Load Balancer tạo ra một DNS record.
2. DNS record đó forward request đều nhau giữa tất cả load balancer node.
3. Từng load balancer node sau đó điều phối và load-balance tiếp xuống các EC2 instance tương ứng.

Hai điều phải ghi nhớ: load balancer node được triển khai vật lý lên subnet, và với mỗi Availability Zone muốn load-balance traffic tới thì phải triển khai một load balancer node lên một subnet trong Availability Zone đó.

Cross-zone load balancing

Để thấy rõ giá trị của feature này, trước hết xét trường hợp không có nó.

Giả sử một VPC có hai Availability Zone, load balancer được cấu hình với đúng một load balancer node trong mỗi Availability Zone. Khi người dùng gửi request tới load balancer, tức tới DNS entry:

1. Request được phân phối đều nhau giữa toàn bộ load balancer node: 50% xuống node trên, 50% xuống node dưới. Nếu có bốn node thì mỗi node 25%.
2. Sau đó từng load balancer node phân phối đều phần của nó cho các EC2 instance trong cùng Availability Zone.

Đặt số liệu vào ví dụ: Availability Zone dưới có hai EC2 instance, nên mỗi instance nhận 50% của 50%, tức 25% và 25% tổng lượng traffic. Availability Zone trên chỉ có một EC2 instance, nên instance đó nhận 100% của 50%, tức 50% tổng lượng traffic.

Kết quả là traffic không được phân phối đều giữa ba EC2 instance: 25%, 25% và 50%. Nguyên nhân gốc là mặc định load balancer node chỉ route traffic tới EC2 instance trong cùng Availability Zone, không đi xuyên Availability Zone được.

Đó chính là lý do feature cross-zone load balancing được tạo ra. Nó cho phép load balancer node load-balance traffic tới EC2 instance và resource ở các Availability Zone khác nhau. Load balancer node ở trên gửi được traffic xuống các EC2 instance phía dưới, và node phía dưới gửi được traffic lên các EC2 instance ở Availability Zone trên. Nhờ đó traffic được phân phối đều hơn trên toàn bộ EC2 instance.

Public load balancer và private load balancer

Load balancer triển khai được theo cách tương tự EC2 instance:

Loại	Triển khai lên	Phạm vi truy cập
Public load balancer	public subnet	người dùng từ internet truy cập được
Private load balancer	private subnet	chỉ truy cập được từ bên trong tổ chức, không mở ra internet

Cách làm không khác gì việc đặt một EC2 instance lên private subnet thay vì public subnet: người triển khai tự định nghĩa load balancer đó nên được cấu hình thế nào. Khái niệm public subnet và private subnet nằm ở Part 2.1: VPC, subnet, routing, gateway và firewall.

Khi có cả một private Elastic Load Balancer và một public Elastic Load Balancer, người dùng từ internet không nói chuyện được với private load balancer, vì bản chất nó là private và không truy cập được từ internet, còn cái public thì truy cập được.

Nguyên tắc chọn: resource là web server thì đặt sau một public load balancer để người dùng truy cập được; resource là thứ nội bộ thì bảo vệ bằng một private load balancer vì nó không nên mở ra internet.

Ví dụ kiến trúc nhiều lớp

Phần này đi qua một ví dụ đơn giản về cách dùng Elastic Load Balancer trong kiến trúc application tổng thể, với một load balancer cho từng stage hoặc từng layer, và dùng cả public lẫn private Elastic Load Balancer cho cùng một application.

Lớp API. Đây là lớp chịu trách nhiệm xử lý API request, gồm vài EC2 instance chạy API. Lớp này cần một load balancer để load-balance traffic tới các EC2 instance đó. Đây là một public Elastic Load Balancer, vì người dùng cần truy cập được, nó phải mở ra công chúng. Người dùng gửi request tới public load balancer, load balancer phân phối traffic xuống các EC2 instance.

Lớp database. Giả sử application có thêm một lớp nữa là database, gồm vài EC2 instance xử lý logic database. Lớp này cũng cần load-balance traffic tới các database instance, nên cấu hình một load balancer cho toàn bộ EC2 instance chạy database.

Lúc này lớp API, cụ thể là các EC2 instance trong lớp API, gửi được traffic request tới load balancer của lớp database, và load balancer đó load-balance tiếp tới toàn bộ EC2 instance trong lớp database. Nghĩa là một lớp gửi traffic tới load balancer của lớp kia, luôn giao tiếp thông qua load balancer để bảo đảm traffic luôn được cân bằng đều giữa các lớp của application.

Biến lớp database thành private. Thông thường người dùng cuối không nên truy cập được database hoặc lớp database, nên lớp này không dùng public load balancer mà chuyển thành private load balancer. Như vậy nó không mở ra công chúng, và chỉ lớp API nói chuyện được với lớp database.

Một điểm quan trọng: load balancer ở app tier và bất kỳ EC2 instance nào trên public subnet đều forward request tới resource trong private subnet mà không gặp vấn đề gì. Đi từ public subnet sang private subnet là chuyện bình thường, và nó mang lại thêm một lớp bảo mật, vì client không nói chuyện trực tiếp được với private subnet hay private load balancer đó.

Tổng kết thiết kế: lớp API để lộ ra vì nó vốn dành cho công chúng; lớp database được bảo vệ bằng cách đặt trong private subnet và nằm sau một private load balancer.

Listener

Khi cấu hình Elastic Load Balancer, thực chất chỉ có hai mảnh cấu hình cần tập trung: listener và target group.

Listener là một process kiểm tra các connection request bằng protocol và port đã cấu hình. Có nhiều loại listener để chọn:

• Listen cho các request có HTTP method cụ thể.
• Với Application Load Balancer, listen cho host name cụ thể trong request.
• Listen trên nhiều loại field khác nhau, tùy loại load balancer đang dùng.

Ví dụ: mọi request nhắm tới host tên app1.com thì cấu hình một listener, listener đó tìm các request khớp đúng cấu hình cho app một, rồi forward sang một target group.

Target group

Target group route request tới một hoặc nhiều target đã register, ví dụ EC2 instance, bằng protocol và port number được chỉ định. Nói gọn, target group chỉ là một tập hợp EC2 instance hoặc resource khác như ECS hay Lambda function mà traffic cần được load-balance tới.

Ví dụ bộ rule hoàn chỉnh trên một Application Load Balancer:

Rule khớp theo	Giá trị khớp	Forward tới target group chứa
host	app1.com	hai EC2 instance
host và path	app2.com/auth	container chạy trong ECS
host và path	app2.com với một route khác, ví dụ phần giỏ hàng	Lambda function

Ở rule thứ hai, điều kiện khớp là một path cụ thể: mọi request khớp app2.com/auth được forward tới một target group khác, và target group đó là các container chạy trong ECS. Rule thứ ba xử lý cùng host app2 nhưng ở một route khác, ví dụ rule thứ hai lo logic authentication còn rule thứ ba lo giỏ hàng, và nó được route tới một target group gồm Lambda function.

Target group chứa được EC2 instance, ECS, Lambda function, và gửi tới nhiều target group cùng lúc cũng được nếu cần.

Health check trên target group

Health check cấu hình được theo từng target group. Health check được thực hiện trên toàn bộ target đã register vào một target group được chỉ định trong một listener rule của load balancer.

Nhờ vậy, nếu một EC2 instance fail health check thì chỉ cần ngừng route traffic tới nó, traffic sẽ dồn sang các target còn lại trong cùng target group.

Chốt lại

• Elastic Load Balancer tự động phân phối traffic đi vào qua nhiều target ở nhiều Availability Zone.
• Nó phân phối traffic được tới EC2 instance, IP address, Lambda function.
• Có ba loại load balancer: classic, application và network.
• Classic Load Balancer đã lỗi thời và nên tránh.
• Application Load Balancer hoạt động ở application layer, nên forward dựa trên các header và field nhất định trong HTTP hoặc HTTPS request.
• Network Load Balancer forward được mọi loại traffic, kể cả traffic không phải HTTP và không phải HTTPS. Network Load Balancer nhanh hơn Application Load Balancer.
• HTTP và HTTPS luôn được terminate trên Application Load Balancer, không terminate trên Network Load Balancer.
• Cross-zone load balancing cho phép phân phối traffic đều nhau trên mọi instance ở mọi Availability Zone.
• Listener khớp traffic theo rule và xử lý connection request.
• Target group route request tới các EC2 instance đã register, theo protocol và port được chỉ định.

---

2. Thực hành: dựng Application Load Balancer cho hai web server

Mục tiêu của phần này là dựng một load balancer để load-balance network request tới một hoặc nhiều EC2 instance.

Môi trường chuẩn bị trước

Một số thứ đã được provision sẵn để không mất thời gian vào các thao tác thủ công lặp lại như tạo VPC:

• Hai instance: web server one và web server two, triển khai ở hai Availability Zone khác nhau là us-east-1a và us-east-1b.
• Hai instance này hiện là public server: VPC chứa chúng đã có internet gateway, và route đã được thiết lập sẵn nên chúng có internet access.
• Chúng chỉ là web server thuần, dùng NGINX với trang mặc định, nhưng thẻ h1 đã được sửa để trang server một ghi this is server one và trang server hai ghi this is server two. Nhờ vậy phân biệt được đang kết nối tới server nào.

Kiểm tra trước khi làm gì: lấy IP address của web server one, mở http://<ip-web-server-one> thì thấy trang web đơn giản ghi this is server one; làm tương tự với server hai thì thấy this is server two.

Về phần network, trang VPC cho thấy hai subnet đang chứa hai server:

Subnet	CIDR	Availability Zone	Chứa
web us-east-1a	10.0.201.0/24	us-east-1a	web server one
web us-east-1b	10.0.202.0/24	us-east-1b	web server two

Cả hai là public subnet, và chính điều đó cho hai server internet access.

Lý do cần load balancer trong tình huống này: hai server đang chạy trên hai IP khác nhau, còn người dùng cần đúng một address hoặc một DNS name thống nhất để gửi request, và địa chỉ đó phải route được tới cả hai server. Thêm vào đó, vì hai server chạy ở hai Availability Zone khác nhau nên có dự phòng: một Availability Zone sập thì web server ở Availability Zone kia gánh toàn bộ request. Thiết kế này tốt hơn việc chỉ có một server trong một Availability Zone.

Bước 1: tạo subnet riêng cho load balancer

Việc đầu tiên là tạo các subnet dành riêng cho load balancer, vì load balancer node sẽ được triển khai lên các subnet đó. Và vì cần load-balance traffic tới cả us-east-1a lẫn us-east-1b, cần một subnet trong mỗi Availability Zone đó để triển khai load balancer.

Trước khi tạo cần kiểm tra lại dải đang dùng để không overlap với hai subnet 201 và 202 đang có. Hai subnet mới dùng số 101 và 102:

Name	Availability Zone	IPv4 CIDR block
lb-us-east-1a	us-east-1a	10.0.101.0/24
lb-us-east-1b	us-east-1b	10.0.102.0/24

Sau bước này VPC có đúng bốn subnet: web us-east-1a, web us-east-1b cho server, và lb-us-east-1a, lb-us-east-1b cho load balancer.

Bước 2: quyết định public hay private

Câu hỏi tiếp theo là load balancer này nên public hay private. Ý nghĩa của public và private với load balancer giống hệt với EC2 instance: load balancer có nên truy cập được từ internet hay không.

Ở đây đang làm một website nên câu trả lời là public: nó phải truy cập được bởi toàn bộ người dùng cuối. Vì vậy lb-us-east-1a và lb-us-east-1b, hai subnet sẽ chứa load balancer node, phải là public subnet.

Hai subnet này vốn đã được cấu hình thành public subnet: mở route table của chúng ra thì thấy đã có default route trỏ về internet gateway. Nghĩa là load balancer triển khai lên đó sẽ truy cập được từ internet ngay.

Bước 3: tạo Application Load Balancer

Vào trang EC2, cuộn xuống mục Load Balancers, bấm Create load balancer. Phần này triển khai một Application Load Balancer, nhưng các bước gần như y hệt với Network Load Balancer.

Điền thông tin:

• Name: web load balancer.
• Loại: internet-facing.
• IP address type: chọn chỉ IPv4, hoặc dual stack để nhận cả một IPv4 address và một IPv6 address. Ở đây chọn IPv4.
• VPC: chọn VPC demo.
• Mappings: phải chọn ít nhất hai Availability Zone và một subnet cho mỗi zone. Load balancer route traffic tới target trong các Availability Zone này, và vì có server ở cả hai zone nên chọn cả hai. Với mỗi zone phải chỉ rõ subnet nào: chọn lb-us-east-1a và lb-us-east-1b, không chọn các subnet web. Điểm dễ sai chính là chỗ này: load balancer node phải được triển khai lên subnet dành riêng cho load balancer, các subnet web là nơi chứa web server.
• Security group: quyết định loại traffic nào được phép tới load balancer. Đây là load balancer cho web server nên dùng một security group đã tạo trước, chỉ cho phép port 80 và port 443.

Bước 4: listener và routing

Tới mục Listeners and routing. Listener nói cho load balancer biết nó cần listen request trên port nào, và câu hỏi thực tế là người dùng sẽ gửi traffic tới port nào.

Đây là web application nên người dùng gửi tới port 80 cho HTTP và port 443 cho HTTPS. Console để sẵn mặc định là port 80. Nếu muốn load balancer listen trên port 443 hoặc port khác thì sửa ở đây: Application Load Balancer chỉ làm HTTP và HTTPS, nhưng port thì đổi được về mặt kỹ thuật, ví dụ listen trên port 300 cũng được. Ở đây giữ nguyên port HTTP mặc định, luôn là port 80.

Phần còn lại của listener là: khi nhận một HTTP request trên port 80 thì gửi nó đi đâu. Vì đây là load balancer, đích đến là các back-end web server, và cơ chế để làm việc đó là target group. Target group chỉ là một tập resource mà các request này cần được forward tới.

Bước 5: tạo target group

Bấm tạo target group, console mở một tab mới.

• Target type: chọn load-balance tới instance. Các lựa chọn khác là IP address, Lambda function, hoặc load balancer khác.
• Target group name: target group web.
• Port: câu hỏi ở đây khác với lúc cấu hình listener. Lúc trước là load balancer listen trên port nào, còn lúc này là web server đang listen trên port nào khi load balancer forward request xuống. Web server đang listen trên port HTTP mặc định, tức port 80. Đó cũng chính là lý do gõ http://<ip> trong browser mà không cần ghi port: port 80 là ngầm định.
• Protocol: HTTP. Và chỉ định VPC tương ứng.
• Health checks: cấu hình để định kỳ gửi health check HTTP hoặc HTTPS tới server. Phải cho nó một path cụ thể mà server đang listen để dùng làm phép thử. Mặc định là root path, tức dấu /. Nếu có một route dành riêng cho health check thì điền ví dụ health vào đây, và load balancer sẽ gửi HTTP request tới đúng path đó. Nếu không nhận được response hợp lệ, nó coi server đang chết và thực hiện biện pháp phòng ngừa cần thiết là không forward traffic tới node đó. Môi trường này không có route health riêng nên giữ nguyên root path. Mục advanced health check dành cho cấu hình sâu hơn.

Bấm Next để tới bước Register targets:

• Chọn hai EC2 instance muốn đưa vào target group này.
• Ports for the selected instances, tức port dùng để route traffic: đã là port 80, đúng nhu cầu.
• Hai server hiện ở trạng thái pending phía dưới. Target group sẽ register hai server đó, và vì server listen trên port 80 nên khi load balancer gửi request tới target group này, nó biết phải gửi trên port 80.

Bấm tạo target group.

Bước 6: gắn target group vào load balancer rồi tạo

Quay lại tab cấu hình Application Load Balancer, bấm refresh rồi chọn target group web.

Ở đây thêm được nhiều listener nữa nếu muốn, ví dụ một listener cho HTTPS rồi forward về cùng bộ server. Ví dụ này giữ đơn giản nên không thêm, nhưng cần thấy rằng về mặt kỹ thuật một Application Load Balancer load-balance được qua nhiều bộ server khác nhau, nhiều microservice khác nhau, với rất nhiều rule listen trên các port khác nhau và forward tương ứng theo các rule đó. Ở đây chỉ listen trên port 80 nên xóa listener dư rồi bấm Create load balancer.

Việc provision load balancer mất vài phút.

Bước 7: kiểm tra load balancing

Khi load balancer chuyển sang trạng thái active, mở nó ra. Thứ cần tập trung là DNS name: đây là địa chỉ người dùng gửi request tới để request chạm vào load balancer.

Copy DNS name đó, mở một tab mới và gửi một HTTP request tới đó. Kết quả:

• Lần đầu: request được forward tới server một, trang ghi this is server one.
• Bấm refresh: lần này là server hai.
• Refresh tiếp: một, hai, một, hai, một, hai.

Load balancer đang load-balance đúng trên toàn bộ web server.

Ghi chú về bảo mật: đừng để web server public

Có một điểm cần chỉ rõ sau khi demo chạy được. Vào danh sách EC2 instance, lọc theo trạng thái Running, sẽ thấy hai web server. Mở một trong hai ra thì thấy nó vẫn có public IP address. Nghĩa là copy IP đó và truy cập trực tiếp thì vẫn vào được server, bỏ qua hoàn toàn load balancer.

Trong một application thật thì không nên như vậy: nếu người dùng đáng lẽ phải đi qua load balancer thì đừng bao giờ để họ truy cập trực tiếp vào back-end server. Có hai cách xử lý:

1. Dùng security group với firewall rule chỉ cho phép traffic đến từ load balancer đi tới server.
2. Cách được khuyến nghị hơn: thay vì để các server này public, đặt chúng lên private subnet. Web server không cần nằm trên public subnet, vì người dùng không cần truy cập trực tiếp vào web server. Người dùng luôn đi qua load balancer, nên load balancer cần nằm trên public subnet, còn web server mà nó load-balance tới hoàn toàn nằm được trên private subnet.

Load balancer tồn tại trên public subnet, nhận request, rồi forward xuống server trên private subnet. Cách này cho thêm một lớp bảo mật vì không ai còn truy cập trực tiếp được vào back-end web server, và nó nâng mức an toàn chung của thiết kế application trên AWS.

Điểm chốt của ghi chú này: không bắt buộc phải đặt web server lên public subnet khi load balancer đã là public.

---

3. VPN: kết nối site-to-site qua IPsec

Vấn đề cần giải

Giả sử có một VPC, trong đó có một private subnet với một số resource đã triển khai. Một nhu cầu thực tế là phải truy cập được các resource đó từ một data center on-premises: các thiết bị trong data center riêng cần nói chuyện được với private subnet, hoặc với resource bên trong private subnet.

Khó khăn là nó private: không truy cập được qua internet, các resource đó không có public IP. Vậy cần một thứ gì đó cho phép thiết lập giao tiếp an toàn và bảo mật giữa mạng on-premises và các private resource trong cloud.

Đó là lúc VPN vào việc. Triển khai một VPN để kết nối mạng on-premises với VPC, nhờ đó dữ liệu được gửi qua lại an toàn giữa hai bên. Kết nối đi qua một IPsec tunnel, và tunnel này encrypt traffic: khi dữ liệu đi qua internet thì không ai khác đọc được dữ liệu đang truyền.

Hai đầu của một VPN: VPN gateway và customer gateway

Giả sử VPC có CIDR block 10.0.0.0/16, bên trong có một số private subnet và resource.

Việc đầu tiên là triển khai một VPN gateway. VPN gateway terminate VPN ở phía AWS, nghĩa là IPsec tunnel kết thúc trên thiết bị VPN này.

Phía on-premises có CIDR block riêng, hoặc một số subnet riêng, nơi mọi thiết bị trong mạng on-prem lấy IP address. Trong ví dụ này dải đó là 192.168.0.0/16. Ở mạng on-premises phải triển khai một customer gateway, thiết bị này terminate VPN ở phía on-premises, tức phía khách hàng.

Hai đầu đều cần public IP address:

Thiết bị	Nằm ở phía	Public IP trong ví dụ
customer gateway	on-premises, phía khách hàng	1.1.1.1
VPN gateway (virtual private gateway)	AWS	2.2.2.2

Nhờ hai public IP đó, một IPsec tunnel được thiết lập qua internet giữa 1.1.1.1 trên customer gateway và 2.2.2.2 trên VPN gateway.

Các điểm cần nhớ:

• VPN gateway nằm ở phía AWS, customer gateway nằm ở phía on-premises.
• IPsec tunnel đi qua internet thường, chính internet dùng hằng ngày, chứ không phải một đường riêng nào khác.

💡 Hình dung: IPsec tunnel giống một kiện hàng niêm phong gửi qua đường bưu chính công cộng. Kiện hàng vẫn đi chung xe với mọi thứ khác, ai cũng thấy nó đang di chuyển, nhưng chỉ hai đầu có chìa khóa niêm phong mới mở ra đọc được bên trong.

Routing: static và dynamic

Câu hỏi tiếp theo là xử lý routing ra sao, không chỉ ở phía AWS mà cả phía on-premises.

Bối cảnh: có virtual private gateway, có customer gateway, có một VPN connection giữa hai cái. Phía AWS là CIDR block 10.0.0.0/16, phía on-premises là 192.168.0.0/16. Vấn đề cần giải: làm sao để resource biết rằng khi gửi tới một IP address nào đó trong dải 192.168.0.0/16 thì phải gửi về VPN gateway, qua IPsec tunnel, tới customer gateway ở đầu bên kia.

Có hai phương án:

Phương án	Cách làm
static	Tự định nghĩa thủ công một route trong AWS routing table: để tới 192.168.0.0/16 thì trỏ về VPN gateway. Việc này thiết lập kết nối giữa hai site.
dynamic	Cấu hình một dynamic routing protocol để trao đổi route giữa VPN gateway và customer gateway. Customer gateway gửi các route thuộc dải địa chỉ của nó sang VPN gateway một cách động bằng BGP, nhờ đó VPN gateway biết cách tới dải địa chỉ đó.

Nói gọn: static là tự định nghĩa một static route trong AWS route table, dynamic là cấu hình một protocol để trao đổi route giữa customer gateway và VPN gateway.

Pricing

Chi phí chạy một VPN gateway gồm hai phần:

• Phí cho mỗi available VPN connection-hour: mỗi giờ VPN còn chạy là bị tính phí.
• Phí cho data được transfer out từ EC2 ra internet, tức traffic đi ra từ AWS hoặc từ gateway ra ngoài.

Đây là mô thức chung của AWS: tính phí traffic đi ra, không tính phí traffic đi vào.

Giới hạn của virtual private gateway

Hạng mục	Giới hạn
Bandwidth tối đa mỗi VPN tunnel	1,25 Gbps
Số packet tối đa mỗi giây	140.000 packet mỗi giây
MTU	1.466 byte

Nếu các mức trên chưa đủ dùng thì cách nâng là dùng ECMP trên nhiều VPN tunnel để tăng bandwidth tổng. Không bị giới hạn ở một tunnel duy nhất, tạo thêm tunnel là được.

Chốt lại

• VPN kết nối VPC với data center on-premises.
• Virtual private gateway là endpoint phía Amazon của VPN, nó terminate VPN connection ở phía AWS, và nó được attach vào một VPC.
• Customer gateway là phía on-premises, nó terminate VPN connection ở phía on-prem.
• Khi VPN tunnel, tức IPsec tunnel, được hình thành thì dữ liệu đi qua internet. Dữ liệu được encrypt nên an toàn, nhưng vẫn phải nhớ nó đi qua internet.
• Mạng on-premises khai được static trong route table, hoặc trao đổi dynamic bằng một routing protocol như BGP.
• Tính phí theo giờ cho mỗi VPN connection, cộng với egress data đi ra.
• Bandwidth tối đa là 1,25 Gbps.

---

4. Direct Connect

Direct Connect là gì

Direct Connect là một kết nối vật lý tới AWS. Cách hiểu đơn giản nhất là coi nó như một phương án thay thế cho VPN.

Phần trên đã cho thấy VPN hình thành IPsec tunnel qua internet. Nhưng nếu không muốn đi qua internet thì sao: internet không ổn định, không đáng tin cậy, và không cho tốc độ nhanh. Vì vậy AWS tạo ra service Direct Connect, cho phép kết nối vật lý tới resource của AWS để có một kết nối trực tiếp.

Đường kết nối có thể là link 1 gigabit, 10 gigabit, hoặc 100 gigabit đi thẳng vào AWS, cho một kết nối tốc độ cao, đáng tin cậy và bảo mật. Điểm cần nhấn mạnh nhất: nó là kết nối vật lý, không đi qua internet.

Ba thành phần của Direct Connect

Thành phần 1: mạng on-premises. Đây là data center vật lý, hoặc văn phòng công ty, hoặc mạng on-prem. Ở đó có edge router hoặc firewall. Router này có thể là chính router đang dùng cho kết nối internet, hoặc một router dành riêng cho Direct Connect. Việc chọn cách nào tùy tổ chức.

Thành phần 2: Direct Connect location. Đây chỉ là một địa điểm nơi có thể kết nối tới một router của Amazon. Địa điểm này thường không do Amazon sở hữu: nó thường là một data center khu vực mà AWS thuê một phần diện tích hoặc một rack để đặt router của họ, và khách hàng kết nối tới các router đó. Nói lại cho rõ: Direct Connect location không nhất thiết là data center của AWS.

Trong Direct Connect location có hai router:

Router	Thuộc về
customer router	khách hàng tự cài đặt tại location đó
AWS Direct Connect router	AWS sở hữu

Khi mua một Direct Connect, thứ thực sự được mua là một port trên router của AWS. Việc đặt một cross-connect nghĩa là đặt một kết nối giữa router của khách hàng và router của AWS.

Thành phần 3: phía AWS. Từ router của AWS, đường đi tiếp vào AWS, nơi có thể nói chuyện với private resource hoặc với public service như S3.

Hai kiểu đích đến

Cách kết nối tới hai loại đích này khác nhau:

• Tới private resource trong private subnet: thiết lập một Virtual Private Gateway, rồi thiết lập kết nối giữa cross-connect, router của AWS và Virtual Private Gateway đó. Nhờ vậy nói chuyện được với private subnet.
• Tới public service: đi từ router của AWS tới các public service.

Chuỗi đường đi đầy đủ từ mạng on-premises vào AWS cloud: mạng on-premises, tới customer gateway, customer gateway có kết nối tới customer router trong DX location, trong DX location có cross-connect tới router của AWS, rồi từ router của AWS vào AWS.

Vì sao nhanh hơn VPN

Ý tưởng cốt lõi của Direct Connect: thay vì đi qua internet như VPN, đây là kết nối trực tiếp tới một router của AWS, nhờ đó truy cập hạ tầng AWS ở tốc độ cao hơn, tốc độ ổn định hơn và độ trễ thấp hơn.

Lý do đạt được điều đó: đoạn từ router của AWS tới Virtual Private Gateway, hoặc đi trực tiếp tới các public service của AWS, chạy trên AWS backbone. Đây là mạng của AWS, do AWS vận hành, không đi qua internet mà đi qua hạ tầng của họ.

Pricing

Hai loại phí:

• Port hour: số giờ sử dụng một port.
• Outbound data transfer: dữ liệu đi ra khỏi AWS.

Nhắc lại mô thức chung: outbound data transfer đi ra khỏi AWS luôn bị tính phí.

Chốt lại

• Direct Connect liên kết trực tiếp on-premises với AWS, không routing qua internet như VPN.
• Nó cho throughput lớn hơn và kết nối bảo mật, ổn định hơn so với VPN chạy qua internet.
• Tính phí theo port hour và outbound data transfer.

---

5. VPC peering

Hành vi mặc định của VPC

Trước khi vào VPC peering cần nhắc lại hành vi mặc định của VPC. Mặc định, resource trong một VPC và resource trong một VPC khác không nói chuyện được với nhau, vì VPC đóng vai một network boundary. Chi tiết về tính cô lập này nằm ở Part 2.1: VPC, subnet, routing, gateway và firewall.

Vậy khi cần chúng nói chuyện được với nhau thì làm thế nào. Đó là lúc VPC peering vào việc.

VPC peering là gì

Mục đích và ý tưởng của VPC peering: nó đóng vai một network connection giữa hai VPC, và nó xử lý việc route traffic giữa hai VPC đó. Nhờ vậy vượt qua được giới hạn không giao tiếp được giữa các VPC khác nhau.

Sau khi thiết lập một peering, giữa hai VPC có một network connection, và instance ở cả hai VPC giao tiếp được với nhau như thể chúng nằm trong cùng một network.

Phạm vi linh hoạt của VPC peering:

• Peering giữa các VPC trong cùng một region.
• Peering giữa các VPC ở các region khác nhau.
• Peering giữa các VPC thuộc các AWS account khác nhau: một VPC ở account này peer được với một VPC ở account khác.

Pricing

Hạng mục	Chi phí
Bản thân peering	không phát sinh chi phí, không phụ phí nào
Data transfer qua VPC peering trong cùng một Availability Zone	miễn phí
Data transfer qua VPC peering giữa các Availability Zone	bị tính phí

Cách cấu hình một VPC peering

Giả sử VPC 1 có CIDR block 10.1.0.0/16 và VPC 2 có CIDR block 10.2.0.0/16.

Bước 1: gửi và chấp nhận peering request. Một trong hai VPC gửi request tới VPC kia để khởi tạo peering. Chủ sở hữu VPC 1, tức người sở hữu AWS account của VPC đó, gửi một peering request tới chủ sở hữu VPC 2, vì peering làm được xuyên AWS account. Nếu cả hai cùng một account thì về bản chất đang tự gửi request cho chính mình.

Sau khi request được gửi, chủ sở hữu VPC 2 phải accept peering request đó. Trong console có hẳn một nút cho việc này: một request hiện lên kèm thông báo nhỏ, và phải bấm accept. Việc đó tạo ra peering giữa hai VPC.

Bước 2: xử lý routing. Sau khi peering đã được khởi tạo, được accept và đã hoạt động, việc tiếp theo là routing, vì lúc này VPC 1 vẫn chưa biết cách tới VPC 2, chính xác hơn là chưa biết cách tới CIDR block của VPC 2.

Nhìn vào routing table của VPC 1: cần một route trả lời câu hỏi làm sao tới 10.2.0.0/16. Vì vậy phải tạo một route trong route table:

Destination	Target
10.2.0.0/16	peering connection tương ứng

Mỗi peering có một unique identifier dùng được làm target. Nhờ route này, mọi traffic từ bất kỳ instance nào trong VPC 1 nhắm tới VPC 2 sẽ khớp route này và biết phải gửi qua peering.

Và phải làm đúng như vậy theo chiều ngược lại: trong route table của VPC 2, thêm một route với destination 10.1.0.0/16 và target là peering connection. Sau đó instance ở hai VPC khác nhau giao tiếp tự do được với nhau.

VPC peering không transitive

Giả sử có ba VPC: VPC 1, VPC 2, VPC 3. Có một peering giữa VPC 1 và VPC 2, và một peering giữa VPC 2 và VPC 3.

Suy luận trực giác sẽ là VPC 1 nói chuyện được với VPC 3 thông qua VPC 2. Suy luận đó sai. Việc này không làm được, và nó có tên gọi riêng là transitive peering: VPC 1 dùng VPC 2 làm một transit VPC để nói chuyện với VPC 3. AWS không hỗ trợ transitive peering.

Vì vậy nếu VPC 1 và VPC 3 cần nói chuyện được với nhau thì phải thiết lập một peering riêng giữa chính hai VPC đó.

Chốt lại

• VPC peering là network connection giữa hai VPC, nó route traffic giữa hai VPC đó.
• VPC peering kết nối được VPC trong cùng region, VPC ở các region khác nhau, và VPC thuộc các AWS account khác nhau.
• Không có phí cho việc tạo một VPC peering.
• Data transfer đi xuyên Availability Zone thì bị tính phí.
• VPC peering không transitive.

---

6. Thực hành: dựng VPC peering giữa hai VPC

Mục tiêu phần này là thiết lập một VPC peering để resource trong một VPC giao tiếp được với resource trong một VPC khác.

Môi trường chuẩn bị trước

Hai VPC đã được cấu hình sẵn:

VPC	CIDR block	EC2 instance bên trong	Private IP
VPC-A	10.1.0.0/16	server one	10.1.1.13
VPC-B	10.2.0.0/16	server two	10.2.1.139

Cả hai server đều đã có đường kết nối vào. Ngoài ra toàn bộ security group và NACL đã được mở allow all traffic, nên nếu kết nối thất bại thì nguyên nhân chắc chắn không nằm ở firewall.

Bước 1: xác nhận mặc định không thông nhau

Đăng nhập vào server one rồi ping private IP address của server two:

ping 10.2.1.139
# thất bại, không có phản hồi

Kết quả thất bại đúng như dự kiến, vì mặc định các VPC không giao tiếp được với nhau: chúng là một networking boundary, tồn tại để cô lập resource. Để nói chuyện được với server đó cần định nghĩa một VPC peering. Nhắc lại lần nữa: nguyên nhân thất bại lúc này chỉ là chưa có VPC peering, vì security group và NACL đã allow hết.

Bước 2: tạo peering connection

Vào mục Peering Connections, bấm Create Peering Connection:

• Name: VPC-A to VPC-B, đặt vậy cho dễ nhận ra.
• Local VPC to peer with: chọn VPC đứng vai requester. Nhắc lại cơ chế: một VPC phải request peering tới VPC kia. Chọn bên nào cũng được, ở đây để VPC-A request tới VPC-B, làm ngược lại cũng cho kết quả y hệt.
• Select another VPC to peer with: chỉ định peer với một VPC trong cùng account hay trong account của người khác. Đây là nơi thể hiện việc peering xuyên AWS account làm được. Ở đây chọn peering trong cùng account vì cả hai VPC cùng một account.
• Region: chọn same Region hoặc cross-Region. Cả hai VPC ở us-east-1 nên chọn this Region.
• Acceptor VPC: VPC-B, đây là VPC phải accept request.

Console hiển thị CIDR block của hai bên để đối chiếu. Một điểm quan trọng: CIDR block của hai VPC buộc phải khác nhau mới peer được, vì routing phải thiết lập được. Đây chính là một lý do để luôn bảo đảm CIDR block của các VPC không overlap, kể cả khi khá tự tin rằng sẽ không bao giờ cần kết nối chúng lại: đặt dải khác nhau không mất gì.

Bấm Create Peering Connection.

Bước 3: accept request

Về lại Peering Connections, peering connection hiện ra với trạng thái pending acceptance: VPC-A đã gửi request, giờ chủ sở hữu của VPC-B phải accept nó.

Vì đây là peering trong cùng account nên cùng một người vừa request vừa accept. Nghe có vẻ vô nghĩa nhưng cơ chế là như vậy, vì cần giữ được khả năng gửi request peering tới một VPC thuộc account của người khác.

Chọn peering connection, mở Actions, có hai lựa chọn là reject request và accept request. Chọn accept request. Peering giữa VPC-A và VPC-B đã thành công.

Bước 4: vẫn chưa thông, vì thiếu route

Chạy lại lệnh ping từ server one:

ping 10.2.1.139
# vẫn thất bại

Vì sao vẫn thất bại khi đã có peering? Vì chưa có route cho các VPC: VPC-A không biết cách tới VPC-B. Có peering nhưng không biết route sang VPC-B ra sao.

Mở route table của VPC-A ra để thấy rõ. Toàn bộ subnet và các EC2 instance nằm trên các subnet đó đều dùng route table này. Các route hiện có:

Destination	Target	Ghi chú
10.1.0.0/16	local	local route của chính VPC này
0.0.0.0/0	internet gateway	default route, không liên quan tới phần này

Không có route nào tới 10.2.0.0/16, nên nó hoàn toàn không biết đường. Kết luận: dù đã thiết lập peering, vẫn phải thiết lập các route cần thiết để tới VPC kia.

Bước 5: thêm route ở cả hai phía

Vào route table của VPC-A, tab Routes, thêm route:

Destination	Target
10.2.0.0/16	peering connection vừa tạo

Giờ VPC-A biết cách tới VPC-B. Nhưng mở route table của VPC-B ra (chú ý chọn đúng route table của VPC, không phải chọn chính VPC) thì thấy VPC-B không biết cách tới VPC-A. Vậy nên phải đặt route ở cả hai phía. Thêm vào route table của VPC-B:

Destination	Target
10.1.0.0/16	peering VPC-A to VPC-B

Bấm Save changes.

Bước 6: kiểm tra lại

Chạy lại lệnh ping từ server one:

ping 10.2.1.139
# phản hồi thành công

Hai server trên hai VPC khác nhau đã có kết nối, và toàn bộ đường đi qua VPC peering. Nghĩa là traffic không đi qua internet, nó chạy hoàn toàn trong hạ tầng AWS giữa hai VPC.

Toàn bộ việc cần làm để dựng một VPC peering gọn lại thành ba việc: gửi request từ một VPC, accept request, và thiết lập đủ các route để hai VPC biết đường route tới nhau.

---

7. Transit Gateway

Vấn đề cần giải: full mesh của VPC peering

Các phần trên đã cho thấy mặc định VPC không nói chuyện được với nhau, nên resource ở VPC 1 không nói chuyện được với resource ở VPC 2. Muốn chúng nói chuyện được thì phải thiết lập một VPC peering connection để xử lý routing giữa hai VPC.

Giả sử tiếp: lập một peering giữa VPC 2 và VPC 3 thì hai VPC đó cũng giao tiếp được. Lúc này VPC 1 nói chuyện được với VPC 2, VPC 3 nói chuyện được với VPC 2. Nhưng VPC 1 không nói chuyện được với VPC 3, vì transitive routing không được hỗ trợ: VPC 1 không đi qua VPC 2 rồi sang VPC 3 được, vì khi đó VPC 2 là một transitive VPC. Để VPC 1 nói chuyện được với VPC 3 thì phải có peering trực tiếp giữa hai cái.

Nâng lên bốn VPC: để cả bốn VPC giao tiếp được với nhau thì cần một full mesh các peering, nghĩa là mọi VPC phải peer với mọi VPC còn lại. Hệ quả rõ ràng: số VPC càng tăng thì số VPC peering tăng không giới hạn, và việc quản trị ngày càng khó.

Thêm một lớp phức tạp nữa: nếu có môi trường on-premises và cần giao tiếp từ on-premises tới cả bốn VPC thì phải thiết lập một VPN connection từ customer gateway tới từng VPC, tức bốn VPN connection. Vậy không chỉ các peering mà cả số VPN cũng tăng theo số VPC.

Transit Gateway là gì

Để giải các vấn đề đó, service Transit Gateway được tạo ra. Ý tưởng chính: tránh phải tạo và duy trì một full mesh giữa các VPC.

Cách hoạt động: triển khai một Transit Gateway, rồi bốn VPC chỉ cần peer hoặc kết nối với Transit Gateway, không còn phải peer với nhau nữa. Transit Gateway đóng vai một router route traffic giữa các VPC. Lúc này chỉ còn phải quản một kết nối tới Transit Gateway, trong khi mọi VPC vẫn giao tiếp được với nhau.

Kết quả là có được một full mesh về mặt giao tiếp mà không phải tạo một full mesh các VPC peering, chỉ bằng một kết nối duy nhất từ mỗi VPC tới Transit Gateway. Nói cách khác, Transit Gateway đóng vai một thiết bị routing transitive để route traffic giữa các VPC.

💡 Hình dung: VPC peering giống việc mỗi cặp nhà trong khu dân cư tự xây một con đường riêng nối thẳng sang nhau: bốn nhà đã cần sáu con đường. Transit Gateway giống việc xây một vòng xoay chung ở giữa, mỗi nhà chỉ cần một con đường ra vòng xoay là đi đâu cũng được.

Yêu cầu về subnet

Để cấu hình Transit Gateway, phải chỉ định một subnet trong mỗi Availability Zone của một VPC để Transit Gateway dùng cho việc route traffic.

Điểm này quan trọng: nếu trong một VPC đang dùng ba Availability Zone khác nhau, gọi là Availability Zone một, hai, ba, và muốn Transit Gateway thực sự route cho các subnet thuộc ba Availability Zone đó, thì phải tạo một subnet riêng trong từng Availability Zone đó để Transit Gateway dùng cho mục đích kết nối. Nói ngắn: với mỗi Availability Zone cần route traffic, phải tạo thêm một subnet cho Transit Gateway hoạt động trong đó.

Kết nối on-premises qua Transit Gateway

Điểm hay của Transit Gateway là ở tình huống hybrid. Trước đây, để nối môi trường on-premises tới cả bốn VPC thì cần một VPN connection từ customer gateway tới từng VPC. Với Transit Gateway thì terminate VPN connection trên chính Transit Gateway, nên chỉ cần một kết nối, rồi Transit Gateway xử lý routing tới mọi VPC đang nối vào nó. Số VPN connection giảm từ bốn xuống một.

Ngoài VPN, cũng dùng được Direct Connect để nối môi trường on-premises tới AWS Transit Gateway. Nghĩa là Transit Gateway hỗ trợ cả VPN lẫn Direct Connect.

Peering giữa các Transit Gateway

Transit Gateway peer được với Transit Gateway khác. Hệ quả:

• Muốn có kết nối giữa các region khác nhau thì peer Transit Gateway ở region này với Transit Gateway ở region kia.
• Transit Gateway cũng peer được với Transit Gateway ở các AWS account khác nhau.

Chốt lại

• Transit Gateway đơn giản hóa networking giữa các VPC và với môi trường on-premises.
• Nó cho phép transitive routing.
• Phải chỉ định một subnet trong mỗi Availability Zone để Transit Gateway dùng cho việc route traffic.
• Nó peer được với Transit Gateway khác ở region khác, và ở AWS account khác.

---

8. PrivateLink và VPC endpoint

Vấn đề cần giải

Giả sử một EC2 instance được triển khai vào một private subnet. Nếu instance này cần truy cập một S3 bucket thì phải cho nó internet access: tạo một internet gateway hoặc một NAT gateway để nó tới được URL của S3 bucket. Hai loại gateway này được nói kỹ ở Part 2.1: VPC, subnet, routing, gateway và firewall.

Vấn đề của cách làm đó: để cho EC2 instance truy cập được một AWS service như S3, vốn là một trong các public service của AWS, lại phải cấp cho nó full internet access. Việc này sinh ra cả một loạt vấn đề khác:

• EC2 instance bị phơi ra internet, nên dễ bị tấn công hơn.
• Có thể instance này vốn không cần internet access, nhu cầu thật chỉ là truy cập một S3 bucket.

Cần một cách đơn giản hơn và an toàn hơn để cấp quyền truy cập các public service mà AWS cung cấp, ví dụ S3, cho các resource nội bộ, mà không phải cấp cho chúng internet access.

PrivateLink là gì

PrivateLink được tạo ra để giải đúng vấn đề đó. Cách nó hoạt động: PrivateLink cho VPC quyền truy cập trực tiếp tới các public service như S3, nên traffic không cần route qua internet.

Cách này an toàn hơn vì không phải phơi toàn bộ resource nội bộ ra internet, mà vẫn có kết nối trực tiếp tới các public service của AWS.

Kết nối tới service trong VPC khác

Ngoài trường hợp trên, PrivateLink còn cho phép resource trong VPC kết nối tới service nằm ở VPC khác bằng private IP address. Các service đó sẽ trông như thể đang được kết nối trực tiếp vào VPC của mình.

Ứng dụng thực tế: nếu một công ty thứ ba đang cung cấp một service và cần truy cập service đó, về mặt kỹ thuật có thể tạo một PrivateLink tới VPC nơi service đó chạy, để có quyền truy cập trực tiếp như thể service được host ngay trong VPC của mình. Nhờ cách này, mọi service của bên thứ ba đều trông như đã nằm sẵn trong VPC của mình.

Chốt lại

• PrivateLink cho phép resource trong VPC kết nối tới service như thể chúng nằm trong cùng một VPC.
• Nó được dùng để kết nối tới các AWS service như S3 và CloudWatch, hoặc tới các VPC khác bên trong AWS.
• VPC endpoint là thứ tạo điều kiện cho giao tiếp giữa instance trong VPC và các service đó.

---

9. CloudFront

Vấn đề cần giải: latency theo khoảng cách

Xét một web server được triển khai vào một region ở Bắc Mỹ. Người dùng muốn nói chuyện với web server này thì gửi một request và nhận một response.

Vấn đề: nếu người dùng ở tận phía bên kia địa cầu, ví dụ ở Ấn Độ, thì request của họ phải đi xuyên nửa vòng trái đất tới web server ở Bắc Mỹ, và kết quả là latency rất cao.

Edge location

Để xử lý vấn đề latency cao với người dùng ở xa nơi triển khai server, AWS cung cấp edge location.

Web server vẫn triển khai vào một region như bình thường. Ngoài ra AWS có các edge location nhỏ hơn rải khắp toàn cầu. Số edge location nhiều hơn số region, vì edge location không phải là region đầy đủ: chúng là các site rất nhỏ, chỉ phục vụ một vài service nhất định.

Cách dùng: lấy toàn bộ file của web application và cache chúng tại các edge location, nghĩa là lưu các file đó ở edge location. Sau đó:

• Người dùng vẫn nói chuyện trực tiếp với web server được, không vấn đề gì.
• Nhưng người dùng ở vùng xa, thay vì đi tận về web server, sẽ gửi request tới một trong các edge location, và edge location cung cấp toàn bộ file cần thiết.
• Người dùng ở Úc cũng vậy: họ nói chuyện với một edge location gần hơn.

Ý tưởng chung là giảm tổng thời gian người dùng cần để tương tác với application, vì họ chỉ phải nói chuyện với edge location, nơi hiện đang chứa toàn bộ các file đó.

Edge location là khái niệm rất quan trọng với CloudFront, vì CloudFront về bản chất là một CDN: toàn bộ chuyện của nó là cache file trong các edge location để giảm latency, để không phải mọi người đều đi về đúng một server ở đúng một region.

CloudFront là gì

CloudFront là một web service giúp tăng tốc việc phân phối nội dung static và dynamic, ví dụ:

• HTML, CSS, JavaScript.
• Media file như hình ảnh, video, bài hát.

Mục tiêu là để người dùng truy cập được các nội dung đó từ nơi gần họ nhất. Bản chất nó là một CDN.

CloudFront phân phối nội dung qua một mạng data center toàn cầu gọi là edge location. Khi người dùng gửi request cho nội dung đang được CloudFront phục vụ, request được route tới edge location cho latency, tức độ trễ, thấp nhất, nhờ đó nội dung được phân phối với hiệu năng tốt nhất có thể. Nói lại: thay vì gửi request về tận một server duy nhất, người dùng gửi request tới edge location gần họ nhất để giảm thiểu độ trễ.

Origin

Thành phần đầu tiên trong kiến trúc CloudFront là origin.

Origin là vị trí nguồn của nội dung sẽ được CloudFront cache. Ví dụ có vài hình ảnh hoặc file lưu trong một S3 bucket thì chính bucket đó là origin. Về bản chất đây là lời khai với CloudFront rằng đây là các file cần phân phối tới các edge location.

S3 không phải nguồn duy nhất: dùng được cả custom origin, ví dụ:

• Load balancer.
• Một HTTP server chạy trên một EC2 instance.

Nhắc lại cho gọn: origin không gì khác ngoài vị trí nguồn của nội dung cần được cache.

CloudFront lấy file từ origin rồi cache chúng ở edge location. Khi file đã được cache ở edge location, người dùng lấy nội dung trực tiếp từ edge location, không phải đi về origin, nơi có thể nằm ở một vị trí rất xa.

Distribution và domain name

Giả sử có một S3 bucket với vài media file hoặc hình ảnh, và bucket đó làm origin. Để cấu hình CloudFront, phải cấu hình cái gọi là distribution.

Distribution là một đơn vị, hay một khối, cấu hình trong CloudFront. Mỗi khi cần cache một object hoặc một tập object, việc phải làm là tạo một CloudFront distribution. Trong distribution, khai cho CloudFront biết nó tìm origin, tức các file nguồn, ở đâu.

Sau đó CloudFront tạo ra một domain name, và các hình ảnh đã cache ở edge location truy cập được qua domain đó. Domain name có dạng như xyz.cloudfront.net.

Tiếp đó CloudFront gửi toàn bộ cấu hình của distribution xuống các edge location, nhờ vậy các edge location biết file origin thật nằm ở đâu.

Luồng request: cache hit và cache miss

Người dùng gửi request tới domain name do CloudFront distribution cung cấp, và request đó chạm vào một edge location. Có hai trường hợp:

Tình huống	Hành vi của edge location
Nội dung đã được cache ở edge location đó	trả response về ngay lập tức
Edge location không có nội dung đó, vì lý do nào đi nữa	edge location đang giữ cấu hình của distribution nên biết origin ở đâu: nó gửi một request về origin để lấy hình ảnh, rồi forward hình ảnh đó cho người dùng. Từ đó trở đi nội dung này đã được cache tại edge location để lần sau lấy nhanh hơn

Nhờ vậy, nếu chính người dùng đó hoặc một người dùng khác gửi request tới cùng edge location, edge location không phải gửi request về tận S3 bucket nữa, vì nội dung đã được cache tại đó, nên trả về một response nhanh.

Bốn điểm cần tách bạch:

1. Distribution là đơn vị cấu hình.
2. Domain name được tạo ra từ distribution.
3. Distribution được push xuống các edge location.
4. Edge location hoạt động theo nguyên tắc: đã cache thì trả dữ liệu về ngay; chưa cache thì gửi request về origin lấy dữ liệu, cache lại, rồi trả response cho người dùng.

Time to live

Khi nội dung được cache tại một edge location, nó tồn tại ở đó trong một khoảng thời gian định sẵn, gọi là time to live, viết tắt TTL.

Giá trị TTL quyết định nội dung còn hợp lệ ở một edge location trong bao lâu trước khi hết hạn. Mặc định:

Hạng mục	Giá trị
TTL mặc định cho object cache tại edge location	24 giờ

Diễn biến: cache một object ở edge, object nằm đó 24 giờ, sau 24 giờ nó hết hạn và không còn được cache nữa. Khi đó, nếu edge location nhận một request từ người dùng, nó phải gửi request về origin để lấy lại object đó rồi cache lại.

Dù mặc định là 24 giờ, đặt được thời gian hết hạn khác. Nếu cần hết hạn nhanh hơn thì đặt TTL thành hai giờ, và cứ sau mỗi hai giờ object sẽ hết hạn.

Ví dụ TTL trong thực tế: một CloudFront distribution trỏ về origin là một S3 bucket, giữ TTL mặc định 24 giờ. Các object được cache tại toàn bộ edge location và nằm đó 24 giờ. Sau 24 giờ, toàn bộ file đó bị invalidate, và phải fetch lại file từ S3 bucket rồi cache lại cho 24 giờ tiếp theo.

Cache invalidation

Cache invalidation là việc invalidate thủ công nội dung đang được cache tại một edge location.

Tình huống dẫn tới nhu cầu này: một CloudFront distribution đã thiết lập, origin có một file, gọi là file màu xanh, đại diện cho version một. Version một đã được cache ở các edge location.

Giờ file đó được cập nhật, thành màu đỏ, đại diện cho version hai. Nhưng edge location phải chờ 24 giờ cho object hết hạn, vì TTL là 24 giờ, nên trong 24 giờ đó chúng vẫn giữ version cũ. Người dùng gửi request tới edge location sẽ nhận sai version, nhận version cũ.

Cách xử lý là thực hiện một cache invalidation, tức một quy trình thủ công để dọn sạch cache ở các edge location. Sau khi cache đã được dọn, khi người dùng gửi request tới một edge location, edge location sẽ thấy không còn file nào được cache, nên gửi request về origin, lấy file, cache file đó tại edge location, rồi trả response về cho người dùng. Kết quả là version mới được cache và người dùng nhận đúng version mới.

Phạm vi của invalidation:

• Invalidation được thực hiện trên một distribution. Distribution là đơn vị cấu hình, nên việc invalidate diễn ra trên từng distribution riêng lẻ, không phải dọn sạch toàn bộ nội dung của toàn bộ edge location.
• Invalidate được toàn bộ object trong một distribution, hoặc một folder cụ thể, hoặc một object cụ thể.

Path khai khi invalidate	Phạm vi bị invalidate
/*	toàn bộ distribution
/<tên file>	đúng một file
/images/*	toàn bộ object trong folder images

Tích hợp với service khác

SSL và TLS: mặc định SSL, TLS, tức HTTPS, đã được bật sẵn. Default domain name đã có HTTPS, và AWS cấp một SSL certificate mặc định cho *.cloudfront.net. Nếu muốn dùng custom domain name riêng thì dùng AWS Certificate Manager: tạo một certificate cho CloudFront distribution rồi dùng custom domain name với custom certificate.

CloudWatch: CloudFront tự động publish các operational metric của distribution sang CloudWatch để theo dõi ở đó. Bật thêm extra metric cũng được, nhưng phát sinh thêm chi phí.

Use case

Những thứ thường được cache tại edge location:

• Static website, tức website không có server-side logic.
• Video cho service video-on-demand, cũng như cho streaming.
• Media file các loại.

Thực tế lưu được bất kỳ loại file nào mà người dùng cần truy cập, nhưng các trường hợp phổ biến là static website và phần lớn media file của các website đó.

Chốt lại

• CloudFront phân phối nội dung qua một mạng data center toàn cầu gọi là edge location.
• Nó giúp đưa nội dung tới gần khách hàng hơn để họ có latency thấp hơn.
• Origin trong cấu hình CloudFront là nguồn nội dung cho các edge location, tức nơi chứa file gốc.
• Distribution là đơn vị cấu hình của CloudFront.
• CloudFront distribution nhận được một default domain name.
• Giá trị TTL quyết định nội dung còn hợp lệ bao lâu trước khi edge location phải gửi request về origin. TTL mặc định là 24 giờ.
• Cache invalidation cho phép invalidate object tại edge location trước khi TTL của chúng hết hạn.

---

10. Thực hành: CloudFront với S3 làm origin

Mục tiêu phần này: lấy một hình ảnh, lưu nó trong một S3 bucket để bucket đó làm origin, rồi cache hình ảnh đó trên một CloudFront distribution. Hình ảnh sẽ được cache trên toàn bộ edge location, nhờ đó người dùng không phải gửi request tới tận vị trí của bucket mà tới site edge gần họ nhất.

Bước 1: dựng origin bằng S3

Origin có thể là bất kỳ thứ gì: một web server, một S3 bucket, nhiều nơi khác. Ở đây dùng S3 vì đó là ví dụ đơn giản nhất.

Lưu ý về trình tự: ở bước này chưa liên quan gì tới CloudFront, việc duy nhất cần làm là tìm một nơi để lưu file, hình ảnh, hay bất cứ gì cần cache ở edge.

Vào S3, tạo một bucket:

• Bucket name: một tên bất kỳ, ví dụ demo-bucket-123.
• Region: để mặc định.
• Cho phép internet access.
• Mọi tùy chọn khác để mặc định.

Vào bucket, upload một file. File dùng ở đây là ảnh một chiếc xe màu xanh, tên file là car.jpg. Giữ mọi tùy chọn mặc định rồi upload.

Bước 2: mở quyền truy cập cho file

Sau khi file đã upload, bấm vào file sẽ thấy một object URL. Mở URL đó ra thì nhận access denied.

Nguyên nhân nằm ở bucket policy: phải bảo đảm bucket thực sự khả dụng cho internet truy cập. Vào tab Permissions, tạo một policy. Policy này nói rằng bất kỳ ai, kể cả trên internet, đều truy cập được bucket này và thực hiện được GetObject, tức lấy được mọi object trong bucket. Nếu áp dụng lại cho bucket khác thì chỉ cần đổi tên bucket trong policy. Bấm save.

Quay lại bucket, bấm vào file rồi bấm vào URL: giờ bất kỳ ai cũng truy cập được hình ảnh qua chính URL đó.

Origin đã xong. Nhu cầu tiếp theo: cache hình ảnh này ở edge để người dùng không phải đi tận tới S3 bucket, vốn đang nằm ở Northern Virginia. Với người dùng ở Mỹ thì không thành vấn đề lớn, nhưng với người dùng ở Ấn Độ thì đây là một hình ảnh rất lớn phải tải về trọn vẹn, và nếu đường internet chậm thì độ trễ tải ảnh sẽ rất lớn.

Bước 3: tạo CloudFront distribution

Vào CloudFront, tạo một distribution.

Origin. Chọn vị trí các file cần cache. Các lựa chọn gồm Elastic Load Balancer, API Gateway, MediaStore, web server riêng, và S3 bucket. Ở đây chọn S3 bucket, nó đã hiện sẵn trong danh sách.

Origin path. Chỉ định được một path cụ thể. Ví dụ trong bucket có một folder tên images chứa toàn bộ hình ảnh và chỉ muốn cache folder đó thì điền /images, khi đó chỉ nội dung trong đúng directory ấy được cache. Ở đây các file nằm ở root directory của bucket và nhu cầu là cache mọi thứ trong bucket, nên để trống.

Name. Tên mặc định đã đủ dùng.

Origin access. Mục này quyết định người dùng truy cập origin ra sao:

Lựa chọn	Hệ quả
Public	người dùng truy cập được file trực tiếp từ S3 bucket nếu họ muốn, không cần đi qua CloudFront distribution, vì bucket là public. Họ vẫn mở được car.jpg qua object URL của S3
Origin access control	từ bucket chỉ lấy được hình ảnh thông qua CloudFront. Thứ duy nhất truy cập được bucket là chính CloudFront, còn người dùng chỉ truy cập được CloudFront

Trong thực tế, khi dựng một website, nhất là static website host trên CloudFront, không có lý do gì để cho phép truy cập bucket trực tiếp, nên origin access control là lựa chọn hợp lý: thêm một lớp bảo mật để không ai truy cập thẳng vào bucket. Demo này để public cho đơn giản.

Các tùy chọn khác:

• Compress objects automatically: đặt yes.
• Viewer protocol policy: ở đây cho phép cả HTTP và HTTPS. Thực tế, với một site chuyên nghiệp thì nên redirect HTTP sang HTTPS để người dùng luôn dùng HTTPS; nếu không muốn redirect thì chọn HTTPS only.
• Allowed HTTP methods: ở đây chỉ GET. Nếu cần thêm PUT, POST, PATCH thì chọn thêm.
• Web application firewall: là service bảo mật để chống một số dạng tấn công, bật được ở đây. Demo này để disabled.
• Price class, tức chọn vùng cache: mặc định là dùng toàn bộ edge location. Giới hạn lại được, ví dụ chỉ North America và Europe, hoặc chỉ North America, hoặc North America cùng Europe, Asia, Middle East và Africa. Demo này cache ở toàn bộ edge location.
• Custom SSL certificate: thiết lập certificate bằng AWS Certificate Manager ngay tại đây nếu cần.
• Supported HTTP versions và tùy chọn bật IPv6: để mặc định.

Bấm tạo distribution. Việc này thường mất vài phút.

Bước 4: truy cập file qua distribution

Khi distribution đã deploy xong, nó ở trạng thái enabled và có một distribution domain name. Đây là địa chỉ để truy cập các file đã cache.

Dán URL đó vào browser thì không có gì hiện ra. Nguyên nhân: trong S3 bucket chỉ có file, không có web server nào được host ở đó. Vì vậy phải truy cập theo dạng URL của distribution kèm /car.jpg.

Truy cập https://<distribution-domain-name>/car.jpg thì hình ảnh hiện ra. Điểm cần nhớ: khi mở domain name này, request không đi về S3 bucket mà đi tới các edge location nơi file đang được cache, nên gần hơn và nhanh hơn nhiều.

Bước 5: chứng minh TTL đang giữ version cũ

Về lại S3 bucket và xóa hẳn hình ảnh cũ bằng Permanently delete. Sau đó upload một hình ảnh mới: ảnh một chiếc xe màu đỏ, cùng tên file car.jpg. Nghĩa là ảnh xe xanh đã bị thay bằng ảnh xe đỏ.

Kiểm tra hai nơi:

Truy cập qua	Kết quả
object URL của S3	xe đỏ, tức file mới
CloudFront distribution, bấm refresh	vẫn là xe xanh

Vì sao S3 cho xe đỏ mà CloudFront vẫn cho xe xanh? Vì hình ảnh này đang được cache tại edge location, và nó còn ở đó cho tới khi TTL hết hạn.

Xem TTL ở đâu: vào CloudFront distribution, mở tab Behaviors. Distribution có một behavior; chọn nó rồi bấm Edit, cuộn xuống phần cache policy, mở ra xem viewer policy thì thấy các thiết lập TTL. Giá trị default TTL là 86.400 giây, tức một ngày.

Nghĩa là mặc định ảnh xe xanh trong CloudFront distribution được cache 24 giờ, nên sẽ không thấy được ảnh xe đỏ cho tới khi ảnh này hết hạn, TTL hết hạn, và CloudFront distribution phải gửi request về origin để lấy ảnh.

Bước 6: invalidation để buộc cập nhật ngay

Cách buộc nó cập nhật trước khi TTL hết hạn là thực hiện một invalidation.

Về trang CloudFront, vào Distributions, chọn distribution, mở tab Invalidations, bấm tạo một invalidation. Ở đây phải khai các object nào đang được cache cần invalidate:

Giá trị khai	Phạm vi
/*	mọi object
/car.jpg	chỉ đúng file đó
/images/*	toàn bộ hình ảnh trong folder đó

Demo này invalidate mọi thứ nên dùng /*. Việc này mất một khoảng thời gian, vì nó phải đi tới toàn bộ edge location và invalidate toàn bộ các file đang được cache ở đó.

Khi invalidation hoàn tất, lấy lại distribution domain name, mở một tab mới và truy cập /car.jpg: lần này nhận ảnh xe đỏ.

Cơ chế đằng sau: ảnh xe xanh đã được invalidate, nên khi có request tới distribution domain, tức tới DNS entry, edge location thấy không còn ảnh nào được cache ở đây (vì đã invalidate), nó gửi request về origin và lấy đúng ảnh đang nằm ở đó.

Toàn bộ quy trình cache hình ảnh với CloudFront chỉ có vậy. Việc host một static website hoàn toàn bằng S3 và CloudFront cũng theo gần như đúng các bước trên.

---

11. Chạy code tại edge location

Ý tưởng chính

Phần này nói về CloudFront Functions và Lambda@Edge.

Bản thân các edge location vốn chỉ là cache: chúng cache file ở edge, và ngoài việc đó thì không làm được gì khác, chỉ xử lý request và gửi response.

Với Lambda@Edge và CloudFront Functions, điều mới làm được là viết các function nhẹ chạy ngay tại các edge location, việc trước đây không làm được. Các function này thực hiện được nhiều loại tác vụ:

• Thao tác với request và response chảy qua CloudFront.
• Thực hiện authentication và authorization cơ bản.
• Sinh response ngay tại edge: trả một response về từ edge, tùy biến tùy ý, mà không phải gửi về một back-end server nào.

Hệ quả kiến trúc: không nhất thiết phải có server vật lý nữa, vì phần lớn logic và back-end logic tồn tại được ngay tại các edge location. Điểm đặc biệt duy nhất của cả hai loại function này là chúng chạy tại edge location.

Thời điểm function chạy

CloudFront Functions và Lambda@Edge khác nhau ở chỗ này.

CloudFront Functions chạy ở hai thời điểm:

1. Khi nhận một request từ viewer, tức khi có người gửi request tới một edge node.
2. Trước khi CloudFront trả response về cho viewer.

Lambda@Edge chạy ở bốn thời điểm:

1. Khi CloudFront nhận request từ viewer, giống CloudFront Functions.
2. Khi CloudFront forward request về origin: nếu object không được cache ở edge location thì request được gửi về origin, và code chạy được trước khi request đó được gửi đi.
3. Khi nhận response trở về từ origin.
4. Trước khi trả response về cho viewer.

Thời điểm	CloudFront Functions	Lambda@Edge
nhận request từ viewer	có	có
trước khi forward request về origin	không	có
khi nhận response từ origin	không	có
trước khi trả response về viewer	có	có

Khi nào dùng CloudFront Functions

CloudFront Functions phù hợp cho function nhẹ, chạy ngắn. Các use case:

• Cache key normalization: biến đổi các attribute của HTTP request để tạo ra một cache key tối ưu, nhờ đó cải thiện cache hit ratio.
• Header manipulation: insert, modify hoặc delete các HTTP header trong request hoặc response. Ví dụ thêm một header true client IP vào mọi request.
• URL redirect và rewrite: redirect viewer sang trang khác dựa trên thông tin trong request, hoặc rewrite toàn bộ request từ một path sang một path khác.
• Request authentication: validate các hashed authorization token, ví dụ JSON Web Token, bằng cách soi authorization header hoặc các metadata khác của request.

Khi nào dùng Lambda@Edge

Lambda@Edge phù hợp cho các tình huống sau:

• Function mất vài millisecond hoặc hơn để hoàn thành, tức function chạy dài.
• Function cần CPU hoặc memory điều chỉnh được.
• Function phụ thuộc third-party library, ví dụ AWS SDK để tích hợp với các AWS service khác.
• Function cần network access để dùng các service bên ngoài cho việc xử lý.
• Function cần truy cập file system, hoặc cần truy cập body của HTTP request.

Chọn giữa hai loại

Nguyên tắc chọn: nếu function cực ngắn, ở mức dưới một millisecond, thì CloudFront Functions tốt hơn. Dài hơn mức đó thì chuyển sang Lambda@Edge. Tương tự, nếu cần network access thì CloudFront Functions không có, buộc phải dùng Lambda@Edge.

Đây là điểm cần nắm chắc cho kỳ thi: cả hai nhằm cùng một mục tiêu là chạy code ở edge location, nhưng phải chọn đúng service tùy theo việc code cần làm.

Chốt lại

• Lambda@Edge và CloudFront Functions cho phép chạy code tại các edge location, gần người dùng nhất có thể.
• Cả hai dùng được để thao tác với request và response chảy qua CloudFront.
• CloudFront Functions phù hợp cho header manipulation, URL redirect và authorization.
• Lambda@Edge phù hợp cho function chạy dài và các function cần network access hoặc file access.

---

12. Global Accelerator

Vấn đề cần giải

Giả sử một application được triển khai ở Bắc Mỹ. Khi một người dùng ở bất kỳ đâu trên thế giới muốn nói chuyện với nó, họ gửi request tới server đó: request đi qua service provider của họ, đi xuyên internet, rồi cuối cùng tới server đang host application. Điều này đúng với mọi người dùng trên toàn cầu.

Vấn đề là đường đi đó không nhất thiết là đường hiệu quả nhất qua internet: nó đi theo bất kỳ đường nào mà service provider dẫn đi. Nói chung, khi truyền dữ liệu qua internet:

• Internet không phải đường truyền đáng tin cậy nhất.
• Internet không luôn cho kết nối tốt nhất.
• Internet có latency cao hơn so với các kết nối trực tiếp, và nhìn chung hiệu năng bị suy giảm chỉ vì phải đi qua internet.

Vì vậy không thể trông đợi hiệu năng tốt nhất khi đi qua internet. Global Accelerator được tạo ra để xử lý đúng vấn đề đó, nhằm cải thiện trải nghiệm chung của người dùng cuối bằng cách để họ không phải chịu các giới hạn của việc đi xuyên internet.

Cách Global Accelerator hoạt động

Khi bật Global Accelerator, có quyền dùng toàn bộ edge location của nó. Các edge location này gần giống edge location của CloudFront nhưng khác ở mục đích sử dụng.

Luồng đi với Global Accelerator:

1. Người dùng gửi request để nói chuyện với application, và request đi tới edge location của Global Accelerator gần họ nhất.
2. Từ edge location đó, traffic không còn đi qua internet thường nữa, mà đi qua AWS backbone.

Nói lại theo trình tự: người dùng kết nối vào internet, gửi request tới edge location Global Accelerator gần nhất, và từ sau đó traffic đi qua AWS backbone. Vì đi qua AWS backbone, kết nối nhanh hơn nhiều, bảo mật hơn nhiều, và nhìn chung hiệu quả hơn, vì đó là mạng của AWS, do họ thiết kế để tới mọi region và mọi data center của họ nhanh và hiệu quả nhất có thể.

Người dùng ở Nam Mỹ cũng theo đúng cơ chế: họ tới edge location Global Accelerator gần nhất, rồi đi xuyên mạng backbone của AWS.

Điểm quan trọng nhất cần hiểu: các edge location này tồn tại để đưa traffic của người dùng lên mạng backbone của AWS càng nhanh càng tốt, vì mạng backbone của AWS nhanh hơn nhiều so với service provider thông thường của người dùng, do nó không đi qua internet mà đi qua mạng backbone riêng của AWS.

Phân biệt với CloudFront

Nhiều người lẫn CloudFront với Global Accelerator vì cả hai đều có edge location. Khác biệt cốt lõi:

Service	Việc nó làm ở edge location
CloudFront	cache dữ liệu tại edge: lưu và cache object ở edge location để người dùng lấy object đó nhanh nhất có thể
Global Accelerator	route người dùng tới edge location để họ lên được mạng AWS ngay lập tức, tối ưu thời gian tới application

Nói ngắn: CloudFront dùng để cache dữ liệu ở edge, còn Global Accelerator dùng để đưa người dùng lên AWS backbone, vì mạng của Global Accelerator nhanh hơn và hiệu quả hơn nhiều so với kết nối internet thông thường.

---

13. Route 53

Route 53 là gì

Route 53 là Domain Name Service có quản lý của AWS. Nó giúp quản mọi việc liên quan tới DNS.

Hai nhóm việc chính làm được với Route 53:

• Đóng vai domain registrar: mua được domain tương tự các site như GoDaddy hay Namecheap. Muốn mua một domain name như example.com thì làm thẳng trong Route 53.
• Quản toàn bộ DNS record ngay trong Route 53.

Một đặc tính cần nhớ: Route 53 là global service, nó không gắn với một region nào.

Hosted zone

Khái niệm phải nắm khi làm việc với Route 53 là hosted zone.

Khi có một domain name muốn để Route 53 quản, ví dụ example.com, việc phải làm là tạo một hosted zone. Hosted zone là nơi định nghĩa toàn bộ record và rule. Nói cách khác, zone là nơi chứa toàn bộ DNS rule và DNS record.

Khi tạo một hosted zone cho một domain cụ thể, AWS reserve bốn name server dành riêng cho zone đó. Nếu có thêm một domain khác, ví dụ fastcars.com, thì điều tương tự xảy ra: domain đó có hosted zone riêng, và AWS reserve bốn name server riêng cho hosted zone đó. Toàn bộ record của domain fastcars.com tồn tại trong đúng hosted zone của nó.

Chốt lại

• Route 53 là managed DNS service của AWS.
• Route 53 là global service, không gắn với region nào.
• Hosted zone là một tập hợp các DNS record của một domain cụ thể.

---

14. Thực hành: đăng ký domain và tạo DNS record trong Route 53

Route 53 là managed DNS service của AWS, và phần này đi qua hai việc: register domain name và định nghĩa DNS entry cho domain đó. Việc register domain cũng làm được ở các site khác như GoDaddy hay Namecheap, nhưng ở đây làm trong Route 53.

Bước 1: register một domain

Tra Route 53 trong console rồi mở service. Vào mục Domains và chọn Register domains.

Nếu account chưa có domain nào thì danh sách trống. Ở đây có hai hướng: transfer domain đã register ở nơi khác về, hoặc register mới ngay tại đây. Phần này register mới.

Việc đầu tiên là kiểm tra domain có còn trống không. Tên dùng trong demo là một tên vô thưởng vô phạt để lấy được domain giá rẻ, vì domain luôn tốn tiền. Tra tên demo-site-123 thì kết quả cho thấy:

Domain	Giá
demo-site-123.com	13 USD mỗi năm
demo-site-123.link	một mức giá khác, cũng khả dụng

Ở đây chọn mua demo-site-123.com, rồi bấm Proceed to Checkout.

Bước 2: checkout

Các lựa chọn ở bước checkout:

• Auto-renew: sau một năm, domain có tự động gia hạn để tiếp tục sở hữu domain đó hay không. Bỏ chọn thì phải tự nhớ gia hạn, và việc này rất dễ quên, nên để nguyên auto-renew là lựa chọn an toàn.
• Contact information: điền form thông tin liên hệ.
• Privacy protection: bảo đảm đã bật privacy protection cho toàn bộ contact của domain.

Điền xong thì bấm Next. Màn hình tiếp theo tóm tắt lại thứ đang mua, kèm thông báo rằng sẽ có một annual management fee: khi register một domain với Route 53, một hosted zone cũng được tạo, và hosted zone này phát sinh một khoản phí nhỏ cộng thêm vào 13 USD mỗi năm.

Cuộn xuống, kiểm tra lại thông tin liên hệ cho đúng, đồng ý terms and conditions, rồi bấm submit.

Việc register domain name mất một lúc. Ngoài ra sẽ nhận được một email báo registration status cho mỗi domain đã register, nên cần kiểm tra email để chắc chắn mọi thứ ổn. Sau đó chờ tới khi domain xuất hiện trong mục registered domains của Route 53.

Bước 3: xem thông tin domain và hosted zone

Khi quy trình register hoàn tất, danh sách cho thấy:

• Domain name.
• Ngày domain hết hạn, ở đây là một năm kể từ hiện tại.
• Trạng thái auto-renew đang bật.

Bấm vào domain để xem thêm: ngày register, ngày hết hạn, thông tin liên hệ, và bốn name server mà AWS cấp cho hosted zone.

Nhắc lại cơ chế: khi register một domain name thì nhận được một hosted zone, và đó là nơi lưu toàn bộ DNS record và DNS entry.

Vào mục Hosted Zones sẽ thấy đúng một hosted zone, chính là của demo-site-123.com vừa register. Mở nó ra thì thấy:

• Các thông tin trùng với phần trên, gồm bốn DNS server đã reserve.
• Toàn bộ DNS record đã được cấu hình tự động.
• Nút Create record để tạo thêm DNS record, với loại record tùy chọn.

Bước 4: tạo một A record trỏ về web server

Môi trường có sẵn một web server đang chạy. Đây là một public server, có IP address. Dán IP address đó vào browser thì thấy một website ghi this is demo-site-123.com.

Hiện tại vẫn phải dùng IP address để truy cập. Việc cần làm là tạo một DNS record để dùng chính domain name trỏ tới web server này.

Vào Route 53, bấm Create record. Console mở menu quick create record:

• Record type: dùng A record. Việc giải thích các loại DNS record nằm ngoài phạm vi của AWS và của kỳ thi AWS Solutions Architect Associate, nhưng điểm cần nhớ là: bất cứ khi nào cần một record trỏ tới một IP address cụ thể thì dùng A record.
• Record name: hiện đang để trống tương ứng với demo-site-123.com, tức root domain. Nếu muốn www.demo-site-123.com thì điền www. Nếu muốn một subdomain, ví dụ course.example.com, thì điền phần subdomain tương ứng. Ở đây chỉ cần root domain để người dùng vào thẳng URL đó là tới server.
• Value: chính là IP address của web server. Dán IP vào đây. Nghĩa là mỗi khi có ai truy cập domain này, Route 53 phản hồi rằng để tới đó thì đi tới IP address này.
• TTL và vài property khác: để mặc định.

Bấm Create records. Console thông báo: Route 53 propagate các thay đổi tới toàn bộ Route 53 authoritative DNS server trong vòng 60 giây, và dùng nút View status để kiểm tra trạng thái propagation.

Bấm View status thì trạng thái đang là pending. Chờ 60 giây rồi kiểm tra lại thì trạng thái chuyển thành in sync.

Bước 5: kiểm tra

Mở một tab browser và gõ demo-site-123.com: trang web hiện ra, đúng server đã trỏ tới.

Đó là toàn bộ cốt lõi của Route 53: register một domain name, định nghĩa các DNS record cần thiết, và Route 53 lo phần còn lại. Với kỳ thi Solutions Architect, điều cần nắm là Route 53 phục vụ việc quản domain name và DNS entry.

---

15. Route 53 Application Recovery Controller

Service này làm gì

Amazon Route 53 Application Recovery Controller là service liên tục giám sát khả năng phục hồi của một application sau sự cố, và điều khiển việc application recovery xuyên nhiều AWS Region và nhiều Availability Zone.

Ý tưởng của service: làm cho quy trình application recovery đơn giản hơn và đáng tin cậy hơn bằng cách loại bỏ các bước thủ công mà các công cụ và quy trình truyền thống đòi hỏi. Nói cách khác, nó tự động hóa toàn bộ việc liên tục kiểm tra xem backup location hay backup site có đang hoạt động, đang chạy đúng, và có fail over sang đó được khi sự cố xảy ra hay không.

Mô hình active và standby

Giả sử một application triển khai ở một region, đó là active deployment, và có một backup hoặc standby deployment ở region khác.

Application Recovery Controller được thiết lập để giám sát môi trường backup, bảo đảm nó đang chạy, đã scale up và được cấu hình đúng, để biết chắc rằng khi cần fail over sang đó thì nó sẵn sàng hoạt động.

Tiếp đó, dựa trên các cấu hình định trước, Application Recovery Controller giám sát cả primary deployment. Nếu primary deployment có vấn đề, nó dùng một metric nào đó làm điều kiện, ví dụ nếu application suy giảm quá 5% thì fail over sang backup site, chuyển toàn bộ traffic sang backup site cho tới khi xử lý xong sự cố ở active site.

Ngoài ra Application Recovery Controller còn dùng để chuyển traffic thủ công khỏi một deployment trong lúc bảo trì theo kế hoạch. Khi biết trước sẽ bảo trì primary deployment, cách làm là thực hiện một manual diversion, và trong thời gian bảo trì thì fail over traffic sang standby site.

Kiến trúc

Ví dụ kiến trúc cụ thể:

Active site, ở us-east-1: một load balancer và vài EC2 instance trong một Availability Zone, cùng một DynamoDB table mà các EC2 instance kết nối tới. Application chính là tổ hợp load balancer, EC2 instance và DynamoDB table đó.

Standby site, còn gọi là backup site hay failover site, ở một region khác: thiết lập y hệt, gồm một load balancer và một EC2 instance kết nối tới DynamoDB table. Table ở đây là một global DynamoDB table, đó là lý do nó không nằm trong một AWS Region riêng lẻ nào.

Route 53 đứng ở trước: đây là service quản DNS, nên với application cụ thể, nó route traffic tới active site, tức Route 53 chịu trách nhiệm đưa traffic tới load balancer ở active site. Khi cần thì fail over, tức để Route 53 trỏ DNS entry sang load balancer ở standby site. Đó là cách lật qua lại giữa hai site.

Ba thuật ngữ cần hiểu

Thuật ngữ	Định nghĩa
cell	nhóm toàn bộ resource cần thiết để một application hoạt động độc lập. Trong ví dụ trên, một cell ở us-east-1 vì nó có đủ mọi thứ cần để hoạt động: load balancer và EC2 instance. Standby site là một cell khác, cũng có đủ mọi thứ cần để chạy
recovery group	một tập hợp các cell đại diện cho một application cần kiểm tra failover readiness. Trong ví dụ trên, recovery group gồm cả hai cell, nên nó giám sát cả active site lẫn standby site, bảo đảm cả hai đang chạy và hoạt động đúng
resource set	một tập AWS resource trải qua nhiều cell. Mọi resource đi xuyên hơn một cell, ví dụ global DynamoDB table ở trên, đều là một ví dụ của resource set

Readiness check và routing control

Readiness check: Application Recovery Controller thực hiện readiness check để giám sát mức sẵn sàng của standby deployment. Nó soi đúng cell đó và xác minh rằng toàn bộ resource tạo nên standby deployment đang chạy và sẵn sàng. Nó liên tục thực hiện các check đó và ghi lại những gì đang hoạt động, để bảo đảm mọi thứ sẵn sàng khi cần fail over sang standby site.

Routing control: cho phép fail over thủ công toàn bộ application stack sang standby site. Chỉ cần ra lệnh cho Route 53 fail over sang standby site, Route 53 lấy DNS entry của application và trỏ nó sang standby site. Đó chính là cách thực hiện một failover, và về bản chất toàn bộ việc này diễn ra thông qua Route 53.

Chốt lại

• Amazon Route 53 Application Recovery Controller là service liên tục giám sát khả năng phục hồi của application sau sự cố.
• Các capability của nó làm cho application recovery đơn giản hơn và đáng tin cậy hơn bằng cách loại bỏ các bước thủ công.
• cell là các silo chứa các đơn vị failover độc lập của một application: chúng nhóm toàn bộ AWS resource cần thiết để application hoạt động độc lập.
• recovery group là một tập hợp các cell đại diện cho một application, hoặc một nhóm application, cần kiểm tra failover readiness.
• resource set là các resource trải qua nhiều cell.
• readiness check xác nhận mức sẵn sàng của một tập AWS resource để được fail over sang.

---

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, tên bucket và domain name trong các phần thực hành (web load balancer, target group web, VPC-A, demo-bucket-123, demo-site-123.com...) là tên ví dụ chung, đặt lại thế nào cũng được.