Các kiến trúc giải pháp nâng cao

1. Lambda với SNS & SQS

Ba dịch vụ Lambda, SNS và SQS kết hợp với nhau theo vài mẫu rất hay gặp trong đề thi. Điểm mấu chốt bạn phải nhớ là mỗi cách ghép có cơ chế retry (thử lại) và DLQ (Dead Letter Queue — hàng chờ chứa message xử lý thất bại) khác nhau, và riêng SQS FIFO có thêm đặc tính blocking.

Mẫu ghép	Cách Lambda nhận message	Đặc tính khi lỗi
SQS + Lambda	Lambda poll (chủ động lấy) message từ queue	Try, retry; message lỗi cuối cùng đi vào DLQ gắn với SQS
SQS FIFO + Lambda	Lambda poll từ queue FIFO	Try, retry; message lỗi gây blocking (chặn các message sau trong cùng group) rồi đi vào DLQ
SNS + Lambda	SNS gọi Lambda theo kiểu asynchronous	retries; nếu vẫn thất bại thì vào DLQ

Điểm khác biệt đáng chú ý nhất: với SQS FIFO, thứ tự message được đảm bảo nên một message xử lý mãi không thành công sẽ chặn cả những message đứng sau — đây là lý do DLQ trở nên quan trọng hơn hẳn so với queue thường.

2. Fan Out Pattern

Giả sử bạn muốn cùng một message đi vào nhiều SQS queue (nhiều hệ thống tiêu thụ độc lập nhau). Có hai cách, và slide đặt chúng cạnh nhau để so sánh:

Option 1: ứng dụng dùng SDK gọi lần lượt PUT #1, PUT #2, PUT #3 vào ba queue. Nghĩa là ứng dụng phải tự biết có bao nhiêu queue và tự gửi từng lần — mỗi lần gửi là một lần có thể lỗi.
Option 2 – Fan Out: ứng dụng dùng SDK PUT một lần duy nhất vào một SNS topic, còn các SQS queue thì subscribe vào topic đó. SNS lo việc nhân bản message ra tất cả queue đang subscribe.

Fan Out là mẫu bạn nên chọn khi số lượng hệ thống tiêu thụ có thể thay đổi: thêm một consumer mới chỉ là thêm một queue subscribe vào topic, không phải sửa code ứng dụng.

3. S3 Event Notifications

S3 Event Notifications cho phép bucket S3 phát ra event mỗi khi có thay đổi, và gửi event đó tới Lambda Function, SQS hoặc SNS.

Các loại event: S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication…
Có thể lọc theo tên object (ví dụ *.jpg).
Use case kinh điển: tạo thumbnail cho các ảnh được upload lên S3.
Bạn có thể tạo bao nhiêu “S3 event” cũng được.
Về độ trễ: S3 event notification thường giao event trong vài giây, nhưng đôi khi có thể mất một phút hoặc lâu hơn.

S3 Event Notifications với Amazon EventBridge

Thay vì gửi trực tiếp tới ba đích trên, bucket S3 có thể đẩy toàn bộ event (all events) vào Amazon EventBridge, rồi EventBridge dùng rules để định tuyến tới hơn 18 dịch vụ AWS làm đích. Đi qua EventBridge, bạn có thêm:

Advanced filtering: lọc nâng cao bằng JSON rules (theo metadata, kích thước object, tên object…).
Multiple Destinations: ví dụ Step Functions, Kinesis Data Streams / Firehose…
EventBridge Capabilities: Archive, Replay Events, Reliable delivery (lưu trữ lại event, phát lại event, và giao event tin cậy).

4. EventBridge – bắt các lời gọi API

Một mẫu giám sát rất mạnh: CloudTrail ghi lại mọi lời gọi API trong tài khoản, đẩy sang Amazon EventBridge, và EventBridge khớp rule rồi gửi SNS để alert cho người vận hành.

Ví dụ trong slide: một User gọi API DeleteTable lên DynamoDB. CloudTrail ghi lại lời gọi API đó, EventBridge nhận event và bắn thông báo qua SNS — nhờ vậy bạn biết ngay có người vừa xóa một table, thay vì phát hiện ra vài ngày sau.

5. API Gateway tích hợp trực tiếp với dịch vụ AWS

API Gateway không chỉ gọi Lambda — nó có thể tích hợp trực tiếp với các dịch vụ AWS khác. Slide lấy ví dụ với Kinesis Data Streams:

Client gửi request vào API Gateway → API Gateway send records vào Kinesis Data Streams → Kinesis Data Firehose đọc từ stream và store các file .json vào Amazon S3.

Điểm hay của mẫu này là bạn có một endpoint HTTP công khai để nhận dữ liệu từ client, nhưng không cần viết một dòng code xử lý nào — toàn bộ đường đi từ API tới file trên S3 là tích hợp giữa các dịch vụ managed.

6. Chiến lược caching nhiều tầng

Slide “Caching Strategies” xếp các lựa chọn cache theo từng tầng trong đường đi của một request, từ ngoài vào trong. Cùng một request có thể được cache ở nhiều chỗ khác nhau, và mỗi chỗ đánh đổi khác nhau giữa caching, TTL, network, computation, cost, latency.

Tầng	Cơ chế cache
Gần client nhất (edge)	CloudFront (edge)
Trước API	API Gateway (có caching riêng)
App logic trên EC2 / Lambda	— (nơi quyết định đọc cache hay không)
Trước database	Redis, Memcached, DAX
Nội dung tĩnh trên S3	CloudFront

Cách đọc bảng này: càng cache gần client thì càng cắt được nhiều network latency và nhiều computation ở phía sau, nhưng TTL càng khó kiểm soát độ mới của dữ liệu. Ngược lại, cache ngay trước database (Redis/Memcached/DAX) giữ dữ liệu tươi hơn nhưng request vẫn phải đi hết đường mạng tới hệ thống của bạn.

7. Chặn một địa chỉ IP — chặn ở đâu là đúng?

Đây là chuỗi slide rất đáng học, vì nó cho thấy cùng một yêu cầu “chặn một IP” nhưng câu trả lời đổi theo kiến trúc. Nguyên tắc xuyên suốt: Security Group chỉ có allow rule, nên muốn deny một IP cụ thể thì phải dùng NACL (có cả deny và allow rule) hoặc WAF.

EC2 có public IP, không có load balancer

Client đi trực tiếp vào EC2 Instance nằm trong Public Subnet của VPC, máy có public IP và có thể có Firewall Software (tùy chọn) cài trong OS. Ở kiến trúc này, IP được chặn tại NACL (deny + allow rules), vì Security Group chỉ có allow rule. Ngoài ra bạn còn có thêm lớp firewall ngay trong hệ điều hành nếu muốn.

Có Application Load Balancer (ALB)

Client vào Application Load Balancer ở Public Subnet (với ALB Security Group), ALB thực hiện Connection Termination (kết thúc kết nối tại ALB) rồi mở kết nối mới tới EC2 Instance ở Private Subnet qua private IP (với EC2 Security Group). Vì ALB kết thúc kết nối, EC2 không còn thấy IP gốc của client ở tầng kết nối — nên việc chặn IP phải làm ở lớp ngoài, tại NACL đứng trước ALB.

Có Network Load Balancer (NLB)

Kiến trúc tương tự nhưng dùng Network Load Balancer với NLB Security Group; EC2 Instance ở Private Subnet với private IP và EC2 Security Group; NACL vẫn là nơi đặt rule chặn. Khác với diagram của ALB, ở đây slide không vẽ bước Connection Termination — phần còn lại của cách chặn IP là giống nhau.

ALB + AWS WAF

Thêm AWS WAF trước Application Load Balancer: WAF làm IP Address Filtering — đây là cách chặn IP ở tầng ứng dụng, mềm dẻo hơn NACL. NACL, ALB Security Group, EC2 Security Group và EC2 ở Private Subnet vẫn giữ nguyên vai trò như trên.

ALB + CloudFront + WAF

Khi đặt CloudFront ra trước cùng, kiến trúc đổi bản chất: client giờ nói chuyện với CloudFront, và AWS WAF (IP Address Filtering) được gắn ở CloudFront, còn CloudFront Geo Restriction lo phần chặn theo quốc gia. Điều quan trọng nhất trong slide này: vì traffic tới ALB giờ đến từ các CloudFront Public IP, nên NACL trong VPC KHÔNG còn giúp được gì (slide ghi rõ “NOT helpful”) — bạn không thể dùng NACL để chặn IP của client thật nữa.

8. High Performance Computing (HPC)

Cloud là môi trường hoàn hảo cho HPC, vì ba lý do rất cụ thể:

Bạn có thể tạo ra rất nhiều tài nguyên trong thời gian cực ngắn.
Bạn có thể rút ngắn thời gian ra kết quả bằng cách thêm tài nguyên.
Bạn chỉ trả tiền cho hệ thống đã dùng.

Các bài toán HPC điển hình: genomics (giải mã gen), computational chemistry (hóa tính toán), financial risk modeling (mô hình rủi ro tài chính), weather prediction (dự báo thời tiết), machine learning, deep learning, autonomous driving (xe tự hành).

Phần còn lại của mục này trả lời câu hỏi “dịch vụ nào hỗ trợ HPC?”, chia theo bốn nhóm.

Data Management & Transfer

AWS Direct Connect: chuyển dữ liệu ở mức GB/s lên cloud, qua một private secure network.
Snowball & Snowmobile: chuyển dữ liệu ở mức PB lên cloud.
AWS DataSync: chuyển khối lượng dữ liệu lớn giữa on-premise và S3, EFS, FSx for Windows.

Compute and Networking

EC2 Instances: loại CPU optimized và GPU optimized; dùng Spot Instances / Spot Fleets kết hợp Auto Scaling để tiết kiệm chi phí.
EC2 Placement Groups – kiểu Cluster: đặt các EC2 instance cùng một rack, cùng một AZ để có hiệu năng mạng tốt: low latency, mạng 10 Gbps.
EC2 Enhanced Networking (SR-IOV): băng thông cao hơn, PPS (packet per second) cao hơn, độ trễ thấp hơn. Có hai lựa chọn:
- Option 1: Elastic Network Adapter (ENA) — lên tới 100 Gbps.
- Option 2: Intel 82599 VF — lên tới 10 Gbps, đây là lựa chọn LEGACY (cũ).
Elastic Fabric Adapter (EFA): bản ENA được cải tiến dành riêng cho HPC, chỉ chạy trên Linux. EFA rất tốt cho inter-node communications và các tightly coupled workload (các node phải liên tục trao đổi với nhau). EFA dùng chuẩn MPI (Message Passing Interface) và bỏ qua (bypass) hệ điều hành Linux bên dưới để cung cấp một kênh truyền có độ trễ thấp và đáng tin cậy.

Storage

Instance-attached storage:
- EBS: scale tới 256.000 IOPS với io2 Block Express.
- Instance Store: scale tới hàng triệu IOPS, gắn với EC2 instance, độ trễ thấp.
Network storage:
- Amazon S3: phù hợp cho large blob, không phải một file system.
- Amazon EFS: IOPS scale theo tổng dung lượng, hoặc dùng provisioned IOPS.
- Amazon FSx for Lustre: distributed file system được tối ưu cho HPC, đạt hàng triệu IOPS, và được S3 hỗ trợ ở phía sau (backed by S3).

Automation and Orchestration

AWS Batch: hỗ trợ multi-node parallel jobs, cho phép chạy một job duy nhất trải trên nhiều EC2 instance; dễ dàng lên lịch job và tự khởi chạy EC2 instance tương ứng.
AWS ParallelCluster: công cụ quản lý cluster open-source để triển khai HPC trên AWS. Cấu hình bằng text file, tự động tạo VPC, Subnet, kiểu cluster và instance type, và có thể bật EFA trên cluster để cải thiện hiệu năng mạng.

9. Tạo một EC2 instance có tính sẵn sàng cao

Chuỗi ba slide cuối chương giải một bài toán rất cụ thể: bạn có một EC2 instance (không phải cụm) mang Elastic IP Address, chạy một service kiểu “What time is it? → 5:30 pm!”, và bạn muốn nó tự sống lại khi chết. Ba phiên bản của giải pháp ngày càng tự động hơn.

Phiên bản 1 — CloudWatch Event / Alarm

Một CloudWatch Event (hoặc Alarm dựa trên metric) monitor instance đang chạy. Khi phát hiện sự cố, nó start một Standby EC2 instance và attach Elastic IP vào máy dự phòng đó. Cách này hoạt động, nhưng bạn phải tự nuôi sẵn một máy standby.

Phiên bản 2 — dùng Auto Scaling Group

Thay máy standby bằng một Auto Scaling Group với cấu hình rất đặc biệt:

1 min, 1 max, 1 desired — luôn đúng một instance.
Trải trên >= 2 AZ (Availability Zone 1 và Availability Zone 2).
EC2 User Data để tự attach Elastic IP khi máy khởi động, tìm Elastic IP dựa trên Tag.
EC2 instance role cho phép gọi API để attach Elastic IP.

Khi instance chết, ASG tự tạo Replacement EC2 instance ở AZ còn lại, và User Data tự gắn lại Elastic IP — không cần CloudWatch, không cần máy standby.

Phiên bản 3 — ASG + EBS để giữ dữ liệu

Phiên bản 2 vẫn còn một lỗ hổng: dữ liệu trên ổ đĩa của máy cũ mất theo máy cũ. Bổ sung thêm EBS vào vòng đời của ASG bằng hai lifecycle hook:

On ASG Terminate lifecycle hook: tạo một EBS Snapshot (kèm tags) từ EBS Volume của instance đang bị terminate.
On ASG Launch lifecycle hook: từ EBS Snapshot đó, tạo một EBS Volume mới và attach vào instance thay thế.

Kết quả là một “instance đơn lẻ” nhưng tự phục hồi cả địa chỉ IP lẫn dữ liệu trên ổ đĩa, xuyên qua nhiều AZ.

Tóm tắt nhanh

Chủ đề	Cần nhớ
SQS + Lambda	Lambda poll queue; message lỗi cuối cùng vào DLQ gắn với queue
SNS + Lambda	SNS invoke asynchronous, retry ở phía SNS, còn lại vào DLQ
SQS FIFO + Lambda	Thứ tự được đảm bảo nên một message lỗi chặn các message sau trong cùng group; DLQ là thứ gỡ tắc
Fan Out	Một PUT vào SNS topic, nhiều SQS queue subscribe — thay cho việc ứng dụng tự PUT nhiều lần
S3 Event Notifications	Tới Lambda / SQS / SNS, lọc theo tên object, thường vài giây nhưng có thể quá một phút
S3 + EventBridge	Cần khi muốn lọc bằng JSON rules (metadata, kích thước), hơn 18 đích, hoặc Archive và Replay
CloudTrail + EventBridge + SNS	Mẫu cảnh báo cho mọi lời gọi API, ví dụ `DeleteTable`
API Gateway tích hợp thẳng	Vào Kinesis Data Streams → Firehose → S3, không cần Lambda
Các tầng cache	CloudFront (edge), API Gateway, Redis / Memcached / DAX trước database, CloudFront cho nội dung S3
Chặn IP	Security Group không deny được. EC2 trần hoặc có ELB → NACL; có ALB thì nên dùng WAF; có CloudFront → WAF ở CloudFront và Geo Restriction, lúc này NACL không còn hữu ích
HPC — mạng	Placement Group Cluster, Enhanced Networking (ENA tới 100 Gbps, Intel 82599 VF tới 10 Gbps legacy), EFA (Linux, MPI, bypass OS)
HPC — lưu trữ	EBS io2 Block Express 256.000 IOPS, Instance Store hàng triệu IOPS, FSx for Lustre backing bởi S3
HPC — điều phối	AWS Batch cho multi-node parallel job, AWS ParallelCluster dựng cả cluster từ text file
HPC — truyền dữ liệu	Direct Connect cho GB/s, Snowball / Snowmobile cho PB, DataSync tới S3 / EFS / FSx for Windows
EC2 đơn lẻ nhưng HA	ASG 1/1/1 trên ≥ 2 AZ, User Data attach Elastic IP theo tag, instance role cho API call, lifecycle hook để snapshot và restore EBS