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

Đáp án

A — Khởi chạy một file gateway kết nối với trung tâm dữ liệu tại chỗ bằng AWS Storage Gateway. Tải tài liệu lên file gateway và đặt lifecycle policy chuyển dữ liệu sang Glacier để lưu trữ dài hạn.

Vì sao đúng

Đề nêu bốn yêu cầu, và file gateway đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Sao lưu bền vững cho tài liệu tại chỗ | dữ liệu lưu thành object trên S3 | | Cache cục bộ cho dữ liệu vừa truy cập | file gateway giữ cache trên đĩa tại chỗ | | Truy cập qua giao thức SMB | file gateway hỗ trợ NFS VÀ SMB | | Truy cập trong vài phút suốt 6 tháng, rồi lưu trữ 10 năm | lifecycle policy chuyển sang Glacier |

Cách file gateway hoạt động:

Máy chủ tại chỗ
    ↓ mount qua SMB (hoặc NFS)
File Gateway (máy ảo chạy tại trung tâm dữ liệu của bạn)
    ├─ CACHE cục bộ: dữ liệu vừa truy cập → độ trễ thấp
    └─ đồng bộ lên S3: mỗi tệp thành MỘT OBJECT
                        ↓ lifecycle policy sau 6 tháng
                      S3 Glacier Deep Archive

Vế "giảm chi phí truyền dữ liệu ra (egress)" được cache giải quyết: tệp đã đọc gần đây nằm sẵn trên đĩa cục bộ, nên đọc lại không phát sinh phí truyền dữ liệu từ AWS.

Và điểm quan trọng: tệp lưu trên S3 dưới dạng object gốc, nên bạn truy cập được trực tiếp qua S3 API — khác hẳn tape gateway, nơi dữ liệu nằm trong định dạng băng ảo.

Lifecycle policy khớp với hai giai đoạn của đề:

{"Rules": [{
  "Status": "Enabled",
  "Transitions": [{"Days": 180, "StorageClass": "GLACIER"}],
  "Expiration": {"Days": 3830}
}]}

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

• B. Khởi chạy một tape gateway và tải tài liệu lên đó, đặt lifecycle chuyển sang Glacier — đây là phương án gần nhất và cũng là một loại Storage Gateway, nhưng nó không hỗ trợ SMB: tape gateway phơi ra một thư viện băng ảo qua giao thức iSCSI VTL, dành cho phần mềm sao lưu doanh nghiệp (Veeam, NetBackup, Commvault). Đề yêu cầu rõ "stored to and retrieved from AWS via SMB".
• C. Thiết lập Direct Connect, tải tài liệu lên EBS volume, dùng lifecycle chuyển snapshot sang S3 rồi Glacier — hai vấn đề: EBS volume không chia sẻ qua SMB cho máy chủ tại chỗ; và không có lifecycle policy nào tự chuyển EBS snapshot sang S3 bucket — snapshot do EBS quản lý.
• D. Dùng AWS Snowmobile để di chuyển toàn bộ tệp; tải lên S3 và đặt lifecycle chuyển sang Glacier — hoàn toàn không tương xứng: Snowmobile là xe container 45 foot để di chuyển hàng exabyte một lần. Đề cần sao lưu liên tục và cache cục bộ, không phải một đợt di chuyển khối lượng khổng lồ.

Ghi nhớ

Bốn loại AWS Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Dữ liệu lưu thành | Dùng cho | |---|---|---|---| | File Gateway (S3) | NFS, SMB | object S3 gốc | chia sẻ tệp, sao lưu tài liệu ← câu này | | FSx File Gateway | SMB | FSx for Windows | truy cập FSx từ tại chỗ với cache | | Volume Gateway | iSCSI (khối) | EBS snapshot | ổ đĩa khối cho ứng dụng | | Tape Gateway | iSCSI VTL | băng ảo trong S3/Glacier | thay thư viện băng vật lý |

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

"SMB", "NFS", "file share" → File Gateway "iSCSI", "block volume" → Volume Gateway "backup software", "virtual tape", "VTL" → Tape Gateway

Hai chế độ của Volume Gateway: | Chế độ | Đặc điểm | |---|---| | Cached volumes | dữ liệu chính ở S3, cache nóng tại chỗ | | Stored volumes | dữ liệu chính TẠI CHỖ, sao lưu bất đồng bộ lên S3 |

Các lớp lưu trữ Glacier — chọn theo thời gian truy xuất: | Lớp | Thời gian truy xuất | Chi phí | |---|---|---| | Glacier Instant Retrieval | mili giây | cao nhất trong nhóm | | Glacier Flexible Retrieval | 1–5 phút (expedited) tới 5–12 giờ | vừa | | Glacier Deep Archive | 12–48 giờ | rẻ nhất — khoảng 1 USD/TB/tháng |

Với yêu cầu của đề — "truy cập trong vài phút suốt 6 tháng, rồi lưu trữ một thập kỷ" — cấu hình hợp lý là:

0–6 tháng:    S3 Standard hoặc Standard-IA  (truy cập ngay)
6 tháng–10 năm: Glacier Deep Archive         (rẻ nhất cho lưu trữ dài)

Ba lưu ý khi triển khai File Gateway: | Lưu ý | Chi tiết | |---|---| | Kích thước cache tại chỗ quyết định hiệu năng | AWS khuyến nghị tối thiểu 150 GB | | Tích hợp Active Directory cho SMB | phân quyền theo tài khoản domain | | Băng thông tải lên có thể điều tiết | tránh chiếm hết đường truyền giờ làm việc |

Dòng đầu là yếu tố quyết định trải nghiệm: cache quá nhỏ nghĩa là phần lớn lượt đọc phải lấy từ S3 — vừa chậm vừa tốn phí truyền dữ liệu, đúng thứ mà đề muốn tránh.

Và một lưu ý về chi phí truy xuất: chuyển sang Deep Archive tiết kiệm rất nhiều phí lưu trữ, nhưng phí truy xuất và thời gian chờ 12–48 giờ là đáng kể. Chỉ chuyển những gì thực sự không cần truy cập nữa — với dữ liệu thỉnh thoảng cần, Glacier Instant Retrieval thường là điểm cân bằng tốt hơn.

Đáp án

B — Dùng partition key có ĐỘ PHÂN BIỆT CAO (high-cardinality), tức là có rất nhiều giá trị khác nhau giữa các item.

Vì sao đúng

Đề nêu hai mục tiêu, và cả hai đều phụ thuộc vào một điều duy nhất: phân bố đều dữ liệu giữa các partition. | Mục tiêu | Cơ chế | |---|---| | Phân bố tải đều | partition key nhiều giá trị → dữ liệu trải đều | | Dùng hết throughput đã cấp | mọi partition đều được dùng, không có cái nào nhàn rỗi |

Cách DynamoDB phân chia dữ liệu:

DynamoDB BĂM giá trị partition key
    → kết quả quyết định item nằm ở PARTITION nào
    → mỗi partition có giới hạn riêng:
        3.000 RCU và 1.000 WCU

Vì sao độ phân biệt thấp gây ra "hot partition":

Partition key = "trang_thai" (chỉ 3 giá trị: mới, đang xử lý, xong)
    → toàn bộ dữ liệu dồn vào 3 partition
    → mọi request "đang xử lý" đánh vào MỘT partition
    → partition đó chạm trần 3.000 RCU
    → THROTTLING, dù bảng còn thừa throughput

Partition key = "ma_don_hang" (hàng triệu giá trị)
    → dữ liệu trải đều trên rất nhiều partition
    → không partition nào thành nút thắt

Ví dụ về lựa chọn partition key: | Thuộc tính | Độ phân biệt | Phù hợp làm partition key | |---|---|---| | user_id, order_id, device_id | rất cao | ✅ | | email | rất cao | ✅ | | ngay (chỉ 365 giá trị/năm) | trung bình | ⚠️ có thể tạo hot partition | | gioi_tinh, trang_thai, quoc_gia | thấp | ❌ |

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

• C. Dùng partition key có độ phân biệt THẤP, tức là ít giá trị khác nhau — đây là phương án gần nhất và ngược hoàn toàn: đó chính là công thức tạo ra hot partition và throttling.
• A. Giảm số lượng partition key trong bảng DynamoDB — hiểu sai cấu trúc: một bảng DynamoDB chỉ có MỘT partition key trong khoá chính. Không có khái niệm "giảm số lượng partition key".
• D. Tránh dùng composite primary key gồm partition key và sort key — lời khuyên sai hướng: composite key rất hữu ích — nó cho phép nhiều item chia sẻ một partition key và truy vấn theo dải giá trị sort key. Nó không gây vấn đề phân bố nào.

Ghi nhớ

Hai loại khoá chính của DynamoDB: | Loại | Cấu trúc | Đặc điểm | |---|---|---| | Simple primary key | chỉ partition key | mỗi giá trị khoá là một item | | Composite primary key | partition key + sort key | nhiều item cùng partition key, truy vấn theo dải |

Composite key là mẫu thiết kế mạnh, không phải thứ cần tránh:

PK = "USER#123",  SK = "ORDER#2026-08-01"
PK = "USER#123",  SK = "ORDER#2026-08-15"
    → Query mọi đơn hàng của USER#123 trong tháng 8 bằng MỘT lời gọi

Giới hạn của một partition — con số cần nhớ: | Giới hạn | Giá trị | |---|---| | Read capacity | 3.000 RCU | | Write capacity | 1.000 WCU | | Dung lượng | 10 GB |

Adaptive capacity giúp giảm nhẹ vấn đề — DynamoDB tự chuyển throughput sang partition nóng. Nhưng nó không vượt được giới hạn cứng của một partition, nên thiết kế khoá vẫn quan trọng.

Ba kỹ thuật xử lý hot partition khi không tránh được: | Kỹ thuật | Cách làm | |---|---| | Write sharding | thêm hậu tố ngẫu nhiên: trang_thai#1 … trang_thai#10 | | Khoá tổng hợp | ghép nhiều thuộc tính: quoc_gia#thanh_pho#user_id | | DAX làm cache | giảm tải đọc cho item nóng |

Write sharding là mẫu chuẩn khi buộc phải dùng khoá có độ phân biệt thấp:

Ghi:  PK = "trang_thai#dang_xu_ly#" + random(1..10)
Đọc:  Query cả 10 shard rồi gộp kết quả

Ba dấu hiệu của hot partition: | Dấu hiệu | Nơi xem | |---|---| | ThrottledRequests tăng | CloudWatch | | Throughput đã cấp còn dư nhưng vẫn bị throttle | so ConsumedCapacity với ProvisionedCapacity | | CloudWatch Contributor Insights | hiện chính xác khoá nào bị truy cập nhiều nhất |

Contributor Insights là công cụ chẩn đoán trực tiếp nhất — nó liệt kê các partition key nóng nhất, nên bạn không phải đoán.

Và một nguyên tắc thiết kế nền tảng của DynamoDB mà câu này chạm tới: thiết kế bảng theo MẪU TRUY CẬP, không theo cấu trúc dữ liệu. Khác với cơ sở dữ liệu quan hệ nơi bạn chuẩn hoá trước rồi truy vấn sau, với DynamoDB bạn phải biết trước sẽ truy vấn thế nào — vì khoá chính quyết định cả hiệu năng lẫn khả năng truy vấn, và đổi khoá chính sau này đòi tạo bảng mới và di chuyển toàn bộ dữ liệu.

Đáp án

C — Xác thực người dùng bằng Redis AUTH, tạo cụm Redis mới với cả hai tham số --transit-encryption-enabled và --auth-token.

Vì sao đúng

Đề nêu ba yêu cầu, và Redis AUTH đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Bắt buộc xác thực trước khi chạy lệnh Redis | Redis AUTH token | | Yêu cầu nhập mật khẩu | auth token đóng vai trò mật khẩu | | Thông tin đăng nhập DÀI HẠN | auth token không tự hết hạn |

Điểm kỹ thuật bắt buộc: Redis AUTH đòi mã hoá khi truyền.

--auth-token KHÔNG dùng được nếu thiếu --transit-encryption-enabled

Lý do hiển nhiên: token đi qua đường truyền dưới dạng rõ trong lệnh AUTH. Không mã hoá thì bất kỳ ai nghe lén được mạng đều lấy được nó — nên AWS bắt buộc bật cả hai cùng lúc.

aws elasticache create-replication-group   --replication-group-id phien-ngan-hang   --replication-group-description "Quan ly phien"   --engine redis   --transit-encryption-enabled   --auth-token "MatKhauRatDaiVaPhucTap123!"   --at-rest-encryption-enabled

Và vế "long-lived credentials" là điểm phân biệt quyết định với phương án A: | | Redis AUTH token | IAM authentication token | |---|---|---| | Thời hạn | KHÔNG hết hạn | 15 phút | | Xoay vòng | thủ công (hỗ trợ hai token cùng lúc) | tự động theo phiên | | Đề yêu cầu | ✅ "long-lived credentials" | ❌ |

Đề nêu rõ "access should be managed with long-lived credentials" — nên Redis AUTH là lựa chọn khớp yêu cầu.

Và vế "MULTI EXEC" trong đề có ý nghĩa: đó là lệnh giao dịch của Redis, và AUTH bảo vệ mọi lệnh sau khi kết nối — kể cả nhóm lệnh giao dịch.

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

• A. Sinh IAM authentication token từ thông tin đăng nhập AWS và dùng token đó làm mật khẩu — đây là phương án gần nhất và là tính năng có thật, hiện đại hơn, nhưng nó trái yêu cầu "long-lived credentials": IAM auth token của ElastiCache hết hạn sau 15 phút. (Trong thực tế, IAM authentication thường là lựa chọn TỐT HƠN vì không có bí mật dài hạn — nhưng nó không khớp điều kiện mà đề đặt ra.)
• B. Thiết lập Redis replication group và bật tham số AtRestEncryptionEnabled — giải quyết vấn đề khác: mã hoá khi LƯU bảo vệ dữ liệu trên đĩa. Nó không xác thực ai được kết nối và chạy lệnh.
• D. Bật mã hoá khi truyền cho Redis replication group — là điều kiện cần nhưng không đủ: nó bảo vệ dữ liệu trên đường truyền, nhưng không yêu cầu ai phải nhập mật khẩu. Nó là một nửa của đáp án C.

Ghi nhớ

Ba lớp bảo mật của ElastiCache for Redis: | Lớp | Cơ chế | |---|---| | Xác thực | Redis AUTH token hoặc IAM authentication | | Mã hoá khi truyền | --transit-encryption-enabled (TLS) | | Mã hoá khi lưu | --at-rest-encryption-enabled | | Mạng | security group, subnet group |

Hai lớp đầu phụ thuộc nhau: Redis AUTH bắt buộc phải có mã hoá khi truyền.

Hai cách xác thực vào ElastiCache for Redis: | Cách | Thời hạn | Quản lý ở | |---|---|---| | Redis AUTH token | không hết hạn | ElastiCache | | IAM authentication | 15 phút | IAM — không có bí mật lưu ở đâu |

IAM authentication là lựa chọn hiện đại hơn cho hầu hết trường hợp: quyền quản lý tập trung trong IAM, không có mật khẩu nào để rò rỉ hay xoay vòng. Nhưng nó yêu cầu Redis 7.0 trở lên và ứng dụng phải sinh token định kỳ.

Ba ràng buộc của Redis AUTH token: | Ràng buộc | Chi tiết | |---|---| | Độ dài 16–128 ký tự | | | Không chứa ký tự đặc biệt nhất định | ", /, @, khoảng trắng | | Đặt lúc TẠO cụm hoặc qua modify với chiến lược xoay vòng | |

Xoay vòng token không gián đoạn — cơ chế đáng biết:

# Bước 1: thêm token mới, cụm chấp nhận CẢ HAI
aws elasticache modify-replication-group --replication-group-id phien-ngan-hang   --auth-token "TokenMoi..." --auth-token-update-strategy ROTATE

# Bước 2: sau khi mọi client đã chuyển sang token mới
aws elasticache modify-replication-group --replication-group-id phien-ngan-hang   --auth-token "TokenMoi..." --auth-token-update-strategy SET

Giai đoạn ROTATE cho phép cả token cũ lẫn mới cùng hoạt động — nên bạn cập nhật ứng dụng dần mà không có thời gian ngừng.

Ba lưu ý về mã hoá khi truyền: | Lưu ý | Chi tiết | |---|---| | Bật lúc TẠO cụm | với engine cũ thì không đổi được sau | | Client phải hỗ trợ TLS | thêm tham số kết nối | | Có chi phí xử lý nhỏ | thường không đáng kể |

Và Redis 6 trở lên có thêm một cơ chế mạnh hơn AUTH: Redis ACL (RBAC). Nó cho phép tạo nhiều user với quyền khác nhau — ví dụ một user chỉ đọc, một user được chạy lệnh quản trị:

aws elasticache create-user --user-id ung-dung-doc   --user-name ung-dung-doc --engine redis   --passwords "MatKhau..." --access-string "on ~* +@read"

Với ứng dụng ngân hàng như đề mô tả, RBAC là bước tiến đáng cân nhắc so với một auth token duy nhất dùng chung cho mọi thành phần.

Đáp án

A — Dùng AWS Shield Advanced để phát hiện và giảm thiểu tấn công DDoS.

Vì sao đúng

Đề nêu tình huống: phát hiện một loạt tấn công DDoS và cần củng cố hạ tầng để bảo vệ dữ liệu khách hàng.

Shield Advanced là dịch vụ chuyên trách chống DDoS của AWS: | Khả năng | Chi tiết | |---|---| | Phát hiện tự động | phân tích lưu lượng, nhận diện mẫu tấn công | | Giảm thiểu ở tầng 3, 4 và 7 | không chỉ tầng mạng | | Shield Response Team (SRT) | hỗ trợ 24/7 trong lúc bị tấn công | | Bảo vệ chi phí | hoàn phí cho chi phí scale do tấn công gây ra | | Metric và báo cáo chi tiết | DDoSDetected và các metric quy mô | | WAF bao gồm | không tính phí riêng |

Vì sao Shield Advanced chứ không phải Shield Standard:

Shield Standard:  MIỄN PHÍ, bật sẵn cho mọi tài khoản
                  → bảo vệ tầng 3/4 phổ biến
                  → NHƯNG im lặng: không metric, không thông báo, không hỗ trợ

Shield Advanced:  → thấy được cuộc tấn công qua metric
                  → có đội chuyên gia can thiệp
                  → được bảo vệ khỏi hoá đơn tăng vọt

Đề nói kiến trúc sư "đã phát hiện một loạt tấn công" và cần "củng cố" — nghĩa là mức bảo vệ mặc định không còn đủ, và cần khả năng phát hiện, phản ứng và hỗ trợ chuyên sâu.

Và "bảo vệ chi phí" là điểm đáng giá bị đánh giá thấp: một cuộc tấn công lớn sinh ra hoá đơn truyền dữ liệu và auto scaling rất lớn — Shield Advanced hoàn lại phần chi phí đó.

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

• C. Thiết lập AWS WAF để lọc, giám sát và chặn lưu lượng HTTP — đây là phương án gần nhất và là lớp bảo vệ quan trọng cho tầng 7, nhưng nó chỉ giải quyết một phần: WAF hoạt động ở tầng ứng dụng và chỉ gắn được vào CloudFront, ALB, API Gateway. Nó không chống được tấn công tầng 3/4 như SYN flood hay UDP reflection. (WAF là bổ sung tốt — và Shield Advanced đã bao gồm nó.)
• B. Dùng AWS Firewall Manager thiết lập một lớp bảo mật ngăn SYN flood, UDP reflection và các tấn công DDoS khác — nhầm vai trò: Firewall Manager là lớp QUẢN LÝ TẬP TRUNG cho WAF, Shield Advanced và security group ở quy mô tổ chức. Nó không tự chống DDoS — nó chỉ giúp áp chính sách Shield/WAF cho nhiều tài khoản.
• D. Kết hợp security group và NACL để chỉ cho phép lưu lượng được uỷ quyền vào VPC — không đủ trước DDoS: security group và NACL lọc theo IP, cổng và giao thức. Tấn công DDoS gửi lưu lượng trông hợp lệ với khối lượng khổng lồ — và bản thân bảng connection tracking của security group có thể bị cạn (xem câu #7789).

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 | tầng 3/4/7 nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Tấn công tầng 3/4 và tầng 7 — phân biệt: | | Tầng 3/4 | Tầng 7 | |---|---|---| | Ví dụ | SYN flood, UDP reflection, DNS amplification | HTTP flood, slowloris, tấn công API tốn tài nguyên | | Đặc điểm | khối lượng lớn, gói tin dị thường | request HỢP LỆ, khó phân biệt với người dùng thật | | Chống bằng | Shield | WAF |

Tài nguyên bảo vệ được bằng Shield Advanced: | Tài nguyên | |---| | CloudFront distribution | | Route 53 hosted zone | | ALB, NLB, Classic Load Balancer | | Elastic IP | | Global Accelerator |

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ụ ở hơn 600 điểm | | Giảm diện tích phơi ra | origin trong private subnet, chỉ nhận từ CloudFront | | Chuẩn bị mở rộng | ASG, nhưng cân nhắc chi phí | | Biết khi bị tấn công | alarm trên DDoSDetected |

Dòng thứ hai hay bị quên nhất: đặt CloudFront phía trước nhưng vẫn để ALB nhận lưu lượng từ 0.0.0.0/0 thì kẻ tấn công tìm ra IP gốc và bỏ qua toàn bộ lớp bảo vệ. Bịt bằng AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing trong security group của origin.

Ba cấu hình nên bật cùng Shield Advanced: | Cấu hình | Lợi ích | |---|---| | Proactive engagement | SRT tự vào cuộc — không cần bạn mở ticket | | Health-based detection | dùng Route 53 health check để phát hiện chính xác hơn | | Alarm trên DDoSDetected | biết ngay khi có tấn công |

Dòng đầu là khác biệt lớn nhất về thời gian phản ứng — trong một cuộc tấn công, mỗi phút đều quan trọng, và việc SRT đã đang xử lý trước khi bạn kịp đọc email là giá trị thật.

Và một điểm về Firewall Manager để hiểu đúng vai trò của nó: với tổ chức nhiều tài khoản, Firewall Manager rất hữu ích — nó tự động đăng ký mọi ALB và CloudFront mới vào Shield Advanced và gắn Web ACL chuẩn. Nhưng nó là công cụ quản trị, không phải cơ chế phòng thủ; Shield Advanced mới là thứ thực sự giảm thiểu tấn công.

Đáp án

B — Dùng Amazon FSx for Lustre cho lưu trữ nóng và Amazon S3 cho lưu trữ nguội.

Vì sao đúng

Đề nêu hai nhu cầu tách bạch, và mỗi dịch vụ phục vụ một cái: | Nhu cầu | Dịch vụ | |---|---| | Lưu trữ NÓNG hiệu năng cao, SONG SONG, xử lý đồng thời | FSx for Lustre | | Lưu trữ NGUỘI tiết kiệm để lưu trữ dài hạn | Amazon S3 |

Vì sao FSx for Lustre là lựa chọn duy nhất cho "parallel hot storage":

Lustre là hệ thống tệp SONG SONG được thiết kế cho HPC
    → dữ liệu được chia nhỏ (stripe) trên NHIỀU máy chủ lưu trữ
    → hàng trăm client đọc ĐỒNG THỜI từ các máy chủ khác nhau
    → thông lượng hàng trăm GB/giây, độ trễ dưới mili giây

Và điểm khiến cặp Lustre + S3 đặc biệt phù hợp: chúng tích hợp GỐC với nhau.

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 1200   --lustre-configuration     'ImportPath=s3://kho-du-lieu-huan-luyen/,ExportPath=s3://kho-du-lieu-huan-luyen/ket-qua/,
     DeploymentType=SCRATCH_2'

Đây là mẫu chuẩn cho học máy: dữ liệu huấn luyện nằm rẻ trên S3, khi cần huấn luyện thì dựng một file system Lustre trỏ vào đó, chạy xong thì xoá — chỉ trả tiền hiệu năng cao trong lúc thực sự dùng.

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

• C. Dùng Amazon EFS cho lưu trữ nóng và S3 cho lưu trữ nguội — đây là phương án gần nhất và EFS là hệ thống tệp chia sẻ hợp lệ, nhưng nó không phải hệ thống tệp song song hiệu năng cao: EFS tối ưu cho chia sẻ tệp chung với thông lượng vừa phải. Với hàng nghìn tập dữ liệu cần đọc đồng thời ở tốc độ cao, EFS là nút thắt.
• A. Dùng FSx for Lustre và Provisioned IOPS SSD (io1) của EBS cho lưu trữ nguội — sai hoàn toàn ở vế nguội: io1 là loại EBS ĐẮT NHẤT, dành cho workload I/O cao nhất. Dùng nó làm "cost-effective cold storage" là ngược hẳn mục đích.
• D. Dùng FSx for Windows File Server cho lưu trữ nóng và S3 cho nguội — sai loại hệ thống tệp: FSx for Windows phục vụ chia sẻ tệp SMB cho ứng dụng Windows. Nó không phải hệ thống tệp song song và không phù hợp cho tải huấn luyện học máy.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — chọn theo workload: | Dịch vụ | Đặc điểm | Dùng cho | |---|---|---| | FSx for Lustre | song song, thông lượng cực cao | HPC, học máy, phân tích ← câu này | | FSx for Windows File Server | SMB, tích hợp Active Directory | ứng dụng Windows | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | môi trường lai, tính năng doanh nghiệp | | FSx for OpenZFS | NFS, snapshot nhanh | thay thế NAS trên Linux |

Từ khoá nhận diện:

"parallel", "HPC", "machine learning training", "high throughput" → FSx for Lustre "SMB", "Windows", "Active Directory" → FSx for Windows "POSIX shared file system", "Linux" → EFS "block storage", "iSCSI" → EBS hoặc FSx ONTAP

Hai kiểu triển khai của FSx for Lustre: | Kiểu | Đặc điểm | Dùng khi | |---|---|---| | Scratch | KHÔNG sao chép dự phòng, rẻ hơn | xử lý tạm thời — dữ liệu gốc vẫn ở S3 | | Persistent | có sao chép, tự khôi phục khi hỏng | lưu trữ lâu dài, dữ liệu quan trọng |

Scratch phù hợp với mẫu dùng của đề: dữ liệu nguồn nằm an toàn trên S3, Lustre chỉ là lớp tăng tốc tạm thời — mất nó cũng không mất dữ liệu.

Các lớp lưu trữ S3 cho dữ liệu nguội: | Lớp | Truy xuất | Chi phí | |---|---|---| | Standard-IA | tức thì | vừa | | Glacier Instant Retrieval | mili giây | thấp hơn | | Glacier Flexible Retrieval | 1 phút – 12 giờ | thấp | | Glacier Deep Archive | 12–48 giờ | rẻ nhất (~1 USD/TB/tháng) | | Intelligent-Tiering | tự chuyển theo mẫu truy cập | tự tối ưu |

Với "tập dữ liệu sinh lợi nhuận thấp" như đề mô tả — chúng vẫn có thể cần dùng lại — Glacier Instant Retrieval hoặc Intelligent-Tiering thường là điểm cân bằng tốt hơn Deep Archive.

Ba lưu ý khi dùng FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Dung lượng tối thiểu 1,2 TB (SSD scratch) | không dựng được file system nhỏ | | Chỉ hỗ trợ Linux client | cần cài Lustre client | | Tính phí theo dung lượng đã cấp, không theo lượng dùng | xoá khi không dùng để tiết kiệm |

Dòng cuối là chìa khoá tiết kiệm chi phí: mẫu dùng đúng là dựng file system trước khi huấn luyện, xoá sau khi xong — kết quả đã được export về S3, nên không mất gì.

Và một lưu ý về hiệu năng: thông lượng của Lustre tỷ lệ với dung lượng đã cấp. Nếu cần thông lượng cao hơn cho cùng một lượng dữ liệu, bạn cấp thêm dung lượng — hoặc chọn loại PERSISTENT với mức thông lượng trên mỗi TiB cao hơn.

Đáp án

A — Tạo một NAT Gateway ở MỖI Availability Zone. Cấu hình route table trong mỗi PRIVATE subnet để instance dùng NAT Gateway trong cùng AZ.

Vì sao đúng

Đề nêu hai yêu cầu, và A đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Loại bỏ điểm hỏng đơn lẻ | mỗi AZ một NAT Gateway độc lập | | Tiết kiệm chi phí | đúng một cái mỗi AZ, không thừa |

Vấn đề với kiến trúc hiện tại:

Một NAT Gateway duy nhất ở AZ-a
    ├─ instance ở AZ-a → NAT (cùng AZ)
    ├─ instance ở AZ-b → NAT ở AZ-a   ← đi CHÉO AZ
    └─ instance ở AZ-c → NAT ở AZ-a   ← đi CHÉO AZ

AZ-a sập → MỌI instance ở MỌI AZ mất đường ra Internet

Kiến trúc sau khi sửa:

AZ-a: private subnet → route 0.0.0.0/0 → NAT-a (ở public subnet AZ-a)
AZ-b: private subnet → route 0.0.0.0/0 → NAT-b (ở public subnet AZ-b)
AZ-c: private subnet → route 0.0.0.0/0 → NAT-c (ở public subnet AZ-c)

AZ-b sập → chỉ instance ở AZ-b bị ảnh hưởng
        → AZ-a và AZ-c vẫn hoạt động bình thường

Và điều này còn TIẾT KIỆM chi phí, không chỉ tăng độ tin cậy: | Chi phí | Chi tiết | |---|---| | Truyền dữ liệu chéo AZ | ~0,01 USD/GB mỗi chiều — bị tính khi đi qua NAT ở AZ khác | | Giữ lưu lượng trong cùng AZ | loại bỏ hoàn toàn khoản đó |

Với khối lượng tải bản vá lớn, khoản tiết kiệm truyền dữ liệu có thể bù lại phần lớn chi phí NAT Gateway thêm.

Và vế "route table trong PRIVATE subnet" là chi tiết đúng: instance nằm ở private subnet, nên chính route table của các subnet đó phải trỏ tới NAT Gateway.

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

• B. Tạo NAT Gateway ở mỗi AZ; cấu hình route table trong mỗi PUBLIC subnet — đây là phương án gần nhất và chỉ sai một từ: NAT Gateway nằm trong public subnet, nhưng route table cần sửa là của PRIVATE subnet — nơi có instance cần ra Internet. Route table của public subnet trỏ tới Internet Gateway.
• C. Tạo HAI NAT Gateway ở mỗi AZ; cấu hình route table trong public subnet — thừa gấp đôi chi phí mà không thêm lợi ích: NAT Gateway đã dư thừa sẵn BÊN TRONG một AZ. Và vẫn sai ở vế public subnet.
• D. Tạo BA NAT Gateway ở mỗi AZ; cấu hình route table trong private subnet — vế route table đúng nhưng lãng phí gấp ba: cùng lý do như C.

Ghi nhớ

Đặc điểm sẵn sàng của NAT Gateway — điểm cốt lõi của câu hỏi: | Phạm vi | Tính sẵn sàng | |---|---| | BÊN TRONG một AZ | dư thừa tự động — AWS lo | | GIỮA các AZ | KHÔNG — bạn phải tự tạo một cái mỗi AZ |

Đây là lý do một NAT Gateway mỗi AZ là đủ, và hai cái là lãng phí.

Kiến trúc VPC chuẩn cho ứng dụng nhiều tầng:

AZ-a                          AZ-b
├─ Public subnet              ├─ Public subnet
│   ├─ NAT Gateway A          │   ├─ NAT Gateway B
│   └─ ALB node               │   └─ ALB node
│   route: 0.0.0.0/0 → IGW    │   route: 0.0.0.0/0 → IGW
│                             │
└─ Private subnet             └─ Private subnet
    ├─ EC2 instance               ├─ EC2 instance
    route: 0.0.0.0/0 → NAT A      route: 0.0.0.0/0 → NAT B

Mỗi private subnet cần route table RIÊNG — nếu dùng chung một route table cho mọi private subnet, chúng đều trỏ tới cùng một NAT và bạn quay lại điểm hỏng đơn lẻ.

NAT Gateway và NAT Instance — phân biệt: | | NAT Gateway | NAT Instance | |---|---|---| | Quản lý | AWS quản lý hoàn toàn | bạn tự vá, tự giám sát | | Băng thông | tự mở rộng tới 100 Gbps | giới hạn theo loại instance | | Sẵn sàng trong AZ | tự động | phải tự dựng | | Security group | KHÔNG có | có |

NAT Gateway là lựa chọn mặc định — NAT Instance chỉ còn hợp lý cho môi trường nhỏ cần tiết kiệm tối đa, hoặc khi cần tính năng đặc biệt như port forwarding.

Ba khoản chi phí của NAT Gateway: | Khoản | Mức | |---|---| | Phí theo giờ | ~0,045 USD/giờ mỗi cái | | Phí xử lý dữ liệu | ~0,045 USD/GB đi qua | | Phí truyền chéo AZ | ~0,01 USD/GB mỗi chiều — tránh được bằng cách đặt NAT cùng AZ |

Cách giảm chi phí NAT Gateway đáng kể nhất — và đề gợi mở trực tiếp: | Cách | Lợi ích | |---|---| | VPC Gateway endpoint cho S3 và DynamoDB | MIỄN PHÍ — lưu lượng không qua NAT | | VPC Interface endpoint cho dịch vụ khác | rẻ hơn NAT với khối lượng lớn | | Đặt kho bản vá trên S3 | tải bản vá qua Gateway endpoint thay vì Internet |

Dòng cuối rất phù hợp với tình huống của đề: nếu bản vá được lưu trên S3 (hoặc dùng Systems Manager Patch Manager với VPC endpoint), lưu lượng đó không đi qua NAT Gateway chút nào — vừa nhanh hơn, vừa không tốn phí xử lý dữ liệu, vừa không phụ thuộc vào Internet.

Và với IPv6, cơ chế khác hẳn: dùng Egress-Only Internet Gateway thay cho NAT Gateway (xem câu #8170) — nó miễn phí và cho phép lưu lượng ra mà chặn kết nối vào.

Đáp án

A — Dùng Amazon VPC endpoint để định tuyến mọi truy cập tới S3 và DynamoDB qua endpoint riêng tư.

Vì sao đúng

Đề nêu yêu cầu rõ: EC2 trong private subnet phải gửi dữ liệu tới S3 và DynamoDB qua endpoint riêng tư không đi qua Internet công cộng.

VPC endpoint là cơ chế chính xác cho việc đó:

KHÔNG có VPC endpoint:
    EC2 (private subnet) → NAT Gateway → INTERNET → S3
                                          ^^^^^^^^
                                   trái yêu cầu bảo mật

CÓ Gateway endpoint:
    EC2 → route table trỏ tới endpoint → mạng nội bộ AWS → S3
    → KHÔNG rời khỏi hạ tầng AWS

Và S3 cùng DynamoDB là hai dịch vụ duy nhất dùng GATEWAY endpoint:

aws ec2 create-vpc-endpoint   --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway   --route-table-ids rtb-private-a rtb-private-b

aws ec2 create-vpc-endpoint   --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-northeast-1.dynamodb   --vpc-endpoint-type Gateway   --route-table-ids rtb-private-a rtb-private-b

Ba lợi ích cùng lúc: | Lợi ích | Chi tiết | |---|---| | Bảo mật | lưu lượng không ra Internet | | MIỄN PHÍ | Gateway endpoint không tính phí giờ lẫn phí dữ liệu | | Không cần NAT Gateway cho lưu lượng này | tiết kiệm đáng kể |

Dòng giữa đáng nhấn mạnh: Gateway endpoint là một trong số ít tính năng bảo mật của AWS hoàn toàn miễn phí và còn giúp tiết kiệm tiền — nên không có lý do gì để không dùng.

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

• D. Dùng AWS Direct Connect để định tuyến truy cập tới S3 và DynamoDB qua endpoint riêng tư — đây là phương án gần nhất về mặt "kết nối riêng tư", nhưng Direct Connect nối trung tâm dữ liệu TẠI CHỖ với AWS. Đề nói về EC2 đã nằm trong VPC — không có mạng tại chỗ nào ở đây.
• C. Bật DynamoDB Encryption at Rest và S3 Server-Side Encryption để định tuyến mọi lưu lượng qua endpoint riêng tư — nhầm hai khái niệm hoàn toàn khác nhau: mã hoá bảo vệ nội dung dữ liệu, nó không ảnh hưởng tới ĐƯỜNG ĐI của lưu lượng. Dữ liệu mã hoá vẫn đi qua Internet nếu không có endpoint.
• B. (trùng nội dung với A) — hai phương án có văn bản giống hệt nhau; xem ghi chú cuối bài.

Ghi nhớ

Hai loại VPC endpoint — bảng cần thuộc: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table entry | MIỄN PHÍ | | Interface endpoint | hầu hết dịch vụ khác | ENI trong subnet (PrivateLink) | theo giờ + GB |

Nhớ đúng danh sách hai dịch vụ của Gateway endpoint — đây là chi tiết được hỏi rất thường xuyên.

Các dịch vụ dùng Interface endpoint hay gặp:

SSM, ssmmessages, ec2messages   (Session Manager)
Secrets Manager, KMS
ECR (api và dkr), ECS
CloudWatch Logs, Monitoring
SNS, SQS, Kinesis
API Gateway (private API)

So sánh ba đặc điểm: | | Gateway | Interface | |---|---|---| | Truy cập từ tại chỗ (qua DX/VPN) | ❌ KHÔNG | ✅ CÓ | | Cần security group | ❌ | ✅ phải mở 443 | | Cần sửa route table | ✅ | ❌ (dùng private DNS) |

Dòng đầu là lý do đôi khi vẫn dùng Interface endpoint cho S3: khi cần truy cập S3 riêng tư từ trung tâm dữ liệu tại chỗ qua Direct Connect, Gateway endpoint không dùng được.

Endpoint policy — lớp kiểm soát bổ sung đáng dùng:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::bucket-duoc-phep/*"
}

Nó giới hạn những gì đi qua endpoint — một instance bị xâm nhập trong VPC cũng không dùng endpoint để chạm tới bucket khác.

Và chiều ngược lại — ràng buộc bucket chỉ nhận từ endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::bucket/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Kết hợp hai chiều tạo thành khoá chặt: bucket chỉ nhận request qua endpoint này, và endpoint này chỉ cho phép truy cập đúng bucket đó.

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

Phương án A và B có nội dung HOÀN TOÀN GIỐNG NHAU — cả hai đều là "Use Amazon VPC endpoints to route all access to S3 and DynamoDB via private endpoints."

Đây là lỗi của bộ đề nguồn, gần như chắc chắn do sao chép nhầm khi soạn. Trong một đề thi thật, hai phương án trùng nhau mà chỉ một được tính đúng là câu hỏi không hợp lệ.

Điều đó không ảnh hưởng tới kiến thức cần nắm: VPC endpoint là câu trả lời đúng, và hai phương án còn lại (Direct Connect, mã hoá) đều sai rõ ràng vì lý do đã phân tích. Nếu gặp tình huống này trong đề thật, hãy chọn phương án có nội dung đúng và bỏ qua sự trùng lặp.

Đáp án

A — Gắn một EBS volume vào EC2 instance. Dùng Amazon S3 lưu dữ liệu sao lưu và cấu hình lifecycle policy chuyển object sang Amazon S3 Glacier.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi vế của đáp án phục vụ một cái: | Yêu cầu | Cơ chế | |---|---| | Lưu trữ KHỐI BỀN VỮNG cho workload quan trọng | EBS volume | | Sao lưu vào dịch vụ lưu trữ ĐỐI TƯỢNG | Amazon S3 | | Sau 30 ngày chuyển sang dịch vụ LƯU TRỮ DÀI HẠN | lifecycle policy → Glacier |

Từ khoá "persistent" loại bỏ instance store ngay lập tức:

EBS volume:
    → tồn tại ĐỘC LẬP với vòng đời instance
    → dừng, khởi động lại, thậm chí terminate instance
      → dữ liệu VẪN CÒN (nếu DeleteOnTermination=false)
    → tháo ra gắn sang instance khác được

Instance store:
    → gắn VẬT LÝ vào máy chủ chủ
    → DỪNG hoặc TERMINATE instance → MẤT SẠCH dữ liệu
    → thậm chí lỗi phần cứng cũng mất

Và "data archiving storage service" chỉ đúng một thứ: Glacier. | Lớp | Là gì | |---|---| | S3 Glacier (các biến thể) | lớp LƯU TRỮ DÀI HẠN — rẻ nhất | | S3 Standard-IA | truy cập không thường xuyên, không phải archive | | S3 One Zone-IA | truy cập không thường xuyên, một AZ — cũng KHÔNG phải archive |

Lifecycle policy khớp chính xác yêu cầu 30 ngày:

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}]
  }]
}

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

• B. Gắn EBS volume; dùng S3 và cấu hình lifecycle chuyển object sang S3 One Zone-IA — đây là phương án gần nhất và có vế EBS đúng, nhưng nó sai lớp lưu trữ đích: One Zone-IA là lớp truy cập không thường xuyên, không phải lưu trữ dài hạn (archiving). Và nó chỉ lưu ở MỘT AZ — kém bền hơn cho dữ liệu sao lưu quan trọng.
• C. Gắn instance store volume; dùng S3 và lifecycle chuyển sang Glacier — vế S3 và Glacier đúng nhưng vế lưu trữ khối sai: instance store KHÔNG bền vững — mất dữ liệu khi instance dừng. Trái thẳng yêu cầu "persistent block storage volume for mission-critical workloads".
• D. Gắn instance store volume; dùng S3 và lifecycle chuyển sang One Zone-IA — sai cả hai vế, kết hợp lỗi của B và C.

Ghi nhớ

EBS và instance store — bảng phân biệt cần thuộc: | | EBS | Instance store | |---|---|---| | Bền vững | ✅ độc lập với instance | ❌ mất khi dừng/terminate | | Vị trí | mạng lưu trữ (gắn qua mạng) | đĩa VẬT LÝ trên máy chủ chủ | | Hiệu năng | rất tốt, io2 Block Express tới 256.000 IOPS | cao hơn — không qua mạng | | Snapshot | ✅ | ❌ | | Đổi kích thước khi đang chạy | ✅ | ❌ | | 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, hoặc dữ liệu đã được sao chép ở tầng ứng dụng (như một số cụm NoSQL).

Các lớp lưu trữ S3 và mục đích: | Lớp | Truy xuất | Dùng cho | |---|---|---| | Standard | tức thì | dữ liệu truy cập thường xuyên | | Standard-IA | tức thì, có phí truy xuất | ít truy cập nhưng cần ngay | | One Zone-IA | tức thì | ít truy cập, chấp nhận rủi ro một AZ | | Glacier Instant Retrieval | mili giây | archive nhưng thỉnh thoảng cần ngay | | Glacier Flexible Retrieval | 1 phút – 12 giờ | archive điển hình | | Glacier Deep Archive | 12–48 giờ | rẻ nhất (~1 USD/TB/tháng) | | Intelligent-Tiering | tự động | mẫu truy cập không đoán được |

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

Ba cách sao lưu EBS sang S3: | Cách | Đặc điểm | |---|---| | EBS snapshot | tự động qua Data Lifecycle Manager hoặc AWS Backup | | Ứng dụng tự đẩy tệp lên S3 | kiểm soát chi tiết ← mô tả trong đề | | AWS Backup | quản lý tập trung nhiều dịch vụ, có vault lock |

AWS Backup là lựa chọn đáng cân nhắc nhất cho môi trường thật: nó sao lưu EBS, RDS, EFS, DynamoDB, FSx theo một chính sách duy nhất, hỗ trợ sao lưu chéo tài khoản và chéo Region, và có Backup Vault Lock ngăn xoá bản sao lưu — mức bảo vệ mà lifecycle policy thuần không có.

(Lưu ý: EBS snapshot được lưu trong S3 do AWS quản lý, không nằm trong bucket của bạn — nên không áp lifecycle policy của bạn lên chúng được. Muốn quản lý vòng đời snapshot thì dùng Data Lifecycle Manager.)

Và một tối ưu đáng biết: nếu mẫu truy cập của dữ liệu sao lưu không rõ ràng, S3 Intelligent-Tiering tự chuyển giữa các tầng theo hành vi thực tế — kể cả xuống tầng archive — mà không cần bạn đoán trước con số 30 ngày có đúng hay không.

Đáp án

B — Bật S3 Object Lock ở chế độ COMPLIANCE với retention period một năm.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều chỉ tới đúng một cấu hình: | Yêu cầu | Cơ chế | |---|---| | Không ai ghi đè hoặc xoá được trong đúng MỘT NĂM | retention period = 1 năm | | Kể cả ROOT USER cũng bị chặn | chế độ COMPLIANCE |

Khác biệt giữa hai chế độ là toàn bộ nội dung câu hỏi: | | GOVERNANCE | COMPLIANCE | |---|---|---| | Gỡ trước hạn | ✅ với s3:BypassGovernanceRetention | ❌ KHÔNG AI — kể cả root, kể cả AWS | | Rút ngắn thời hạn | ✅ | ❌ | | Kéo dài thời hạn | ✅ | ✅ (chỉ được kéo DÀI) | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý nghiêm ngặt |

Đề nói rõ "the root user must also be restricted" — và đó là điều chỉ COMPLIANCE làm được.

aws s3api put-object --bucket du-lieu-thu-nghiem-lam-sang   --key ho-so-2026.csv --body du-lieu.csv   --object-lock-mode COMPLIANCE   --object-lock-retain-until-date 2027-08-30T00:00:00Z

Và "retention period" chứ không phải "legal hold" là chi tiết thứ hai: | Cơ chế | Đặc điểm | |---|---| | Retention period | khoá tới một NGÀY CỤ THỂ — có thời hạn | | Legal hold | khoá VÔ THỜI HẠN cho tới khi gỡ tường minh |

Đề yêu cầu "in a period of one year ONLY" — tức là có thời hạn xác định. Legal hold không có khái niệm thời hạn, nên cụm "legal hold of one year" trong phương án C và D là mâu thuẫn nội tại.

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

• A. Object Lock ở chế độ GOVERNANCE với retention một năm — đây là phương án gần nhất và đúng về thời hạn, nhưng nó không chặn được root: người có quyền s3:BypassGovernanceRetention gỡ được khoá trước hạn. Đề yêu cầu tường minh rằng root cũng phải bị hạn chế.
• **D. Object Lock ở chế độ COMPLIANCE với legal hold một năm — chế độ đúng nhưng cơ chế sai: legal hold không nhận tham số thời hạn. Nó chỉ có Status: ON hoặc OFF.
• **C. Object Lock ở chế độ GOVERNANCE với legal hold một năm — sai cả hai vế.

Ghi nhớ

Hai cơ chế khoá của Object Lock: | Cơ chế | Tham số | Kết thúc khi | |---|---|---| | Retention period | Mode + RetainUntilDate | tới ngày đã định | | Legal hold | Status: ON/OFF | có người gỡ tường minh |

Hai cơ chế ĐỘC LẬP và cộng dồn: một object có thể vừa có retention period vừa có legal hold — nó chỉ xoá được khi cả hai đã hết hiệu lực.

Legal hold dùng khi nào: có tranh chấp pháp lý đang diễn ra và chưa biết khi nào kết thúc. Retention period dùng khi thời hạn lưu trữ đã được quy định rõ.

Ba điều kiện để dùng Object Lock:

① Versioning phải BẬT — và không tắt được khi Object Lock đang dùng
② Object Lock bật lúc TẠO bucket
   (bật cho bucket có sẵn cần qua AWS Support)
③ Đặt retention/legal hold cho từng object, hoặc default cho bucket

Default retention cho bucket — tiện hơn đặt từng object:

aws s3api put-object-lock-configuration --bucket du-lieu-thu-nghiem-lam-sang   --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 1}}}'

Mọi object tải lên sau đó tự động được khoá một năm.

Cảnh báo nghiêm túc về COMPLIANCE:

Đặt nhầm thời hạn 10 năm cho một object
    → KHÔNG xoá được
    → KHÔNG rút ngắn được
    → AWS Support cũng KHÔNG gỡ hộ
    → trả tiền lưu trữ đủ 10 năm

Luôn kiểm thử ở GOVERNANCE trước khi dùng COMPLIANCE trong sản xuất.

Bốn lớp bảo vệ dữ liệu trên S3 — theo độ mạnh: | Lớp | Chống lại | |---|---| | Object Lock (COMPLIANCE) | BẤT KỲ AI, kể cả root | | Object Lock (GOVERNANCE) | người dùng thường | | MFA Delete | xoá phiên bản (nhưng root bật/tắt được) | | Versioning | xoá nhầm (delete marker) |

Ba ứng dụng của Object Lock chế độ COMPLIANCE: | Ứng dụng | Chi tiết | |---|---| | Tuân thủ quy định | SEC 17a-4(f), FINRA, CFTC — lưu trữ bất biến ← câu này | | Bảo vệ log kiểm toán | kẻ chiếm được root cũng không xoá được dấu vết | | Chống ransomware | bản sao lưu không bị mã hoá hay xoá |

Dòng giữa là ứng dụng đáng làm cho mọi tổ chức: bucket chứa log CloudTrail với Object Lock COMPLIANCE khiến việc xoá dấu vết trở nên bất khả thi — kể cả với kẻ đã chiếm được quyền cao nhất trong tài khoản.

Và một lưu ý về chi phí: object bị khoá vẫn tính phí lưu trữ đầy đủ trong suốt thời hạn. Kết hợp với lifecycle rule chuyển sang Glacier Deep Archive — Object Lock hoạt động ở mọi lớp lưu trữ, nên bạn giữ được tính bất biến mà giảm được đáng kể chi phí cho dữ liệu chỉ cần lưu chứ không cần truy cập.

Đáp án

D — Dùng AWS KMS tạo một KMS key trong custom key store và lưu key material không xuất được (non-extractable) trong AWS CloudHSM.

Vì sao đúng

Đề nêu bốn yêu cầu, và chỉ custom key store thoả hết: | Yêu cầu | Cơ chế | |---|---| | Tích hợp dễ dàng với dịch vụ AWS khác | KMS key — dùng được với S3, EBS, RDS... | | Toàn quyền kiểm soát việc tạo khoá | CloudHSM do bạn vận hành | | Xoá key material NGAY LẬP TỨC | ngắt kết nối key store → khoá vô dụng tức thì | | Kiểm toán việc dùng khoá ĐỘC LẬP với CloudTrail | CloudHSM có log kiểm toán RIÊNG |

Vế cuối là điểm phân biệt quyết định và ít người để ý:

KMS thường:      mọi lời gọi ghi vào CloudTrail
                 → nếu ai đó vô hiệu hoá CloudTrail thì mất dấu vết

Custom key store: CloudHSM có audit log RIÊNG BIỆT
                 → nằm ngoài tầm kiểm soát của AWS CloudTrail
                 → hai nguồn kiểm toán độc lập

Đây là yêu cầu thật của các ngành chịu quản lý nghiêm ngặt: bằng chứng kiểm toán không được phụ thuộc vào một hệ thống duy nhất có thể bị người trong nội bộ can thiệp.

Và "immediately remove the key material" — custom key store cho hai cách:

# Cách 1: ngắt kết nối key store — mọi khoá trong đó ngừng hoạt động NGAY
aws kms disconnect-custom-key-store --custom-key-store-id cks-abc123

# Cách 2: xoá key material trong chính cụm CloudHSM

Khác hẳn KMS thường, nơi ScheduleKeyDeletion có thời gian chờ tối thiểu 7 ngày.

Custom key store là cầu nối giữa hai dịch vụ:

AWS KMS (API quen thuộc, tích hợp S3/EBS/RDS)
    ↓ custom key store
AWS CloudHSM (key material nằm trong HSM CỦA BẠN, không bao giờ rời ra)

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

• B. Tạo KMS key trong custom key store và lưu key material trong Amazon S3 — đây là phương án gần nhất và có vế custom key store đúng, nhưng nó sai nghiêm trọng về bảo mật: key material KHÔNG BAO GIỜ được lưu ngoài HSM. Toàn bộ giá trị của HSM là khoá không rời khỏi phần cứng chuyên dụng. Và custom key store bắt buộc phải được hậu thuẫn bởi CloudHSM.
• C. Dùng KMS tạo AWS MANAGED key và lưu key material trong CloudHSM — mâu thuẫn nội tại: AWS managed key (như aws/s3) do AWS tạo và quản lý hoàn toàn — bạn không sửa được key policy, không kiểm soát được key material. Trái thẳng yêu cầu "full control".
• A. Dùng KMS tạo AWS OWNED key và lưu key material trong CloudHSM — còn ít kiểm soát hơn nữa: AWS owned key thuộc về AWS, bạn thậm chí không nhìn thấy chúng trong tài khoản của mình.

Ghi nhớ

Bốn loại KMS key — theo mức kiểm soát: | Loại | Ai kiểm soát | Sửa key policy | Kiểm toán | |---|---|---|---| | AWS owned | AWS hoàn toàn | ❌ | không thấy | | AWS managed (aws/s3) | AWS | ❌ | CloudTrail | | Customer managed | bạn | ✅ | CloudTrail | | Custom key store + CloudHSM | BẠN, gồm cả phần cứng | ✅ | CloudTrail + log CloudHSM ← câu này |

Cột cuối là điểm phân biệt của câu hỏi này.

Custom key store và CloudHSM trực tiếp — chọn cái nào: | | Custom key store | CloudHSM trực tiếp | |---|---|---| | API | KMS (quen thuộc) | PKCS#11, JCE, CNG | | Tích hợp S3, EBS, RDS | ✅ | ❌ phải tự viết | | Dùng khi | cần SSE cho dịch vụ AWS ← câu này | ứng dụng tự quản lý mã hoá |

Đề nói "easily integrate this with other AWS services" — và đó là lý do custom key store thắng CloudHSM thuần.

Bốn điều cần biết về custom key store: | Điều | Chi tiết | |---|---| | Cụm CloudHSM cần ít nhất 2 HSM | tính sẵn sàng | | Cụm phải ở trạng thái kết nối | cụm chết = không giải mã được gì | | BẠN chịu trách nhiệm sao lưu | AWS không khôi phục hộ | | Chi phí đáng kể | CloudHSM tính phí theo giờ mỗi HSM |

Dòng thứ hai là rủi ro vận hành thật: với KMS thường, AWS đảm bảo tính sẵn sàng; với custom key store, mất cụm là mất khả năng truy cập mọi dữ liệu mã hoá bằng khoá đó. Đó là cái giá của việc tự kiểm soát.

Ba lý do tổ chức chọn custom key store: | Lý do | Chi tiết | |---|---| | Yêu cầu tuân thủ về vị trí và quyền kiểm soát khoá | một số quy định đòi tổ chức tự vận hành HSM | | Xoá key material tức thì | không chờ 7–30 ngày ← câu này | | Kiểm toán độc lập | log CloudHSM tách biệt ← câu này |

Và một lựa chọn trung gian đáng biết: KMS key với key material NHẬP KHẨU (origin EXTERNAL) cũng cho phép xoá tức thì bằng DeleteImportedKeyMaterial và cho bạn tự sinh key material — mà không cần vận hành cụm CloudHSM. Nó rẻ hơn nhiều nhưng không có log kiểm toán độc lập, nên không đáp ứng đủ yêu cầu của đề này.

Cả CloudHSM lẫn KMS đều đạt FIPS 140-2 Level 3 cho module mật mã — khác biệt không nằm ở mức chứng nhận mà ở ai vận hành phần cứng đó.