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

Đáp án

D và E.

• E — Triển khai AWS Organizations để tạo kiến trúc nhiều tài khoản, cho khung nhìn hợp nhất và quản lý tập trung
• D — Tích hợp AWS IAM Identity Center với dịch vụ thư mục của công ty để xác thực tập trung. Cấu hình Service Control Policy (SCP) để quản lý các tài khoản

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi đáp án giải quyết một cái: | Yêu cầu | Cơ chế | |---|---| | Kiến trúc nhiều tài khoản hợp nhất, giảm chi phí vận hành | E — AWS Organizations | | Tích hợp thư mục doanh nghiệp để xác thực tập trung | D — IAM Identity Center |

E — Organizations là nền tảng bắt buộc:

Gom mọi tài khoản vào một tổ chức
    ├─ thanh toán hợp nhất (chia sẻ Reserved Instance, Savings Plan)
    ├─ cấu trúc OU phản ánh cơ cấu doanh nghiệp
    ├─ SCP làm rào chắn cho toàn bộ tổ chức
    └─ điều kiện tiên quyết cho IAM Identity Center

D — IAM Identity Center cho xác thực, và SCP cho kiểm soát:

Nhân viên đăng nhập bằng tài khoản thư mục công ty
    ↓ IAM Identity Center xác thực qua AD Connector hoặc SAML
    ↓ cấp thông tin đăng nhập TẠM THỜI
Truy cập nhiều tài khoản AWS từ MỘT cổng duy nhất
    → quyền theo permission set
    → SCP đặt trần cho mọi tài khoản

Ba lợi ích vận hành mà đề mong muốn: | Lợi ích | Chi tiết | |---|---| | Không có IAM user hay access key dài hạn | thông tin đăng nhập tạm thời qua STS | | Nghỉ việc là mất quyền trên MỌI tài khoản | vô hiệu hoá tài khoản thư mục là xong | | Permission set định nghĩa MỘT LẦN, gán nhiều tài khoản | không tạo role giống hệt ở từng nơi |

Dòng cuối là khoản tiết kiệm chi phí vận hành lớn nhất — với công ty đa quốc gia nhiều chi nhánh, việc quản lý quyền ở một chỗ thay vì hàng chục tài khoản là khác biệt căn bản.

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

• **A. Tạo một entity mới trong AWS Organizations và cấu hình hệ thống xác thực của nó dùng AWS Directory Service TRỰC TIẾP — đây là phương án gần nhất và nhắc đúng cả Organizations lẫn Directory Service, nhưng nó mô tả một tính năng không tồn tại: AWS Organizations KHÔNG có hệ thống xác thực. Nó quản lý tài khoản và chính sách; việc xác thực là của IAM Identity Center hoặc IAM federation.
• **B. Tạo identity pool qua Amazon Cognito và cấu hình IAM Identity Center chấp nhận xác thực Cognito — nhầm đối tượng và nhầm cơ chế: Cognito dành cho người dùng ứng dụng web và di động, không phải nhân viên. Và IAM Identity Center không nhận Cognito làm nguồn danh tính.
• **C. Dùng AWS CloudTrail để ghi log và giám sát tập trung trên mọi tài khoản — là việc nên làm nhưng không trả lời câu hỏi: CloudTrail cho khả năng kiểm toán, nó không hợp nhất tài khoản và không xác thực ai cả.

Ghi nhớ

Ba dịch vụ quản lý nhiều tài khoản — vai trò khác nhau: | Dịch vụ | Việc | |---|---| | AWS Organizations | NỀN TẢNG: gom tài khoản, thanh toán hợp nhất, SCP | | AWS IAM Identity Center | SSO: một danh tính truy cập nhiều tài khoản | | AWS Control Tower | DỰNG môi trường theo chuẩn — chạy TRÊN hai cái trên |

Với công ty đa quốc gia mới hợp nhất, Control Tower đáng cân nhắc mạnh — nó tự động dựng Landing Zone với tài khoản Log Archive, tài khoản Audit, guardrail và Account Factory chỉ bằng vài cú nhấp.

Bốn nguồn danh tính cho IAM Identity Center: | Nguồn | Đặc điểm | |---|---| | Identity Center directory | thư mục dựng sẵn — đơn giản nhất | | Active Directory | qua AD Connector hoặc Managed Microsoft AD | | Nhà cung cấp SAML bên ngoài | Okta, Azure AD, Ping | | — | |

Khái niệm cốt lõi của IAM Identity Center: | Khái niệm | Là gì | |---|---| | Permission set | tập quyền, gán cho nhóm ở nhiều tài khoản | | Assignment | (người dùng/nhóm) × (tài khoản) × (permission set) | | Access portal | cổng đăng nhập một lần |

Bốn đặc tính của SCP: | Đặc tính | Chi tiết | |---|---| | KHÔNG cấp quyền | chỉ giới hạn — vẫn cần IAM cho phép | | ÁP cho root user của tài khoản THÀNH VIÊN | rào chắn thật | | KHÔNG áp cho tài khoản QUẢN LÝ | đừng đặt workload ở đó | | KHÔNG áp cho service-linked role | tránh làm hỏng dịch vụ AWS |

Bộ SCP nền tảng nên có:

Chặn organizations:LeaveOrganization
Chặn cloudtrail:StopLogging, DeleteTrail
Chặn guardduty:Delete*, config:Delete*
Giới hạn Region bằng NotAction + aws:RequestedRegion

Ba lợi ích chi phí của thanh toán hợp nhất: | Lợi ích | Chi tiết | |---|---| | Một hoá đơn cho cả tổ chức | dễ theo dõi | | Mức dùng cộng dồn hưởng bậc giá tốt hơn | S3, truyền dữ liệu | | Reserved Instance và Savings Plan chia sẻ | tài khoản này mua, tài khoản khác dùng được |

Dòng cuối là khoản tiết kiệm đáng kể cho công ty nhiều chi nhánh — dung lượng đặt trước không bị lãng phí ở một tài khoản trong khi tài khoản khác trả giá On-Demand.

(Câu #8203 trong cùng lô này hỏi gần như cùng tình huống với bộ phương án khác — cả hai đều dẫn tới cùng một kết luận: Organizations làm nền, IAM Identity Center làm xác thực.)

Và một lưu ý về thứ tự triển khai: Organizations phải có trước, vì IAM Identity Center ở chế độ tổ chức yêu cầu nó. Với các tài khoản đã tồn tại, dùng cơ chế mời gia nhập thay vì tạo mới.

Đáp án

C — Thay Kinesis Data Streams bằng một Amazon SQS queue. Tạo một Lambda function xử lý các yêu cầu một cách bất đồng bộ.

Vì sao đúng

Đề nêu bốn điều kiện, và cả bốn đều chỉ tới cặp SQS + Lambda: | Điều kiện | Cơ chế | |---|---| | Chỉ MỘT VÀI người dùng tải ảnh lên | khối lượng thấp — không cần dịch vụ luồng | | Xử lý bất đồng bộ | SQS đệm, Lambda xử lý | | Mỗi lượt mất khoảng 5 phút | trong giới hạn 15 phút của Lambda | | Tiết kiệm chi phí nhất | cả hai đều trả theo mức dùng |

Vì sao thay Kinesis bằng SQS là đúng — đây là điểm mấu chốt:

Kinesis Data Streams:
    → tính phí theo SHARD-GIỜ, chạy 24/7 dù không có dữ liệu
    → thiết kế cho hàng nghìn bản ghi mỗi giây
    → cần cho: phát lại dữ liệu, nhiều consumer độc lập, thứ tự nghiêm ngặt

SQS:
    → tính phí theo SỐ REQUEST, không có gì chạy nền
    → dùng ít thì gần như miễn phí
    → đúng cho hàng đợi công việc đơn giản

Với "một vài người dùng" như đề mô tả, Kinesis là dịch vụ đắt tiền bị dùng sai chỗ.

Và Lambda phù hợp vì 5 phút nằm gọn trong giới hạn: | Giới hạn Lambda | Giá trị | |---|---| | Thời gian chạy tối đa | 15 phút | | Bộ nhớ | tới 10.240 MB | | Dung lượng /tmp | tới 10 GB |

Luồng đầy đủ:

Người dùng tải ảnh
    ↓ ứng dụng gửi thông điệp vào SQS, trả lời NGAY "đã nhận"
SQS đệm công việc
    ↓ event source mapping tự gọi Lambda
Lambda xử lý (≤ 5 phút) → ghi vào S3

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

• **A. Kết hợp Lambda và Step Functions để điều phối và xử lý bất đồng bộ — đây là phương án gần nhất và hoàn toàn hoạt động, nhưng nó phức tạp hơn mức cần thiết: Step Functions dành cho quy trình NHIỀU BƯỚC có trạng thái, có rẽ nhánh và xử lý lỗi phức tạp. Ở đây chỉ có một bước xử lý — thêm một dịch vụ điều phối là chi phí và độ phức tạp không cần thiết.
• **B. Dùng SQS xếp hàng rồi xử lý bằng EC2 On-Demand — SQS đúng nhưng compute sai: EC2 On-Demand chạy và tính tiền 24/7 dù chỉ có vài lượt tải lên mỗi ngày. Trái thẳng yêu cầu tiết kiệm nhất.
• **D. Dùng SNS làm bộ đệm rồi xử lý bằng EC2 On-Demand — hai vấn đề: SNS KHÔNG PHẢI bộ đệm — nó đẩy thông điệp đi ngay và không lưu giữ; nếu người nhận không xử lý được thì thông điệp mất. Và vẫn dùng EC2 chạy liên tục.

Ghi nhớ

SQS và Kinesis Data Streams — bảng phân biệt cốt lõi: | | SQS | Kinesis Data Streams | |---|---|---| | Mô hình giá | theo REQUEST | theo SHARD-GIỜ (chạy liên tục) | | Lưu giữ | 1–14 ngày | 1–365 ngày | | Phát lại (replay) | ❌ đọc xong là xoá | ✅ | | Nhiều consumer đọc CÙNG dữ liệu | ❌ | ✅ | | Thứ tự | Standard: gần đúng; FIFO: nghiêm ngặt | theo shard | | Quản lý shard | không có | có |

Quy tắc chọn:

Hàng đợi công việc, mỗi thông điệp xử lý một lần → SQS Phân tích thời gian thực, nhiều consumer, cần phát lại → Kinesis

SNS và SQS — cũng hay bị nhầm: | | SNS | SQS | |---|---|---| | Mô hình | push (đẩy) | poll (kéo) | | Số người nhận | nhiều — pub/sub | một consumer mỗi thông điệp | | Lưu giữ | KHÔNG — gửi ngay hoặc thử lại rồi bỏ | 1–14 ngày |

Dòng cuối là điểm loại của phương án D: gọi SNS là "buffer" là sai bản chất.

Ba cấu hình quan trọng của SQS khi dùng với Lambda: | Cấu hình | Việc | |---|---| | VisibilityTimeout | phải ≥ timeout của Lambda — nếu không thông điệp bị xử lý LẶP | | BatchSize | số thông điệp mỗi lần gọi Lambda | | Dead-letter queue | thông điệp lỗi sau N lần thử |

Dòng đầu là lỗi phổ biến nhất: Lambda chạy 5 phút mà visibility timeout 30 giây nghĩa là thông điệp xuất hiện lại và bị xử lý nhiều lần — sinh ra kết quả trùng lặp.

Quy tắc: VisibilityTimeout ≥ 6 × timeout của Lambda (AWS khuyến nghị)

Ba cách giảm chi phí cho khối lượng thấp: | Cách | Lợi ích | |---|---| | Long polling (ReceiveMessageWaitTimeSeconds = 20) | giảm mạnh lời gọi API rỗng | | Lambda thay vì EC2 | không trả tiền khi nhàn rỗi | | SQS thay vì Kinesis | không có shard chạy nền |

Ba dịch vụ điều phối — chọn theo độ phức tạp: | Dịch vụ | Phù hợp | |---|---| | SQS + Lambda | một bước xử lý đơn giản ← câu này | | Step Functions | nhiều bước, rẽ nhánh, thử lại có trạng thái, chờ phê duyệt | | EventBridge | định tuyến sự kiện theo mẫu |

Step Functions đáng dùng khi: xử lý ảnh gồm nhiều giai đoạn (kiểm tra định dạng → thay đổi kích thước → thêm watermark → lưu → thông báo), mỗi bước có thể lỗi và cần thử lại riêng. Với một bước duy nhất như đề, nó là công cụ thừa.

Và một lưu ý về trải nghiệm người dùng mà đề nhắc tới: ứng dụng trả lời "thành công" ngay sau khi đưa vào hàng đợi, không chờ 5 phút xử lý xong. Với người dùng cần biết kết quả cuối, hãy bổ sung một cơ chế thông báo — ghi trạng thái vào DynamoDB để client hỏi, hoặc gửi thông báo qua SNS khi hoàn tất.

Đáp án

A — Dùng Route 53 Geolocation Routing policy.

Vì sao đúng

Đề nêu yêu cầu rõ ràng: người dùng Nhật Bản kết nối tới ap-northeast-1, người dùng Thuỵ Điển kết nối tới eu-west-1 — và lý do là tuân thủ quy định, không phải hiệu năng.

Geolocation routing định tuyến theo VỊ TRÍ ĐỊA LÝ của người dùng:

Truy vấn DNS từ Nhật Bản
    → Route 53 xác định quốc gia từ IP của trình phân giải
    → trả về địa chỉ ALB ở ap-northeast-1

Truy vấn từ Thuỵ Điển
    → trả về địa chỉ ALB ở eu-west-1

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes": [
    {"Action": "CREATE", "ResourceRecordSet": {
      "Name": "san.congty.vn", "Type": "A",
      "SetIdentifier": "nhat-ban",
      "GeoLocation": {"CountryCode": "JP"},
      "AliasTarget": {"DNSName": "alb-tokyo...", "EvaluateTargetHealth": true, ...}}},
    {"Action": "CREATE", "ResourceRecordSet": {
      "Name": "san.congty.vn", "Type": "A",
      "SetIdentifier": "thuy-dien",
      "GeoLocation": {"CountryCode": "SE"},
      "AliasTarget": {"DNSName": "alb-ireland...", ...}}}]}'

Vì sao Geolocation chứ không phải Latency routing — đây là điểm phân biệt quan trọng:

Geolocation:  định tuyến theo QUỐC GIA của người dùng
              → ĐẢM BẢO đúng vị trí, bất kể độ trễ
              → đúng cho yêu cầu TUÂN THỦ  ← câu này

Latency:      định tuyến theo Region cho ĐỘ TRỄ THẤP NHẤT
              → có thể đưa người Nhật sang Region khác
                nếu đường mạng lúc đó nhanh hơn
              → KHÔNG đảm bảo tuân thủ

Đề nói "because of the compliance requirements in these two locations" — nên tính xác định về vị trí quan trọng hơn tốc độ.

Và nhớ tạo một bản ghi mặc định cho người dùng ở các nước khác:

"GeoLocation": {"CountryCode": "*"}

Không có nó, người dùng ngoài Nhật và Thuỵ Điển không nhận được câu trả lời nào.

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

• **D. Dùng Route 53 Weighted Routing policy — đây là phương án gần nhất về mặt cũng là chính sách của Route 53, nhưng nó chia lưu lượng theo TỶ LỆ, không theo vị trí: người Nhật có thể bị đưa sang Ireland và ngược lại. Weighted dùng cho A/B testing và triển khai dần.
• **C. Tạo CloudFront distribution với geo-restriction — nhầm chức năng: geo restriction CHẶN người dùng từ một số quốc gia. Nó không định tuyến tới Region khác nhau.
• **B. Dùng Application Load Balancer tự động định tuyến lưu lượng tới đúng Region — không thực hiện được: ALB là dịch vụ theo Region — nó phân phối tải giữa các target trong cùng một Region, không định tuyến chéo Region.

Ghi nhớ

Các chính sách định tuyến của Route 53 — bảng cần thuộc: | Chính sách | Định tuyến theo | |---|---| | Simple | một bản ghi | | Weighted | tỷ lệ phần trăm — A/B testing | | Latency | Region cho ĐỘ TRỄ thấp nhất — tối ưu hiệu năng | | Geolocation | VỊ TRÍ người dùng — tuân thủ, nội dung địa phương ← câu này | | Geoproximity | khoảng cách địa lý, có bias điều chỉnh được | | Failover | primary khi khoẻ, secondary khi hỏng | | Multivalue answer | trả nhiều IP có health check | | IP-based | theo dải IP CIDR của client |

Câu hỏi phân biệt — hai chính sách hay bị nhầm nhất:

"compliance", "data residency", "nội dung theo quốc gia", "ngôn ngữ" → Geolocation "performance", "lowest latency", "fastest response" → Latency

Ba mức phân giải của Geolocation: | Mức | Ví dụ | |---|---| | Châu lục | EU, AS, NA | | Quốc gia | JP, SE ← câu này | | Bang (chỉ Hoa Kỳ) | CA, TX | | Mặc định (*) | cho mọi nơi không khớp — BẮT BUỘC phải có |

Route 53 chọn bản ghi CỤ THỂ NHẤT: bang thắng quốc gia, quốc gia thắng châu lục, châu lục thắng mặc định.

Hạn chế của định tuyến theo địa lý — cần biết: | Hạn chế | Chi tiết | |---|---| | Dựa trên IP của TRÌNH PHÂN GIẢI DNS, không phải của người dùng | dùng DNS công cộng (8.8.8.8) có thể cho kết quả sai | | VPN vượt qua được | không phải cơ chế thực thi mạnh | | Cơ sở dữ liệu GeoIP không hoàn hảo | vài phần trăm sai sót |

Dòng đầu là hạn chế kỹ thuật thật: nếu người dùng Nhật cấu hình DNS công cộng đặt ở Mỹ, Route 53 có thể thấy truy vấn đến từ Mỹ. EDNS Client Subnet giảm nhẹ vấn đề này bằng cách truyền một phần IP của client, và Route 53 có hỗ trợ — nhưng không phải mọi trình phân giải đều gửi nó.

Hệ quả cho yêu cầu tuân thủ: DNS routing là lớp hướng dẫn, không phải lớp thực thi. Nếu quy định thực sự nghiêm ngặt về nơi dữ liệu được xử lý, cần thêm kiểm soát ở tầng ứng dụng — ví dụ xác minh quốc gia từ hồ sơ người dùng và từ chối phục vụ ở Region sai.

Ba lưu ý khi cấu hình: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC có bản ghi mặc định (*) | thiếu nó, người dùng nước khác không truy cập được | | Bật health check cho mỗi bản ghi | tự chuyển hướng khi một Region hỏng | | Đặt TTL hợp lý | thấp thì linh hoạt, cao thì giảm chi phí truy vấn |

Kết hợp Geolocation với Failover là mẫu mạnh: mỗi quốc gia có bản ghi chính và bản ghi dự phòng, nên khi Region chính hỏng, người dùng vẫn được phục vụ — dù từ Region khác, và bạn cần cân nhắc điều đó với yêu cầu tuân thủ.

Đáp án

D — Thiết lập các security rule chặn SQL injection và cross-site scripting trong AWS WAF, rồi gắn rule vào Application Load Balancer.

Vì sao đúng

Đề mô tả hai loại tấn công cụ thể — SQL injection và XSS — và cả hai đều là tấn công tầng ứng dụng (tầng 7).

WAF là dịch vụ duy nhất của AWS lọc được nội dung HTTP request:

SQL injection:  ' OR 1=1--  nằm trong tham số truy vấn hoặc form
XSS:            <script>...</script>  nằm trong dữ liệu người dùng nhập
    → phải ĐỌC ĐƯỢC nội dung request mới phát hiện được
    → chỉ WAF làm được việc đó

Và AWS có sẵn managed rule cho đúng hai loại này: | Bộ rule | Bảo vệ | |---|---| | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesCommonRuleSet | OWASP phổ biến, gồm cả XSS | | AWSManagedRulesKnownBadInputsRuleSet | mẫu khai thác đã biết |

Dùng managed rule tốt hơn tự viết vì AWS cập nhật khi có kỹ thuật tấn công mới — bạn không phải theo kịp các biến thể mã hoá hex, comment /**/, encode URL hay Unicode.

Và WAF gắn được vào ALB — đúng kiến trúc mà đề mô tả:

Người dùng → WAF web ACL → Application Load Balancer → Auto Scaling group

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

• B. Dùng AWS Firewall Manager thiết lập rule chặn SQLi và XSS, gắn vào ALB — đây là phương án gần nhất và Firewall Manager thật sự làm việc với WAF, nhưng nó là lớp QUẢN LÝ TẬP TRUNG cho nhiều tài khoản trong AWS Organizations. Nó không tự chặn gì cả — nó triển khai và áp dụng chính sách WAF. Với một ứng dụng đơn lẻ, dùng WAF trực tiếp là đúng và đơn giản hơn.
• A. Dùng Amazon GuardDuty để ngăn SQL injection và XSS — GuardDuty KHÔNG CHẶN gì: nó phát hiện mối đe doạ bằng cách phân tích VPC Flow Logs, DNS log và CloudTrail, rồi sinh finding. Nó không kiểm tra nội dung HTTP request.
• **C. Chặn mọi địa chỉ IP nguồn tấn công bằng Network ACL — sai tầng và không bền: NACL lọc theo IP, cổng, giao thức ở tầng 3/4 — nó không nhìn thấy nội dung request. Và kẻ tấn công đổi IP là phải cập nhật lại mãi.

Ghi nhớ

Bốn dịch vụ tường lửa và bảo vệ của AWS: | Dịch vụ | Tầng | Bảo vệ | |---|---|---| | AWS WAF | 7 (HTTP) | CloudFront, ALB, API Gateway, AppSync | | AWS Shield | 3/4/7 | chống DDoS | | AWS Network Firewall | 3/4 | lưu lượng VPC | | Security group / NACL | 3/4 | ENI / subnet | | AWS Firewall Manager | — | QUẢN LÝ tập trung WAF, Shield, security group |

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

"SQL injection", "XSS", "HTTP request", "web exploit" → WAF "DDoS" → Shield "quản lý cho NHIỀU tài khoản" → Firewall Manager

Bốn loại statement của WAF rule: | Loại | Việc | |---|---| | Managed rule group | bộ quy tắc sẵn của AWS — cập nhật tự động | | Rate-based | giới hạn tần suất theo IP hoặc khoá tuỳ chỉnh | | Match statement | khớp IP set, chuỗi, regex, kích thước, quốc gia | | Logical | AND, OR, NOT |

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

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

① Đặt rule group ở action Count
② Bật log WAF, quan sát vài ngày
③ Kiểm tra request HỢP LỆ nào bị khớp nhầm
④ Thêm exception rồi chuyển sang Block

Bước ③ quan trọng với ứng dụng có form nhập liệu: rule SQLi đôi khi khớp nhầm nội dung chứa dấu nháy hoặc từ khoá SQL hợp lệ.

Và biện pháp gốc rễ mà WAF không thay thế được: | Lỗ hổng | Cách chữa đúng | |---|---| | SQL injection | prepared statement / parameterized query | | XSS | escape output, Content Security Policy |

Ứng dụng dùng đúng truy vấn tham số hoá thì MIỄN NHIỄM với SQL injection ngay cả khi không có WAF. WAF là lớp phòng thủ bổ sung, không phải cái cớ để bỏ qua việc viết mã an toàn.

Và với tình huống của đề — dữ liệu sản xuất đã bị ảnh hưởng — ngoài việc bật WAF, cần rà soát mã ứng dụng để tìm và sửa chính lỗ hổng đó, đồng thời kiểm tra phạm vi dữ liệu bị tác động qua log.

Đáp án

A — Tải HTML, CSS, JavaScript và ảnh lên MỘT bucket S3 duy nhất, bật website hosting, tạo CloudFront distribution và trỏ tên miền vào S3 website endpoint.

Vì sao đúng

Đề nêu ba yêu cầu, và kiến trúc S3 + CloudFront đáp ứng cả ba với chi phí thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Tải trang tối ưu | CloudFront cache ở biên gần người dùng | | Chịu được tần suất request cao | S3 và CloudFront tự mở rộng | | Tiết kiệm nhất | KHÔNG có máy chủ nào chạy |

Vì sao "một bucket duy nhất" là chi tiết đúng:

Website tĩnh = HTML + CSS + JS + ảnh
    → tất cả đều là TỆP TĨNH
    → không có lý do gì tách ra nhiều nơi
    → một bucket, một CloudFront distribution
    → cấu hình đơn giản nhất, chi phí thấp nhất

So sánh chi phí với các phương án có máy chủ: | | S3 + CloudFront | EC2 / Beanstalk | |---|---|---| | Chi phí khi không có ai truy cập | gần bằng 0 | trả tiền 24/7 | | Mở rộng | tự động, không giới hạn | phải cấu hình ASG | | Vá lỗi, bảo trì | không có gì | hệ điều hành, web server | | Sẵn sàng cao | mặc định | phải tự dựng đa AZ |

Và ảnh độ phân giải cao là chỗ CloudFront phát huy mạnh nhất:

Ảnh lớn được cache ở điểm biên gần người dùng
    → không phải tải lại từ S3 mỗi lần
    → giảm cả độ trễ lẫn phí truyền dữ liệu

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

• **B. Host website bằng Nginx trên EC2; ảnh trên S3; CloudFront làm CDN cho ảnh — đây là phương án gần nhất và hoạt động tốt, nhưng nó tốn kém không cần thiết: một website hoàn toàn tĩnh không cần máy chủ web nào. EC2 chạy 24/7 tốn tiền, phải vá lỗi, và phải tự dựng sẵn sàng cao.
• **D. Host website trong Elastic Beanstalk; ảnh trên S3; CloudFront cho ảnh — cùng vấn đề: Beanstalk chạy trên EC2 phía dưới. Nó thêm một tầng quản lý cho thứ vốn không cần máy chủ.
• **C. Auto Scaling group với AMI có Apache; ảnh trên EBS; trỏ endpoint tới Global Accelerator — tốn kém nhất và sai công cụ: EBS gắn với một instance nên không chia sẻ được giữa các máy trong ASG; và Global Accelerator KHÔNG CACHE — với nội dung tĩnh, CloudFront vượt trội.

Ghi nhớ

Kiến trúc website tĩnh chuẩn trên AWS:

Route 53 (alias record)
    ↓
CloudFront (HTTPS qua ACM, cache biên, WAF)
    ↓ OAC
S3 bucket RIÊNG TƯ

Lưu ý quan trọng về endpoint của S3: | Endpoint | Đặc điểm | |---|---| | Website endpoint (s3-website-<region>) | hỗ trợ index/error document, redirect; CHỈ HTTP | | REST API endpoint (s3.<region>) | hỗ trợ HTTPS, dùng được với OAC |

Website endpoint KHÔNG hỗ trợ HTTPS — đây là lý do chính để đặt CloudFront phía trước, và tại sao kiến trúc hiện đại dùng REST endpoint + OAC thay vì website endpoint công khai.

(Đáp án A dùng website endpoint, hợp lệ theo câu hỏi. Nhưng nếu triển khai thật, hãy dùng OAC với bucket riêng tư — an toàn hơn hẳn và vẫn có index document nhờ CloudFront Function hoặc default root object.)

Ba dịch vụ biên — chọn đúng: | Dịch vụ | Cache | Dùng cho | |---|---|---| | CloudFront | ✅ | nội dung web tĩnh và động | | Global Accelerator | ❌ | TCP/UDP không phải HTTP, cần IP tĩnh | | Route 53 | — | định tuyến tầng DNS |

Ba cách tối ưu thêm cho website nhiều ảnh: | Cách | Lợi ích | |---|---| | Cache-Control: max-age dài cho ảnh | ít request tới origin | | Bật nén Gzip/Brotli | giảm dung lượng HTML, CSS, JS | | Dùng định dạng ảnh hiện đại (WebP, AVIF) | giảm 25–50% dung lượng so với JPEG |

Dòng cuối đáng làm nhất với "high-resolution images" — và CloudFront chọn định dạng theo header Accept được nhờ CloudFront Functions hoặc Lambda@Edge.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Phí truyền dữ liệu của CloudFront rẻ hơn S3 trực tiếp | tiết kiệm thật với lưu lượng lớn | | Chọn price class phù hợp | PriceClass_100 nếu người dùng tập trung ở Bắc Mỹ và châu Âu | | Cache hit ratio cao = ít lời gọi S3 | theo dõi metric CacheHitRate |

Và một lựa chọn đáng biết cho website tĩnh hiện đại: AWS Amplify Hosting đóng gói sẵn toàn bộ kiến trúc này (S3 + CloudFront + CI/CD từ Git) — ít công cấu hình hơn nữa, dù kém linh hoạt hơn khi cần tuỳ chỉnh sâu.

Đáp án

A — Dùng AWS DataSync chuyển hồ sơ lịch sử từ tại chỗ lên AWS, và chọn Amazon S3 Glacier Deep Archive làm đích.

Vì sao đúng

Đề nêu hai yêu cầu, và A đáp ứng cả hai với chi phí thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Chuyển hồ sơ LỊCH SỬ lên AWS | DataSync — dịch vụ di chuyển dữ liệu được quản lý | | Tối ưu chi phí và công vận hành | ghi THẲNG vào Deep Archive, không qua tầng trung gian |

Điểm mấu chốt: DataSync ghi TRỰC TIẾP vào lớp lưu trữ đích được.

Phương án C (qua Standard rồi lifecycle):
    ① Ghi vào S3 Standard        → trả giá Standard trong 30 ngày
    ② Sau 30 ngày lifecycle chuyển → thêm phí chuyển đổi mỗi object
    → tốn kém và thừa một bước

Phương án A (ghi thẳng):
    Ghi thẳng vào Deep Archive
    → trả giá Deep Archive ngay từ đầu
    → không có phí chuyển đổi

Với "historical records" — dữ liệu vốn đã nguội — không có lý do gì để chúng nằm ở Standard dù chỉ một ngày.

aws datasync create-location-s3   --s3-bucket-arn arn:aws:s3:::kho-ho-so-lich-su   --s3-storage-class DEEP_ARCHIVE   --s3-config BucketAccessRoleArn=arn:aws:iam::...:role/DataSyncRole

Và DataSync là công cụ đúng cho việc di chuyển một lần: | Đặc điểm | Chi tiết | |---|---| | Được quản lý hoàn toàn | không tự viết script | | Nhanh hơn công cụ thông thường | giao thức tối ưu, nén, song song | | Xác minh tính toàn vẹn | kiểm tra checksum sau khi chuyển | | Giữ metadata | quyền, timestamp |

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

• **C. Dùng DataSync với đích là S3 Standard, rồi lifecycle chuyển sang Deep Archive sau 30 ngày — đây là phương án gần nhất và hoạt động, nhưng nó tốn kém hơn không cần thiết: bạn trả giá Standard suốt 30 ngày cho dữ liệu vốn không ai đụng tới, cộng phí chuyển đổi cho từng object.
• **B. Dùng AWS Storage Gateway chuyển hồ sơ, đích là Deep Archive — sai công cụ cho nhu cầu này: Storage Gateway dành cho kiến trúc LAI liên tục — nó chạy như một máy ảo tại chỗ, làm cache và đồng bộ thường xuyên. Đề mô tả một đợt di chuyển để giải phóng dung lượng, không phải nhu cầu truy cập lai lâu dài.
• **D. Dùng Storage Gateway, đích là S3 Glacier, rồi lifecycle chuyển sang Deep Archive sau 30 ngày — kết hợp cả hai vấn đề: sai công cụ và thừa một bước chuyển tầng tốn phí.

Ghi nhớ

Ba công cụ di chuyển dữ liệu lên AWS — chọn theo tình huống: | Công cụ | Phù hợp | |---|---| | AWS DataSync | di chuyển và đồng bộ qua MẠNG — nhanh, được quản lý ← câu này | | AWS Storage Gateway | kiến trúc LAI — cache cục bộ, truy cập liên tục | | AWS Snow Family | băng thông hạn chế, khối lượng rất lớn |

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

"di chuyển một lần", "đồng bộ định kỳ", "có băng thông tốt" → DataSync "vẫn cần truy cập từ tại chỗ với độ trễ thấp" → Storage Gateway "truyền qua mạng mất hơn một tuần" → Snow Family

Các lớp lưu trữ mà DataSync ghi thẳng được:

S3 Standard, Intelligent-Tiering, Standard-IA, One Zone-IA,
Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive

Ghi thẳng vào lớp đích tiết kiệm cả phí lưu trữ lẫn phí chuyển đổi.

Các lớp lưu trữ cho dữ liệu lưu trữ dài hạn: | Lớp | Truy xuất | Chi phí | |---|---|---| | Standard-IA | mili giây | ~45% rẻ hơn Standard | | Glacier Instant Retrieval | mili giây | rẻ hơn | | Glacier Flexible Retrieval | 1 phút – 12 giờ | rẻ hơn nữa | | Glacier Deep Archive | 12–48 giờ | ~1 USD/TB/tháng — rẻ nhất |

Deep Archive phù hợp cho "historical records" — dữ liệu lưu để tuân thủ, hiếm khi ai xem.

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

Xoá trước hạn vẫn bị tính đủ phí — với hồ sơ lịch sử cần giữ nhiều năm thì không phải vấn đề.

Ba khả năng của DataSync đáng biết: | Khả năng | Chi tiết | |---|---| | Chuyển giữa tại chỗ và AWS | qua agent, hoặc qua Direct Connect/VPN | | Chuyển giữa các dịch vụ AWS | S3 ↔ EFS ↔ FSx | | Lên lịch và chỉ chuyển phần thay đổi | cho đồng bộ định kỳ |

Và một lưu ý về chi phí truy xuất: nếu sau này cần lấy lại hồ sơ từ Deep Archive, phí truy xuất và thời gian chờ 12–48 giờ là đáng kể. Với dữ liệu thỉnh thoảng cần gấp, Glacier Instant Retrieval là điểm cân bằng tốt hơn — đắt hơn về lưu trữ nhưng truy xuất tức thì.

Đáp án

D — Header x-amz-server-side-encryption.

Vì sao đúng

Đề nêu rõ: dùng SSE-S3 (server-side encryption với khoá do S3 quản lý), mã hoá AES-256.

Header đúng và giá trị của nó:

PUT /anh.jpg HTTP/1.1
Host: bucket.s3.amazonaws.com
x-amz-server-side-encryption: AES256

Ba giá trị hợp lệ của header này — tương ứng ba kiểu SSE: | Giá trị | Kiểu mã hoá | |---|---| | AES256 | SSE-S3 — khoá do S3 quản lý ← câu này | | aws:kms | SSE-KMS — khoá trong KMS | | aws:kms:dsse | DSSE-KMS — mã hoá hai lớp |

Và ba header còn lại đều thuộc về SSE-C — một kiểu hoàn toàn khác:

SSE-C = Server-Side Encryption với khoá KHÁCH HÀNG CUNG CẤP
    → bạn tự sinh và tự lưu khoá
    → gửi khoá theo TỪNG REQUEST
    → S3 dùng khoá đó rồi VỨT BỎ, không lưu lại

Ba header này luôn đi CÙNG NHAU — và chúng không dùng cho SSE-S3.

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

• **B. x-amz-server-side-encryption-customer-algorithm — đây là phương án gần nhất về mặt cũng khai thuật toán, nhưng nó thuộc bộ header của SSE-C, không phải SSE-S3. Với SSE-S3, bạn không cung cấp khoá nào nên không cần khai thuật toán riêng.
• **A. x-amz-server-side-encryption-customer-key — header truyền khoá của khách hàng trong SSE-C. SSE-S3 không có khoá nào để truyền.
• **C. x-amz-server-side-encryption-customer-key-MD5 — header kiểm tra tính toàn vẹn của khoá trong SSE-C.

Ghi nhớ

Bốn kiểu mã hoá phía máy chủ của S3: | Kiểu | Ai giữ khoá | Header chính | |---|---|---| | SSE-S3 | AWS hoàn toàn | x-amz-server-side-encryption: AES256 | | SSE-KMS | bạn qua KMS | x-amz-server-side-encryption: aws:kms | | SSE-C | bạn — gửi mỗi request | bộ ba header -customer-* | | DSSE-KMS | bạn qua KMS, hai lớp | aws:kms:dsse |

Mẹo nhớ: header có chuỗi -customer- thì thuộc về SSE-C — kiểu duy nhất mà khách hàng gửi khoá lên.

Cách mã hoá phong bì của SSE-S3:

S3 nhận object
    ↓ sinh một DATA KEY ngẫu nhiên, DUY NHẤT cho object này
    ↓ mã hoá object bằng data key đó (AES-256)
    ↓ mã hoá data key bằng root key của S3
    ↓ lưu data key đã mã hoá cùng object

Mỗi object có khoá riêng — đây là điểm nhiều người không biết về SSE-S3.

Ba cách bật mã hoá cho bucket: | Cách | Đặc điểm | |---|---| | Default encryption trên bucket | mọi object mới tự động được mã hoá — KHUYẾN NGHỊ | | Header trong từng request | phải nhớ ở mọi nơi ghi | | Bucket policy bắt buộc | từ chối request không có header |

Default encryption là cách đúng — nó đảm bảo không ai vô tình tải lên object chưa mã hoá:

aws s3api put-bucket-encryption --bucket kho-du-lieu   --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Lưu ý về mặc định hiện nay: từ năm 2023, S3 tự động mã hoá mọi object mới bằng SSE-S3 — nên câu hỏi này giờ mang tính lịch sử nhiều hơn. Nhưng header vẫn cần thiết khi bạn muốn chỉ định kiểu khác (như aws:kms).

Bucket policy bắt buộc mã hoá bằng KMS — mẫu đáng dùng cho dữ liệu nhạy cảm:

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

Ba lưu ý về SSE-C: | Lưu ý | Chi tiết | |---|---| | BẮT BUỘC dùng HTTPS | khoá đi trong header, không được để lộ | | Mất khoá = mất dữ liệu | S3 KHÔNG lưu khoá của bạn | | Phải gửi khoá cho mọi lần GET | không chỉ lúc PUT |

SSE-C ít được dùng trong thực tế vì gánh nặng quản lý khoá rất lớn — hầu hết trường hợp SSE-KMS cho mức kiểm soát tương đương mà dễ vận hành hơn nhiều.

Đáp án

A — Geoproximity Routing.

Vì sao đúng

Đề có một cụm từ quyết định: "a LARGER PORTION of traffic" từ Philippines và Bắc Ấn Độ sẽ được định tuyến tới ap-northeast-1.

Chỉ Geoproximity routing cho phép ĐIỀU CHỈNH tỷ lệ theo vị trí:

Geoproximity định tuyến theo KHOẢNG CÁCH ĐỊA LÝ
    → người dùng đi tới tài nguyên GẦN nhất
    → NHƯNG có tham số BIAS để MỞ RỘNG hoặc THU HẸP vùng phủ

Bias là điều làm nên câu trả lời:

bias = 0    → vùng phủ theo khoảng cách thực
bias > 0    → MỞ RỘNG vùng phủ của Region đó (tối đa +99)
bias < 0    → THU HẸP vùng phủ (tối thiểu -99)

Áp vào tình huống của đề:

Philippines và Bắc Ấn Độ nằm giữa hai Region
    ap-northeast-1 (Tokyo) và ap-southeast-2 (Sydney)

Đặt bias DƯƠNG cho ap-northeast-1
    → vùng phủ của Tokyo mở rộng về phía nam và tây
    → NHIỀU HƠN lưu lượng từ hai khu vực đó đi về Tokyo

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes": [{"Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.congty.vn", "Type": "A",
      "SetIdentifier": "tokyo",
      "GeoProximityLocation": {"AWSRegion": "ap-northeast-1", "Bias": 50},
      "AliasTarget": {...}}}]}'

Và Route 53 có công cụ trực quan hoá bản đồ lưu lượng (Traffic Flow) để bạn thấy vùng phủ thay đổi thế nào khi điều chỉnh bias — hữu ích vì tác động của bias không dễ hình dung.

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

• **B. Geolocation Routing — đây là phương án gần nhất và cũng định tuyến theo vị trí, nhưng nó là nhị phân: một quốc gia được ánh xạ tới đúng một tài nguyên. Nó không có khái niệm "phần lớn hơn" — không điều chỉnh tỷ lệ được.
• **D. Weighted Routing — chia tỷ lệ nhưng KHÔNG theo vị trí: nó phân phối lưu lượng theo trọng số cho mọi người dùng, bất kể họ ở đâu. Không thể nói "người Philippines thì nghiêng về Tokyo".
• **C. Latency Routing — định tuyến theo ĐỘ TRỄ thấp nhất, và bạn không điều chỉnh được. Nếu đường mạng từ Philippines tới Sydney nhanh hơn thì lưu lượng đi Sydney, dù bạn muốn ngược lại.

Ghi nhớ

Các chính sách định tuyến của Route 53 — bảng cần thuộc: | Chính sách | Định tuyến theo | Điều chỉnh được? | |---|---|---| | Simple | một bản ghi | — | | Weighted | tỷ lệ phần trăm | ✅ nhưng KHÔNG theo vị trí | | Latency | độ trễ thấp nhất | ❌ | | Geolocation | quốc gia/châu lục/bang | ❌ nhị phân | | Geoproximity | khoảng cách + BIAS | ✅ theo vị trí ← câu này | | Failover | primary khoẻ/hỏng | — | | Multivalue answer | nhiều IP có health check | — | | IP-based | dải CIDR của client | — |

Ba chính sách theo vị trí — phân biệt rõ:

"Quốc gia X PHẢI đi tới Region Y" (tuân thủ) → Geolocation "Nghiêng NHIỀU HƠN về Region Y cho khu vực đó" → Geoproximity "Nhanh nhất, không quan tâm ở đâu" → Latency

Ba đặc điểm của Geoproximity: | Đặc điểm | Chi tiết | |---|---| | Chỉ cấu hình được qua Traffic Flow | không tạo trực tiếp bằng bản ghi thường | | Hỗ trợ cả Region AWS lẫn toạ độ tuỳ ý | dùng được cho tài nguyên ngoài AWS | | Bias từ −99 tới +99 | mở rộng hoặc thu hẹp vùng phủ |

Dòng đầu là ràng buộc thực tế: Geoproximity đòi dùng Route 53 Traffic Flow — một tính năng có phí riêng (khoảng 50 USD/tháng cho mỗi traffic policy record).

Hạn chế chung của định tuyến theo địa lý: | Hạn chế | Chi tiết | |---|---| | Dựa trên IP của TRÌNH PHÂN GIẢI DNS | dùng DNS công cộng có thể cho kết quả sai | | VPN vượt qua được | không phải cơ chế thực thi mạnh | | Cơ sở dữ liệu vị trí không hoàn hảo | vài phần trăm sai sót |

EDNS Client Subnet giảm nhẹ vấn đề đầu — Route 53 có hỗ trợ, nhưng không phải trình phân giải nào cũng gửi nó.

Ba lưu ý khi cấu hình: | Lưu ý | Chi tiết | |---|---| | Bật health check cho mỗi endpoint | tự chuyển hướng khi một Region hỏng | | Đặt TTL hợp lý | thấp thì linh hoạt, cao thì rẻ hơn | | Dùng bản đồ trực quan để kiểm chứng | tác động của bias khó hình dung bằng số |

Và một lưu ý về kết hợp chính sách: Route 53 cho phép lồng nhiều chính sách qua Traffic Flow — ví dụ Geoproximity ở tầng ngoài để chọn Region, rồi Failover ở tầng trong để chuyển sang Region dự phòng khi endpoint chính hỏng. Đó là cách xây chính sách định tuyến thật sự linh hoạt.

Đáp án

B — Dùng AWS DataSync để chuyển dữ liệu. Lưu toàn bộ dữ liệu trong Amazon S3 và bật Object Lock.

Vì sao đúng

Đề nêu hai yêu cầu, và B đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Chuyển hồ sơ hiện có lên cloud, hồ sơ tương lai cũng lưu ở đó | DataSync + S3 | | Ngăn dữ liệu bị xoá hoặc ghi đè | S3 Object Lock |

Điểm mấu chốt: Object Lock CHỈ tồn tại trên Amazon S3.

S3       → có Object Lock (WORM)  ✓
EFS      → KHÔNG có Object Lock   ✗
EBS      → KHÔNG có Object Lock   ✗
FSx      → KHÔNG có Object Lock   ✗

Đây là lý do hai phương án nhắc tới EFS và EBS sai ngay từ khái niệm.

Object Lock thực thi mô hình WORM (write once, read many):

Object được ghi với retention period hoặc legal hold
    → KHÔNG ai xoá được
    → KHÔNG ai ghi đè được
    → với chế độ COMPLIANCE: kể cả root user

aws s3api create-bucket --bucket ho-so-tai-chinh   --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration --bucket ho-so-tai-chinh   --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 7}}}'

Và DataSync là công cụ đúng cho việc di chuyển: | Đặc điểm | Chi tiết | |---|---| | Được quản lý hoàn toàn | không tự viết script đồng bộ | | Nhanh hơn công cụ thông thường | giao thức tối ưu, nén, song song | | Xác minh checksum | đảm bảo dữ liệu không hỏng khi chuyển | | Lên lịch được | cho hồ sơ tương lai |

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

• **A. Dùng AWS Storage Gateway dựng lưu trữ lai; lưu dữ liệu trên S3 và bật Object Lock — đây là phương án gần nhất và S3 + Object Lock hoàn toàn đúng, nhưng Storage Gateway là công cụ sai cho tình huống này: nó dành cho kiến trúc LAI liên tục với cache cục bộ. Đề nói trung tâm dữ liệu sắp hết chỗ và họ muốn chuyển hẳn lên cloud — DataSync phù hợp hơn.
• **C. Dùng DataSync; lưu dữ liệu trong Amazon EFS và bật Object Lock — EFS KHÔNG CÓ Object Lock. Đây là tính năng riêng của S3.
• **D. Dùng Storage Gateway; lưu dữ liệu trong Amazon EBS và bật Object Lock — sai cả hai: EBS không có Object Lock, và Storage Gateway không lưu vào EBS theo cách này.

Ghi nhớ

Hai chế độ của S3 Object Lock: | | GOVERNANCE | COMPLIANCE | |---|---|---| | Gỡ trước hạn | ✅ với s3:BypassGovernanceRetention | ❌ KHÔNG AI — kể cả root | | Rút ngắn thời hạn | ✅ | ❌ | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý nghiêm ngặt |

Với hồ sơ tài chính của nhiều công ty như đề mô tả, COMPLIANCE là chế độ phù hợp.

Hai cơ chế khoá: | Cơ chế | Kết thúc khi | |---|---| | Retention period | tới ngày đã định | | Legal hold | có người gỡ tường minh — VÔ THỜI HẠN |

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

① Versioning phải BẬT (Object Lock tự bật nó, và không tắt được)
② 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 object, hoặc default cho bucket

Cảnh báo về COMPLIANCE: đặt nhầm thời hạn nghĩa là trả tiền lưu trữ đủ thời hạn đó — AWS Support cũng không gỡ hộ. Kiểm thử ở GOVERNANCE trước.

Ba công cụ di chuyển dữ liệu — chọn theo tình huống: | Công cụ | Phù hợp | |---|---| | AWS DataSync | di chuyển và đồng bộ qua mạng ← câu này | | AWS Storage Gateway | kiến trúc LAI — vẫn cần truy cập từ tại chỗ | | AWS Snow Family | băng thông hạn chế, khối lượng rất lớn |

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

"chuyển lên cloud", "giải phóng dung lượng tại chỗ" → DataSync "vẫn cần truy cập độ trễ thấp từ tại chỗ" → Storage Gateway

Object Lock hoạt động ở MỌI lớp lưu trữ — nên bạn kết hợp được với lifecycle rule chuyển hồ sơ cũ sang Glacier Deep Archive, giữ tính bất biến mà giảm mạnh chi phí:

{"Rules": [{"Status": "Enabled",
  "Transitions": [{"Days": 90, "StorageClass": "DEEP_ARCHIVE"}]}]}

Ba lớp bảo vệ bổ sung cho hồ sơ tài chính: | Lớp | Chống | |---|---| | Object Lock (COMPLIANCE) | xoá và sửa bởi BẤT KỲ AI | | Mã hoá SSE-KMS | truy cập trái phép vào nội dung | | CloudTrail data event | kiểm toán ai đã đọc gì | | Cross-Region Replication | mất mát do sự cố Region |

Và một lưu ý về chi phí lâu dài: Object Lock không cho xoá, nên dung lượng chỉ tăng. Với hồ sơ tài chính giữ nhiều năm, hãy tính trước tổng chi phí và dùng lifecycle chuyển sang Deep Archive sớm — chênh lệch giữa Standard và Deep Archive là khoảng 20 lần.

Đáp án

C — Dùng AWS Storage Gateway để sao lưu dữ liệu và chuyển sang Amazon S3 Glacier Deep Archive.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều chỉ tới cùng một cấu hình: | Điều kiện | Cơ chế | |---|---| | Đang dùng giải pháp SAO LƯU BĂNG TỪ tại chỗ | Tape Gateway — thư viện băng ảo | | Giữ 10 năm | lưu trữ dài hạn | | Truy cập một tới hai lần mỗi năm | Deep Archive — rẻ nhất |

Tape Gateway là loại Storage Gateway dành riêng cho việc thay thế thư viện băng vật lý:

Phần mềm sao lưu doanh nghiệp (Veeam, NetBackup, Commvault)
    ↓ giao thức iSCSI VTL — phần mềm tưởng đang ghi vào băng thật
Tape Gateway (máy ảo tại trung tâm dữ liệu của bạn)
    ↓
Băng ảo trong S3
    ↓ archive
S3 Glacier hoặc Glacier Deep Archive

Lợi ích lớn nhất: không phải thay đổi quy trình sao lưu hiện có — phần mềm và quy trình giữ nguyên, chỉ có thư viện băng vật lý được thay bằng thư viện ảo.

Và Deep Archive là lớp đúng cho tần suất truy cập mà đề nêu: | Lớp | Truy xuất | Chi phí lưu trữ | |---|---|---| | Glacier Flexible Retrieval | 1 phút – 12 giờ | rẻ | | Glacier Deep Archive | 12–48 giờ | ~1 USD/TB/tháng — rẻ hơn khoảng 4 lần |

Với 10 năm lưu trữ và một tới hai lần truy cập mỗi năm, chênh lệch chi phí lưu trữ vượt xa mọi bất tiện về thời gian truy xuất.

Phép tính minh hoạ cho 100 TB trong 10 năm:

Glacier Flexible:  ~4 USD/TB/tháng × 100 TB × 120 tháng ≈ 48.000 USD
Deep Archive:      ~1 USD/TB/tháng × 100 TB × 120 tháng ≈ 12.000 USD

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

• **A. Dùng Storage Gateway sao lưu trực tiếp vào Amazon S3 Glacier — đây là phương án gần nhất và hoạt động, nhưng nó đắt hơn khoảng bốn lần so với Deep Archive cho cùng một khối lượng. Với tần suất truy cập một tới hai lần mỗi năm, Glacier Flexible là mức dịch vụ cao hơn mức cần thiết.
• **D. Dùng Amazon S3 lưu dữ liệu và lifecycle rule chuyển sang Glacier — bỏ qua vế công cụ: đề nói công ty đang dùng giải pháp sao lưu băng từ. Phương án này không nói gì tới việc kết nối hệ thống đó với AWS, và nó đòi thay đổi toàn bộ quy trình sao lưu.
• **B. Đặt Snowball Edge để nhập bản sao lưu trực tiếp vào Glacier — sai loại nhu cầu: Snowball dành cho một đợt di chuyển khối lượng lớn. Sao lưu là hoạt động liên tục, định kỳ — không thể gửi thiết bị qua bưu điện mỗi tuần.

Ghi nhớ

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

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

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

Các lớp lưu trữ Glacier — chọn theo thời gian chấp nhận chờ: | Lớp | Truy xuất | Phù hợp | |---|---|---| | Glacier Instant Retrieval | mili giây | archive nhưng thỉnh thoảng cần NGAY | | Glacier Flexible Retrieval | 1 phút (expedited) – 12 giờ (bulk) | archive điển hình | | Glacier Deep Archive | 12–48 giờ | lưu trữ nhiều năm, hiếm truy cập ← câu nà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 |

Với 10 năm lưu trữ thì ràng buộc này không phải vấn đề.

Ba đặc điểm của Tape Gateway: | Đặc điểm | Chi tiết | |---|---| | Băng ảo dung lượng 100 GB – 5 TB | tuỳ bạn tạo | | Băng "active" nằm trong Virtual Tape Library | truy cập nhanh | | Băng "archived" chuyển sang Glacier | retrieve về VTL trước khi đọc được |

Dòng cuối là quy trình cần biết: để đọc một băng đã archive, bạn phải retrieve nó về VTL trước — với Deep Archive mất 12–48 giờ. Đó là lý do lớp này chỉ phù hợp khi tần suất truy cập rất thấp.

Ba lợi ích của Tape Gateway so với băng vật lý: | Lợi ích | Chi tiết | |---|---| | Không có băng vật lý để bảo quản và vận chuyển | giảm rủi ro mất mát | | Không có thư viện băng để bảo trì | giảm chi phí phần cứng | | Độ bền 11 số 9 | băng từ vật lý xuống cấp theo thời gian |

Và một lưu ý về kiểm chứng: với dữ liệu giữ 10 năm, hãy thử khôi phục định kỳ. Một bản sao lưu chưa từng được khôi phục thử không phải là bản sao lưu — nó chỉ là một giả định. Với Deep Archive, việc thử này cũng cho bạn biết thực tế mất bao lâu để lấy lại dữ liệu khi cần gấp.