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

Đáp án

A — Dùng AWS Lake Formation để hợp nhất dữ liệu từ nhiều tài khoản vào một tài khoản duy nhất.

Vì sao đúng

Đề nêu ba yêu cầu, và Lake Formation được thiết kế đúng cho cả ba: | Yêu cầu | Cơ chế | |---|---| | Truy vấn dữ liệu ở nhiều tài khoản từ một data lake trung tâm | Lake Formation chia sẻ chéo tài khoản | | Cấp quyền theo VAI TRÒ người dùng | quyền ở mức bảng, cột, dòng và ô | | Giảm thiểu chi phí và công vận hành | KHÔNG phải sao chép dữ liệu |

Điểm quan trọng nhất và hay bị hiểu nhầm: Lake Formation KHÔNG di chuyển dữ liệu.

Dữ liệu VẪN NẰM NGUYÊN trong bucket S3 của từng tài khoản
    ↓ Lake Formation quản lý METADATA và QUYỀN tập trung
Tài khoản trung tâm truy vấn được mọi nguồn
    → không sao chép, không tốn phí truyền dữ liệu
    → không có bản sao lệch nhau

Đây chính là vế "minimize overhead and costs": mọi phương án sao chép dữ liệu đều nhân đôi chi phí lưu trữ và tạo ra vấn đề đồng bộ.

Và mức phân quyền của Lake Formation vượt xa IAM policy thuần: | Mức | Ví dụ | |---|---| | Bảng | role A truy cập được bảng don_hang | | Cột | role B thấy mọi cột TRỪ so_the_tin_dung | | Dòng | role C chỉ thấy dòng có chi_nhanh = 'HN' | | Ô (cell) | kết hợp cả hai | | Gắn thẻ (LF-Tags) | cấp quyền theo thẻ thay vì liệt kê từng bảng |

LF-Tags là cơ chế mở rộng tốt nhất: gắn thẻ mucDoNhayCam=cao cho các bảng, rồi cấp quyền theo thẻ — bảng mới gắn thẻ đó tự động thừa hưởng quyền, không phải cấu hình lại.

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

• C. Tạo Lambda function chạy theo lịch bằng EventBridge để chuyển dữ liệu từ nhiều tài khoản sang bucket S3 của tài khoản trung tâm — đây là phương án gần nhất và hoạt động được, nhưng nó tốn kém và nhiều công nhất: phải viết và bảo trì mã, nhân đôi chi phí lưu trữ, tốn phí truyền dữ liệu chéo tài khoản, và dữ liệu luôn cũ hơn nguồn. Và nó không giải quyết vế phân quyền theo vai trò chút nào.
• B. Dùng Amazon Data Firehose để hợp nhất dữ liệu từ nhiều tài khoản vào một tài khoản — sai loại dịch vụ: Firehose là đường ống nạp dữ liệu LUỒNG (log, sự kiện, telemetry). Nó không phải công cụ hợp nhất dữ liệu tĩnh đã nằm sẵn trong các bucket S3.
• D. Dùng AWS Control Tower để quản lý tập trung bucket S3 của từng tài khoản — nhầm chức năng: Control Tower dựng và quản trị môi trường nhiều tài khoản (tạo tài khoản theo mẫu, áp guardrail, thiết lập log tập trung). Nó không quản lý dữ liệu hay cấp quyền truy cập dữ liệu.

Ghi nhớ

Ba thành phần của AWS Lake Formation: | Thành phần | Việc | |---|---| | Data Catalog (dùng chung với Glue) | metadata: bảng, lược đồ, vị trí | | Permissions | quyền ở mức bảng, cột, dòng, ô | | Blueprints | mẫu nạp dữ liệu từ nguồn có sẵn |

Lake Formation dùng chung Glue Data Catalog — nên Athena, Redshift Spectrum, EMR và QuickSight đều tôn trọng quyền mà bạn đặt.

Hai mô hình chia sẻ chéo tài khoản của Lake Formation: | Mô hình | Đặc điểm | |---|---| | Chia sẻ trực tiếp tới tài khoản | liệt kê account ID | | Chia sẻ tới AWS Organizations hoặc OU | tài khoản mới tự động được bao phủ |

Lake Formation và IAM policy thuần — vì sao Lake Formation hơn: | | IAM + bucket policy | Lake Formation | |---|---|---| | Mức phân quyền | bucket, prefix | bảng, CỘT, DÒNG | | Quản lý | mỗi tài khoản một bộ policy | tập trung một chỗ | | Kiểm toán | rải rác | một nơi xem toàn bộ quyền | | Chia sẻ chéo tài khoản | thủ công từng bucket | qua Data Catalog |

Cột giữa là hạn chế thật của cách làm truyền thống: với bucket policy, bạn không giấu được một cột khỏi người dùng — hoặc họ đọc được cả tệp, hoặc không đọc được gì.

Kiến trúc data lake nhiều tài khoản chuẩn:

Tài khoản Producer A ──┐
Tài khoản Producer B ──┼─→ Lake Formation (tài khoản trung tâm)
Tài khoản Producer C ──┘        ↓ quản lý metadata + quyền
                          Tài khoản Consumer
                          ↓ Athena / Redshift Spectrum / EMR
                        Truy vấn dữ liệu Ở NGUYÊN CHỖ CŨ

Ba dịch vụ truy vấn tôn trọng quyền Lake Formation: | Dịch vụ | Đặc điểm | |---|---| | Amazon Athena | SQL không máy chủ — phù hợp nhất cho truy vấn không thường xuyên | | Redshift Spectrum | truy vấn từ cụm Redshift | | Amazon EMR | xử lý Spark quy mô lớn |

Athena thường là lựa chọn đúng cho yêu cầu "minimize costs": tính phí theo dữ liệu quét, không trả tiền khi không truy vấn.

Ba tối ưu chi phí cho data lake: | Tối ưu | Mức tiết kiệm | |---|---| | Định dạng cột (Parquet, ORC) | thường 30–90% dữ liệu quét | | Phân vùng theo ngày, khu vực | chỉ quét phần cần thiết | | Lifecycle chuyển dữ liệu cũ sang Glacier | giảm phí lưu trữ |

Và một lưu ý khi triển khai Lake Formation trên dữ liệu có sẵn: nó yêu cầu bạn đăng ký vị trí S3 với Lake Formation và chuyển quyền từ IAM sang mô hình Lake Formation. Trong giai đoạn chuyển tiếp, hai mô hình quyền cùng tồn tại và có thể gây bối rối — nên rà soát và gỡ các bucket policy cũ sau khi đã chuyển xong.

Đáp án

B — Tạo Auto Scaling group với minimum capacity là 4 và maximum capacity là 6. Triển khai 2 instance ở Availability Zone A và 2 instance ở Availability Zone B.

Vì sao đúng

Đề dùng hai từ có ý nghĩa kỹ thuật khác nhau, và đó là toàn bộ câu hỏi: | Thuật ngữ | Nghĩa | |---|---| | Highly available (sẵn sàng cao) | chịu được sự cố, có thể suy giảm hiệu năng | | Fault tolerant (chịu lỗi) | chịu được sự cố mà KHÔNG suy giảm dịch vụ |

Yêu cầu "fault tolerant" cho workload quan trọng nghĩa là: mất một AZ vẫn phải còn đủ 2 instance.

Phương án C: min = 2, mỗi AZ 1 instance
    AZ-a sập → còn 1 instance
    → KHÔNG đủ 2 instance cho "normal workload"
    → dịch vụ SUY GIẢM  ✗

Phương án B: min = 4, mỗi AZ 2 instance
    AZ-a sập → còn 2 instance ở AZ-b
    → ĐÚNG mức cần cho normal workload
    → dịch vụ KHÔNG suy giảm  ✓

Đây là nguyên tắc dự phòng N+N: để chịu được mất một AZ mà không suy giảm, bạn cần gấp đôi dung lượng cần thiết, chia đều hai AZ.

Và max = 6 khớp yêu cầu "tự động mở rộng lên sáu instance cho tải cao điểm".

Auto Scaling tự cân bằng giữa các AZ — đó là hành vi mặc định:

desired = 4, hai AZ  →  2 + 2
desired = 6, hai AZ  →  3 + 3

Nên bạn chỉ cần khai đúng số lượng và danh sách subnet; ASG lo phần phân bố.

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

• C. min = 2, max = 6; dùng 2 AZ và triển khai 1 instance mỗi AZ — đây là phương án gần nhất và khớp chữ "ít nhất hai instance", nhưng nó chỉ SẴN SÀNG CAO, không CHỊU LỖI: mất một AZ còn đúng một instance — dưới mức cần cho tải bình thường. Với "mission-critical workloads", đó là suy giảm dịch vụ.
• D. min = 2, max = 4; 2 instance ở AZ A và 2 ở AZ B — sai maximum: đề nói mở rộng lên sáu instance cho tải cao điểm. Trần 4 không đáp ứng được.
• A. min = 2, max = 6; triển khai 4 instance trong Availability Zone A — không sẵn sàng cao chút nào: toàn bộ instance nằm trong một AZ. AZ đó sập là mất hoàn toàn dịch vụ.

Ghi nhớ

Sẵn sàng cao và chịu lỗi — bảng phân biệt quan trọng: | | Highly Available | Fault Tolerant | |---|---|---| | Khi có sự cố | vẫn chạy, có thể CHẬM HƠN | vẫn chạy BÌNH THƯỜNG | | Dự phòng | N+1 | N+N (hoặc hơn) | | Chi phí | thấp hơn | cao hơn — dung lượng dư | | Ví dụ | 1 instance mỗi AZ, 2 AZ | 2 instance mỗi AZ, 2 AZ |

Từ khoá trong đề thi:

"fault tolerant", "no degradation", "mission-critical" → dự phòng N+N "highly available" đơn thuần → một instance mỗi AZ có thể đủ

Ba tham số của Auto Scaling group: | Tham số | Việc | |---|---| | MinSize | sàn — ASG không bao giờ xuống dưới | | MaxSize | trần — rào chắn chi phí quan trọng | | DesiredCapacity | số lượng hiện tại, thay đổi theo chính sách mở rộng |

MaxSize là rào chắn chi phí không nên bỏ qua: nó ngăn ASG mở rộng vô hạn khi có tải bất thường — kể cả tải do tấn công gây ra.

Cách Auto Scaling phân bố instance:

① Cố gắng phân bố ĐỀU giữa các AZ đã khai
② Khi scale-out: chọn AZ có ÍT instance nhất
③ Khi scale-in: chọn AZ có NHIỀU instance nhất (xem câu #8142)
④ AZ mất khả dụng → khởi chạy bù ở AZ còn lại

Bước ④ là hành vi tự khôi phục: khi AZ-a sập, ASG tự khởi chạy instance thay thế ở AZ-b để đạt lại DesiredCapacity — nên sau vài phút bạn có lại đủ 4 instance, dù cả bốn nằm trong một AZ.

Ba cấu hình bổ sung cho tính sẵn sàng: | Cấu hình | Lợi ích | |---|---| | Dùng từ 3 AZ trở lên | mất một AZ chỉ mất 1/3 dung lượng thay vì 1/2 | | ELB health check thay vì EC2 health check | phát hiện ứng dụng hỏng, không chỉ máy hỏng | | HealthCheckGracePeriod đủ dài | tránh thay thế instance đang khởi động |

Dòng đầu đáng cân nhắc về mặt kinh tế: với ba AZ, dự phòng N+N chỉ cần 1,5 lần dung lượng thay vì 2 lần — vì mất một AZ chỉ mất một phần ba. Với yêu cầu của đề, ba AZ với 3 instance (min = 3) cũng đáp ứng được và rẻ hơn.

ELB health check là thay đổi nhỏ mà quan trọng: mặc định ASG dùng EC2 status check, chỉ phát hiện máy chết. Nếu ứng dụng treo mà máy vẫn chạy, ASG không làm gì. Chuyển sang ELB health check khiến ASG thay thế cả instance có ứng dụng hỏng:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --health-check-type ELB --health-check-grace-period 300

Và một cách giảm chi phí đáng kể cho dung lượng dư: dùng mixed instance policy với Spot Instance cho phần vượt trên mức nền. Với ứng dụng không trạng thái, phần dung lượng chỉ dùng lúc cao điểm có thể chạy trên Spot với giá rẻ hơn 60–90%.

Đáp án

B — Chuyển cấu hình file share hiện có sang Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu ba đặc điểm của hệ thống hiện tại, và cả ba đều chỉ tới FSx for Windows: | Đặc điểm | Cơ chế | |---|---| | Ứng dụng web dùng IIS trên Windows Server | môi trường Windows | | File share trên NAS | chia sẻ tệp qua SMB | | Cần sẵn sàng cao | FSx Multi-AZ với chuyển đổi tự động |

FSx for Windows File Server là dịch vụ Windows-native thật sự: | Tính năng | Chi tiết | |---|---| | Giao thức SMB | ứng dụng Windows dùng nguyên không sửa gì | | Tích hợp Active Directory | phân quyền theo tài khoản domain | | Windows ACL đầy đủ | quyền NTFS giữ nguyên | | DFS Namespace | gộp nhiều file system thành một không gian tên | | Volume Shadow Copy | người dùng tự khôi phục phiên bản trước của tệp |

Vế "migrate the existing file share configuration" là điểm mấu chốt: FSx for Windows cho phép chuyển sang mà không sửa ứng dụng và không đổi cách phân quyền — đường dẫn UNC vẫn dạng \\fs-abc123.congty.local\share.

Và Multi-AZ cho vế sẵn sàng cao:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 300 --storage-type SSD   --subnet-ids subnet-0aaa subnet-0bbb   --windows-configuration     'DeploymentType=MULTI_AZ_1,ThroughputCapacity=32,
     ActiveDirectoryId=d-1234567890'

Dữ liệu được sao chép đồng bộ giữa hai AZ, chuyển đổi tự động khi có sự cố.

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

• **A. Chuyển cấu hình file share sang AWS Storage Gateway — đây là phương án gần nhất và File Gateway có hỗ trợ SMB, nhưng nó dành cho kiến trúc LAI: nó chạy như một máy ảo tại trung tâm dữ liệu của bạn, làm cache cục bộ và đồng bộ lên S3. Đề nói công ty chuyển hẳn ứng dụng lên AWS — không còn máy chủ tại chỗ để đặt gateway. (Có FSx File Gateway cho việc truy cập FSx từ tại chỗ, nhưng đó cũng là kịch bản lai.)
• **C. Chuyển sang Amazon EFS — sai giao thức: EFS dùng NFS, thiết kế cho Linux. Windows không mount EFS một cách tự nhiên, và không có tích hợp Active Directory hay Windows ACL.
• **D. Chuyển sang Amazon EBS — sai loại lưu trữ: EBS là lưu trữ KHỐI gắn với MỘT instance. Nó không phải file share và không chia sẻ được giữa nhiều máy chủ (trừ Multi-Attach hạn chế trong cùng AZ).

Ghi nhớ

Bốn dịch vụ lưu trữ chia sẻ — chọn theo hệ điều hành và giao thức: | Dịch vụ | Giao thức | Hệ điều hành | |---|---|---| | FSx for Windows File Server | SMB | Windows ← câu này | | Amazon EFS | NFS (POSIX) | Linux | | FSx for Lustre | POSIX hiệu năng cao | Linux — HPC, học máy | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | đa nền tảng |

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

"Windows", "SMB", "Active Directory", "IIS", ".NET", "SharePoint" → FSx for Windows "Linux", "NFS", "POSIX" → EFS "HPC", "machine learning", "parallel" → FSx for Lustre

Hai kiểu triển khai của FSx for Windows: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, KHÔNG chịu được sự cố AZ | | Multi-AZ | sao chép đồng bộ, chuyển đổi tự động ← đề yêu cầu |

Yêu cầu "highly available" trong đề bắt buộc chọn Multi-AZ — Single-AZ vẫn có độ bền dữ liệu nhưng file system không truy cập được khi AZ đó gặp sự cố.

Ba lựa chọn Active Directory cho FSx: | Lựa chọn | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD do AWS vận hành — đơn giản nhất | | AD tự quản (self-managed) | AD của bạn trên EC2 hoặc tại chỗ qua DX/VPN | | — | FSx for Windows BẮT BUỘC phải nối AD |

Dòng cuối là điều kiện tiên quyết hay bị bỏ sót: không có AD thì không tạo được FSx for Windows file system.

Ba công cụ di chuyển dữ liệu sang FSx: | Công cụ | Đặc điểm | |---|---| | AWS DataSync | được quản lý, giữ nguyên metadata và ACL, nhanh | | Robocopy | công cụ Windows quen thuộc, dùng /COPYALL để giữ ACL | | AWS Snowball | khối lượng rất lớn, băng thông hạn chế |

DataSync là lựa chọn khuyến nghị: nó giữ nguyên quyền NTFS, timestamp và các luồng dữ liệu phụ — thứ mà một lệnh sao chép thường làm mất.

Ba tính năng đáng bật cho môi trường sản xuất: | Tính năng | Lợi ích | |---|---| | Sao lưu tự động hằng ngày | giữ tới 90 ngày | | Volume Shadow Copy | người dùng tự khôi phục tệp bằng tab "Previous Versions" | | Mã hoá at-rest bằng KMS | bật mặc định |

Volume Shadow Copy giảm đáng kể số yêu cầu hỗ trợ: người dùng xoá nhầm tệp thì tự khôi phục được ngay trong Windows Explorer, không cần gọi quản trị viên.

Và một lưu ý về hiệu năng: FSx for Windows tính hiệu năng theo throughput capacity (MB/giây) mà bạn cấp, độc lập với dung lượng lưu trữ. Cấp quá thấp gây nghẽn dù còn nhiều dung lượng trống — nên đo lường tải thật của file share hiện tại trước khi chọn con số.

Đáp án

D — Amazon Aurora Global Database.

Vì sao đúng

Đề nêu bốn yêu cầu, và Aurora Global Database là dịch vụ quan hệ duy nhất đạt được các con số đó: | Yêu cầu | Aurora Global Database | |---|---| | Cơ sở dữ liệu QUAN HỆ | Aurora — tương thích MySQL và PostgreSQL | | RPO 1 giây | độ trễ sao chép điển hình DƯỚI 1 giây | | RTO dưới 1 phút | promote Region phụ thường dưới 1 phút | | Sao chép chéo Region tự động | tích hợp sẵn, không cần cấu hình gì thêm |

Cách Aurora Global Database đạt được các con số này:

Sao chép ở TẦNG LƯU TRỮ, không phải tầng cơ sở dữ liệu
    → không dùng binlog replication như MySQL truyền thống
    → dùng hạ tầng mạng chuyên dụng của AWS
    → không tiêu tốn CPU của instance cơ sở dữ liệu
    → độ trễ điển hình DƯỚI 1 GIÂY qua các lục địa

Đây là khác biệt kiến trúc căn bản so với cross-Region read replica thông thường: | | Aurora Global Database | RDS cross-Region read replica | |---|---|---| | Tầng sao chép | lưu trữ (storage-level) | logic (binlog/WAL) | | Độ trễ | thường dưới 1 giây | vài giây tới vài phút, biến động | | Ảnh hưởng tới primary | gần như không | tiêu tốn CPU và I/O | | Promote khi thảm hoạ | dưới 1 phút | vài phút, thủ công | | Số Region phụ | tối đa 5 | nhiều nhưng khó quản |

Và tính năng "managed planned failover" cho phép chuyển vùng có kiểm soát khi cần bảo trì Region chính — không mất dữ liệu chút nào.

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

• **B. Amazon RDS for PostgreSQL với cross-Region read replica — đây là phương án gần nhất và cũng cho sao chép chéo Region, nhưng nó không đạt được các con số đề yêu cầu: sao chép logic qua WAL có độ trễ vài giây tới vài phút tuỳ tải, và promote replica là thao tác THỦ CÔNG mất nhiều phút — không đạt RTO dưới 1 phút.
• **A. Amazon DynamoDB Global Table — sai loại cơ sở dữ liệu: đề nêu rõ "relational database solution". DynamoDB là NoSQL khoá–giá trị, không hỗ trợ JOIN, giao dịch phức tạp hay SQL. (Về mặt RPO/RTO thì Global Table rất tốt — nhưng nó không phải cơ sở dữ liệu quan hệ.)
• **C. Amazon Timestream for Analytics — sai hoàn toàn loại dịch vụ: Timestream là cơ sở dữ liệu chuỗi thời gian cho dữ liệu IoT và telemetry. Nó không phải cơ sở dữ liệu quan hệ và không có cơ chế khôi phục thảm hoạ như đề mô tả.

Ghi nhớ

RPO và RTO — hai chỉ số nền tảng của khôi phục thảm hoạ: | Chỉ số | Nghĩa | |---|---| | RPO (Recovery Point Objective) | MẤT bao nhiêu dữ liệu là chấp nhận được | | RTO (Recovery Time Objective) | MẤT bao lâu để khôi phục dịch vụ |

RPO = 1 giây  → được phép mất tối đa 1 giây dữ liệu cuối
RTO = 1 phút  → dịch vụ phải chạy lại trong vòng 1 phút

Bốn chiến lược khôi phục thảm hoạ — theo RPO/RTO và chi phí: | Chiến lược | RPO / RTO | Chi phí | |---|---|---| | Backup & Restore | giờ / giờ | thấp nhất | | Pilot Light | phút / chục phút | thấp | | Warm Standby | giây / phút | vừa | | Multi-Site Active/Active | gần 0 / gần 0 | cao nhất |

Yêu cầu RPO 1 giây và RTO dưới 1 phút của đề nằm ở mức Warm Standby trở lên — và Aurora Global Database chính là công nghệ nền cho mức đó.

Bốn đặc điểm của Aurora Global Database: | Đặc điểm | Chi tiết | |---|---| | Một Region CHÍNH (đọc và ghi) | | | Tối đa 5 Region PHỤ (chỉ đọc) | mỗi Region tới 16 read replica | | Độ trễ sao chép thường dưới 1 giây | | | write forwarding | Region phụ nhận lệnh ghi và chuyển tiếp về chính |

write forwarding đáng biết: nó cho phép ứng dụng ở Region phụ ghi dữ liệu mà không cần biết Region nào là chính — đơn giản hoá đáng kể mã ứng dụng đa Region.

Hai kiểu chuyển vùng: | Kiểu | Khi nào | Mất dữ liệu | |---|---|---| | Managed planned failover | bảo trì có kế hoạch | KHÔNG — RPO = 0 | | Unplanned (detach and promote) | Region chính gặp thảm hoạ | tối đa bằng độ trễ sao chép |

Ba lợi ích khác ngoài khôi phục thảm hoạ: | Lợi ích | Chi tiết | |---|---| | Đọc độ trễ thấp toàn cầu | người dùng đọc từ Region gần nhất | | Tách workload phân tích | chạy báo cáo ở Region phụ, không ảnh hưởng chính | | Tuân thủ về vị trí dữ liệu | bản sao ở khu vực pháp lý yêu cầu |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền cho instance ở MỌI Region | Region phụ vẫn tính phí đầy đủ | | Phí sao chép dữ liệu chéo Region | tính theo số thao tác ghi được sao chép | | Region phụ có thể chỉ cần 1 instance nhỏ | giảm chi phí, mở rộng khi cần chuyển vùng |

Dòng cuối là mẫu tiết kiệm phổ biến: giữ Region phụ ở dung lượng tối thiểu (mô hình pilot light), rồi mở rộng nhanh khi thực sự phải chuyển vùng. Aurora tách compute khỏi storage nên việc thêm instance rất nhanh.

Và một điều cần kiểm chứng định kỳ: diễn tập chuyển vùng thật. Managed planned failover cho phép làm việc này mà không mất dữ liệu — một quy trình khôi phục thảm hoạ chưa từng được thử không phải là một quy trình, nó chỉ là một tài liệu.

Đáp án

A và C.

• A — Dùng Amazon S3 và tạo lifecycle policy chuyển object sang Amazon S3 Glacier sau 2 năm
• C — Dùng Amazon S3 và tạo lifecycle policy chuyển object sang Amazon S3 Standard-IA sau 2 năm

Vì sao đúng

Đề nêu bốn yêu cầu, và cả hai đáp án đều dựa trên cùng một nền tảng đúng: | Yêu cầu | Cơ chế | |---|---| | Người dùng TOÀN CẦU tải lên nhiều loại tệp | S3 — dung lượng không giới hạn, truy cập qua HTTP | | Tệp cũ hơn 2 năm chuyển sang lớp lưu trữ khác | lifecycle policy với Days: 730 | | Tiết kiệm và mở rộng được | S3 tính phí theo dung lượng thực dùng | | Bền vững và sẵn sàng cao | 11 số 9 độ bền, dữ liệu trên nhiều AZ |

Vì sao S3 là lựa chọn đúng cho tình huống này:

Ứng dụng chạy trên Auto Scaling group
    → instance được thêm và bớt liên tục
    → KHÔNG lưu tệp trên đĩa của instance
    → S3 là kho lưu trữ dùng chung, độc lập với vòng đời instance

Lifecycle policy cho cả hai lớp:

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [
      {"Days": 730, "StorageClass": "STANDARD_IA"},
      {"Days": 1095, "StorageClass": "GLACIER"}
    ]
  }]
}

Hai đáp án khác nhau ở mức đánh đổi giữa chi phí và tốc độ truy xuất: | Lớp | Chi phí lưu trữ | Truy xuất | |---|---|---| | Standard-IA | rẻ hơn Standard ~45% | tức thì, có phí truy xuất | | Glacier | rẻ hơn Standard ~68–95% | 1 phút – 12 giờ (Flexible) |

Cả hai đều hợp lệ — chọn cái nào tuỳ vào việc tệp cũ có còn cần truy cập nhanh hay không.

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

• B. Dùng Amazon EFS và tạo lifecycle policy chuyển sang EFS-IA sau 2 năm — đây là phương án gần nhất và EFS thật sự có lifecycle policy, nhưng nó không phù hợp cho tình huống này: EFS là hệ thống tệp NFS cho Linux, không phải kho lưu trữ cho ứng dụng web toàn cầu. Và EFS đắt hơn S3 đáng kể cho cùng dung lượng — trái yêu cầu "cost-effective".
• D. Dùng EBS volume để lưu tệp; cấu hình Data Lifecycle Manager (DLM) lên lịch chụp snapshot sau 2 năm — hai vấn đề: EBS volume gắn với MỘT instance, không chia sẻ được cho Auto Scaling group; và snapshot là SAO LƯU, không phải chuyển lớp lưu trữ — dữ liệu gốc vẫn nằm trên EBS với giá đầy đủ.
• E. Dùng cấu hình RAID 0 nhiều EBS volume để lưu tệp; DLM chụp snapshot sau 2 năm — cùng vấn đề như D, cộng thêm rủi ro: RAID 0 không có dự phòng — hỏng một volume là mất toàn bộ dữ liệu. Trái thẳng yêu cầu "durability".

Ghi nhớ

Các lớp lưu trữ S3 — bảng cần thuộc: | Lớp | Truy xuất | Chi phí lưu trữ | Dùng cho | |---|---|---|---| | Standard | tức thì | cao nhất | truy cập thường xuyên | | Intelligent-Tiering | tức thì | tự tối ưu | mẫu truy cập không đoán được | | Standard-IA | tức thì + phí truy xuất | ~45% rẻ hơn | ít truy cập nhưng cần ngay | | One Zone-IA | tức thì | rẻ hơn nữa | chấp nhận rủi ro một AZ | | Glacier Instant Retrieval | mili giây | rẻ | archive nhưng thỉnh thoảng cần | | Glacier Flexible Retrieval | 1 phút – 12 giờ | rẻ hơn | archive điển hình | | Glacier Deep Archive | 12–48 giờ | ~1 USD/TB/tháng | lưu trữ nhiều năm |

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 thời hạn vẫn bị tính đủ phí — nên đừng chuyển dữ liệu ngắn hạn sang lớp archive.

Ba yếu tố quyết định chi phí S3: | Yếu tố | Chi tiết | |---|---| | Dung lượng lưu trữ | theo GB-tháng, khác nhau theo lớp | | Số request | PUT, GET, LIST — lớp IA và Glacier tính phí cao hơn | | Phí truy xuất | chỉ với IA và Glacier |

Dòng cuối là bẫy chi phí phổ biến: chuyển dữ liệu vẫn thường xuyên được truy cập sang Standard-IA có thể đắt hơn giữ ở Standard — vì phí truy xuất vượt quá khoản tiết kiệm lưu trữ.

S3 Intelligent-Tiering giải quyết đúng vấn đề đó: nó tự theo dõi mẫu truy cập của từng object và chuyển tầng tự động, không có phí truy xuất. Với dữ liệu người dùng tải lên mà bạn không đoán được ai sẽ mở lại tệp nào, đây thường là lựa chọn tốt hơn cả hai đáp án của đề:

{"Transitions": [{"Days": 0, "StorageClass": "INTELLIGENT_TIERING"}]}

Bốn thao tác của lifecycle rule: | Thao tác | Việc | |---|---| | Transitions | chuyển sang lớp rẻ hơn | | 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 nhưng đáng kể: multipart upload thất bại để lại các phần đã tải lên, và chúng tính phí lưu trữ mãi mãi cho tới khi bị dọn. Đặt rule này cho mọi bucket:

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

Và một lưu ý về độ bền: mọi lớp S3 (trừ One Zone-IA) đều có độ bền 99,999999999% và lưu dữ liệu trên ít nhất ba AZ — nên yêu cầu "durability và high availability" của đề được đáp ứng ở mọi lớp, kể cả Glacier.

Đáp án

A — Bật Transfer Acceleration trên bucket đích và tải dữ liệu lên bằng Multipart Upload.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều chỉ tới Transfer Acceleration: | Điều kiện | Cơ chế | |---|---| | Nhiều địa điểm ở các quốc gia khác nhau | truyền dữ liệu qua khoảng cách xa | | Kết nối Internet TỐC ĐỘ CAO ở mỗi nơi | có băng thông để tận dụng | | Tổng hợp về Bắc Virginia NHANH NHẤT | S3 Transfer Acceleration |

Cách Transfer Acceleration hoạt động:

KHÔNG có acceleration:
    Trạm ở Nhật → INTERNET CÔNG CỘNG (nhiều chặng, không tối ưu) → S3 ở us-east-1
    → độ trễ cao, thông lượng thấp và biến động

CÓ acceleration:
    Trạm ở Nhật → đ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) → S3 ở us-east-1
    → nhanh hơn đáng kể, đặc biệt với khoảng cách lớn

Và Multipart Upload nhân đôi hiệu quả: | Lợi ích | Chi tiết | |---|---| | Tải nhiều phần SONG SONG | tận dụng hết băng thông sẵn có | | Thử lại chỉ phần lỗi | không phải tải lại cả 500 GB | | Tạm dừng và tiếp tục được | |

Với tệp 500 GB, multipart upload không phải tuỳ chọn mà là bắt buộc:

Giới hạn của một lần PUT: 5 GB
Bắt buộc multipart:        tệp trên 5 GB
Khuyến nghị multipart:     tệp trên 100 MB

Kết hợp cả hai là cấu hình tối ưu cho đúng bài toán này: đường đi ngắn và ổn định (acceleration) cộng với việc dùng hết băng thông (multipart song song).

aws s3api put-bucket-accelerate-configuration   --bucket du-lieu-khi-tuong --accelerate-configuration Status=Enabled

aws configure set default.s3.use_accelerate_endpoint true
aws configure set default.s3.max_concurrent_requests 20
aws s3 cp du-lieu.dat s3://du-lieu-khi-tuong/

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

• B. Tải dữ liệu lên bucket S3 gần nhất, rồi thiết lập cross-region replication sang bucket đích — đây là phương án gần nhất và hoạt động được, nhưng nó chậm hơn và tốn kém hơn: dữ liệu phải được ghi hai lần (bucket nguồn rồi bucket đích), tốn phí lưu trữ kép và phí truyền dữ liệu chéo Region. Và CRR là bất đồng bộ nên có độ trễ thêm.
• C. Dùng AWS Snowball Edge để truyền lượng dữ liệu lớn — không phù hợp với điều kiện của đề: Snowball là thiết bị vật lý được vận chuyển bằng đường bưu điện, mất nhiều ngày tới nhiều tuần. Nó dành cho nơi băng thông hạn chế — nhưng đề nói rõ mỗi trạm có kết nối Internet tốc độ cao.
• **D. Thiết lập kết nối Site-to-Site VPN — không tăng tốc gì: VPN vẫn chạy trên Internet công cộng với cùng đường đi, và còn thêm overhead mã hoá IPsec. Nó phục vụ kết nối riêng tư, không phải tối ưu thông lượng.

Ghi nhớ

Ba cách đưa dữ liệu lớn vào AWS — chọn theo băng thông và thời gian: | Cách | Phù hợp khi | |---|---| | S3 Transfer Acceleration | có băng thông tốt, cần nhanh, khoảng cách xa ← câu này | | AWS DataSync | đồng bộ định kỳ từ tại chỗ, có agent, giữ metadata | | AWS Snow Family | băng thông hạn chế, khối lượng rất lớn (TB tới PB) | | Direct Connect | cần kết nối riêng lâu dài, băng thông ổn định |

Quy tắc ước lượng thô: nếu tải qua Internet mất hơn một tuần, hãy cân nhắc Snow Family.

500 GB qua đường 1 Gbps ≈ 1,2 giờ  → dùng Internet
50 TB qua đường 100 Mbps ≈ 46 ngày → dùng Snowball

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 | | Tính phí thêm theo GB | chỉ tính khi thực sự có tăng tốc |

Dòng cuối là chi tiết công bằng: AWS chỉ tính phí acceleration nếu nó thực sự nhanh hơn đường thường. Và có công cụ đo trước khi bật:

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

Ba tham số tối ưu cho multipart upload: | Tham số | Ảnh hưởng | |---|---| | multipart_chunksize | kích thước mỗi phần — lớn hơn thì ít request hơn | | max_concurrent_requests | số phần tải song song — tận dụng băng thông | | multipart_threshold | ngưỡng chuyển sang multipart (mặc định 8 MB) |

Với đường truyền tốc độ cao, tăng max_concurrent_requests là cách hiệu quả nhất để dùng hết băng thông — mặc định 10 thường chưa tận dụng hết đường 1 Gbps trở lên.

Ba giới hạn kích thước của S3: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | Một lần PUT tối đa | 5 GB | | Số phần trong multipart | 1 tới 10.000 | | Kích thước mỗi phần | 5 MB – 5 GB (trừ phần cuối) |

Và một lifecycle rule nên có cho mọi bucket dùng multipart: dọn các phần tải lên dở dang. Chúng tính phí lưu trữ mãi mãi nếu không được dọn, và với tệp 500 GB thì các phần bỏ dở rất tốn kém:

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

Và một lựa chọn đáng cân nhắc cho tình huống thu thập dữ liệu định kỳ như đề mô tả: AWS DataSync với agent đặt tại mỗi trạm. Nó tự động hoá việc đồng bộ theo lịch, xác minh tính toàn vẹn, và xử lý thử lại — bền hơn là chạy aws s3 cp bằng script tự viết.

Đáp án

D — Tạo file system bằng Amazon FSx for Windows File Server và tham gia (join) vào một Active Directory domain trên AWS.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều chỉ tới FSx for Windows: | Yêu cầu | Cơ chế | |---|---| | SharePoint dùng Windows shared file storage | giao thức SMB | | Sẵn sàng cao | FSx Multi-AZ với chuyển đổi tự động | | Tích hợp Active Directory để phân quyền và xác thực | FSx for Windows BẮT BUỘC nối AD |

Microsoft SharePoint là chỉ dấu rõ ràng: nó là ứng dụng Windows đòi file share SMB với quyền NTFS và xác thực bằng tài khoản domain. Không có dịch vụ nào khác của AWS đáp ứng đủ ba thứ đó.

FSx for Windows là dịch vụ Windows-native thật sự: | Tính năng | Chi tiết | |---|---| | Giao thức SMB (2.0 tới 3.1.1) | ứng dụng dùng nguyên, không sửa gì | | Windows ACL đầy đủ (NTFS) | quyền giữ nguyên khi di chuyển | | Tích hợp Active Directory | xác thực bằng Kerberos, phân quyền theo nhóm domain | | DFS Namespace và DFS Replication | gộp không gian tên, sao chép | | Volume Shadow Copy | người dùng tự khôi phục phiên bản cũ |

Và vế "join it to an Active Directory domain in AWS" là chi tiết đúng và bắt buộc:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 500 --storage-type SSD   --subnet-ids subnet-0aaa subnet-0bbb   --windows-configuration     'DeploymentType=MULTI_AZ_1,ThroughputCapacity=32,
     ActiveDirectoryId=d-1234567890'

Không có AD thì không tạo được FSx for Windows file system — đây không phải tuỳ chọn.

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

• B. Tạo file system bằng Amazon EFS và tham gia vào Active Directory domain — đây là phương án gần nhất và có vế AD nghe hợp lý, nhưng EFS KHÔNG tham gia được vào Active Directory: nó là hệ thống tệp NFS cho Linux, dùng quyền POSIX (UID/GID), không có khái niệm Windows ACL hay xác thực Kerberos domain.
• **C. Tạo NFS file share bằng AWS Storage Gateway — sai giao thức và sai kiến trúc: SharePoint cần SMB, không phải NFS. Và Storage Gateway dành cho kiến trúc lai — nó chạy tại trung tâm dữ liệu của bạn làm cache, trong khi đề nói công ty chuyển hẳn lên AWS.
• **A. Khởi chạy EC2 Windows Server và mount một S3 bucket làm file volume — S3 KHÔNG mount được như một ổ đĩa một cách được hỗ trợ chính thức: nó là lưu trữ đối tượng truy cập qua HTTP API. (Có công cụ bên thứ ba mô phỏng điều đó, nhưng chúng không cung cấp ngữ nghĩa hệ thống tệp đầy đủ mà SharePoint cần — khoá tệp, ghi một phần, quyền NTFS.)

Ghi nhớ

Bốn dịch vụ lưu trữ chia sẻ — chọn theo hệ điều hành: | Dịch vụ | Giao thức | Xác thực | Hệ điều hành | |---|---|---|---| | FSx for Windows | SMB | Active Directory | Windows ← câu này | | Amazon EFS | NFS | POSIX (UID/GID), IAM | Linux | | FSx for Lustre | POSIX | POSIX | Linux — HPC | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | cả AD lẫn POSIX | đa nền tảng |

Từ khoá nhận diện Windows workload:

"SharePoint", "IIS", ".NET", "SQL Server", "Active Directory", "SMB", "NTFS" → FSx for Windows

Ba lựa chọn Active Directory cho FSx: | Lựa chọn | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD thật do AWS vận hành — đơn giản nhất | | AD tự quản trên EC2 | toàn quyền kiểm soát, tự vận hành | | AD tại chỗ qua Direct Connect/VPN | dùng lại AD hiện có |

Lưu ý quan trọng: AD Connector KHÔNG dùng được cho FSx — nó là proxy xác thực, không phải thư mục đầy đủ. FSx cần một AD thật.

Hai kiểu triển khai của FSx for Windows: | Kiểu | Sẵn sàng | Chi phí | |---|---|---| | Single-AZ | AZ sập là mất truy cập | rẻ hơn | | Multi-AZ | sao chép đồng bộ, chuyển đổi tự động | cao hơn |

Đề yêu cầu "highly available" — nên Multi-AZ là bắt buộc.

Ba yếu tố quyết định hiệu năng FSx for Windows: | Yếu tố | Chi tiết | |---|---| | Throughput capacity | MB/giây — cấp riêng, ĐỘC LẬP với dung lượng | | Storage type | SSD (độ trễ thấp) hoặc HDD (rẻ hơn) | | Deployment type | Multi-AZ có độ trễ ghi cao hơn chút |

Dòng đầu là chỗ hay cấu hình sai: cấp dung lượng lớn nhưng throughput thấp sẽ gây nghẽn dù còn nhiều chỗ trống. Đo tải thật của file share hiện tại trước khi chọn.

Ba công cụ di chuyển dữ liệu sang FSx: | Công cụ | Đặc điểm | |---|---| | AWS DataSync | giữ nguyên ACL, timestamp, luồng dữ liệu phụ | | Robocopy /COPYALL | công cụ Windows quen thuộc | | AWS Snowball | khối lượng lớn, băng thông hạn chế |

Giữ nguyên ACL là yêu cầu bắt buộc với SharePoint — mất quyền NTFS nghĩa là phải cấu hình lại toàn bộ phân quyền tài liệu.

Và một lưu ý về kiến trúc SharePoint trên AWS: ngoài file share, SharePoint còn cần SQL Server làm cơ sở dữ liệu nội dung. Cân nhắc Amazon RDS for SQL Server ở Multi-AZ với xác thực Windows — nó cũng cần AWS Managed Microsoft AD, nên cùng một thư mục phục vụ được cả hai thành phần.

Đáp án

C — Tạo một rate-based rule trong AWS WAF và gắn web ACL vào Application Load Balancer.

Vì sao đúng

Đề mô tả một mẫu tấn công rất cụ thể: nhiều hệ thống với địa chỉ IP THAY ĐỔI LIÊN TỤC gửi số lượng lớn request bất hợp pháp.

Cụm "frequently changing IP addresses" loại bỏ mọi cách chặn theo danh sách IP:

Chặn theo IP cụ thể:
    → chặn IP A → kẻ tấn công chuyển sang IP B
    → chặn IP B → chuyển sang IP C
    → cuộc đuổi bắt không bao giờ kết thúc

Rate-based rule:
    → không quan tâm IP nào
    → chặn BẤT KỲ IP nào vượt ngưỡng request
    → IP mới cũng bị chặn ngay khi nó vượt ngưỡng

Rate-based rule chặn theo HÀNH VI, không theo danh tính — đó là lý do nó đối phó được với IP luân chuyển.

{
  "Name": "GioiHanTanSuat",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {"Limit": 500, "AggregateKeyType": "IP"}
  },
  "Action": {"Block": {}}
}

Và vế "minimal impact on legitimate traffic" cũng được đáp ứng: | Đặc điểm | Chi tiết | |---|---| | Người dùng thật hiếm khi vượt ngưỡng | duyệt web bình thường vài chục request/phút | | Tự động gỡ chặn | khi tần suất giảm xuống dưới ngưỡng | | Cửa sổ trượt 5 phút | không chặn vĩnh viễn |

Dòng giữa quan trọng: khác với chặn cứng theo IP, rate-based rule tự bỏ chặn — nên người dùng hợp lệ đứng sau NAT chung với kẻ lạm dụng sẽ được phục vụ lại khi tình hình bình thường.

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

• A. Tạo một regular rule trong AWS WAF và gắn web ACL vào ALB — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng regular rule khớp theo ĐIỀU KIỆN TĨNH (IP set, chuỗi, đường dẫn, quốc gia). Với IP thay đổi liên tục và request trông hợp lệ, không có điều kiện tĩnh nào bắt được.
• B. Tạo network ACL tuỳ chỉnh gắn vào subnet của ALB để chặn các request vi phạm — hai vấn đề: NACL chặn theo địa chỉ IP tĩnh, nên phải cập nhật liên tục; và nó áp cho cả subnet, có thể ảnh hưởng tài nguyên khác. NACL cũng có giới hạn 20 rule mặc định.
• D. Tạo rule tuỳ chỉnh trong security group của ALB để chặn các request vi phạm — security group KHÔNG CÓ rule deny: nó chỉ có rule Allow, và không khớp rule nào nghĩa là từ chối ngầm định. Không có cách nào "chặn" một IP cụ thể bằng security group.

Ghi nhớ

Cơ chế của rate-based rule: | Đặc điểm | Chi tiết | |---|---| | Cửa sổ đánh giá | 5 phút trượt (cấu hình được: 1, 2, 5, 10 phút) | | Khoá gộp | IP, header, cookie, query string, hoặc kết hợp | | Ngưỡng tối thiểu | 100 request trong cửa sổ | | Tự gỡ chặn | khi tần suất giảm |

Bốn loại AggregateKeyType: | Khoá | Đếm theo | |---|---| | IP | địa chỉ IP nguồn ← câu này | | FORWARDED_IP | IP trong X-Forwarded-For — cần khi có CDN phía trước | | CUSTOM_KEYS | header, cookie, session ID — chính xác hơn IP | | CONSTANT | toàn bộ request khớp scope-down |

CUSTOM_KEYS mạnh cho trường hợp thực tế: giới hạn theo session ID trong cookie hoặc user ID trong header thay vì IP — người dùng chia sẻ IP không bị ảnh hưởng lẫn nhau.

FORWARDED_IP là chi tiết bắt buộc khi có CloudFront: nếu không, WAF thấy mọi request đến từ IP của CloudFront và rate limit sẽ chặn nhầm toàn bộ.

Bốn hành động của WAF rule: | Hành động | Kết quả | |---|---| | Count | chỉ đếm — CHẾ ĐỘ THỬ NGHIỆM | | Allow | cho qua | | Block | chặn, trả 403 | | CAPTCHA / Challenge | phân biệt người và bot |

Challenge đáng ưu tiên trong tình huống của đề: nó gửi một thử thách JavaScript im lặng — bot không vượt qua, trình duyệt thật thì qua mà người dùng không nhận ra. Giảm rủi ro chặn nhầm so với Block.

Quy trình triển khai an toàn:

① Đặt rule ở action Count
② Bật log WAF, quan sát vài ngày
③ Xem có request HỢP LỆ nào vượt ngưỡng không
④ Điều chỉnh ngưỡng, rồi chuyển sang Block hoặc Challenge

Bật Block ngay từ đầu là cách nhanh nhất để chặn nhầm khách hàng thật.

Ba lớp bảo vệ nên có cùng nhau: | Lớp | Chống | |---|---| | Shield Standard | tầng 3/4, MIỄN PHÍ, tự động | | WAF rate-based rule | lạm dụng khối lượng ở tầng 7 ← câu này | | WAF managed rule group | SQL injection, XSS, bot đã biết |

AWSManagedRulesBotControlRuleSet đáng cân nhắc thêm cho đề này: nó nhận diện và phân loại bot bằng chữ ký và hành vi — bắt được cả những bot chưa vượt ngưỡng tần suất.

Và một lưu ý về nguyên tắc: đừng chặn cứng theo IP cho lưu lượng người dùng cuối. Văn phòng, trường học và mạng di động dùng chung một IP — chặn vĩnh viễn sẽ nuốt luôn khách hàng thật mà không có cách nào biết. Cơ chế đếm trong cửa sổ thời gian luôn là lựa chọn an toàn hơn.

Đáp án

D — Tạo một native function hoặc stored procedure gọi AWS Lambda function. Cấu hình Lambda gửi thông báo sự kiện tới một Amazon SQS queue để hệ thống xử lý tiêu thụ.

Vì sao đúng

Đề cần phản ứng khi một dòng dữ liệu bị xoá khỏi bảng — tức là một sự kiện DỮ LIỆU, không phải sự kiện hạ tầng.

Và đó chính là điểm phân biệt quyết định của câu hỏi:

RDS Event Subscription theo dõi sự kiện của INSTANCE và CLUSTER:
    ✓ chuyển đổi dự phòng (failover)
    ✓ sao lưu bắt đầu/kết thúc
    ✓ thay đổi cấu hình
    ✓ khởi động lại, hết dung lượng lưu trữ
    ✗ KHÔNG BAO GIỜ biết về INSERT, UPDATE, DELETE trên bảng

Nên mọi phương án dựa trên RDS event subscription (A, B, C) đều sai từ gốc — chúng không bao giờ được kích hoạt bởi việc một chiếc xe được bán.

Aurora có cơ chế gốc để gọi Lambda từ trong cơ sở dữ liệu:

-- Aurora MySQL
CALL mysql.lambda_async(
  'arn:aws:lambda:ap-northeast-1:111122223333:function:xu-ly-xe-da-ban',
  CONCAT('{"xe_id":"', OLD.xe_id, '","gia":"', OLD.gia, '"}')
);

-- Aurora PostgreSQL — cần extension aws_lambda
SELECT aws_lambda.invoke(
  aws_commons.create_lambda_function_arn('arn:aws:lambda:...:xu-ly-xe-da-ban'),
  json_build_object('xe_id', OLD.xe_id)::json, 'Event');

Đặt trong một trigger là hoàn tất luồng:

CREATE TRIGGER sau_khi_xoa_xe
AFTER DELETE ON danh_sach_xe
FOR EACH ROW
CALL thong_bao_xe_da_ban(OLD.xe_id);

Và SQS ở cuối là lựa chọn đúng cho "distributed processing system": | Lợi ích | Chi tiết | |---|---| | Đệm thông điệp | hệ thống xử lý chậm hay chết thì dữ liệu vẫn chờ | | Nhiều consumer xử lý song song | đúng nghĩa "phân tán" | | Thử lại và DLQ | không mất thông điệp khi lỗi |

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

• C. Tạo RDS event subscription gửi thông báo tới SNS; SNS fan-out sang nhiều SQS queue; xử lý bằng Lambda — đây là phương án gần nhất và có kiến trúc fan-out hoàn toàn đúng (SNS → nhiều SQS là mẫu chuẩn), nhưng nó sai ở nguồn sự kiện: RDS event subscription không phát sự kiện khi dữ liệu thay đổi.
• A. RDS event subscription gửi tới SQS; cấu hình SQS queue fan-out sang nhiều SNS topic — sai cả nguồn sự kiện lẫn chiều fan-out: SQS không fan-out sang SNS. Chiều đúng là SNS → nhiều SQS.
• B. RDS event subscription gửi tới Lambda; Lambda fan-out sang nhiều SQS queue — sai nguồn sự kiện. (Và RDS event subscription gửi tới SNS, không gửi trực tiếp tới Lambda.)

Ghi nhớ

Hai loại "sự kiện" trong ngữ cảnh cơ sở dữ liệu — bảng phân biệt cốt lõi: | Loại | Ví dụ | Cơ chế bắt | |---|---|---| | Sự kiện HẠ TẦNG | failover, backup, thay đổi cấu hình | RDS Event Subscription → SNS | | Sự kiện DỮ LIỆU | INSERT, UPDATE, DELETE trên bảng | trigger + native Lambda function |

Nhầm hai loại này là lỗi phổ biến nhất trong nhóm câu hỏi về RDS.

Cách bắt thay đổi dữ liệu theo từng loại cơ sở dữ liệu: | Cơ sở dữ liệu | Cơ chế | |---|---| | Aurora MySQL | mysql.lambda_async() | | Aurora PostgreSQL | extension aws_lambda | | DynamoDB | DynamoDB Streams + Lambda trigger | | Bất kỳ (bao gồm RDS thường) | AWS DMS với Change Data Capture (CDC) |

Dòng cuối là lựa chọn tổng quát đáng biết: AWS DMS CDC đọc transaction log của cơ sở dữ liệu và stream thay đổi sang Kinesis, S3 hoặc dịch vụ khác — hoạt động với RDS thường vốn không có native Lambda function.

Ba quyền cần cấu hình cho Aurora gọi Lambda:

① IAM role cho cụm Aurora với quyền lambda:InvokeFunction
② Gắn role vào cụm qua aws rds add-role-to-db-cluster
③ Đặt cluster parameter aws_default_lambda_role

Thiếu bước ② là lỗi hay gặp nhất — tạo role rồi quên gắn vào cụm.

Ba cân nhắc khi gọi Lambda từ trigger cơ sở dữ liệu: | Cân nhắc | Chi tiết | |---|---| | Dùng chế độ BẤT ĐỒNG BỘ (Event) | gọi đồng bộ sẽ làm CHẬM giao dịch cơ sở dữ liệu | | Trigger chạy trong giao dịch | Lambda lỗi có thể làm rollback thao tác DELETE | | Khối lượng lớn gây áp lực | xoá hàng loạt sẽ gọi Lambda hàng loạt |

Dòng đầu là thực hành bắt buộc: mysql.lambda_async vốn đã bất đồng bộ, còn với PostgreSQL phải khai 'Event' làm tham số cuối. Gọi đồng bộ trong trigger là công thức làm chậm toàn bộ ứng dụng.

Mẫu kiến trúc đầy đủ cho đề này:

Xe được bán → DELETE khỏi danh sách
    ↓ trigger AFTER DELETE
Aurora gọi Lambda (bất đồng bộ)
    ↓
SQS queue
    ↓ nhiều worker xử lý song song
Hệ thống xử lý phân tán

Và nếu cần fan-out tới nhiều hệ thống, chèn SNS vào giữa:

Lambda → SNS topic → SQS queue A (kế toán)
                   → SQS queue B (báo cáo)
                   → SQS queue C (thông báo khách hàng)

Đó chính là mẫu mà phương án C mô tả — kiến trúc đúng, chỉ là nguồn sự kiện sai.

Một lựa chọn thay thế đáng cân nhắc cho thiết kế dài hạn: thay vì dùng trigger cơ sở dữ liệu, hãy để chính ứng dụng phát sự kiện sau khi commit thành công. Trigger trong cơ sở dữ liệu là logic ẩn — người bảo trì sau này đọc mã ứng dụng sẽ không thấy nó, và đó là nguồn gốc của nhiều sự cố khó chẩn đoán.

Đáp án

D — Tạo một S3 bucket có mã hoá, khởi chạy một AWS Transfer for SFTP endpoint để tải tệp lên bucket đó, và cấu hình một S3 lifecycle rule xoá tệp sau một tháng.

Vì sao đúng

Đề nêu bốn yêu cầu, và D đáp ứng cả bốn với công vận hành thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Truyền tệp bằng SFTP | AWS Transfer Family — dịch vụ SFTP được quản lý | | Mã hoá khi lưu | S3 server-side encryption | | Sẵn sàng cao | cả Transfer Family lẫn S3 đều dư thừa nhiều AZ | | Tự xoá sau một tháng | S3 lifecycle rule |

Vì sao AWS Transfer Family là lựa chọn "least operational overhead":

Tự dựng máy chủ SFTP trên EC2:
    → tự cài và vá phần mềm SFTP
    → tự lo tính sẵn sàng cao (nhiều instance, load balancer)
    → tự quản lý khoá SSH của người dùng
    → tự giám sát và ghi log

AWS Transfer Family:
    → endpoint được quản lý hoàn toàn
    → tự dư thừa nhiều AZ
    → tích hợp IAM, Directory Service hoặc identity provider tuỳ chỉnh
    → ghi log sẵn vào CloudWatch

Và vế "S3 lifecycle rule" là chi tiết phân biệt với phương án A:

{
  "Rules": [{
    "Status": "Enabled",
    "Expiration": {"Days": 30}
  }]
}

Lifecycle rule là tính năng GỐC của S3 — nó chạy tự động, không cần lịch, không cần mã.

Trong khi "retention policy trên SFTP server" mà phương án A nhắc tới KHÔNG TỒN TẠI: AWS Transfer Family chỉ là giao thức truyền tệp, nó không quản lý vòng đời dữ liệu.

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

• A. Tạo S3 bucket có mã hoá; cấu hình AWS Transfer for SFTP; cấu hình retention policy TRÊN SFTP SERVER để xoá tệp sau một tháng — đây là phương án gần nhất và ba phần tư là đúng, nhưng nó mô tả một tính năng không tồn tại: AWS Transfer Family không có retention policy. Việc xoá theo tuổi là của S3 lifecycle.
• B. Tạo Amazon EFS có mã hoá; cấu hình Transfer for SFTP tải lên EFS; áp EFS lifecycle policy xoá tệp sau 30 ngày — hiểu sai EFS lifecycle policy: nó CHUYỂN tệp sang lớp lưu trữ rẻ hơn (IA, Archive) theo mẫu truy cập — nó KHÔNG XOÁ tệp. Và EFS đắt hơn S3 đáng kể cho mục đích lưu trữ tài liệu.
• C. Dựng EC2 instance cài dịch vụ SFTP; mount EFS có mã hoá; thêm cron job xoá tệp cũ hơn một tháng — công vận hành cao nhất: phải tự vá máy chủ, tự lo sẵn sàng cao, tự viết và giám sát cron job. Đúng thứ mà "least operational overhead" muốn tránh.

Ghi nhớ

Bốn giao thức mà AWS Transfer Family hỗ trợ: | Giao thức | Đặc điểm | |---|---| | SFTP | SSH File Transfer Protocol — phổ biến nhất | | FTPS | FTP over TLS | | FTP | không mã hoá — chỉ dùng trong VPC | | AS2 | trao đổi dữ liệu B2B |

Hai đích lưu trữ: | Đích | Dùng khi | |---|---| | Amazon S3 | lưu trữ đối tượng, rẻ, có lifecycle ← câu này | | Amazon EFS | cần ngữ nghĩa hệ thống tệp POSIX |

Ba cách xác thực người dùng SFTP: | Cách | Đặc điểm | |---|---| | Service-managed | AWS lưu khoá công khai SSH — đơn giản nhất | | AWS Directory Service | xác thực bằng Active Directory | | Custom identity provider | Lambda hoặc API Gateway — tích hợp hệ thống có sẵn |

Ba loại endpoint: | Loại | Truy cập từ | |---|---| | Public | Internet | | VPC (internet-facing) | Internet, có Elastic IP cố định | | VPC (internal) | chỉ trong VPC — riêng tư nhất |

Loại thứ hai đáng chú ý cho đối tác doanh nghiệp: nó cho địa chỉ IP tĩnh, nên đối tác đưa được vào danh sách trắng tường lửa của họ.

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

Lưu ý về thời điểm xoá: lifecycle rule chạy mỗi ngày một lần và không đảm bảo xoá đúng vào giờ thứ 720. Object có thể tồn tại thêm vài giờ sau mốc 30 ngày — với yêu cầu tuân thủ nghiêm ngặt về thời hạn, cần cơ chế khác.

Ba lớp mã hoá nên bật cho bucket này: | Lớp | Cấu hình | |---|---| | Mã hoá khi lưu | SSE-S3 hoặc SSE-KMS mặc định trên bucket | | Mã hoá khi truyền | SFTP vốn đã mã hoá; thêm bucket policy aws:SecureTransport | | Block Public Access | mặc định bật cho bucket mới |

Bucket policy bắt buộc HTTPS — nên có cho mọi bucket chứa tài liệu mật:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::tai-lieu/*"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Và một lưu ý về chi phí: AWS Transfer Family tính phí theo giờ cho mỗi endpoint đang bật (khoảng 0,30 USD/giờ, tức ~216 USD/tháng) cộng phí theo GB truyền. Với khối lượng nhỏ, đó là khoản đáng kể — nhưng so với chi phí vận hành và rủi ro bảo mật của việc tự dựng máy chủ SFTP có sẵn sàng cao, nó thường vẫn rẻ hơn.