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

Đáp án

B — Chuyển ứng dụng sang một EC2 instance có hibernation được bật.

Vì sao đúng

Đề nêu vấn đề: instance được dừng ngoài giờ để tiết kiệm, nhưng khởi động lại mất vài phút trước khi ứng dụng sẵn sàng.

Hibernation giải quyết đúng vấn đề đó:

DỪNG thông thường (stop):
    → hệ điều hành tắt hẳn
    → khởi động lại = boot từ đầu + khởi động ứng dụng + nạp cache
    → mất vài phút

HIBERNATE (ngủ đông):
    → nội dung RAM được GHI XUỐNG root EBS volume
    → khởi động lại = nạp RAM trở lại
    → tiến trình đang chạy TIẾP TỤC ngay tại chỗ
    → ứng dụng đã sẵn sàng, cache đã nóng

Và điểm mấu chốt của câu hỏi: hibernation CHỈ BẬT ĐƯỢC LÚC KHỞI CHẠY INSTANCE.

aws ec2 run-instances --hibernation-options Configured=true ...
    ↑ tham số này CHỈ có ở lúc TẠO instance
    → KHÔNG có API nào bật hibernation cho instance đang tồn tại

Nên phải "migrate the application to an EC2 instance with hibernation enabled" — tức là tạo instance mới với cờ đó rồi chuyển ứng dụng sang.

Và vế "without driving the cost up" được đáp ứng: instance ở trạng thái hibernate không tính phí compute, chỉ tính phí lưu trữ EBS — giống hệt trạng thái stopped.

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

• **C. Bật chế độ hibernation trên EC2 instance hiện có — đây là phương án gần nhất và là bẫy chính của câu hỏi: không bật hibernation cho instance đã tồn tại được. Tham số HibernationOptions chỉ nhận giá trị lúc khởi chạy.
• **A. Chuyển ứng dụng sang EC2 instance chạy Linux — không giải quyết vấn đề: đổi hệ điều hành không làm thời gian khởi động ứng dụng ngắn đi, và ứng dụng Windows với FSx for Windows File Server không chuyển sang Linux dễ dàng.
• **D. Tắt Instance Metadata Service để giảm thứ phải nạp lúc khởi động — hiểu sai hoàn toàn: IMDS là một endpoint HTTP nội bộ, nó không "nạp" gì lúc khởi động và không ảnh hưởng tới thời gian boot. Tắt nó còn làm instance mất khả năng dùng IAM role.

Ghi nhớ

Ba trạng thái của EC2 instance — bảng phân biệt: | Trạng thái | RAM | Chi phí compute | Thời gian khởi động lại | |---|---|---|---| | Running | giữ | có | — | | Stopped | MẤT | không | vài phút (boot đầy đủ) | | Hibernated | GHI xuống EBS | không | nhanh hơn — nạp RAM trở lại |

Ba điều kiện để dùng hibernation: | Điều kiện | Chi tiết | |---|---| | Bật lúc KHỞI CHẠY | không đổi được sau ← điểm của câu hỏi | | Root volume là EBS, ĐÃ MÃ HOÁ | bắt buộc | | Root volume đủ lớn chứa RAM | dung lượng ≥ RAM + hệ điều hành + dữ liệu |

Điều kiện thứ hai đáng nhớ: hibernation bắt buộc root volume phải mã hoá — vì nội dung RAM (có thể chứa dữ liệu nhạy cảm) được ghi xuống đĩa.

Ba giới hạn khác của hibernation: | Giới hạn | Chi tiết | |---|---| | Chỉ một số loại instance | M, C, R, T3 và các thế hệ được hỗ trợ | | RAM tối đa | tuỳ loại instance (thường tới 150 GB) | | Thời gian hibernate tối đa | 60 ngày | | Không dùng được với instance store | root phải là EBS |

Giới hạn 60 ngày ít khi thành vấn đề với mẫu dùng "dừng ngoài giờ, bật lại hôm sau".

Ba cách khác để rút ngắn thời gian khởi động: | Cách | Lợi ích | |---|---| | AMI đã nướng sẵn ứng dụng và cấu hình | không cài đặt lúc khởi chạy | | Warm pool của Auto Scaling | giữ instance ở trạng thái Stopped hoặc Hibernated | | Giảm việc làm trong user data | mọi lệnh trong user data đều thêm thời gian |

Warm pool đáng biết: nó là cơ chế Auto Scaling giữ sẵn một nhóm instance ở trạng thái Stopped hoặc Hibernated, và chuyển sang InService rất nhanh khi cần — kết hợp hibernation thì thời gian sẵn sàng còn ngắn hơn nữa.

Ba cách tiết kiệm chi phí cho instance dùng theo giờ hành chính: | Cách | Mức tiết kiệm | |---|---| | Dừng ngoài giờ (như đề đang làm) | tới ~65% nếu chỉ chạy 8 giờ/ngày, 5 ngày/tuần | | Instance Scheduler của AWS | tự động hoá việc dừng và bật theo lịch | | Savings Plan cho phần chạy liên tục | giảm giá cho cam kết dài hạn |

AWS Instance Scheduler là giải pháp dựng sẵn cho chính mẫu dùng này — nó dừng và bật instance theo lịch dựa trên tag, thay vì tự viết Lambda.

Và một lưu ý về FSx for Windows File Server trong kiến trúc của đề: FSx tính phí liên tục dù instance có dừng hay không. Nếu file system chỉ phục vụ ứng dụng này, cân nhắc kích thước throughput capacity nhỏ nhất đủ dùng — đó thường là khoản chi phí lớn hơn cả EC2 trong mẫu dùng theo giờ hành chính.

Đáp án

A và C.

• C — Mọi dữ liệu trên instance store sẽ MẤT
• A — Máy chủ vật lý chứa instance có thể thay đổi

Vì sao đúng

Đề mô tả instance có instance store volume và Elastic IP, được dừng rồi khởi động lại hằng ngày.

C — instance store không bền vững, và đây là hệ quả nghiêm trọng nhất:

Instance store = đĩa VẬT LÝ gắn trực tiếp vào máy chủ chủ

DỪNG instance:
    → instance rời khỏi máy chủ vật lý đó
    → dữ liệu trên đĩa cục bộ MẤT HOÀN TOÀN
    → không có cách nào khôi phục

A — và lý do dữ liệu mất chính là vì máy chủ vật lý thay đổi:

Instance ở trạng thái stopped:
    → không chiếm phần cứng nào
Khởi động lại:
    → AWS đặt instance lên MỘT MÁY CHỦ VẬT LÝ KHÁC (thường là vậy)
    → đĩa cục bộ của máy cũ không đi theo

Hai đáp án này là nguyên nhân và hệ quả của nhau — đó là lý do chúng đi cùng nhau.

Và với kiến trúc mà đề mô tả, đây là lỗi thiết kế nghiêm trọng:

Ứng dụng dùng instance store + tự động dừng mỗi tối
    → MỖI NGÀY mất toàn bộ dữ liệu trên đó
    → nếu đó là dữ liệu quan trọng, hệ thống hỏng ngay từ đêm đầu tiên

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

• **D. Elastic IP bị tách khỏi instance — đây là phương án gần nhất và đúng với IP công khai THÔNG THƯỜNG, nhưng Elastic IP thì KHÔNG: EIP vẫn gắn với instance qua chu kỳ dừng và khởi động. (Đó chính là lý do EIP tồn tại — địa chỉ cố định.)
• **B. ENI bị tháo ra — sai: giao diện mạng chính (eth0) vẫn gắn với instance qua chu kỳ dừng/khởi động. Nó chỉ bị xoá khi instance bị chấm dứt.
• **E. Không có gì thay đổi — sai vì hai điều ở A và C thực sự xảy ra.

Ghi nhớ

Điều gì xảy ra khi DỪNG rồi KHỞI ĐỘNG một EC2 instance: | Thành phần | Kết quả | |---|---| | Dữ liệu instance store | MẤT | | Máy chủ vật lý | có thể ĐỔI | | Địa chỉ IPv4 công khai (thông thường) | MẤT, được cấp cái mới | | Elastic IP | GIỮ NGUYÊN | | IP riêng | giữ nguyên | | Dữ liệu EBS volume | giữ nguyên | | ENI chính | giữ nguyên | | Instance ID | giữ nguyên |

Bảng này là nội dung cốt lõi của câu hỏi — và hai dòng về IP là chỗ dễ nhầm nhất.

EBS và instance store — bảng phân biệt: | | EBS | Instance store | |---|---|---| | Bền vững qua stop/start | ✅ | ❌ MẤT | | Vị trí | mạng lưu trữ | đĩa vật lý trên host | | Hiệu năng | rất tốt | cao hơn — không qua mạng | | Snapshot | ✅ | ❌ | | Chi phí | tính riêng | bao gồm trong giá instance |

Instance store vẫn hữu ích cho:

Bộ nhớ đệm, dữ liệu tạm, không gian scratch
Dữ liệu đã được sao chép ở tầng ứng dụng (một số cụm NoSQL)
Workload cần I/O cực cao và chấp nhận mất dữ liệu

Ba trạng thái và ảnh hưởng tới dữ liệu: | Thao tác | Instance store | EBS | Elastic IP | |---|---|---|---| | Reboot | giữ | giữ | giữ | | Stop / Start | MẤT | giữ | giữ | | Terminate | MẤT | tuỳ DeleteOnTermination | tách ra, vẫn thuộc về bạn | | Hibernate / Start | MẤT | giữ | giữ |

Chú ý dòng đầu: REBOOT không mất dữ liệu instance store — vì instance vẫn ở trên cùng máy chủ vật lý. Chỉ stop/start mới mất.

Ba lưu ý về Elastic IP: | Lưu ý | Chi tiết | |---|---| | Giữ qua stop/start | ← điểm loại của phương án D | | Tính phí khi KHÔNG gắn vào instance đang chạy | nhớ giải phóng khi không dùng | | Giới hạn 5 EIP mỗi Region | tăng được nếu cần |

Dòng giữa là chi tiết chi phí đáng nhớ: khi instance được dừng qua đêm, Elastic IP vẫn tính phí vì nó không gắn vào instance đang chạy. Với mẫu dùng của đề, đó là khoản chi nhỏ nhưng liên tục.

Và lời khuyên kiến trúc cho tình huống của đề: | Vấn đề | Cách sửa | |---|---| | Dữ liệu trên instance store mất mỗi đêm | chuyển sang EBS volume | | Nếu cần chia sẻ giữa nhiều máy | EFS hoặc S3 | | Nếu chỉ là cache | ElastiCache — không mất khi instance dừng |

Chuyển sang EBS là thay đổi nhỏ mà giải quyết triệt để: dữ liệu sống sót qua mọi chu kỳ dừng/khởi động, và bạn còn chụp snapshot được.

Và một lưu ý về chính chiến lược tiết kiệm mà đề mô tả: dừng instance ngoài giờ tiết kiệm được tới 65% chi phí compute cho ứng dụng chỉ dùng 8 giờ mỗi ngày, 5 ngày mỗi tuần. Đó là tối ưu đáng làm — chỉ cần đảm bảo dữ liệu nằm ở nơi bền vững trước khi bật lịch tự động.

Đáp án

B và E.

• B — Dùng Expedited Retrieval để truy cập dữ liệu tài chính
• E — Mua provisioned retrieval capacity

Vì sao đúng

Đề nêu ba yêu cầu, và cặp B+E là cách duy nhất đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Lấy dữ liệu trong DƯỚI 15 PHÚT | Expedited Retrieval — 1 tới 5 phút | | Năng lực truy xuất phải SẴN SÀNG KHI CẦN | provisioned capacity đảm bảo điều đó | | Xử lý tới 150 MB/giây thông lượng | mỗi đơn vị provisioned capacity cho ~150 MB/giây |

Ba chế độ truy xuất của Glacier Flexible Retrieval: | Chế độ | Thời gian | Chi phí | |---|---|---| | Expedited | 1–5 phút | cao nhất | | Standard | 3–5 giờ | vừa | | Bulk | 5–12 giờ | rẻ nhất |

Chỉ Expedited đạt được "dưới 15 phút" — hai chế độ còn lại tính bằng giờ.

Và provisioned capacity giải quyết vấn đề mà nhiều người không biết:

Expedited retrieval theo yêu cầu (on-demand):
    → AWS phục vụ theo dung lượng còn trống tại thời điểm đó
    → lúc cao điểm có thể bị TỪ CHỐI với lỗi
      "InsufficientCapacityException"
    → KHÔNG có đảm bảo nào

Provisioned capacity:
    → bạn TRẢ TIỀN TRƯỚC để dành riêng năng lực
    → mỗi đơn vị: ít nhất 3 lần truy xuất expedited mỗi 5 phút
    → và tới 150 MB/giây thông lượng
    → ĐẢM BẢO khi cần

Đề nói rõ "should be able to retrieve the required data in under 15 minutes UNDER ALL CIRCUMSTANCES" và "retrieval capacity is available when you need it" — đó chính xác là mô tả của provisioned capacity.

Và con số 150 MB/giây trong đề khớp đúng với thông số của một đơn vị provisioned capacity — đây không phải trùng hợp.

aws glacier purchase-provisioned-capacity --account-id -

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

• **C. Dùng Bulk Retrieval để truy cập dữ liệu — đây là phương án gần nhất về mặt cũng là một chế độ truy xuất, nhưng nó mất 5–12 giờ — hoàn toàn không đáp ứng yêu cầu dưới 15 phút.
• **A. Truy xuất dữ liệu bằng Glacier Select — giải quyết vấn đề khác: Glacier Select cho phép chạy truy vấn SQL trên dữ liệu lưu trữ để chỉ lấy phần cần thiết. Nó không đảm bảo thời gian truy xuất và không phải cơ chế bảo đảm năng lực.
• **D. Khai một dải (range) cụ thể của kho lưu trữ để truy xuất — là kỹ thuật tối ưu, không phải bảo đảm: truy xuất theo dải giảm lượng dữ liệu phải lấy về, nhưng nó không thay đổi thời gian chờ và không đảm bảo năng lực.

Ghi nhớ

Ba chế độ truy xuất của S3 Glacier Flexible Retrieval: | Chế độ | Thời gian | Dùng khi | |---|---|---| | Expedited | 1–5 phút | cần gấp — kiểm toán bất ngờ ← câu này | | Standard | 3–5 giờ | mặc định | | Bulk | 5–12 giờ | khối lượng lớn, không gấp — rẻ nhất |

Với Glacier Deep Archive thì chỉ có hai chế độ: | Chế độ | Thời gian | |---|---| | Standard | 12 giờ | | Bulk | 48 giờ |

Deep Archive KHÔNG có Expedited — nếu yêu cầu là dưới 15 phút, Deep Archive hoàn toàn không dùng được.

Ba lớp Glacier — chọn theo yêu cầu thời gian: | Lớp | Truy xuất nhanh nhất | Chi phí lưu trữ | |---|---|---| | Glacier Instant Retrieval | MILI GIÂY | cao nhất trong nhóm | | Glacier Flexible Retrieval | 1–5 phút (Expedited) | vừa | | Glacier Deep Archive | 12 giờ | rẻ nhất |

Và một lựa chọn đáng cân nhắc cho tình huống của đề: Glacier Instant Retrieval.

Nó cho truy xuất MILI GIÂY mà không cần provisioned capacity
    → đơn giản hơn nhiều
    → đắt hơn về lưu trữ nhưng rẻ hơn về vận hành

(Instant Retrieval ra mắt sau khi câu hỏi này được soạn — nên đáp án dùng Expedited + provisioned capacity là đúng theo bộ đề, nhưng nếu thiết kế mới hôm nay, Instant Retrieval thường là lựa chọn tốt hơn cho yêu cầu "dưới 15 phút, mọi hoàn cảnh".)

Hai đặc điểm của provisioned capacity: | Đặc điểm | Chi tiết | |---|---| | Mua theo đơn vị | mỗi đơn vị có hiệu lực 1 THÁNG | | Mỗi đơn vị đảm bảo | 3 lần truy xuất expedited mỗi 5 phút, tới 150 MB/giây |

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | 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 dữ liệu có thể bị xoá sớm.

Ba loại chi phí khi dùng Glacier: | Loại | Chi tiết | |---|---| | Lưu trữ | theo GB-tháng | | Truy xuất | theo GB, KHÁC NHAU nhiều giữa các chế độ | | Request | theo số lượng |

Expedited đắt hơn Bulk khoảng 10 lần về phí truy xuất — nên chỉ dùng khi thực sự cần gấp.

Và một lời khuyên về thiết kế cho yêu cầu kiểm toán bất ngờ: cân nhắc giữ dữ liệu của 12 tháng gần nhất ở Standard-IA hoặc Glacier Instant Retrieval, chỉ chuyển dữ liệu cũ hơn sang Flexible Retrieval. Kiểm toán thường tập trung vào giai đoạn gần đây, nên cách này đáp ứng yêu cầu tốc độ mà vẫn tiết kiệm cho phần lớn dữ liệu.

Đáp án

C — Amazon S3 Transfer Acceleration.

Vì sao đúng

Đề nêu ba điều kiện, và Transfer Acceleration khớp với cả ba: | Điều kiện | Cơ chế | |---|---| | Người dùng khắp thế giới tải lên MỘT bucket tập trung | truyền qua khoảng cách xa | | Cải thiện thông lượng, tốc độ NHẤT QUÁN | đi qua mạng xương sống của AWS | | Bất kể vị trí người dùng | hơn 600 điểm biên toàn cầu |

Cách hoạt động:

KHÔNG có acceleration:
    Người dùng ở châu Âu
        → INTERNET CÔNG CỘNG (nhiều chặng, chất lượng biến động)
        → bucket ở us-east-1
    → thông lượng thấp và không ổn định

CÓ acceleration:
    Người dùng
        → điểm biên CloudFront GẦN NHẤT (vài mili giây)
        → MẠNG XƯƠNG SỐNG CỦA AWS (tối ưu, ổn định)
        → bucket ở us-east-1

Và "consistently fast" là điểm mấu chốt: qua Internet công cộng, tốc độ phụ thuộc vào tuyến đường và tình trạng mạng lúc đó. Qua mạng AWS, nó ổn định và dự đoán được.

Cấu hình rất gọn:

aws s3api put-bucket-accelerate-configuration   --bucket kho-giao-dich --accelerate-configuration Status=Enabled

# Phía client chỉ đổi endpoint
aws configure set default.s3.use_accelerate_endpoint true

Và AWS có công cụ đo trước khi cam kết:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
    en/accelerate-speed-comparsion.html

Chi phí chỉ phát sinh khi thực sự có tăng tốc — AWS không tính phí nếu đường thường nhanh hơn.

Và với "terabytes of transactional data", hãy kết hợp với multipart upload song song — hai kỹ thuật bổ trợ nhau: acceleration tối ưu đường đi, multipart tận dụng hết băng thông.

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

• **B. AWS Direct Connect — đây là phương án gần nhất về mặt cũng cải thiện chất lượng đường truyền, nhưng nó không phù hợp với tình huống: Direct Connect là kết nối vật lý chuyên dụng từ một trung tâm dữ liệu cụ thể tới AWS. Với người dùng phân tán khắp thế giới, bạn không thể kéo cáp riêng cho từng người.
• **D. Dùng CloudFront Origin Access Control (OAC) — nhầm chức năng và nhầm chiều: OAC là cơ chế bảo mật cho phép CloudFront đọc từ bucket S3 riêng tư. Nó phục vụ phân phối nội dung xuống người dùng, không tăng tốc tải lên.
• **A. FTP — giao thức cũ và không liên quan: S3 không hỗ trợ FTP gốc, và FTP không có cơ chế tăng tốc nào. (AWS Transfer Family cung cấp endpoint SFTP cho S3, nhưng đó là để tương thích giao thức, không phải để tăng tốc.)

Ghi nhớ

Ba dịch vụ tăng tốc của AWS — phân biệt rõ: | Dịch vụ | Chiều | Cache | Dùng cho | |---|---|---|---| | S3 Transfer Acceleration | tải LÊN và tải xuống S3 | ❌ | truyền dữ liệu qua khoảng cách xa ← câu này | | CloudFront | phân phối XUỐNG người dùng | ✅ | nội dung web, tải lặp lại | | Global Accelerator | TCP/UDP | ❌ | ứng dụng không phải HTTP, cần IP tĩnh |

Câu hỏi phân biệt:

"upload to S3 from around the world" → Transfer Acceleration "deliver content to users" → CloudFront "TCP/UDP application, static IP" → Global Accelerator

Ba đặc điểm của Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Dùng mạng biên của CloudFront | hơn 600 điểm hiện diện | | Endpoint riêng | bucket.s3-accelerate.amazonaws.com | | Chỉ tính phí khi CÓ tăng tốc thật | công bằng và đo được trước |

Ba yêu cầu để bật:

① Tên bucket KHÔNG chứa dấu chấm (.)
② Tên bucket tuân thủ quy tắc DNS
③ Bật ở mức bucket

Điều kiện đầu là ràng buộc thật — bucket tên du.lieu.cong.ty không dùng được Transfer Acceleration.

Ba cách đưa dữ liệu lớn vào AWS — chọn theo băng thông: | Cách | Phù hợp khi | |---|---| | Transfer Acceleration + multipart | có băng thông tốt, người dùng ở xa ← câu này | | AWS DataSync | đồng bộ định kỳ từ tại chỗ, có agent | | AWS Snow Family | băng thông hạn chế, khối lượng rất lớn |

Quy tắc ước lượng: nếu truyền qua mạng mất hơn một tuần, cân nhắc Snow Family.

Ba tham số tối ưu cho multipart upload — dùng kèm acceleration: | Tham số | Ảnh hưởng | |---|---| | max_concurrent_requests | số phần tải song song — quan trọng nhất | | multipart_chunksize | kích thước mỗi phần | | multipart_threshold | ngưỡng chuyển sang multipart |

Và một lifecycle rule bắt buộc cho bucket nhận nhiều tệp lớn:

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Multipart thất bại để lại các phần đã tải, và chúng tính phí lưu trữ mãi mãi mà không hiện trong danh sách object.

Ba cân nhắc cho kiến trúc nhận dữ liệu toàn cầu: | Cân nhắc | Cách làm | |---|---| | Client tải THẲNG lên S3 | pre-signed URL — dữ liệu không qua máy chủ ứng dụng | | Xử lý sau khi tải lên | S3 event notification → Lambda | | Cân nhắc bucket theo Region | nếu quy định về vị trí dữ liệu yêu cầu |

Dòng cuối đáng cân nhắc cho nền tảng giao dịch: một số quốc gia yêu cầu dữ liệu tài chính phải lưu trong lãnh thổ. Khi đó kiến trúc "một bucket tập trung" có thể không hợp pháp — và giải pháp là bucket theo khu vực với cơ chế tổng hợp riêng.

Đáp án

B — Dùng Lifecycle Policy trong S3 để chuyển dữ liệu lỗi thời sang Glacier.

Vì sao đúng

Đề cần tự động chuyển dữ liệu cũ sang lớp lưu trữ rẻ hơn sau một khoảng thời gian — và lifecycle policy là tính năng gốc của S3 cho đúng việc đó.

Cấu hình rất gọn và không cần mã:

{
  "Rules": [{
    "ID": "chuyen-du-lieu-cu-sang-glacier",
    "Status": "Enabled",
    "Filter": {"Prefix": "ho-so/"},
    "Transitions": [
      {"Days": 90,  "StorageClass": "STANDARD_IA"},
      {"Days": 365, "StorageClass": "GLACIER"},
      {"Days": 730, "StorageClass": "DEEP_ARCHIVE"}
    ]
  }]
}

Bốn lợi ích so với việc tự viết: | 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 object mới tự động | tệp mới cũng theo cùng chính sách | | Miễn phí | chỉ trả phí chuyển đổi mỗi object |

Và nó áp được cho từng nhóm object qua prefix hoặc tag — nên bạn có chính sách khác nhau cho từng loại dữ liệu trong cùng một bucket.

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

• **A. Dùng một EC2 instance với scheduled job 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 dựng máy chạy cron, viết script, xử lý lỗi, quản lý thông tin đăng nhập, giám sát. Và máy chạy 24/7 tốn tiền cho một 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 Timestream — sai loại dịch vụ: đây là cơ sở dữ liệu chuỗi thời gian cho dữ liệu IoT và telemetry. Không liên quan tới quản lý vòng đời object S3.

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 là tối ưu chi phí âm thầm mà đáng làm cho mọi bucket: multipart upload thất bại để lại các phần đã tải, và chúng tính phí mãi mãi mà không hiện trong danh sách object.

Các lớp lưu trữ và 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 — muốn đưa dữ liệu trở lại Standard thì phải sao chép hoặc restore.

Ràng buộc thời gian lưu tối thiểu — ảnh hưởng trực tiếp tới chi phí: | 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í — nên đừng chuyển dữ liệu ngắn hạn sang các lớp này.

Và có 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
    → không đặt Days < 30 cho hai lớp đó được

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

Ba cách lọc object trong lifecycle rule: | Cách | Ví dụ | |---|---| | Prefix | "Prefix": "log/2025/" | | Tag | "Tag": {"Key": "LoaiDuLieu", "Value": "loi-thoi"} | | Kích thước | ObjectSizeGreaterThan, ObjectSizeLessThan |

Lọc theo tag rất linh hoạt: ứng dụng gắn tag khi ghi object, và lifecycle tự áp chính sách phù hợp — không cần tổ chức dữ liệu theo thư mục.

Lọc theo kích thước đáng biết: chuyển object rất nhỏ sang Glacier có thể đắt hơn do phí overhead cho mỗi object (Glacier tính thêm 32 KB metadata mỗi object). Đặt ObjectSizeGreaterThan: 131072 (128 KB) tránh được điều đó.

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 | bạn đặt theo TUỔI | AWS theo MẪU TRUY CẬP thực tế | | Phù hợp | biết rõ dữ liệu nào nguội khi nào ← câu này | mẫu truy cập khó đoán | | Phí truy xuất | có (ở lớp IA và Glacier) | KHÔNG | | Phí giám sát | không | có, nhỏ theo object |

Với "obsolete data sau một khoảng thời gian" như đề mô tả — tức là quy tắc rõ ràng theo tuổi — lifecycle rule là lựa chọn đúng và rẻ hơn.

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Lifecycle chạy MỘT LẦN mỗi ngày | không đảm bảo chuyển đúng vào giờ thứ N | | Có phí cho mỗi lần chuyển đổi object | với hàng triệu object nhỏ, khoản này đáng kể | | Kiểm tra thời gian truy xuất của lớp đích | Deep Archive mất 12–48 giờ |

Và một lời khuyên khi thiết kế chính sách: đo mẫu truy cập thật trước khi đặt số ngày. Dùng S3 Storage Lens hoặc S3 Storage Class Analysis — chúng cho biết object thực sự ngừng được truy cập sau bao lâu, thay vì đoán một con số rồi phải trả phí truy xuất cao vì chuyển quá sớm.

Đáp án

A và B — đây là hai phương án KHÔNG phù hợp để giảm thiểu DDoS:

• A — Dùng Dedicated EC2 Instance để mỗi instance có hiệu năng tối đa
• B — Thêm nhiều Elastic Fabric Adapter (EFA) vào mỗi instance để tăng băng thông mạng

Vì sao đúng

Đề hỏi phương án KHÔNG phù hợp — nên phải nhận ra cái nào không liên quan tới DDoS.

A — Dedicated Instance giải quyết vấn đề hoàn toàn khác:

Dedicated Instance = phần cứng vật lý KHÔNG chia sẻ với khách hàng khác
    → phục vụ yêu cầu TUÂN THỦ (một số quy định cấm hạ tầng dùng chung)
    → hoặc yêu cầu về giấy phép phần mềm tính theo lõi vật lý
    → KHÔNG liên quan gì tới việc chống lưu lượng độc hại

Và nó còn không giúp gì về hiệu năng mạng — băng thông vẫn theo loại instance.

B — EFA cũng sai mục đích:

Elastic Fabric Adapter = giao diện mạng cho HPC
    → bỏ qua hệ điều hành (OS-bypass) để giảm độ trễ giữa các NODE
    → dùng cho MPI, NCCL — giao tiếp NỘI BỘ trong cụm
    → KHÔNG tăng băng thông với Internet
    → KHÔNG lọc lưu lượng độc hại

Điểm mấu chốt: tăng dung lượng KHÔNG PHẢI là chống DDoS.

Kẻ tấn công có thể sinh lưu lượng lớn hơn bất kỳ dung lượng nào bạn mua
    → và bạn TRẢ TIỀN cho dung lượng đó
    → chống DDoS phải là LỌC và HẤP THỤ Ở BIÊN, không phải mua thêm máy

Vì sao ba phương án còn lại là biện pháp ĐÚNG

(Câu hỏi tìm cái KHÔNG phù hợp, nên ba cái này đều hợp lệ.)

• **E. Dùng AWS Shield và AWS WAF — là bộ đôi chống DDoS chính thức: Shield cho tầng 3/4, WAF cho tầng 7.
• **C. Dùng CloudFront phân phối cả nội dung tĩnh lẫn động — hấp thụ tấn công ở hơn 600 điểm biên, và có Shield Standard sẵn.
• **D. Dùng ALB với Auto Scaling group; đặt RDS trong private subnet — ALB phân phối tải và tích hợp WAF; private subnet giảm diện tích phơi ra của cơ sở dữ liệu.

Ghi nhớ

Ba lớp phòng thủ DDoS trên AWS: | Lớp | Chống | Chi phí | |---|---|---| | Shield Standard | tầng 3/4 phổ biến | MIỄN PHÍ, tự động | | AWS WAF | tầng 7 theo quy tắc | tính phí | | Shield Advanced | nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Bốn nguyên tắc kiến trúc chống DDoS: | Nguyên tắc | Cách làm | |---|---| | Đẩy lưu lượng ra BIÊN | CloudFront, Route 53 hấp thụ trên hạ tầng toàn cầu | | Giảm diện tích phơi ra | origin trong private subnet, chỉ nhận từ CloudFront | | Lọc ở tầng 7 | WAF với rate-based rule và managed rule | | Biết khi bị tấn công | alarm trên DDoSDetected (Shield Advanced) |

Và nguyên tắc phản diện — điều KHÔNG nên làm:

✗ Mua máy to hơn để "chịu được"
✗ Tăng băng thông instance
✗ Dùng Dedicated Instance
    → kẻ tấn công luôn sinh được nhiều hơn
    → và bạn trả tiền cho chính cuộc tấn công

Ba khái niệm hay bị nhầm với biện pháp bảo mật: | Khái niệm | Thực sự là gì | |---|---| | Dedicated Instance / Dedicated Host | phần cứng không chia sẻ — cho TUÂN THỦ và GIẤY PHÉP | | Elastic Fabric Adapter (EFA) | mạng độ trễ thấp cho HPC — giao tiếp NỘI BỘ cụm | | Placement group | vị trí vật lý của instance — cho hiệu năng hoặc sẵn sàng |

Không cái nào trong ba liên quan tới bảo mật mạng.

Dedicated Instance và Dedicated Host — phân biệt: | | Dedicated Instance | Dedicated Host | |---|---|---| | Cách ly | phần cứng không chia sẻ | cả máy chủ vật lý dành riêng | | Thấy được socket và lõi | ❌ | ✅ — cho giấy phép BYOL | | Chi phí | cao hơn shared | cao nhất |

Dedicated Host cần thiết cho giấy phép phần mềm tính theo lõi vật lý (Windows Server, SQL Server, Oracle) — đó là lý do thật để dùng nó.

Ba đặc điểm của EFA: | Đặc điểm | Chi tiết | |---|---| | OS-bypass | ứng dụng giao tiếp thẳng với phần cứng mạng | | Hỗ trợ MPI và NCCL | thư viện chuẩn của HPC và huấn luyện phân tán | | Chỉ hiệu quả TRONG cùng cluster placement group | không tăng tốc lưu lượng Internet |

Với HPC như đề mô tả, EFA vẫn là công cụ đúng — chỉ là cho mục đích hiệu năng, không phải bảo mật.

Ba cấu hình nên có nếu ứng dụng HPC phơi ra Internet: | Cấu hình | Lý do | |---|---| | Node tính toán trong PRIVATE subnet | không truy cập được từ Internet | | Chỉ endpoint API công khai qua ALB + WAF | bề mặt tấn công tối thiểu | | Shield Advanced nếu dịch vụ quan trọng | có SRT và bảo vệ chi phí |

Và một lưu ý riêng cho HPC: cụm tính toán thường có hạn mức vCPU rất lớn, nên nếu bị tấn công và Auto Scaling mở rộng theo, hoá đơn có thể tăng vọt. Đặt MaxSize hợp lý và AWS Budgets với cảnh báo là biện pháp bảo vệ tài chính đơn giản mà hiệu quả.

Đáp án

D — Cấu hình thuộc tính CreationPolicy cho instance trong template CloudFormation. Gửi tín hiệu thành công sau khi ứng dụng đã cài đặt và cấu hình xong bằng helper script cfn-signal.

Vì sao đúng

Đề nêu yêu cầu rõ: đảm bảo các thành phần đã chạy đúng TRƯỚC KHI việc tạo stack tiếp tục — và CreationPolicy là cơ chế cho đúng việc đó.

Vấn đề mà nó giải quyết:

KHÔNG có CreationPolicy:
    CloudFormation tạo EC2 instance
        → API trả về "đã tạo xong"
        → CloudFormation coi tài nguyên HOÀN TẤT
        → chuyển sang tài nguyên tiếp theo
    NHƯNG: SQL Server chưa cài xong, AD chưa join, SharePoint chưa cấu hình
        → tài nguyên phụ thuộc khởi tạo trên nền chưa sẵn sàng → hỏng

CreationPolicy khiến CloudFormation CHỜ tín hiệu:

MaySharePoint:
  Type: AWS::EC2::Instance
  CreationPolicy:
    ResourceSignal:
      Count: 1
      Timeout: PT30M        # chờ tối đa 30 phút
  Properties:
    UserData:
      Fn::Base64: !Sub |
        <powershell>
        # cài đặt và cấu hình SharePoint...
        cfn-signal.exe -e $lastexitcode --stack ${AWS::StackName} `
          --resource MaySharePoint --region ${AWS::Region}
        </powershell>

Luồng đầy đủ:

CloudFormation tạo instance
    ↓ CHỜ (tối đa Timeout)
User data chạy: cài SQL Server, join AD, cấu hình SharePoint
    ↓ xong → gọi cfn-signal với mã thoát 0
CloudFormation nhận tín hiệu THÀNH CÔNG
    ↓ đánh dấu tài nguyên hoàn tất
    → tiếp tục tạo tài nguyên phụ thuộc

Nếu hết thời gian chờ hoặc nhận tín hiệu thất bại, CloudFormation ROLLBACK cả stack — đúng hành vi mong muốn cho một môi trường phức tạp.

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

• **A. Cấu hình thuộc tính DependsOn; gửi tín hiệu thành công bằng cfn-init — đây là phương án gần nhất và DependsOn có liên quan tới thứ tự, nhưng nó chỉ đảm bảo thứ tự TẠO tài nguyên, không chờ ứng dụng bên trong sẵn sàng. Và cfn-init cài đặt phần mềm, nó KHÔNG gửi tín hiệu — việc đó là của cfn-signal.
• **B. Cấu hình UpdatePolicy; gửi tín hiệu bằng cfn-signal — sai thời điểm áp dụng: UpdatePolicy điều khiển hành vi khi CẬP NHẬT tài nguyên (chủ yếu cho Auto Scaling group và rolling update). Đề nói về việc TẠO stack.
• **C. Cấu hình UpdateReplacePolicy; gửi tín hiệu bằng cfn-signal — sai mục đích hoàn toàn: UpdateReplacePolicy quyết định làm gì với tài nguyên CŨ khi nó bị thay thế trong lúc cập nhật (giữ lại, chụp snapshot, hay xoá).

Ghi nhớ

Bốn attribute điều khiển hành vi của tài nguyên CloudFormation: | Attribute | Việc | |---|---| | CreationPolicy | CHỜ tín hiệu thành công trước khi coi là tạo xong ← câu này | | UpdatePolicy | hành vi khi CẬP NHẬT (rolling update cho ASG) | | DeletionPolicy | làm gì khi XOÁ stack (Retain, Snapshot, Delete) | | UpdateReplacePolicy | làm gì với tài nguyên cũ khi bị thay thế | | DependsOn | thứ tự TẠO tài nguyên |

DependsOn và CreationPolicy giải quyết hai vấn đề khác nhau:

DependsOn:       "tạo B SAU KHI A được tạo"
                 → chỉ về THỨ TỰ

CreationPolicy:  "A chưa xong cho tới khi nó BÁO là đã sẵn sàng"
                 → về TRẠNG THÁI THẬT bên trong

Thường dùng CẢ HAI cùng nhau.

Bốn helper script của CloudFormation trên EC2: | Script | Việc | |---|---| | cfn-init | đọc metadata AWS::CloudFormation::Init — cài gói, ghi tệp, chạy lệnh | | cfn-signal | GỬI TÍN HIỆU thành công hoặc thất bại ← câu này | | cfn-get-metadata | lấy metadata của tài nguyên | | cfn-hup | theo dõi thay đổi metadata và chạy lại cấu hình |

Phân biệt cfn-init và cfn-signal là điểm sai của phương án A — chúng thường dùng cùng nhau nhưng làm hai việc khác nhau:

cfn-init.exe -s ${AWS::StackName} -r MaySharePoint --region ${AWS::Region}
cfn-signal.exe -e $lastexitcode --stack ${AWS::StackName} `
  --resource MaySharePoint --region ${AWS::Region}

Hai tài nguyên hỗ trợ CreationPolicy: | Tài nguyên | Đặc điểm | |---|---| | AWS::EC2::Instance | chờ một tín hiệu | | AWS::AutoScaling::AutoScalingGroup | chờ N tín hiệu (Count) từ N instance | | AWS::CloudFormation::WaitCondition | cơ chế chờ tổng quát hơn |

Với ASG, Count phải khớp số instance mong đợi — nếu không stack sẽ chờ tới hết timeout rồi rollback.

Ba cấu hình quan trọng của ResourceSignal: | Cấu hình | Chi tiết | |---|---| | Count | số tín hiệu cần nhận | | Timeout | định dạng ISO 8601: PT30M = 30 phút, tối đa 12 giờ | | — | hết timeout mà chưa đủ tín hiệu → rollback |

Với môi trường phức tạp như SharePoint + SQL Server + AD, đặt timeout rộng rãi — cài đặt Windows và join domain có thể mất khá lâu.

Ba lưu ý khi dùng cfn-signal: | Lưu ý | Chi tiết | |---|---| | Instance cần quyền cloudformation:SignalResource | qua IAM role | | Cần đường mạng tới endpoint CloudFormation | private subnet cần VPC endpoint hoặc NAT | | Luôn gửi tín hiệu, kể cả khi lỗi | -e $lastexitcode để CloudFormation biết mà rollback sớm |

Dòng cuối quan trọng: nếu script lỗi mà không gửi tín hiệu, stack sẽ chờ tới hết timeout rồi mới rollback — lãng phí thời gian và làm việc chẩn đoán khó hơn.

Và với môi trường nhiều thành phần phụ thuộc như đề mô tả, cân nhắc AWS Systems Manager Automation hoặc AWS Launch Wizard for SharePoint — chúng đóng gói sẵn quy trình triển khai phức tạp này, ít công hơn nhiều so với tự viết template từ đầu.

Đáp án

C — Spot Instances.

Vì sao đúng

Đề nêu hai đặc điểm, và cả hai đều chỉ thẳng tới Spot: | Đặc điểm | Cơ chế | |---|---| | Môi trường KHÔNG PHẢI sản xuất | không có yêu cầu SLA nghiêm ngặt | | Batch job không ưu tiên, CÓ THỂ BỊ GIÁN ĐOẠN bất cứ lúc nào | đúng định nghĩa của workload phù hợp với Spot |

Spot Instance là dung lượng dư của AWS bán với giá rẻ:

AWS có phần cứng chưa dùng tới
    → bán với giá giảm tới 90% so với On-Demand
    → ĐỔI LẠI: có thể THU HỒI khi AWS cần dung lượng đó
    → báo trước 2 PHÚT qua IMDS hoặc EventBridge

Và cụm "can be interrupted at any time" trong đề chính là điều kiện tiên quyết của Spot — nếu workload không chịu được gián đoạn thì Spot không dùng được.

Mức tiết kiệm: | Loại mua | Chi phí tương đối | |---|---| | On-Demand | 100% | | Reserved Instance / Savings Plan | 40–70% | | Spot | 10–40% |

Với batch job không ưu tiên chạy trong môi trường thử nghiệm, không có lý do gì trả giá On-Demand.

Xử lý cảnh báo thu hồi:

{"source": ["aws.ec2"],
 "detail-type": ["EC2 Spot Instance Interruption Warning"]}

→ Lambda hoặc script trên instance lưu checkpoint và rút khỏi cụm trong hai phút.

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

• **B. On-Demand Instances — đây là phương án gần nhất về mặt linh hoạt, nhưng nó đắt nhất: bạn trả giá đầy đủ cho tính linh hoạt và đảm bảo dung lượng — hai thứ mà workload này không cần.
• **A. Reserved Instances — sai mô hình cam kết: RI đòi cam kết 1 hoặc 3 năm cho một cấu hình cụ thể. Batch job không ưu tiên trong môi trường phi sản xuất thường có tải biến động và không chạy liên tục — cam kết dài hạn là lãng phí.
• **D. On-Demand Capacity Reservations — ngược với nhu cầu: nó giữ trước dung lượng trong một AZ để đảm bảo luôn có máy khi cần. Bạn trả tiền kể cả khi không dùng, và workload này không cần đảm bảo gì.

Ghi nhớ

Năm mô hình mua EC2 — bảng cần thuộc: | Mô hình | Giảm giá | Cam kết | Phù hợp | |---|---|---|---| | On-Demand | 0% | không | tải không đoán được, ngắn hạn | | Savings Plans | tới 72% | 1 hoặc 3 năm (theo USD/giờ) | linh hoạt nhất trong nhóm cam kết | | Reserved Instances | tới 72% | 1 hoặc 3 năm (theo cấu hình) | tải ổn định, cấu hình cố định | | Spot | tới 90% | không, nhưng CÓ THỂ BỊ THU HỒI | workload chịu được gián đoạn ← câu này | | Dedicated Host | — | tuỳ chọn | giấy phép BYOL, tuân thủ |

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

"fault-tolerant", "flexible", "can be interrupted", "batch", "non-critical" → Spot "steady state", "predictable usage", "1-year commitment" → Savings Plan hoặc RI "unpredictable", "short-term", "cannot be interrupted" → On-Demand "guaranteed capacity in a specific AZ" → Capacity Reservation

Ba workload phù hợp với Spot: | Workload | Lý do | |---|---| | Xử lý lô, ETL | chạy lại được từ đầu hoặc từ checkpoint | | Kết xuất đồ hoạ, mã hoá video | chia nhỏ được thành nhiều công việc độc lập | | Huấn luyện mô hình học máy | có checkpoint | | Môi trường CI/CD, dev/test | ← câu này |

Ba workload KHÔNG nên dùng Spot: | Workload | Lý do | |---|---| | Cơ sở dữ liệu chính | mất instance là mất dịch vụ | | Ứng dụng có trạng thái không sao lưu | dữ liệu mất | | Dịch vụ có SLA nghiêm ngặt | không đảm bảo dung lượng |

Ba cách giảm rủi ro khi dùng Spot: | Cách | Lợi ích | |---|---| | Dùng NHIỀU loại instance và NHIỀU AZ | khả năng bị thu hồi đồng loạt thấp hơn nhiều | | Lắng nghe cảnh báo 2 phút | lưu checkpoint, rút khỏi load balancer | | Spot Fleet với capacity-optimized | chọn pool có ít khả năng bị thu hồi nhất |

Chiến lược phân bổ của Spot Fleet: | Chiến lược | Đặc điểm | |---|---| | capacity-optimized | chọn pool dư dung lượng nhất — ÍT bị thu hồi nhất | | lowest-price | rẻ nhất, nhưng dễ bị thu hồi hơn | | diversified | trải đều nhiều pool |

capacity-optimized là khuyến nghị của AWS cho hầu hết trường hợp — chênh lệch giá nhỏ nhưng độ ổn định cao hơn hẳn.

Mixed instance policy trong Auto Scaling group là mẫu rất phổ biến:

{"OnDemandBaseCapacity": 2,
 "OnDemandPercentageAboveBaseCapacity": 20,
 "SpotAllocationStrategy": "capacity-optimized"}

Giữ một mức nền On-Demand để đảm bảo dịch vụ, phần vượt trên đó dùng Spot — kết hợp độ tin cậy với tiết kiệm.

Và một lưu ý về giá Spot hiện nay: giá không còn biến động theo cơ chế đấu giá như trước — AWS điều chỉnh mượt theo cung cầu dài hạn. Nên bạn không cần đặt giá thầu; chỉ cần chấp nhận rủi ro bị thu hồi.

Đáp án

B — Spot Instances.

Vì sao đúng

Đề mô tả một kiến trúc đã được thiết kế sẵn để chịu gián đoạn — và đó là điều kiện lý tưởng cho Spot:

"Nếu tiến trình bị gián đoạn, video sẽ được máy khác chuyển mã
 dựa trên hệ thống hàng đợi"
    ↓
Ứng dụng ĐÃ CHỊU ĐƯỢC việc mất instance giữa chừng
    → Spot không gây thiệt hại gì

Hàng đợi là thứ khiến kiến trúc này an toàn với Spot:

Worker kéo công việc từ queue
    ↓ đang chuyển mã thì bị thu hồi
Thông điệp KHÔNG được xoá khỏi queue
    ↓ hết visibility timeout
Thông điệp XUẤT HIỆN LẠI
    ↓ worker khác nhận và làm lại
→ không mất công việc nào

Và ba đặc điểm khác của tình huống cũng khớp với Spot: | Đặc điểm | Vì sao phù hợp | |---|---| | Chỉ cần cho tới khi xử lý hết tồn đọng | tạm thời — không cam kết dài hạn được | | Thêm nhiều máy cùng lúc | Spot cho phép mở rộng lớn với chi phí thấp | | Không có yêu cầu về thời hạn nghiêm ngặt | chậm hơn một chút cũng chấp nhận được |

Mức tiết kiệm rất đáng kể:

Chuyển mã video là workload NẶNG TÍNH TOÁN
    → thường dùng instance loại c hoặc g (có GPU)
    → những loại này đắt
    → giảm 70–90% với Spot là khoản tiết kiệm lớn

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

• **D. On-Demand Instances — đây là phương án gần nhất về mặt cũng linh hoạt và không cam kết, nhưng nó đắt hơn nhiều: bạn trả giá đầy đủ cho việc đảm bảo dung lượng — thứ mà kiến trúc này không cần vì đã có hàng đợi lo việc thử lại.
• **A. Reserved Instances — sai mô hình cam kết: RI đòi cam kết 1 hoặc 3 năm. Đề nói rõ instance chỉ cần cho tới khi xử lý hết tồn đọng — có thể vài ngày hoặc vài tuần. Cam kết một năm cho nhu cầu vài tuần là lãng phí lớn.
• **C. Dedicated Instances — đắt nhất và sai mục đích: Dedicated Instance đảm bảo phần cứng không chia sẻ với khách hàng khác — phục vụ yêu cầu tuân thủ hoặc giấy phép phần mềm. Nó không liên quan gì tới bài toán này.

Ghi nhớ

Năm mô hình mua EC2: | Mô hình | Giảm giá | Cam kết | |---|---|---| | On-Demand | 0% | không | | Savings Plans | tới 72% | 1 hoặc 3 năm (theo USD/giờ) | | Reserved Instances | tới 72% | 1 hoặc 3 năm (theo cấu hình) | | Spot | tới 90% | không — nhưng có thể bị thu hồi | | Dedicated Host | — | cho giấy phép BYOL |

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

"can be interrupted"
"fault-tolerant"
"flexible start and end times"
"queue-based" / "batch processing"
"temporary capacity" / "reduce backlog"
"most cost-effective"

Đề này có tới bốn trong sáu dấu hiệu trên.

Ba kiến trúc làm cho Spot an toàn: | Kiến trúc | Cơ chế | |---|---| | Hàng đợi (SQS) + worker | thông điệp quay lại queue khi worker chết ← câu này | | Checkpoint định kỳ | chạy lại từ điểm gần nhất | | Công việc chia nhỏ, độc lập | mất một phần không ảnh hưởng phần khác |

Cấu hình SQS quan trọng cho mẫu này: | Cấu hình | Chi tiết | |---|---| | VisibilityTimeout ≥ thời gian chuyển mã | nếu ngắn hơn, video bị xử lý TRÙNG | | Dead-letter queue | video hỏng không chặn hàng đợi mãi | | Long polling | giảm chi phí lời gọi API |

Và với video dài, nên gia hạn visibility timeout trong lúc xử lý:

sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                              VisibilityTimeout=1800)

Ba cách giảm rủi ro bị thu hồi: | Cách | Lợi ích | |---|---| | Dùng NHIỀU loại instance và NHIỀU AZ | giảm mạnh khả năng bị thu hồi đồng loạt | | Chiến lược capacity-optimized | chọn pool dư dung lượng nhất | | Xử lý cảnh báo 2 phút | trả thông điệp về queue ngay thay vì chờ timeout |

Xử lý cảnh báo thu hồi cho worker chuyển mã:

# Kiểm tra IMDS định kỳ
r = requests.get('http://169.254.169.254/latest/meta-data/spot/instance-action')
if r.status_code == 200:
    sqs.change_message_visibility(QueueUrl=q, ReceiptHandle=rh,
                                  VisibilityTimeout=0)   # trả lại NGAY

Đặt visibility về 0 khiến thông điệp có sẵn lập tức — máy khác nhận ngay thay vì chờ hết timeout.

Ba cách mở rộng đội worker theo tồn đọng: | Cách | Metric | |---|---| | ASG target tracking | ApproximateNumberOfMessagesVisible / số instance | | Step scaling theo độ sâu hàng đợi | ngưỡng bậc thang | | Lambda cho video ngắn | nếu xử lý dưới 15 phút |

Mixed instance policy là cấu hình thực dụng nhất:

{"OnDemandBaseCapacity": 1,
 "OnDemandPercentageAboveBaseCapacity": 0,
 "SpotAllocationStrategy": "capacity-optimized",
 "InstancesDistribution": {"SpotMaxPrice": ""}}

Giữ một máy On-Demand làm nền để hàng đợi luôn được xử lý, phần còn lại toàn Spot — cân bằng giữa tiến độ và chi phí.

Và một lựa chọn thay thế đáng biết cho chính bài toán chuyển mã video: AWS Elemental MediaConvert. Nó là dịch vụ được quản lý, tính phí theo phút video xử lý, và không cần quản lý instance nào — với đội ngũ nhỏ, chi phí vận hành tiết kiệm được thường vượt chênh lệch giá so với tự chạy Spot.

Đáp án

A và D.

• A — Bật DynamoDB Accelerator (DAX), đảm bảo Auto Scaling được bật và tăng dung lượng đọc ghi tối đa
• D — Dùng API Gateway kết hợp Lambda, bật caching cho dữ liệu hay truy cập và bật DynamoDB global replication

Vì sao đúng

Đề nêu ba yêu cầu, và hai đáp án bổ sung nhau ở hai tầng khác nhau: | Tầng | Cơ chế | |---|---| | Tầng dữ liệu | A — DAX cache + Auto Scaling dung lượng | | Tầng API | D — API Gateway caching + Global Tables |

A — DAX giảm độ trễ và giảm cả chi phí:

Không có DAX:
    Mỗi lượt đọc → DynamoDB → tính phí RCU, độ trễ mili giây

Có DAX:
    Item nóng → phục vụ từ CACHE trong bộ nhớ
        → độ trễ MICROgiây (nhanh hơn ~10 lần)
        → KHÔNG tiêu tốn RCU của bảng
        → vừa nhanh hơn vừa rẻ hơn

Và vế "ensure that Auto Scaling is enabled" là chi tiết quan trọng nhất của câu hỏi:

Đề nói bảng được tạo bằng AWS CLI
    → Auto Scaling KHÔNG được bật mặc định
    → (chỉ Console mới bật sẵn khi tạo bảng)
    → nên phải bật tường minh

Đây chính là điểm phân biệt với phương án E — nó khẳng định sai rằng Auto Scaling bật mặc định.

D — caching ở tầng API cắt tải ngay từ gốc:

API Gateway cache
    → request lặp lại được trả lời NGAY
    → Lambda không chạy, DynamoDB không bị hỏi
    → tiết kiệm cả chi phí Lambda lẫn chi phí đọc DynamoDB

Và Global Tables cho vế "millions of users each day" phân tán toàn cầu:

Người chơi ở châu Á đọc từ bản sao ở Region châu Á
    → độ trễ thấp hơn nhiều so với gọi về một Region duy nhất

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

• **E. Vì Auto Scaling đã bật MẶC ĐỊNH nên dung lượng tự điều chỉnh; cũng bật DAX để cải thiện từ mili giây xuống micro giây — đây là phương án gần nhất và có vế DAX hoàn toàn đúng, nhưng nó sai ở tiền đề: bảng tạo bằng AWS CLI KHÔNG có Auto Scaling theo mặc định. Đây là bẫy dựa trên một chi tiết thật trong đề.
• **B. Cấu hình CloudFront với DynamoDB làm origin; cache dữ liệu trên thiết bị bằng ElastiCache — hai lỗi: DynamoDB không dùng được làm origin của CloudFront (nó là API, không phải HTTP origin phục vụ nội dung); và ElastiCache là dịch vụ trong VPC, không chạy trên thiết bị của người dùng.
• **C. Dùng IAM Identity Center để xác thực người chơi và cho họ truy cập DynamoDB trực tiếp qua SSO; đặt tay RCU/WCU cao hơn — sai đối tượng: IAM Identity Center dành cho nhân viên truy cập tài khoản AWS, không phải hàng triệu người chơi game. Và đặt tay dung lượng cao là lãng phí khi tải biến động.

Ghi nhớ

Hai chế độ dung lượng của DynamoDB: | Chế độ | Đặc điểm | |---|---| | Provisioned + Auto Scaling | rẻ hơn khi tải ổn định, cần cấu hình | | On-demand | tự mở rộng hoàn toàn, đắt hơn mỗi request nhưng không phải dự báo |

Auto Scaling có bật mặc định không — tuỳ cách tạo bảng: | Cách tạo | Auto Scaling | |---|---| | AWS Console | thường BẬT sẵn | | AWS CLI, SDK, CloudFormation | KHÔNG bật ← điểm của câu hỏi |

Đây là loại chi tiết dễ bỏ sót và gây throttling bất ngờ trong sản xuất.

Ba tầng cache trong kiến trúc này: | Tầng | Dịch vụ | Độ trễ | |---|---|---| | API | API Gateway cache | phục vụ ngay, không gọi backend | | Dữ liệu | DAX | microgiây | | Ứng dụng | ElastiCache | mili giây thấp |

Ba tầng này bổ sung nhau — mỗi tầng cắt bớt một phần tải xuống tầng dưới.

Ba đặc điểm của DAX: | Đặc điểm | Chi tiết | |---|---| | Cache ghi xuyên qua (write-through) | ghi vào DAX cũng ghi vào DynamoDB | | Tương thích API DynamoDB | đổi endpoint là xong, gần như không sửa mã | | Chạy trong VPC | cụm node do bạn cấu hình |

Lưu ý về DAX: nó chỉ tăng tốc đọc, và cache có thể trả dữ liệu hơi cũ — nên truy vấn cần dữ liệu mới nhất phải đọc thẳng DynamoDB với strongly consistent read.

Ba đặc điểm của DynamoDB Global Tables: | Đặc điểm | Chi tiết | |---|---| | Đa chủ (multi-active) | đọc và ghi được ở MỌI Region | | Sao chép nhất quán cuối cùng | thường dưới một giây | | Giải quyết xung đột "last writer wins" | ghi cùng lúc ở hai Region thì bản mới nhất thắng |

Ba lưu ý về API Gateway caching: | Lưu ý | Chi tiết | |---|---| | Tính phí theo GIỜ, không theo lượt dùng | cache lớn chạy 24/7 tốn đáng kể | | Chỉ cache phương thức GET | POST, PUT không cache | | TTL 0–3600 giây | với dữ liệu game, TTL ngắn vẫn cắt được nhiều tải |

Ngay cả TTL 5–10 giây cũng rất hiệu quả khi có hàng triệu người dùng hỏi cùng một thứ.

Ba nguyên tắc thiết kế bảng DynamoDB cho game: | Nguyên tắc | Lý do | |---|---| | Partition key độ phân biệt CAO | tránh hot partition và throttling | | Thiết kế theo MẪU TRUY CẬP | đổi khoá chính sau này đòi tạo bảng mới | | Dùng GSI cho truy vấn phụ | ví dụ bảng xếp hạng theo điểm |

Và một metric đáng đặt alarm: ThrottledRequests. Nếu nó tăng trong khi dung lượng đã cấp còn dư, đó là dấu hiệu hot partition — dùng CloudWatch Contributor Insights để tìm chính xác khoá nào đang bị truy cập quá nhiều.