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

Đáp án

C — Kết nối sẽ được cho phép.

Vì sao đúng

Câu hỏi kiểm tra cách Network ACL đánh giá rule — và nguyên tắc đó quyết định câu trả lời.

NACL đánh giá theo THỨ TỰ SỐ và DỪNG ở rule khớp đầu tiên:

Rule 100:  ALLOW  All Traffic  from 0.0.0.0/0
Rule 101:  DENY   All Traffic  from 110.238.109.37/32
Rule *:    DENY   All Traffic  from 0.0.0.0/0

Gói tin từ 110.238.109.37 tới:
    ① Xét rule 100 → 0.0.0.0/0 KHỚP → ALLOW → DỪNG
    ② Rule 101 KHÔNG BAO GIỜ được xét tới
    → kết nối ĐƯỢC PHÉP

Đây là khác biệt căn bản so với security group và IAM policy: | Cơ chế | Cách đánh giá | |---|---| | NACL | theo THỨ TỰ SỐ, dừng ở rule khớp ĐẦU TIÊN | | Security group | xét MỌI rule, chỉ có Allow | | IAM policy | xét mọi statement, explicit DENY luôn thắng |

Nên với NACL, một rule DENY ở số LỚN HƠN rule ALLOW bao quát là VÔ DỤNG — nó không bao giờ được đánh giá.

Muốn chặn địa chỉ đó, phải đặt rule DENY ở SỐ NHỎ HƠN:

Rule 90:   DENY   All Traffic  from 110.238.109.37/32   ← xét trước
Rule 100:  ALLOW  All Traffic  from 0.0.0.0/0

(Ảnh minh hoạ trong đề không hiển thị được ở đây, nhưng bộ rule tiêu chuẩn của dạng câu hỏi này là như trên — và chính thứ tự đó tạo ra đáp án C.)

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

• **D. Kết nối sẽ bị từ chối — đây là phương án gần nhất và là điều người ta mong đợi khi nhìn thấy rule DENY, nhưng nó bỏ qua thứ tự đánh giá: rule ALLOW ở số nhỏ hơn đã quyết định trước, và NACL dừng ngay tại đó.
• **A. Ban đầu được phép rồi sau đó bị từ chối — NACL không có hành vi theo thời gian: mỗi gói tin được đánh giá độc lập theo cùng bộ rule, cho cùng kết quả.
• **B. Ban đầu bị từ chối rồi sau đó được phép — cùng lý do: không có cơ chế nào khiến quyết định thay đổi theo thời gian.

Ghi nhớ

Nguyên tắc đánh giá NACL — thuộc lòng cái này:

① Rule được xét theo THỨ TỰ SỐ TĂNG DẦN
② DỪNG ngay ở rule khớp ĐẦU TIÊN
③ Không rule nào khớp → rule mặc định (*) → DENY

Hệ quả thực tế quan trọng:

Đặt rule DENY cụ thể ở số NHỎ HƠN rule ALLOW bao quát. Ngược lại thì rule DENY không bao giờ có tác dụng.

Security group và NACL — bảng phân biệt cốt lõi: | | Security group | Network ACL | |---|---|---| | Mức | ENI/instance | subnet | | Trạng thái | stateful | stateless — phải mở CẢ HAI chiều | | Rule | CHỈ Allow | Allow VÀ Deny | | Đánh giá | MỌI rule | theo thứ tự, DỪNG ở rule đầu khớp | | Nguồn chấp nhận | IP, CIDR, security group, prefix list | CHỈ CIDR | | Mặc định (VPC) | chặn inbound | cho phép hết | | Mặc định (tự tạo) | chặn inbound | CHẶN HẾT |

Hai dòng cuối là bẫy hay gặp: NACL bạn tự tạo chặn mọi thứ, khác hẳn NACL mặc định của VPC.

Bộ rule NACL tối thiểu cho subnet có web server:

INBOUND
  100 | HTTP  (80)              | 0.0.0.0/0 | ALLOW
  110 | HTTPS (443)             | 0.0.0.0/0 | ALLOW
  120 | Custom TCP 1024-65535   | 0.0.0.0/0 | ALLOW  ← phản hồi cho kết nối RA
  *   | ALL                     | 0.0.0.0/0 | DENY

OUTBOUND
  100 | HTTP  (80)              | 0.0.0.0/0 | ALLOW
  110 | HTTPS (443)             | 0.0.0.0/0 | ALLOW
  120 | Custom TCP 1024-65535   | 0.0.0.0/0 | ALLOW  ← phản hồi cho client
  *   | ALL                     | 0.0.0.0/0 | DENY

Cả hai chiều đều cần rule cổng tạm — vì NACL không có trạng thái, và kết nối có thể khởi tạo từ hai phía.

Ba lời khuyên khi dùng NACL: | Lời khuyên | Lý do | |---|---| | Đánh số cách nhau 10 hoặc 100 | chừa chỗ chèn rule sau này | | Dùng NACL mặc định trừ khi có nhu cầu rõ ràng | security group đủ cho hầu hết trường hợp | | Dùng NACL khi cần rule DENY | security group không có Deny |

Dòng giữa là lời khuyên thực dụng nhất: NACL là nguồn gốc của rất nhiều sự cố mạng khó chẩn đoán — triệu chứng thường là timeout không có thông báo lỗi. Chỉ siết NACL khi thực sự cần chặn theo danh sách đen.

Trường hợp NACL thực sự hữu ích: | Trường hợp | Lý do | |---|---| | Chặn một dải IP cụ thể | security group KHÔNG có rule Deny | | Cắt kết nối đang mở | NACL stateless, có hiệu lực ngay với mọi gói tin | | Lớp phòng thủ bổ sung ở mức subnet | defense in depth |

Dòng giữa đáng nhớ: vì security group có trạng thái, đổi rule của nó không ngắt kết nối đã thiết lập. Muốn cắt ngay một kết nối đang mở, NACL là công cụ đúng.

Và với instance trong private subnet như đề mô tả: hãy kiểm tra xem có thực sự cần NACL tuỳ chỉnh không. Private subnet vốn đã không truy cập được từ Internet nhờ route table — thêm một lớp NACL cấu hình sai thường gây hại nhiều hơn lợi.

Đáp án

B — Cấu hình lifecycle configuration rule trên S3 bucket để xoá (purge) log giao dịch sau một tháng.

Vì sao đúng

Đề cần giữ log một tháng rồi xoá — và lifecycle rule với thao tác Expiration làm đúng việc đó.

Cấu hình gọn và không cần mã:

{
  "Rules": [{
    "ID": "xoa-log-giao-dich-sau-30-ngay",
    "Status": "Enabled",
    "Filter": {"Prefix": "log-giao-dich/"},
    "Expiration": {"Days": 30}
  }]
}

Bốn lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần mã, không cần máy chủ | không có gì để bảo trì | | Không cần lịch chạy | S3 tự đánh giá hằng ngày | | Áp cho object mới tự động | log mới ghi cũng theo cùng chính sách | | Miễn phí | thao tác Expiration không tính phí |

Và nó lọc được theo prefix hoặc tag — nên bạn có chính sách khác nhau cho từng loại dữ liệu trong cùng một bucket:

log-giao-dich/  → xoá sau 30 ngày
bao-cao/        → giữ 7 năm, chuyển sang Glacier sau 90 ngày

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

• **A. Thêm một bucket policy mới trên S3 bucket — đây là phương án gần nhất về mặt cũng là cấu hình trên bucket, nhưng bucket policy chỉ kiểm soát QUYỀN TRUY CẬP: ai được đọc, ghi, xoá. Nó không tự thực hiện hành động nào — không xoá object theo thời gian.
• **C. Tạo một IAM policy tự động xoá log sau một tháng — hiểu sai bản chất IAM policy: nó cấp hoặc từ chối quyền, nó không phải cơ chế tự động hoá. Không có IAM policy nào tự chạy lệnh xoá.
• **D. Bật CORS trên bucket để cho phép tự động xoá dữ liệu hằng tháng — hoàn toàn không liên quan: CORS quy định trình duyệt có cho JavaScript từ origin này gọi tài nguyên ở origin khác hay không. Nó không có khả năng quản lý vòng đời dữ liệu.

Ghi nhớ

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

Dòng thứ ba rất quan trọng nếu bucket bật versioning:

Versioning BẬT + chỉ có Expiration:
    → xoá object chỉ tạo DELETE MARKER
    → mọi phiên bản cũ VẪN CÒN và VẪN TÍNH PHÍ
    → dữ liệu không thực sự bị xoá

Cấu hình đầy đủ cho bucket có versioning:

{"Rules": [{
  "Status": "Enabled",
  "Expiration": {"Days": 30},
  "NoncurrentVersionExpiration": {"NoncurrentDays": 1},
  "Expiration": {"ExpiredObjectDeleteMarker": true}
}]}

Ba cách lọc object trong lifecycle rule: | Cách | Ví dụ | |---|---| | Prefix | "Prefix": "log-giao-dich/" | | Tag | "Tag": {"Key": "LoaiDuLieu", "Value": "log"} | | Kích thước | ObjectSizeGreaterThan |

Lọc theo tag linh hoạt hơn: ứng dụng gắn tag khi ghi, và lifecycle tự áp chính sách phù hợp — không phụ thuộc vào cấu trúc thư mục.

Ba lưu ý khi dùng Expiration: | Lưu ý | Chi tiết | |---|---| | Lifecycle chạy MỘT LẦN mỗi ngày | không xoá đúng vào giờ thứ 720 | | Có thể chậm vài giờ sau mốc | với yêu cầu tuân thủ chặt về thời hạn thì cần cơ chế khác | | Thao tác xoá là VĨNH VIỄN | không khôi phục được nếu versioning tắt |

Dòng cuối đáng cân nhắc: với log giao dịch của ứng dụng thương mại điện tử, hãy chắc chắn rằng một tháng là đủ cho mọi nhu cầu — điều tra sự cố, kiểm toán, tranh chấp với khách hàng. Xoá rồi thì không lấy lại được.

Ba lựa chọn thay thế cho việc xoá hẳn: | Lựa chọn | Đặc điểm | |---|---| | Chuyển sang Glacier Deep Archive | giữ được, chi phí ~1 USD/TB/tháng | | Xuất sang CloudWatch Logs với retention | truy vấn được bằng Logs Insights | | Nén và gộp trước khi lưu | giảm dung lượng đáng kể |

Với log giao dịch, dòng đầu đáng cân nhắc: chi phí giữ ở Deep Archive rất thấp, và nếu có tranh chấp phát sinh sau vài tháng, bạn vẫn còn dữ liệu.

Ba cơ chế thường bị nhầm là công cụ tự động hoá: | Cơ chế | Thực sự là gì | |---|---| | Bucket policy | quyền truy cập tài nguyên | | IAM policy | quyền của principal | | CORS | quy tắc cho TRÌNH DUYỆT về truy cập chéo origin | | Lifecycle rule | quản lý VÒNG ĐỜI object ← đáp án |

Chỉ lifecycle rule thực hiện hành động theo thời gian — ba cái còn lại đều là cơ chế kiểm soát, không phải tự động hoá.

Và một lifecycle rule nên có cho mọi bucket, không chỉ bucket log:

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

Multipart upload thất bại để lại các phần đã tải, và chúng tính phí lưu trữ mãi mãi mà không hiện trong danh sách object — nên rất dễ bị bỏ quên.

Đáp án

D — Bật job bookmark cho ETL job.

Vì sao đúng

Đề mô tả vấn đề chính xác: dữ liệu cũ từ các lần chạy trước bị xử lý lại, làm job chạy lâu hơn.

Job bookmark là tính năng của AWS Glue giải quyết đúng điều đó:

Không có bookmark:
    Lần chạy 1: xử lý tệp A, B, C
    Lần chạy 2: xử lý tệp A, B, C, D    ← A, B, C bị làm lại
    Lần chạy 3: xử lý tệp A, B, C, D, E ← càng ngày càng chậm

Có bookmark:
    Lần chạy 1: xử lý A, B, C → lưu trạng thái
    Lần chạy 2: chỉ xử lý D
    Lần chạy 3: chỉ xử lý E

Cách Glue theo dõi trạng thái: | Nguồn | Cách nhận biết dữ liệu mới | |---|---| | Amazon S3 | thời điểm sửa đổi (last modified) của object | | JDBC (cơ sở dữ liệu) | giá trị cột khoá tăng dần (bookmark key) |

aws glue update-job --job-name job-bao-cao-hang-ngay   --job-update '{"DefaultArguments": {"--job-bookmark-option": "job-bookmark-enable"}}'

Và bookmark là tính năng dựng sẵn — không cần viết mã, không cần dịch vụ phụ, đúng yêu cầu "most operationally efficient".

Ba giá trị của tuỳ chọn bookmark: | Giá trị | Hành vi | |---|---| | job-bookmark-enable | chỉ xử lý dữ liệu mới | | job-bookmark-disable | xử lý lại toàn bộ mỗi lần (mặc định) | | job-bookmark-pause | xử lý một khoảng cụ thể mà không cập nhật bookmark |

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

• **C. Tạo một Lambda function xoá dữ liệu đã xử lý; dùng EventBridge kích hoạt khi job chuyển sang trạng thái SUCCEEDED — đây là phương án gần nhất và về mặt logic có giải quyết được, nhưng nó nhiều công hơn hẳn và PHÁ HUỶ DỮ LIỆU: bạn phải viết và bảo trì Lambda, và dữ liệu gốc bị xoá — không chạy lại được nếu phát hiện lỗi trong kết quả.
• **B. Song song hoá job bằng cách chia dữ liệu thành phân vùng nhỏ và xử lý đồng thời bằng nhiều EC2 instance — không giải quyết nguyên nhân gốc: nó làm việc xử lý lại nhanh hơn, nhưng vẫn xử lý lại. Và tự quản lý EC2 là công vận hành lớn.
• **A. Tăng kích thước tập dữ liệu để tăng tốc quá trình trích xuất và phân tích — vô nghĩa: dữ liệu nhiều hơn làm job chậm hơn, không nhanh hơn.

Ghi nhớ

Bốn thành phần của AWS Glue: | Thành phần | Việc | |---|---| | ETL job | chuyển đổi dữ liệu — Spark hoặc Python shell | | Crawler | phát hiện lược đồ, cập nhật Data Catalog | | Data Catalog | kho metadata dùng chung với Athena, Redshift Spectrum, EMR | | Job bookmark | theo dõi dữ liệu đã xử lý ← câu này |

Ba điều kiện để job bookmark hoạt động đúng: | Điều kiện | Chi tiết | |---|---| | Job phải có job-name và JOB_RUN_ID ổn định | bookmark gắn với tên job | | Mã phải gọi job.commit() ở cuối | không gọi thì bookmark KHÔNG được cập nhật | | Dùng create_dynamic_frame.from_catalog hoặc from_options | không phải mọi cách đọc đều hỗ trợ bookmark |

Điều kiện thứ hai là lỗi phổ biến nhất:

from awsglue.job import Job
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# ... xử lý dữ liệu ...

job.commit()    # ← THIẾU DÒNG NÀY thì bookmark không tiến lên

Ba thao tác quản lý bookmark:

# Xoá bookmark — job sẽ xử lý lại toàn bộ
aws glue reset-job-bookmark --job-name job-bao-cao-hang-ngay

# Tạm dừng bookmark cho một lần chạy cụ thể
--job-bookmark-option job-bookmark-pause
--job-bookmark-from <run-id> --job-bookmark-to <run-id>

reset-job-bookmark hữu ích khi cần xử lý lại sau khi sửa lỗi logic.

Ba lưu ý về bookmark với nguồn S3: | Lưu ý | Chi tiết | |---|---| | Dựa trên thời điểm sửa đổi của object | ghi đè object cũ sẽ khiến nó bị xử lý lại | | Không phát hiện object bị XOÁ | dữ liệu đã xử lý vẫn nằm ở đích | | Xoá tệp rồi thêm lại cùng tên | được coi là tệp mới |

Ba cách tối ưu khác cho Glue ETL job: | Cách | Lợi ích | |---|---| | Phân vùng dữ liệu nguồn theo ngày | kết hợp với predicate pushdown, chỉ đọc phân vùng cần | | Dùng định dạng cột (Parquet) | giảm mạnh dữ liệu đọc | | Điều chỉnh số worker và loại worker | cân bằng tốc độ và chi phí |

Predicate pushdown là kỹ thuật bổ trợ mạnh cho bookmark:

dyf = glueContext.create_dynamic_frame.from_catalog(
    database="du_lieu_chung_khoan", table_name="giao_dich",
    push_down_predicate="ngay >= '2026-08-01'")

Nó lọc ngay ở tầng đọc — Glue thậm chí không tải các phân vùng không khớp.

Ba lưu ý về chi phí Glue: | Lưu ý | Chi tiết | |---|---| | Tính phí theo DPU-giờ | tối thiểu 1 phút mỗi lần chạy | | Glue 3.0 trở lên khởi động nhanh hơn | giảm chi phí cho job ngắn | | Python shell job rẻ hơn Spark job | cho việc nhẹ, không cần Spark |

Và bookmark chính là tối ưu chi phí lớn nhất cho job chạy hằng ngày trên dữ liệu tích luỹ: thay vì thời gian chạy tăng tuyến tính theo tổng dữ liệu, nó giữ ổn định theo lượng dữ liệu mới mỗi ngày.

Và một lựa chọn thay thế đáng biết nếu dữ liệu nguồn có cấu trúc phân vùng rõ ràng: chỉ trỏ job vào phân vùng của ngày hôm đó bằng tham số truyền vào lúc chạy. Cách này đơn giản và dễ hiểu hơn bookmark, nhưng đòi hỏi dữ liệu được tổ chức theo ngày một cách nhất quán.

Đáp án

D — Cấu hình Security Group của EC2 instance để cho phép lưu lượng vào cổng 22 từ IP của bạn.

Vì sao đúng

Đề cho một manh mối quyết định: các instance KHÁC trong cùng VPC vẫn truy cập được bình thường.

Suy luận từ manh mối đó:

Instance khác trong CÙNG VPC → SSH được
    ↓
VPC, subnet, route table, Internet Gateway, NACL → ĐỀU ĐÚNG
    (chúng dùng chung cho cả subnet)
    ↓
Vấn đề phải nằm ở thứ RIÊNG của instance mới
    ↓
Security Group

Và SSH dùng TCP cổng 22:

Inbound rule cần có:
  Type: SSH   Protocol: TCP   Port: 22   Source: <IP nhà bạn>/32

Security group mặc định khi tạo mới chặn MỌI lưu lượng vào — nên instance vừa triển khai với security group mới toanh sẽ không SSH được, đúng như triệu chứng.

aws ec2 authorize-security-group-ingress --group-id sg-0abc123   --protocol tcp --port 22 --cidr 203.0.113.25/32

Chú ý /32 — đó là một địa chỉ duy nhất. Mở 0.0.0.0/0 cho cổng 22 là phơi SSH ra cả Internet.

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

• **B. Cấu hình Network ACL của VPC cho phép cổng 22 từ IP của bạn — đây là phương án gần nhất và cũng liên quan tới lọc mạng, nhưng nó mâu thuẫn với dữ kiện của đề: NACL áp ở mức subnet, dùng chung cho mọi instance trong đó. Nếu NACL chặn cổng 22 thì các instance khác cũng không SSH được — mà đề nói chúng vẫn vào bình thường.
• **C. Cấu hình Security Group cho phép cổng 3389 — sai cổng: 3389 là RDP, dùng cho Windows. Đề nói rõ là SSH.
• **A. Dùng Amazon Data Lifecycle Manager — hoàn toàn không liên quan: DLM tự động hoá việc tạo và xoá EBS snapshot theo lịch. Nó không dính gì tới kết nối mạng.

Ghi nhớ

Security group và NACL — bảng phân biệt cốt lõi: | | Security group | Network ACL | |---|---|---| | Áp ở mức | ENI / instance | SUBNET | | Trạng thái | stateful — phản hồi tự động được phép | stateless — phải mở CẢ HAI chiều | | Rule | CHỈ Allow | Allow VÀ Deny | | Đánh giá | MỌI rule | theo thứ tự số, dừng ở rule đầu khớp | | Nguồn chấp nhận | IP, CIDR, security group khác, prefix list | CHỈ CIDR |

Kỹ thuật chẩn đoán quan trọng nhất từ câu này:

Chỉ MỘT instance hỏng → nghi security group hoặc cấu hình của chính instance đó. CẢ SUBNET hỏng → nghi NACL, route table, hoặc Internet Gateway.

Danh sách kiểm tra khi không SSH được vào EC2 — theo thứ tự: | Bước | Kiểm tra | |---|---| | ① Security group | có rule inbound TCP 22 từ IP của bạn không | | ② Instance ở public subnet | route table có đường ra Internet Gateway không | | ③ Có IP công khai | instance được cấp public IP hoặc Elastic IP chưa | | ④ NACL | inbound 22 và outbound cổng tạm 1024–65535 | | ⑤ Khoá SSH | đúng tệp .pem, quyền chmod 400 | | ⑥ Tường lửa trong hệ điều hành | iptables, firewalld | | ⑦ Instance đã boot xong | kiểm tra status check 2/2 |

Bước ④ có một chi tiết dễ quên: NACL không có trạng thái, nên phải mở cổng tạm ở chiều RA để phản hồi SSH đi được về máy bạn. Security group thì không cần vì nó stateful.

Các cổng thường gặp trong đề thi: | Cổng | Dịch vụ | |---|---| | 22 | SSH (Linux) | | 3389 | RDP (Windows) | | 80 / 443 | HTTP / HTTPS | | 3306 | MySQL, Aurora MySQL | | 5432 | PostgreSQL | | 1433 | SQL Server | | 1521 | Oracle | | 20–21 | FTP | | 25 | SMTP |

Và một lựa chọn tốt hơn hẳn việc mở cổng 22 ra Internet: AWS Systems Manager Session Manager.

Không cần cổng 22 mở
Không cần IP công khai
Không cần quản lý khoá SSH
Ghi log toàn bộ phiên làm việc
Phân quyền bằng IAM

aws ssm start-session --target i-0abc123def456

Instance chỉ cần SSM Agent và IAM role AmazonSSMManagedInstanceCore — với instance trong private subnet thì thêm VPC endpoint cho SSM. Đây là cách AWS khuyến nghị hiện nay cho truy cập quản trị.

Đáp án

A và C.

• A — Bật SSE trên S3 bucket để dùng mã hoá AES-256
• C — Tự mã hoá dữ liệu bằng khoá của mình rồi sao chép lên S3 qua endpoint HTTPS

Vì sao đúng

Đề cần mã hoá khi lưu trữ (at rest) cho dữ liệu trên S3 — và có đúng hai họ giải pháp.

A — mã hoá phía máy chủ (server-side encryption):

S3 nhận dữ liệu → TỰ mã hoá trước khi ghi xuống đĩa
    → SSE-S3: AES-256, khoá do S3 quản lý hoàn toàn
    → không cần đổi mã ứng dụng

Và AES-256 là thuật toán mà đề nêu đích danh.

C — mã hoá phía client (client-side encryption):

Ứng dụng mã hoá dữ liệu TRƯỚC khi gửi
    → S3 chỉ nhận được khối dữ liệu đã mã hoá
    → AWS KHÔNG BAO GIỜ thấy dữ liệu gốc
    → mức kiểm soát cao nhất

Với HIPAA, cả hai đều hợp lệ — và client-side còn mạnh hơn vì nhà cung cấp đám mây không thể giải mã dữ liệu.

(Vế "over HTTPS endpoints" trong phương án C nói về mã hoá khi truyền, nhưng cốt lõi của nó vẫn là client-side encryption — mã hoá bằng khoá của chính bạn.)

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

• **B. Lưu dữ liệu trong EBS snapshot đã mã hoá — đây là phương án gần nhất về mặt cũng là mã hoá at rest, nhưng nó trả lời câu hỏi khác: đề hỏi cách mã hoá dữ liệu trên S3. EBS snapshot là dịch vụ lưu trữ khác, không phải phương pháp mã hoá cho S3.
• **D. Lưu trên EBS volume có mã hoá THAY CHO S3 — đổi cả kiến trúc thay vì trả lời câu hỏi: đề nói dữ liệu đang được sao lưu và lưu trên S3. Và EBS gắn với một AZ, độ bền thấp hơn S3 nhiều.
• **E. Dùng AWS Shield để bảo vệ dữ liệu at rest — nhầm hoàn toàn: Shield là dịch vụ chống tấn công DDoS. Nó không mã hoá bất cứ thứ gì.

Ghi nhớ

Bốn cách mã hoá dữ liệu trên S3: | Cách | Ai giữ khoá | Ai mã hoá | Đặc điểm | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | S3 | AES-256, mặc định, miễn phí | | SSE-KMS | AWS KMS, bạn kiểm soát chính sách | S3 | có audit trail trong CloudTrail | | SSE-C | BẠN — gửi khoá theo mỗi request | S3 | AWS không lưu khoá | | Client-side | BẠN hoàn toàn | ứng dụng của bạn | kiểm soát cao nhất ← C |

Từ 2023, S3 mã hoá SSE-S3 MẶC ĐỊNH cho mọi object mới — nhưng câu hỏi vẫn kiểm tra việc bật tường minh, và với tuân thủ thì cấu hình tường minh vẫn là thực hành tốt.

SSE-S3 và SSE-KMS — chọn cái nào: | | SSE-S3 | SSE-KMS | |---|---|---| | Chi phí | miễn phí | có phí KMS theo request | | Audit ai giải mã | ❌ | ✅ CloudTrail ghi mọi lời gọi Decrypt | | Kiểm soát chính sách khoá | ❌ | ✅ key policy riêng | | Xoay khoá tự động | AWS lo | cấu hình được, hằng năm | | Giới hạn tốc độ | không | có hạn mức request KMS |

Với HIPAA và dữ liệu tài chính, SSE-KMS thường là lựa chọn tốt hơn vì nó cho biết ai đã giải mã dữ liệu nào, lúc nào — thứ mà kiểm toán viên hay hỏi.

Chính sách bắt buộc mã hoá — nên có cho mọi bucket chứa dữ liệu nhạy cảm:

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

Nó chặn ngay tại thời điểm ghi — mạnh hơn việc phát hiện rồi sửa sau.

Ba tầng bảo vệ dữ liệu cho tuân thủ HIPAA trên S3: | Tầng | Cơ chế | |---|---| | Mã hoá at rest | SSE-KMS hoặc client-side ← câu này | | Mã hoá in transit | bucket policy yêu cầu aws:SecureTransport = true | | Kiểm soát truy cập | Block Public Access, bucket policy chặt, IAM tối thiểu |

Chính sách bắt buộc HTTPS:

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

Và một lưu ý pháp lý quan trọng: để lưu dữ liệu y tế được bảo vệ (PHI) trên AWS một cách hợp lệ, tổ chức phải ký Business Associate Addendum (BAA) với AWS và chỉ dùng các dịch vụ đủ điều kiện HIPAA. Mã hoá là điều kiện cần, không phải điều kiện đủ.

Đáp án

B — Tạo một launch template mới.

Vì sao đúng

Đề cần dùng AMI mới để khởi chạy đội EC2 instance trong Auto Scaling group.

Và AMI là thuộc tính nằm trong launch template:

Launch template chứa:
    ✓ AMI ID          ← thứ cần đổi
    ✓ Loại instance
    ✓ Key pair
    ✓ Security group
    ✓ IAM instance profile
    ✓ User data
    ✓ Block device mapping

Điểm mấu chốt: launch template KHÔNG SỬA ĐƯỢC sau khi tạo — nó bất biến.

Muốn đổi AMI:
    → tạo PHIÊN BẢN MỚI của launch template
    → cập nhật ASG trỏ vào phiên bản đó
    → instance mới dùng AMI mới

# Tạo phiên bản mới với AMI mới
aws ec2 create-launch-template-version   --launch-template-name lt-ung-dung-web   --source-version 1   --launch-template-data '{"ImageId":"ami-0moi123"}'

# Trỏ ASG vào phiên bản mới
aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung-web   --launch-template LaunchTemplateName=lt-ung-dung-web,Version='$Latest'

Và instance ĐANG CHẠY không tự đổi sang AMI mới — chỉ instance được khởi chạy sau đó mới dùng. Muốn thay hết thì dùng instance refresh:

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-ung-dung-web   --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

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

• **A. Không cần làm gì, cứ khởi chạy instance trong ASG với cùng launch template — sai về mặt cơ chế: launch template hiện tại trỏ vào AMI cũ. Không đổi gì thì instance mới vẫn dùng AMI cũ.
• **C. Tạo target group mới — nhầm thành phần: target group thuộc về load balancer, nó quản lý danh sách đích nhận lưu lượng và cấu hình health check. Nó không chứa thông tin AMI nào.
• **D. Tạo cả target group lẫn launch template mới — thừa một nửa: phần launch template đúng, nhưng target group không cần đụng tới. Chỉ AMI thay đổi, còn cách phân phối lưu lượng thì không.

Ghi nhớ

Launch template và launch configuration: | | Launch template | Launch configuration | |---|---|---| | Trạng thái | được khuyến nghị | ĐÃ LỖI THỜI — không tạo mới được từ 2023 | | Phiên bản | ✅ nhiều phiên bản, quay lui được | ❌ bất biến hoàn toàn | | Mixed instance policy | ✅ | ❌ | | Spot + On-Demand kết hợp | ✅ | ❌ | | Dùng được ngoài ASG | ✅ (RunInstances, Spot Fleet) | ❌ |

Cả hai đều BẤT BIẾN sau khi tạo — khác biệt là launch template cho phép tạo phiên bản mới trong cùng một template, còn launch configuration thì phải tạo hẳn cái mới.

(Câu hỏi dùng cách nói "tạo launch template mới"; trong thực tế thao tác chuẩn là tạo phiên bản mới của template hiện có rồi trỏ ASG vào $Latest hoặc $Default. Kết quả giống nhau, nhưng cách sau giữ được lịch sử và quay lui dễ hơn.)

Ba cách trỏ ASG vào phiên bản launch template: | Cách khai | Ý nghĩa | |---|---| | Số cụ thể (3) | cố định — kiểm soát chặt nhất | | $Latest | luôn dùng phiên bản mới nhất | | $Default | dùng phiên bản được đánh dấu mặc định |

Với môi trường sản xuất, trỏ vào SỐ CỤ THỂ an toàn hơn: $Latest khiến mọi phiên bản mới lập tức có hiệu lực với instance kế tiếp — kể cả phiên bản bạn vừa tạo để thử.

Ba tuỳ chọn của instance refresh: | Tuỳ chọn | Việc | |---|---| | MinHealthyPercentage | giữ bao nhiêu phần trăm instance lành mạnh trong lúc thay | | InstanceWarmup | thời gian chờ instance mới sẵn sàng trước khi thay tiếp | | CheckpointPercentages | thay theo từng đợt, dừng lại giữa các đợt để kiểm tra |

CheckpointPercentages là cách triển khai canary an toàn: thay 10% trước, dừng lại quan sát, rồi mới tiếp.

Ba lưu ý về AMI trong quy trình triển khai: | Lưu ý | Chi tiết | |---|---| | AMI mang tính Region | sao chép sang Region khác nếu ASG đa Region | | Dùng EC2 Image Builder để tự động nướng AMI | có pipeline, kiểm thử, phân phối | | AMI đã nướng sẵn giảm thời gian khởi động | ít việc phải làm trong user data |

Và một lưu ý vận hành: khi đổi AMI, hãy giữ lại AMI cũ ít nhất vài chu kỳ triển khai. Nếu AMI mới có lỗi chỉ lộ ra sau vài giờ chạy, quay lui bằng cách trỏ ASG về phiên bản launch template cũ là thao tác nhanh nhất — nhưng chỉ được nếu AMI cũ chưa bị xoá đăng ký.

Đáp án

A — Cấu hình Active-Active Failover với chính sách định tuyến Weighted.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều chỉ tới cấu hình active-active: | Yêu cầu | Cơ chế | |---|---| | MỌI tài nguyên đều sẵn sàng càng nhiều càng tốt | active-active — tất cả cùng phục vụ | | Chịu được sự cố của cả một AWS Region | tài nguyên ở nhiều Region | | Route 53 phát hiện tài nguyên hỏng và NGỪNG trả về nó | health check gắn với từng record |

Cách Route 53 làm active-active:

Nhiều record CÙNG TÊN, CÙNG LOẠI
    + mỗi record có HEALTH CHECK riêng
    ↓
Route 53 chỉ trả về các record được đánh giá LÀNH MẠNH
    ↓
Một Region sập → health check thất bại
    → record đó bị loại khỏi câu trả lời
    → lưu lượng tự chuyển sang Region còn lại

Và weighted routing khiến MỌI tài nguyên đều được dùng:

Region A: weight 50   → nhận ~50% lưu lượng
Region B: weight 50   → nhận ~50% lưu lượng
    → cả hai đều ĐANG PHỤC VỤ (active-active)
    → không có tài nguyên nào "ngồi chờ"

Đó chính là "set all of the resources to be available all the time as much as possible" mà đề yêu cầu.

Điểm quan trọng nhất: active-active KHÔNG dùng failover routing policy.

Route 53 hỗ trợ active-active bằng CÁC chính sách:
    weighted, latency-based, geolocation, multivalue answer
    → miễn là mỗi record có health check

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

• **C. Active-Active Failover với một Primary và một Secondary — đây là phương án gần nhất và là bẫy chính: khái niệm "primary/secondary" thuộc về failover routing policy, và đó là cấu hình active-PASSIVE. Secondary chỉ nhận lưu lượng khi primary hỏng — mâu thuẫn với "active-active".
• **B. Active-Passive Failover với Weighted Records — mâu thuẫn nội tại: weighted record khiến mọi tài nguyên cùng phục vụ, tức là active-active. Và active-passive vốn đã kém chịu lỗi hơn vì tài nguyên dự phòng ngồi không.
• **D. Active-Passive Failover với nhiều Primary và Secondary — vẫn là active-passive: dù có nhiều tài nguyên, mô hình này vẫn để một nhóm ngồi chờ. Không đáp ứng "mọi tài nguyên đều sẵn sàng".

Ghi nhớ

Active-active và active-passive trong Route 53: | | Active-active | Active-passive | |---|---|---| | Cấu hình | nhiều record cùng tên + health check | failover routing: PRIMARY và SECONDARY | | Tài nguyên phục vụ | TẤT CẢ cùng lúc | chỉ primary | | Chính sách dùng được | weighted, latency, geolocation, multivalue | chỉ failover | | Tận dụng tài nguyên | tối đa | secondary ngồi không | | Chịu lỗi | cao hơn | phụ thuộc thời gian chuyển đổi |

Quy tắc nhận diện:

Thấy "primary" và "secondary" → failover policy → active-PASSIVE Thấy "all resources available", "distribute traffic" → active-ACTIVE

Bảy chính sách định tuyến của Route 53: | Chính sách | Việc | |---|---| | Simple | một record, không health check | | Weighted | chia lưu lượng theo tỷ lệ — A/B test, active-active ← câu này | | Latency-based | định tuyến tới Region có độ trễ thấp nhất | | Failover | primary / secondary — active-passive | | Geolocation | theo vị trí địa lý của người dùng | | Geoproximity | theo khoảng cách, có bias điều chỉnh được | | Multivalue answer | trả về tới 8 bản ghi lành mạnh — cân bằng tải đơn giản |

Với ứng dụng toàn cầu như đề mô tả, latency-based routing thường cho trải nghiệm tốt hơn weighted — nó tự đưa người dùng tới Region gần nhất về mặt độ trễ mạng. Weighted vẫn đúng theo bộ đề, và phù hợp khi bạn muốn kiểm soát tỷ lệ tường minh (ví dụ Region mới chỉ nhận 10% để quan sát).

Ba loại health check của Route 53: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ cụ thể | | Calculated | kết hợp kết quả của nhiều health check khác | | CloudWatch alarm | dựa trên trạng thái của một alarm |

Calculated health check rất hữu ích cho kiến trúc nhiều tầng: coi một Region là lành mạnh chỉ khi cả web tier lẫn database tier đều lành mạnh.

Ba cấu hình health check ảnh hưởng tới thời gian chuyển đổi: | Cấu hình | Ảnh hưởng | |---|---| | Request interval | 10 giây (fast) hoặc 30 giây | | Failure threshold | số lần lỗi liên tiếp trước khi coi là hỏng | | TTL của record | client vẫn dùng câu trả lời cũ tới khi hết TTL |

TTL là yếu tố hay bị bỏ sót: dù Route 53 loại record hỏng ngay lập tức, client đã cache câu trả lời cũ vẫn tiếp tục gọi tới Region đã sập cho tới khi TTL hết. Với record dùng cho failover, đặt TTL thấp (60 giây hoặc ít hơn).

Và một lưu ý về chi phí và độ phức tạp: kiến trúc đa Region active-active nhân đôi chi phí hạ tầng và đòi hỏi giải quyết bài toán đồng bộ dữ liệu giữa các Region — DynamoDB Global Tables hoặc Aurora Global Database. Với dịch vụ chuyển tiền quốc tế 24/7 như đề mô tả thì xứng đáng, nhưng đó là quyết định cần cân nhắc chứ không phải mặc định.

Đáp án

C — Dùng AWS Fargate trên Amazon EKS với Service Auto Scaling.

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp EKS + Fargate đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Nền tảng dùng KUBERNETES | EKS là Kubernetes được quản lý | | Bỏ nhu cầu cấp phát và quản lý máy chủ | Fargate — không có node nào để quản lý | | Khai và trả tiền theo tài nguyên MỖI ỨNG DỤNG | Fargate tính phí theo vCPU và bộ nhớ của từng pod | | Tăng bảo mật qua CÁCH LY ứng dụng ngay từ thiết kế | mỗi pod chạy trong môi trường ảo hoá RIÊNG |

Điểm mạnh nhất của Fargate cho ngân hàng trực tuyến là cách ly:

EC2 launch type:
    Nhiều pod CHIA SẺ một node
        → chia sẻ nhân hệ điều hành
        → lỗ hổng thoát container ảnh hưởng pod khác

Fargate:
    MỖI pod có ranh giới ảo hoá RIÊNG
        → không chia sẻ nhân với pod khác
        → "application isolation BY DESIGN" như đề nói

Và mô hình tính phí khớp với "pay for resources per application":

EC2 launch type:  trả tiền cho NODE, dù pod dùng hết hay không
Fargate:          trả tiền theo vCPU và RAM mà POD yêu cầu

Service Auto Scaling (qua Horizontal Pod Autoscaler) tự điều chỉnh số pod theo tải — và với Fargate, mỗi pod mới tự có tài nguyên riêng, không cần lo node có đủ chỗ không.

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

• **A. Dùng Amazon ECS để chạy cụm Kubernetes trên Fargate — sai về mặt khái niệm: ECS là bộ điều phối container RIÊNG của AWS, nó không chạy Kubernetes. Dịch vụ Kubernetes của AWS là EKS. Đề nói rõ nền tảng dùng Kubernetes.
• **D. Triển khai EKS trên AWS Outposts với Cluster Autoscaler và đồng bộ pod mồ côi bằng Amazon AppFlow — hai lỗi: Outposts là phần cứng AWS đặt tại trung tâm dữ liệu của bạn — bạn vẫn phải quản lý máy chủ vật lý, ngược hẳn yêu cầu. Và AppFlow là dịch vụ tích hợp dữ liệu SaaS (Salesforce, Slack...), nó không "đồng bộ pod" gì cả.
• **B. Chạy ứng dụng trên Amazon EMR Serverless với EBS bật fast snapshot restore — sai loại dịch vụ: EMR Serverless dành cho xử lý dữ liệu lớn (Spark, Hive), không phải chạy microservice Kubernetes.

Ghi nhớ

Bốn cách chạy container trên AWS: | Cách | Bộ điều phối | Quản lý máy chủ | |---|---|---| | ECS trên EC2 | ECS | bạn quản lý node | | ECS trên Fargate | ECS | không có node | | EKS trên EC2 | Kubernetes | bạn quản lý node | | EKS trên Fargate | Kubernetes | không có node ← câu này |

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

"Kubernetes", "kubectl", "pod", "helm" → EKS "serverless", "no servers to manage", "per-application pricing" → Fargate Cả hai → EKS trên Fargate

ECS và EKS — chọn cái nào: | | ECS | EKS | |---|---|---| | Độ phức tạp | thấp hơn | cao hơn | | Chuẩn mở | ❌ riêng của AWS | ✅ Kubernetes | | Di chuyển sang nơi khác | khó | dễ — Kubernetes chạy ở đâu cũng được | | Phí control plane | miễn phí | ~0,10 USD/giờ mỗi cụm | | Hệ sinh thái công cụ | AWS | rất lớn — Helm, Istio, ArgoCD... |

Ba giới hạn của EKS trên Fargate — cần biết trước khi chọn: | Giới hạn | Chi tiết | |---|---| | Không hỗ trợ DaemonSet | agent giám sát phải chạy dạng sidecar | | Không dùng được GPU | workload học máy phải dùng node EC2 | | Chỉ dùng EFS cho lưu trữ bền vững | không gắn EBS trực tiếp | | Không có privileged container | một số công cụ hệ thống không chạy được |

Dòng đầu ảnh hưởng trực tiếp tới vận hành: các công cụ giám sát và thu thập log thường triển khai dạng DaemonSet. Với Fargate, phải chuyển sang mô hình sidecar hoặc dùng Fluent Bit built-in log routing của Fargate.

Ba loại auto scaling trong Kubernetes: | Loại | Điều chỉnh | |---|---| | Horizontal Pod Autoscaler (HPA) | SỐ LƯỢNG pod theo CPU, bộ nhớ, hoặc metric tuỳ chỉnh | | Vertical Pod Autoscaler (VPA) | tài nguyên yêu cầu của mỗi pod | | Cluster Autoscaler / Karpenter | số node — KHÔNG cần với Fargate |

Với Fargate, bạn chỉ cần HPA — không có node để mở rộng, nên tầng thứ ba biến mất hoàn toàn. Đó là phần đơn giản hoá lớn nhất mà Fargate mang lại.

Ba cấu hình bảo mật nên có cho nền tảng ngân hàng trên EKS: | Cấu hình | Lý do | |---|---| | IRSA (IAM Roles for Service Accounts) | mỗi pod có quyền IAM riêng, tối thiểu | | Network policy | kiểm soát pod nào gọi được pod nào | | Quét image trong ECR | phát hiện lỗ hổng trước khi triển khai | | Secrets từ Secrets Manager qua CSI driver | không nhúng bí mật vào image |

IRSA là thực hành quan trọng nhất: thay vì gắn một IAM role rộng cho cả node, mỗi service account của Kubernetes ánh xạ sang một IAM role riêng — nguyên tắc quyền tối thiểu áp được tới từng microservice.

Và một cân nhắc về chi phí: Fargate đắt hơn EC2 tính theo đơn vị vCPU-giờ, nhưng nó loại bỏ phần dung lượng thừa của node và toàn bộ công vận hành. Với microservice nhỏ, tải biến động — đúng như đề mô tả — tổng chi phí thường thấp hơn; với workload lớn chạy liên tục, node EC2 kèm Savings Plan thường rẻ hơn.

Đáp án

D — Amazon S3 để lưu tệp log của ELB và Amazon EMR để phân tích.

Vì sao đúng

Đề cần hai việc: thu thập log của Application Load Balancer và phân tích chúng ở quy mô lớn.

S3 là đích lưu log GỐC của ELB — không có lựa chọn khác:

Access log của ALB được cấu hình ghi THẲNG vào S3
    → không cần agent, không cần ứng dụng trung gian
    → tệp nén gzip, phân vùng theo thời gian

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn>   --attributes Key=access_logs.s3.enabled,Value=true                Key=access_logs.s3.bucket,Value=kho-log-alb

Và EMR là dịch vụ phân tích dữ liệu lớn được quản lý:

EMR chạy Hadoop, Spark, Hive, Presto trên cụm được quản lý
    → đọc THẲNG từ S3 (qua EMRFS)
    → xử lý song song trên nhiều node
    → phù hợp với "all combined log files" của một công ty viễn thông lớn

Và cụm từ "easily perform log analysis" trong đề loại các phương án tự viết: EMR cung cấp sẵn công cụ phân tích, không phải viết ứng dụng từ đầu.

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

• **C. S3 để lưu log và một EC2 instance với ứng dụng TỰ VIẾT để phân tích — đây là phương án gần nhất và phần lưu trữ hoàn toàn đúng, nhưng nó thua ở phần phân tích: tự viết ứng dụng phân tích không phải là "easily", và một instance đơn không xử lý nổi khối lượng log của một nhà mạng lớn.
• **B. EC2 với EBS volume cho cả lưu trữ lẫn phân tích — sai ở cả hai vế: ALB không ghi log vào EBS được (nó chỉ ghi vào S3), và EBS gắn với một AZ, dung lượng có hạn, độ bền thấp hơn S3 nhiều.
• **A. DynamoDB để lưu và EC2 để phân tích — sai loại cơ sở dữ liệu: DynamoDB là kho khoá–giá trị cho truy cập theo khoá với độ trễ thấp. Nó không phù hợp để quét toàn bộ phục vụ phân tích, và chi phí lưu hàng terabyte log ở đó rất cao.

Ghi nhớ

Ba cách phân tích log lưu trên S3 — chọn theo nhu cầu: | Cách | Đặc điểm | Phù hợp | |---|---|---| | Amazon Athena | truy vấn SQL, KHÔNG máy chủ, trả tiền theo dữ liệu quét | truy vấn thỉnh thoảng, đơn giản nhất | | Amazon EMR | cụm Hadoop/Spark, xử lý phức tạp | ETL nặng, học máy, quy mô rất lớn ← câu này | | Redshift Spectrum | truy vấn S3 từ Redshift | đã có kho dữ liệu Redshift | | OpenSearch Service | tìm kiếm và trực quan hoá gần thời gian thực | điều tra sự cố, dashboard |

Athena là lựa chọn đơn giản hơn cho phần lớn tình huống phân tích log — không có cụm nào để quản lý, và nó đọc trực tiếp access log của ALB:

CREATE EXTERNAL TABLE alb_logs (
  type string, time string, elb string,
  client_ip string, target_ip string,
  request_processing_time double,
  elb_status_code string, request_verb string, request_url string
) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
LOCATION 's3://kho-log-alb/AWSLogs/123456789012/elasticloadbalancing/';

(EMR vẫn là đáp án đúng theo bộ đề, và nó thực sự phù hợp hơn khi khối lượng rất lớn hoặc cần xử lý phức tạp ngoài SQL.)

Ba loại log của Elastic Load Balancer: | Log | Nội dung | Đích | |---|---|---| | Access log | mọi request: IP, độ trễ, mã trạng thái | S3 | | Connection log | thông tin kết nối TLS của client | S3 | | CloudWatch metric | số liệu tổng hợp | CloudWatch |

Access log KHÔNG bật mặc định — phải bật tường minh, và nó miễn phí ngoài chi phí lưu trữ S3.

Ba tối ưu quan trọng khi phân tích log ở quy mô lớn: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo ngày/giờ | truy vấn chỉ quét phân vùng cần — giảm mạnh chi phí | | Chuyển sang Parquet | giảm 80–90% dữ liệu quét so với text | | Nén dữ liệu | ít I/O hơn |

Chuyển đổi sang Parquet là tối ưu có hiệu quả lớn nhất: log ALB dạng text nén gzip vẫn phải giải nén và quét toàn bộ; Parquet là định dạng cột nên truy vấn chỉ đọc các cột cần thiết.

Ba lưu ý về chi phí lưu log: | Lưu ý | Cách xử lý | |---|---| | Log tích tụ rất nhanh | lifecycle rule chuyển sang Glacier hoặc xoá | | Quy định lưu trữ có thể yêu cầu giữ nhiều năm | Glacier Deep Archive rất rẻ | | Athena tính phí theo dữ liệu QUÉT | phân vùng và Parquet giảm mạnh khoản này |

Lifecycle rule mẫu cho bucket log:

{"Rules": [{
  "Status": "Enabled", "Filter": {"Prefix": "AWSLogs/"},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"},
                  {"Days": 90, "StorageClass": "GLACIER"}],
  "Expiration": {"Days": 2555}
}]}

Và một lưu ý về EMR cho tình huống của đề: nếu công việc phân tích chỉ chạy định kỳ chứ không liên tục, dùng transient cluster — cụm tự dựng lên, chạy xong công việc rồi tự tắt. Nó rẻ hơn nhiều so với cụm chạy 24/7, và kết hợp với Spot Instance cho node task thì chi phí giảm thêm đáng kể.

Đáp án

A — Chuyển audio thành văn bản bằng Amazon Transcribe; dùng Amazon Translate dịch tiếng Hindi sang tiếng Anh; dùng Amazon Comprehend để phân tích cảm xúc.

Vì sao đúng

Đề yêu cầu ba bước xử lý, và mỗi bước có đúng một dịch vụ AWS tương ứng: | Bước | Dịch vụ | Việc | |---|---|---| | ① Audio → văn bản | Amazon Transcribe | nhận dạng giọng nói | | ② Hindi → tiếng Anh | Amazon Translate | dịch máy thần kinh | | ③ Phân tích cảm xúc | Amazon Comprehend | NLP: sentiment, thực thể, chủ đề |

Và vế "without maintaining any machine learning model" là điều kiện quyết định:

Cả ba dịch vụ đều là AI ĐƯỢC QUẢN LÝ SẴN
    → gọi API là xong
    → không huấn luyện, không triển khai, không bảo trì mô hình
    → khác hẳn SageMaker (bạn phải tự làm mọi thứ đó)

Và kiến trúc này mở rộng sang ngôn ngữ mới rất dễ — đúng như đề dự tính (tiếng Ả Rập, tiếng Trung, tiếng Tây Ban Nha):

Transcribe hỗ trợ hơn 100 ngôn ngữ
Translate hỗ trợ hơn 75 ngôn ngữ
    → thêm ngôn ngữ = đổi tham số, KHÔNG đổi kiến trúc

Luồng đầy đủ trong thực tế:

Ghi âm cuộc gọi → S3
    ↓ S3 event
Lambda gọi Transcribe (StartTranscriptionJob)
    ↓ kết quả JSON về S3
Nếu ngôn ngữ ≠ tiếng Anh → Translate
    ↓
Comprehend DetectSentiment → POSITIVE / NEGATIVE / NEUTRAL / MIXED
    ↓
Lưu kết quả vào DynamoDB, dựng báo cáo

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

• **B. Dùng Amazon Polly StartSpeechSynthesisTask để chuyển audio thành văn bản; Rekognition để dịch; Fraud Detector + SageMaker BlazingText cho cảm xúc — sai cả ba dịch vụ: Polly làm NGƯỢC LẠI — nó chuyển văn bản thành giọng nói. Rekognition phân tích ẢNH và VIDEO, không dịch văn bản. Và SageMaker đòi bạn tự huấn luyện mô hình — vi phạm yêu cầu của đề.
• **C. Dùng Amazon Lex để chuyển audio thành văn bản; Translate để dịch; SageMaker Clarify cho cảm xúc — hai lỗi: Lex là dịch vụ xây CHATBOT (nhận diện ý định trong hội thoại), không phải công cụ phiên âm hàng loạt. Và SageMaker Clarify dùng để phát hiện THIÊN LỆCH và giải thích mô hình, không dự đoán cảm xúc.
• **D. Dùng Comprehend để chuyển audio thành văn bản; Kendra để dịch; Detective cho cảm xúc — cả ba đều sai vai: Comprehend xử lý văn bản, không xử lý audio. Kendra là công cụ TÌM KIẾM DOANH NGHIỆP. Và Amazon Detective là dịch vụ ĐIỀU TRA BẢO MẬT, không liên quan gì tới ngôn ngữ.

Ghi nhớ

Các dịch vụ AI được quản lý sẵn của AWS — bảng cần thuộc: | Dịch vụ | Đầu vào → đầu ra | |---|---| | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói (ngược với Transcribe) | | Translate | văn bản ngôn ngữ A → ngôn ngữ B | | Comprehend | văn bản → cảm xúc, thực thể, chủ đề, ngôn ngữ, PII | | Rekognition | ảnh và video → nhãn, khuôn mặt, văn bản trong ảnh | | Textract | tài liệu quét → văn bản, bảng, biểu mẫu | | Lex | hội thoại → ý định (chatbot) | | Kendra | câu hỏi → tài liệu liên quan (tìm kiếm) | | Personalize | hành vi → gợi ý | | Forecast | chuỗi thời gian → dự báo | | Fraud Detector | giao dịch → điểm rủi ro gian lận |

Cặp dễ nhầm nhất là Transcribe và Polly — hãy nhớ Polly là con vẹt (nói ra tiếng), Transcribe là người chép lại.

Bốn giá trị cảm xúc mà Comprehend trả về: | Giá trị | Ý nghĩa | |---|---| | POSITIVE | tích cực | | NEGATIVE | tiêu cực | | NEUTRAL | trung tính | | MIXED | vừa tích cực vừa tiêu cực trong cùng văn bản |

r = comprehend.detect_sentiment(Text=van_ban, LanguageCode='en')
print(r['Sentiment'], r['SentimentScore'])
# NEGATIVE {'Positive': 0.02, 'Negative': 0.93, ...}

Nên dùng cả điểm số chứ không chỉ nhãn — một cuộc gọi NEGATIVE với điểm 0,51 rất khác một cuộc gọi 0,98.

Ba tính năng của Transcribe đáng biết cho tình huống trung tâm cuộc gọi: | Tính năng | Việc | |---|---| | Speaker diarization | tách lời của nhân viên và của khách hàng | | Custom vocabulary | nhận đúng tên sản phẩm, thuật ngữ ngành | | Automatic language identification | tự nhận ngôn ngữ — không cần khai trước | | PII redaction | tự che số thẻ, số điện thoại trong bản ghi |

Speaker diarization đặc biệt quan trọng ở đây: nếu không tách người nói, cảm xúc tiêu cực của khách hàng và lời trấn an của nhân viên bị trộn lẫn, kết quả phân tích mất ý nghĩa.

Và automatic language identification giải quyết trực tiếp vấn đề đa ngôn ngữ của đề — không cần biết trước cuộc gọi là tiếng Anh hay tiếng Hindi:

transcribe.start_transcription_job(
    TranscriptionJobName='cuoc-goi-001',
    Media={'MediaFileUri': 's3://ghi-am/cuoc-goi-001.mp3'},
    IdentifyLanguage=True,
    LanguageOptions=['en-US', 'hi-IN', 'ar-AE', 'es-ES'],
    Settings={'ShowSpeakerLabels': True, 'MaxSpeakerLabels': 2})

Và một lựa chọn dựng sẵn cho chính bài toán này: Amazon Connect Contact Lens. Nếu trung tâm cuộc gọi dùng Amazon Connect, Contact Lens đã tích hợp sẵn phiên âm, phân tích cảm xúc, phát hiện khoảng lặng và từ khoá — không cần tự ghép ba dịch vụ. Với hệ thống tổng đài khác thì kiến trúc ba bước ở trên là cách đúng.