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

Đáp án

D — Amazon S3 Standard-Infrequent Access (Standard-IA).

Vì sao đúng

Đề nêu ba điều kiện, và Standard-IA là lựa chọn duy nhất thoả cả ba: | Điều kiện | Yêu cầu | |---|---| | Truy cập HAI LẦN mỗi năm tài chính | rất thưa — không cần Standard | | Phải có sẵn với độ trễ MILI GIÂY | loại mọi lớp Glacier cần restore | | Hàng trăm terabyte | chi phí lưu trữ là yếu tố quyết định |

Vế "millisecond latency" là điều kiện loại bỏ Glacier:

Glacier Deep Archive:  12–48 giờ  ✗
Glacier Flexible:      1 phút – 12 giờ  ✗
Standard-IA:           TỨC THÌ, cùng độ trễ với Standard  ✅

Và Standard-IA rẻ hơn Standard khoảng 45%:

Standard:     ~0,023 USD/GB-tháng
Standard-IA:  ~0,0125 USD/GB-tháng
    ↓
    Với 500 TB: chênh lệch khoảng 5.250 USD mỗi tháng

Đổi lại có phí truy xuất, nhưng với hai lần đọc mỗi năm thì không đáng kể:

Phí truy xuất: ~0,01 USD/GB
500 TB × 2 lần/năm = 1 PB truy xuất = ~10.000 USD/năm
    ↓
    So với tiết kiệm 63.000 USD/năm ở chi phí lưu trữ
    → vẫn có lợi rất lớn

Và AWS Step Functions trong đề không ảnh hưởng tới lựa chọn lớp lưu trữ — nó chỉ điều phối quy trình tạo báo cáo.

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

• **C. S3 Intelligent-Tiering — đây là phương án gần nhất và cũng cho truy xuất tức thì, nhưng nó không tối ưu khi mẫu truy cập ĐÃ BIẾT RÕ: Intelligent-Tiering có giá trị khi bạn không đoán được dữ liệu nào sẽ được đọc. Ở đây đề nói rõ hai lần mỗi năm — đặt Standard-IA tường minh rẻ hơn và tránh được phí giám sát theo object của Intelligent-Tiering.
• **B. S3 Standard — đắt hơn không cần thiết: trả giá cao nhất cho dữ liệu đọc hai lần mỗi năm.
• **A. Glacier Deep Archive — rẻ nhất nhưng vi phạm yêu cầu: thời gian truy xuất 12–48 giờ, hoàn toàn không đáp ứng "millisecond latency".

Ghi nhớ về lựa chọn tốt hơn

Với mẫu "đọc hai lần mỗi năm nhưng cần mili giây", Glacier Instant Retrieval là lựa chọn tối ưu hơn:

Glacier Instant Retrieval:
    Lưu trữ: ~0,004 USD/GB-tháng  (rẻ hơn Standard-IA ~68%)
    Truy xuất: MILI GIÂY
    Phí truy xuất: cao hơn Standard-IA
    Lưu tối thiểu: 90 ngày

Với 500 TB đọc hai lần mỗi năm, nó rẻ hơn Standard-IA đáng kể. (Nó không nằm trong các phương án, và Standard-IA vẫn là đáp án đúng theo bộ đề.)

Ghi nhớ

Các lớp lưu trữ S3 — bảng cần thuộc: | Lớp | Truy xuất | Chi phí lưu | Lưu tối thiểu | |---|---|---|---| | Standard | tức thì | ~0,023 USD/GB | không | | Intelligent-Tiering | tức thì | tự tối ưu + phí giám sát | không | | Standard-IA | tức thì | ~0,0125 USD/GB | 30 ngày | | One Zone-IA | tức thì | ~0,01 USD/GB | 30 ngày | | Glacier Instant Retrieval | MILI GIÂY | ~0,004 USD/GB | 90 ngày | | Glacier Flexible | 1 phút – 12 giờ | ~0,0036 USD/GB | 90 ngày | | Glacier Deep Archive | 12–48 giờ | ~0,00099 USD/GB | 180 ngày |

Ba câu hỏi để chọn đúng lớp:

① Cần truy xuất NHANH đến mức nào?
      Mili giây → Standard, IA, hoặc Glacier Instant Retrieval
      Chờ được → Glacier Flexible hoặc Deep Archive
② Truy cập BAO NHIÊU LẦN?
      Thường xuyên → Standard
      Vài lần mỗi năm → IA hoặc Glacier Instant
③ Mẫu truy cập có ĐOÁN ĐƯỢC không?
      Có → đặt lớp tường minh
      Không → Intelligent-Tiering

Ba yếu tố chi phí thường bị bỏ qua: | Yếu tố | Chi tiết | |---|---| | Kích thước tính phí tối thiểu | 128 KB cho IA — tệp nhỏ bị tính như 128 KB | | Thời gian lưu tối thiểu | xoá sớm vẫn tính đủ | | Phí truy xuất | tích tụ nếu đọc nhiều |

Với hàng trăm TB, hãy kiểm tra kích thước tệp trung bình — nếu nhiều tệp nhỏ hơn 128 KB thì Standard-IA có thể đắt hơn Standard.

Bốn tầng của S3 Intelligent-Tiering: | Tầng | Chuyển sang khi | |---|---| | Frequent Access | mặc định | | Infrequent Access | 30 ngày không truy cập | | Archive Instant Access | 90 ngày không truy cập | | Archive / Deep Archive Access (tuỳ chọn) | 90–730 ngày |

Ưu điểm lớn nhất của Intelligent-Tiering: KHÔNG có phí truy xuất — nên nếu tần suất đọc bất ngờ tăng, hoá đơn không nhảy vọt.

Và với dữ liệu kiểm toán, hãy cân nhắc thêm: | Biện pháp | Lý do | |---|---| | S3 Object Lock chế độ Compliance | không ai xoá được — đáp ứng WORM | | Versioning | chống ghi đè nhầm | | Lifecycle rule | tự chuyển tầng theo tuổi |

Lifecycle rule cho dữ liệu kiểm toán:

{"Rules": [{
  "Status": "Enabled", "Filter": {"Prefix": "bao-cao-kiem-toan/"},
  "Transitions": [
    {"Days": 30, "StorageClass": "STANDARD_IA"},
    {"Days": 730, "StorageClass": "GLACIER_IR"}]}]}

Và ba tối ưu cho việc truy vấn dữ liệu kiểm toán: | Tối ưu | Lợi ích | |---|---| | Chuyển sang Parquet | giảm 80–90% dữ liệu quét khi dùng Athena | | Phân vùng theo kỳ báo cáo | chỉ đọc phân vùng cần | | Nén dữ liệu | giảm chi phí lưu trữ và truy xuất |

Với hàng trăm TB, việc chuyển sang Parquet có thể vừa giảm chi phí lưu trữ vừa giảm chi phí truy vấn.

Ba lưu ý về AWS Step Functions trong kiến trúc của đề: | Lưu ý | Chi tiết | |---|---| | Standard workflow chạy tới 1 NĂM | phù hợp cho quy trình dài | | Có retry và catch dựng sẵn | đúng như đề mô tả | | Tính phí theo số bước chuyển trạng thái | rất rẻ cho quy trình chạy hai lần mỗi năm |

Và một lời khuyên: hãy dùng S3 Storage Class Analysis để đo mẫu truy cập thật trong vài tháng. Với hàng trăm terabyte, chênh lệch giữa các lớp lên tới hàng chục nghìn USD mỗi năm — con số đủ lớn để xứng đáng đo đạc thay vì phỏng đoán.

Đáp án

A — Dùng Amazon Aurora Global Database cho bảng games và dùng Amazon Aurora thường cho bảng users và games_played.

Vì sao đúng

Đề nêu ba ràng buộc, và đáp án thoả cả ba: | Ràng buộc | Giải pháp | |---|---| | Bảng games phải truy cập được TOÀN CẦU | Aurora Global Database — sao chép tới nhiều Region | | Bảng users và games_played chỉ theo TỪNG KHU VỰC | Aurora thường ở mỗi Region | | ÍT sửa mã ứng dụng nhất | ứng dụng ĐÃ dùng Aurora — giữ nguyên SQL và driver |

Vế cuối là điểm phân biệt quyết định:

Ứng dụng hiện tại kết nối Amazon Aurora
    → dùng SQL, driver MySQL hoặc PostgreSQL
        ↓
Giữ Aurora:
    → không đổi mã truy vấn
    → chỉ đổi chuỗi kết nối

Chuyển sang DynamoDB:
    → viết lại TOÀN BỘ tầng truy cập dữ liệu
    → mô hình dữ liệu khác hẳn (không JOIN, không SQL)
    → đây là "refactoring" lớn nhất có thể

Và Aurora Global Database làm đúng việc phân phối toàn cầu:

Region chính (Mỹ):        đọc và GHI bảng games
Region phụ (châu Âu, Á):  ĐỌC bảng games với độ trễ thấp
    → sao chép dưới 1 giây
    → tới 5 Region phụ

Và bảng theo khu vực dùng cluster Aurora riêng ở mỗi Region:

Region châu Âu:  Aurora cluster riêng chứa users và games_played của châu Âu
Region châu Á:   Aurora cluster riêng chứa users và games_played của châu Á
    → dữ liệu người dùng ở lại khu vực → tốt cho tuân thủ

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

• **C. Dùng DynamoDB global table cho games và Aurora cho hai bảng còn lại — đây là phương án gần nhất và DynamoDB global table thực sự là công nghệ đa Region tốt, nhưng nó đòi viết lại mã cho bảng games: chuyển từ SQL sang API của DynamoDB, thiết kế lại khoá, bỏ JOIN. Đề yêu cầu "minimal application refactoring".
• **B. Aurora Global Database cho games và DynamoDB cho hai bảng còn lại — đòi viết lại nhiều hơn nữa: hai bảng phải chuyển sang DynamoDB.
• **D. DynamoDB cho cả ba bảng — viết lại toàn bộ ứng dụng: mọi truy vấn, mọi quan hệ, mọi giao dịch đều phải thiết kế lại.

Ghi nhớ

Aurora Global Database — đặc điểm cần thuộc: | Đặc điểm | Chi tiết | |---|---| | Một Region CHÍNH (ghi) + tới 5 Region phụ (đọc) | | | Độ trễ sao chép | thường DƯỚI 1 GIÂY | | Thăng cấp Region phụ | dưới 1 phút — cho phục hồi thảm hoạ | | Mỗi Region phụ có tới 16 replica đọc | mở rộng đọc cục bộ | | Write forwarding | ghi từ Region phụ, chuyển tiếp về chính |

Write forwarding đơn giản hoá mã ứng dụng rất nhiều:

Ứng dụng ở Region phụ gửi câu lệnh ghi
    → Aurora tự chuyển tiếp về Region chính
    → ứng dụng không cần biết Region nào là chính

Aurora Global Database và DynamoDB Global Tables: | | Aurora Global Database | DynamoDB Global Tables | |---|---|---| | Mô hình dữ liệu | QUAN HỆ, SQL | khoá–giá trị, NoSQL | | Ghi | MỘT Region chính | ĐA CHỦ — ghi ở mọi Region | | Độ trễ sao chép | dưới 1 giây | dưới 1 giây | | Số Region phụ | 5 | không giới hạn cứng | | Giải quyết xung đột | không cần (một nơi ghi) | last writer wins | | Chuyển từ ứng dụng SQL | ✅ không sửa mã | ❌ phải viết lại |

Quy tắc nhận diện:

Đã dùng SQL, cần đa Region, ít sửa mã → Aurora Global Database Cần GHI ở nhiều Region cùng lúc → DynamoDB Global Tables Ứng dụng mới, mô hình khoá–giá trị → DynamoDB

Ba lý do giữ dữ liệu người dùng theo khu vực: | Lý do | Chi tiết | |---|---| | Tuân thủ về vị trí dữ liệu | GDPR và nhiều luật yêu cầu dữ liệu ở lại khu vực | | Độ trễ thấp | người chơi đọc ghi ở Region gần mình | | Giảm chi phí sao chép | không nhân bản dữ liệu không cần chia sẻ |

Dòng đầu là lý do quan trọng nhất — và cũng là lý do đề tách riêng hai loại bảng.

Ba lưu ý khi triển khai Aurora Global Database: | Lưu ý | Chi tiết | |---|---| | Chỉ Region chính GHI được | trừ khi bật write forwarding | | Region phụ có độ trễ sao chép | đọc-sau-ghi nên trỏ về Region chính | | Chi phí nhân theo số Region | instance, lưu trữ, và phí sao chép |

Dòng giữa là vấn đề thực tế: người chơi cập nhật hồ sơ rồi tải lại trang, nếu đọc từ Region phụ chưa kịp đồng bộ thì thấy dữ liệu cũ.

Ba loại endpoint trong kiến trúc toàn cầu: | Endpoint | Dùng cho | |---|---| | Cluster endpoint của Region chính | mọi thao tác GHI | | Reader endpoint của Region địa phương | truy vấn đọc | | Custom endpoint | nhóm instance theo mục đích |

Ba tính năng khác của Aurora đáng biết: | Tính năng | Việc | |---|---| | Backtrack | quay ngược cluster tới 72 giờ | | Cloning copy-on-write | tạo bản sao trong vài phút | | Aurora Serverless v2 | tự co giãn, phù hợp cho Region có tải thấp |

Serverless v2 rất phù hợp cho Region mới mở:

Region châu Á mới ra mắt, ít người chơi
    → Serverless v2 co xuống mức tối thiểu
    → tự bung ra khi lượng người chơi tăng
    → không phải đoán kích thước instance

Ba lưu ý về chi phí Aurora Global Database: | Khoản | Chi tiết | |---|---| | Instance ở mỗi Region | | | Lưu trữ tính riêng ở mỗi Region | dữ liệu được nhân bản | | Phí sao chép xuyên Region | theo số thao tác ghi được sao chép |

Và Aurora I/O-Optimized đáng cân nhắc cho game có tải cao:

Không tính phí I/O, giá compute và lưu trữ cao hơn ~25%
    → có lợi khi chi phí I/O vượt 25% tổng hoá đơn
    → và làm hoá đơn dự đoán được

Và một lời khuyên về kiến trúc dữ liệu game: hãy xem lại xem bảng games có thực sự cần ghi tập trung không. Nếu nó chủ yếu là dữ liệu tham chiếu ít thay đổi (danh mục trò chơi, cấu hình), một lựa chọn còn đơn giản hơn là cache nó ở mỗi Region bằng ElastiCache và chỉ đồng bộ khi có cập nhật — cách đó tránh được cả chi phí lẫn độ phức tạp của Global Database.

Đáp án

B — Dùng Amazon API Gateway kết hợp Amazon Kinesis Data Analytics.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Truy cập qua REST API | API Gateway phơi endpoint REST | | Dữ liệu vị trí có sẵn THỜI GIAN THỰC | Kinesis xử lý luồng với độ trễ mili giây | | Kiến trúc nhiều tầng để lưu và truy xuất | API Gateway (tầng tiếp nhận) + Kinesis (tầng xử lý) |

Kiến trúc đầy đủ:

Xe tải gửi toạ độ GPS
    ↓ HTTPS
API Gateway (REST endpoint)
    ↓ tích hợp TRỰC TIẾP với Kinesis — không cần Lambda
Kinesis Data Streams
    ↓
Kinesis Data Analytics (Managed Service for Apache Flink)
    → tính toán trên cửa sổ thời gian: tốc độ trung bình,
      phát hiện đi sai tuyến, thời gian dừng
    ↓
Nền tảng phân tích (dashboard, cảnh báo)

Và API Gateway tích hợp TRỰC TIẾP với Kinesis — không cần Lambda ở giữa:

{"type": "AWS",
 "uri": "arn:aws:apigateway:ap-southeast-1:kinesis:action/PutRecord",
 "requestTemplates": {"application/json":
   "{\"StreamName\":\"vi-tri-xe-tai\",\"Data\":\"$util.base64Encode($input.body)\",\"PartitionKey\":\"$input.path('$.maXe')\"}"}}

Đây gọi là service integration — bỏ được cả một tầng, giảm độ trễ và chi phí.

Và Kinesis Data Analytics cho phép phân tích bằng SQL trên luồng:

SELECT STREAM ma_xe,
       AVG(toc_do) OVER (PARTITION BY ma_xe
                         RANGE INTERVAL '5' MINUTE PRECEDING) AS toc_do_tb
FROM "LUONG_NGUON";

Không phải viết ứng dụng consumer nào.

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

• **D. Dùng API Gateway với AWS Lambda — đây là phương án gần nhất và là kiến trúc rất phổ biến, nhưng nó thiếu tầng phân tích thời gian thực: Lambda xử lý từng request độc lập, nó không tính toán trên cửa sổ thời gian hay tổng hợp theo luồng. Đề nói rõ "accessible in real-time in its analytics platform".
• **A. QuickSight với Redshift — không phải thời gian thực: Redshift là kho dữ liệu cho phân tích theo lô, độ trễ truy vấn tính bằng giây. Và không có tầng nào tiếp nhận dữ liệu từ xe tải.
• **C. Athena với S3 — cũng là phân tích trên dữ liệu đã lưu, không phải luồng thời gian thực. Và thiếu tầng REST API.

Ghi nhớ

Bốn dịch vụ trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Data Streams | hàng đợi luồng, phát lại được, nhiều consumer | | Data Firehose | giao dữ liệu tự động vào S3, Redshift, OpenSearch | | Managed Service for Apache Flink (trước là Data Analytics) | phân tích luồng bằng SQL hoặc Flink | | Video Streams | video và âm thanh |

Quy tắc nhận diện:

"real-time analytics", "windowed aggregation", "streaming SQL" → Kinesis Data Analytics / Flink "ingest stream", "multiple consumers", "replay" → Data Streams "deliver to S3 without code" → Firehose

Ba loại tích hợp của API Gateway: | Loại | Đặc điểm | |---|---| | Lambda | phổ biến nhất, chạy mã tuỳ ý | | AWS Service (direct integration) | gọi THẲNG Kinesis, SQS, DynamoDB, Step Functions | | HTTP | proxy tới endpoint bên ngoài | | Mock | trả về phản hồi cố định |

Direct integration đáng dùng khi không cần logic phức tạp: | Lợi ích | Chi tiết | |---|---| | Bỏ được một tầng | ít thành phần hơn | | Không có cold start | độ trễ thấp hơn | | Rẻ hơn | không trả phí Lambda |

Ba loại cửa sổ trong phân tích luồng: | Loại | Ý nghĩa | |---|---| | Tumbling window | cửa sổ cố định, không chồng lấn — "mỗi 5 phút" | | Sliding window | cửa sổ trượt, chồng lấn | | Session window | nhóm theo phiên hoạt động |

Với theo dõi xe tải, tumbling window 5 phút là lựa chọn tự nhiên.

Ba cách chọn partition key cho Kinesis: | Cách | Hệ quả | |---|---| | Mã xe tải | thứ tự được giữ cho từng xe, phân tán đều ← đúng nhất | | Mã khu vực | có thể gây hot shard nếu một khu vực đông | | Ngẫu nhiên | phân tán tốt nhưng mất thứ tự |

Kiến trúc đầy đủ cho theo dõi phương tiện:

Xe tải → API Gateway (hoặc AWS IoT Core)
    ↓
Kinesis Data Streams
    ├─▶ Flink: phát hiện bất thường → cảnh báo qua SNS
    ├─▶ Lambda → DynamoDB: vị trí HIỆN TẠI, truy vấn nhanh
    └─▶ Firehose → S3 → Athena: phân tích lịch sử

Và AWS IoT Core đáng cân nhắc thay API Gateway cho thiết bị: | | API Gateway | AWS IoT Core | |---|---|---| | Giao thức | HTTPS | MQTT — nhẹ, tiết kiệm pin và băng thông | | Xác thực thiết bị | API key, IAM | chứng chỉ X.509 cho từng thiết bị | | Khi thiết bị mất mạng | request thất bại | device shadow giữ trạng thái | | Rule engine | ❌ | ✅ định tuyến thẳng vào Kinesis |

Với xe tải chạy qua vùng sóng yếu, MQTT và device shadow là ưu điểm thật.

Ba lưu ý về thông lượng: | Yếu tố | Giới hạn | |---|---| | Một shard Kinesis | 1 MB/giây hoặc 1.000 bản ghi/giây | | API Gateway | 10.000 request/giây mặc định (tăng được) | | Flink | theo số Kinesis Processing Unit |

Phép tính cho đề:

1.000 xe × 1 bản ghi mỗi 5 giây = 200 bản ghi/giây
    → một shard là đủ
    → nhưng nên dùng chế độ ON-DEMAND vì đội xe sẽ tăng

Ba tính năng của API Gateway nên bật: | Tính năng | Lý do | |---|---| | Throttling | bảo vệ Kinesis khỏi tăng tải đột ngột | | Request validation | loại bỏ payload sai định dạng sớm | | API key hoặc IAM auth | chỉ thiết bị hợp lệ gửi được dữ liệu |

Và một lời khuyên về chi phí: Kinesis Data Analytics tính phí theo Kinesis Processing Unit-giờ, và nó chạy liên tục. Với ứng dụng chỉ cần phân tích trong giờ hoạt động cao điểm như đề mô tả, hãy cân nhắc dừng ứng dụng Flink ngoài giờ — hoặc dùng Lambda cho các phép tính đơn giản và chỉ dùng Flink khi thực sự cần cửa sổ thời gian.

Đáp án

D — Tạo CloudWatch metric filter xử lý log CloudTrail chứa chi tiết lời gọi API và đếm các mã lỗi cần theo dõi; tạo alarm dựa trên tỷ lệ của metric đó để gửi thông báo SNS.

Vì sao đúng

Đề cần cảnh báo GẦN THỜI GIAN THỰC khi có nhiều lời gọi API bất hợp lệ — và metric filter là cách chuẩn để biến mẫu trong log thành metric có thể đặt alarm.

Luồng đầy đủ:

CloudTrail ghi mọi lời gọi API
    ↓ gửi sang CloudWatch Logs
Metric filter quét log tìm mã lỗi
    ↓ mỗi lần khớp → tăng metric tuỳ chỉnh
CloudWatch alarm theo dõi TỶ LỆ của metric
    ↓ vượt ngưỡng
SNS → thông báo cho đội bảo mật

Bước bắt buộc: đưa CloudTrail sang CloudWatch Logs.

aws cloudtrail update-trail --name theo-doi-api   --cloud-watch-logs-log-group-arn <arn-log-group>   --cloud-watch-logs-role-arn <arn-role>

Metric filter bắt các mã lỗi:

aws logs put-metric-filter --log-group-name /aws/cloudtrail   --filter-name loi-goi-api-that-bai   --filter-pattern '{($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*")}'   --metric-transformations       metricName=SoLoiTruyCap,metricNamespace=BaoMat,metricValue=1

Và alarm dựa trên TỶ LỆ chứ không phải con số tuyệt đối:

aws cloudwatch put-metric-alarm --alarm-name canh-bao-goi-api-bat-hop-le   --metric-name SoLoiTruyCap --namespace BaoMat   --statistic Sum --period 300 --threshold 50   --comparison-operator GreaterThanThreshold --evaluation-periods 1   --alarm-actions <arn-sns> --treat-missing-data notBreaching

Vì sao dùng tỷ lệ: một vài lỗi AccessDenied là bình thường (ứng dụng thử quyền, người dùng gõ nhầm). Đột biến về SỐ LƯỢNG mới là dấu hiệu bất thường.

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

• **A. Chạy truy vấn Athena trên log CloudTrail trong S3 và dùng QuickSight dựng dashboard — đây là phương án gần nhất và rất tốt cho PHÂN TÍCH SÂU, nhưng nó không phải cảnh báo gần thời gian thực: Athena là truy vấn theo yêu cầu, và dashboard cần người ngồi xem. Đề yêu cầu "trigger near-real-time warnings".
• **B. Dùng Trusted Advisor theo dõi kiểm tra Service Limits — sai loại vấn đề: Service Limits cảnh báo khi mức dùng tài nguyên tiến gần hạn mức. Nó không liên quan tới lời gọi API bất hợp lệ.
• **C. Đưa CloudTrail sang Kinesis và dùng metric mức stream để kích hoạt Lambda — metric của Kinesis không biết gì về nội dung: chúng đo thông lượng và độ trễ của stream, không phân tích được mã lỗi trong từng bản ghi.

Ghi nhớ

Ba cách phân tích log CloudTrail — mỗi cách một mục đích: | Cách | Đặc điểm | Phù hợp | |---|---|---| | Metric filter + alarm | gần thời gian thực, tự động | CẢNH BÁO ← câu này | | Athena trên bucket log | truy vấn SQL linh hoạt | ĐIỀU TRA sâu | | CloudTrail Lake | truy vấn SQL, giữ tới 10 năm | điều tra, không cần dựng Athena | | Event history (Console) | 90 ngày gần đây, không cần trail | tra cứu nhanh |

Cú pháp filter pattern cho log JSON: | Mẫu | Khớp với | |---|---| | { $.errorCode = "AccessDenied" } | trường errorCode bằng giá trị đó | | { $.errorCode = "*Unauthorized*" } | chứa chuỗi | | { ($.a = "x") \|\| ($.b = "y") } | HOẶC | | { ($.a = "x") && ($.b > 5) } | VÀ |

Với log JSON, mẫu { $.field = value } chính xác hơn nhiều so với khớp chuỗi thô.

Các mã lỗi CloudTrail đáng theo dõi: | Mã lỗi | Ý nghĩa | |---|---| | AccessDenied | không có quyền — dấu hiệu dò quét | | UnauthorizedOperation | tương tự, cho EC2 | | Client.UnauthorizedOperation | | | SignatureDoesNotMatch | thông tin đăng nhập sai | | InvalidClientTokenId | access key không tồn tại |

Ba alarm bảo mật nên có cho mọi tài khoản: | Alarm | Mẫu | |---|---| | Đăng nhập bằng tài khoản ROOT | { $.userIdentity.type = "Root" } | | Thay đổi IAM policy | { ($.eventName = Put*Policy) \|\| ($.eventName = Delete*Policy) } | | Tắt CloudTrail | { $.eventName = "StopLogging" } | | Thay đổi security group | { $.eventName = "AuthorizeSecurityGroupIngress" } | | Đăng nhập console thất bại nhiều lần | { $.eventName = "ConsoleLogin" && $.errorMessage = "Failed*" } |

Và AWS có sẵn bộ alarm khuyến nghị — tài liệu CIS AWS Foundations Benchmark liệt kê đầy đủ.

Ba cấu hình alarm quan trọng: | Cấu hình | Chi tiết | |---|---| | treat-missing-data notBreaching | metric đếm lỗi không có dữ liệu = tốt, không phải thiếu dữ liệu | | evaluation-periods | số chu kỳ liên tiếp vượt ngưỡng | | datapoints-to-alarm | M trong N chu kỳ |

Dòng đầu quan trọng với metric filter đếm lỗi — không đặt thì alarm sẽ ở trạng thái INSUFFICIENT_DATA khi mọi thứ bình thường.

Và có công cụ chuyên dụng hơn cho phát hiện đe doạ: Amazon GuardDuty.

GuardDuty:
    ✓ tự phân tích CloudTrail, VPC Flow Logs, DNS logs
    ✓ dùng học máy và tình báo mối đe doạ
    ✓ phát hiện mẫu tấn công đã biết
    ✓ KHÔNG cần cấu hình metric filter nào

Các finding của GuardDuty liên quan tới lời gọi API bất thường: | Finding | Ý nghĩa | |---|---| | Discovery:IAMUser/AnomalousBehavior | hành vi dò quét bất thường | | UnauthorizedAccess:IAMUser/MaliciousIPCaller | gọi từ IP độc hại đã biết | | CredentialAccess:IAMUser/AnomalousBehavior | truy cập thông tin đăng nhập bất thường | | Recon:IAMUser/MaliciousIPCaller | trinh sát từ IP xấu |

GuardDuty là lựa chọn ít công hơn nhiều — bật một công tắc thay vì viết từng metric filter. (Đáp án D vẫn đúng theo bộ đề và cho kiểm soát chi tiết hơn về ngưỡng.)

Ba loại sự kiện của CloudTrail: | Loại | Ghi gì | Chi phí | |---|---|---| | Management event | thao tác trên tài nguyên | miễn phí cho bản sao đầu | | Data event | thao tác trên dữ liệu (s3:GetObject) | có phí, khối lượng lớn | | Insights event | phát hiện hoạt động API BẤT THƯỜNG | có phí |

CloudTrail Insights đáng biết cho tình huống này:

Insights tự học mẫu hoạt động API bình thường
    → phát hiện đột biến về tốc độ gọi hoặc tỷ lệ lỗi
    → phát finding vào EventBridge
    → không cần đặt ngưỡng thủ công

Bốn thực hành tốt khi cấu hình CloudTrail: | Thực hành | Lý do | |---|---| | Trail cho TOÀN BỘ Region | hoạt động ở Region lạ vẫn bị ghi | | Ghi vào bucket ở TÀI KHOẢN RIÊNG | kẻ tấn công không xoá được dấu vết | | Bật log file validation | chứng minh log toàn vẹn | | Organization trail | một trail cho mọi tài khoản |

Và một lời khuyên về chi phí: CloudWatch Logs tính phí theo dữ liệu nạp vào (~0,50 USD/GB), và log CloudTrail của tài khoản lớn có thể rất nhiều. Hãy chỉ đưa management event sang CloudWatch Logs cho mục đích cảnh báo, còn data event thì để nguyên ở S3 và truy vấn bằng Athena khi cần điều tra.

Đáp án

A và C.

• A — Dùng VPC security group để kiểm soát lưu lượng vào và ra khỏi file system
• C — Dùng IAM policy để kiểm soát client nào được mount file system với quyền gì

Vì sao đúng

EFS có hai tầng kiểm soát truy cập độc lập, và hai đáp án là hai tầng đó: | Tầng | Cơ chế | Kiểm soát | |---|---|---| | Mạng | security group của mount target | máy nào KẾT NỐI được tới EFS | | Danh tính | IAM policy | ai được MOUNT và với quyền gì |

A — security group là tầng bảo vệ đầu tiên:

EFS có MOUNT TARGET ở mỗi AZ, mỗi cái là một ENI
    → gắn security group vào mount target
    → chỉ cho phép cổng 2049 (NFS) từ security group của EC2 được phép

aws ec2 authorize-security-group-ingress --group-id sg-mount-target   --protocol tcp --port 2049 --source-group sg-may-chu-ung-dung

Tham chiếu theo SECURITY GROUP thay vì IP — instance mới trong Auto Scaling group tự động được phép.

C — và IAM policy kiểm soát ở tầng danh tính:

{"Effect": "Allow",
 "Action": ["elasticfilesystem:ClientMount",
            "elasticfilesystem:ClientWrite"],
 "Resource": "arn:aws:elasticfilesystem:*:*:file-system/fs-0abc123",
 "Condition": {"Bool": {"elasticfilesystem:AccessedViaMountTarget": "true"}}}

Ba quyền IAM của EFS: | Quyền | Việc | |---|---| | ClientMount | được mount (đọc) | | ClientWrite | được ghi | | ClientRootAccess | truy cập với quyền root — cấp rất hạn chế |

Và mount với IAM authorization:

sudo mount -t efs -o tls,iam fs-0abc123:/ /du-lieu

Hai tầng này bổ sung nhau — đó là lý do câu hỏi yêu cầu chọn hai.

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

• **B. Dùng network ACL để kiểm soát lưu lượng tới EC2 instance — đây là phương án gần nhất vì NACL cũng là cơ chế lọc mạng, nhưng nó kém phù hợp: NACL áp cho cả subnet và chỉ lọc theo CIDR — không tham chiếu được security group. Với instance do Auto Scaling tạo, IP thay đổi liên tục nên rule theo CIDR khó duy trì.
• **D. Dùng thông tin đăng nhập root của IAM policy để cấu hình client — không có cơ chế như vậy: "IAM policy root credentials" không phải khái niệm có thật. Và dùng tài khoản root cho việc hằng ngày là thực hành bảo mật rất kém.
• **E. Dùng Amazon GuardDuty để ngăn truy cập không mong muốn — GuardDuty PHÁT HIỆN, không NGĂN CHẶN: nó phân tích log và báo hành vi đáng ngờ, nhưng không chặn kết nối nào.

Ghi nhớ

Ba tầng kiểm soát truy cập EFS: | Tầng | Cơ chế | Kiểm soát | |---|---|---| | Mạng | security group của mount target | máy nào kết nối được | | Danh tính | IAM policy + file system policy | ai mount được, quyền gì | | Hệ thống tệp | quyền POSIX + EFS Access Point | ai đọc ghi được thư mục nào |

Tầng thứ ba đáng chú ý — EFS Access Point:

aws efs create-access-point --file-system-id fs-0abc123   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/du-lieu-nhom-a,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=750}'

Và file system policy là resource policy của EFS:

{"Statement": [{
  "Effect": "Deny",
  "Principal": {"AWS": "*"},
  "Action": "*",
  "Condition": {"Bool": {"elasticfilesystem:AccessedViaMountTarget": "false"}}},
 {"Effect": "Deny",
  "Principal": {"AWS": "*"},
  "Action": "*",
  "Condition": {"Bool": {"aws:SecureTransport": "false"}}}]}

Statement thứ hai BẮT BUỘC mã hoá đường truyền — tương tự aws:SecureTransport của S3.

Ba cấu hình bảo mật nên có cho EFS: | Cấu hình | Chi tiết | |---|---| | Mã hoá at rest | bật LÚC TẠO file system (KMS) | | Mã hoá in transit | tuỳ chọn -o tls khi mount | | File system policy bắt buộc TLS | không phụ thuộc client có nhớ khai hay không |

Mã hoá at rest KHÔNG bật được sau khi tạo — phải tạo file system mới và chuyển dữ liệu.

Ba lưu ý về mount target: | Lưu ý | Chi tiết | |---|---| | Một mount target MỖI AZ | thiếu thì máy ở AZ đó trả phí truyền chéo AZ | | Mỗi mount target là một ENI có IP riêng | gắn security group vào đây | | Mount target ở private subnet | không phơi ra Internet |

Và cổng NFS là 2049 — con số cần nhớ.

Ba loại chính sách áp cho EFS: | Loại | Gắn vào | Việc | |---|---|---| | IAM identity policy | user, role | client nào được mount | | EFS file system policy | file system | resource policy — bắt buộc TLS, chặn truy cập ngoài | | Access point policy | qua IAM với điều kiện access point | phân quyền theo nhóm |

Và EFS hỗ trợ truy cập xuyên tài khoản qua file system policy — hữu ích khi nhiều tài khoản dùng chung dữ liệu.

Ba lưu ý khi mount EFS từ EC2: | Lưu ý | Chi tiết | |---|---| | Cài amazon-efs-utils | để dùng được -t efs và tuỳ chọn tls, iam | | Thêm vào /etc/fstab | để mount lại sau khi khởi động | | Instance cần IAM role | nếu dùng IAM authorization |

fs-0abc123:/ /du-lieu efs _netdev,tls,iam 0 0

Và với truy cập từ tại chỗ, EFS mount được qua Direct Connect hoặc VPN — nhưng cần mở cổng 2049 và có đường mạng tới mount target.

Ba công cụ giám sát truy cập EFS: | Công cụ | Việc | |---|---| | CloudTrail | ghi thao tác quản trị (tạo, xoá, sửa cấu hình) | | VPC Flow Logs | thấy máy nào kết nối tới mount target | | CloudWatch metric | ClientConnections, TotalIOBytes |

Lưu ý: CloudTrail KHÔNG ghi thao tác đọc ghi tệp — khác với S3 data event. Muốn audit ở mức tệp thì phải dùng công cụ ở tầng hệ điều hành.

Và một lời khuyên: hãy dùng EFS Access Point cho mỗi ứng dụng thay vì cho mọi instance mount thư mục gốc. Nó vừa cách ly dữ liệu giữa các ứng dụng, vừa loại bỏ việc phải đồng bộ uid và gid giữa các máy — một nguồn lỗi phổ biến với NFS.

Đáp án

C — Dùng permissions boundary để kiểm soát mức quyền TỐI ĐA mà nhân viên có thể cấp cho các IAM principal.

Vì sao đúng

Đề nêu vấn đề rõ: lập trình viên mới được cấp toàn quyền DynamoDB và vô tình xoá bảng sản xuất.

Và permissions boundary đặt TRẦN quyền cho một thực thể:

Permissions boundary là một policy gắn vào IAM user hoặc role
    → nó KHÔNG cấp quyền
    → nó GIỚI HẠN mức quyền tối đa mà thực thể đó có thể có
        ↓
Quyền hiệu lực = GIAO của (identity policy) và (permissions boundary)

Ví dụ cho tình huống này:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Action": ["dynamodb:GetItem", "dynamodb:PutItem",
               "dynamodb:UpdateItem", "dynamodb:Query", "dynamodb:Scan"],
    "Resource": "*"},
   {"Effect": "Deny",
    "Action": ["dynamodb:DeleteTable", "dynamodb:CreateTable",
               "dynamodb:UpdateTable"],
    "Resource": "*"}]}

Dù ai đó gắn AmazonDynamoDBFullAccess cho lập trình viên, họ vẫn KHÔNG xoá được bảng.

aws iam put-user-permissions-boundary   --user-name lap-trinh-vien-moi   --permissions-boundary arn:aws:iam::123456789012:policy/ranh-gioi-lap-trinh-vien

Và permissions boundary còn giải quyết một vấn đề sâu hơn: uỷ quyền an toàn.

Cho phép trưởng nhóm TỰ TẠO IAM role cho ứng dụng
    → nhưng BẮT BUỘC mọi role họ tạo phải gắn permissions boundary
    → họ không thể tạo ra role có quyền vượt trần

{"Effect": "Allow", "Action": "iam:CreateRole", "Resource": "*",
 "Condition": {"StringEquals":
   {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/ranh-gioi-lap-trinh-vien"}}}

Đây chính là "control the MAXIMUM permissions employees can GRANT to IAM principals" mà đề nêu.

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

• **B. Gỡ toàn quyền database cho MỌI IAM user trong tổ chức — đây là phương án gần nhất và có ngăn được sự cố, nhưng nó quá thô và không bền vững: một số vai trò thật sự cần toàn quyền (quản trị viên database, quy trình tự động). Và nó không có cơ chế nào ngăn ai đó cấp lại quyền đó sau này.
• **A. Chỉ tài khoản root mới có toàn quyền database — thực hành rất kém: AWS khuyến nghị không dùng root cho việc hằng ngày. Và nó tạo ra nút thắt vận hành.
• **D. CTO xem xét quyền của từng lập trình viên mới — không mở rộng được và phụ thuộc con người: quy trình thủ công sẽ thất bại khi tổ chức lớn lên, và một lần sơ suất là sự cố tái diễn.

Ghi nhớ

Bốn cơ chế giới hạn quyền trên AWS — bảng cần thuộc: | Cơ chế | Áp cho | Đặc điểm | |---|---|---| | Identity policy | user, group, role | CẤP quyền | | Permissions boundary | một user hoặc role cụ thể | GIỚI HẠN trần quyền của thực thể đó | | Service Control Policy (SCP) | tài khoản hoặc OU | giới hạn trần cho CẢ TÀI KHOẢN | | Session policy | phiên AssumeRole | giới hạn cho một phiên |

Công thức quyền hiệu lực:

Quyền = (identity policy) ∩ (permissions boundary) ∩ (SCP) ∩ (session policy)
        và KHÔNG có explicit Deny nào ở bất kỳ tầng nào

Chỉ cần một tầng không cho phép là hành động bị từ chối.

Permissions boundary và SCP — chọn cái nào: | | Permissions boundary | SCP | |---|---|---| | Phạm vi | một IAM user hoặc role | CẢ tài khoản hoặc OU | | Yêu cầu Organizations | ❌ | ✅ | | Ảnh hưởng root của tài khoản | ❌ | ✅ | | Phù hợp | uỷ quyền cho lập trình viên trong một tài khoản | ranh giới ở cấp tổ chức |

Với tình huống trong đề — một tổ chức, cần giới hạn quyền lập trình viên — permissions boundary là công cụ đúng.

Ba trường hợp dùng permissions boundary: | Trường hợp | Chi tiết | |---|---| | Uỷ quyền tạo IAM role an toàn | lập trình viên tự tạo role cho ứng dụng nhưng không vượt trần | | Giới hạn quyền của lập trình viên | ← câu này | | Ngăn nâng quyền (privilege escalation) | không tự cấp thêm quyền cho mình |

Và ngăn nâng quyền là lý do quan trọng nhất:

Không có boundary:
    Lập trình viên có iam:AttachUserPolicy
        → tự gắn AdministratorAccess cho mình
        → thành quản trị viên

Có boundary:
    → quyền vẫn bị giới hạn bởi trần
    → gắn policy gì cũng không vượt được

Ba biện pháp bổ sung nên có: | Biện pháp | Chi tiết | |---|---| | Tách TÀI KHOẢN cho dev và production | cách ly tuyệt đối, mạnh hơn mọi policy | | Bật DeletionProtectionEnabled cho bảng DynamoDB | chặn xoá ngay ở tầng dịch vụ | | Bật point-in-time recovery | khôi phục được nếu vẫn xảy ra |

Deletion protection của DynamoDB đáng bật cho mọi bảng sản xuất:

aws dynamodb update-table --table-name bang-san-xuat   --deletion-protection-enabled

Đây là biện pháp đơn giản nhất và hiệu quả trực tiếp cho đúng sự cố trong đề.

Và point-in-time recovery là lưới an toàn cuối cùng:

aws dynamodb update-continuous-backups --table-name bang-san-xuat   --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Khôi phục về bất kỳ giây nào trong 35 ngày — nhưng lưu ý: PITR không cứu được bảng đã bị xoá nếu không có backup. Deletion protection quan trọng hơn.

Ba mức cách ly môi trường — từ yếu tới mạnh: | Mức | Cách ly | |---|---| | Thẻ + IAM condition (ABAC) | logic, trong một tài khoản | | Permissions boundary | trần quyền cho từng người | | TÀI KHOẢN riêng cho prod và non-prod | tuyệt đối |

AWS khuyến nghị tách tài khoản cho ranh giới prod và non-prod — với Organizations và Control Tower, việc này không còn phức tạp.

Ba công cụ hỗ trợ áp dụng quyền tối thiểu: | Công cụ | Việc | |---|---| | IAM Access Analyzer policy generation | sinh policy từ hoạt động THẬT trong CloudTrail | | Access Advisor | dịch vụ nào thực sự được dùng gần đây | | IAM Policy Simulator | thử một hành động và xem lý do |

Access Advisor rất hữu ích để thu hẹp quyền hiện có:

Xem lập trình viên đã dùng dịch vụ nào trong 90 ngày qua
    → gỡ quyền cho các dịch vụ chưa từng chạm tới

Và một lời khuyên về quy trình onboarding: hãy định nghĩa sẵn permission set hoặc group cho từng vai trò (lập trình viên, quản trị viên hạ tầng, kiểm toán) và gắn permissions boundary tương ứng. Khi có người mới, thêm họ vào group — không ai phải quyết định cấp quyền gì, và không ai vô tình cấp quá tay.

Đáp án

C — Lưu kết quả truy vấn trung gian trong Amazon S3 Standard.

Vì sao đúng

Đề cho một con số quyết định: dữ liệu chỉ giữ 24 GIỜ.

Và mọi lớp rẻ hơn đều có RÀNG BUỘC THỜI GIAN LƯU TỐI THIỂU: | Lớp | Lưu tối thiểu | |---|---| | S3 Standard | KHÔNG có | | Standard-IA | 30 ngày | | One Zone-IA | 30 ngày | | Glacier Instant Retrieval | 90 ngày |

Nên với dữ liệu tồn tại 24 giờ:

Đưa vào One Zone-IA:
    → xoá sau 1 ngày
    → VẪN BỊ TÍNH PHÍ ĐỦ 30 NGÀY
    → đắt hơn Standard khoảng 13 lần cho cùng lượng dữ liệu

Và đề còn nêu một dữ kiện thứ hai loại các lớp IA:

"These results are HEAVILY REFERENCED by other parts of the analytics pipeline"
    ↓
    Truy cập THƯỜNG XUYÊN
    → các lớp Infrequent Access có PHÍ TRUY XUẤT mỗi GB
    → đọc nhiều lần thì phí truy xuất tích tụ rất nhanh

S3 Standard không có cả hai vấn đề:

✓ Không có thời gian lưu tối thiểu
✓ KHÔNG có phí truy xuất
✓ Trả tiền theo GB-giờ thực tế

Và nên đặt lifecycle rule tự dọn:

{"Rules": [{
  "ID": "xoa-ket-qua-trung-gian",
  "Status": "Enabled",
  "Filter": {"Prefix": "vung-tam/"},
  "Expiration": {"Days": 1}}]}

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

• **B. S3 One Zone-IA — đây là phương án gần nhất vì giá lưu trữ mỗi GB rẻ nhất trong các lớp truy cập tức thì, nhưng nó sai ở hai điểm: ràng buộc 30 ngày khiến dữ liệu 24 giờ bị tính phí gấp 30 lần thời gian thật, và phí truy xuất cộng thêm với dữ liệu được đọc nhiều.
• **A. S3 Standard-IA — cùng hai vấn đề, và giá lưu trữ còn cao hơn One Zone-IA.
• **D. Glacier Instant Retrieval — tệ hơn nữa: ràng buộc 90 ngày và phí truy xuất cao nhất trong các lớp truy cập tức thì.

Ghi nhớ

Bảng ràng buộc của các lớp lưu trữ — nội dung cốt lõi: | Lớp | Lưu tối thiểu | Phí truy xuất | Kích thước tính phí tối thiểu | |---|---|---|---| | Standard | không | KHÔNG | không | | Standard-IA | 30 ngày | có | 128 KB | | One Zone-IA | 30 ngày | có | 128 KB | | Glacier Instant Retrieval | 90 ngày | cao | 128 KB | | Glacier Flexible | 90 ngày | cao | 40 KB | | Glacier Deep Archive | 180 ngày | cao nhất | 40 KB | | Intelligent-Tiering | không | KHÔNG | không (có phí giám sát) |

Hai cột đầu là nguyên nhân khiến "lớp rẻ hơn" thường đắt hơn cho dữ liệu ngắn hạn.

Ba câu hỏi để chọn đúng lớp:

① Dữ liệu tồn tại BAO LÂU?
      Dưới 30 ngày → Standard (không có lựa chọn khác hợp lý)
② Đọc BAO NHIÊU LẦN?
      Nhiều → tránh lớp có phí truy xuất
③ Cần truy xuất NHANH đến mức nào?
      Tức thì → Standard, IA, Glacier Instant Retrieval

Đề này trả lời "dưới 30 ngày" và "đọc nhiều" — cả hai đều dẫn tới Standard.

Và Intelligent-Tiering đáng cân nhắc khi không chắc:

Intelligent-Tiering:
    ✓ KHÔNG có thời gian lưu tối thiểu
    ✓ KHÔNG có phí truy xuất
    ✗ có phí giám sát nhỏ theo object
        ↓
    Với dữ liệu 24 giờ, phí giám sát là chi phí thừa
    → Standard vẫn rẻ hơn

Ba lưu ý về chi phí S3 thường bị bỏ qua: | Khoản | Chi tiết | |---|---| | Phí REQUEST | ~0,005 USD mỗi 1.000 PUT | | Phí truyền dữ liệu RA Internet | ~0,09 USD/GB | | Phần multipart dở dang | tính phí mãi mãi, không hiện trong danh sách |

Với đường ống phân tích ghi hàng triệu tệp nhỏ, phí request có thể vượt phí lưu trữ.

Và lifecycle rule bắt buộc cho mọi bucket:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Ba tối ưu cho vùng tạm của đường ống phân tích: | Tối ưu | Lợi ích | |---|---| | Gộp kết quả thành tệp LỚN | giảm phí request và tăng tốc đọc | | Dùng định dạng Parquet | giảm dung lượng và tăng tốc truy vấn | | Nén dữ liệu | giảm cả lưu trữ lẫn băng thông |

Và lifecycle expiration có độ phân giải theo NGÀY:

Giá trị nhỏ nhất là 1 ngày
    → không xoá được chính xác sau 24 giờ
    → và lifecycle chạy MỘT LẦN mỗi ngày, có thể chậm vài giờ

Nếu cần xoá chính xác hơn:

EventBridge Scheduler → Lambda xoá theo tag hoặc thời gian tạo
    → kiểm soát chính xác hơn lifecycle rule

Ba lựa chọn khác cho dữ liệu trung gian: | Lựa chọn | Phù hợp | |---|---| | S3 Standard + lifecycle | đơn giản nhất, phổ biến nhất ← câu này | | S3 Express One Zone | độ trễ thấp nhất, cho truy cập rất nóng — đắt hơn | | EFS hoặc FSx for Lustre | khi cần ngữ nghĩa hệ thống tệp |

S3 Express One Zone đáng biết: nó cho độ trễ thấp hơn Standard tới 10 lần, phù hợp cho dữ liệu trung gian được đọc rất nhiều trong đường ống phân tích — đổi lại giá lưu trữ cao hơn nhưng phí request rẻ hơn nhiều.

Ba lưu ý khi thiết kế vùng tạm (staging zone) của data lake: | Lưu ý | Chi tiết | |---|---| | Tách prefix riêng cho vùng tạm | dễ áp lifecycle mà không đụng dữ liệu chính | | Đặt lifecycle NGAY khi tạo bucket | tránh tích tụ | | Giám sát dung lượng bằng S3 Storage Lens | phát hiện vùng tạm phình to bất thường |

Và một lời khuyên: hãy dùng S3 Storage Lens để xem phân bố dung lượng theo prefix và theo lớp lưu trữ. Với data lake hàng petabyte, vùng tạm không được dọn là nguồn lãng phí lớn mà rất khó phát hiện nếu chỉ nhìn tổng chi phí.

Đáp án

C — Cấu hình Auto Scaling group dùng target tracking policy với metric là CPU utilization và giá trị mục tiêu 50%.

Vì sao đúng

Đề mô tả chính xác cơ chế của target tracking: giữ một metric ở một GIÁ TRỊ MỤC TIÊU.

Và đội ngũ đã xác định được con số đó:

"functions at its PEAK PERFORMANCE when CPU utilization is about 50%"
    ↓
    → biết chính xác giá trị mong muốn
    → đó là đầu vào duy nhất mà target tracking cần

Cách target tracking hoạt động:

Bạn khai: giữ CPU trung bình ở 50%
    ↓
Auto Scaling tự:
    ✓ tạo và quản lý CloudWatch alarm
    ✓ tính toán cần thêm hoặc bớt bao nhiêu instance
    ✓ điều chỉnh liên tục để metric bám sát mục tiêu

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung   --policy-name giu-cpu-50 --policy-type TargetTrackingScaling   --estimated-instance-warmup 300   --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Và target tracking có hai hành vi thông minh dựng sẵn: | Hành vi | Chi tiết | |---|---| | Mở rộng NHANH, thu hẹp THẬN TRỌNG | tránh cắt dung lượng quá tay | | Tự chống dao động | không thêm bớt liên tục quanh ngưỡng |

AWS khuyến nghị target tracking cho hầu hết trường hợp — nó đơn giản nhất và ít sai sót nhất.

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

• **A. Dùng step scaling với CPU làm metric mục tiêu và giá trị 50% — đây là phương án gần nhất và cũng co giãn theo CPU, nhưng nó hiểu sai cơ chế: step scaling không có khái niệm "target value". Nó cần bạn khai ngưỡng alarm và các BẬC điều chỉnh (vượt 10% thì thêm 2 máy, vượt 25% thì thêm 4 máy). Cụm từ "target metric with a target value" thuộc về target tracking.
• **D. Dùng simple scaling với giá trị mục tiêu 50% — cùng lỗi khái niệm, và simple scaling còn là loại policy cũ: nó chỉ có một hành động và phải chờ hết cooldown trước khi phản ứng tiếp.
• **B. Dùng CloudWatch alarm kích hoạt ở ngưỡng CPU 50% — alarm chỉ QUAN SÁT, không HÀNH ĐỘNG: nó cần được gắn với một scaling policy thì mới co giãn được. Bản thân alarm không thêm bớt instance nào.

Ghi nhớ

Năm loại scaling policy — bảng cần thuộc: | Loại | Bạn khai gì | Đặc điểm | |---|---|---| | Target tracking | MỘT giá trị mục tiêu | AWS tự lo phần còn lại — đơn giản nhất ← câu này | | Step scaling | ngưỡng + nhiều BẬC điều chỉnh | kiểm soát chi tiết | | Simple scaling | ngưỡng + một hành động | cũ, chậm vì cooldown | | Scheduled scaling | thời điểm và dung lượng | mẫu tải biết trước theo giờ | | Predictive scaling | metric để dự báo | mở rộng TRƯỚC dựa trên học máy |

Từ khoá nhận diện:

"target value", "maintain metric at X%" → target tracking "set of scaling adjustments", "step" → step scaling "at a specific time" → scheduled scaling "forecast", "recurring pattern" → predictive scaling

Bốn metric dựng sẵn cho target tracking: | Metric | Đo gì | |---|---| | ASGAverageCPUUtilization | CPU trung bình của nhóm ← câu này | | ASGAverageNetworkIn / NetworkOut | lưu lượng mạng | | ALBRequestCountPerTarget | số request mỗi target — thường phản ánh tải tốt hơn CPU |

Và dùng được metric tuỳ chỉnh:

{"TargetValue": 100.0,
 "CustomizedMetricSpecification": {
   "MetricName": "BacklogMoiInstance",
   "Namespace": "UngDung", "Statistic": "Average"}}

Ba tham số quan trọng: | Tham số | Việc | |---|---| | EstimatedInstanceWarmup | bỏ qua instance mới trong tính toán metric cho tới khi sẵn sàng | | DisableScaleIn | chỉ mở rộng, không thu hẹp | | TargetValue | giá trị cần giữ |

EstimatedInstanceWarmup là tham số quan trọng nhất:

Không đặt (hoặc quá ngắn):
    → instance mới chưa khởi động xong đã bị tính vào metric
    → metric vẫn cao → ASG thêm tiếp
    → MỞ RỘNG QUÁ MỨC, rồi thu hẹp ồ ạt

Và DisableScaleIn hữu ích khi dùng nhiều policy:

Policy A (target tracking CPU): chỉ mở rộng
Policy B (scheduled): kiểm soát việc thu hẹp
    → tránh hai policy đánh nhau

Ba nguyên tắc để co giãn ổn định: | Nguyên tắc | Lý do | |---|---| | Mở rộng NHANH, thu hẹp CHẬM | mở rộng muộn gây gián đoạn; thu hẹp muộn chỉ tốn ít tiền | | Chọn metric phản ánh đúng tải | CPU không phải lúc nào cũng đúng | | Đặt MinSize đủ chịu tải nền | tránh co giãn liên tục quanh mức thấp |

Và khi nào CPU KHÔNG phải metric đúng: | Loại workload | Metric phù hợp hơn | |---|---| | Nặng I/O (đọc ghi đĩa, gọi mạng) | độ sâu hàng đợi, số request | | Nặng bộ nhớ | metric bộ nhớ tuỳ chỉnh (cần CloudWatch agent) | | Web | ALBRequestCountPerTarget |

Nhắc lại: CloudWatch KHÔNG có metric bộ nhớ mặc định — phải cài unified CloudWatch agent.

Ba cấu hình khác cần đúng: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay instance mà load balancer đánh giá là hỏng | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động ứng dụng | | Trải qua ít nhất HAI AZ | chịu lỗi |

Và có thể dùng NHIỀU target tracking policy cùng lúc:

Policy 1: giữ CPU ở 50%
Policy 2: giữ ALBRequestCountPerTarget ở 1000
    → ASG chọn hành động nào cho DUNG LƯỢNG LỚN HƠN
    → an toàn hơn, không policy nào bị bỏ qua

Ba metric để kiểm chứng hiệu quả: | Metric | Ý nghĩa | |---|---| | GroupDesiredCapacity | số máy ASG muốn có | | GroupInServiceInstances | số máy thực sự đang phục vụ | | CPU thực tế so với mục tiêu | bám sát 50% nghĩa là policy hoạt động đúng |

Và một lời khuyên khi chẩn đoán: xem Activity history của Auto Scaling group để biết ASG đã phản ứng lúc nào, bao nhiêu, và vì lý do gì. Nếu thấy thêm rồi bớt liên tục, gần như chắc chắn là thiếu EstimatedInstanceWarmup — đó là tham số bị bỏ sót nhiều nhất.

Đáp án

A — Cấu hình S3 Event Notification kích hoạt Lambda function khi có mô tả sản phẩm mới; trong hàm, dùng Amazon Comprehend custom entity recognition để trích xuất tên nguyên liệu; lưu vào DynamoDB và để ứng dụng truy vấn điểm an toàn.

Vì sao đúng

Đề nêu bốn ràng buộc, và đáp án thoả cả bốn: | Ràng buộc | Giải pháp | |---|---| | Trích xuất TÊN NGUYÊN LIỆU từ văn bản | Comprehend custom entity recognition | | Hoàn toàn tự động | S3 event → Lambda, không ai can thiệp | | KHÔNG có chuyên gia học máy trong công ty | Comprehend huấn luyện mô hình tuỳ chỉnh mà không cần viết mã ML | | Ít công vận hành, tiết kiệm nhất | serverless hoàn toàn |

Vì sao cần CUSTOM entity recognition chứ không phải DetectEntities thường:

DetectEntities mặc định nhận diện:
    người, tổ chức, địa điểm, ngày tháng, số lượng, sự kiện
        ↓
    "NGUYÊN LIỆU THỰC PHẨM" KHÔNG nằm trong danh sách
    → phải huấn luyện mô hình tuỳ chỉnh

Và custom entity recognition không đòi kỹ năng học máy:

Bạn cung cấp:
    ① Danh sách thực thể mẫu (annotation hoặc entity list)
    ② Tập văn bản huấn luyện
        ↓
Comprehend tự:
    ✓ huấn luyện mô hình
    ✓ đánh giá độ chính xác
    ✓ triển khai endpoint
    → không viết dòng mã ML nào

aws comprehend create-entity-recognizer   --recognizer-name nhan-dien-nguyen-lieu   --language-code en --data-access-role-arn <arn-role>   --input-data-config '{
    "EntityTypes": [{"Type": "NGUYEN_LIEU"}],
    "Documents": {"S3Uri": "s3://kho-huan-luyen/van-ban/"},
    "EntityList": {"S3Uri": "s3://kho-huan-luyen/danh-sach-nguyen-lieu.csv"}}'

Và kiến trúc hoàn toàn serverless:

Người bán tải mô tả sản phẩm → S3
    ↓ S3 event notification
Lambda gọi Comprehend custom entity recognition
    ↓ nhận danh sách nguyên liệu
Lambda tra DynamoDB lấy điểm an toàn
    ↓ ghi kết quả
Ứng dụng front-end truy vấn

Và vế "non-food items có thể bỏ qua" được xử lý tự nhiên — mô hình không tìm thấy thực thể nào thì Lambda kết thúc, không ảnh hưởng gì.

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

• **D. Dùng SageMaker với mô hình NLP tự huấn luyện, gọi qua EventBridge và Lambda, huấn luyện lại hằng tháng — đây là phương án gần nhất về mặt cũng nhận diện được nguyên liệu, nhưng nó vi phạm hai ràng buộc: đề nói rõ công ty KHÔNG có chuyên gia học máy, và SageMaker đòi chuẩn bị dữ liệu, huấn luyện, đánh giá, triển khai và bảo trì endpoint. Đó là công vận hành và chi phí lớn nhất trong bốn phương án.
• **B. Dùng Amazon Lookout for Vision quét tệp văn bản — sai loại dịch vụ hoàn toàn: Lookout for Vision phát hiện khiếm khuyết trong ẢNH sản phẩm trên dây chuyền sản xuất. Nó không đọc văn bản.
• **C. Dùng Amazon Transcribe chuyển bản ghi âm tổng hợp ngược lại thành văn bản rồi khớp từ khoá — vòng vo và vô lý: văn bản đã là văn bản, không cần chuyển qua giọng nói rồi ngược lại. Và khớp từ khoá đơn giản không xử lý được biến thể cách viết.

Ghi nhớ

Ba mức nhận diện thực thể của Amazon Comprehend: | Mức | Đặc điểm | |---|---| | DetectEntities (dựng sẵn) | người, tổ chức, địa điểm, ngày, số lượng — KHÔNG tuỳ chỉnh | | Custom entity recognition | huấn luyện loại thực thể RIÊNG của bạn ← câu này | | Custom classification | phân loại tài liệu theo nhãn riêng |

Và cả hai loại "custom" đều KHÔNG cần kỹ năng học máy — đó là điểm bán hàng chính của Comprehend.

Hai cách cung cấp dữ liệu huấn luyện cho custom entity: | Cách | Đặc điểm | |---|---| | Entity list | danh sách thực thể + tài liệu chứa chúng — đơn giản hơn | | Annotations | đánh dấu vị trí chính xác trong văn bản — chính xác hơn |

Với danh sách nguyên liệu có sẵn, entity list là cách nhanh nhất.

Các dịch vụ AI được quản lý của AWS — bảng cần thuộc: | Dịch vụ | Đầu vào → đầu ra | |---|---| | Comprehend | văn bản → thực thể, cảm xúc, chủ đề, PII | | Comprehend Medical | văn bản y tế → PHI, thuốc, chẩn đoán | | Textract | tài liệu quét → văn bản, bảng, biểu mẫu | | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói | | Rekognition | ảnh, video → nhãn, khuôn mặt | | Lookout for Vision | ảnh sản phẩm → phát hiện khiếm khuyết | | Lex | hội thoại → ý định | | Kendra | câu hỏi → tài liệu liên quan |

Quy tắc nhận diện trong đề thi:

"no ML expertise", "minimal operational overhead" → dịch vụ AI được quản lý, KHÔNG phải SageMaker "custom entity type not in the built-in list" → Comprehend custom entity recognition "train your own model", "fine-tune" → SageMaker (và thường là đáp án SAI khi đề nói không có chuyên gia ML)

Hai chế độ chạy custom entity recognition: | Chế độ | Đặc điểm | |---|---| | Asynchronous batch job | rẻ hơn, xử lý nhiều tài liệu cùng lúc | | Real-time endpoint | độ trễ thấp, nhưng tính phí theo GIỜ dù có dùng hay không |

Với mô hình xử lý theo sự kiện tải lên, batch job thường rẻ hơn nhiều:

Endpoint thời gian thực chạy 24/7:
    → tính phí liên tục dù cả ngày chỉ có vài tài liệu

Batch job:
    → gom tài liệu mỗi giờ rồi chạy một lần
    → chỉ trả tiền cho thời gian xử lý thật

Ba lưu ý về chi phí Comprehend: | Khoản | Chi tiết | |---|---| | Huấn luyện mô hình | tính một lần theo dữ liệu huấn luyện | | Endpoint thời gian thực | theo GIỜ — nhớ xoá khi không dùng | | Batch inference | theo số ký tự xử lý |

Endpoint bị quên là nguồn chi phí âm thầm phổ biến — hãy đặt alarm hoặc tự động xoá sau khi xử lý xong.

Ba lưu ý khi thiết kế đường ống này: | Lưu ý | Chi tiết | |---|---| | Lambda có timeout 15 phút | với tài liệu lớn, dùng batch job bất đồng bộ | | Xử lý được trường hợp không tìm thấy thực thể | non-food item — bỏ qua êm ái | | Ghi log kết quả để đánh giá độ chính xác | và cải thiện mô hình |

Và mẫu bất đồng bộ cho tài liệu lớn:

S3 event → Lambda khởi động batch job của Comprehend
    ↓ job xong → kết quả về S3
    ↓ S3 event
Lambda thứ hai đọc kết quả, tra DynamoDB, ghi điểm

Ba cách cải thiện độ chính xác của mô hình: | Cách | Chi tiết | |---|---| | Thêm dữ liệu huấn luyện đa dạng | nhiều cách viết khác nhau của cùng nguyên liệu | | Dùng annotations thay entity list | chính xác hơn với văn bản phức tạp | | Huấn luyện lại định kỳ | khi có nguyên liệu mới xuất hiện |

Và Comprehend báo các chỉ số đánh giá sau khi huấn luyện:

Precision: trong số nhận diện được, bao nhiêu phần trăm đúng
Recall:    trong số thực thể có thật, bắt được bao nhiêu phần trăm
F1 score:  trung bình điều hoà của hai chỉ số trên

Nên xem chúng trước khi đưa vào sản xuất — F1 dưới 0,8 thường cần thêm dữ liệu huấn luyện.

Và một lời khuyên về thiết kế bảng DynamoDB: dùng tên nguyên liệu đã chuẩn hoá làm partition key (viết thường, bỏ dấu, bỏ khoảng trắng thừa). Comprehend trả về đúng chuỗi trong văn bản gốc, và nếu không chuẩn hoá thì "Đường mía" và "đường mía" sẽ là hai khoá khác nhau.

Đáp án

B — Số lượt gọi Lambda từ SNS đã vượt hạn mức đồng thời (concurrency quota) của tài khoản; đội ngũ cần liên hệ AWS Support để yêu cầu tăng.

Vì sao đúng

Đề cho hai con số, và tỷ lệ giữa chúng là manh mối:

Ngoài mùa:  ~100 request mỗi giây     → hoạt động bình thường
Cao điểm:   ~5.000 request mỗi giây   → nhiều thông báo KHÔNG được giao
    ↓
    Tăng 50 lần → chạm một giới hạn nào đó

Và giới hạn đó là mức đồng thời của Lambda:

Hạn mức đồng thời mặc định: 1.000 cho cả TÀI KHOẢN
    ↓
Công thức ước lượng số lượt đồng thời:
    Đồng thời = số request/giây × thời gian chạy trung bình (giây)
        ↓
    5.000 request/giây × 0,3 giây = 1.500 lượt đồng thời
    → VƯỢT hạn mức 1.000
    → Lambda ném TooManyRequestsException (429)
    → SNS không giao được thông báo

Và SNS thì hoàn toàn không phải vấn đề:

SNS mở rộng gần như không giới hạn
    → 5.000 request/giây là con số rất nhỏ với SNS
    → nút thắt nằm ở phía NGƯỜI NHẬN, không phải người gửi

Cách khắc phục:

# Yêu cầu tăng hạn mức đồng thời qua Service Quotas
aws service-quotas request-service-quota-increase   --service-code lambda --quota-code L-B99A9384   --desired-value 5000

Và trong lúc chờ, có biện pháp tạm:

Đặt SQS giữa SNS và Lambda:
    SNS → SQS → Lambda
        → SQS làm vùng đệm hấp thụ đỉnh tải
        → Lambda xử lý theo tốc độ của mình
        → không mất thông báo nào

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

• **A. SNS đã chạm giới hạn mở rộng, cần liên hệ AWS tăng hạn mức — đây là phương án gần nhất vì cũng nói về hạn mức, nhưng nó nhắm sai dịch vụ: SNS xử lý được khối lượng lớn hơn nhiều lần con số trong đề. Nút thắt nằm ở Lambda.
• **C. Cần cấp thêm máy chủ chạy dịch vụ Lambda — hiểu sai bản chất serverless: Lambda không có máy chủ nào để cấp phát. AWS quản lý toàn bộ hạ tầng; bạn chỉ điều chỉnh hạn mức.
• **D. Cần cấp thêm máy chủ chạy dịch vụ SNS — cùng lỗi: SNS cũng là dịch vụ được quản lý hoàn toàn.

Ghi nhớ

Hạn mức của AWS Lambda — bảng cần thuộc: | Hạn mức | Giá trị mặc định | |---|---| | Đồng thời (concurrency) mỗi tài khoản mỗi Region | 1.000 (tăng được) | | Thời gian chạy tối đa | 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | Burst concurrency | 500–3.000 tuỳ Region | | Kích thước gói zip | 50 MB nén / 250 MB giải nén |

Công thức tính số lượt đồng thời — cần nhớ:

Đồng thời = số request mỗi giây × thời gian chạy (giây)

Ví dụ: 1.000 request/giây × 2 giây = 2.000 lượt đồng thời.

Ba loại concurrency của Lambda: | Loại | Việc | |---|---| | Unreserved (mặc định) | dùng chung phần còn lại của hạn mức tài khoản | | Reserved concurrency | DÀNH RIÊNG một phần cho hàm — và cũng GIỚI HẠN nó | | Provisioned concurrency | giữ sẵn môi trường thực thi — hết cold start, có phí |

Reserved concurrency có hai tác dụng cùng lúc:

Đặt reserved = 200 cho một hàm:
    ✓ đảm bảo hàm đó luôn có 200 lượt
    ✓ và KHÔNG BAO GIỜ vượt 200 → bảo vệ các hàm khác

Ba biện pháp xử lý đỉnh tải cho Lambda: | Biện pháp | Chi tiết | |---|---| | Tăng hạn mức tài khoản | qua Service Quotas | | Đặt SQS làm vùng đệm | hấp thụ đỉnh, xử lý dần | | Provisioned concurrency | giữ sẵn môi trường cho hàm quan trọng |

Và mẫu SNS → SQS → Lambda là kiến trúc chuẩn cho tải biến động:

SNS topic
    ├─▶ SQS queue A → Lambda A
    ├─▶ SQS queue B → Lambda B
    └─▶ SQS queue C → Lambda C
        ↓
    Mỗi nhánh có vùng đệm riêng
    Lỗi ở một nhánh không ảnh hưởng nhánh khác
    Thông điệp không mất khi Lambda bị throttle

Ba hành vi khi SNS gọi Lambda trực tiếp: | Tình huống | Hành vi | |---|---| | Lambda bị throttle | SNS thử lại theo chính sách retry | | Hết số lần thử | thông điệp bị BỎ (trừ khi có DLQ) | | Có DLQ | thông điệp vào dead-letter queue |

Nên cấu hình DLQ cho SNS subscription:

aws sns set-subscription-attributes   --subscription-arn <arn> --attribute-name RedrivePolicy   --attribute-value '{"deadLetterTargetArn":"<arn-sqs-dlq>"}'

Ba metric cần đặt alarm cho Lambda: | Metric | Ý nghĩa | |---|---| | Throttles | số lần bị từ chối vì hết hạn mức — chỉ báo trực tiếp | | ConcurrentExecutions | tiến gần hạn mức là dấu hiệu sắp có vấn đề | | Errors | lỗi trong hàm |

aws cloudwatch put-metric-alarm --alarm-name lambda-bi-throttle   --metric-name Throttles --namespace AWS/Lambda   --statistic Sum --period 300 --threshold 1   --comparison-operator GreaterThanThreshold

Ba cách giảm số lượt đồng thời cần thiết: | Cách | Chi tiết | |---|---| | Rút ngắn thời gian chạy | tăng bộ nhớ để có nhiều CPU hơn | | Xử lý theo LÔ | một lần gọi xử lý nhiều thông điệp | | Loại bỏ chờ đợi không cần thiết | gọi song song thay vì tuần tự |

Rút ngắn thời gian chạy có tác động trực tiếp:

5.000 request/giây × 0,3 giây = 1.500 đồng thời
5.000 request/giây × 0,1 giây = 500 đồng thời
    → giảm ba lần thời gian chạy = giảm ba lần nhu cầu đồng thời

Và AWS Lambda Power Tuning giúp tìm cấu hình bộ nhớ tối ưu — thường tìm ra điểm vừa nhanh hơn vừa rẻ hơn.

Ba lưu ý về burst concurrency: | Lưu ý | Chi tiết | |---|---| | Burst limit khác concurrency limit | 500–3.000 tuỳ Region | | Sau burst, tăng thêm 500 mỗi phút | | | Tải tăng ĐỘT NGỘT có thể bị throttle dù chưa chạm trần | |

Dòng cuối quan trọng với tình huống của đề: mùa giải bắt đầu và lưu lượng nhảy vọt trong vài giây — burst limit có thể là nút thắt trước cả concurrency limit.

Và một lời khuyên: hãy yêu cầu tăng hạn mức TRƯỚC mùa cao điểm, không phải khi đã có sự cố. Yêu cầu tăng hạn mức cần AWS xử lý và có thể mất vài ngày — biết trước lịch mùa giải là lợi thế mà đội ngũ nên tận dụng.