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

Đáp án

A — Cấu hình CloudFront behavior xử lý các định dạng ảnh khác nhau dựa trên header User-Agent. Dùng Lambda@Edge để sửa header phản hồi và phục vụ đúng định dạng.

Vì sao đúng

Đề nêu hai yêu cầu, và Lambda@Edge là công cụ duy nhất làm được cả hai: | Yêu cầu | Cơ chế | |---|---| | Phục vụ WebP cho trình duyệt hỗ trợ, JPEG cho các trình duyệt còn lại | Lambda@Edge đọc header và chọn định dạng | | Thêm header tuỳ chỉnh vào phản hồi để theo dõi | Lambda@Edge sửa được phản hồi |

Lambda@Edge chạy ngay tại điểm biên và can thiệp được vào bốn thời điểm: | Sự kiện | Chạy khi | |---|---| | Viewer request | ngay khi CloudFront nhận request | | Origin request | trước khi gọi origin — nơi chọn định dạng ảnh | | Origin response | sau khi nhận phản hồi từ origin | | Viewer response | trước khi trả về người dùng — nơi thêm header theo dõi |

Mã ví dụ cho origin request:

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const headers = request.headers;
  const accept = headers['accept'] ? headers['accept'][0].value : '';

  if (accept.includes('image/webp')) {
    request.uri = request.uri.replace(/\.jpg$/, '.webp');
  }
  return request;
};

Và vế "cấu hình cache behavior" là mảnh ghép cần thiết: header dùng để quyết định phải nằm trong cache key, nếu không CloudFront sẽ phục vụ nhầm định dạng từ cache:

{"HeadersConfig": {"HeaderBehavior": "whitelist",
                   "Headers": {"Quantity": 1, "Items": ["Accept"]}}}

Không có bước này, người dùng đầu tiên nhận WebP sẽ khiến mọi người sau đó cũng nhận WebP — kể cả trình duyệt không hỗ trợ.

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

• C. Tạo một CloudFront response headers policy và dùng nó để phục vụ đúng định dạng ảnh theo header User-Agent — đây là phương án gần nhất và response headers policy có thật, nhưng nó chỉ THÊM hoặc SỬA HEADER của phản hồi. Nó không chọn được nội dung nào để phục vụ — không có logic điều kiện nào.
• **B. Tạo nhiều CloudFront distribution, mỗi cái phục vụ một định dạng; định tuyến theo User-Agent bằng Route 53 — không thực hiện được: Route 53 định tuyến ở tầng DNS, và DNS không nhìn thấy header HTTP nào cả. Nó chỉ biết địa chỉ IP của người hỏi.
• **D. Triển khai dịch vụ chuyển đổi ảnh trên EC2 tích hợp với CloudFront; dùng Lambda sửa header — công vận hành cao nhất: phải dựng, vá, mở rộng và giám sát một đội EC2 — trái yêu cầu "minimizing operational overhead".

Ghi nhớ

Hai dịch vụ tính toán ở biên của CloudFront: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Ngôn ngữ | chỉ JavaScript | Node.js, Python | | Thời gian chạy | dưới 1 mili giây | 5 giây (viewer), 30 giây (origin) | | Truy cập mạng | ❌ KHÔNG | ✅ gọi được dịch vụ khác | | Truy cập body của request | ❌ | ✅ | | Sự kiện | chỉ viewer request/response | cả bốn sự kiện | | Chi phí | rẻ hơn ~6 lần | cao hơn |

Quy tắc chọn:

Viết lại URL, thêm header, kiểm tra token đơn giản → CloudFront Functions Cần gọi API, đọc body, hoặc can thiệp ở origin request/response → Lambda@Edge

(Với bài toán chọn định dạng ảnh chỉ dựa trên header, CloudFront Functions ở viewer request cũng làm được và rẻ hơn — nhưng thêm header vào phản hồi cần viewer response, mà Functions cũng hỗ trợ. Đáp án dùng Lambda@Edge là hợp lệ, chỉ là không phải phương án tiết kiệm nhất.)

Ba header dùng để quyết định định dạng ảnh: | Header | Đặc điểm | |---|---| | Accept | chuẩn xác nhất — trình duyệt khai image/webp nếu hỗ trợ | | User-Agent | suy đoán từ tên trình duyệt — kém tin cậy hơn | | CloudFront-Viewer-* | header do CloudFront tự thêm |

Accept đáng dùng hơn User-Agent: nó là tuyên bố trực tiếp của trình duyệt về định dạng nó hiểu, không phải suy đoán từ chuỗi phiên bản.

Ba loại policy của CloudFront: | Policy | Quyết định | |---|---| | Cache policy | cái gì nằm trong CACHE KEY + TTL | | Origin request policy | cái gì được chuyển tiếp tới origin (không vào cache key) | | Response headers policy | header CloudFront THÊM vào phản hồi |

Nguyên tắc quan trọng: đưa vào cache key càng ít càng tốt — mỗi giá trị khác nhau tạo một mục cache riêng. Với Accept, hãy dùng normalizeAcceptHeader hoặc chuẩn hoá về hai giá trị (webp / jpeg) để không phân mảnh cache theo hàng trăm biến thể chuỗi Accept.

Ba lưu ý khi triển khai Lambda@Edge: | Lưu ý | Chi tiết | |---|---| | Phải triển khai ở us-east-1 | rồi CloudFront tự nhân bản ra các edge | | Không dùng được biến môi trường | nhúng cấu hình vào mã hoặc lấy từ header | | Giới hạn kích thước và thời gian nghiêm ngặt | nhỏ hơn Lambda thường |

Và một lựa chọn thay thế cho chính bài toán này: nhiều tổ chức dùng dịch vụ chuyển đổi ảnh theo yêu cầu (chuyển đổi và cache lại tại edge) thay vì lưu sẵn hai bản WebP và JPEG. Cách đó tiết kiệm dung lượng lưu trữ nhưng tốn tính toán ở lần đầu — chọn cái nào tuỳ vào số lượng ảnh và tần suất truy cập.

Đáp án

A và B.

• B — Phải có một tên miền đã đăng ký
• A — Tên bucket S3 phải TRÙNG với tên miền

Vì sao đúng

Đề hỏi các điều kiện tiên quyết để Route 53 định tuyến tới một website tĩnh trên S3 — và hai điều kiện này là bắt buộc.

B — tên miền đã đăng ký là hiển nhiên nhưng cần thiết: phải có một hosted zone trong Route 53 để tạo bản ghi. Tên miền đăng ký qua Route 53 hoặc nơi khác đều được, miễn là name server trỏ về Route 53.

A — tên bucket phải trùng tên miền, và đây là ràng buộc kỹ thuật thật:

Tên miền:  www.congty.vn
Tên bucket PHẢI LÀ:  www.congty.vn

Vì sao:
    S3 website endpoint định tuyến request dựa trên header Host
    → request tới www.congty.vn mang Host: www.congty.vn
    → S3 tìm bucket TÊN ĐÚNG NHƯ VẬY
    → tên bucket khác → S3 không biết phục vụ bucket nào → lỗi 404

Cấu hình đầy đủ:

① Tạo bucket tên "www.congty.vn"
② Bật Static website hosting trên bucket
③ Đặt bucket policy cho phép đọc công khai (hoặc dùng CloudFront + OAC)
④ Trong Route 53, tạo ALIAS record:
       Name:   www.congty.vn
       Type:   A
       Alias:  s3-website-ap-northeast-1.amazonaws.com

Alias record là lựa chọn đúng thay vì CNAME: nó dùng được ở đỉnh tên miền (apex, congty.vn) nơi CNAME bị chuẩn DNS cấm, và không tính phí truy vấn.

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

• **D. Bucket S3 phải cùng Region với hosted zone — đây là phương án gần nhất và nghe có vẻ hợp lý, nhưng hosted zone của Route 53 là tài nguyên TOÀN CẦU — nó không thuộc Region nào. Bucket đặt ở Region nào cũng được; bạn chỉ cần trỏ alias tới đúng website endpoint của Region đó.
• **C. Record set phải thuộc loại "MX" — sai loại bản ghi: MX (Mail Exchange) dùng cho ĐỊNH TUYẾN EMAIL. Cho website phải dùng A record với alias (hoặc CNAME cho tên miền con).
• **E. Phải bật CORS trên bucket S3 — không cần cho việc phục vụ website: CORS chỉ cần khi JavaScript từ MỘT origin gọi tài nguyên ở origin KHÁC. Phục vụ trang web thông thường không cần nó.

Ghi nhớ

Bốn điều kiện để trỏ Route 53 tới S3 static website:

① Tên miền đã đăng ký, có hosted zone trong Route 53
② Tên bucket TRÙNG KHỚP tên miền
③ Static website hosting đã bật trên bucket
④ Alias record trỏ tới S3 website endpoint

Alias record và CNAME — bảng phân biệt: | | Alias | CNAME | |---|---|---| | Dùng ở đỉnh tên miền (apex) | ✅ | ❌ chuẩn DNS cấm | | Chi phí truy vấn | MIỄN PHÍ | tính phí | | Trỏ tới | tài nguyên AWS (S3, CloudFront, ALB, API Gateway) | bất kỳ tên miền nào | | Loại bản ghi | A hoặc AAAA | CNAME |

Alias là lựa chọn mặc định khi đích là tài nguyên AWS — miễn phí và dùng được ở apex.

Hai loại endpoint của S3 — dễ nhầm: | Endpoint | Định dạng | Đặc điểm | |---|---|---| | Website endpoint | bucket.s3-website-<region>.amazonaws.com | hỗ trợ index document, error document, redirect; CHỈ HTTP | | REST API endpoint | bucket.s3.<region>.amazonaws.com | hỗ trợ HTTPS, dùng cho API |

Website endpoint KHÔNG hỗ trợ HTTPS — đây là hạn chế quan trọng và là lý do chính để đặt CloudFront phía trước.

Kiến trúc khuyến nghị cho website tĩnh trên AWS:

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

Với kiến trúc này, tên bucket KHÔNG cần trùng tên miền — vì CloudFront xử lý header Host, không phải S3. Đó là một khác biệt đáng nhớ so với đáp án của câu hỏi.

Ba lưu ý khi cấu hình S3 static website: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM cho CloudFront phải ở us-east-1 | dù distribution phục vụ toàn cầu | | Bucket policy cho phép s3:GetObject công khai | hoặc dùng OAC nếu có CloudFront | | Block Public Access phải tắt | nếu phục vụ trực tiếp qua website endpoint |

Dòng cuối là đánh đổi cần cân nhắc: phục vụ trực tiếp từ S3 đòi bucket công khai. Dùng CloudFront + OAC cho phép giữ bucket riêng tư hoàn toàn — an toàn hơn hẳn.

Và một mẹo hữu ích cho chuyển hướng: tạo thêm một bucket tên congty.vn (không có www) với cấu hình redirect requests trỏ về www.congty.vn — cách này gộp mọi truy cập về một tên miền chuẩn mà không cần máy chủ nào.

Đáp án

A và C.

• C — Dùng Amazon SQS để tận dụng cả máy chủ tại chỗ lẫn EC2 instance cho ứng dụng phi kết dính
• A — Dùng Amazon SWF (Simple Workflow Service) cho cùng mục đích

Vì sao đúng

Đề cần kiến trúc phi kết dính (decoupled) hoạt động được với cả tài nguyên trên AWS lẫn máy chủ tại chỗ — và hai dịch vụ này chia sẻ một đặc điểm then chốt.

Cả SQS lẫn SWF đều là dịch vụ dựa trên POLLING qua API công khai:

Máy chủ tại chỗ:
    → gọi HTTPS tới endpoint của SQS/SWF
    → KÉO công việc về xử lý
    → không cần AWS mở kết nối vào mạng của bạn

EC2 instance:
    → làm y hệt
    → hai bên xử lý CÙNG một hàng đợi công việc

Đây là lý do chúng hoạt động trong môi trường lai: worker ở đâu cũng được, miễn là có kết nối Internet ra ngoài và thông tin đăng nhập AWS.

SQS — hàng đợi thông điệp đơn giản: | Đặc điểm | Chi tiết | |---|---| | Tách rời producer và consumer | bên gửi không cần biết bên nhận | | Đệm thông điệp | consumer chết thì công việc vẫn chờ | | Nhiều worker chia nhau xử lý | mở rộng theo độ sâu hàng đợi |

SWF — điều phối quy trình có trạng thái: | Đặc điểm | Chi tiết | |---|---| | Theo dõi trạng thái từng bước | biết task nào đang chạy, xong hay lỗi | | Hỗ trợ worker CON NGƯỜI | bước cần người phê duyệt | | Task chạy dài (tới một năm) | phù hợp quy trình nghiệp vụ phức tạp |

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

• **D. Dùng VPC peering để kết nối máy chủ tại chỗ và EC2 instance — đây là phương án gần nhất về mặt cũng nói tới kết nối, nhưng nó không thực hiện được: VPC peering nối HAI VPC với nhau. Máy chủ tại chỗ không nằm trong VPC nào — muốn kết nối chúng cần Direct Connect hoặc Site-to-Site VPN. Và peering là kết nối mạng, không phải cơ chế phi kết dính.
• **B. Dùng RDS — là cơ sở dữ liệu, không phải cơ chế tách rời: nó lưu trữ dữ liệu, không điều phối công việc giữa các thành phần.
• **E. Dùng DynamoDB — cùng lý do: nó là kho dữ liệu. (Về mặt kỹ thuật, người ta có thể tự dựng hàng đợi trên DynamoDB, nhưng đó là viết lại thứ SQS đã làm sẵn tốt hơn.)

Ghi nhớ

Nguyên tắc nền tảng về kiến trúc phi kết dính:

Các thành phần giao tiếp qua một lớp trung gian, không gọi thẳng nhau. Một thành phần chết không kéo theo cả hệ thống.

Bốn dịch vụ tách rời của AWS: | Dịch vụ | Mô hình | Dùng khi | |---|---|---| | Amazon SQS | hàng đợi, một consumer mỗi thông điệp | tách rời đơn giản, xử lý bất đồng bộ | | Amazon SNS | pub/sub, nhiều người nhận | phát tán một sự kiện tới nhiều đích | | Amazon MQ | broker ActiveMQ/RabbitMQ | di chuyển ứng dụng đã dùng JMS, AMQP | | AWS Step Functions | máy trạng thái, điều phối trực quan | quy trình nhiều bước — thay thế hiện đại cho SWF | | Amazon SWF | quy trình có trạng thái, worker con người | ứng dụng cũ |

Step Functions là lựa chọn được khuyến nghị cho thiết kế mới — SWF vẫn hoạt động nhưng AWS không phát triển thêm. Với đề thi, cả hai vẫn là đáp án hợp lệ.

Ba đặc điểm khiến SQS phù hợp cho môi trường lai: | Đặc điểm | Chi tiết | |---|---| | Endpoint HTTPS công khai | máy chủ ở đâu cũng gọi được | | Mô hình KÉO (polling) | không cần mở cổng vào mạng tại chỗ | | Xác thực bằng IAM | dùng access key hoặc IAM Roles Anywhere |

Dòng giữa là lợi ích bảo mật quan trọng: hệ thống tại chỗ chỉ mở kết nối ra ngoài, không phải mở cổng cho AWS gọi vào — nên không cần thay đổi tường lửa biên.

IAM Roles Anywhere đáng biết cho môi trường lai: nó cho phép máy chủ tại chỗ nhận thông tin đăng nhập AWS tạm thời bằng chứng chỉ X.509 — thay vì lưu access key dài hạn trên máy.

Ba cấu hình quan trọng của SQS: | Cấu hình | Việc | |---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn khi đang xử lý — đặt DÀI HƠN thời gian xử lý | | Long polling | tới 20 giây — giảm lời gọi API rỗng và chi phí | | Dead-letter queue | thông điệp lỗi sau N lần thử |

Long polling đặc biệt đáng bật cho worker tại chỗ: nó giảm mạnh số lời gọi API qua Internet, tiết kiệm cả chi phí lẫn băng thông.

Ba lợi ích của kiến trúc phi kết dính: | Lợi ích | Chi tiết | |---|---| | Chịu lỗi | thành phần chết không lan sang cái khác | | Mở rộng độc lập | mỗi tầng co giãn theo tải riêng | | Hấp thụ đột biến | hàng đợi làm bộ đệm |

Và một mẫu kiến trúc đáng cân nhắc cho tình huống di chuyển dần lên cloud: dùng SQS làm cầu nối trong giai đoạn chuyển tiếp — worker tại chỗ và worker trên EC2 cùng đọc một hàng đợi, và bạn dịch chuyển tỷ lệ xử lý sang AWS bằng cách tăng dần số worker trên cloud, không cần thay đổi gì ở phía producer.

Đáp án

A — Dùng Amazon Rekognition để phát hiện ảnh có nội dung khiêu dâm hoặc bạo lực trong S3. Tạo một Interface VPC endpoint cho Rekognition với policy phù hợp để ngăn lưu lượng đi qua Internet công cộng.

Vì sao đúng

Đề nêu ba yêu cầu, và A đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Dùng AI để gắn cờ ảnh cần kiểm duyệt | Rekognition Content Moderation | | Ít công nhất | API dựng sẵn — không cần huấn luyện mô hình | | Lưu lượng không đi qua Internet công cộng | Interface VPC endpoint |

Rekognition có sẵn API kiểm duyệt nội dung:

kq = rekognition.detect_moderation_labels(
    Image={'S3Object': {'Bucket': 'anh-nguoi-dung', 'Name': 'anh123.jpg'}},
    MinConfidence=80)

for nhan in kq['ModerationLabels']:
    print(nhan['Name'], nhan['Confidence'])
    # Explicit Nudity, Violence, Visually Disturbing, Drugs...

Vì sao đây là "LEAST amount of effort":

Rekognition:
    → gọi MỘT API, nhận về nhãn kiểm duyệt kèm độ tin cậy
    → không huấn luyện, không gán nhãn dữ liệu, không vận hành mô hình

SageMaker (phương án B):
    → phải thu thập và gán nhãn hàng nghìn ảnh
    → huấn luyện, đánh giá, triển khai endpoint
    → tự lo mở rộng và giám sát

Và vế "chỉ gắn cờ để người xem xét" khớp với cách dùng đúng của Rekognition: nó trả về độ tin cậy, nên bạn đặt ngưỡng để quyết định ảnh nào cần người kiểm tra — chứ không tự động xoá.

Interface endpoint cho vế riêng tư:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.rekognition   --vpc-endpoint-type Interface   --subnet-ids subnet-0aaa subnet-0bbb   --security-group-ids sg-0ccc --private-dns-enabled

Rekognition dùng Interface endpoint — chỉ S3 và DynamoDB dùng Gateway endpoint.

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

• **B. Dùng mô hình phân loại ảnh trong SageMaker; thiết lập GuardDuty kết nối với SageMaker để đảm bảo lưu lượng không qua Internet — đây là phương án gần nhất về mặt cũng dùng AI, nhưng nó nhiều công hơn hẳn (phải tự huấn luyện mô hình) và GuardDuty không kiểm soát đường đi của lưu lượng — nó là dịch vụ phát hiện mối đe doạ.
• **C. Dùng Amazon Detective để phát hiện ảnh khiêu dâm hoặc bạo lực; dùng Audit Manager đảm bảo lưu lượng không qua Internet — nhầm cả hai dịch vụ: Detective điều tra sự cố bảo mật từ log, nó không xem ảnh; Audit Manager thu thập bằng chứng tuân thủ, không kiểm soát mạng.
• **D. Dùng Amazon Monitron giám sát mỗi lượt tải lên; dùng Transit Gateway Network Manager chặn request ra Internet — Monitron giám sát TÌNH TRẠNG MÁY MÓC CÔNG NGHIỆP qua cảm biến rung và nhiệt độ. Hoàn toàn không liên quan tới ảnh.

Ghi nhớ

Các dịch vụ AI dựng sẵn của AWS — bảng nhận diện: | Dịch vụ | Việc | |---|---| | Rekognition | phân tích ẢNH và VIDEO — nhận diện vật thể, khuôn mặt, kiểm duyệt nội dung | | Comprehend | xử lý ngôn ngữ tự nhiên — cảm xúc, thực thể, PII trong văn bản | | Transcribe / Polly | giọng nói → văn bản / văn bản → giọng nói | | Translate | dịch ngôn ngữ | | Textract | trích xuất văn bản và bảng từ tài liệu quét | | Fraud Detector | phát hiện gian lận giao dịch | | Personalize | gợi ý cá nhân hoá |

Quy tắc chọn:

Có API dựng sẵn cho bài toán của bạn → dùng nó (ít công nhất) Bài toán đặc thù, không có API sẵn → SageMaker

Các nhãn kiểm duyệt của Rekognition:

Explicit Nudity, Suggestive, Violence,
Visually Disturbing, Rude Gestures, Drugs,
Tobacco, Alcohol, Gambling, Hate Symbols

Mỗi nhãn có nhãn cha và nhãn con — bạn lọc theo mức chi tiết phù hợp với chính sách của mình.

Hai loại VPC endpoint — nhắc lại vì hay bị nhầm: | Loại | Dịch vụ | Chi phí | |---|---|---| | Gateway | CHỈ S3 và DynamoDB | MIỄN PHÍ | | Interface | hầu hết dịch vụ khác, gồm Rekognition | theo giờ + GB |

Ba điều kiện để Interface endpoint hoạt động:

① Security group của endpoint cho phép HTTPS (443) từ nguồn
② enableDnsSupport và enableDnsHostnames bật trên VPC
③ Bật private DNS để tên miền dịch vụ tự phân giải về endpoint

Thiếu điều kiện ① là lỗi phổ biến nhất — endpoint tạo thành công, hiện available, nhưng mọi lời gọi đều timeout.

Endpoint policy để siết chặt thêm:

{"Effect": "Allow", "Principal": "*",
 "Action": ["rekognition:DetectModerationLabels"],
 "Resource": "*"}

Nó đảm bảo qua endpoint này chỉ gọi được API kiểm duyệt, không phải mọi API của Rekognition.

Ba lưu ý khi triển khai kiểm duyệt nội dung: | Lưu ý | Chi tiết | |---|---| | Đặt ngưỡng độ tin cậy phù hợp | quá thấp gây nhiều báo động giả, quá cao bỏ sót | | Luôn giữ người trong vòng lặp | AI gắn cờ, người quyết định | | Lưu lại quyết định để cải thiện | dữ liệu phản hồi cho việc hiệu chỉnh ngưỡng |

Và một kiến trúc gọn cho tình huống này: S3 event notification → Lambda → Rekognition → ghi kết quả vào DynamoDB. Ảnh vượt ngưỡng được đưa vào hàng đợi chờ người kiểm duyệt, phần còn lại đi thẳng — tự động hoá phần lớn công việc mà vẫn giữ quyền quyết định cuối cùng cho con người.

Đáp án

D và E.

• D — Trên tài khoản chính, dùng AWS Organizations tạo một organization mới với đầy đủ tính năng. Mời các tài khoản con gia nhập
• E — Cấu hình AWS IAM Identity Center cho tổ chức và tích hợp với dịch vụ thư mục của công ty bằng Active Directory Connector

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ế | |---|---| | Hợp nhất nhiều tài khoản thành cấu trúc đa tài khoản | D — AWS Organizations | | Đơn giản hoá đăng nhập bằng thư mục có sẵn | E — IAM Identity Center + AD Connector |

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

Tạo organization ở tài khoản quản lý
    ↓ MỜI các tài khoản đã có gia nhập
    → thanh toán hợp nhất
    → áp SCP làm rào chắn
    → điều kiện tiên quyết cho IAM Identity Center

"All features" là chế độ đúng — chế độ chỉ có thanh toán hợp nhất không cho dùng SCP.

Và "invite the child accounts" là chi tiết đúng: các tài khoản đã tồn tại từ trước, nên phải mời chúng gia nhập chứ không tạo mới.

E — AD Connector là cầu nối tới thư mục có sẵn:

Người dùng đăng nhập portal của IAM Identity Center
    ↓ AD Connector CHUYỂN TIẾP xác thực về AD của công ty
    ↓ AD trả kết quả
IAM Identity Center cấp quyền theo permission set
    → truy cập nhiều tài khoản AWS từ một cổng duy nhất

Ba lợi ích của AD Connector: | Lợi ích | Chi tiết | |---|---| | Không sao chép dữ liệu thư mục | mọi truy vấn chuyển tiếp về AD gốc | | Không lưu mật khẩu | quan trọng cho tuân thủ | | Nghỉ việc là mất quyền ngay | vô hiệu hoá tài khoản AD là xong |

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

• **C. Tạo SCP để quản lý các tài khoản con; cấu hình IAM Identity Center dùng AWS Directory Service — đây là phương án gần nhất và cả hai vế đều hợp lý, nhưng nó bỏ qua bước tạo organization và mời tài khoản. SCP chỉ tồn tại khi đã có organization — nó là hệ quả, không phải bước đầu tiên.
• **A. Dùng Organizations tạo organization mới; bật external authentication của organization và trỏ tới dịch vụ thư mục — mô tả một tính năng không tồn tại: AWS Organizations không có "external authentication". Xác thực là việc của IAM Identity Center hoặc IAM federation.
• **B. Tạo identity pool trên Amazon Cognito dùng dịch vụ thư mục; cấu hình IAM Identity Center chấp nhận xác thực Cognito — nhầm mục đích của Cognito: nó dành cho người dùng ứng dụng web và di động, không phải nhân viên truy cập AWS Console. Và IAM Identity Center không nhận Cognito làm nguồn danh tính.

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 |

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 ← câu này | | Nhà cung cấp SAML bên ngoài | Okta, Azure AD, Ping | | — | |

Ba lựa chọn của AWS Directory Service: | Dịch vụ | Là gì | |---|---| | AD Connector | PROXY tới AD tại chỗ — không lưu gì ← câu này | | AWS Managed Microsoft AD | AD THẬT do AWS vận hành | | Simple AD | thư mục độc lập tương thích Samba |

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

"Đã có AD, muốn dùng lại, không sao chép dữ liệu" → AD Connector "Cần AD đầy đủ trên cloud, hoặc ứng dụng cần LDAP/Kerberos" → Managed Microsoft AD

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

Permission set là điều làm IAM Identity Center mạnh hơn IAM truyền thống: định nghĩa quyền một lần rồi gán cho nhiều tài khoản — thay vì tạo role giống hệt nhau ở từng tài khoản.

Ba lợi ích của mô hình này so với IAM user: | 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 | | Một danh tính, nhiều tài khoản | không phải nhớ nhiều bộ đăng nhập | | Quản lý tập trung | thêm hay bớt quyền ở một chỗ |

Và một điểm quan trọng về vòng đời: khi nhân viên rời công ty, vô hiệu hoá tài khoản AD là mất quyền ngay lập tức trên MỌI tài khoản AWS — với IAM user, bạn phải nhớ xoá thủ công ở từng tài khoản, và đó là chỗ hay bị bỏ sót.

(Câu #8219 trong cùng lô này hỏi gần như cùng một tình huống với bộ phương án khác — xem thêm ở đó.)

Đáp án

C — Dùng Route 53 với tuỳ chọn failover trỏ tới một S3 website bucket tĩnh hoặc CloudFront distribution.

Vì sao đúng

Đề mô tả một tình huống cụ thể: ứng dụng động có thể quá tải trong vài tuần đầu, và cần chuyển sang trang tĩnh khi hỏng.

Đây là mẫu "static fallback" — một chiến lược suy giảm có kiểm soát:

Bình thường:  Route 53 → ứng dụng MEAN stack (bản ghi PRIMARY)

Ứng dụng quá tải, health check thất bại:
              Route 53 → S3 static website (bản ghi SECONDARY)
              → người dùng thấy trang thông báo thay vì lỗi 503
              → chi phí gần bằng không, không thể quá tải

Vì sao trang tĩnh là lựa chọn dự phòng tốt: | Đặc điểm | Chi tiết | |---|---| | Không thể quá tải | S3 tự mở rộng gần như vô hạn | | Chi phí cực thấp | trả theo request, không có máy chạy | | Sẵn sàng ngay | không cần khởi động gì | | Giữ được thương hiệu | thông báo có kiểm soát thay vì trang lỗi trắng |

Cấu hình:

Bản ghi PRIMARY:   alias → ALB của ứng dụng   + health check
Bản ghi SECONDARY: alias → S3 website endpoint hoặc CloudFront

Và Route 53 health check tự động phát hiện sự cố — không cần người can thiệp:

Health check gọi endpoint mỗi 30 giây từ nhiều vị trí toàn cầu
    → thất bại 3 lần liên tiếp
    → Route 53 ngừng trả về bản ghi primary
    → truy vấn DNS trả về địa chỉ của trang tĩnh

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

• **A. Nhân bản kiến trúc ứng dụng ở Region khác và cấu hình DNS weight-based routing — đây là phương án gần nhất và cho tính sẵn sàng cao hơn, nhưng nó sai ở hai điểm: weighted routing chia lưu lượng LIÊN TỤC cho cả hai — không phải cơ chế dự phòng; và nhân đôi toàn bộ hạ tầng rất tốn kém cho một startup sắp ra mắt.
• **B. Bật failover sang ứng dụng chạy trong trung tâm dữ liệu tại chỗ — không phù hợp với ngữ cảnh: đề nói về một ứng dụng web sắp ra mắt trên cloud, không đề cập hạ tầng tại chỗ nào. Và duy trì một bản sao tại chỗ còn tốn kém hơn nữa.
• **D. Thêm máy chủ phòng khi ứng dụng hỏng — không phải cơ chế failover: thêm dung lượng giúp chịu tải cao hơn, nhưng không có gì tự động chuyển hướng khi sự cố xảy ra. Và nó không trả lời câu hỏi về DNS failover.

Ghi nhớ

Các chính sách định tuyến của Route 53: | Chính sách | Định tuyến theo | |---|---| | Simple | một bản ghi | | Failover | primary khi khoẻ, secondary khi hỏng ← câu này | | Weighted | tỷ lệ phần trăm — A/B testing, triển khai dần | | Latency | Region cho độ trễ thấp nhất | | Geolocation | vị trí địa lý của người dùng | | Multivalue answer | trả nhiều IP có health check |

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

"chỉ khi primary hỏng", "disaster recovery", "fallback" → Failover "chia tỷ lệ", "canary", "A/B testing" → Weighted

Ba loại health check của Route 53: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới một địa chỉ | | Calculated | kết hợp kết quả nhiều health check | | CloudWatch alarm | theo trạng thái alarm — dùng cho endpoint RIÊNG TƯ |

Loại thứ ba giải quyết một hạn chế quan trọng: health check của Route 53 đến từ Internet công cộng, nên không kiểm tra được tài nguyên trong private subnet.

Bốn chiến lược khôi phục — đề này ở mức thấp nhất mà vẫn hữu ích: | Chiến lược | RTO | Chi phí | |---|---|---| | Static fallback | phút (theo TTL DNS) | rất thấp ← câu này | | Pilot Light | chục phút | thấp | | Warm Standby | phút | vừa | | Multi-Site Active/Active | gần 0 | cao nhất |

Static fallback không phải "khôi phục" đúng nghĩa — ứng dụng vẫn hỏng. Nhưng nó biến một trang lỗi thành một thông báo có kiểm soát, và với startup thì đó là đánh đổi hợp lý.

Ba lưu ý khi triển khai failover: | Lưu ý | Chi tiết | |---|---| | Đặt TTL THẤP (60 giây hoặc ít hơn) | TTL cao kéo dài thời gian gián đoạn thực tế | | Bật EvaluateTargetHealth cho alias record | Route 53 tự kiểm tra sức khoẻ của ALB | | Kiểm thử failover định kỳ | tắt health check thủ công để diễn tập |

Dòng đầu quan trọng hơn vẻ ngoài: Route 53 chuyển đổi trong vài chục giây, nhưng trình phân giải DNS của người dùng vẫn cache địa chỉ cũ tới hết TTL. TTL 300 giây nghĩa là một số người dùng còn thấy lỗi thêm năm phút nữa.

Và một cải thiện đáng cân nhắc cho trang tĩnh dự phòng: đặt CloudFront phía trước S3 thay vì trỏ thẳng vào website endpoint. Nó cho HTTPS (S3 website endpoint chỉ hỗ trợ HTTP), cache ở biên, và bạn dùng chung một distribution cho cả hai trạng thái nếu cấu hình origin group — khi đó CloudFront tự chuyển sang origin dự phòng mà không cần chờ TTL của DNS.

Đáp án

B — AWS Snowball Edge.

Vì sao đúng

Đề cho hai dữ kiện, và chúng quyết định câu trả lời:

Dữ liệu: 80 TB
Thời gian nếu truyền qua mạng: 2 THÁNG

Hai tháng là quá lâu — và trong suốt thời gian đó băng thông của công ty bị chiếm dụng, ảnh hưởng tới mọi hoạt động khác.

Snowball Edge giải quyết bằng vận chuyển vật lý:

① AWS gửi thiết bị tới trung tâm dữ liệu của bạn      (vài ngày)
② Bạn sao chép 80 TB qua mạng NỘI BỘ 10 GbE           (khoảng 1 ngày)
③ Gửi thiết bị về AWS                                 (vài ngày)
④ AWS nạp dữ liệu vào S3                              (1 ngày)
    → tổng: khoảng MỘT TUẦN thay vì hai tháng

Và dung lượng khớp gần như hoàn hảo: | Thiết bị | Dung lượng khả dụng | |---|---| | Snowball Edge Storage Optimized | ~80 TB | | Snowball Edge Compute Optimized | ~28 TB | | Snowcone | 8 TB |

80 TB vừa đúng một thiết bị Storage Optimized — không cần chia nhiều thiết bị như trường hợp 250 TB.

Quy tắc ước lượng đáng nhớ:

Truyền qua mạng mất hơn MỘT TUẦN → cân nhắc Snow Family.

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

• **A. AWS Snowmobile — đây là phương án gần nhất về mặt cũng là vận chuyển vật lý, nhưng nó hoàn toàn không tương xứng: Snowmobile là xe container dài 45 foot chở tới 100 PB. Dùng nó cho 80 TB là lãng phí lớn về cả chi phí lẫn công tổ chức.
• **C. AWS Direct Connect — quá chậm để thiết lập và không tiết kiệm: lắp đặt Direct Connect mất vài tuần tới vài tháng — không nhanh hơn việc truyền qua đường hiện có. Và đầu tư một kết nối riêng chỉ cho một đợt chuyển dữ liệu là không hợp lý.
• **D. Amazon S3 Multipart Upload — là kỹ thuật tối ưu, không phải giải pháp: multipart upload chia tệp thành nhiều phần tải song song, giúp tận dụng hết băng thông sẵn có. Nhưng nó không tạo ra băng thông mới — nếu đường truyền là nút thắt thì hai tháng vẫn là hai tháng.

Ghi nhớ

Bảng quyết định theo quy mô dữ liệu: | Dữ liệu | Băng thông | Nên dùng | |---|---|---| | Vài GB tới vài TB | tốt | tải trực tiếp hoặc Transfer Acceleration | | Chục tới trăm TB | hạn chế | Snowball Edge ← câu này | | PB trở lên | bất kỳ | Snowmobile hoặc nhiều Snowball | | Đồng bộ LIÊN TỤC | có kết nối | DataSync hoặc Storage Gateway |

Công thức tính thời gian truyền:

Số ngày = (Dung lượng GB × 8) / (Băng thông Mbps × 0,0864)

80 TB qua 100 Mbps  → ~74 ngày   → Snowball
80 TB qua 1 Gbps    → ~7,4 ngày  → ranh giới, tuỳ tình huống
80 TB qua 10 Gbps   → ~18 giờ    → tải trực tiếp

Các thiết bị Snow Family: | Thiết bị | Dung lượng | Đặc điểm | |---|---|---| | Snowcone | 8–14 TB | nhỏ gọn, chạy pin, môi trường khắc nghiệt | | Snowball Edge Storage Optimized | ~80 TB | di chuyển dữ liệu quy mô TB | | Snowball Edge Compute Optimized | ~28 TB + GPU | xử lý tại chỗ, học máy ở biên | | Snowmobile | tới 100 PB | quy mô exabyte |

(AWS đã điều chỉnh danh mục Snow Family theo thời gian — kiểm tra tài liệu hiện hành khi triển khai thật.)

Ba đặc điểm bảo mật của Snowball: | Đặc điểm | Chi tiết | |---|---| | Mã hoá AES-256 bằng KMS key của BẠN | AWS không có khoá | | Vỏ chống giả mạo, có TPM | phát hiện can thiệp vật lý | | Xoá sạch theo chuẩn NIST 800-88 | sau khi nạp dữ liệu xong |

Thiết bị thất lạc trên đường vận chuyển vẫn an toàn — dữ liệu mã hoá bằng khoá mà chỉ bạn kiểm soát.

Ba lưu ý khi lập kế hoạch: | Lưu ý | Chi tiết | |---|---| | Thời gian vận chuyển hai chiều | vài ngày mỗi chiều | | Tốc độ sao chép cục bộ | dùng nhiều luồng song song, cổng 10 GbE | | Dữ liệu thay đổi trong lúc chuyển | cần đồng bộ phần chênh lệch sau đó |

Dòng cuối là bước hay bị quên: sau khi Snowball nạp xong, dữ liệu tại chỗ đã thay đổi trong một tuần. Dùng AWS DataSync đồng bộ phần chênh lệch — nó chỉ chuyển những gì khác biệt.

Ba khả năng bổ sung của Snowball Edge: | Khả năng | Chi tiết | |---|---| | Chạy EC2 instance ngay trên thiết bị | xử lý tại chỗ trước khi gửi | | Chạy Lambda function | biến đổi dữ liệu khi ghi vào | | Dùng làm lưu trữ tạm ở nơi không có mạng | tàu biển, giàn khoan, vùng xa |

Đây là lý do tên gọi là "Edge" — nó không chỉ là ổ cứng vận chuyển, mà là một nút tính toán ở biên.

Và một lưu ý về đích đến: đề nói chuyển kho dữ liệu (data warehouse) 80 TB. Sau khi dữ liệu vào S3, bước tiếp theo thường là nạp vào Redshift hoặc truy vấn trực tiếp bằng Athena. Nếu chọn Athena, hãy chuyển dữ liệu sang định dạng Parquet có phân vùng — nó giảm 30–90% lượng dữ liệu quét và do đó giảm chi phí truy vấn tương ứng.

Đáp án

B — Dùng AWS Security Token Service (STS).

Vì sao đúng

Đề nêu ba yêu cầu, và STS là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cơ chế | |---|---| | Cấp token truy cập NGẮN HẠN | STS cấp thông tin đăng nhập tạm thời | | Truy cập tài khoản KHÁC (production) | AssumeRole chéo tài khoản | | Chỉ quyền GHI vào EC2 và S3 | permission policy của role |

Cách hoạt động của assume role chéo tài khoản:

Tài khoản PRODUCTION tạo một IAM role
    ↓ trust policy: cho phép tài khoản DEVELOPMENT assume
    ↓ permission policy: chỉ EC2 và S3, chỉ thao tác ghi

Lập trình viên ở tài khoản development
    ↓ gọi sts:AssumeRole
STS trả về: AccessKeyId, SecretAccessKey, SessionToken
    ↓ HẾT HẠN sau 15 phút tới 12 giờ
Truy cập tài nguyên production trong thời hạn đó

Trust policy ở tài khoản production:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/lap-trinh-vien"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "Bool": {"aws:MultiFactorAuthPresent": "true"},
    "DateLessThan": {"aws:CurrentTime": "2026-12-31T23:59:59Z"}
  }
}

Hai điều kiện trong ví dụ trên đáng chú ý cho tình huống của đề: bắt buộc MFA, và giới hạn thời gian cho quyền tạm thời — khớp với việc quyền truy cập chỉ có hiệu lực trong một giai đoạn.

Và "short-lived access tokens" trong đề chính là mô tả của STS — không dịch vụ nào khác trong các phương án làm việc này cho tài nguyên AWS.

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

• **A. Dùng Amazon Cognito để cấp JSON Web Token (JWT) — đây là phương án gần nhất về mặt cũng cấp token, nhưng nó nhắm vào đối tượng khác: Cognito dành cho người dùng ứng dụng web và di động, không phải lập trình viên truy cập tài nguyên AWS. (Cognito Identity Pool có đổi được token lấy thông tin đăng nhập AWS — nhưng nó vẫn gọi STS bên dưới, và dựng cả một user pool cho một lập trình viên là quá mức.)
• **C. Dùng AWS SSO (nay là IAM Identity Center) — là giải pháp tốt cho tổ chức, nhưng nó không phải câu trả lời cho câu hỏi được đặt ra: đề hỏi dịch vụ nào CẤP token ngắn hạn. IAM Identity Center là lớp quản lý phía trên và vẫn dùng STS bên dưới để cấp thông tin đăng nhập.
• **D. Tất cả các phương án đều đúng — sai vì A và C không trả lời đúng câu hỏi về cơ chế cấp token.

Ghi nhớ

Các API chính của AWS STS: | API | Dùng cho | |---|---| | AssumeRole | chéo tài khoản, hoặc nâng quyền tạm thời ← câu này | | AssumeRoleWithSAML | federation doanh nghiệp (AD FS, Okta) | | AssumeRoleWithWebIdentity | Google, Facebook, OIDC, Cognito | | GetSessionToken | thêm MFA cho IAM user | | GetFederationToken | identity broker tự viết |

Ba thành phần của một IAM role: | Thành phần | Việc | |---|---| | Trust policy | AI được phép assume role này | | Permission policy | role này LÀM ĐƯỢC GÌ | | Session duration | thời hạn tối đa của phiên |

Nhầm hai policy đầu là lỗi phổ biến: trust policy nói về danh tính, permission policy nói về quyền.

Thời hạn của thông tin đăng nhập tạm thời: | Nguồn | Thời hạn | |---|---| | AssumeRole | 15 phút – 12 giờ (mặc định 1 giờ) | | EC2 instance profile | tự làm mới liên tục | | GetSessionToken | 15 phút – 36 giờ |

MaxSessionDuration của role đặt trần cho thời hạn — không xin dài hơn được.

Ba lợi ích của thông tin đăng nhập tạm thời: | Lợi ích | Chi tiết | |---|---| | Tự hết hạn | không cần xoay vòng thủ công | | Không lưu ở đâu cả | không có bí mật dài hạn để rò rỉ | | Thu hồi được | chính sách theo aws:TokenIssueTime |

Cách thu hồi mọi phiên đang hoạt động — hữu ích khi có sự cố:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-08-30T12:00:00Z"}}}

Ba điều kiện đáng thêm vào trust policy cho quyền tạm thời: | Điều kiện | Việc | |---|---| | aws:MultiFactorAuthPresent | bắt buộc MFA | | aws:CurrentTime | giới hạn khoảng thời gian quyền có hiệu lực | | sts:ExternalId | chống confused deputy — bắt buộc với bên thứ ba |

ExternalId là thực hành bắt buộc khi cấp quyền cho tổ chức bên ngoài — nó ngăn một khách hàng khác của cùng nhà cung cấp lừa họ truy cập vào tài khoản của bạn.

Và với yêu cầu "chỉ ghi vào EC2 và S3" của đề: hãy viết permission policy liệt kê hành động cụ thể thay vì dùng ký tự đại diện. s3:PutObject khác hẳn s3:Put* — cái sau vô tình cho phép PutBucketPolicy và PutObjectAcl, tức là đổi được cả quyền truy cập.

Đáp án

D — Dùng Amazon Data Lifecycle Manager (DLM) để tự động hoá việc tạo EBS snapshot.

Vì sao đúng

Đề cần giải pháp nhanh nhất và tiết kiệm nhất để tự động sao lưu mọi EBS volume — và DLM là tính năng dựng sẵn cho đúng việc đó.

DLM là dịch vụ được quản lý, không cần viết mã:

aws dlm create-lifecycle-policy   --description "Sao luu EBS hang ngay"   --state ENABLED   --execution-role-arn arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRole   --policy-details '{
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "SaoLuu", "Value": "hang-ngay"}],
    "Schedules": [{
      "Name": "HangNgay",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"]},
      "RetainRule": {"Count": 7},
      "CopyTags": true
    }]}'

Bốn lợi ích so với việc tự viết script: | Lợi ích | Chi tiết | |---|---| | Không cần mã, không cần máy chủ | không có gì để bảo trì | | Nhắm mục tiêu theo TAG | volume mới gắn tag là tự động được sao lưu | | Tự XOÁ snapshot cũ | không tích tụ chi phí lưu trữ | | Miễn phí | chỉ trả phí lưu trữ snapshot |

Dòng thứ hai là điểm mạnh vận hành lớn nhất: gắn tag SaoLuu=hang-ngay cho volume mới là xong — không phải cập nhật danh sách ở đâu cả.

Dòng thứ ba là điều mà script tự viết hay bỏ sót: tạo snapshot thì dễ, nhưng quên dọn snapshot cũ khiến chi phí tăng đều đặn và không ai để ý cho tới khi nhìn hoá đơn.

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

• **A. Tạo scheduled job gọi lệnh create-snapshot qua AWS CLI định kỳ — đây là phương án gần nhất và hoạt động được, nhưng nó nhiều công hơn hẳn: phải có máy chạy cron, viết script, xử lý lỗi, quản lý thông tin đăng nhập, và tự viết logic dọn snapshot cũ. Trái yêu cầu "fastest and most cost-effective".
• **B. Dùng Storage Gateway với EBS volume làm nguồn và lưu bản sao lưu ở máy chủ tại chỗ — sai kiến trúc: Storage Gateway kết nối hạ tầng tại chỗ với AWS, không sao lưu EBS về tại chỗ. Và gửi bản sao lưu ra khỏi AWS làm tăng chi phí truyền dữ liệu lẫn độ phức tạp.
• **C. Dùng "EBS-cycle policy" trong Amazon S3 để tự động sao lưu EBS volume — mô tả một tính năng không tồn tại: không có khái niệm "EBS-cycle policy". S3 lifecycle policy chỉ áp cho object trong bucket của bạn, và EBS snapshot không nằm trong bucket nào của bạn.

Ghi nhớ

Ba cách sao lưu EBS — theo công sức: | Cách | Đặc điểm | |---|---| | Data Lifecycle Manager (DLM) | MIỄN PHÍ, không cần mã, nhắm theo tag ← câu này | | AWS Backup | quản lý tập trung NHIỀU dịch vụ, có vault lock, chéo tài khoản | | Script tự viết | linh hoạt nhất, nhiều công nhất |

AWS Backup là lựa chọn mạnh hơn cho môi trường lớn: | Khả năng | DLM | AWS Backup | |---|---|---| | EBS snapshot | ✅ | ✅ | | Nhiều dịch vụ (RDS, EFS, DynamoDB, FSx) | ❌ | ✅ | | Sao lưu chéo tài khoản | ❌ | ✅ | | Backup Vault Lock (WORM) | ❌ | ✅ | | Chi phí | miễn phí | tính phí quản lý |

Với yêu cầu "chỉ EBS, nhanh nhất, rẻ nhất" của đề, DLM là câu trả lời đúng — nhưng nếu tổ chức cần sao lưu nhiều loại tài nguyên hoặc cần cách ly tài khoản, AWS Backup xứng đáng với khoản phí thêm.

Bốn tính năng của DLM: | Tính năng | Chi tiết | |---|---| | Lịch tạo snapshot | mỗi 1, 2, 3, 4, 6, 8, 12 hoặc 24 giờ | | Quy tắc giữ | theo số lượng hoặc theo số ngày | | Sao chép chéo Region | cho khôi phục thảm hoạ | | Fast Snapshot Restore | khôi phục nhanh, không cần "làm nóng" |

Ba đặc điểm của EBS snapshot: | Đặc điểm | Chi tiết | |---|---| | Tăng dần (incremental) | chỉ lưu khối THAY ĐỔI so với snapshot trước | | Lưu trong S3 do AWS quản lý | không nằm trong bucket của bạn | | Phạm vi REGION | sao chép sang Region khác được |

Tính tăng dần khiến snapshot rẻ hơn nhiều so với tưởng tượng: snapshot hằng ngày của một volume 500 GB ít thay đổi chỉ tốn thêm vài GB mỗi ngày.

Nhưng xoá snapshot không giải phóng dung lượng như bạn nghĩ: vì các snapshot chia sẻ khối dữ liệu, xoá một cái ở giữa chuỗi chỉ giải phóng những khối không còn snapshot nào tham chiếu tới.

Ba lưu ý về tính nhất quán của snapshot: | Lưu ý | Chi tiết | |---|---| | Snapshot là crash-consistent theo mặc định | như rút điện đột ngột | | Với cơ sở dữ liệu, nên flush và freeze trước | hoặc dùng snapshot của chính RDS | | Nhiều volume trong một instance | dùng multi-volume snapshot để nhất quán giữa các volume |

Dòng cuối là tính năng đáng biết: create-snapshots (số nhiều) chụp mọi volume của một instance tại cùng một thời điểm — cần thiết khi dữ liệu trải trên nhiều volume.

Và một thực hành nên theo: gắn tag cho snapshot (CopyTags: true trong DLM làm việc này) để biết snapshot thuộc volume nào, ứng dụng nào, môi trường nào — khi cần khôi phục gấp, việc tìm đúng snapshot trong hàng nghìn cái là vấn đề thật.

Đáp án

C và D.

• C — Cooldown đảm bảo Auto Scaling group KHÔNG khởi chạy hoặc chấm dứt thêm instance TRƯỚC KHI hoạt động mở rộng trước đó có hiệu lực
• D — Giá trị mặc định là 300 giây

Vì sao đúng

Đề hỏi về cooldown period — cơ chế ngăn Auto Scaling phản ứng thái quá.

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

KHÔNG có cooldown:
    10:00:00  CPU = 90% → ASG thêm 2 instance
    10:00:30  instance mới CHƯA khởi động xong, CPU vẫn 90%
              → ASG thêm 2 instance NỮA
    10:01:00  vẫn chưa xong → thêm 2 nữa
              → mở rộng quá mức, tốn tiền vô ích

CÓ cooldown 300 giây:
    10:00:00  CPU = 90% → thêm 2 instance
    10:00:00–10:05:00  ASG BỎ QUA mọi tín hiệu mở rộng
              → instance mới có thời gian khởi động và nhận tải
    10:05:00  đánh giá lại tình hình THẬT

Cooldown là "thời gian chờ để nhìn thấy kết quả" — không phải thời gian để instance "hạ nhiệt" như tên gọi có thể gợi ý.

Và 300 giây (5 phút) là giá trị mặc định — con số cần thuộc.

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --default-cooldown 300

Cooldown áp cho cả mở rộng lẫn thu hẹp — đó là lý do phát biểu C nói "launch OR terminate".

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

• **A. Cooldown đảm bảo trước khi ASG mở rộng, các EC2 instance có đủ thời gian "hạ nhiệt" — đây là phương án gần nhất và hiểu sai tên gọi: cooldown không liên quan gì tới nhiệt độ hay trạng thái của instance. Nó là thời gian ASG tạm dừng ra quyết định để hoạt động trước phát huy tác dụng.
• **E. Giá trị mặc định là 600 giây — sai con số: mặc định là 300 giây.
• **B. Cooldown đảm bảo ASG khởi chạy hoặc chấm dứt instance mà không có thời gian ngừng — nhầm với cơ chế khác: việc không gián đoạn dịch vụ là nhờ connection draining (deregistration delay) của load balancer và lifecycle hook, không phải cooldown.

Ghi nhớ

Bốn cơ chế điều tiết của Auto Scaling — hay bị nhầm với nhau: | Cơ chế | Việc | |---|---| | Cooldown period | tạm dừng ra quyết định sau một hoạt động mở rộng (mặc định 300 giây) | | Health check grace period | chờ trước khi bắt đầu kiểm tra sức khoẻ instance MỚI (mặc định 300 giây) | | Instance warmup | thời gian instance mới được coi là chưa sẵn sàng đóng góp metric | | Lifecycle hook | tạm dừng vòng đời để chạy tác vụ tuỳ chỉnh |

Cooldown và health check grace period đều mặc định 300 giây nhưng phục vụ mục đích khác nhau — đây là chỗ dễ lẫn.

Lưu ý quan trọng về target tracking:

Simple scaling  → dùng COOLDOWN
Target tracking → dùng INSTANCE WARMUP (không dùng cooldown)
Step scaling    → dùng INSTANCE WARMUP

AWS khuyến nghị target tracking thay cho simple scaling — và với nó, DefaultInstanceWarmup là tham số cần quan tâm thay vì cooldown.

Ba loại chính sách mở rộng động: | Loại | Cách hoạt động | |---|---| | Target tracking | giữ một metric ở giá trị mục tiêu — AWS khuyến nghị | | Step scaling | các bước khác nhau theo mức độ vi phạm | | Simple scaling | một hành động cố định + cooldown — cơ chế cũ |

Vì sao target tracking tốt hơn: | | Target tracking | Simple scaling | |---|---|---| | Cấu hình | một giá trị mục tiêu | nhiều alarm và bước | | Phản ứng | liên tục, tỷ lệ với độ lệch | cố định | | Thời gian chờ | instance warmup — linh hoạt hơn | cooldown chặn MỌI hành động |

Điểm yếu của cooldown: nó chặn cả việc mở rộng khẩn cấp trong 300 giây, kể cả khi tải tăng vọt thêm. Instance warmup không có nhược điểm đó — nó chỉ loại instance đang khởi động khỏi phép tính metric.

Ba tham số nên chỉnh theo ứng dụng: | Tham số | Chỉnh khi | |---|---| | Cooldown / warmup | ứng dụng khởi động lâu (JVM, cache warm-up) | | Health check grace period | tương tự | | MinSize / MaxSize | MaxSize là rào chắn chi phí quan trọng |

Với ứng dụng Java khởi động mất 5 phút, cooldown 300 giây là quá ngắn — ASG sẽ đánh giá lại khi instance mới còn chưa nhận tải, và có thể mở rộng thêm không cần thiết.

Ba cách rút ngắn thời gian mở rộng: | Cách | Lợi ích | |---|---| | Warm pool | giữ instance ở trạng thái Stopped — khởi động rất nhanh | | AMI đã nướng sẵn ứng dụng | không cài đặt lúc khởi chạy | | Scheduled scaling cho mẫu tải biết trước | mở rộng TRƯỚC khi cần |

Và một điều đáng nhớ về ngữ cảnh của đề: nó nói cooldown giúp "protect the system from unintended slowdown or unavailability". Điều đó đúng cho chiều thu hẹp — cooldown ngăn ASG chấm dứt instance dồn dập khi tải vừa giảm tạm thời, tránh việc phải mở rộng lại ngay sau đó.