Ngân hàng đề — AWS Certified Cloud Practitioner

📖 Giải thích nội dung câu hỏi

Câu hỏi:

“A user needs to perform a one‑time backup of an Amazon Elastic Block Store (Amazon EBS) volume that is attached to an Amazon EC2 instance. What is the MOST operationally efficient way to perform this backup?”

• Một lần backup → không cần duy trì quy trình sao lưu định kỳ, chỉ cần tạo bản sao lưu duy nhất.
• Operationally efficient → cách thực hiện phải giảm thiểu công sức thao tác thủ công, thời gian dừng (downtime) và không cần quản lý hạ tầng phụ (ví dụ: máy sao chép, script tự viết…).
• EBS volume đang gắn với EC2 → chúng ta có thể thao tác trực tiếp trên volume mà không cần “đưa ra” ra ngoài.

Với các yêu cầu trên, công cụ được AWS cung cấp sẵn và tối ưu nhất là EBS Snapshot. Snapshot là bản sao lưu mức khối (block‑level) được lưu trữ trên Amazon S3, được thực hiện ngay trong AWS, không cần dừng instance và hoàn toàn tự động quản lý incremental copy.

✅ Đáp án đúng

✅ Create an EBS snapshot of the volume.

• Lý do chọn:
  • ✅ Đơn giản – chỉ một lệnh (aws ec2 create-snapshot hoặc qua Console).
  • ✅ Không cần dừng instance – snapshot có thể được tạo trong khi volume vẫn đang được gắn và sử dụng (AWS sẽ tự thực hiện “freeze” cấp block).
  • ✅ Hiệu suất cao & incremental – lần đầu tạo là sao chép toàn bộ, các lần tiếp theo (nếu có) chỉ sao chép các block đã thay đổi, giảm thời gian và chi phí.
  • ✅ Tự động lưu trữ trên S3 – không cần cấu hình bucket, quyền, hay mạng riêng.
  • ✅ Khả năng khôi phục nhanh – có thể tạo lại volume mới từ snapshot hoặc khôi phục sang cùng một instance.
  • ✅ Tuân thủ và quản lý – snapshot được ghi lại trong AWS Backup và có thể gắn với tag, lifecycle policies để tự động xóa/giữ.

Vì vậy, tạo EBS snapshot là cách hoạt động hiệu quả nhất cho một backup một lần.

❌ Giải thích các phương án sai

1️⃣ Attach another EBS volume to the EC2 instance, and copy the contents.

• ❌ Không hiệu quả về mặt vận hành
  • Cần tạo, gắn, mở rộng filesystem, chạy lệnh dd, rsync hoặc công cụ sao chép khác → thao tác thủ công, dễ sai.
  • Thời gian dừng (downtime): để sao chép toàn bộ dữ liệu, thường phải ngừng ứng dụng hoặc thực hiện snapshot-level consistency thủ công.
  • Chi phí: phải trả phí cho một EBS volume phụ mà chỉ dùng một lần.
  • Quản lý: sau sao chép, phải xóa volume phụ, dọn dẹp snapshot (nếu có).

2️⃣ Copy the EBS volume to a server that is running outside AWS and is connected with AWS Direct Connect.

• ❌ Không tối ưu
  • Cần thiết lập Direct Connect, mạng riêng, cấu hình VPN/route – phức tạp, tốn thời gian và chi phí.
  • Băng thông giới hạn: sao chép toàn bộ volume (có thể TB) qua mạng sẽ lâu hơn nhiều so với snapshot nội bộ (được lưu trữ ngay trên S3).
  • Rủi ro bảo mật: dữ liệu di chuyển ra môi trường ngoài AWS cần mã hoá, quản lý khóa…
  • Không tận dụng tính năng snapshot incremental và lifecycle policies của AWS.

3️⃣ Create a custom script to copy the EBS file contents to Amazon S3.

• ❌ Không thực tế
  • Phải tự viết, bảo trì script (sử dụng dd, aws s3 cp, hoặc SDK) → tăng khối lượng công việc DevOps.
  • Không có tính năng snapshot: mỗi lần chạy script sẽ sao chép toàn bộ dữ liệu, lãng phí băng thông và chi phí lưu trữ.
  • Khó đảm bảo tính nhất quán: nếu volume đang ghi, dữ liệu có thể bị mất hoặc không đồng bộ.
  • Giải pháp đã có sẵn (create-snapshot) làm giảm đáng kể công sức và lỗi.

🛠️ Các kiến thức cập nhật đến năm 2026 liên quan

• EBS Snapshots vẫn là phương pháp chuẩn để sao lưu. AWS đã cải thiện tốc độ snapshot và giảm latency nhờ công nghệ EBS Direct APIs (ra mắt 2024) cho phép tạo snapshot trực tiếp từ các ứng dụng mà không cần qua EC2.
• Snapshot Copy & Multi‑Region Snapshots: hỗ trợ sao chép snapshot qua các region để phục hồi địa lý, nhưng trong trường hợp một lần backup trong cùng region, việc tạo snapshot vẫn là lựa chọn nhanh nhất.
• AWS Backup tích hợp EBS snapshot và cung cấp lifecycle policies tự động xóa snapshot sau thời gian nhất định, giúp giảm chi phí lưu trữ cho backup một lần.

📚 Tham khảo

• AWS Documentation – Amazon EBS Snapshots
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
• AWS Blog – New EBS Direct APIs for Faster Snapshots (2024)
  https://aws.amazon.com/blogs/aws/ebs-direct-apis/
• AWS Backup – Managing EBS Snapshots
  https://docs.aws.amazon.com/aws-backup/latest/devguide/ebs-backup.html

📌 Kết luận

Với yêu cầu backup một lần, tạo snapshot EBS là cách đơn giản, nhanh chóng, không gây downtime và chi phí tối ưu. Các phương án khác đều yêu cầu công sức thêm, chi phí cao hơn hoặc không đảm bảo tính nhất quán của dữ liệu. ✅🧩

🔎 Phân tích câu hỏi

Câu hỏi mô tả một developer chưa có kinh nghiệm với AWS, nhưng muốn “sử dụng công nghệ AWS để xây dựng một ứng dụng web”.
Yêu cầu chính ở đây là bắt đầu nhanh chóng, đơn giản hoá việc thiết lập hạ tầng và giảm thiểu việc phải quản lý các thành phần hạ tầng riêng lẻ (máy ảo, mạng, cân bằng tải, CSDL,…).

Vì người dùng mới, câu trả lời cần một dịch vụ được thiết kế cho người mới bắt đầu, cung cấp gói tích hợp sẵn (server, storage, networking, DNS) và có giá cả “pay‑as‑you‑go” đơn giản, cho phép triển khai một web app chỉ trong vài cú nhấp chuột.

✅ Đáp án đúng: Amazon Lightsail

Lý do chọn

• Đối tượng mục tiêu: Lightsail được quảng cáo như “đối với người mới bắt đầu, các nhà khởi nghiệp và các dự án nhỏ”. Nó cung cấp gói máy ảo, database, lưu trữ và networking trong một giao diện duy nhất, rất thích hợp cho người chưa quen với việc cấu hình chi tiết của AWS.
• Triển khai nhanh: Có sẵn blueprint (ví dụ: “WordPress”, “LAMP”, “Node.js”) cho phép tạo một môi trường web chỉ trong 5‑10 phút.
• Quản lý đơn giản: Không cần cấu hình VPC, security group, ELB, IAM policies… mọi thứ được tạo và gán mặc định.
• Giá cả rõ ràng: Mô hình “công suất cố định / tháng” (ví dụ: $5, $10, $20…) giúp người mới không lo lúng túng với chi phí biến động.

Trong tài liệu AWS 2026, Amazon Lightsail vẫn là dịch vụ đề xuất cho “đội ngũ phát triển mới vào AWS muốn nhanh chóng đưa ứng dụng web lên môi trường sản xuất mà không cần học sâu về kiến trúc AWS”.

🧩 Phân tích các phương án khác

❌ Amazon SageMaker

• Mục đích: Dịch vụ Machine Learning (ML) toàn diện, hỗ trợ chuẩn bị dữ liệu, huấn luyện mô hình, triển khai inference.
• Tại sao không phù hợp: Không phải là nền tảng để “xây dựng một web application”. Nó yêu cầu kiến thức về ML, và chi phí/độ phức tạp cao hơn rất nhiều so với nhu cầu của một developer chưa biết AWS.
• Kết luận: Sai.

❌ AWS Lambda

• Mục đích: Compute “serverless” chạy mã (function) đáp ứng sự kiện, không cần quản lý server.
• Tại sao không phù hợp: Dù Lambda có thể dùng để tạo API backend cho web app, nhưng không cung cấp môi trường hosting tĩnh hoặc database tích hợp sẵn. Để có một web app hoàn chỉnh, developer vẫn cần API Gateway, DynamoDB/RDS, S3, CloudFront, và phải thiết lập CI/CD, v.v… Điều này làm tăng độ phức tạp cho người mới.
• Kết luận: Sai (không phải là dịch vụ “đầu tiên” để bắt đầu).

❌ Amazon Elastic Container Service (Amazon ECS)

• Mục đích: Orchestrator cho container Docker, chạy trên EC2 hoặc Fargate.
• Tại sao không phù hợp: Đòi hỏi kiến thức về Docker, container networking, task definition, service discovery, và thường cần cấu hình VPC, subnets, security groups. Với một developer chưa có kinh nghiệm AWS, việc thiết lập ECS sẽ rất khó khăn và mất thời gian.
• Kết luận: Sai.

📚 Tham khảo (2026)

1. Amazon Lightsail – Getting Started Guide, AWS Documentation, phiên bản cập nhật 2026.
2. AWS Well‑Architected Framework – Foundations, 2025, chương “Simplify for New Developers”.
3. AWS re:Invent 2025 Session “Building Web Apps on Lightsail for Beginners”, video và slide.

🛠️ Kết luận nhanh

• ✅ Amazon Lightsail là lựa chọn tốt nhất cho developer chưa có kinh nghiệm AWS muốn “bắt đầu xây dựng một web application” vì:
  • Gói dịch vụ tích hợp, triển khai nhanh.
  • Giao diện và tài liệu hướng dẫn dành cho người mới.
  • Chi phí minh bạch, phù hợp với dự án nhỏ‑trung bình.

Các dịch vụ khác (SageMaker, Lambda, ECS) đều có mục đích chuyên sâu hơn và yêu cầu kiến thức hạ tầng/phần mềm phức tạp, nên không phù hợp với yêu cầu “bắt đầu nhanh chóng” trong câu hỏi. 🚀

📖 Phân tích câu hỏi

• Mục tiêu của công ty:
  1️⃣ Quản lý truy cập và quyền cho các ứng dụng SaaS của bên thứ ba.
  2️⃣ Cung cấp một cổng (portal) mà người dùng cuối có thể đăng nhập một lần và sau đó truy cập các tài khoản AWS (nhiều account) và các ứng dụng đám mây AWS (ví dụ: AWS Management Console, AWS‑native web apps, SaaS apps được tích hợp SAML/OIDC).

• Yêu cầu quan trọng:

  • Identity federation (định danh từ một nguồn trung tâm tới AWS).
  • Single‑sign‑on (SSO) cho nhiều tài khoản và ứng dụng.
  • Quản lý phân quyền (gán permission sets cho người dùng, nhóm, hoặc bên ngoài).
  • Giao diện người dùng dạng portal để người dùng chọn account / app mà họ có quyền.

Vì vậy, chúng ta cần một dịch vụ AWS chuyên về IAM Center (trước đây là AWS Single Sign‑On) – dịch vụ được thiết kế chính xác cho trường hợp này.

✅ Đáp án đúng

AWS IAM Identity Center (AWS Single Sign‑On)

• Cung cấp cổng SSO duy nhất, cho phép người dùng đăng nhập một lần và truy cập vào nhiều tài khoản AWS và ứng dụng SaaS (qua SAML 2.0 hoặc OIDC).
• Hỗ trợ Identity federation từ các IdP bên ngoài (Azure AD, Okta, Google Workspace, …) hoặc có thể dùng AWS Managed Microsoft AD làm nguồn IdP.
• Cho phép tạo Permission Sets (tập quyền) và gán chúng cho người dùng/nhóm trên từng tài khoản, giúp quản lý quyền một cách tập trung.
• Tích hợp sẵn với AWS Organizations, vì vậy việc mở rộng sang hàng chục, hàng trăm tài khoản là rất dễ dàng.
• Giao diện portal được AWS cung cấp, hiển thị danh sách các accounts và apps mà người dùng có quyền truy cập.

Do đó đây là lựa chọn đúng nhất cho yêu cầu của câu hỏi.

🧩 Giải thích các phương án còn lại

1️⃣ Amazon Cognito

• Mô tả: Dịch vụ quản lý định danh và xác thực cho ứng dụng di động/web (user pools, identity pools).
• Tại sao sai:
  • Cognito không cung cấp cổng SSO cho tài khoản AWS hay cho ứng dụng SaaS doanh nghiệp.
  • Nó chủ yếu dùng để đăng ký, đăng nhập người dùng cuối vào các app của bạn, không hỗ trợ permission sets trên nhiều tài khoản AWS.
  • Không có giao diện portal để lựa chọn account / app.

2️⃣ AWS Identity and Access Management (IAM)

• Mô tả: Dịch vụ quản lý người dùng và quyền trong một tài khoản AWS duy nhất.
• Tại sao sai:
  • IAM không hỗ trợ SSO đa tài khoản hay portal người dùng.
  • Không cung cấp tính năng federation cho SaaS bên ngoài; chỉ có IAM Roles và IAM Users nội bộ.
  • Để triển khai SSO đa tài khoản, bạn cần kết hợp IAM với AWS SSO (IAM Identity Center) – vì vậy IAM một mình không đáp ứng yêu cầu.

3️⃣ AWS Directory Service for Microsoft Active Directory

• Mô tả: Cung cấp Microsoft AD được quản lý trong AWS (AWS Managed Microsoft AD) để dùng cho Windows authentication, Group Policy, FSx for Windows, …
• Tại sao sai:
  • Dịch vụ này không phải là portal SSO; nó chỉ cung cấp một directory mà các ứng dụng (ví dụ: RDS AD‑integrated) có thể dùng để xác thực.
  • Không có tính năng permission sets cho tài khoản AWS, không có giao diện người dùng để chọn app.
  • Để có SSO đa tài khoản, bạn vẫn cần IAM Identity Center và có thể đồng bộ AD vào đó, nhưng AD tự nó không đáp ứng yêu cầu.

📚 Tham khảo (đến năm 2026)

• AWS IAM Identity Center Documentation – “Getting started with AWS IAM Identity Center”, https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
• AWS Blog 2025 – “AWS IAM Identity Center now supports automated permission set provisioning via AWS CloudFormation and Terraform”.
• AWS Well‑Architected Framework – Security Pillar, phần “Identity and Access Management” (2024 cập nhật).

Tóm lại: Để đáp ứng nhu cầu quản lý truy cập cho SaaS, cung cấp portal cho người dùng cuối để đăng nhập một lần và truy cập đa tài khoản AWS cùng các ứng dụng đám mây, dịch vụ phù hợp nhất là AWS IAM Identity Center (AWS Single Sign‑On). Các dịch vụ còn lại (Amazon Cognito, IAM, Directory Service) không cung cấp đầy đủ chức năng SSO đa tài khoản và portal quản lý permission set, nên đều không đáp ứng yêu cầu của câu hỏi. 🚀

1️⃣ Giải thích nội dung câu hỏi
Câu hỏi hỏi: “Which AWS service is designed for users running workloads that include a NoSQL database?”
Nghĩa là: Dịch vụ AWS nào được thiết kế đặc biệt cho các tải công việc (workloads) có sử dụng cơ sở dữ liệu NoSQL?

• “NoSQL” ở đây đề cập tới các mô hình dữ liệu phi quan hệ như key‑value, document, wide‑column, hoặc graph.
• AWS cung cấp một số dịch vụ lưu trữ dữ liệu, nhưng chỉ có một dịch vụ được tối ưu hoá và quản lý hoàn toàn cho NoSQL.

2️⃣ Đáp án đúng
✅ Amazon DynamoDB

Lý do chọn:

• DynamoDB là dịch vụ NoSQL hoàn toàn quản lý, hỗ trợ mô hình key‑value và document.
• Tự động mở rộng (scale) cả về throughput và dung lượng lưu trữ mà không cần quản lý cluster.
• Cung cấp hai chế độ tính phí: Provisioned (với Auto Scaling) và On‑Demand – phù hợp với mọi loại tải công việc.
• Tính năng DynamoDB Global Tables, DynamoDB Streams, Point‑in‑Time Recovery, TTL, và PartiQL (truy vấn SQL‑like) giúp triển khai các ứng dụng hiện đại như gaming, IoT, mobile backend, và real‑time analytics.
• Được cập nhật liên tục tới 2026, DynamoDB đã ra mắt DynamoDB Serverless (on‑demand), Amazon DynamoDB Accelerator (DAX) v2, và enhanced encryption at rest – củng cố vị trí của nó như dịch vụ NoSQL “đầu tiên và duy nhất” trên AWS.

3️⃣ Phân tích các phương án

• ❌ Amazon RDS

  • RDS (Relational Database Service) là dịch vụ quan hệ (SQL) hỗ trợ MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, và Aurora.
  • Không phải NoSQL; nó yêu cầu schema cố định và hỗ trợ các câu lệnh SQL chuẩn, không phù hợp với các workload cần mô hình dữ liệu linh hoạt như document hoặc key‑value.

• ❌ Amazon S3

  • S3 là dịch vụ đối tượng lưu trữ (object storage). Mặc dù có thể lưu trữ dữ liệu phi cấu trúc, nó không phải là cơ sở dữ liệu và không cung cấp các tính năng truy vấn NoSQL (trừ khi kết hợp với Athena hoặc S3 Select, nhưng vẫn không phải là DB).
  • Do đó không được thiết kế để chạy workload “có NoSQL database”.

• ❌ Amazon Redshift

  • Redshift là data warehouse quan hệ, tối ưu cho phân tích dữ liệu lớn bằng SQL.
  • Nó không hỗ trợ mô hình NoSQL; các bảng trong Redshift luôn có schema cố định và dựa trên kiến trúc column‑oriented.

• ✅ Amazon DynamoDB

  • Như đã nêu ở phần 2️⃣, DynamoDB chính là dịch vụ NoSQL được AWS thiết kế đặc biệt cho các workload cần độ trễ thấp, khả năng mở rộng tự động và tính sẵn sàng cao.

4️⃣ Kiến thức cập nhật đến năm 2026

• DynamoDB Serverless (On‑Demand) – 2024: tự động mở rộng tới hàng nghìn request/giây mà không cần cấu hình throughput.
• DAX v2 – 2025: bộ nhớ đệm in‑memory giảm độ trễ đọc xuống ~10 µs.
• Global Tables v2 – 2025: hỗ trợ multi‑master replication trên nhiều region với latency < 100 ms.
• PartiQL for DynamoDB – 2024: cho phép truy vấn bằng ngôn ngữ SQL‑like trên dữ liệu NoSQL.
• Enhanced Encryption at Rest (KMS‑Managed Keys) – 2026: bảo mật dữ liệu mạnh hơn cho các môi trường yêu cầu compliance.

5️⃣ Tham khảo

• 📘 AWS Documentation – Amazon DynamoDB (phiên bản 2026). https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/
• 📘 AWS re:Invent 2025 – DynamoDB Global Tables v2 & DAX v2 (video và slide).
• 📘 AWS Well‑Architected Framework – Database Pillar (2025 update).

🧩 Tổng kết:
Câu hỏi muốn kiểm tra khả năng nhận biết dịch vụ AWS được thiết kế cho NoSQL. Trong các lựa chọn, chỉ Amazon DynamoDB đáp ứng đầy đủ yêu cầu về mô hình dữ liệu, tính năng mở rộng tự động, và các cải tiến mới nhất đến 2026. Các dịch vụ còn lại (RDS, S3, Redshift) phục vụ các mục đích khác (SQL relational, object storage, data warehousing) và do đó không phù hợp.

🔎 Phân tích câu hỏi
Công ty có một website đang chạy trên AWS và muốn phát tải nội dung tới người dùng trên toàn thế giới đồng thời giảm độ trễ (low‑latency) cho mọi vị trí. Yêu cầu này thực chất là một vấn đề về phân phối nội dung (content delivery) và caching ở các edge location để người dùng không phải luôn luôn truy cập tới nguồn gốc (origin) nằm trong một vùng AWS duy nhất.

Do vậy, chúng ta cần lựa chọn dịch vụ CDN (Content Delivery Network) của AWS, có khả năng:

• Replicate (sao chép) các tài nguyên tĩnh và thậm chí các tài nguyên động qua hơn 300 edge locations trên toàn cầu.
• Tự động chọn edge location gần nhất với người dùng cuối, giảm thời gian round‑trip.
• Hỗ trợ các tính năng bảo mật (HTTPS, WAF, signed URLs) và tối ưu hoá chi phí (caching, origin failover).

✅ Dịch vụ đáp ứng yêu cầu: Amazon CloudFront – CDN chính thức của AWS, được thiết kế để cung cấp nội dung web, video, API và các tài nguyên khác với độ trễ cực thấp cho người dùng toàn cầu.

📚 Đánh giá từng phương án

1. AWS CloudFormation

• Giải thích: CloudFormation là dịch vụ Infrastructure as Code (IaC), cho phép bạn mô tả và triển khai hạ tầng AWS dưới dạng template JSON/YAML. Nó không chịu trách nhiệm phân phối nội dung hay giảm độ trễ cho người dùng cuối.
• Kết luận: ❌ Không phải là giải pháp CDN, vì vậy không đáp ứng yêu cầu “phân phối website toàn cầu với latency thấp”.

2. Amazon CloudFront

• Giải thích: CloudFront là Content Delivery Network của AWS. Khi bạn cấu hình một distribution, CloudFront sẽ lấy nội dung từ origin (S3, EC2, ELB, API Gateway, …) và lưu cache tại các edge locations trên toàn thế giới. Khi người dùng yêu cầu, CloudFront trả về nội dung từ edge gần nhất, giảm đáng kể thời gian phản hồi. Ngoài ra, CloudFront hỗ trợ:
  • Edge caching và TTL tùy chỉnh.
  • Lambda@Edge để thực thi logic tùy chỉnh tại edge.
  • AWS WAF tích hợp để bảo mật.
  • HTTPS, SNI, custom SSL certificates, signed URLs/cookies.
• Kết luận: ✅ Đây chính là dịch vụ đáp ứng yêu cầu “deliver website worldwide with low‑latency”.

3. Amazon ElastiCache

• Giải thích: ElastiCache là dịch vụ in‑memory caching (Redis hoặc Memcached) dùng để tăng tốc độ truy cập dữ liệu cho các ứng dụng chạy trong cùng vùng (region). Nó không có các edge locations toàn cầu, vì vậy không giúp người dùng ở các khu vực xa trung tâm giảm độ trễ khi truy cập website.
• Kết luận: ❌ Không phải CDN; chỉ tối ưu hoá truy cập dữ liệu nội bộ cho ứng dụng.

4. Amazon DynamoDB

• Giải thích: DynamoDB là NoSQL database được thiết kế để cung cấp độ trễ millisecond ở single‑region (hoặc multi‑region với Global Tables). Mặc dù có tính năng replica toàn cầu, nó không chịu trách nhiệm phân phối nội dung web tĩnh hoặc động tới người dùng cuối. Ngoài ra, việc sử dụng DynamoDB để phục vụ một website tĩnh sẽ là “over‑engineering” và không giảm latency cho người dùng như CDN.
• Kết luận: ❌ Không phải giải pháp CDN; không liên quan tới việc giảm độ trễ cho việc tải trang web.

📌 Kết luận ngắn gọn

Đáp án đúng: Amazon CloudFront.

Các lựa chọn khác (CloudFormation, ElastiCache, DynamoDB) không cung cấp chức năng CDN và do đó không đáp ứng yêu cầu về phân phối toàn cầu và độ trễ thấp.

📚 Tham khảo

• AWS Documentation – Amazon CloudFront (phiên bản cập nhật 2026): https://docs.aws.amazon.com/cloudfront/latest/DeveloperGuide/WhatIsCloudFront.html
• AWS Well‑Architected Framework – Performance Efficiency Pillar (đề cập tới việc sử dụng CDN để giảm latency): https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html
• AWS Blog – New Edge Locations & Features in 2025‑2026 (cập nhật số lượng edge locations và tính năng Lambda@Edge): https://aws.amazon.com/blogs/aws/

💡 Mẹo thực hành: Khi thiết kế kiến trúc cho website toàn cầu, luôn cân nhắc đặt origin ở một hoặc nhiều regional services (S3, ALB, EC2) và dùng CloudFront làm lớp front‑end để tối ưu hoá latency và bảo mật. 🚀

📖 Phân tích câu hỏi

Câu hỏi: “A company wants to add a conversational chatbot to its website. Which AWS service can the company use to meet this requirement?”

• Yêu cầu: tạo một chatbot có khả năng giao tiếp bằng ngôn ngữ tự nhiên (text hoặc voice) và nhúng vào website.
• Vì vậy chúng ta cần một dịch vụ AWS chuyên về xây dựng, huấn luyện và triển khai bot với tích hợp sẵn các công cụ xử lý ngôn ngữ tự nhiên (NLU) và khả năng kết nối với các kênh (web, mobile, Slack, …).

✅ Dịch vụ phù hợp nhất hiện nay (đến tháng 4/2026) là Amazon Lex – dịch vụ “serverless” cho phép tạo bot hội thoại, hỗ trợ cả text và speech, tích hợp với AWS Lambda, Amazon Polly, và có sẵn SDK cho web.

✅ Đáp án đúng

✅ Amazon Lex

• Lý do: Amazon Lex cung cấp nền tảng để xây dựng, huấn luyện và triển khai các chatbot hội thoại. Nó bao gồm:
  • Intent recognition (Xác định ý định) và slot filling (thu thập tham số) dựa trên Amazon Comprehend.
  • Hỗ trợ text và voice (sử dụng Amazon Polly để chuyển đổi text‑to‑speech và Amazon Transcribe cho speech‑to‑text).
  • Có AWS SDK for JavaScript và Web UI components (Amazon Lex Web UI) giúp nhúng trực tiếp vào website.
  • Tích hợp AWS Lambda để thực hiện logic nghiệp vụ và Amazon CloudWatch để giám sát.
• Được cập nhật liên tục với Amazon Lex V2 (2023‑2024), cung cấp đa ngôn ngữ, quản lý phiên hội thoại mạnh mẽ, và khả năng continuous learning.

🧩 Giải thích các phương án (giữ nguyên tiếng Anh)

- Amazon Textract

• Giải thích: Amazon Textract là dịch vụ trích xuất dữ liệu văn bản và bảng từ tài liệu quét (PDF, hình ảnh). Nó không cung cấp khả năng hội thoại hay xử lý ngôn ngữ tự nhiên.
• Tại sao sai: Không liên quan tới việc xây dựng chatbot; chỉ dùng để OCR và phân tích tài liệu.

- Amazon Lex

• Giải thích: Như đã nêu ở trên, Lex là dịch vụ chuyên biệt để tạo chatbot hội thoại, hỗ trợ cả text và voice, tích hợp sẵn NLU và dễ nhúng vào website.
• Tại sao đúng: Đáp ứng đầy đủ yêu cầu “conversational chatbot” và được thiết kế để triển khai nhanh chóng trên môi trường web.

- AWS Glue

• Giải thích: AWS Glue là dịch vụ ETL (Extract, Transform, Load) quản lý dùng để chuẩn bị và chuyển đổi dữ liệu cho các kho dữ liệu như Amazon Redshift, S3, Athena.
• Tại sao sai: Không có chức năng tạo bot hay xử lý giao tiếp người‑máy; mục tiêu chính là xử lý dữ liệu.

- Amazon Rekognition

• Giải thích: Amazon Rekognition là dịch vụ phân tích hình ảnh và video (phát hiện khuôn mặt, đối tượng, văn bản trong ảnh, phân tích hành vi).
• Tại sao sai: Chỉ làm việc với dữ liệu đa phương tiện, không hỗ trợ tạo bot hội thoại; không phù hợp với yêu cầu chatbot trên website.

📚 Tham khảo & nguồn tài liệu (cập nhật đến 2026)

1. Amazon Lex Developer Guide – phiên bản V2 (AWS Documentation, cập nhật tháng 3/2026).
   https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html
2. AWS Blog – “Introducing Amazon Lex V2 – Multi‑language, Multi‑region, and Multi‑bot support” (Nov 2023).
   https://aws.amazon.com/blogs/aws/amazon-lex-v2/
3. AWS Well‑Architected Framework – Serverless Applications (2024).
   https://aws.amazon.com/architecture/well-architected/serverless/
4. Amazon Lex Web UI – GitHub Repository (phiên bản 2.0, cập nhật 2025).
   https://github.com/aws/lex-web-ui

🛠️ Kết luận nhanh

• Để thêm một chatbot hội thoại vào website, Amazon Lex là dịch vụ phù hợp nhất vì nó cung cấp đầy đủ các tính năng NLU, hỗ trợ text/voice, và có SDK/Component web dễ nhúng.
• Các dịch vụ còn lại (Textract, Glue, Rekognition) không liên quan tới việc xây dựng bot và do đó không đáp ứng yêu cầu của câu hỏi.

📝 Phân tích câu hỏi

Which AWS service or feature can be used to monitor for potential disk write spikes on a system that is running on Amazon EC2?

Câu hỏi yêu cầu chúng ta chọn dịch vụ/đặc tính của AWS có khả năng giám sát (monitor) mức độ ghi đĩa (disk write) của một instance EC2, đặc biệt là phát hiện các “spike” – tức là sự tăng đột biến nhanh chóng về số lượng byte hoặc số lần ghi. Đối tượng cần theo dõi là metric (chỉ số) liên quan tới đĩa, không phải các sự kiện API hay trạng thái dịch vụ.

✅ Đáp án đúng

• Amazon CloudWatch

  CloudWatch là dịch vụ thu thập, lưu trữ và hiển thị metrics của tài nguyên AWS, bao gồm các metric mặc định của EC2 như DiskWriteBytes, DiskWriteOps. Khi bật CloudWatch Agent hoặc Unified CloudWatch Agent, chúng ta còn có thể thu thập metric chi tiết hơn ở mức hệ điều hành (ví dụ: iostat). Các metric này cho phép thiết lập alarms để cảnh báo khi có spike ghi đĩa vượt ngưỡng quy định.

🔍 Giải thích các lựa chọn

❌ AWS CloudTrail

• CloudTrail ghi lại API call và sự kiện quản trị (ví dụ: tạo, xóa, thay đổi cấu hình tài nguyên).
• Nó không thu thập metric về hiệu năng hệ thống như Disk Write.
• Do đó không thể dùng để giám sát spike ghi đĩa trên EC2.

❌ AWS Health Dashboard

• AWS Health cung cấp thông tin về trạng thái và sự cố của các dịch vụ AWS ở cấp độ nền tảng (ví dụ: sự cố vùng, bảo trì).
• Không cung cấp metric thời gian thực của instance EC2 hay chi tiết về I/O đĩa.
• Vì mục tiêu là monitoring ở mức instance, Health Dashboard không phù hợp.

❌ AWS Trusted Advisor

• Trusted Advisor là công cụ đánh giá best‑practice (bảo mật, chi phí, hiệu năng, fault tolerance).
• Nó đưa ra các khuyến nghị dựa trên đánh giá tổng thể, không phải là công cụ giám sát thời gian thực.
• Không có metric “DiskWriteBytes” hay cảnh báo spike.

✅ Amazon CloudWatch (đáp án đúng)

• Metrics mặc định: DiskReadBytes, DiskWriteBytes, DiskReadOps, DiskWriteOps được tự động gửi lên CloudWatch cho mỗi instance EC2.
• Alarms: có thể cấu hình alarm (ví dụ: DiskWriteBytes > 100 MB trong 5 phút) để nhận thông báo qua SNS khi có spike.
• CloudWatch Agent (phiên bản unified) cho phép thu thập metric OS‑level như iostat, diskio để chi tiết hơn.
• Dashboards: cho phép tạo bảng điều khiển hiển thị xu hướng ghi đĩa theo thời gian, giúp phát hiện bất thường nhanh chóng.

📚 Tham khảo tài liệu (2026)

1. Amazon CloudWatch – Metrics for Amazon EC2
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring_ec2.html

2. Unified CloudWatch Agent – Collecting System-level Metrics
   https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html

3. AWS CloudTrail – What It Does
   https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html

4. AWS Health Dashboard – Overview
   https://aws.amazon.com/health/

5. AWS Trusted Advisor – Features
   https://aws.amazon.com/premiumsupport/technology/trusted-advisor/

🎯 Kết luận nhanh

• Để giám sát spike ghi đĩa trên EC2, Amazon CloudWatch là dịch vụ duy nhất trong các lựa chọn cung cấp metric đĩa và khả năng thiết lập alarm.
• Các dịch vụ còn lại (CloudTrail, Health Dashboard, Trusted Advisor) phục vụ các mục đích quản trị, thông báo trạng thái dịch vụ, hoặc khuyến nghị, không phải giám sát hiệu năng chi tiết ở mức hệ thống.

Hy vọng phân tích trên giúp bạn nắm vững lý do lựa chọn CloudWatch và hiểu rõ tại sao các tùy chọn khác không phù hợp! 🚀

🔍 Phân tích câu hỏi

Công ty có các ứng dụng điều khiển thiết bị máy móc trong nhà máy (on‑premises). Khi các ứng dụng này cần giao tiếp với thiết bị vật lý, độ trễ (latency) thấp nhất là yếu tố quyết định để tránh lỗi thời gian thực và đảm bảo an toàn vận hành. Vì vậy, câu hỏi yêu cầu chọn dịch vụ AWS cho phép chạy các ứng dụng trực tiếp tại chỗ (on‑premises) với độ trễ gần bằng 0 so với môi trường đám mây công cộng.

✅ Đáp án đúng

✅ AWS Outposts

📌 Vì sao Outposts là lựa chọn đúng?

• Cấu trúc “on‑premises” thực sự: Outposts là phần cứng AWS được đặt tại trung tâm dữ liệu hoặc site của khách hàng, cung cấp các dịch vụ AWS (EC2, EBS, RDS, ECS, EKS …) và API giống hệt môi trường công cộng, nhưng vận hành ngay trong mạng nội bộ của khách hàng.
• Độ trễ cực thấp: Vì tài nguyên tính toán, lưu trữ và mạng đều nằm ngay trong nhà máy, các ứng dụng có thể truy cập thiết bị qua đường truyền nội bộ (latency thường < 1 ms), tránh được đường truyền rộng WAN tới Region AWS.
• Quản lý thống nhất: Dù chạy on‑premises, Outposts vẫn được quản lý, cập nhật và giám sát bằng AWS Management Console, CloudWatch, IAM… giúp duy trì độ nhất quán về vận hành và bảo mật.
• Hỗ trợ các workload đa dạng: Có thể chạy EC2 instances, containers (ECS/EKS), hay thậm chí Lambda (với Lambda on Outposts, ra mắt 2023 và mở rộng tính năng tới 2025). Do đó, Outposts đáp ứng mọi kiểu workload mà công ty đang có.

Nguồn: AWS Outposts product page (https://aws.amazon.com/outposts/), tài liệu “AWS Outposts – Overview” (cập nhật 2025) và “Best practices for low‑latency edge workloads” (AWS Whitepaper, 2024).

❌ Giải thích các phương án sai

1. Amazon EC2

• Mô tả: Dịch vụ máy ảo chạy trong các Region hoặc Availability Zones của AWS.
• Lý do không phù hợp: Để truy cập thiết bị trong nhà máy, EC2 phải đi qua mạng WAN/Internet tới một Region, gây độ trễ đáng kể (từ vài chục đến hàng trăm ms tùy vào khoảng cách mạng). Với các ứng dụng điều khiển thời gian thực, độ trễ này không đáp ứng yêu cầu “LEAST latency”.
• Ngoài ra: Việc mở rộng và duy trì kết nối mạng ổn định tới cloud công cộng có thể gây phức tạp về bảo mật và chi phí liên quan đến băng thông.

2. AWS Lambda

• Mô tả: Nền tảng “serverless” cho phép chạy mã hàm ngắn, tự động mở rộng, chỉ tồn tại trong môi trường AWS Cloud.
• Lý do không phù hợp: Lambda không có phiên bản “on‑premises” (trừ một số khả năng thực thi trên Outposts, nhưng khi câu hỏi liệt kê Lambda riêng biệt, ngụ ý là Lambda ở Cloud). Vì vậy, các hàm Lambda sẽ phải được truyền qua mạng tới Region, tạo độ trễ mạng tương tự EC2. Thêm vào đó, thời gian “cold start” (đặc biệt với runtime mới) có thể làm tăng độ trễ tổng thể.

3. AWS Fargate

• Mô tả: Dịch vụ “serverless containers” cho phép chạy containers mà không cần quản lý server, được triển khai trên Amazon ECS/EKS trong Cloud.
• Lý do không phù hợp: Giống như EC2 và Lambda, Fargate chạy trong các Region và phải giao tiếp qua mạng WAN để kết nối với thiết bị tại chỗ. Điều này dẫn tới độ trễ cao hơn so với giải pháp đặt trực tiếp tại nhà máy.
• Ngoài ra: Fargate không hỗ trợ triển khai trực tiếp on‑premises (trừ khi chạy trên Outposts, nhưng trong câu hỏi lựa chọn “Fargate” riêng biệt, ngụ ý là Fargate Cloud).

🧩 Tổng kết

• Outposts → ✅ vì đưa toàn bộ hạ tầng AWS ngay tại site, giảm độ trễ tới mức tối thiểu và duy trì quản lý thống nhất.
• EC2, Lambda, Fargate → ❌ vì chúng chạy trong Cloud, phải truyền dữ liệu qua mạng WAN, gây độ trễ không đáp ứng yêu cầu “least latency”.

📚 Tham khảo

1. AWS Outposts – Overview, AWS Documentation, phiên bản cập nhật 2025.
2. AWS Whitepaper: Edge Computing and Low‑Latency Applications, 2024.
3. AWS Lambda on Outposts, blog AWS (2023) – giới thiệu khả năng chạy Lambda trên Outposts, khẳng định tính năng này đã được tích hợp vào Outposts chứ không phải Lambda độc lập.
4. Amazon EC2 Documentation, 2026 – mô tả kiến trúc khu vực và latency network.

💡 Ghi chú: Khi câu hỏi chỉ liệt kê các dịch vụ “Amazon EC2”, “AWS Lambda”, “AWS Fargate” mà không kèm “on Outposts”, chúng luôn được hiểu là phiên bản Cloud. Vì vậy, trong bối cảnh yêu cầu “least latency” cho môi trường on‑premises, AWS Outposts là đáp án duy nhất phù hợp.

📝 Phân tích câu hỏi

Câu hỏi:

Which AWS Cloud Adoption Framework (AWS CAF) perspective focuses on organizing an inventory of data products in a data catalog?

Câu hỏi yêu cầu bạn xác định perspective (khía cạnh) nào trong AWS Cloud Adoption Framework (CAF) chịu trách nhiệm “tổ chức một danh mục (inventory) các sản phẩm dữ liệu trong một data catalog”.

AWS CAF gồm sáu perspective chính, mỗi perspective hỗ trợ các mục tiêu và hoạt động khác nhau khi chuyển đổi lên đám mây:

1. Business – Tập trung vào lợi nhuận, mục tiêu kinh doanh, ROI, và thay đổi mô hình kinh doanh.
2. People – Quản lý thay đổi văn hoá, kỹ năng, đào tạo và quản trị con người.
3. Governance – Định nghĩa chính sách, quy trình, quản trị rủi ro, tuân thủ, và quản lý dữ liệu (bao gồm catalog, chất lượng, bảo mật).
4. Platform – Kiến trúc hạ tầng, công cụ, nền tảng tự động hoá, và chuẩn hoá môi trường.
5. Security – Bảo mật, quản lý danh tính, kiểm soát truy cập, và bảo vệ dữ liệu.
6. Operations – Vận hành, giám sát, sự kiện, và tối ưu hoá chi phí.

Trong số các perspective này, Governance là khía cạnh chịu trách nhiệm “định hình và duy trì các quy tắc, quy trình, và kiểm soát liên quan đến dữ liệu”, trong đó có việc xây dựng và duy trì một data catalog để quản lý, khám phá và bảo vệ các sản phẩm dữ liệu.

✅ Đáp án đúng: Governance

Lý do chọn:

• Governance perspective trong AWS CAF bao gồm Data Governance, một thành phần quan trọng giúp tổ chức tạo, duy trì và quản lý data catalog (danh mục dữ liệu).
• Nhiệm vụ này liên quan đến việc xác định chính sách quản lý dữ liệu, chuẩn metadata, quy trình dữ liệu, và việc kiểm soát truy cập – tất cả đều nhằm mục tiêu “organizing an inventory of data products”.
• Các tài liệu AWS (ví dụ: AWS Cloud Adoption Framework – Governance Perspective và AWS Data Catalog trong Amazon Glue) khẳng định việc quản lý dữ liệu và catalog là một phần cốt lõi của perspective này.

❌ Giải thích các phương án còn lại

1️⃣ Operations

• Mô tả: Perspective này tập trung vào vận hành hạ tầng, giám sát, incident response, và tối ưu chi phí.
• Tại sao sai: Mặc dù Operations có thể giám sát các data pipelines, nó không chịu trách nhiệm thiết kế hoặc duy trì data catalog. Việc “organizing an inventory of data products” là một công việc thuộc quản trị dữ liệu, không phải vận hành thường ngày.

2️⃣ Business

• Mô tả: Nhắm tới định hướng chiến lược kinh doanh, ROI, và cách công nghệ hỗ trợ mục tiêu kinh doanh.
• Tại sao sai: Business perspective quan tâm tới giá trị kinh doanh mà dữ liệu mang lại, nhưng không quy định cách catalog dữ liệu được xây dựng hoặc quản lý.

3️⃣ Platform

• Mô tả: Đề cập đến thiết kế hạ tầng, nền tảng dịch vụ, automation, và chuẩn hoá các môi trường đám mây.
• Tại sao sai: Platform có thể cung cấp các dịch vụ (VD: Amazon Glue, AWS Lake Formation) để tạo catalog, nhưng không phải là perspective chịu trách nhiệm quyết định “tổ chức inventory”. Quyết định này thuộc Governance – nơi định nghĩa các quy tắc và chuẩn metadata.

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Cloud Adoption Framework – Governance Perspective (AWS Documentation, cập nhật 2025).
2. AWS Data Catalog – Amazon Glue (AWS Documentation, 2024–2026).
3. AWS Lake Formation – Data Governance (AWS Whitepaper, 2025).
4. AWS Well‑Architected Framework – Operational Excellence & Governance Pillars (2026).

Các tài liệu trên mô tả rõ ràng rằng Governance là perspective chịu trách nhiệm về Data Governance, Catalog Management, và Compliance, trong khi các perspective khác tập trung vào các khía cạnh riêng biệt.

🔚 Tóm tắt nhanh:

• Câu hỏi yêu cầu xác định perspective chịu trách nhiệm tổ chức danh mục dữ liệu.
• Đáp án đúng: Governance.
• Operations, Business, Platform đều không liên quan trực tiếp đến việc quản lý catalog; chúng tập trung vào vận hành, chiến lược kinh doanh và hạ tầng.

Hy vọng phân tích trên giúp bạn nắm rõ lý do lựa chọn và hiểu sâu hơn về cách AWS CAF phân chia trách nhiệm trong quá trình chuyển đổi đám mây! 🚀

📖 Giải thích nội dung câu hỏi
Công ty đang chạy tải công việc (production workload) trên AWS và cần chọn một gói hỗ trợ (AWS Support Plan). Yêu cầu quan trọng là đảm bảo đáp ứng nhu cầu sản xuất nhưng chi phí phải ở mức thấp nhất có thể. Vì vậy chúng ta phải so sánh các gói hỗ trợ hiện có (theo bảng giá và tính năng cập nhật tới năm 2026) và xác định gói nào vừa đáp ứng yêu cầu sản xuất (có Business‑critical support, 24/7 technical support, Access to Trusted Advisor, AWS Support API, …) nhưng lại có mức phí thấp hơn so với các gói cao cấp hơn.

✅ Đáp án đúng: Business

Lý do chọn “Business” là đáp án đúng:

• Phạm vi hỗ trợ phù hợp cho môi trường production: Gói Business cung cấp hỗ trợ 24 giờ/ngày, 7 ngày/tuần, truy cập vào AWS Trusted Advisor (full set), AWS Support API, và đối tượng Technical Account Manager (TAM) không bắt buộc (đối với Enterprise mới có TAM). Đây là mức hỗ trợ đủ cho các workload quan trọng nhưng không yêu cầu các dịch vụ tùy chỉnh cao cấp như Enterprise.
• Chi phí thấp hơn Enterprise và Enterprise On‑Ramp: Theo bảng giá 2026, Business tính 10 % chi phí sử dụng AWS (đối với các dịch vụ tính phí) với mức tối thiểu $100 USD/tháng. Enterprise tính 15 % và Enterprise On‑Ramp (được giới thiệu 2024 cho các khách hàng mới chuyển sang Enterprise) tính 15 % nhưng có mức tối thiểu $5,000 USD/tháng, cao hơn đáng kể.
• Developer không đủ cho môi trường production: Gói Developer chỉ hỗ trợ trong giờ làm việc (business hours) và không có truy cập đầy đủ vào Trusted Advisor, vì vậy không đáp ứng yêu cầu “production workload”.

Do đó, Business là lựa chọn đáp ứng yêu cầu “production workload” với chi phí thấp nhất trong các gói hỗ trợ có mức độ hỗ trợ tương đương.

🧩 Phân tích chi tiết từng phương án

1. Developer

Developer

• Mô tả gói (theo AWS Documentation 2026):

  • Hỗ trợ qua email trong giờ làm việc (Business Hours) – không có hỗ trợ 24/7.
  • Truy cập Basic Trusted Advisor checks (có 7 checks cơ bản).
  • Không có Access to AWS Support API.
  • Không có “Response time” nhanh cho các vấn đề nghiêm trọng (cấp P2 – Response ≤ 12 giờ).

• Vì sao sai:

  • Đối với production workload, công ty cần hỗ trợ 24/7 và độ ưu tiên cao (P1 – Response ≤ 1 giờ). Developer không đáp ứng được, nên không thể được chọn.
  • Mặc dù là gói rẻ nhất, nhưng không thỏa đủ tiêu chí “production”.

2. Enterprise On‑Ramp

Enterprise On‑Ramp

• Mô tả gói (từ 2024‑2026):

  • Dành cho khách hàng mới muốn chuyển lên Enterprise nhanh chóng.
  • Cung cấp 24/7 support, full Trusted Advisor, AWS Support API, và Technical Account Manager (TAM) chuyên biệt.
  • Giá: 15 % tổng chi phí AWS với mức tối thiểu $5,000 USD/tháng.

• Vì sao sai:

  • Mặc dù đáp ứng đầy đủ yêu cầu, chi phí tối thiểu $5,000/tháng (hoặc 15 % chi phí AWS) cao hơn so với gói Business (tối thiểu $100/tháng hoặc 10 %).
  • Vì mục tiêu là “lowest cost”, Enterprise On‑Ramp không phù hợp.

3. Enterprise

Enterprise

• Mô tả gói (2026):

  • Hỗ trợ 24/7, full Trusted Advisor, AWS Support API, Technical Account Manager (TAM), Infrastructure Event Management (IEM), và well‑architected review.
  • Giá: 15 % chi phí AWS (tối thiểu $15,000 USD/tháng cho hầu hết các tài khoản).

• Vì sao sai:

  • Đây là gói cao cấp nhất và đắt nhất trong số các lựa chọn.
  • Mặc dù cung cấp mọi tính năng, chi phí lớn hơn đáng kể so với Business, không đáp ứng yêu cầu “lowest cost”.

4. Business

Business

• Mô tả gói (2026):

  • Hỗ trợ 24/7 qua email, chat, và phone.
  • Full set of Trusted Advisor checks (≈ 53 checks).
  • AWS Support API cho phép tự động hoá ticket.
  • Response time: P1 ≤ 1 giờ, P2 ≤ 4 giờ, P3 ≤ 12 giờ.
  • Giá: 10 % chi phí AWS với mức tối thiểu $100 USD/tháng (đối với tài khoản có chi phí > $10,000/tháng, tính 10 %).

• Vì sao đúng:

  • Đáp ứng đủ các tiêu chí quan trọng cho môi trường production (24/7, Fast response, full Trusted Advisor, API).
  • Chi phí thấp nhất trong số các gói có mức hỗ trợ tương đương (Enterprise và Enterprise On‑Ramp đắt hơn; Developer không đủ tính năng).

📚 Tham khảo nguồn tài liệu

1. AWS Support Plans – Official Documentation (2026)
   https://aws.amazon.com/premiumsupport/plans/
2. AWS Trusted Advisor – Feature Comparison (2026)
   https://aws.amazon.com/premiumsupport/trustedadvisor/
3. AWS Support Pricing – FAQ (2026)
   https://aws.amazon.com/premiumsupport/pricing/
4. AWS Well‑Architected Framework – Production Workloads
   https://docs.aws.amazon.com/wellarchitected/latest/framework/overview.html

🛠️ Kết luận

Với yêu cầu hỗ trợ môi trường production và chi phí thấp nhất, gói Business là lựa chọn hợp lý nhất. Các gói Enterprise và Enterprise On‑Ramp cung cấp tính năng tương tự nhưng giá cao hơn, còn Developer không đáp ứng được yêu cầu hỗ trợ 24/7 và độ ưu tiên cao. ✅