Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

A — Triển khai Auto Scaling group với 2 instance ở mỗi AZ trong 3 Availability Zone, sau một Application Load Balancer.

Vì sao đúng

Đề nêu điều kiện: cần TỐI THIỂU 4 instance để phục vụ, và phải chịu lỗi (fault tolerant).

"Chịu lỗi" nghĩa là mất một AZ vẫn còn đủ 4 máy — hãy kiểm tra từng phương án:

A. 2 + 2 + 2 = 6 máy, 3 AZ
   Mất một AZ → còn 4 máy  ✅ ĐỦ

B. 2 + 2 = 4 máy, 2 AZ
   Mất một AZ → còn 2 máy  ✗ thiếu 2

C. 4 máy, 1 AZ
   Mất AZ đó → còn 0 máy   ✗ mất toàn bộ

D. 1 + 1 + 1 + 1 = 4 máy, 4 AZ
   Mất một AZ → còn 3 máy  ✗ thiếu 1

Chỉ phương án A duy trì được mức tối thiểu 4 máy sau khi mất một AZ.

Công thức tổng quát cho bài toán này:

Số máy mỗi AZ = ceil( N / (số AZ − 1) )
Tổng số máy    = số AZ × số máy mỗi AZ

Với N = 4, 3 AZ:
    ceil(4 / 2) = 2 máy mỗi AZ
    tổng = 3 × 2 = 6 máy

Và vì sao ba AZ tốt hơn hai:

2 AZ:  cần 4+4 = 8 máy   (mỗi AZ phải gánh được toàn bộ tải)
3 AZ:  cần 2+2+2 = 6 máy
    → tiết kiệm 25% với cùng mức chịu lỗi

Vì sao các phương án khác sai

• **B. 2 instance ở mỗi AZ trong 2 AZ — đây là phương án gần nhất và có trải qua nhiều AZ, nhưng nó không đủ dự phòng: mất một AZ chỉ còn 2 máy, thiếu một nửa so với yêu cầu tối thiểu 4.
• **D. 1 instance ở mỗi AZ trong 4 AZ — trải rộng nhất nhưng vẫn không đủ: mất một AZ còn 3 máy. Và không phải Region nào cũng có 4 AZ.
• **C. 4 instance trong MỘT AZ — không chịu lỗi chút nào: đủ số máy nhưng mất AZ đó là mất toàn bộ dịch vụ. Đây là điều mà kiến trúc chịu lỗi phải tránh trước tiên.

Ghi nhớ

Công thức tính số instance cho kiến trúc chịu lỗi N+1 theo AZ:

Cần N máy phục vụ, chịu được mất 1 AZ, có K AZ:
    Máy mỗi AZ = ceil( N / (K − 1) )
    Tổng       = K × ceil( N / (K − 1) )

Bảng tra nhanh: | Cần | 2 AZ | 3 AZ | 4 AZ | |---|---|---|---| | 2 máy | 4 | 3 | 4 | | 4 máy | 8 | 6 | 8 | | 6 máy | 12 | 9 | 8 | | 9 máy | 18 | 15 | 12 |

Ba AZ thường là điểm cân bằng tốt nhất — nó giảm được lượng dự phòng thừa so với hai AZ mà không phức tạp như bốn.

Ba cấu hình Auto Scaling group cho kiến trúc này: | Cấu hình | Giá trị | |---|---| | MinSize | 6 — đảm bảo luôn đủ sau sự cố AZ | | DesiredCapacity | 6 | | MaxSize | cao hơn để chịu được tăng tải bất ngờ |

Và bật cân bằng AZ tự động:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung-ngan-hang   --vpc-zone-identifier "subnet-az-a,subnet-az-b,subnet-az-c"   --min-size 6 --desired-capacity 6 --max-size 12   --health-check-type ELB --health-check-grace-period 300

--health-check-type ELB là cấu hình quan trọng thường bị bỏ sót:

Mặc định (EC2):
    chỉ thay instance khi MÁY chết hẳn
    → ứng dụng treo nhưng máy còn sống → KHÔNG bị thay
ELB:
    thay instance khi LOAD BALANCER đánh giá là không lành mạnh
    → bắt được cả lỗi ở tầng ứng dụng

Ba cơ chế chịu lỗi mà ASG cung cấp: | Cơ chế | Việc | |---|---| | Tự thay instance hỏng | duy trì đủ số lượng mong muốn | | AZ Rebalancing | tự cân bằng lại khi một AZ có nhiều máy hơn | | Phân bổ đều khi khởi chạy | ưu tiên AZ đang có ít instance nhất |

AZ Rebalancing đáng biết: sau khi một AZ phục hồi, ASG tự khởi chạy máy ở đó rồi mới chấm dứt máy thừa ở AZ khác — nên dung lượng không bao giờ tụt xuống dưới mức mong muốn trong quá trình cân bằng.

Ba yếu tố khác của kiến trúc chịu lỗi mà câu hỏi không nhắc tới: | Yếu tố | Chi tiết | |---|---| | Database phải Multi-AZ | tầng web chịu lỗi mà database một AZ thì vô nghĩa | | NAT Gateway mỗi AZ | một NAT dùng chung là điểm hỏng đơn | | Không lưu trạng thái trên instance | phiên đăng nhập ở ElastiCache, tệp ở S3 hoặc EFS |

Dòng đầu là điểm hay bị bỏ sót nhất: rất nhiều kiến trúc đầu tư kỹ cho tầng web nhiều AZ rồi để RDS chạy Single-AZ — và điểm hỏng đơn vẫn còn nguyên.

Và một lưu ý về chi phí cho ngân hàng đầu tư như đề mô tả: 6 máy chạy liên tục là ứng viên tốt cho Savings Plan hoặc Reserved Instance — mức nền ổn định, biết trước sẽ chạy dài hạn. Phần vượt trên mức nền (khi ASG mở rộng) để On-Demand hoặc Spot.

Đáp án

B — Dùng Lifecycle Policy.

Vì sao đúng

Đề mô tả mẫu truy cập rất rõ: video chỉ được xem thường xuyên trong BA THÁNG ĐẦU sau khi đăng — và đó chính là tình huống mà lifecycle policy sinh ra để giải.

Cấu hình gọn, không cần mã, không cần máy chủ:

{
  "Rules": [{
    "ID": "chuyen-video-cu-sang-glacier",
    "Status": "Enabled",
    "Filter": {"Prefix": "video-chat-luong-cao/"},
    "Transitions": [
      {"Days": 90,  "StorageClass": "GLACIER"},
      {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
    ]
  }]
}

Bốn lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần mã, không cần máy chủ | không có gì để bảo trì | | Không cần lịch chạy | S3 tự đánh giá hằng ngày | | Áp cho video mới tự động | đăng bài mới cũng theo cùng quy tắc | | Miễn phí | chỉ trả phí chuyển đổi mỗi object |

Và mức tiết kiệm rất đáng kể với video:

S3 Standard:              ~0,023 USD/GB-tháng
Glacier Flexible:         ~0,0036 USD/GB-tháng   → rẻ hơn ~6 lần
Glacier Deep Archive:     ~0,00099 USD/GB-tháng  → rẻ hơn ~23 lần

Với kho video hàng chục terabyte, chênh lệch này là hàng nghìn USD mỗi tháng.

Vì sao các phương án khác sai

• **A. Dùng shell script tuỳ chỉnh để chuyển dữ liệu từ S3 sang Glacier — đây là phương án gần nhất và hoạt động được, nhưng nó nhiều công hơn hẳn: phải có máy chạy script, viết logic phân trang cho hàng triệu object, xử lý lỗi, giám sát. Và máy chạy 24/7 tốn tiền cho việc mà S3 làm miễn phí.
• **C. Dùng Amazon SQS — là hàng đợi thông điệp: nó không có khả năng chuyển đổi lớp lưu trữ nào.
• **D. Dùng Amazon SWF (Simple Workflow Service) — sai công cụ: SWF điều phối các bước trong một quy trình nghiệp vụ phức tạp. Dùng nó cho việc mà lifecycle rule làm sẵn là thừa thãi. (Và SWF cũng là dịch vụ thế hệ cũ — AWS khuyến nghị dùng Step Functions cho nhu cầu mới.)

Ghi nhớ

Bốn thao tác của lifecycle rule: | Thao tác | Việc | |---|---| | Transitions | chuyển sang lớp lưu trữ rẻ hơn ← câu này | | Expiration | xoá object sau N ngày | | NoncurrentVersionTransitions/Expiration | quản lý phiên bản cũ khi bật versioning | | AbortIncompleteMultipartUpload | dọn phần tải lên dở dang |

Dòng cuối đặc biệt quan trọng với trang chia sẻ video: video là tệp lớn nên gần như luôn dùng multipart upload, và mỗi lần tải lên thất bại để lại các phần đã tải tính phí mãi mãi mà không hiện trong danh sách object:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Thứ tự chuyển đổi hợp lệ:

Standard
   ↓
Standard-IA / One Zone-IA / Intelligent-Tiering
   ↓
Glacier Instant Retrieval
   ↓
Glacier Flexible Retrieval
   ↓
Glacier Deep Archive

Lifecycle chỉ chuyển XUỐNG (rẻ hơn), không chuyển ngược lên.

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá trước hạn vẫn bị tính đủ phí — cần tính vào chi phí nếu video có thể bị người dùng xoá sớm.

Và một ràng buộc về thời gian chuyển đổi:

Object phải ở Standard ít nhất 30 NGÀY
    trước khi chuyển sang Standard-IA hoặc One Zone-IA

(Chuyển thẳng sang Glacier thì không có ràng buộc này.)

Lưu ý riêng cho video: cân nhắc kỹ trước khi chuyển sang Glacier.

Video ở Glacier Flexible Retrieval:
    → KHÔNG phát trực tiếp được
    → phải RESTORE trước (1 phút tới 12 giờ tuỳ chế độ)
    → người dùng bấm play sẽ không xem được ngay

Ba lựa chọn cho tình huống của đề: | Lựa chọn | Đặc điểm | |---|---| | Glacier Instant Retrieval | truy xuất MILI GIÂY, rẻ hơn Standard ~68% | | Standard-IA | truy xuất tức thì, rẻ hơn ~45%, có phí truy xuất | | Glacier Flexible / Deep Archive | rẻ nhất nhưng phải restore |

Với video cũ thỉnh thoảng vẫn có người xem, Glacier Instant Retrieval thường là lựa chọn đúng hơn Glacier Flexible — nó giữ được trải nghiệm phát ngay lập tức mà vẫn tiết kiệm phần lớn chi phí. (Lifecycle policy vẫn là đáp án đúng của câu hỏi; điều cần chọn kỹ là lớp ĐÍCH.)

S3 Intelligent-Tiering là lựa chọn thay thế đáng cân nhắc: | | Lifecycle rule | Intelligent-Tiering | |---|---|---| | Quyết định chuyển tầng | theo TUỔI | theo MẪU TRUY CẬP thực tế | | Phù hợp | quy luật rõ ràng ← câu này | mẫu truy cập khó đoán | | Phí truy xuất | có (ở IA và Glacier) | KHÔNG | | Phí giám sát | không | nhỏ, theo object |

Với video, Intelligent-Tiering có một ưu điểm lớn: không có phí truy xuất — nên một video cũ bất ngờ lan truyền trở lại không tạo ra hoá đơn bất ngờ.

Và một lời khuyên: dùng S3 Storage Class Analysis để đo mẫu truy cập thật trước khi chốt con số ngày. Nó cho biết video thực sự ngừng được xem sau bao lâu, thay vì đoán ba tháng rồi phải trả phí truy xuất vì chuyển quá sớm.

Đáp án

D và E.

• E — eu-east-2a: 3 instance, eu-east-2b: 3 instance, eu-east-2c: 3 instance
• D — eu-east-2a: 6 instance, eu-east-2b: 6 instance, eu-east-2c: 0 instance

Vì sao đúng

Đề yêu cầu luôn có 6 instance chạy, và phải chịu lỗi 100% khi MỘT AZ bất kỳ không dùng được.

Kiểm tra từng phương án — mất AZ có nhiều máy nhất là trường hợp xấu nhất:

E. 3 + 3 + 3 = 9 máy
   Mất bất kỳ AZ nào → còn 6 máy   ✅ ĐỦ

D. 6 + 6 + 0 = 12 máy
   Mất 2a → còn 6 máy              ✅
   Mất 2b → còn 6 máy              ✅
   Mất 2c → còn 12 máy             ✅ ĐỦ trong mọi trường hợp

A. 2 + 4 + 2 = 8 máy
   Mất 2b (có 4 máy) → còn 4 máy   ✗ thiếu 2

B. 2 + 2 + 2 = 6 máy
   Mất bất kỳ AZ nào → còn 4 máy   ✗ thiếu 2

C. 4 + 2 + 2 = 8 máy
   Mất 2a (có 4 máy) → còn 4 máy   ✗ thiếu 2

Quy tắc kiểm tra: lấy TỔNG trừ đi AZ ĐÔNG NHẤT, kết quả phải ≥ số máy yêu cầu.

Phương án A và C là bẫy tinh vi: chúng có tổng 8 máy — nhiều hơn 6 — nhưng phân bố không đều, nên mất đúng AZ đông nhất là thiếu.

Vì sao các phương án khác sai

• **C. 4 + 2 + 2 — đây là phương án gần nhất về tổng số máy (8 máy, dư 2), nhưng phân bố lệch: AZ 2a chứa 4 máy, mất nó thì chỉ còn 4. Chịu lỗi phụ thuộc vào AZ ĐÔNG NHẤT, không phải vào tổng số.
• **A. 2 + 4 + 2 — cùng lỗi, chỉ đổi AZ nào bị dồn máy.
• **B. 2 + 2 + 2 = đúng 6 máy — không có dự phòng nào: phân bố đều nhưng tổng chỉ vừa đủ, mất một AZ là thiếu ngay.

Ghi nhớ

Công thức chịu lỗi khi mất một AZ:

Số máy còn lại (xấu nhất) = TỔNG − (số máy ở AZ ĐÔNG NHẤT)
    → phải ≥ N (số máy yêu cầu)

Với K AZ và phân bố ĐỀU, số máy mỗi AZ:

ceil( N / (K − 1) )

N = 6, K = 3 → ceil(6/2) = 3 máy mỗi AZ → tổng 9
N = 6, K = 2 → ceil(6/1) = 6 máy mỗi AZ → tổng 12

Bảng tra nhanh — cần N máy, chịu được mất 1 AZ: | Cần | 2 AZ | 3 AZ | 4 AZ | |---|---|---|---| | 4 máy | 8 | 6 | 8 | | 6 máy | 12 ← D | 9 ← E | 8 | | 8 máy | 16 | 12 | 12 | | 9 máy | 18 | 15 | 12 |

Cả D và E đều đúng về mặt chịu lỗi, nhưng E rẻ hơn 25% (9 máy so với 12). Nếu đề hỏi thêm "cost-effective" thì chỉ E là đáp án.

Đây là bài học thiết kế quan trọng: dùng NHIỀU AZ hơn thì cần ÍT máy dự phòng hơn.

2 AZ: mỗi AZ phải gánh được TOÀN BỘ tải khi AZ kia sập → dự phòng 100%
3 AZ: mỗi AZ chỉ gánh thêm một nửa phần của AZ mất → dự phòng 50%
4 AZ: dự phòng ~33%

Ba cấu hình Auto Scaling group cho phương án E: | Cấu hình | Giá trị | |---|---| | MinSize | 9 | | DesiredCapacity | 9 | | Subnet | ba subnet ở ba AZ khác nhau |

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-thuong-mai-dien-tu   --min-size 9 --desired-capacity 9 --max-size 18   --vpc-zone-identifier "subnet-2a,subnet-2b,subnet-2c"   --health-check-type ELB --health-check-grace-period 300

ASG tự phân bổ đều giữa các AZ đã khai — bạn không phải chỉ định số máy cho từng AZ.

Ba cơ chế của ASG hỗ trợ chịu lỗi AZ: | Cơ chế | Việc | |---|---| | Phân bổ đều khi khởi chạy | ưu tiên AZ đang có ít instance nhất | | AZ Rebalancing | tự cân bằng lại sau khi một AZ phục hồi | | Tự thay instance hỏng | duy trì DesiredCapacity |

Lưu ý về AZ Rebalancing: nó khởi chạy máy mới TRƯỚC rồi mới chấm dứt máy thừa, nên trong quá trình cân bằng dung lượng có thể tạm vượt DesiredCapacity — hãy đặt MaxSize đủ chỗ.

Ba yếu tố khác cần cân nhắc mà câu hỏi không nhắc tới: | Yếu tố | Chi tiết | |---|---| | Database phải Multi-AZ | tầng web chịu lỗi mà database một AZ là vô nghĩa | | NAT Gateway mỗi AZ | một NAT dùng chung là điểm hỏng đơn | | Phí truyền dữ liệu giữa các AZ | ~0,01 USD/GB mỗi chiều — đáng kể với lưu lượng lớn |

Dòng cuối là đánh đổi thực tế của kiến trúc nhiều AZ: mỗi lần web server ở AZ này gọi database ở AZ khác đều tốn tiền. Với ứng dụng thương mại điện tử lưu lượng lớn, khoản này có thể vượt cả chi phí instance — nên hãy cân nhắc đặt read replica ở mỗi AZ nếu truy vấn đọc chiếm phần lớn.

Và một lưu ý về khả năng dung lượng: khi một AZ thực sự sập, mọi khách hàng AWS trong Region đó cùng lúc cố khởi chạy instance ở các AZ còn lại. Đó là lý do nên dựng sẵn đủ máy thay vì trông chờ ASG mở rộng kịp lúc — đúng như cả hai phương án D và E đều làm.

Đáp án

A — Tạo một Amazon Kinesis Data Stream để thu thập thông điệp.

Vì sao đúng

Đề nêu ba yêu cầu, và Kinesis Data Streams là lựa chọn khớp nhất trong bốn phương án: | Yêu cầu | Cơ chế | |---|---| | KHÔNG được mất thông điệp nào | giữ dữ liệu 1–365 ngày, phát lại được | | Xử lý trong EMR ĐÚNG THỨ TỰ đến | thứ tự được đảm bảo TRONG mỗi shard | | Hàng nghìn thông điệp mỗi ngày | mỗi shard chịu 1.000 bản ghi/giây |

Cách Kinesis đảm bảo thứ tự:

Bản ghi được đưa vào shard theo PARTITION KEY
    → cùng partition key → cùng shard
    → trong một shard, bản ghi giữ nguyên THỨ TỰ ghi vào
    → consumer đọc tuần tự theo sequence number

Muốn thứ tự tuyệt đối cho toàn bộ luồng thì dùng MỘT shard; muốn thông lượng cao hơn thì chọn partition key sao cho các nhóm cần giữ thứ tự nằm cùng shard.

Và khả năng phát lại là thứ đảm bảo "không mất thông điệp":

EMR xử lý lỗi giữa chừng
    → bản ghi VẪN CÒN trong stream (tới hết thời gian giữ)
    → đọc lại từ checkpoint, không mất gì

Và Kinesis tích hợp sẵn với EMR qua Spark Streaming hoặc thư viện KCL.

Vì sao các phương án khác sai

• **B. Dùng SQS queue MẶC ĐỊNH (standard) — đây là phương án gần nhất và cũng là hàng đợi tin cậy, nhưng standard queue vi phạm HAI trong ba yêu cầu: nó giao ít nhất một lần (có thể TRÙNG LẶP) và KHÔNG đảm bảo thứ tự. (SQS FIFO thì đáp ứng được, nhưng đề ghi rõ là queue mặc định.)
• **C. Dùng SNS Topic — sai mô hình: SNS là phát tán (pub/sub), nó đẩy thông điệp tới người đăng ký chứ không giữ lại để xử lý theo thứ tự. Không có cơ chế phát lại, và EMR không phải đích đăng ký của SNS.
• **D. Dùng Data Firehose — không giữ được thứ tự và không phát lại được: Firehose gom bản ghi theo lô rồi giao vào S3 hoặc Redshift. Nó không có cơ chế phát lại, và thứ tự trong tệp đầu ra không được đảm bảo.

Ghi nhớ về chất lượng câu hỏi

Đề đòi "no duplicates are produced", và Kinesis Data Streams không đảm bảo tuyệt đối điều đó. Kinesis là hệ thống ít nhất một lần (at-least-once):

Producer thử lại khi mạng lỗi → bản ghi có thể vào stream hai lần
Consumer khởi động lại        → có thể xử lý lại bản ghi đã xử lý

Dịch vụ AWS duy nhất đảm bảo xử lý CHÍNH XÁC MỘT LẦN là SQS FIFO — nhưng phương án B ghi rõ "default queue" (tức standard), nên nó bị loại vì lý do khác. Trong bốn lựa chọn có sẵn, Kinesis vẫn là câu trả lời đúng.

Trong thực tế, cách xử lý là làm cho consumer IDEMPOTENT — mỗi bản ghi mang một mã định danh, và consumer bỏ qua mã đã xử lý.

Ghi nhớ

Bốn dịch vụ nhắn tin của AWS — bảng phân biệt: | | Kinesis Data Streams | SQS Standard | SQS FIFO | SNS | |---|---|---|---|---| | Thứ tự | ✅ trong shard | ❌ | ✅ trong message group | ❌ | | Trùng lặp | có thể | có thể | ❌ không (5 phút) | có thể | | Phát lại | ✅ 1–365 ngày | ❌ (xoá sau khi đọc) | ❌ | ❌ | | Nhiều consumer độc lập | ✅ | ❌ (một thông điệp một người đọc) | ❌ | ✅ fan-out | | Thông lượng | rất cao | không giới hạn | 300–3.000 TPS | rất cao |

Từ khoá nhận diện trong đề thi:

"replay", "multiple consumers", "real-time streaming", "order within shard" → Kinesis Data Streams "exactly-once", "strict FIFO ordering", "no duplicates" → SQS FIFO "fan-out", "notify multiple subscribers" → SNS "deliver to S3/Redshift, no code" → Firehose

Ba khái niệm của Kinesis Data Streams: | Khái niệm | Ý nghĩa | |---|---| | Shard | đơn vị thông lượng: 1 MB/giây ghi, 2 MB/giây đọc | | Partition key | quyết định bản ghi vào shard nào | | Sequence number | thứ tự bản ghi trong shard |

Chọn partition key là quyết định thiết kế quan trọng nhất:

Partition key = một giá trị cố định
    → mọi bản ghi vào MỘT shard
    → thứ tự tuyệt đối, nhưng thông lượng giới hạn ở 1 shard

Partition key = ID người dùng
    → thứ tự được giữ CHO TỪNG NGƯỜI DÙNG
    → thông lượng phân tán qua nhiều shard  ← thường là lựa chọn đúng

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | khai số shard, rẻ hơn khi tải ổn định | | On-demand | tự mở rộng tới 200 MB/giây, không phải tính shard |

Với "hàng nghìn thông điệp mỗi ngày" như đề mô tả, một shard là quá đủ — thậm chí rất thừa, vì một shard chịu được 1.000 bản ghi mỗi giây.

Ba metric cần theo dõi: | Metric | Cảnh báo khi | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — nguy cơ mất dữ liệu khi hết hạn giữ | | WriteProvisionedThroughputExceeded | thiếu shard | | ReadProvisionedThroughputExceeded | quá nhiều consumer standard |

Và một lưu ý về kiến trúc trong đề: với khối lượng chỉ hàng nghìn thông điệp mỗi ngày, EMR là công cụ khá nặng. Một cụm Hadoop cho lượng dữ liệu đó là quá mức — Lambda đọc từ Kinesis rồi ghi kết quả vào S3 hoặc DynamoDB sẽ đơn giản và rẻ hơn nhiều. EMR chỉ xứng đáng khi khối lượng tăng lên hàng triệu bản ghi hoặc khi việc xử lý thực sự cần Spark.

Đáp án

B — Dùng AWS Certificate Manager (ACM) để cấp chứng chỉ SSL/TLS công khai và gắn vào HTTPS listener của các ALB.

Vì sao đúng

Đề nêu hai yêu cầu, và ACM đáp ứng cả hai một cách tối ưu: | Yêu cầu | Cơ chế | |---|---| | Chứng chỉ được TIN CẬY CÔNG KHAI | ACM là CA công khai được mọi trình duyệt tin | | ÍT CÔNG VẬN HÀNH NHẤT | miễn phí, tự động gia hạn, tích hợp sẵn với ALB |

Bốn lợi ích của ACM: | Lợi ích | Chi tiết | |---|---| | Miễn phí cho tài nguyên AWS | không tốn đồng nào | | TỰ ĐỘNG GIA HẠN | không bao giờ hết hạn bất ngờ | | Tích hợp một cú nhấp với ALB | không phải tải lên hay cài đặt | | Khoá riêng không bao giờ rời khỏi AWS | an toàn hơn tự quản lý |

Vế "tự động gia hạn" là lợi ích lớn nhất về mặt vận hành:

Chứng chỉ tự quản lý:
    → hết hạn sau 90 ngày (Let's Encrypt) hoặc 1 năm
    → phải nhớ gia hạn, phải triển khai lại
    → QUÊN = website báo lỗi bảo mật, người dùng bỏ đi
    → và đề nói có NHIỀU ứng dụng, mỗi cái một tên miền

ACM:
    → tự gia hạn trước khi hết hạn
    → tự cập nhật vào ALB
    → không ai phải làm gì

Cấp chứng chỉ với xác thực bằng DNS:

aws acm request-certificate --domain-name ung-dung-mot.com   --subject-alternative-names "*.ung-dung-mot.com"   --validation-method DNS

Và với nhiều tên miền như đề mô tả, ALB hỗ trợ SNI — gắn tới 25 chứng chỉ vào cùng một listener 443, mỗi tên miền một chứng chỉ.

Vì sao các phương án khác sai

• **A. Tự dựng CA bằng Let's Encrypt trên một EC2 instance và sinh chứng chỉ bằng certbot — đây là phương án gần nhất và cũng cho chứng chỉ được tin cậy công khai, nhưng nó nhiều công hơn hẳn: phải duy trì một máy chủ, viết tự động hoá cho certbot, xử lý gia hạn mỗi 90 ngày, và triển khai lại lên ALB mỗi lần. (Ngoài ra Let's Encrypt là CA bên ngoài — bạn không "dựng CA" mà chỉ dùng client của họ.)
• **C. Dùng OpenSSL sinh chứng chỉ TỰ KÝ rồi nhập vào ACM — vi phạm yêu cầu cốt lõi: chứng chỉ tự ký KHÔNG được trình duyệt tin cậy. Người dùng sẽ thấy cảnh báo bảo mật đỏ. Đề yêu cầu "publicly trusted".
• **D. Cấp chứng chỉ bằng ACM Private Certificate Authority — sai loại CA: ACM Private CA cấp chứng chỉ cho mạng NỘI BỘ, và chúng không được trình duyệt công cộng tin cậy trừ khi bạn cài root CA vào từng máy. Ngoài ra Private CA còn tốn khoảng 400 USD mỗi tháng.

Ghi nhớ

Chứng chỉ công khai và chứng chỉ riêng — phân biệt: | | ACM Public Certificate | ACM Private CA | |---|---|---| | Trình duyệt tin cậy | ✅ mặc định | ❌ phải cài root CA | | Chi phí | MIỄN PHÍ | ~400 USD/tháng + phí mỗi chứng chỉ | | Dùng cho | website công cộng ← câu này | dịch vụ nội bộ, IoT, mTLS | | Xác thực sở hữu tên miền | bắt buộc (DNS hoặc email) | không cần |

Hai cách xác thực của ACM: | Cách | Đặc điểm | |---|---| | DNS validation | thêm bản ghi CNAME MỘT LẦN → tự gia hạn VĨNH VIỄN | | Email validation | phải bấm link xác nhận mỗi lần gia hạn |

DNS validation là lựa chọn đúng gần như luôn luôn — nó là điều kiện để tự động gia hạn hoạt động. Và nếu tên miền nằm trong Route 53, ACM tạo bản ghi giúp bạn chỉ bằng một nút bấm.

Giới hạn Region của ACM — chi tiết hay gây lỗi: | Dùng cho | Chứng chỉ phải ở | |---|---| | ALB, NLB, API Gateway (regional) | CÙNG Region với tài nguyên | | CloudFront | BẮT BUỘC us-east-1 | | API Gateway (edge-optimized) | BẮT BUỘC us-east-1 |

Dòng thứ hai là lỗi rất phổ biến: cấp chứng chỉ ở Region của ứng dụng rồi không thấy nó trong danh sách chọn của CloudFront.

Ba cách phục vụ nhiều tên miền qua HTTPS: | Cách | Thêm tên miền mới | |---|---| | Wildcard (*.example.com) | không cần làm gì (nếu là subdomain) | | SAN (nhiều tên trong một chứng chỉ) | phải cấp lại chứng chỉ | | SNI (nhiều chứng chỉ, một listener) | chỉ thêm chứng chỉ mới |

Với "mỗi ứng dụng có tên miền riêng" như đề mô tả, SNI là mô hình phù hợp:

aws elbv2 add-listener-certificates --listener-arn <arn>   --certificates CertificateArn=<arn-chung-chi-moi>

Ba cấu hình HTTPS nên có cho ALB: | Cấu hình | Lý do | |---|---| | Chuyển hướng HTTP → HTTPS (301) | cấu hình ngay trên listener cổng 80 | | Chính sách bảo mật TLS hiện đại | ELBSecurityPolicy-TLS13-1-2-2021-06 | | Bật HSTS ở tầng ứng dụng | trình duyệt tự dùng HTTPS từ lần sau |

Ba giới hạn của ACM cần biết: | Giới hạn | Chi tiết | |---|---| | Không XUẤT được khoá riêng của chứng chỉ công khai | không dùng được ngoài AWS | | Chỉ gắn được vào dịch vụ AWS tích hợp | ALB, CloudFront, API Gateway, App Runner... | | Không gắn trực tiếp vào EC2 | phải nhập chứng chỉ vào máy theo cách thủ công |

Dòng cuối đáng nhớ: nếu cần chứng chỉ chạy trực tiếp trên web server của EC2 (Nginx, Apache), ACM public certificate không dùng được — khi đó Let's Encrypt hoặc mua chứng chỉ từ CA khác mới là lựa chọn. Trong đề này ứng dụng nằm sau ALB nên ACM hoàn toàn phù hợp.

Và một lời khuyên vận hành: đặt CloudWatch alarm cho metric DaysToExpiry của ACM. Tự động gia hạn hoạt động rất tin cậy, nhưng nó thất bại lặng lẽ nếu bản ghi CNAME xác thực bị xoá — và alarm là thứ duy nhất báo cho bạn trước khi chứng chỉ hết hạn thật.

Đáp án

C — Bật DynamoDB Streams để bắt hoạt động của bảng và tự động kích hoạt Lambda function.

Vì sao đúng

Đề cần phát hiện bản ghi mới trong DynamoDB rồi gọi Lambda, với thay đổi kiến trúc TỐI THIỂU — và DynamoDB Streams là tính năng gốc cho đúng việc đó.

Cách hoạt động:

Ghi vào bảng DynamoDB (INSERT, MODIFY, REMOVE)
    ↓
DynamoDB Streams ghi lại thay đổi theo THỨ TỰ, giữ 24 GIỜ
    ↓
Lambda event source mapping poll stream
    ↓
Gọi hàm với LÔ bản ghi thay đổi

Và "minimal configuration change" được đáp ứng hoàn toàn:

KHÔNG sửa ứng dụng ECS đang ghi dữ liệu
KHÔNG thêm dịch vụ trung gian nào
Chỉ cần:
    ① Bật Streams trên bảng
    ② Tạo event source mapping cho Lambda

aws dynamodb update-table --table-name bang-du-lieu-tai-chinh   --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws lambda create-event-source-mapping   --function-name kiem-tra-du-lieu   --event-source-arn <arn-cua-stream>   --starting-position LATEST --batch-size 100

Hàm Lambda nhận sự kiện có dạng:

def lambda_handler(event, context):
    for ban_ghi in event['Records']:
        if ban_ghi['eventName'] == 'INSERT':
            du_lieu_moi = ban_ghi['dynamodb']['NewImage']
            kiem_tra(du_lieu_moi)

Vì sao các phương án khác sai

• **B. Gọi Lambda qua SNS mỗi khi cụm ECS xử lý xong dữ liệu — đây là phương án gần nhất và hoạt động được, nhưng nó đòi SỬA MÃ ỨNG DỤNG ECS để phát thông báo SNS sau mỗi lần ghi. Đề yêu cầu "minimal configuration change to your architecture". Và nó tạo ra rủi ro sai lệch: nếu ghi vào DynamoDB thành công mà gửi SNS thất bại, việc kiểm tra bị bỏ sót.
• **A. Dùng CloudWatch Alarms để kích hoạt Lambda khi có bản ghi mới — CloudWatch không nhìn thấy từng bản ghi: nó thu thập metric tổng hợp (số request, độ trễ, dung lượng tiêu thụ). Không có metric nào báo "có một item mới với nội dung X".
• **D. Dùng Systems Manager Automation để phát hiện bản ghi mới — sai vai trò dịch vụ: SSM Automation chạy các quy trình vận hành trên tài nguyên hạ tầng (vá lỗi, tạo AMI, khởi động lại máy). Nó không theo dõi thay đổi dữ liệu trong bảng.

Ghi nhớ

Bốn giá trị StreamViewType — chọn theo nhu cầu: | Giá trị | Bản ghi chứa | |---|---| | KEYS_ONLY | chỉ khoá chính | | NEW_IMAGE | item SAU khi thay đổi | | OLD_IMAGE | item TRƯỚC khi thay đổi | | NEW_AND_OLD_IMAGES | cả hai — cho phép SO SÁNH trước và sau |

NEW_AND_OLD_IMAGES là lựa chọn linh hoạt nhất và cũng là yêu cầu bắt buộc nếu sau này muốn bật Global Tables.

Ba loại sự kiện trong stream: | eventName | Nghĩa | |---|---| | INSERT | item mới ← đề quan tâm cái này | | MODIFY | item được cập nhật | | REMOVE | item bị xoá |

Ba đặc điểm của DynamoDB Streams: | Đặc điểm | Chi tiết | |---|---| | Giữ bản ghi 24 GIỜ | không cấu hình dài hơn được | | Thứ tự được đảm bảo cho mỗi khoá chính | các thay đổi của cùng một item luôn đúng thứ tự | | Chính xác một lần trong stream | mỗi thay đổi xuất hiện đúng một lần |

Giới hạn 24 giờ là điều cần lưu ý: nếu Lambda hỏng và không ai sửa trong một ngày, bản ghi sẽ mất vĩnh viễn. Hãy đặt alarm cho IteratorAge.

Bốn cấu hình quan trọng của event source mapping: | Cấu hình | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi (tới 10.000) | | MaximumBatchingWindowInSeconds | chờ gom thêm bản ghi (tới 300 giây) | | BisectBatchOnFunctionError | chia đôi lô khi lỗi để cô lập bản ghi hỏng | | DestinationConfig | gửi bản ghi hỏng sang SQS hoặc SNS |

Hai cấu hình cuối là bắt buộc trong thực tế:

Không có chúng:
    một bản ghi gây lỗi hàm
        → Lambda thử lại MÃI
        → CHẶN toàn bộ shard
        → không bản ghi nào phía sau được xử lý
        → tới khi bản ghi hỏng hết hạn 24 giờ

Đây là sự cố kinh điển với Lambda đọc stream.

DynamoDB Streams và Kinesis Data Streams for DynamoDB: | | DynamoDB Streams | Kinesis Data Streams for DynamoDB | |---|---|---| | Thời gian giữ | 24 giờ | tới 365 ngày | | Số consumer | 2 (khuyến nghị) | nhiều hơn, có enhanced fan-out | | Đảm bảo | chính xác một lần | ít nhất một lần | | Cấu hình | bật một công tắc | trỏ vào stream Kinesis |

Nếu cần giữ lâu hơn 24 giờ hoặc nhiều consumer, dùng bản Kinesis.

Ba ứng dụng điển hình của DynamoDB Streams: | Ứng dụng | Chi tiết | |---|---| | Kiểm tra và xác thực dữ liệu | ← câu này | | Đồng bộ sang hệ thống khác | OpenSearch, Redshift, cache | | Kiến trúc hướng sự kiện | gửi email, cập nhật bảng tổng hợp | | Global Tables | chính DynamoDB dùng Streams để sao chép giữa Region |

Và một lưu ý về chi phí: bản thân DynamoDB Streams tính phí theo số lời gọi đọc, nhưng phần Lambda poll stream thì không tính vào số lời gọi Lambda — bạn chỉ trả cho thời gian hàm thực sự chạy. Với hàng nghìn bản ghi mỗi ngày, chi phí gần như không đáng kể; hãy đặt BatchSize lớn để giảm số lần gọi hàm.

Đáp án

B — Thiết lập một AWS Transit Gateway ở mỗi Region để kết nối mọi mạng trong Region đó, rồi định tuyến giữa các Transit Gateway qua peering connection.

Vì sao đúng

Đề nêu bốn yêu cầu, và mô hình Transit Gateway đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Hàng trăm VPC, nhiều tài khoản | TGW là trung tâm hình sao — mỗi VPC một attachment | | Nhiều kết nối VPN tới trung tâm dữ liệu | VPN attachment gắn thẳng vào TGW | | Gộp tất cả vào MỘT gateway | đúng định nghĩa của Transit Gateway | | Hỗ trợ peering GIỮA CÁC REGION | inter-region TGW peering |

Vì sao mô hình hình sao là bắt buộc ở quy mô này:

VPC peering (lưới đầy đủ):
    100 VPC → 100 × 99 / 2 = 4.950 kết nối
        → mỗi kết nối cần route ở cả hai đầu
        → KHÔNG QUẢN LÝ NỔI

Transit Gateway:
    100 VPC → 100 attachment vào MỘT gateway
        → tuyến tính thay vì bậc hai

Và TGW peering nối các Region lại:

    Region 1              Region 2              Region 3
      TGW    ◀──peering──▶  TGW   ◀──peering──▶  TGW
       │                     │                     │
   VPC, VPN              VPC, VPN              VPC, VPN

Lưu lượng giữa các Region đi trên mạng xương sống của AWS, được mã hoá, không qua Internet công cộng.

Chia sẻ TGW giữa các tài khoản bằng AWS RAM:

aws ram create-resource-share --name chia-se-tgw   --resource-arns arn:aws:ec2:...:transit-gateway/tgw-0abc   --principals arn:aws:organizations::111122223333:organization/o-abc123

Vì sao các phương án khác sai

• **D. Bật inter-region VPC peering giữa các VPC ở nhiều Region — đây là phương án gần nhất và VPC peering xuyên Region là tính năng có thật, nhưng nó không mở rộng được: hàng trăm VPC nghĩa là hàng nghìn kết nối peering. Và peering KHÔNG hỗ trợ định tuyến bắc cầu — A peering B, B peering C thì A không tới C được. Nó cũng không gộp được VPN vào cùng một gateway.
• **A. Direct Connect Gateway với public virtual interface — hai lỗi: public VIF dùng để truy cập dịch vụ CÔNG KHAI của AWS (S3, DynamoDB qua địa chỉ công khai), không để vào VPC riêng tư — cái đó cần private VIF hoặc transit VIF. Và đề nói hạ tầng hiện tại dùng VPN, không phải Direct Connect.
• **C. AWS VPN CloudHub cho truy cập VPC xuyên Region — hiểu sai công cụ: CloudHub cho phép các CHI NHÁNH tại chỗ nói chuyện với nhau qua AWS, xoay quanh một virtual private gateway của một VPC. Nó không phải cơ chế kết nối hàng trăm VPC.

Ghi nhớ

Ba cách kết nối nhiều VPC — bảng chọn: | Cách | Bắc cầu | Quy mô | Chi phí | |---|---|---|---| | VPC Peering | ❌ KHÔNG | vài VPC | không phí xử lý dữ liệu | | Transit Gateway | ✅ CÓ | hàng trăm VPC | phí attachment + phí mỗi GB | | PrivateLink | — (chỉ phơi một dịch vụ) | nhiều người dùng dịch vụ | phí endpoint + phí mỗi GB |

Quy tắc chọn:

2–3 VPC → peering Nhiều VPC, nhiều tài khoản, cần bắc cầu → Transit Gateway Chỉ cần gọi một dịch vụ, không nối mạng → PrivateLink

Năm loại attachment của Transit Gateway: | Loại | Nối tới | |---|---| | VPC | VPC trong cùng Region | | VPN | kết nối site-to-site | | Direct Connect Gateway | kết nối DX | | Transit Gateway Peering | TGW ở Region KHÁC | | Connect | SD-WAN, thiết bị của bên thứ ba (GRE) |

Bốn đặc điểm quan trọng của TGW: | Đặc điểm | Chi tiết | |---|---| | Route table riêng cho từng attachment | phân tách lưu lượng — tách prod và dev | | Chia sẻ qua AWS RAM | dùng chung giữa các tài khoản | | Băng thông tới 50 Gbps mỗi VPC attachment | | | Multicast | hỗ trợ, khác với peering |

Route table riêng là tính năng quan trọng nhất cho tổ chức lớn:

Route table "san-xuat":  VPC prod thấy nhau và thấy mạng tại chỗ
Route table "phat-trien": VPC dev chỉ thấy nhau, KHÔNG thấy prod
    → cách ly môi trường ngay ở tầng định tuyến

Ba lưu ý về TGW peering xuyên Region: | Lưu ý | Chi tiết | |---|---| | KHÔNG bắc cầu qua peering | TGW-A peering TGW-B, TGW-B peering TGW-C → A KHÔNG tới C | | Route phải khai TĨNH | không tự lan truyền qua peering | | Lưu lượng được mã hoá tự động | đi trên mạng xương sống AWS |

Dòng đầu là hạn chế cần thiết kế quanh nó: với 5 Region như đề mô tả, nếu cần mọi Region nói chuyện với nhau thì phải tạo peering theo lưới đầy đủ giữa các TGW — 5 TGW cần 10 kết nối peering. Con số này vẫn quản lý được, khác hẳn 4.950 kết nối của VPC peering.

Ba loại virtual interface của Direct Connect — làm rõ vì phương án A nhắc tới: | Loại VIF | Dùng để | |---|---| | Private VIF | vào VPC riêng tư qua virtual private gateway | | Public VIF | truy cập dịch vụ CÔNG KHAI của AWS (S3, DynamoDB) | | Transit VIF | vào Transit Gateway — cho kiến trúc nhiều VPC |

Transit VIF là loại đúng khi kết hợp Direct Connect với Transit Gateway — đó là kiến trúc mà tổ chức trong đề nên hướng tới nếu sau này nâng cấp từ VPN lên DX.

Ba lưu ý về chi phí Transit Gateway: | Khoản | Chi tiết | |---|---| | Phí mỗi attachment mỗi giờ | hàng trăm VPC nghĩa là hàng trăm attachment | | Phí xử lý dữ liệu mỗi GB | thường lớn hơn phí attachment | | Phí truyền dữ liệu xuyên Region | tính riêng cho lưu lượng qua peering |

Với hàng trăm VPC, chi phí TGW là khoản đáng kể — nhưng so với công sức quản lý hàng nghìn kết nối peering thì vẫn là lựa chọn đúng. Với cặp VPC trao đổi lưu lượng rất lớn, cân nhắc thêm peering trực tiếp bên cạnh TGW để tránh phí xử lý dữ liệu.

Và một lời khuyên khi triển khai ở quy mô này: dùng AWS Network Manager để có cái nhìn toàn cảnh về mạng toàn cầu — nó trực quan hoá mọi TGW, attachment và kết nối, đồng thời giám sát trạng thái. Với hàng trăm VPC trải 5 Region, không có công cụ này thì việc chẩn đoán một sự cố định tuyến rất khó khăn.

Đáp án

A và E.

• A — Dùng Amazon S3 để lưu dữ liệu
• E — Cấu hình Server-Side Encryption với AWS KMS Keys (SSE-KMS)

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp S3 + SSE-KMS đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Truy cập HÀNG TUẦN | S3 Standard — truy xuất tức thì | | Mã hoá phong bì (envelope encryption) | KMS dùng đúng cơ chế này | | TỰ ĐỘNG xoay vòng khoá | KMS xoay khoá hằng năm, bật một công tắc | | Audit trail: ai dùng khoá, khi nào | CloudTrail ghi mọi lời gọi KMS |

Mã hoá phong bì — cơ chế mà đề nêu đích danh:

① KMS sinh một DATA KEY ngẫu nhiên
② Data key MÃ HOÁ dữ liệu thật (nhanh, làm tại chỗ)
③ CMK trong KMS mã hoá chính data key đó
④ Data key ĐÃ MÃ HOÁ được lưu kèm object
    → khoá gốc (CMK) KHÔNG BAO GIỜ rời khỏi KMS
    → dữ liệu lớn không phải gửi qua mạng tới KMS

Và audit trail là lý do quyết định loại SSE-S3:

CloudTrail ghi mỗi lời gọi Decrypt:
    - ai (principal)
    - khoá nào
    - object nào
    - lúc nào, từ IP nào
→ SSE-S3 KHÔNG cung cấp thông tin này

Bật xoay khoá tự động:

aws kms enable-key-rotation --key-id <id-khoa>

KMS tạo material khoá mới mỗi năm và giữ material cũ để giải mã dữ liệu đã mã hoá trước đó — hoàn toàn trong suốt với ứng dụng.

Vì sao các phương án khác sai

• **D. Cấu hình SSE-S3 — đây là phương án gần nhất và cũng dùng AES-256 với khoá được AWS xoay vòng, nhưng nó thiếu hai thứ đề đòi: không có audit trail cho biết ai đã dùng khoá, và bạn không kiểm soát chính sách khoá. Đề nói rõ cần "audit trail that shows who used the encryption key".
• **B. Dùng S3 Glacier Deep Archive — sai lớp lưu trữ: dữ liệu được truy cập hằng tuần, mà Deep Archive mất 12–48 giờ để lấy ra. Và nó có ràng buộc lưu tối thiểu 180 ngày.
• **C. Cấu hình SSE-C (khoá do khách hàng cung cấp) — đẩy hết gánh nặng sang bạn: bạn phải tự quản lý, tự lưu, tự xoay vòng khoá và gửi khoá theo mỗi request. Không có xoay vòng tự động, không có audit trail của AWS.

Ghi nhớ

Bốn cách mã hoá S3 — bảng cần thuộc: | Cách | Ai quản lý khoá | Xoay vòng tự động | Audit ai giải mã | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ✅ (AWS lo, bạn không điều khiển) | ❌ | | SSE-KMS | AWS KMS, bạn kiểm soát policy | ✅ bật được, hằng năm | ✅ CloudTrail | | SSE-C | BẠN — gửi theo mỗi request | ❌ bạn tự lo | ❌ | | Client-side | BẠN hoàn toàn | ❌ | ❌ |

Ba từ khoá nhận diện SSE-KMS trong đề thi:

"envelope encryption"       → KMS
"audit trail" / "who used"  → KMS + CloudTrail
"automatic key rotation"    → KMS

Đề này có đủ cả ba.

Ba loại khoá trong KMS: | Loại | Đặc điểm | |---|---| | AWS managed key (aws/s3) | miễn phí lưu, KHÔNG đổi được policy, xoay hằng năm | | Customer managed key (CMK) | ~1 USD/tháng, KIỂM SOÁT ĐẦY ĐỦ policy và xoay vòng | | AWS owned key | AWS dùng nội bộ, bạn không thấy |

Đề đòi kiểm soát và audit nên cần customer managed key — khoá do AWS quản lý không cho bạn đặt key policy.

Chi phí KMS — cần cân nhắc:

Lưu khoá:          ~1 USD mỗi khoá mỗi tháng
Lời gọi API:       ~0,03 USD mỗi 10.000 lời gọi

Với dữ liệu truy cập hằng tuần như đề mô tả, số lời gọi thấp nên chi phí không đáng kể. Nhưng với ứng dụng đọc hàng triệu object mỗi ngày, khoản này lớn nhanh.

Và có cách giảm mạnh chi phí đó: S3 Bucket Keys.

aws s3api put-bucket-encryption --bucket kho-tai-chinh   --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

Nó dùng một khoá cấp bucket để giảm tới 99% số lời gọi KMS — nên bật cho mọi bucket dùng SSE-KMS.

Ba lớp S3 phù hợp với truy cập hằng tuần: | Lớp | Đặc điểm | |---|---| | S3 Standard | truy xuất tức thì, không phí truy xuất ← câu này | | S3 Standard-IA | rẻ hơn ~45% nhưng CÓ phí truy xuất mỗi GB | | S3 Intelligent-Tiering | tự chuyển tầng, không phí truy xuất |

Với truy cập hằng tuần, Standard-IA có thể rẻ hơn hoặc đắt hơn tuỳ khối lượng đọc — phí truy xuất (~0,01 USD/GB) tích tụ nếu đọc nhiều. Intelligent-Tiering là lựa chọn an toàn khi không chắc.

Ba thực hành tốt cho bucket dữ liệu tài chính: | Thực hành | Cấu hình | |---|---| | Bắt buộc mã hoá bằng bucket policy | chặn PutObject không có header aws:kms | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | Bật Block Public Access ở mức tài khoản | ngăn cấu hình sai | | Bật CloudTrail data event cho bucket | ghi mọi thao tác object-level |

Chính sách bắt buộc mã hoá KMS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-tai-chinh/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Và một lưu ý về key policy — thứ mà nhiều người bỏ qua: quyền dùng khoá KMS được quyết định bởi CẢ key policy LẪN IAM policy. Cấp kms:Decrypt trong IAM là chưa đủ nếu key policy không cho phép principal đó. Đây là nguyên nhân phổ biến nhất của lỗi AccessDenied khi làm việc với SSE-KMS.

Đáp án

D — Tích hợp CloudFront với Lambda@Edge để xử lý dữ liệu gần người dùng và phản hồi với độ trễ thấp; xử lý luồng dữ liệu thời gian thực bằng Kinesis rồi lưu kết quả vào S3.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này giải đúng cả ba: | Yêu cầu | Cơ chế | |---|---| | XỬ LÝ dữ liệu gần người dùng về mặt địa lý | Lambda@Edge chạy MÃ tại điểm biên | | Phản hồi request với độ trễ thấp | CloudFront + xử lý tại biên | | Xử lý luồng thời gian thực, lưu bền vững | Kinesis → S3 |

Điểm mấu chốt là động từ "PROCESS" (xử lý), không phải "deliver" (phân phối):

CloudFront thuần:
    → CACHE và PHÂN PHỐI nội dung
    → KHÔNG chạy logic nào

CloudFront + Lambda@Edge:
    → CHẠY MÃ tại hơn 600 điểm biên
    → xử lý, biến đổi, xác thực, định tuyến ngay tại đó
    → người dùng ở Tokyo được xử lý ở Tokyo

Và với phân tích clickstream mà đề mô tả, Lambda@Edge làm được:

Người dùng nhấp chuột
    ↓
Lambda@Edge tại điểm biên gần nhất:
    - làm giàu dữ liệu (thêm vị trí, loại thiết bị)
    - lọc bỏ bot
    - đẩy vào Kinesis
    ↓ (độ trễ thấp — không phải đi về Region gốc)
Kinesis Data Streams xử lý thời gian thực
    ↓
S3 lưu kết quả bền vững

Route 53 không giải quyết được vế "xử lý" — nó chỉ trả lời truy vấn DNS, quyết định người dùng được gửi tới đâu. Đó là lý do hai phương án dùng Route 53 đều thiếu.

Vì sao các phương án khác sai

• **C. CloudFront + Route 53 với Geoproximity routing; xử lý bằng Kinesis và lưu vào S3 — đây là phương án gần nhất và có phần Kinesis + S3 hoàn toàn đúng, nhưng nó thiếu ở phần xử lý: Route 53 chỉ ĐỊNH TUYẾN, không XỬ LÝ. Nó gửi người dùng tới một endpoint, còn việc xử lý vẫn diễn ra ở Region gốc — không "gần người dùng" như đề đòi.
• **A. CloudFront + Route 53 latency-based routing; Kinesis và S3 — cùng vấn đề: định tuyến theo độ trễ giúp chọn Region gần nhất, nhưng vẫn không có xử lý tại biên.
• **B. CloudFront + Lambda@Edge; xử lý luồng bằng Amazon Athena và lưu vào S3 — có phần Lambda@Edge đúng nhưng sai công cụ xử lý luồng: Athena là công cụ truy vấn SQL trên dữ liệu ĐÃ LƯU trong S3. Nó không xử lý luồng thời gian thực — dữ liệu phải nằm sẵn ở S3 rồi mới truy vấn được.

Ghi nhớ

Hai loại hàm chạy tại biên của CloudFront: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Ngôn ngữ | chỉ JavaScript | Node.js, Python | | Thời gian chạy tối đa | dưới 1 mili giây | 5 giây (viewer) / 30 giây (origin) | | Truy cập mạng | ❌ KHÔNG | ✅ gọi được dịch vụ khác | | Truy cập body của request | ❌ | ✅ | | Vị trí chạy | hơn 600 điểm biên | 13 Regional Edge Cache | | Chi phí | rẻ hơn ~6 lần | cao hơn | | Phù hợp | viết lại URL, header đơn giản | logic phức tạp, gọi API, đẩy dữ liệu |

Đề cần đẩy dữ liệu vào Kinesis — tức là gọi dịch vụ khác — nên phải dùng Lambda@Edge, CloudFront Functions không làm được.

Bốn thời điểm kích hoạt Lambda@Edge: | Trigger | Khi nào chạy | |---|---| | Viewer Request | ngay khi nhận request từ người dùng — TRƯỚC khi kiểm tra cache | | Origin Request | trước khi gọi origin (chỉ khi cache miss) | | Origin Response | sau khi nhận phản hồi từ origin | | Viewer Response | ngay trước khi trả về người dùng |

Với thu thập clickstream, Viewer Request là trigger đúng — nó chạy cho mọi request kể cả khi cache hit, nên không bỏ sót sự kiện nào.

Bảy chính sách định tuyến của Route 53 — để phân biệt với phương án A và C: | Chính sách | Việc | |---|---| | Latency-based | tới Region có độ trễ thấp nhất | | Geolocation | theo vị trí của người dùng | | Geoproximity | theo khoảng cách, có bias điều chỉnh được | | Weighted | chia theo tỷ lệ | | Failover | primary/secondary | | Multivalue | tới 8 bản ghi lành mạnh | | Simple | một bản ghi |

Cả bảy đều chỉ trả lời câu hỏi "gửi người dùng tới đâu" — không cái nào xử lý dữ liệu.

Ba công cụ xử lý dữ liệu — đừng nhầm: | Công cụ | Xử lý | |---|---| | Kinesis Data Streams | LUỒNG thời gian thực, độ trễ mili giây | | Athena | dữ liệu ĐÃ LƯU trong S3, truy vấn SQL | | EMR | dữ liệu lớn theo lô hoặc luồng, cụm Spark/Hadoop |

Kiến trúc clickstream đầy đủ trong thực tế:

Lambda@Edge → Kinesis Data Streams
                  ├─▶ Kinesis Data Firehose → S3 (lưu trữ, phân tích sau)
                  └─▶ Managed Service for Apache Flink (phân tích thời gian thực)
                            ↓
                      Dashboard, cảnh báo

Ba lưu ý khi dùng Lambda@Edge: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC tạo hàm ở us-east-1 | CloudFront tự nhân bản ra các điểm | | Không dùng được biến môi trường | phải nhúng cấu hình vào mã | | Giới hạn kích thước gói nhỏ hơn Lambda thường | 1 MB (viewer) / 50 MB (origin) | | Triển khai mất vài phút | phải nhân bản ra toàn cầu |

Dòng đầu là lỗi triển khai phổ biến nhất — tạo hàm ở Region khác thì không gắn được vào CloudFront distribution.

Và một lưu ý về chi phí: Lambda@Edge tính phí theo số lời gọi và thời gian chạy, và nó chạy cho mọi request khi gắn vào Viewer Request. Với trang có hàng chục triệu lượt xem, khoản này đáng kể — hãy cân nhắc gắn vào Origin Request nếu logic không cần chạy trên request đã cache, hoặc dùng CloudFront Functions cho phần logic đơn giản.

Đáp án

C — Bật Amazon RDS Read Replicas.

Vì sao đúng

Đề nêu hai yêu cầu, và read replica đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Tăng THÔNG LƯỢNG ĐỌC | mỗi replica phục vụ truy vấn đọc riêng | | Giao dịch phải tuân thủ ACID | MySQL trên RDS vẫn là cơ sở dữ liệu quan hệ ACID |

Cách read replica mở rộng khả năng đọc:

Một DB instance có giới hạn CPU, bộ nhớ, IOPS
    ↓
Thêm read replica (tối đa 5 với RDS MySQL, 15 với Aurora)
    → mỗi replica có tài nguyên riêng
    → tổng khả năng đọc TĂNG THEO SỐ REPLICA
    → primary được giải phóng để lo việc ghi

Và sao chép bất đồng bộ nghĩa là tạo replica không làm chậm primary:

Primary ghi xong → TRẢ LỜI CLIENT NGAY
                → sao chép sang replica ở nền

Với trang tin toàn cầu như đề mô tả, còn có thể đặt replica ở nhiều Region:

Replica ở Region gần độc giả
    → độ trễ đọc thấp hơn nhiều
    → và là bản dự phòng cho phục hồi thảm hoạ

Vế "ACID" trong đề là để loại phương án hàng đợi và để khẳng định không cần chuyển sang NoSQL — bản thân việc thêm replica không ảnh hưởng tới tính chất ACID của giao dịch trên primary.

Vì sao các phương án khác sai

• **A. Bật Multi-AZ deployment — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về RDS: Multi-AZ là cơ chế SẴN SÀNG CAO, và standby instance KHÔNG phục vụ truy vấn nào. Nó chỉ ngồi chờ để tiếp quản khi primary hỏng. Bật Multi-AZ không tăng thông lượng đọc một chút nào.
• **B. Bật Amazon RDS Standby Replicas — tên gọi không tồn tại như một tính năng riêng: "standby" chính là instance dự phòng của Multi-AZ, và như trên, nó không phục vụ đọc.
• **D. Dùng SQS để xếp hàng các request — sai mô hình cho việc đọc: hàng đợi làm phẳng được đỉnh GHI, nhưng độc giả cần nội dung ngay lập tức — không thể bảo họ chờ trong hàng đợi. Và tổng khả năng đọc của database không tăng chút nào.

Ghi nhớ

Read replica và Multi-AZ — bảng phân biệt cốt lõi: | | Read replica | Multi-AZ | |---|---|---| | Mục đích | MỞ RỘNG ĐỌC | SẴN SÀNG CAO | | Instance thứ hai phục vụ truy vấn | ✅ CÓ endpoint riêng | ❌ KHÔNG BAO GIỜ | | Sao chép | bất đồng bộ | đồng bộ | | Failover | thủ công (promote) | tự động | | Vị trí | cùng AZ, khác AZ, hoặc khác Region | AZ khác cùng Region | | Số lượng | tối đa 5 (RDS MySQL) | 1 standby | | Ảnh hưởng độ trễ ghi | không | có — phải chờ standby xác nhận |

"Standby không phục vụ đọc" là điểm cần thuộc lòng — nó là bẫy xuất hiện rất thường xuyên trong đề thi.

Và chúng bổ sung nhau, kiến trúc sản xuất dùng cả hai:

Primary (Multi-AZ)  ──đồng bộ──▶  Standby        (chịu lỗi AZ)
      │
      └──bất đồng bộ──▶  Read replica × N        (mở rộng đọc)

Bốn công dụng của read replica: | Công dụng | Chi tiết | |---|---| | Gánh tải đọc của ứng dụng | ← câu này | | Tách truy vấn phân tích và báo cáo | không ảnh hưởng ứng dụng | | Replica xuyên Region | giảm độ trễ cho người dùng xa + phục hồi thảm hoạ | | Nâng cấp phiên bản có kiểm soát | promote replica đã nâng cấp |

Ba lưu ý khi dùng read replica: | Lưu ý | Chi tiết | |---|---| | Độ trễ sao chép (replica lag) | ứng dụng có thể đọc dữ liệu CŨ vài giây | | Ứng dụng phải tự tách endpoint đọc và ghi | RDS không tự làm | | Promote là thao tác MỘT CHIỀU | replica thành instance độc lập, không quay lại |

Dòng đầu là vấn đề thực tế lớn nhất: người dùng vừa đăng bình luận rồi tải lại trang, truy vấn vào replica chưa kịp đồng bộ và không thấy bình luận của chính mình. Giải pháp: đọc-sau-ghi phải trỏ vào primary, chỉ nội dung không nhạy cảm về độ mới mới đọc từ replica.

Metric cần đặt alarm: ReplicaLag — nếu độ trễ tăng cao, nguyên nhân thường là primary ghi quá nhiều, replica thiếu tài nguyên, hoặc có truy vấn dài đang chạy trên replica.

Aurora có ưu thế rõ rệt cho ca sử dụng này: | | RDS MySQL replica | Aurora replica | |---|---|---| | Cơ chế | sao chép qua binary log | CHIA SẺ chung tầng lưu trữ | | Độ trễ | giây | mili giây | | Số lượng | 5 | 15 | | Reader endpoint | không có | ✅ tự cân bằng tải giữa các replica | | Failover | thủ công | tự động dưới 30 giây |

Reader endpoint của Aurora là tiện ích đáng giá: ứng dụng chỉ cần một địa chỉ, Aurora tự phân phối truy vấn đọc — không phải tự viết logic cân bằng tải.

Và một lựa chọn nên thử TRƯỚC khi thêm replica: tầng cache.

Trang tin có mẫu truy cập rất thuận lợi cho cache:
    hàng triệu người đọc CÙNG một bài viết
        → ElastiCache trả lời từ bộ nhớ (microgiây)
        → cắt được phần lớn truy vấn với chi phí thấp hơn một replica

Ba tầng nên xem xét theo thứ tự cho trang tin toàn cầu: | Tầng | Cắt được gì | |---|---| | ① CloudFront | request không tới máy chủ ứng dụng | | ② ElastiCache | truy vấn không tới database | | ③ Read replica | phân tán phần tải đọc còn lại |

Tầng ngoài cùng luôn hiệu quả nhất về chi phí — nhưng read replica vẫn là đáp án đúng của câu hỏi vì đề hỏi cụ thể về việc "increase the read-throughput on the MySQL database".

Và một lưu ý về tuân thủ ACID: đọc từ read replica cho tính nhất quán cuối cùng, không phải nhất quán mạnh. Với trang tin thì hoàn toàn chấp nhận được; với giao dịch tài chính thì phải đọc từ primary.