Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả một quản trị viên đang viết tài liệu quy trình tạo EC2 instance qua Amazon EC2 API, và cần liệt kê những loại volume không dùng làm boot volume được. Toàn bộ phần nói về công ty bán lẻ, dữ liệu payroll của HR hay chuyện tạo instance bằng API chỉ là bối cảnh — không có ràng buộc kỹ thuật nào nằm ở đó.

Cụm từ quyết định đáp án là "CANNOT be used as boot volumes" kèm "(Select two)". Đây là câu hỏi phủ định: phải chọn thứ không làm được, chứ không phải thứ phù hợp nhất. Đọc lướt thành "which CAN be used" là chọn ngay gp2 và io1 — hai phương án nghe quen tai nhất — và sai cả hai. Con số "two" cũng là một chốt kiểm: trong danh sách chỉ có đúng hai loại HDD, nên nếu bạn định chọn ba thứ trở lên thì đã hiểu sai câu hỏi.

Ràng buộc thật sự nằm ở chỗ EBS chia làm hai nhóm: nhóm SSD-backed tối ưu cho workload giao dịch với I/O nhỏ, đọc/ghi thường xuyên, thước đo chính là IOPS; và nhóm HDD-backed tối ưu cho workload streaming khối lượng lớn, thước đo chính là throughput (MiB/s). Câu hỏi thực chất kiểm tra bạn có nhớ ranh giới giữa hai nhóm này và hệ quả của nó lên khả năng làm boot volume hay không.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là B — Cold HDD (sc1) và E — Throughput Optimized HDD (st1).

Đây chính là hai loại volume HDD-backed của EBS, và cả hai đều không được phép dùng làm boot volume cho EC2 instance. Lý do gắn với bản chất thiết kế của chúng: st1 và sc1 hướng tới việc đọc/ghi tuần tự khối lượng lớn — log processing, data warehouse, các kho dữ liệu ít truy cập — nên chúng cho throughput tốt nhưng IOPS thấp và độ trễ cao với các thao tác I/O nhỏ, ngẫu nhiên. Mà quá trình boot hệ điều hành lại đúng là kiểu tải I/O nhỏ và rải rác: đọc bootloader, nạp kernel, mở hàng loạt file cấu hình và thư viện nhỏ. AWS vì thế đặt hẳn giới hạn ở cấp dịch vụ, không cho gắn st1 và sc1 làm root device.

Trong hai loại này, sc1 (Cold HDD) là loại chi phí thấp nhất, dành cho dữ liệu truy cập không thường xuyên; st1 nhỉnh hơn về throughput. Nhưng khác biệt đó không quan trọng ở đây — chúng cùng nằm trong nhóm HDD nên cùng bị loại khỏi vai trò boot volume.

❌ Vì sao các phương án còn lại sai

A — General Purpose SSD (gp2): Sai vì gp2 dùng làm boot volume được, và trên thực tế đây là lựa chọn boot volume mặc định phổ biến nhất cho hầu hết instance. Nó thuộc nhóm SSD-backed, cân bằng giữa giá và hiệu năng IOPS, hợp với chính kiểu I/O nhỏ mà quá trình boot sinh ra. Phương án này chỉ hấp dẫn nếu bạn đọc nhầm đề thành câu hỏi thuận.

C — Provisioned IOPS SSD (io1): Sai vì cùng lý do với gp2 — io1 cũng là SSD-backed và hoàn toàn dùng được làm boot volume. io1 còn cho phép khai báo mức IOPS mong muốn, tức là nó nằm ở đầu bên kia của thang IOPS so với st1/sc1. Đây là phương án dễ bị chọn nhầm nhất nếu người học nhớ mang máng rằng io1 "dành cho database, chắc không phải để boot" — nhưng việc một loại volume thường được dùng cho mục đích khác không có nghĩa là nó bị cấm làm root device.

D — Instance Store: Đây là phương án gần đúng và bẫy nặng nhất, vì Instance Store có một điểm yếu rất nổi tiếng: dữ liệu ephemeral, mất sạch khi instance stop hoặc terminate. Người học dễ suy từ "dữ liệu không bền" ra "không thể làm boot volume". Nhưng hai chuyện đó tách bạch: AMI có hai kiểu root device, và instance store-backed AMI là một kiểu hợp lệ — instance boot thẳng từ instance store. Chỗ nó "hỏng" chỉ là tính bền vững và một số hạn chế vận hành (không stop rồi start lại như EBS-backed), chứ không phải là bị cấm boot. Đề hỏi cannot be used as boot volume, và Instance Store thì dùng được, nên D sai.

📌 Điểm cần nhớ

• Ranh giới cần thuộc lòng: mọi loại EBS SSD-backed (gp2, gp3, io1, io2) đều làm boot volume được; hai loại HDD-backed (st1, sc1) thì không. Đây là câu hỏi lặp đi lặp lại trong đề AWS, nhớ theo nhóm SSD/HDD sẽ nhanh hơn nhớ từng tên.
• Lý do đằng sau giúp nhớ chắc hơn quy tắc suông: boot là workload I/O nhỏ, ngẫu nhiên → cần IOPS; st1/sc1 tối ưu cho throughput trên dữ liệu streaming lớn nên không hợp và bị chặn.
• Instance Store dùng làm boot volume được — vấn đề của nó là dữ liệu ephemeral, không phải khả năng boot. Đừng đánh đồng "không bền" với "không boot được".
• Gặp đề có chữ CANNOT / NOT / EXCEPT kèm "(Select two)", hãy dừng lại đọc kỹ và dùng số lượng đáp án yêu cầu làm phép kiểm tra chéo cho cách hiểu của mình.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một startup tài chính lưu bản sao lưu dữ liệu tài chính của người dùng trên S3, và đặt ra hai ràng buộc đi cùng nhau:

1. "does not want to provide its own encryption keys" — startup không muốn tự cung cấp khoá mã hoá. Ràng buộc này loại ngay mọi phương án bắt người dùng cầm khoá trong tay.
2. "still wants to maintain an audit trail of when an encryption key was used and by whom" — vẫn muốn có dấu vết kiểm toán: khoá được dùng lúc nào và bởi ai.

Cụm quyết định là vế thứ hai: audit trail of when an encryption key was used and by whom. Cả bốn phương án đều mã hoá được dữ liệu ở S3, nên "mã hoá" không phân biệt được gì. Thứ phân biệt là: hình thức mã hoá nào vừa để AWS giữ khoá, vừa ghi lại từng lần khoá được gọi ra dùng.

✅ Vì sao đáp án đúng là đúng

A — Use SSE-KMS to encrypt the user data on S3.

SSE-KMS là server-side encryption trong đó khoá được quản lý bởi AWS Key Management Service (KMS). Startup không phải tự sinh, tự giữ hay tự truyền khoá theo từng request — họ chỉ trỏ bucket/object tới một CMK trong KMS, kể cả customer-managed CMK đã tạo sẵn. Ràng buộc "không muốn tự cung cấp khoá mã hoá" được thoả.

Điểm mấu chốt: mọi thao tác mã hoá/giải mã đều đi qua KMS như một lời gọi API riêng biệt. Nhờ đó SSE-KMS cung cấp audit trail cho biết CMK đã được dùng khi nào và bởi ai — đúng từng chữ trong yêu cầu của đề. Đây là khác biệt căn bản giữa SSE-KMS và các hình thức mã hoá còn lại: khoá nằm trong một service có quản trị và có ghi nhận việc sử dụng, chứ không phải một khoá ẩn danh bên trong tầng lưu trữ hay trong tay khách hàng.

❌ Vì sao các phương án còn lại sai

B — Use SSE-C to encrypt the user data on S3. Đây là phương án gần đúng nhưng hỏng ở cả hai ràng buộc. Với SSE-C (Server-Side Encryption with Customer-Provided Keys), S3 vẫn lo phần mã hoá lúc ghi xuống đĩa và giải mã lúc đọc — nghe rất giống A — nhưng khoá do chính khách hàng cung cấp kèm theo từng request. Vậy là vi phạm "không muốn tự cung cấp khoá". Và vì khoá không nằm trong KMS, không có audit trail nào về việc khoá được dùng lúc nào, bởi ai.

C — Client-side encryption với khoá do client cung cấp. Bị loại thẳng bởi vế thứ nhất của đề: startup không muốn tự cung cấp khoá mã hoá, trong khi client-side encryption đặt toàn bộ trách nhiệm sinh và giữ khoá lên phía client. Đây còn là phương án nặng nhất về vận hành trong cả bốn.

D — Use SSE-S3 to encrypt the user data on S3. Phương án gần đúng thứ hai, và cũng là bẫy phổ biến nhất. SSE-S3 thoả ràng buộc thứ nhất rất gọn: AWS quản lý toàn bộ khoá, mỗi object được mã hoá bằng một khoá riêng, startup không phải đụng vào khoá nào. Nhưng nó hỏng đúng ở ràng buộc thứ hai: khoá do S3 tự quản lý bên trong, không phải một CMK có danh tính trong KMS, nên không có dấu vết kiểm toán về việc khoá được sử dụng khi nào và bởi ai. Đề đã cố ý viết "BEST solution" chứ không phải "a working solution" — D mã hoá được nhưng không đáp ứng yêu cầu audit.

📌 Điểm cần nhớ

• Hễ đề nhắc "audit trail" về việc khoá mã hoá được dùng — khi nào, bởi ai, đó là tín hiệu chọn SSE-KMS. Đây gần như là dấu hiệu nhận biết duy nhất tách SSE-KMS khỏi SSE-S3.
• SSE-S3 và SSE-KMS đều để AWS giữ khoá; khác biệt nằm ở chỗ KMS cho bạn một CMK có danh tính, có chính sách truy cập và có ghi nhận việc sử dụng, còn SSE-S3 thì khoá vô hình với bạn.
• SSE-C vẫn là server-side nhưng khoá do khách hàng cung cấp. Đừng nhầm "server-side" với "AWS giữ khoá" — hễ đề nói không muốn tự quản lý/cung cấp khoá là SSE-C và client-side encryption cùng bị loại.
• Đọc kỹ những câu có hai ràng buộc chồng nhau: thường sẽ có một phương án thoả ràng buộc dễ thấy (ở đây là D) để dụ bạn dừng lại sớm. Phải kiểm cả hai ràng buộc trước khi chốt.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một ứng dụng web chạy trên 10 EC2 instance đứng sau Application Load Balancer (ALB). Ứng dụng có ghi lại IP của client, nhưng khi xem dữ liệu thì mọi IP đều giống nhau và trùng đúng với IP của Application Load Balancer. Câu hỏi: làm sao lấy được IP thật của client?

Cụm từ quyết định đáp án là "every IP address being captured is the same, which also happens to be the IP address of the Application Load Balancer" — nó mô tả chính xác cơ chế của một load balancer hoạt động ở tầng 7 (HTTP/HTTPS): ALB kết thúc kết nối TCP của client rồi mở một kết nối mới tới EC2 instance. Vì kết nối tới backend do chính ALB khởi tạo, IP nguồn mà instance nhìn thấy luôn là IP của ALB, không phải của người dùng.

Cụm thứ hai đáng chú ý là Application Load Balancer (không phải Network Load Balancer). Đây là proxy HTTP, nên nó đọc và ghi thêm được các HTTP header — và đó chính là chỗ AWS đặt thông tin IP gốc vào.

✅ Vì sao đáp án đúng là đúng

B — Look at the X-Forwarded-For header.

Elastic Load Balancing tự động chèn header X-Forwarded-For vào request trước khi chuyển tiếp xuống backend, và trong header đó lưu địa chỉ IP của client ban đầu. Ứng dụng chỉ cần đọc header này thay vì đọc IP nguồn ở tầng kết nối là có ngay IP thật của người dùng.

Điểm quan trọng: đây là hành vi mặc định của ELB, không phải thứ phải bật hay lập trình thêm ở phía client. Vấn đề trong đề không nằm ở chỗ thiếu dữ liệu, mà ở chỗ ứng dụng đang lấy dữ liệu sai chỗ — nó đọc IP của kết nối TCP (vốn là ALB) trong khi thông tin cần tìm đã nằm sẵn trong HTTP header. Sửa một dòng logic ghi log là xong, không phải sửa kiến trúc.

❌ Vì sao các phương án còn lại sai

A — Look at the client's cookie. Cookie là dữ liệu do ứng dụng tự đặt và trình duyệt gửi lại; nó không tự nhiên chứa IP của client. Muốn dùng cách này thì phải viết thêm logic ở cả phía client lẫn phía server để nhét IP vào cookie — trong khi ALB đã cung cấp sẵn thông tin đó miễn phí. Đây là cách vòng vèo, tốn công, và về bản chất vẫn phải biết IP từ đâu đó trước khi ghi vào cookie.

C — Modify the front-end of the website so that the users send their IP in the requests. Đây là phương án "gần đúng" theo nghĩa nó có thể đem lại một giá trị IP nào đó, nhưng hỏng ở hai chỗ. Thứ nhất, không cần thiết: IP của client vốn đã đi kèm request và đã được ALB ghi lại vào X-Forwarded-For, sửa front-end là làm lại việc đã có. Thứ hai, dữ liệu do client tự khai thì client tự đặt được giá trị gì cũng được — thông tin lấy từ header do load balancer chèn đáng tin hơn hẳn giá trị do trình duyệt tự khai báo.

D — Look at the X-Forwarded-Proto header. Đây là bẫy đặt ra vì tên header rất giống đáp án đúng, cùng họ X-Forwarded-* và cùng do ELB chèn vào. Nhưng nó trả lời một câu hỏi khác: client đã kết nối tới load balancer bằng giao thức nào — HTTP hay HTTPS. Header này hữu ích khi backend cần biết request gốc có mã hoá hay không (ví dụ để redirect sang HTTPS), chứ hoàn toàn không chứa địa chỉ IP. Đúng họ header, sai thông tin.

📌 Điểm cần nhớ

• Load balancer tầng 7 (ALB) kết thúc kết nối của client rồi mở kết nối mới tới backend, nên IP nguồn mà EC2 instance thấy luôn là IP của load balancer. Thấy triệu chứng "mọi log đều một IP duy nhất và trùng IP của LB" thì nghĩ ngay tới X-Forwarded-For.
• Phân biệt bộ header X-Forwarded-* do ELB chèn: X-Forwarded-For = IP client, X-Forwarded-Proto = giao thức (HTTP/HTTPS), X-Forwarded-Port = cổng client kết nối tới LB. Đề hỏi cái nào thì chọn header tương ứng.
• Khi có sẵn cơ chế của dịch vụ AWS, các phương án đòi sửa code ứng dụng hay front-end gần như luôn sai trong đề thi — vừa thừa việc, vừa kém tin cậy vì dữ liệu do client tự khai thì client tự sửa được.
• Ứng dụng nằm sau proxy phải đọc IP từ HTTP header chứ không đọc IP của kết nối TCP; đây là điều cần cấu hình ở tầng framework/web server, không phải ở tầng load balancer.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty dùng AWS CloudFormation: một template tạo stack chứa VPC và subnet, và giá trị output của subnet đó phải được dùng ở một stack khác.

Cụm từ quyết định đáp án là: "The output value of this subnet has to be used in another stack" — cộng thêm vai trò được hỏi: bạn đang đứng ở phía stack tạo ra giá trị, không phải phía stack tiêu thụ giá trị.

Chia sẻ giá trị giữa các stack trong CloudFormation luôn có hai nửa đối xứng:

Câu hỏi hỏi "provide this information to the other stack" — tức là làm sao đưa/cung cấp thông tin ra ngoài. Đó là nửa export. Đây chính là chỗ bẫy: một nửa phương án nói về phía nhận chứ không phải phía cho.

✅ Vì sao đáp án đúng là đúng

A — Use 'Export' field in the Output section of the stack's template.

Để chia sẻ thông tin giữa các stack, ta export các output value của một stack. Các stack khác trong cùng AWS account và cùng region sau đó có thể import những giá trị đã export.

Cụ thể: trong section Outputs của template stack VPC, mỗi output cần chia sẻ được gắn thêm trường Export kèm một tên. Tên export đó là duy nhất trong phạm vi account + region, và trở thành "địa chỉ" để stack khác gọi tới bằng Fn::ImportValue. Đúng với điều đề bài yêu cầu: cung cấp subnet ID ra cho stack khác dùng.

❌ Vì sao các phương án còn lại sai

B — Use 'Expose' field in the Output section of the stack's template. Đây là phương án gần đúng nhất về mặt hình thức: đúng chỗ (section Outputs), đúng ý tưởng (đưa giá trị ra ngoài), chỉ sai đúng một từ. Nhưng CloudFormation không có trường nào tên Expose — nó là tên bịa ra làm distractor. Bài học rút ra: trong CloudFormation, tên trường phải chính xác từng ký tự, không có chuyện "gần giống thì hiểu được".

D — Use Fn::ImportValue. Đây là bẫy chính của câu, vì Fn::ImportValue là hàm thật và đúng chủ đề chia sẻ giữa các stack. Nó hỏng ở chỗ đứng nhầm phía: Fn::ImportValue được viết trong template của stack đi nhận, để lấy về giá trị mà stack khác đã export. Còn đề đang hỏi làm gì ở stack đang có subnet để cung cấp thông tin. Quan trọng hơn: nếu không có Export ở nguồn thì chẳng có gì để Fn::ImportValue nhặt cả — export là điều kiện đứng trước.

C — Use Fn::Transform. Hàm intrinsic Fn::Transform chỉ định một macro để thực hiện xử lý tuỳ biến trên một phần của template — từ thao tác đơn giản như tìm-và-thay-thế cho tới biến đổi toàn bộ template. Nó thuộc về chuyện xử lý/biến hình template, hoàn toàn không liên quan tới việc truyền giá trị output từ stack này sang stack khác. Sai chủ đề chứ không chỉ sai chi tiết.

📌 Điểm cần nhớ

• Chia sẻ giá trị giữa các stack CloudFormation là cặp đôi hai nửa: Export trong Outputs ở stack nguồn, Fn::ImportValue ở stack đích. Đọc đề xem đang đứng ở phía nào trước khi chọn.
• Từ khoá phân biệt: "provide/share to another stack" → Export; "use/consume a value from another stack" → Fn::ImportValue.
• Giá trị export chỉ import được trong cùng account và cùng region — không phải cơ chế chia sẻ xuyên account hay xuyên region.
• Fn::Transform là hàm gọi macro để xử lý tuỳ biến template, không dính dáng gì tới trao đổi output giữa các stack.
• Cảnh giác với phương án chỉ khác đúng một từ (Expose vs Export): CloudFormation không có trường Expose; tên trường trong template phải đúng chính xác.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một bạn thực tập đang cấu hình xem Amazon EC2 nên làm gì khi nó ngắt (interrupt) một Spot Instance, rồi hỏi: hành vi nào KHÔNG cấu hình được làm interruption behavior?

Hai cụm từ quyết định đáp án:

• "interruption behavior" — đây là một tuỳ chọn có danh sách đóng khi bạn tạo Spot request. Câu hỏi không hỏi "EC2 làm được gì với một instance nói chung", mà hỏi cụ thể trong tập giá trị hợp lệ của trường này.
• "CANNOT" — câu hỏi đảo chiều. Ba phương án đúng theo nghĩa thông thường sẽ là ba phương án sai của câu này; thứ cần tìm là cái duy nhất nằm ngoài danh sách.

Spot Instance là dung lượng EC2 chưa dùng tới, được bán rẻ hơn giá On-Demand. Instance chạy khi còn capacity và mức giá tối đa bạn đặt còn cao hơn Spot price; khi AWS cần lại capacity đó, nó thu hồi instance. Vì thu hồi là chuyện luôn có thể xảy ra, việc bạn khai báo trước là "khi thu hồi thì làm gì với instance của tôi" — và tập lựa chọn đó chỉ có ba giá trị.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là C — Reboot the Spot Instance.

Ba interruption behavior hợp lệ mà EC2 chấp nhận là stop, hibernate và terminate; mặc định là terminate. Reboot không nằm trong danh sách này, nên đây chính là hành vi không thể cấu hình — đúng với chữ CANNOT trong đề.

Lý do khiến reboot vô nghĩa ở đây nằm ở bản chất của interruption: AWS thu hồi Spot Instance vì nó cần lại capacity đó cho mục đích khác. Reboot nghĩa là instance khởi động lại rồi tiếp tục chiếm đúng phần capacity ấy — tức là không trả lại gì cả, hoàn toàn ngược với mục đích của việc thu hồi. Cả ba hành vi hợp lệ đều có điểm chung là giải phóng capacity: stop và hibernate đưa instance về trạng thái không chạy, terminate thì xoá hẳn. Reboot không giải phóng gì, nên nó không thể là một phản ứng hợp lệ với interruption.

❌ Vì sao các phương án còn lại sai

A — Hibernate the Spot Instance: Đây là một giá trị hợp lệ, nên không phải đáp án của câu hỏi dạng CANNOT. Hibernate ghi nội dung RAM xuống EBS root volume rồi dừng instance; khi capacity quay lại, instance tiếp tục từ đúng chỗ đã dừng thay vì khởi động lại từ đầu. Đây là phương án gần đúng dễ chọn nhầm nhất vì hibernate là hành vi "lạ" nhất trong bốn cái, dễ khiến người học nghĩ nó không được hỗ trợ — nhưng nó có thật và được EC2 chấp nhận.

B — Terminate the Spot Instance: Hợp lệ, và còn là hành vi mặc định. Nếu bạn không khai gì cả khi tạo Spot request thì EC2 sẽ terminate instance lúc thu hồi. Đây là phương án dễ loại nhất — chọn nó tức là hiểu ngược chiều câu hỏi.

D — Stop the Spot Instance: Hợp lệ. Instance được dừng lại, EBS volume giữ nguyên dữ liệu, và khi Spot capacity có lại thì request có thể cho instance chạy tiếp. Khác hibernate ở chỗ stop không giữ nội dung RAM — dữ liệu trong bộ nhớ mất, ứng dụng khởi động lại từ đầu, chỉ dữ liệu trên đĩa còn nguyên. Người học hay lẫn stop với hibernate, nhưng ở câu này cả hai đều hợp lệ nên sự khác biệt đó không đổi được đáp án.

📌 Điểm cần nhớ

• Interruption behavior của Spot Instance chỉ có ba giá trị: stop, hibernate, terminate. Mặc định là terminate. Thuộc luôn bộ ba này là giải quyết được mọi câu xoay quanh chủ đề.
• Reboot không bao giờ là một interruption behavior. Mẹo nhớ: interruption tồn tại để AWS lấy lại capacity, mà reboot thì vẫn giữ capacity — nên nó tự mâu thuẫn.
• Phân biệt stop và hibernate: cả hai giữ dữ liệu trên EBS, nhưng chỉ hibernate lưu nội dung RAM để chạy tiếp đúng trạng thái cũ.
• Đọc kỹ chữ CANNOT / NOT / EXCEPT trong đề. Với dạng đảo chiều này, ba phương án "nghe rất đúng" chính là ba phương án cần loại; thói quen chọn cái quen thuộc nhất sẽ dẫn thẳng vào bẫy.
• Spot Instance có thể bị thu hồi bất cứ lúc nào, nên ứng dụng chạy trên Spot phải được thiết kế để chịu được gián đoạn — chọn interruption behavior là một phần của việc chuẩn bị đó.

🧩 Phân tích nội dung câu hỏi

Đội phát triển muốn upload file lên S3 bucket bằng cơ chế SSE-KMS, nhưng đang nhận lỗi permission khi đẩy object qua HTTP. Câu hỏi yêu cầu chọn header cần đưa vào request.

Cụm từ quyết định đáp án là "using the SSE-KMS encryption mechanism". Cả bốn phương án đều dùng đúng một tên header — x-amz-server-side-encryption — nên header nào cũng "trông đúng"; thứ phân biệt chúng nằm ở giá trị của header. Vì vậy câu này thực chất hỏi: giá trị hợp lệ mà S3 chấp nhận cho SSE-KMS là gì?

Chi tiết thứ hai đáng chú ý: SSE-S3 và SSE-KMS là tên gọi của các tuỳ chọn mã hoá trong tài liệu AWS, không phải giá trị nằm trong giao thức. Đề cố tình đặt tên tuỳ chọn vào ô giá trị để bẫy người học quen đọc tài liệu ở mức khái niệm mà chưa từng gọi API trực tiếp. Chi tiết "over HTTP" nhấn mạnh rằng đây là lời gọi REST API thô, nơi bạn phải tự đặt header, chứ không phải SDK hay console tự lo giúp.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là D — 'x-amz-server-side-encryption': 'aws:kms'.

Đây là giá trị mà S3 REST API quy định cho server-side encryption dùng khoá quản lý bởi AWS KMS. Server-side encryption là việc mã hoá dữ liệu tại đích, do chính dịch vụ nhận dữ liệu thực hiện. AWS KMS là dịch vụ quản lý khoá kết hợp phần cứng và phần mềm an toàn, có tính sẵn sàng cao, ở quy mô cloud; S3 dùng CMK của KMS để mã hoá object. Lưu ý KMS chỉ mã hoá phần dữ liệu của object, còn metadata thì không.

Điểm liên quan trực tiếp tới triệu chứng trong đề: nếu request không kèm header x-amz-server-side-encryption, request sẽ bị từ chối. Đội phát triển đang gặp lỗi permission chính vì thiếu header này (hoặc đặt giá trị mà S3 không hiểu, dẫn tới cùng kết quả là request không được chấp nhận). Đặt đúng aws:kms là cách nói với S3 rằng object này phải được mã hoá bằng KMS.

❌ Vì sao các phương án còn lại sai

A — 'x-amz-server-side-encryption': 'SSE-S3': sai hai lớp. Thứ nhất, đây là giá trị header không hợp lệ — SSE-S3 chỉ là tên gọi của tuỳ chọn Server-Side Encryption with Amazon S3-Managed Encryption Keys, không phải chuỗi mà API chấp nhận; giá trị đúng cho tuỳ chọn đó là AES256. Thứ hai, kể cả nếu viết đúng chuỗi, nó vẫn trỏ sang SSE-S3 chứ không phải SSE-KMS như đề yêu cầu.

B — 'x-amz-server-side-encryption': 'AES256': đây là phương án gần đúng nhất, và là chỗ nhiều người vấp. Chuỗi này hợp lệ về mặt cú pháp — S3 chấp nhận nó và mã hoá object bình thường. Nhưng nó khai báo SSE-S3, tức là dùng khoá do S3 quản lý, không đụng tới KMS. Đề nói rõ đội muốn SSE-KMS, nên chọn B là làm đúng thao tác nhưng sai cơ chế mã hoá: object được mã hoá, chỉ là không bằng khoá KMS mà đội cần.

C — 'x-amz-server-side-encryption': 'SSE-KMS': đúng ý định nhưng sai chuỗi. SSE-KMS là tên tuỳ chọn mã hoá trong tài liệu, không phải giá trị header. S3 không nhận ra chuỗi này, nên request vẫn hỏng đúng như triệu chứng mô tả trong đề. Đây là bẫy chính của câu hỏi: người học biết chính xác mình muốn gì mà vẫn trả lời sai vì gõ tên khái niệm vào chỗ đáng lẽ phải gõ giá trị giao thức.

📌 Điểm cần nhớ

• Với header x-amz-server-side-encryption của S3: AES256 = SSE-S3, aws:kms = SSE-KMS. Đây là hai giá trị cần thuộc lòng, và cả hai đều không trùng với tên tuỳ chọn.
• Phân biệt tên khái niệm (SSE-S3, SSE-KMS — dùng khi nói chuyện và đọc tài liệu) với giá trị giao thức (thứ thực sự đi trong request). Đề thi rất hay đảo hai thứ này cho nhau.
• Khi upload lên bucket bắt buộc mã hoá, thiếu header x-amz-server-side-encryption thì request bị từ chối — lỗi hiện ra dưới dạng permission error chứ không phải lỗi "thiếu tham số", nên dễ đi lạc hướng sang IAM policy.
• SSE-KMS chỉ mã hoá phần dữ liệu của object; metadata không được mã hoá, đừng đặt thông tin nhạy cảm vào đó.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một EC2 instance bị lỗi code khiến CPU utilization chạm gần 100% rồi treo cứng, chỉ khôi phục được bằng cách restart. Bản vá phải vài tuần nữa mới có, nên nhiệm vụ trước mắt là tự động restart instance ngay khi nó bắt đầu có dấu hiệu không phản hồi.

Cụm từ quyết định là "at the first sign of the instance becoming unresponsive" — tức là phải phát hiện sớm nhất có thể. Cả bốn phương án đều xoay quanh cùng một ý tưởng (theo dõi CPUUtilization bằng CloudWatch rồi restart), nên thứ phân biệt chúng không phải là "dùng dịch vụ nào" mà là hai chi tiết nhỏ:

1. Độ phân giải của metric — basic monitoring hay detailed monitoring.
2. Cách thực thi hành động restart — dùng alarm action có sẵn của EC2, hay phải viết thêm Lambda / custom code.

Cụm từ thứ hai đáng chú ý là "CPU utilization" — đây là metric mà EC2 đã tự đẩy sang CloudWatch, không phải metric ở tầng hệ điều hành (như bộ nhớ hay dung lượng đĩa) vốn cần CloudWatch agent.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C: tạo CloudWatch alarm cho CPUUtilization với detailed monitoring bật, cấu hình action restart instance khi alarm kích hoạt.

CPUUtilization là metric dựng sẵn của EC2 trong CloudWatch, nên không cần viết gì thêm để thu thập nó. Việc còn lại chỉ là chọn độ phân giải và gắn hành động:

• Detailed monitoring đẩy dữ liệu ở chu kỳ 1 phút thay vì chu kỳ 5 phút mặc định của basic monitoring. Với yêu cầu "phát hiện ở dấu hiệu đầu tiên", chu kỳ ngắn hơn nghĩa là alarm nhận ra tình trạng CPU chạm trần sớm hơn nhiều — đúng tinh thần của đề. Detailed monitoring bật được cả lúc launch instance lẫn khi instance đang chạy hoặc đã stop, và có tính thêm phí theo số metric gửi lên.
• EC2 action "restart/reboot" là hành động dựng sẵn của CloudWatch alarm. Khi alarm chuyển sang trạng thái ALARM, CloudWatch tự gọi hành động đó, không cần thành phần trung gian nào.

Kết hợp lại: metric sẵn có + độ phân giải 1 phút + alarm action sẵn có = giải pháp phát hiện nhanh nhất mà không phải viết một dòng code nào.

❌ Vì sao các phương án còn lại sai

A — dùng metric dựng sẵn nhưng ở basic monitoring, gắn restart action. Đây là phương án gần đúng nhất, vì phần "metric dựng sẵn" và phần "gắn restart action" đều chính xác. Chỗ hỏng nằm đúng ở ràng buộc của đề: basic monitoring chỉ có dữ liệu theo chu kỳ 5 phút. Instance có thể đã treo và nằm im một quãng trước khi alarm kịp nhìn thấy điểm dữ liệu tiếp theo. Với yêu cầu "at the first sign", độ trễ đó là không chấp nhận được. So sánh A với C là bài tập kinh điển: khác nhau duy nhất một chữ basic/detailed, và chính chữ đó là câu trả lời.

B — basic monitoring + Lambda function làm việc restart. Phương án này hỏng ở hai chỗ. Thứ nhất, nó vẫn dùng basic monitoring nên dính đúng vấn đề trễ như A. Thứ hai, nó thêm một Lambda function để làm việc mà CloudWatch alarm đã làm được sẵn bằng EC2 action — thêm code phải viết, thêm IAM role phải cấp quyền, thêm một chỗ có thể hỏng, mà chẳng đổi lại được gì. Trong đề thi AWS, khi một hành động đã là tính năng có sẵn thì lời giải viết code để làm lại nó gần như luôn là phương án sai.

D — viết custom code để đẩy CPU utilization lên CloudWatch làm custom metric, rồi cấu hình alarm action restart. Sai vì làm thừa: CPUUtilization đã là metric EC2 tự phát ra, không cần ai đẩy hộ. Custom metric chỉ cần cho những chỉ số CloudWatch không nhìn thấy từ tầng hypervisor — chẳng hạn mức dùng bộ nhớ hay dung lượng đĩa còn trống trong guest OS. Còn một điểm yếu thực tế nữa: đoạn code đó chạy bên trong chính instance đang bị treo vì CPU 100%, nên đúng lúc cần nhất thì nó lại là thứ dễ ngừng gửi dữ liệu nhất.

📌 Điểm cần nhớ

• Basic monitoring = chu kỳ 5 phút, miễn phí; detailed monitoring = chu kỳ 1 phút, tính phí. Hễ đề nhấn "phát hiện nhanh", "ngay lập tức", "at the first sign" là chọn detailed monitoring.
• CloudWatch alarm có sẵn EC2 actions (stop, terminate, reboot, recover). Thấy phương án dựng Lambda chỉ để làm đúng những việc đó thì loại — thêm thành phần mà không thêm giá trị.
• Metric nào EC2 tự phát, metric nào phải tự đẩy: CPU, network, disk I/O ở tầng hypervisor là có sẵn; memory và disk space trong guest OS mới cần agent hoặc custom metric. Nhớ ranh giới này là loại được ngay các phương án "viết custom code" thừa thãi.
• Khi các phương án khác nhau đúng một chi tiết nhỏ, chi tiết đó chính là điều đề đang kiểm tra — hãy đọc lại đề tìm cụm từ ràng buộc thay vì cân nhắc kiến trúc tổng thể.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một web application chuyển lên AWS với hai yêu cầu ràng buộc lẫn nhau:

1. "The database will be on Amazon RDS and it should not be accessible to the public" — database không được để Internet truy cập vào.
2. "the RDS instance will need access to the internet to download patches every month" — nhưng chính database lại phải ra được Internet.

Cụm từ quyết định là cặp "not be accessible to the public" đứng cạnh "need access to the internet". Đây là mô tả kinh điển của kết nối outbound-only: đi ra được, nhưng bên ngoài không mở kết nối vào được. Trong VPC, đúng một thành phần làm việc đó cho IPv4: NAT gateway đặt ở public subnet, còn instance nằm ở private subnet.

Cụm thứ hai là "The application needs to remain connected to the database" — nghĩa là application server và database phải nằm trong cùng một VPC để nói chuyện với nhau bằng private IP, không cần bắc cầu gì thêm.

Cả bốn phương án đều xếp application ở public subnet và database ở private subnet. Chỗ khác nhau duy nhất là cách cho private subnet ra Internet — đó chính là điểm cần phân biệt.

✅ Vì sao đáp án đúng là đúng

Phương án A mô tả đúng mô hình hai tầng chuẩn của AWS:

• Public subnet có route ra Internet Gateway → application server nhận được traffic từ người dùng và gửi traffic ra ngoài.
• Private subnet có route trỏ tới NAT gateway đặt trong public subnet → RDS khởi tạo được kết nối ra Internet để tải patch.
• NAT gateway chỉ dịch địa chỉ cho traffic đi ra; nó không cho phép ai từ Internet mở kết nối ngược vào private subnet. Nhờ vậy RDS vẫn "not accessible to the public" trong khi vẫn tải được bản vá.
• Application và database ở hai subnet của cùng một VPC nên định tuyến nội bộ có sẵn, chỉ cần cấu hình security group cho phép là kết nối được.

Đây chính là kịch bản mà tài liệu VPC của AWS gọi là "VPC with public and private subnets".

❌ Vì sao các phương án còn lại sai

B — dùng NAT gateway cho cả hai subnet. Đây là phương án gần đúng nhất, và nó hỏng ở nửa sau. NAT gateway sinh ra để phục vụ private subnet. Public subnet theo định nghĩa là subnet có route trỏ tới Internet Gateway; bắt nó đi qua NAT gateway là dư thừa và tự mâu thuẫn — bản thân NAT gateway lại nằm trong public subnet và phụ thuộc vào Internet Gateway để hoạt động, nên route table của public subnet trỏ về NAT gateway sẽ phá luôn đường ra của chính NAT gateway. Ngoài ra application server ở public subnet cần nhận kết nối vào từ người dùng, mà NAT gateway không làm được việc đó.

C — dùng VPC peering giữa private subnet và public subnet. Sai ngay ở khái niệm. VPC peering là kết nối giữa hai VPC, không phải giữa hai subnet trong cùng một VPC. Các subnet trong một VPC vốn đã định tuyến được với nhau, chẳng có gì để "peer". Và kể cả có peering thật thì nó cũng chỉ chuyển traffic private giữa hai VPC, không tạo ra đường đi Internet cho bên nào cả.

D — private subnet ra Internet được nhờ dùng IPv6. Nhầm lẫn giữa giao thức và đường định tuyến. IPv6 chỉ là một họ địa chỉ, giống IPv4; bản thân nó không cấp quyền ra Internet. Với IPv6, muốn có kết nối outbound-only cho private subnet thì phải cấu hình egress-only Internet gateway — một thành phần riêng, không hề được nhắc tới trong phương án này. Thêm nữa, đề không nói gì về việc chuyển sang IPv6, nên đây là điều kiện tự thêm vào.

📌 Điểm cần nhớ

• Yêu cầu dạng "ra Internet được nhưng không cho Internet vào" với IPv4 → private subnet + NAT gateway đặt ở public subnet. Đây là mẫu câu lặp lại rất nhiều trong đề thi.
• NAT gateway phải nằm trong public subnet và bản thân nó dựa vào Internet Gateway; route table của private subnet mới là chỗ trỏ tới NAT gateway. Phương án nào bắt public subnet đi qua NAT gateway đều sai.
• VPC peering nối VPC với VPC, không nối subnet với subnet, và không bao giờ tạo ra đường đi Internet.
• Với IPv6, thành phần tương đương NAT gateway là egress-only Internet gateway; chỉ đổi sang IPv6 mà không cấu hình gì thêm thì vẫn không ra được Internet.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty y tế lưu dữ liệu mật trên Amazon S3, và quy định tuân thủ mới bắt buộc file phải được lưu ở dạng server-side encryption. Hai cụm từ trong đề mới là thứ quyết định đáp án:

1. "server-side encryption" — mã hoá phải diễn ra ở phía AWS, lúc S3 ghi dữ liệu xuống đĩa. Cụm này lập tức loại bỏ mọi phương án mã hoá ở phía client.
2. "does not want to manage S3 encryption keys" — công ty không muốn quản lý khoá. Đây là ràng buộc phân biệt các phương án server-side còn lại với nhau, vì cả ba phương án SSE đều mã hoá phía máy chủ, chỉ khác nhau ở chỗ ai giữ và ai quản lý khoá.

Yêu cầu AES-256 thì hầu như không phân biệt được gì — các cơ chế SSE của S3 đều dùng AES-256. Nó chỉ có tác dụng xác nhận thêm rằng thuật toán mặc định của S3 đã đáp ứng yêu cầu tuân thủ, chứ không cần cấu hình gì đặc biệt.

Nói gọn: đề hỏi cơ chế nào vừa mã hoá phía server, vừa AES-256, vừa không bắt khách hàng đụng tới khoá.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys).

Với SSE-S3, S3 mã hoá từng object bằng một khoá riêng, rồi bản thân khoá đó lại được mã hoá bằng một master key do S3 quản lý và luân chuyển định kỳ. Toàn bộ vòng đời khoá — tạo, lưu, xoay vòng — nằm trong tay Amazon S3; khách hàng không phải sinh khoá, không phải truyền khoá kèm mỗi request, không phải tạo hay cấp quyền cho tài nguyên khoá nào cả. Thuật toán dùng là AES-256, đúng chuẩn mà quy định tuân thủ của công ty yêu cầu.

Ba điều kiện của đề khớp trọn vẹn: server-side ✓, AES-256 ✓, không quản lý khoá ✓. Đây chính là phương án "ít việc phải làm nhất" mà vẫn thoả mãn yêu cầu mã hoá tại chỗ lưu trữ.

❌ Vì sao các phương án còn lại sai

A — SSE-C (Server-Side Encryption with Customer-Provided Keys) Đây đúng là server-side: S3 vẫn là bên thực hiện mã hoá khi ghi và giải mã khi đọc. Nhưng khoá do khách hàng cung cấp — bạn phải tự sinh khoá, tự lưu giữ an toàn, và gửi kèm khoá trong mỗi request lên/xuống. S3 không giữ lại khoá; mất khoá là mất dữ liệu. Như vậy phương án này vi phạm thẳng ràng buộc "không muốn quản lý khoá mã hoá" — nó gần đúng ở vế "server-side", nhưng hỏng đúng ở vế quyết định.

B — Client Side Encryption Sai ngay ở vế đầu tiên của đề. Ở mô hình này, dữ liệu được mã hoá trước khi rời khỏi ứng dụng, rồi mới upload bản đã mã hoá lên S3. Đề yêu cầu rõ "files be stored with server-side encryption", còn client-side thì S3 chỉ nhận về một khối byte đã mã hoá sẵn. Tệ hơn nữa cho tình huống này: bạn phải tự quản lý cả quy trình mã hoá, khoá lẫn công cụ — trái với cả hai ràng buộc của đề.

D — SSE-KMS (Server-Side Encryption with AWS KMS keys) Đây là phương án gây nhầm nhiều nhất, vì nó cũng là server-side và cũng đáp ứng được yêu cầu mã hoá tại chỗ lưu trữ. Điểm khác biệt: SSE-KMS đưa thêm một lớp quản trị khoá qua AWS KMS — bạn có audit trail ghi lại khoá được dùng khi nào và bởi ai, và có tuỳ chọn tự tạo, tự quản lý khoá của mình. Chính phần "quản lý khoá" đó là thứ đề bài nói công ty không muốn. Khi đề chỉ yêu cầu AES-256 và không hề nhắc tới audit, kiểm soát quyền truy cập khoá hay khoá do khách hàng tự tạo, thì SSE-KMS là lựa chọn thừa so với nhu cầu — và nó không phải đáp án được chọn.

📌 Điểm cần nhớ

• Với câu hỏi mã hoá S3, hãy đọc theo hai trục: mã hoá ở đâu (client-side hay server-side) và ai quản lý khoá (S3, KMS, hay khách hàng). Hai trục này đủ để tách bạch cả bốn phương án.
• Cụm "does not want to manage encryption keys" (hoặc "least operational overhead" về quản lý khoá) là tín hiệu chỉ thẳng vào SSE-S3.
• Cụm nhắc tới audit trail việc dùng khoá, kiểm soát quyền trên khoá, hoặc khoá do khách hàng tự tạo/quản lý mới là tín hiệu của SSE-KMS.
• SSE-C vẫn là server-side — đừng loại nó chỉ vì có chữ "Customer"; loại nó vì gánh nặng quản lý và truyền khoá thuộc về khách hàng.
• Yêu cầu AES-256 một mình không phân biệt được các cơ chế SSE của S3; đừng để nó đánh lạc hướng khỏi ràng buộc thật sự trong đề.

🧩 Phân tích nội dung câu hỏi

Một công ty truyền thông chạy hệ thống trên Amazon EC2 với dữ liệu nằm trên Amazon S3, và chi phí S3 cứ tăng đều. Họ muốn ra quyết định về lưu giữ, lưu trữ và xoá dữ liệu dựa trên báo cáo sử dụng và chi phí của S3.

Cụm từ quyết định đáp án là: "track the costs incurred by each S3 bucket in the AWS account" — theo dõi chi phí của từng bucket trong tài khoản.

Hai ràng buộc gói gọn trong cụm đó, và chúng loại gần hết các phương án:

• "each S3 bucket" — phải bóc tách chi phí xuống mức từng bucket, chứ không phải tổng chi phí dịch vụ S3. Trong hoá đơn AWS, S3 mặc định chỉ hiện như một khoản gộp; muốn tách theo bucket thì phải có thứ gì đó gắn nhãn cho từng bucket.
• "costs incurred" — chi phí đã phát sinh thật, dữ liệu quá khứ. Không phải dự toán, không phải cảnh báo ngưỡng, không phải khuyến nghị.

Đề còn nhấn "based on S3 usage and cost reports" — thứ cần là một báo cáo, không phải một cái chuông báo.

✅ Vì sao đáp án đúng là đúng

Phương án A — gắn tag chung cho từng bucket, kích hoạt tag đó thành cost allocation tag, rồi dùng AWS Cost Explorer tạo báo cáo chi phí theo tag.

Đây đúng là quy trình chuẩn của AWS để bóc chi phí S3 theo bucket, và nó khớp cả hai ràng buộc ở trên:

1. Tag là cầu nối giữa tài nguyên và hoá đơn. Gắn một tag chung (ví dụ cùng khoá, khác giá trị theo từng bucket) lên mọi bucket, thì mỗi dòng chi phí phát sinh từ bucket đó sẽ mang theo tag ấy.
2. Phải "activate" tag trong Billing and Cost Management thì tag mới trở thành cost allocation tag. Bước này hay bị quên: tag đã gắn trên tài nguyên nhưng chưa kích hoạt thì dữ liệu chi phí không được phân tách theo nó.
3. Cost Explorer cho phép nhóm và lọc chi phí theo tag, nên sau khi kích hoạt là tạo được báo cáo so sánh bucket nào tốn nhất — đúng thứ công ty cần để quyết định giữ, chuyển hay xoá dữ liệu.

Lưu ý về quyền như giải thích gốc nêu: người thực hiện cần quyền truy cập console Billing and Cost Management và quyền s3:GetBucketTagging, s3:PutBucketTagging để đọc/ghi tag trên bucket.

Một điểm phụ đáng biết: có thể bật thêm AWS Cost and Usage Report để lấy chi tiết billing S3 sâu hơn, nhưng báo cáo đó không cho biết ai đã gọi request vào bucket — muốn có thông tin đó thì phải bật logging từ trước.

❌ Vì sao các phương án còn lại sai

B — AWS Budgets. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì Budgets cũng nằm trong nhóm quản lý chi phí. Nhưng Budgets là công cụ đặt ngân sách và cảnh báo: nó báo khi chi phí hoặc mức sử dụng vượt (hoặc được dự báo sẽ vượt) hạn mức bạn đặt, hoặc khi mức tận dụng/độ phủ reservation tụt dưới ngưỡng. Chỗ hỏng của nó ở đây: Budgets không phải công cụ báo cáo bóc tách chi phí theo từng bucket — nó trả lời "đã vượt ngưỡng chưa", không trả lời "bucket nào tốn bao nhiêu". Đề đang cần bảng so sánh để ra quyết định lưu giữ dữ liệu, không cần chuông báo.

C — AWS Simple Monthly Calculator. Đây là công cụ ước tính (estimate) chi phí hằng tháng cho một kịch bản sử dụng dự kiến, dùng khi bạn còn đang thiết kế hoặc lập kế hoạch. Nó hoàn toàn nằm ngoài tài khoản của bạn: nó không đọc dữ liệu sử dụng thật, nên không thể biết bucket nào trong tài khoản đang tốn nhiều nhất. Đề hỏi về chi phí đã phát sinh, không phải ước tính — sai ngay ở bản chất công cụ.

D — AWS Trusted Advisor. Trusted Advisor đưa ra bộ kiểm tra best practice và khuyến nghị trên nhiều nhóm hạng mục, và đúng là có các check liên quan đến S3, cụ thể: bucket có quyền truy cập mở, cấu hình logging của bucket (đã bật chưa và giữ bao lâu), và bucket chưa bật versioning. Chỗ hỏng: đó là các check về bảo mật và cấu hình, không phải báo cáo chi phí. Trusted Advisor không sinh được báo cáo chi phí phát sinh trên từng S3 bucket. Nó có thể gợi ý chỗ tiết kiệm ở mức chung, nhưng không thay được Cost Explorer trong việc bóc chi phí theo bucket.

📌 Điểm cần nhớ

• Muốn bóc chi phí AWS xuống mức từng tài nguyên (bucket, instance, project, phòng ban), lối đi chuẩn luôn là: gắn tag → kích hoạt cost allocation tag → xem/nhóm trong Cost Explorer. Thiếu bước kích hoạt là tag vô dụng với hoá đơn.
• Phân biệt bốn công cụ chi phí theo câu hỏi mà chúng trả lời: Cost Explorer = "tiền đã đi đâu?"; Budgets = "đã vượt ngưỡng chưa?"; Simple Monthly Calculator = "nếu làm thế này thì tốn bao nhiêu?"; Trusted Advisor = "cấu hình của tôi có lệch best practice không?".
• Gặp từ khoá "track / report / breakdown per resource" thì nghĩ tag + Cost Explorer. Gặp "alert / notify / threshold / exceed" thì mới nghĩ tới Budgets.
• Trusted Advisor với S3 gắn với quyền truy cập mở, logging, versioning — đó là hướng bảo mật/độ bền, đừng kéo nó sang bài toán báo cáo chi phí.