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

Đáp án

D — Đặt một thiết bị AWS Snowball Edge Storage Optimized, chép dữ liệu lên đó, và tạo công việc chuyển đổi tuỳ chỉnh bằng AWS Glue.

Vì sao đúng

Đề nêu ba dữ kiện, và mỗi cái quyết định một phần: | Dữ kiện | Kết luận | |---|---| | 45 TB và băng thông ĐÃ BÃO HOÀ | không truyền qua mạng được → Snowball | | Công việc chuyển đổi phải tiếp tục chạy trên AWS | cần một dịch vụ ETL | | CÔNG VẬN HÀNH ÍT NHẤT | Glue — serverless, không máy chủ |

⚠ "Băng thông đã bão hoà" loại ngay DataSync:

DataSync truyền qua chính đường mạng đó
    → đường đã đầy thì không có chỗ cho nó
        ↓
    Và đề nói "bắt đầu càng sớm càng tốt"
    → chờ đường mạng rảnh không phải lựa chọn

Ước lượng thời gian nếu cố truyền qua mạng:

45 TB qua đường 100 Mbps (giả sử rảnh hoàn toàn)
    → ~41 ngày
        ↓
    Snowball Edge: đặt hàng, chép, gửi về
    → thường trong vòng 1-2 tuần

Đặt thiết bị:

aws snowball create-job --job-type IMPORT \
  --snowball-type EDGE_S \
  --resources '{"S3Resources":[{"BucketArn":
    "arn:aws:s3:::kho-bao-cao"}]}' \
  --address-id <id-dia-chi> \
  --role-arn <arn-role> \
  --kms-key-arn <arn-khoa> \
  --description "Nhap 45TB du lieu bao cao"

Chép dữ liệu lên thiết bị:

snowballEdge unlock-device --endpoint https://192.168.1.100 \
  --manifest-file manifest.bin --unlock-code <ma>

aws s3 cp /du-lieu s3://kho-bao-cao/ --recursive \
  --endpoint http://192.168.1.100:8080

⚠ Vì sao Glue chứ không phải EC2 trên thiết bị:

Phương án C: dùng Snowball Edge có EC2 compute,
             rồi chạy ứng dụng cũ trên EC2 ở AWS
    → vẫn phải quản lý máy, vá, mở rộng
        ↓
Glue: serverless, chỉ định nghĩa công việc
    → không có gì để vận hành

Công việc Glue:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

ngu_canh = GlueContext(SparkContext.getOrCreate())
du_lieu = ngu_canh.create_dynamic_frame.from_catalog(
    database="kho_bao_cao", table_name="du_lieu_tho")

ket_qua = du_lieu.apply_mapping([
    ("ma_kh", "string", "ma_khach_hang", "string"),
    ("gia_tri", "double", "gia_tri", "double")])

ngu_canh.write_dynamic_frame.from_options(
    frame=ket_qua, connection_type="s3",
    connection_options={"path": "s3://kho-bao-cao/da-xu-ly/",
                        "partitionKeys": ["nam", "thang"]},
    format="parquet")

Chạy hằng tuần bằng trigger:

aws glue create-trigger --name chay-hang-tuan \
  --type SCHEDULED --schedule "cron(0 2 ? * MON *)" \
  --actions JobName=chuyen-doi-bao-cao --start-on-creation

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chiếm băng thông của trung tâm dữ liệu | | | Glue không có hạ tầng phải quản lý | | | Thiết bị mã hoá, có theo dõi vận chuyển | |

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

• **C. Snowball Edge có EC2 compute, triển khai ứng dụng chuyển đổi lên EC2 — đây là phương án gần nhất và hoàn toàn chạy được, nhưng giữ lại ứng dụng tự viết trên máy chủ tự quản lý, tức là công vận hành cao hơn Glue. Đề nói "LEAST operational overhead".
• **A. Dùng DataSync — truyền qua đúng đường mạng đã bão hoà; không khả thi trong ràng buộc của đề.
• **B. Dùng Snowcone và triển khai ứng dụng lên thiết bị — Snowcone chỉ chứa 8 TB (HDD) hoặc 14 TB (SSD), không đủ cho 45 TB.

Ghi nhớ

⚠ Họ Snow — bảng dung lượng phải thuộc: | Thiết bị | Dung lượng dùng được | Có compute | |---|---|---| | Snowcone | 8 TB HDD / 14 TB SSD | có, rất nhỏ | | Snowball Edge Storage Optimized | ~80 TB | có | | Snowball Edge Compute Optimized | ~28 TB | mạnh, có GPU tuỳ chọn | | Snowmobile | tới 100 PB | không |

⚠ AWS Snowball "nguyên bản" đã ngừng — hiện chỉ còn Snowball Edge. Đề cũ hay nhắc "AWS Snowball" trần; hiểu là Snowball Edge.

Từ khoá nhận diện:

"bandwidth saturated / limited, TB-PB scale" → Snowball Edge "under ~10 TB, has bandwidth" → DataSync "exabyte scale" → Snowmobile "serverless ETL, least overhead" → Glue "need custom compute at the edge" → Snowball Edge Compute Optimized

⚠ Công thức quyết định Snowball hay mạng:

Thời gian truyền (ngày)
  = dung lượng (TB) × 8000 / (băng thông Mbps × 86,4)
        ↓
    Quá một tuần → cân nhắc Snowball
    Quá một tháng → chắc chắn Snowball

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | Mã hoá 256-bit, khoá quản lý bằng KMS | | | Chống giả mạo, có Trusted Platform Module | | | AWS xoá sạch theo chuẩn NIST sau khi nhập | |

Ba giai đoạn của một job: | Giai đoạn | Thời gian tham khảo | |---|---| | Chuẩn bị và vận chuyển tới | vài ngày | | Chép dữ liệu tại chỗ | tuỳ tốc độ đĩa nguồn | | Gửi về và nhập vào S3 | vài ngày |

⚠ Chép dữ liệu lên thiết bị thường là khâu chậm nhất:

Snowball Edge nhận tới ~1 GB/s qua 10 GbE
    → nhưng nguồn NAS cũ chỉ đọc được 200 MB/s
        ↓
    45 TB ở 200 MB/s ≈ 62 giờ
    → dùng nhiều luồng song song, nhiều thiết bị

Ba lưu ý về nhiều thiết bị: | Lưu ý | Chi tiết | |---|---| | Đặt nhiều thiết bị chạy song song | | | Rút ngắn tổng thời gian đáng kể | | | Mỗi thiết bị một job riêng | |

Ba lưu ý về Glue: | Lưu ý | Chi tiết | |---|---| | Tính theo DPU-giờ, tối thiểu 1 phút | | | Crawler tự suy ra schema | | | Glue Studio có giao diện kéo thả | |

⚠ Glue có ba loại job — chọn đúng loại: | Loại | Dùng cho | |---|---| | Spark | dữ liệu lớn, phân tán | | Python shell | script nhỏ, một máy | | Streaming | luồng liên tục |

45 TB xử lý theo lô hằng tuần
    → Spark job
        ↓
    Python shell chỉ hợp cho việc nhỏ (dưới vài GB)

Ba lưu ý về Glue Data Catalog: | Lưu ý | Chi tiết | |---|---| | Athena, Redshift Spectrum, EMR dùng chung | | | Crawler chạy theo lịch cập nhật schema | | | Phân vùng đăng ký trong catalog | |

Ba lựa chọn khác cho ETL: | Dịch vụ | Khi nào | |---|---| | EMR | cần kiểm soát cụm Spark/Hadoop | | Batch | job container tuỳ ý | | Step Functions + Lambda | luồng công việc nhẹ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So checksum trước và sau khi nhập | | | Đếm số object trong S3 | | | Chạy thử job Glue trên tập nhỏ | |

aws s3 ls s3://kho-bao-cao/ --recursive --summarize \
  | tail -3

Và một lời khuyên: hãy đo tốc độ đọc của hệ thống lưu trữ nguồn trước khi đặt thiết bị. Snowball Edge nhận dữ liệu rất nhanh, nhưng tổng thời gian được quyết định bởi đầu chậm hơn — và nếu NAS cũ chỉ đọc được 200 MB/s thì việc đặt một thiết bị hay ba thiết bị cũng cho ra cùng một lịch trình.

Đáp án

A — Đặt 7 thiết bị Snowball với đích là một bucket S3, rồi tạo lifecycle policy chuyển object sang S3 Glacier.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án này khớp cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | 500 TB, đường Internet băng thông thấp | Snowball — không dùng mạng | | Không được làm nghẽn đường mạng | dữ liệu đi bằng đường vận chuyển vật lý | | Xong trong vài tuần | 7 thiết bị chạy song song |

⚠ Chi tiết quyết định: Snowball KHÔNG nhập thẳng vào Glacier được.

Đích nhập của Snowball chỉ có thể là BUCKET S3
    → không có tuỳ chọn nhập vào S3 Glacier vault
        ↓
    Nhập vào S3 → lifecycle chuyển sang Glacier
    → đây là con đường duy nhất

Đây chính là điều làm phương án C sai.

Vì sao 7 thiết bị:

Snowball Edge Storage Optimized ≈ 80 TB dùng được
    → 500 / 80 ≈ 6,25
        ↓
    7 thiết bị, chạy song song
    → tổng thời gian ≈ thời gian của MỘT thiết bị

Lifecycle chuyển sang Glacier:

aws s3api put-bucket-lifecycle-configuration \
  --bucket kho-luu-tru \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "chuyen-sang-glacier",
      "Filter": {"Prefix": ""},
      "Status": "Enabled",
      "Transitions": [{
        "Days": 0,
        "StorageClass": "GLACIER"}]}]}'

⚠ Days: 0 chuyển ngay khi object được tạo — không phải chờ ngày nào.

Ước lượng nếu cố truyền qua mạng:

500 TB qua đường 100 Mbps
    → ~463 ngày
        ↓
    Qua đường 1 Gbps (nếu có, và rảnh hoàn toàn)
    → ~46 ngày, và làm nghẽn mọi thứ khác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đụng tới băng thông | | | Rẻ hơn nâng cấp đường truyền cho một lần dùng | | | Thiết bị mã hoá và chống giả mạo | |

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

• **C. 7 thiết bị Snowball với đích là S3 Glacier vault — đây là phương án gần nhất và chỉ sai đúng một chi tiết kỹ thuật: Snowball không nhập trực tiếp vào Glacier vault. Phần "bucket policy ép VPC endpoint" cũng không liên quan gì tới yêu cầu của đề.
• **B. Direct Connect rồi truyền thẳng vào Glacier — dựng Direct Connect mất nhiều tuần tới nhiều tháng, và đề chỉ cần chuyển một lần; đầu tư một đường riêng cho một lần di chuyển là không hợp lý.
• **D. Dùng Global Accelerator để tăng tốc tải lên — Global Accelerator cải thiện định tuyến, nhưng không tăng băng thông của đường Internet ở đầu công ty. Nút thắt vẫn nguyên.

Ghi nhớ về chất lượng câu hỏi

⚠ Hai chỗ trong đề này đã lỗi thời:

Chính vì Glacier giờ là lớp lưu trữ của S3
    → cách duy nhất đưa dữ liệu vào là qua S3
    → rồi chuyển lớp bằng lifecycle
        ↓
    Nói cách khác, sự lỗi thời của thuật ngữ
    chính là lý do đáp án A đúng

Dịch vụ S3 Glacier vault kiểu cũ (với archive ID thay vì tên object) vẫn tồn tại cho khách hàng lâu năm, nhưng AWS không khuyến nghị dùng cho thiết kế mới.

Ghi nhớ

⚠ Ba lớp Glacier — bảng phải thuộc: | Lớp | Thời gian lấy | Giá tham khảo/GB-tháng | |---|---|---| | Glacier Instant Retrieval | mili giây | ~0,004 USD | | Glacier Flexible Retrieval | 1-5 phút tới 5-12 giờ | ~0,0036 USD | | Glacier Deep Archive | 12-48 giờ | ~0,00099 USD |

⚠ "S3 Glacier" trong lifecycle = Flexible Retrieval.

Ba chế độ lấy dữ liệu của Flexible Retrieval: | Chế độ | Thời gian | Chi phí | |---|---|---| | Expedited | 1-5 phút | đắt nhất | | Standard | 3-5 giờ | trung bình | | Bulk | 5-12 giờ | rẻ nhất |

Từ khoá nhận diện:

"petabytes, low bandwidth" → Snowball Edge "exabytes" → Snowmobile "archive, rarely accessed, cheapest" → Glacier Deep Archive "archive but need millisecond access" → Glacier Instant Retrieval

⚠ Bốn thời gian tối thiểu phải nhớ: | Lớp | Lưu tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant Retrieval | 90 ngày | | Glacier Flexible Retrieval | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá sớm hơn thời gian tối thiểu
    → vẫn tính đủ tiền cho khoảng đó
        ↓
    Đặt lifecycle sang Deep Archive rồi xoá sau 60 ngày
    = trả tiền 180 ngày

Ba lưu ý về object nhỏ: | Lưu ý | Chi tiết | |---|---| | Mỗi object Glacier tốn ~40 KB siêu dữ liệu | | | Object dưới 128 KB không nên chuyển | | | Gộp object nhỏ trước khi lưu trữ | |

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | ~80 TB dùng được (Storage Optimized) | | | Chép qua giao diện S3 hoặc NFS | | | Nhiều thiết bị chạy song song | |

⚠ Snowball Edge cũng hỗ trợ mount NFS — tiện khi công cụ hiện có chỉ biết nói NFS:

snowballEdge start-service --service-id nfs \
  --virtual-network-interface-arns <arn>

Ba lưu ý về chi phí Snowball: | Khoản | Chi tiết | |---|---| | Phí thuê mỗi job | | | Phí ngày nếu giữ quá thời hạn | | | Nhập dữ liệu vào AWS MIỄN PHÍ | |

⚠ Nhập miễn phí nhưng xuất thì tính phí — đưa dữ liệu ra khỏi AWS bằng Snowball vẫn tính phí truyền dữ liệu ra.

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá 256-bit bằng khoá KMS của bạn | | | Manifest và unlock code gửi riêng | | | E-ink hiển thị địa chỉ trả về, không cần dán nhãn | |

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Chuyển lớp diễn ra bất đồng bộ | | | Có thể mất tới 48 giờ để hoàn tất | | | Phí chuyển tính theo số object | |

⚠ Phí chuyển theo số object là chỗ hay bị bất ngờ:

500 TB gồm 100 triệu tệp nhỏ
    → phí chuyển lớp ~0,05 USD mỗi 1000 object
    → ~5.000 USD chỉ riêng tiền chuyển
        ↓
    Gộp tệp nhỏ trước khi chép lên Snowball

Ba lưu ý về S3 Intelligent-Tiering (lựa chọn thay thế): | Lưu ý | Chi tiết | |---|---| | Tự chuyển lớp theo mẫu truy cập | | | Không có phí lấy dữ liệu | | | Có phí giám sát mỗi object | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm object và dung lượng sau khi nhập | | | Kiểm tra lớp lưu trữ đã chuyển | | | Thử khôi phục một object từ Glacier | |

aws s3api list-objects-v2 --bucket kho-luu-tru --max-items 5 \
  --query "Contents[].[Key,StorageClass]" --output table

Và một lời khuyên: hãy gộp các tệp nhỏ thành gói lớn trước khi chép lên Snowball. Glacier tính phí siêu dữ liệu cho mỗi object và tính phí cho mỗi lần chuyển lớp, nên 100 triệu tệp nhỏ có thể tốn hơn cả tiền lưu trữ của chính khối dữ liệu đó trong nhiều tháng.

Đáp án

D — Tạo AMI để sao lưu instance, chép AMI sang Region thứ hai, và tự động hoá việc triển khai hạ tầng ở Region đó bằng AWS CloudFormation.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này cân bằng đúng giữa chúng: | Yêu cầu | Cách đáp ứng | |---|---| | RTO ≤ 4 giờ | dựng từ AMI + CloudFormation mất chưa tới một giờ | | Dùng ÍT tài nguyên nhất lúc bình thường | không có gì chạy ở Region phụ | | Tiết kiệm chi phí | chỉ trả tiền lưu trữ AMI |

⚠ RTO 4 giờ là khoảng rất rộng — đủ để dựng lại từ đầu:

RTO 4 giờ cho phép chiến lược Backup & Restore
    → không cần giữ máy chạy sẵn
        ↓
    Dựng từ AMI + CloudFormation: 20-40 phút
    → dư dả so với 4 giờ

Chép AMI sang Region thứ hai:

aws ec2 copy-image --source-region ap-southeast-1 \
  --source-image-id ami-abc --region ap-northeast-1 \
  --name "ung-dung-ban-sao" --encrypted --kms-key-id <arn-khoa>

Tự động hoá bằng DLM cho cả AMI lẫn việc chép:

aws dlm create-lifecycle-policy \
  --description "AMI hang ngay + chep xuyen vung" \
  --state ENABLED --execution-role-arn <arn-role> \
  --policy-details '{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes": ["INSTANCE"],
    "TargetTags": [{"Key": "DR", "Value": "co"}],
    "Schedules": [{
      "Name": "hang-ngay",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS",
                     "Times": ["17:00"]},
      "RetainRule": {"Count": 7},
      "CrossRegionCopyRules": [{
        "TargetRegion": "ap-northeast-1",
        "Encrypted": true,
        "RetainRule": {"Interval": 7, "IntervalUnit": "DAYS"}}]}]}'

⚠ Vì sao CloudFormation hơn "Lambda và script tuỳ chỉnh": | Tiêu chí | CloudFormation | Lambda + script | |---|---|---| | Mô tả hạ tầng | khai báo, đọc được | mã thủ tục | | Khi lỗi giữa chừng | tự rollback | để lại trạng thái dở dang | | Bảo trì | AWS lo engine | tự viết, tự sửa | | Kiểm chứng trước | change set | không có |

Thảm hoạ là lúc TỆ NHẤT để phát hiện
script tự viết có lỗi
    → CloudFormation đã được kiểm chứng
      qua hàng triệu lần triển khai

Mẫu CloudFormation tham số hoá theo AMI:

Parameters:
  AmiDR:
    Type: AWS::EC2::Image::Id
    Description: AMI da chep sang vung nay

Resources:
  MauKhoiChay:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        ImageId: !Ref AmiDR
        InstanceType: m5.large

  NhomTuDong:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 2
      MaxSize: 10
      DesiredCapacity: 4
      VPCZoneIdentifier: [!Ref SubnetA, !Ref SubnetB]

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí gần như bằng 0 lúc bình thường | | | Hạ tầng dựng lại y hệt, không sai lệch | | | Diễn tập được bằng cách dựng rồi xoá | |

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

• **A. AMI + chép sang Region thứ hai, tự động hoá bằng Lambda và script tuỳ chỉnh — đây là phương án gần nhất và khác đúng một chi tiết: dùng script tự viết thay vì CloudFormation. Nó chạy được nhưng phải tự bảo trì, không có rollback, và không kiểm chứng trước được.
• **B. Giữ EC2 chạy sẵn ở Region thứ hai 24/7 — cho RTO tốt hơn nhiều nhưng vi phạm cả "fewest possible resources" lẫn "cost-effectively"; với RTO 4 giờ thì đây là chi tiêu không cần thiết.
• **C. Giữ EC2 chạy ở một Availability Zone khác — AZ khác vẫn trong cùng Region, nên không bảo vệ được trước sự cố toàn Region; đề nói rõ "across regions".

Ghi nhớ

⚠ Bốn chiến lược DR — chọn theo RTO: | Chiến lược | RTO | Tài nguyên ở DR | |---|---|---| | Backup & Restore | giờ - ngày | không có gì | | Pilot Light | chục phút | chỉ tầng dữ liệu | | Warm Standby | phút | mọi tầng, quy mô nhỏ | | Multi-Site | gần 0 | đầy đủ, đang phục vụ |

⚠ Chọn chiến lược theo RTO đề cho, không chọn cái "tốt nhất":

RTO 4 giờ  → Backup & Restore là đủ và RẺ NHẤT
RTO 30 phút → Pilot Light
RTO 5 phút  → Warm Standby
RTO ~0      → Multi-Site
        ↓
    Chọn thừa = trả tiền cho thứ không cần

Từ khoá nhận diện:

"RTO hours, minimal resources, cost-effective" → Backup & Restore (AMI + IaC) "RTO minutes, scaled-down but functional" → Warm Standby "RTO near zero, both regions serve" → Multi-Site "automate infrastructure deployment" → CloudFormation

Ba thứ phải chuẩn bị sẵn ở Region DR: | Thứ | Hậu quả nếu quên | |---|---| | AMI đã chép sang | không khởi động được máy nào | | Chứng chỉ ACM | ACM theo Region | | Hạn ngạch tài khoản | quota Region ít dùng rất thấp |

⚠ Hạn ngạch là thứ hay giết RTO nhất:

CloudFormation dựng ASG cần 20 máy
    → quota Region phụ chỉ cho 8
        ↓
    Stack lỗi giữa chừng, giữa lúc sự cố
    → kiểm tra và xin tăng quota TRƯỚC

Ba lưu ý về dữ liệu: | Loại | Cách sao chép | |---|---| | RDS | snapshot chép xuyên Region, hoặc read replica | | S3 | Cross-Region Replication | | DynamoDB | Global Tables |

⚠ AMI chỉ chứa dữ liệu tại thời điểm chụp:

AMI sao lưu hằng ngày
    → RPO tệ nhất là 24 giờ
        ↓
    Dữ liệu quan trọng phải sao chép RIÊNG
    → đừng dựa vào AMI làm cơ chế sao lưu dữ liệu

Ba lưu ý về AMI: | Lưu ý | Chi tiết | |---|---| | AMI theo Region — phải chép mới dùng được | | | Snapshot mã hoá cần khoá KMS ở Region đích | | | Chia sẻ AMI xuyên tài khoản được | |

Ba lưu ý về CloudFormation: | Lưu ý | Chi tiết | |---|---| | StackSets triển khai nhiều Region cùng lúc | | | Change set xem trước thay đổi | | | Tham số hoá mọi thứ khác nhau giữa Region | |

aws cloudformation create-stack-set --stack-set-name ha-tang-dr \
  --template-body file://mau.yaml \
  --capabilities CAPABILITY_IAM

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Failover routing với health check | | | TTL thấp cho bản ghi failover | | | TTL cao = RTO thực tế dài hơn | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Diễn tập ít nhất 2 lần mỗi năm | | | Đo RTO thật, đừng ước lượng | | | Dựng stack rồi xoá — chi phí rất thấp | |

⚠ Đây là lợi thế ít người nói của Backup & Restore:

Diễn tập = dựng stack ở Region phụ, kiểm tra, xoá
    → chỉ trả tiền vài giờ
        ↓
    Rẻ đến mức không có lý do gì để không diễn tập

Ba lưu ý về Elastic Disaster Recovery (DRS): | Lưu ý | Chi tiết | |---|---| | Nhân bản liên tục mức khối | | | RPO tính bằng giây | | | Đắt hơn AMI nhưng RPO tốt hơn nhiều | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xác nhận AMI mới nhất đã có ở Region phụ | | | Dựng stack thử, bấm giờ | | | Kiểm tra hạn ngạch Region phụ | |

aws ec2 describe-images --owners self --region ap-northeast-1 \
  --query "sort_by(Images,&CreationDate)[-3:].[Name,CreationDate]" \
  --output table

Và một lời khuyên: hãy diễn tập bằng cách dựng thật stack DR rồi bấm giờ, mỗi quý một lần. Với chiến lược Backup & Restore thì một lần diễn tập chỉ tốn vài giờ tiền máy, và đó là cách duy nhất biết con số RTO 4 giờ của bạn là thật hay chỉ là một dòng trong tài liệu.

Đáp án

B — Dùng AWS Systems Manager Run Command chạy một lệnh tuỳ chỉnh cài công cụ lên toàn bộ EC2 instance.

Vì sao đúng

Đề nêu bốn yêu cầu, và Run Command đáp ứng cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Cài công cụ BÊN THỨ BA lên 500 máy | Run Command chạy script tuỳ ý | | Nhanh và hiệu quả | chạy song song, hàng trăm máy cùng lúc | | Việc tương tự sẽ lặp lại | lưu thành SSM document dùng lại | | Mở rộng cho máy thêm sau này | chọn máy theo TAG, không theo danh sách |

⚠ Chọn máy theo tag là chi tiết đáp ứng yêu cầu "scale for future instances":

aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'commands=["/tmp/cai-cong-cu.sh"]' \
  --max-concurrency "50" --max-errors "5" \
  --output-s3-bucket-name log-ssm

Máy mới gắn tag MoiTruong=san-xuat
    → lần chạy sau tự động bao gồm nó
        ↓
    Không ai phải cập nhật danh sách

⚠ max-concurrency và max-errors là hai tham số phải đặt: | Tham số | Việc | |---|---| | max-concurrency | bao nhiêu máy chạy cùng lúc | | max-errors | dừng lại sau bao nhiêu lỗi |

500 máy chạy cùng lúc
    → cùng tải một gói từ máy chủ nhà cung cấp
    → có thể làm sập chính máy chủ đó
        ↓
    Đặt max-concurrency 50 hoặc "10%"

max-errors không đặt = mặc định 0
    → một máy lỗi là dừng toàn bộ
        ↓
    Đặt "5" hoặc "1%" để bỏ qua vài máy hỏng

Lưu thành document dùng lại:

schemaVersion: '2.2'
description: Cai cong cu giam sat cua ben thu ba
parameters:
  phienBan:
    type: String
    default: '3.2.1'
mainSteps:
  - action: aws:runShellScript
    name: caiDat
    inputs:
      runCommand:
        - 'curl -fsSL https://nhacungcap.vidu/cai-{{phienBan}}.sh -o /tmp/cai.sh'
        - 'sh /tmp/cai.sh'
        - 'systemctl enable --now cong-cu'

aws ssm create-document --name CaiCongCuGiamSat \
  --document-type Command --document-format YAML \
  --content file://tai-lieu.yaml

Ba điều kiện để Run Command hoạt động: | Điều kiện | Chi tiết | |---|---| | SSM Agent đã cài | có sẵn trên phần lớn AMI của AWS | | Instance profile có AmazonSSMManagedInstanceCore | | | Máy tới được endpoint SSM | qua NAT hoặc VPC endpoint |

⚠ Ba VPC endpoint cần cho máy trong subnet riêng tư:

com.amazonaws.<vung>.ssm
com.amazonaws.<vung>.ssmmessages
com.amazonaws.<vung>.ec2messages
        ↓
    Thiếu một cái là máy không xuất hiện
    trong danh sách managed instance

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

• **D. Dùng Maintenance Windows để cài trong một khoảng thời gian — đây là phương án gần nhất và dùng đúng họ dịch vụ, nhưng Maintenance Window là cơ chế lập lịch: nó chạy Run Command vào giờ đã định. Đề cần cài ngay và nhanh, nên gọi thẳng Run Command là đúng hơn.
• **A. Dùng Patch Manager — Patch Manager dành cho bản vá của hệ điều hành, không phải cài phần mềm bên thứ ba tuỳ ý.
• **C. Viết Lambda để đổi cấu hình máy và một Lambda khác để kiểm chứng — Lambda không chạy lệnh bên trong EC2; nó sẽ phải gọi lại chính Run Command, tức là dựng thêm một tầng vô ích.

Ghi nhớ

⚠ Bốn năng lực Systems Manager hay bị lẫn — bảng phải thuộc: | Năng lực | Việc | |---|---| | Run Command | chạy lệnh MỘT LẦN, ngay | | State Manager | giữ máy ở trạng thái mong muốn, lặp lại | | Patch Manager | vá HỆ ĐIỀU HÀNH | | Maintenance Windows | lịch chạy các việc trên |

Từ khoá nhận diện:

"install software now on many instances" → Run Command "ensure config stays applied, drift" → State Manager "apply OS security patches" → Patch Manager "during a scheduled window" → Maintenance Windows "shell access without SSH keys" → Session Manager

⚠ State Manager đáng cân nhắc cho yêu cầu "ongoing basis":

aws ssm create-association --name CaiCongCuGiamSat \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --schedule-expression "rate(1 day)" \
  --compliance-severity HIGH

Run Command: chạy một lần
State Manager: kiểm tra và áp lại ĐỊNH KỲ
        ↓
    Máy mới khởi động tự được cài
    → có ai gỡ ra thì lần sau tự cài lại

Ba lợi ích của Session Manager (thay SSH): | Lợi ích | Chi tiết | |---|---| | Không cần khoá SSH, không cần cổng 22 mở | | | Mọi phiên ghi log vào CloudTrail và S3 | | | Phân quyền bằng IAM | |

⚠ Bỏ hẳn bastion host được nhờ Session Manager:

Bastion host: một máy phải vá, phải giám sát,
              một cổng mở ra Internet
        ↓
    Session Manager: không cổng nào mở
    → và có bản ghi mọi lệnh đã gõ

Ba lưu ý về Parameter Store: | Lưu ý | Chi tiết | |---|---| | Lưu cấu hình và bí mật | | | SecureString mã hoá bằng KMS | | | Standard tier miễn phí | |

Ba lưu ý về Inventory: | Lưu ý | Chi tiết | |---|---| | Thu thập danh sách phần mềm đã cài | | | Truy vấn bằng Athena hoặc Resource Data Sync | | | Xác nhận công cụ đã cài đủ 500 máy | |

⚠ Inventory là cách kiểm chứng đúng cho đề này:

SELECT resourceid, name, version
FROM ssm_inventory.aws_application
WHERE name = 'cong-cu-giam-sat';

Thay vì tin vào báo cáo của Run Command
    → hỏi thẳng từng máy đang cài gì

Ba lưu ý về gỡ lỗi máy không xuất hiện: | Nguyên nhân | Cách kiểm | |---|---| | SSM Agent chưa chạy | systemctl status amazon-ssm-agent | | Thiếu instance profile | | | Không tới được endpoint | thiếu NAT hoặc VPC endpoint |

aws ssm describe-instance-information \
  --query "InstanceInformationList[].[InstanceId,PingStatus,AgentVersion]" \
  --output table

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | Đổ output ra S3 hoặc CloudWatch Logs | | | Output trên console bị cắt ở 2500 ký tự | | | Cần log đầy đủ để tìm máy nào lỗi | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Giới hạn ai chạy được document nào | | | Giới hạn theo tag của máy đích | | | Không cho phép AWS-RunShellScript tuỳ tiện | |

{"Effect": "Allow", "Action": "ssm:SendCommand",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringEquals":
   {"ssm:resourceTag/MoiTruong": "san-xuat"}}}

⚠ AWS-RunShellScript cho phép chạy BẤT KỲ lệnh nào với quyền root:

Cấp quyền gọi document đó rộng rãi
    = cấp quyền root trên mọi máy
        ↓
    Tạo document riêng cho từng việc
    → chỉ cấp quyền cho document cụ thể

Ba lưu ý về Automation: | Lưu ý | Chi tiết | |---|---| | Automation runbook cho quy trình nhiều bước | | | Có bước phê duyệt thủ công | | | Kết hợp với EventBridge để tự kích hoạt | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem trạng thái lệnh trên từng máy | | | Truy vấn Inventory xác nhận đã cài | | | Thử trên nhóm nhỏ trước | |

aws ssm list-command-invocations --command-id <id> --details \
  --query "CommandInvocations[?Status!='Success'].[InstanceId,Status]" \
  --output table

Và một lời khuyên: hãy đặt max-concurrency thay vì để mặc định khi chạy trên 500 máy. Năm trăm máy cùng tải một gói cài đặt sẽ tấn công máy chủ của nhà cung cấp giống hệt một cuộc tấn công từ chối dịch vụ — và bạn sẽ khám phá ra điều đó bằng cách thấy phần lớn các máy báo lỗi tải về.

Đáp án

A — Dựng CSDL warm standby Amazon RDS for PostgreSQL trên AWS và cấu hình AWS DMS dùng change data capture (CDC).

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | RPO dưới một phút | CDC sao chép thay đổi liên tục, độ trễ vài giây | | RTO trong hai giờ | CSDL đã sẵn sàng, chỉ cần chuyển ứng dụng | | Chi phí tối thiểu | chỉ chạy CSDL, không nhân bản cả máy chủ |

⚠ CDC là chìa khoá cho RPO dưới một phút:

Sao lưu hằng ngày:  RPO tệ nhất 24 giờ
Sao lưu mỗi giờ:    RPO tệ nhất 1 giờ
        ↓
CDC:  đọc write-ahead log của PostgreSQL
      áp thay đổi sang đích liên tục
        ↓
    Độ trễ thường vài giây → RPO dưới một phút

Dựng DMS với CDC:

aws dms create-replication-instance \
  --replication-instance-identifier may-nhan-ban \
  --replication-instance-class dms.r5.large \
  --allocated-storage 100 --multi-az

aws dms create-replication-task \
  --replication-task-identifier nhan-ban-lien-tuc \
  --source-endpoint-arn <arn-postgres-tai-cho> \
  --target-endpoint-arn <arn-rds> \
  --replication-instance-arn <arn-may> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa-bang.json

⚠ full-load-and-cdc làm hai việc theo đúng thứ tự:

1. Full load: chép toàn bộ dữ liệu hiện có
2. CDC:       từ đó theo dõi và áp thay đổi liên tục
        ↓
    Không có khoảng trống giữa hai giai đoạn

Chuẩn bị nguồn PostgreSQL cho CDC:

-- postgresql.conf
wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

CREATE USER dms_user WITH REPLICATION LOGIN PASSWORD '...';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dms_user;

⚠ wal_level = logical đòi khởi động lại PostgreSQL — phải lên kế hoạch cửa sổ bảo trì.

Vì sao "warm standby" hợp với RTO 2 giờ:

CSDL đã chạy và đã có dữ liệu
    → khi thảm hoạ: dừng DMS, chuyển ứng dụng
        ↓
    Phần tính toán có thể dựng lúc đó
    → RTO 2 giờ là dư dả

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO tính bằng giây | | | Chỉ trả tiền một RDS instance + một DMS instance | | | Kiểm chứng được liên tục — dữ liệu đang chảy thật | |

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

• **D. Dùng Elastic Disaster Recovery (DRS) nhân bản liên tục kiểu pilot light — đây là phương án gần nhất và cũng cho RPO tính bằng giây, nhưng DRS nhân bản toàn bộ máy chủ ở mức khối, tốn hơn cho một CSDL đơn lẻ; và nhân bản mức khối của CSDL đang chạy có thể cần crash recovery khi khởi động.
• **B. Sao lưu hằng ngày bằng phần mềm bên thứ ba lên S3 — RPO tệ nhất là 24 giờ, vi phạm thẳng yêu cầu "dưới một phút".
• **C. Dựng active-active giữa tại chỗ và AWS bằng giải pháp HA bên thứ ba — cho RPO/RTO tốt nhất nhưng đắt và phức tạp nhất, ngược với "keeping costs to a minimum".

Ghi nhớ

⚠ Ba cách nhân bản CSDL cho DR — bảng phải thuộc: | Cách | RPO | Chi phí | |---|---|---| | Sao lưu định kỳ | theo chu kỳ sao lưu | thấp nhất | | DMS CDC | giây | trung bình | | Nhân bản gốc của engine | giây | trung bình | | Active-active | gần 0 | cao nhất |

Từ khoá nhận diện:

"RPO seconds/minutes, minimize cost, on-premises database" → DMS CDC "replicate whole servers" → Elastic Disaster Recovery (DRS) "RPO hours acceptable" → sao lưu định kỳ "zero RPO, both sites active" → active-active

⚠ DMS vs DRS — chọn theo phạm vi:

Chỉ cần dữ liệu CSDL  → DMS
Cần cả máy chủ ứng dụng → DRS
        ↓
    Đề này chỉ nói về CSDL PostgreSQL
    → DMS đúng phạm vi hơn

Ba chế độ của DMS task: | Chế độ | Việc | |---|---| | full-load | chép một lần | | cdc | chỉ theo dõi thay đổi | | full-load-and-cdc | cả hai — dùng cho DR |

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Không chép index, khoá ngoại, trigger tự động | | | Dùng SCT nếu đổi engine | | | Cùng engine thì đơn giản hơn nhiều | |

⚠ Đây là điểm hay bị bỏ sót:

DMS chép DỮ LIỆU, không chép cấu trúc phụ
    → index, sequence, trigger, view phải tự tạo
        ↓
    Với DR: dựng schema đầy đủ ở đích TRƯỚC
    rồi mới chạy DMS

pg_dump --schema-only -h nguon -U user csdl > schema.sql
psql -h dich.rds.amazonaws.com -U user -d csdl -f schema.sql

Ba lưu ý về giám sát độ trễ: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | đọc từ nguồn chậm bao lâu | | CDCLatencyTarget | ghi vào đích chậm bao lâu | | CDCIncomingChanges | tồn đọng |

⚠ Đặt cảnh báo cho độ trễ CDC — đây là chỉ số RPO thực tế:

aws cloudwatch put-metric-alarm --alarm-name dms-tre \
  --namespace AWS/DMS --metric-name CDCLatencyTarget \
  --dimensions Name=ReplicationTaskIdentifier,Value=nhan-ban-lien-tuc \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 60 --comparison-operator GreaterThanThreshold \
  --alarm-actions <arn-sns>

Độ trễ CDC 5 phút = RPO thực tế 5 phút
    → không còn "dưới một phút" nữa
        ↓
    Không cảnh báo thì không ai biết

Ba lưu ý về replication slot: | Lưu ý | Chi tiết | |---|---| | PostgreSQL giữ WAL cho slot chưa đọc hết | | | DMS dừng lâu = WAL chất đống | | | Đĩa nguồn có thể đầy | |

⚠ Đây là rủi ro nghiêm trọng của CDC trên PostgreSQL:

Task DMS dừng nhưng slot vẫn tồn tại
    → PostgreSQL không xoá WAL được
        ↓
    Đĩa nguồn đầy → CSDL SẢN XUẤT ngừng hoạt động
    → theo dõi `pg_replication_slots` và dung lượng đĩa

SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(
         pg_current_wal_lsn(), restart_lsn)) AS ton_dong
FROM pg_replication_slots;

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | DMS cần tới được CSDL nguồn | | | Qua VPN hoặc Direct Connect | | | Bật SSL cho endpoint | |

Ba lưu ý về chuyển đổi: | Bước | Chi tiết | |---|---| | Dừng ghi ở nguồn | | | Chờ CDC bắt kịp hoàn toàn | | | Chuyển ứng dụng sang RDS | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Tạo bản sao RDS để thử, đừng đụng bản chính | | | Kiểm tra số dòng và checksum vài bảng | | | Đo thời gian chuyển đổi thật | |

Ba lưu ý về validation của DMS: | Lưu ý | Chi tiết | |---|---| | Bật EnableValidation trong task settings | | | DMS tự so dữ liệu hai bên | | | Báo cáo dòng nào lệch | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một dòng ở nguồn, tìm ở đích | đo thời gian | | Xem CDCLatencyTarget | | | Kiểm tra tồn đọng WAL ở nguồn | |

Và một lời khuyên: hãy theo dõi dung lượng đĩa của CSDL nguồn cùng với độ trễ CDC. Replication slot của PostgreSQL giữ lại WAL cho đến khi DMS đọc hết, nên một task nhân bản chết lặng lẽ sẽ làm đầy đĩa của chính hệ thống sản xuất mà nó được dựng ra để bảo vệ.

Đáp án

D — Tìm trong log CloudTrail bằng Amazon QuickSight và tạo dashboard để nhận diện lỗi.

Vì sao đúng

Trong bốn phương án được đưa ra, đây là cách ít công nhất để có một giao diện tìm và xem lỗi AccessDenied / UnauthorizedOperation.

⚠ Ba phương án còn lại đều đòi viết mã hoặc dựng cụm — D không.

Mẫu lỗi cần tìm trong CloudTrail:

{"errorCode": "AccessDenied",
 "errorMessage": "User: arn:aws:iam::123456789012:user/nam
                  is not authorized to perform: s3:GetObject"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Có giao diện trực quan cho người không viết SQL | | | Chia sẻ dashboard cho cả đội bảo mật | | | Lọc theo người dùng, dịch vụ, thời gian | |

Ghi nhớ về chất lượng câu hỏi

⚠ Câu trả lời đúng nhất cho bài toán này KHÔNG có trong bốn phương án.

Có hai cách chuẩn mà AWS khuyến nghị, và cả hai đều vắng mặt:

1. CloudTrail Lake — ít công nhất, viết SQL thẳng:

aws cloudtrail create-event-data-store \
  --name kho-su-kien --retention-period 365

aws cloudtrail start-query --query-statement "
  SELECT eventTime, userIdentity.arn, eventName, errorCode
  FROM <id-kho>
  WHERE errorCode IN ('AccessDenied','UnauthorizedOperation')
    AND eventTime > '2026-07-01'
  ORDER BY eventTime DESC"

Không dựng gì, không tạo bảng
    → bật kho sự kiện rồi truy vấn ngay

2. Athena — console CloudTrail có nút tạo bảng sẵn:

SELECT eventtime, useridentity.arn, eventname,
       errorcode, errormessage
FROM cloudtrail_logs
WHERE errorcode IN ('AccessDenied', 'UnauthorizedOperation')
  AND from_iso8601_timestamp(eventtime) > current_date - interval '7' day
ORDER BY eventtime DESC;

⚠ Và có một chi tiết kỹ thuật đáng nói về phương án D:

QuickSight KHÔNG đọc trực tiếp log CloudTrail
    → log là JSON nén gzip, phân mảnh theo thư mục
        ↓
    Thực tế phải nối QuickSight qua ATHENA
    → tức là phương án D ngầm bao gồm Athena

Nói rõ điều này vì gặp tình huống tương tự ngoài đời, hãy bắt đầu bằng CloudTrail Lake hoặc Athena; QuickSight chỉ thêm vào khi cần dashboard cho người không viết SQL.

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

• **B. Tìm bằng Amazon Redshift rồi tạo dashboard — đây là phương án gần nhất về mặt cũng cho giao diện phân tích, nhưng phải dựng cụm và nạp dữ liệu vào; Redshift là kho dữ liệu cho phân tích thường xuyên, quá nặng cho việc tra cứu lỗi IAM.
• **A. Viết script chạy bằng AWS Batch — tự dựng compute environment, job queue, job definition và tự viết logic phân tích; nhiều việc nhất trong bốn phương án.
• **C. Viết script tuỳ chỉnh truy vấn bằng Glue — Glue là ETL; dùng nó để tra cứu lỗi là viết mã cho thứ đã có công cụ sẵn.

Ghi nhớ

⚠ Ba cách truy vấn log CloudTrail — bảng phải thuộc: | Cách | Công dựng | Giữ dữ liệu | |---|---|---| | Console Event history | không có gì | chỉ 90 ngày, chỉ management event | | CloudTrail Lake | bật một lần | tới 10 năm | | Athena trên bucket log | tạo bảng | theo lifecycle của bucket |

⚠ Event history của console chỉ 90 ngày — điều tra dài hơn phải có trail ghi ra S3 hoặc CloudTrail Lake.

Từ khoá nhận diện:

"query CloudTrail with SQL, no setup" → CloudTrail Lake "cheap SQL over logs in S3" → Athena "dashboard for non-technical team" → QuickSight (qua Athena) "real-time alert on an API call" → EventBridge

⚠ Với lỗi IAM, cảnh báo thời gian thực thường hữu ích hơn dashboard:

{"source": ["aws.signin"],
 "detail-type": ["AWS Console Sign In via CloudTrail"],
 "detail": {"responseElements": {"ConsoleLogin": ["Failure"]}}}

Ba nguyên nhân thường gặp của AccessDenied: | Nguyên nhân | Cách kiểm | |---|---| | IAM policy thiếu action | đọc errorMessage — nó nêu rõ action | | SCP của tổ chức chặn | thông báo có nhắc "implicit deny" | | Resource policy không cho phép | bucket policy, KMS key policy |

⚠ errorMessage của CloudTrail thường nói thẳng thiếu quyền gì:

"User: arn:... is not authorized to perform:
 s3:GetObject on resource: arn:aws:s3:::kho/tep.txt
 because no identity-based policy allows the s3:GetObject action"
        ↓
    Câu cuối phân biệt: thiếu policy,
    hay bị Deny tường minh, hay SCP chặn

Ba công cụ chẩn đoán quyền: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử trước khi áp | | IAM Access Analyzer | truy cập từ ngoài, quyền thừa | | aws sts decode-authorization-message | giải mã thông báo bị mã hoá |

⚠ Thông báo bị mã hoá cần lệnh riêng để đọc:

aws sts decode-authorization-message \
  --encoded-message <chuoi-dai>

Một số lỗi trả về chuỗi mã hoá dài
    → giải mã ra mới thấy chính xác policy nào chặn

Ba lưu ý về Access Analyzer: | Tính năng | Việc | |---|---| | External access | tài nguyên chia sẻ ra ngoài | | Unused access | quyền cấp mà không dùng | | Policy generation | sinh policy TỪ log CloudTrail |

⚠ Sinh policy từ CloudTrail là tính năng rất đáng dùng:

aws accessanalyzer start-policy-generation \
  --policy-generation-details 'PrincipalArn=<arn-vai-tro>' \
  --cloud-trail-details file://chi-tiet.json

Access Analyzer đọc log 90 ngày qua
    → sinh policy chứa ĐÚNG những quyền đã dùng
        ↓
    Vừa sửa được AccessDenied, vừa không cấp thừa

Ba lưu ý về chi phí: | Cách | Chi phí | |---|---| | Athena | ~5 USD mỗi TB quét | | CloudTrail Lake | phí nạp + phí truy vấn | | QuickSight | theo người dùng |

Ba lưu ý về tối ưu truy vấn Athena: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo ngày và Region | | | Dùng partition projection | | | Luôn có điều kiện lọc thời gian | |

⚠ Không lọc thời gian là quét toàn bộ lịch sử log:

-- Tệ: quét mọi thứ
SELECT * FROM cloudtrail_logs WHERE errorcode = 'AccessDenied';

-- Tốt: cắt phân vùng
SELECT * FROM cloudtrail_logs
WHERE region = 'ap-southeast-1'
  AND year = '2026' AND month = '08'
  AND errorcode = 'AccessDenied';

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản riêng | | | Bật log file validation | | | Object Lock chống xoá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cố tình gây một AccessDenied | | | Tìm nó trong công cụ đã dựng | | | Đo thời gian từ lúc xảy ra tới lúc thấy | |

Và một lời khuyên: hãy dùng Access Analyzer sinh policy từ log thay vì đoán quyền còn thiếu. Sửa AccessDenied bằng cách thêm dần từng quyền có xu hướng kết thúc ở một policy rộng hơn nhiều so với nhu cầu thật — còn policy sinh từ hoạt động thực tế thì vừa khít ngay từ đầu.

Đáp án

C — Cấu hình AWS Systems Manager Patch Manager để áp bản vá lên toàn bộ EC2 instance.

Vì sao đúng

Đề nêu ba dữ kiện, và Patch Manager là công cụ sinh ra cho đúng tình huống này: | Dữ kiện | Cách đáp ứng | |---|---| | Phần mềm bên thứ ba được VÁ định kỳ | Patch Manager quản lý vòng đời bản vá | | Hàng nghìn instance | chạy song song theo tag, theo nhóm | | Cần vá NHANH để bịt lỗ hổng | chạy ngay, không cần chờ cửa sổ bảo trì |

⚠ Patch Manager không chỉ chạy lệnh — nó quản lý cả quy trình:

Run Command: chạy một lệnh, xong
        ↓
Patch Manager:
    → quét xem máy nào THIẾU bản vá nào
    → áp theo baseline đã duyệt
    → báo cáo tuân thủ sau khi vá
    → khởi động lại nếu bản vá yêu cầu

Chạy ngay không chờ cửa sổ bảo trì:

aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'Operation=Install,RebootOption=RebootIfNeeded' \
  --max-concurrency "10%" --max-errors "5%" \
  --output-s3-bucket-name log-va

⚠ AWS-RunPatchBaseline là document dựng sẵn — không phải viết script.

Patch baseline tuỳ chỉnh cho phần mềm bên thứ ba:

aws ssm create-patch-baseline \
  --name baseline-ung-dung \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security]},
      {Key=SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=0,
    ComplianceLevel=CRITICAL}]' \
  --sources 'Name=kho-nha-cung-cap,Products=["*"],
    Configuration="[kho-nha-cung-cap]\nname=Kho ben thu ba\nbaseurl=https://kho.nhacungcap.vidu/el7\nenabled=1"'

⚠ --sources là chỗ khai kho phần mềm của bên thứ ba — đây là cách Patch Manager vá được thứ không nằm trong kho hệ điều hành.

Patch group để vá theo đợt:

aws ssm create-tags --resource-type ManagedInstance \
  --resource-id i-abc \
  --tags 'Key=Patch Group,Value=dot-1'

Vá đợt 1 (10% số máy) → kiểm tra
    → đợt 2 → đợt 3
        ↓
    Bản vá hỏng chỉ ảnh hưởng một phần

⚠ Tên tag là Patch Group — CÓ dấu cách và phân biệt hoa thường. Viết PatchGroup sẽ không có tác dụng, mà cũng không báo lỗi.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Báo cáo tuân thủ tự động | biết máy nào còn thiếu | | Có baseline duyệt bản vá trước | | | Miễn phí — chỉ trả tiền máy | |

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

• **A. Dùng Run Command chạy lệnh tuỳ chỉnh áp bản vá — đây là phương án gần nhất và chạy được, nhưng bạn phải tự viết logic: biết máy nào cần vá gì, tự xử lý khởi động lại, tự tổng hợp báo cáo. Patch Manager làm sẵn tất cả — và chính nó dùng Run Command bên dưới.
• **D. Dùng Maintenance Window — đây là cơ chế lập lịch; đề nói cần vá nhanh để bịt lỗ hổng, chờ tới cửa sổ bảo trì là ngược yêu cầu.
• **B. Viết Lambda để vá — Lambda không chạy lệnh bên trong EC2; nó sẽ phải gọi lại Systems Manager, tức là thêm một tầng vô ích.

Ghi nhớ

⚠ Khi nào Run Command, khi nào Patch Manager — bảng phải thuộc: | Việc | Công cụ | |---|---| | Cài phần mềm mới, chạy script tuỳ ý | Run Command | | VÁ hệ điều hành và phần mềm có kho | Patch Manager | | Giữ cấu hình không bị lệch | State Manager | | Lên lịch cho các việc trên | Maintenance Windows |

Từ khoá nhận diện:

"apply patches, remediate vulnerability, compliance" → Patch Manager "install a tool, run a one-off command" → Run Command "ensure config stays applied" → State Manager "scan for CVEs" → Amazon Inspector

⚠ Inspector và Patch Manager bổ sung nhau:

Inspector:     TÌM ra lỗ hổng nào đang tồn tại
Patch Manager: SỬA chúng
        ↓
    Inspector → EventBridge → Patch Manager
    = quy trình khép kín

Ba khái niệm của Patch Manager: | Khái niệm | Nghĩa | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt | | Patch group | nhóm máy dùng chung baseline | | Patch policy | áp baseline theo lịch cho nhiều tài khoản |

Ba tham số Operation: | Giá trị | Việc | |---|---| | Scan | chỉ kiểm tra, không cài | | Install | cài bản vá | | RebootOption | RebootIfNeeded hoặc NoReboot |

⚠ Luôn Scan trước để biết phạm vi:

aws ssm send-command --document-name "AWS-RunPatchBaseline" \
  --targets 'Key=tag:MoiTruong,Values=san-xuat' \
  --parameters 'Operation=Scan'

Ba lưu ý về khởi động lại: | Lưu ý | Chi tiết | |---|---| | NoReboot để bản vá chờ tới lần khởi động sau | | | Máy sau ALB nên rút khỏi target group trước | | | Lifecycle hook của ASG xử lý được | |

⚠ Khởi động lại hàng nghìn máy cùng lúc là sự cố tự gây:

max-concurrency không đặt
    → mọi máy khởi động lại đồng thời
        ↓
    Dịch vụ ngừng hoàn toàn
    → đặt "10%" là an toàn hơn nhiều

Ba lưu ý về báo cáo tuân thủ: | Lưu ý | Chi tiết | |---|---| | Xem theo từng máy hoặc tổng hợp | | | Đưa vào Security Hub | | | Config rule kiểm tra tuân thủ vá | |

aws ssm list-compliance-summaries \
  --filters 'Key=ComplianceType,Values=Patch'

Ba điều kiện tiên quyết: | Điều kiện | Chi tiết | |---|---| | SSM Agent đang chạy | | | Instance profile có AmazonSSMManagedInstanceCore | | | Tới được endpoint SSM | NAT hoặc VPC endpoint |

Ba lưu ý về Windows: | Lưu ý | Chi tiết | |---|---| | Patch Manager hỗ trợ Windows đầy đủ | | | Lọc theo MSRC_SEVERITY | | | Vá được cả ứng dụng Microsoft | |

Ba cách bổ sung để giảm rủi ro: | Cách | Chi tiết | |---|---| | Thay AMI thay vì vá tại chỗ (immutable) | | | EC2 Image Builder dựng AMI đã vá | | | Thay máy qua ASG rolling update | |

⚠ Hạ tầng bất biến là hướng tốt hơn về lâu dài:

Vá tại chỗ: máy dần khác nhau theo thời gian
    → "sai lệch cấu hình"
        ↓
Thay AMI: mọi máy giống hệt nhau
    → quay lui = triển khai lại AMI cũ

Ba lưu ý về khẩn cấp: | Lưu ý | Chi tiết | |---|---| | ApproveAfterDays=0 cho bản vá nghiêm trọng | | | Vẫn nên thử trên nhóm nhỏ trước | | | Có kế hoạch quay lui | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Scan sau khi Install | phải sạch | | Xem báo cáo tuân thủ | | | Kiểm tra ứng dụng còn chạy đúng | |

Và một lời khuyên: hãy chạy Operation=Scan trên toàn bộ đội máy trước khi bấm Install. Bản quét cho bạn biết chính xác bao nhiêu máy sẽ khởi động lại và bao nhiêu bản vá sẽ được áp — và đó là thông tin bạn muốn có trước khi bắt đầu, chứ không phải trong lúc đang giải thích cho ai đó vì sao dịch vụ vừa ngừng.

Đáp án

A — Dùng CloudFront signed cookies cho học viên đã xác thực.

Vì sao đúng

Đề nêu hai yêu cầu, và signed cookies khớp cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Chỉ học viên đã ghi danh xem được tài liệu | cookie ký, chỉ cấp sau khi đăng nhập | | Đôi khi cấp tài nguyên riêng cho một số học viên | policy tuỳ chỉnh theo từng người |

⚠ Signed cookies vs signed URL — khác biệt quyết định: | | Signed cookie | Signed URL | |---|---|---| | Phạm vi | NHIỀU tệp, cả một cây thư mục | MỘT tệp mỗi URL | | Đổi URL hiện có | không cần | phải đổi mọi link | | Hợp với | khoá học nhiều video, tài liệu | tải một tệp |

Một khoá học có 40 video + 60 tài liệu PDF
    → signed URL: phải ký 100 URL riêng
        ↓
    Signed cookie: một lần ký, mở được cả khoá học

Chính sách tuỳ chỉnh cho phạm vi thư mục:

{"Statement": [{
  "Resource": "https://hoc.vidu.com/khoa-hoc/aws-saa/*",
  "Condition": {
    "DateLessThan": {"AWS:EpochTime": 1756598400},
    "IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}}}]}

Sinh cookie ở phía máy chủ:

from botocore.signers import CloudFrontSigner
import rsa, datetime

def ky(thong_diep):
    khoa = rsa.PrivateKey.load_pkcs1(open('khoa-rieng.pem','rb').read())
    return rsa.sign(thong_diep, khoa, 'SHA-1')

nguoi_ky = CloudFrontSigner('<key-pair-id>', ky)
cookies = nguoi_ky.generate_presigned_cookies(
    policy=chinh_sach_tuy_chinh)

Máy chủ đặt ba cookie: CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id.

⚠ Vế thứ hai của đề — "tài nguyên độc quyền cho một số học viên" — cũng do policy lo:

if hoc_vien.co_quyen_nghien_cuu:
    tai_nguyen = "https://hoc.vidu.com/*"
else:
    tai_nguyen = f"https://hoc.vidu.com/khoa-hoc/{ma_khoa}/*"

Cùng một cơ chế, chỉ khác phạm vi trong policy
    → không cần thêm hệ thống nào

Chặn truy cập thẳng vào S3 bằng OAC:

aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name": "oac-tai-lieu",
    "OriginAccessControlOriginType": "s3",
    "SigningBehavior": "always",
    "SigningProtocol": "sigv4"}'

⚠ Không có OAC thì signed cookie vô nghĩa:

Bucket còn cho phép truy cập trực tiếp
    → ai biết URL S3 là tải được, bỏ qua CloudFront
        ↓
    OAC + bucket policy chỉ cho CloudFront đọc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải đổi URL trong nội dung | | | Một lần cấp, dùng cho cả khoá học | | | Đặt hạn và giới hạn IP được | |

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

• **D. Tạo và cấp S3 pre-signed URL cho học viên đã xác thực — đây là phương án gần nhất và cũng kiểm soát được truy cập, nhưng phải ký từng tệp một, và pre-signed URL trỏ thẳng vào S3 nên bỏ qua CloudFront — mất hết lợi ích CDN mà đề đang dùng.
• **C. Dùng Field-Level Encryption để chặn người chưa ghi danh — FLE mã hoá trường dữ liệu nhạy cảm trong yêu cầu POST gửi tới origin; nó không phải cơ chế kiểm soát truy cập.
• **B. Dùng mã hoá object phía S3 — mã hoá bảo vệ dữ liệu khi lưu trữ, hoàn toàn không quyết định ai được tải về.

Ghi nhớ

⚠ Ba cơ chế bảo vệ nội dung CloudFront — bảng phải thuộc: | Cơ chế | Phạm vi | |---|---| | Signed URL | một tệp | | Signed cookie | nhiều tệp, theo mẫu đường dẫn | | OAC / OAI | chặn truy cập THẲNG vào S3 |

⚠ OAI đã lỗi thời — dùng OAC:

OAC ra mắt tháng 8/2022, thay thế OAI
    → OAI KHÔNG làm việc với bucket SSE-KMS
    → OAI không hỗ trợ các Region mới
        ↓
    Thiết kế mới luôn dùng OAC

Từ khoá nhận diện:

"restrict access to many files, subscribers" → signed cookies "one-time download link for a single file" → signed URL "prevent direct S3 access" → OAC "block by country" → geo restriction "encrypt sensitive form fields" → Field-Level Encryption

Ba thành phần của signed cookie: | Cookie | Nội dung | |---|---| | CloudFront-Policy | policy mã hoá base64 | | CloudFront-Signature | chữ ký | | CloudFront-Key-Pair-Id | định danh khoá công khai |

⚠ Canned policy vs custom policy: | Loại | Đặt được | |---|---| | Canned | chỉ thời hạn, một tài nguyên | | Custom | thời hạn, IP, mẫu đường dẫn, thời gian bắt đầu |

Signed cookie BẮT BUỘC dùng custom policy
    → vì cần mẫu đường dẫn có ký tự đại diện

Ba lưu ý về khoá ký: | Lưu ý | Chi tiết | |---|---| | Dùng key group (mới), không dùng trusted signer (cũ) | | | Khoá riêng lưu trong Secrets Manager | | | Xoay khoá định kỳ | |

aws cloudfront create-public-key --public-key-config '{
  "CallerReference":"khoa-2026","Name":"khoa-ky-cookie",
  "EncodedKey":"-----BEGIN PUBLIC KEY-----\n..."}'

aws cloudfront create-key-group --key-group-config '{
  "Name":"nhom-khoa-hoc","Items":["<id-khoa-cong-khai>"]}'

⚠ Key group cho phép xoay khoá không gián đoạn:

Thêm khoá mới vào group
    → cả khoá cũ và mới đều được chấp nhận
        ↓
    Chuyển sang ký bằng khoá mới
    → gỡ khoá cũ sau khi cookie cũ hết hạn

Ba lưu ý về cookie: | Lưu ý | Chi tiết | |---|---| | Đặt Domain để dùng cho tên miền phụ | | | Đặt Secure và HttpOnly | | | Trình duyệt tự gửi kèm mọi yêu cầu | |

Ba lưu ý về thời hạn: | Lưu ý | Chi tiết | |---|---| | Ngắn giảm rủi ro chia sẻ lại | | | Quá ngắn thì video dài bị đứt giữa chừng | | | Vài giờ là điểm cân bằng thường dùng | |

⚠ Video dài là trường hợp phải tính:

Cookie hết hạn sau 30 phút
    → học viên xem video 45 phút
        ↓
    Đoạn giữa chừng bị 403
    → đặt hạn dài hơn thời lượng dài nhất

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | KHÔNG đưa cookie vào cache key | | | Nếu đưa, mỗi người một bản cache riêng | | | Tỷ lệ trúng cache sụp đổ | |

⚠ Đây là lỗi hiệu năng phổ biến nhất với signed cookie:

Cache policy chuyển tiếp mọi cookie
    → mỗi học viên có chữ ký khác nhau
    → CloudFront coi là object khác nhau
        ↓
    Cache hit rate về gần 0
    → dùng CachingOptimized, không forward cookie

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Theo dõi tỷ lệ 403 | | | Access log ghi kết quả từng yêu cầu | | | 403 tăng đột biến = vấn đề ký hoặc hết hạn | |

Ba lựa chọn nâng cao: | Cách | Việc | |---|---| | CloudFront Functions | kiểm token JWT ở edge | | Lambda@Edge | logic phức tạp hơn | | Cả hai | thay cho signed cookie nếu đã có JWT |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy cập không có cookie | phải 403 | | Truy cập với cookie hợp lệ | phải 200 | | Thử URL S3 trực tiếp | phải bị chặn |

Và một lời khuyên: hãy kiểm tra cache policy không chuyển tiếp cookie CloudFront. Signed cookie khác nhau ở mỗi học viên, nên đưa chúng vào khoá cache sẽ biến CDN thành một proxy không cache gì cả — và triệu chứng là hoá đơn origin tăng vọt trong khi mọi thứ vẫn "hoạt động bình thường".

Đáp án

A — Chia sẻ dashboard từ console CloudWatch: nhập địa chỉ email của người dùng, hoàn tất các bước chia sẻ, rồi gửi liên kết dashboard cho quản lý sản phẩm.

Vì sao đúng

Đề nêu ba ràng buộc, và chia sẻ dashboard đáp ứng đúng nguyên tắc quyền tối thiểu: | Ràng buộc | Cách đáp ứng | |---|---| | Người quản lý sản phẩm KHÔNG có quyền quản trị | không cần tài khoản AWS nào | | Chỉ cần xem log của một tuần | chỉ thấy đúng dashboard được chia sẻ | | Nguyên tắc quyền tối thiểu | quyền hẹp nhất trong bốn phương án |

⚠ So sánh phạm vi quyền của bốn phương án: | Phương án | Người đó xem được gì | |---|---| | A — chia sẻ dashboard | CHỈ dashboard đó | | B — CloudWatchReadOnlyAccess | MỌI metric, log, alarm của cả tài khoản | | C — bastion với credential cached | mọi thứ mà credential đó có quyền | | D — ViewOnlyAccess | danh sách tài nguyên của MỌI dịch vụ |

Cần xem MỘT dashboard
    → cấp quyền xem toàn bộ CloudWatch là thừa
    → cấp ViewOnlyAccess toàn tài khoản còn thừa hơn

Chia sẻ dashboard:

aws cloudwatch put-dashboard --dashboard-name su-co-thang-8 \
  --dashboard-body file://dashboard.json

Rồi trong console: Dashboard → Actions → Share dashboard, chọn chia sẻ cho người dùng cụ thể và nhập email.

Ba cách chia sẻ dashboard: | Cách | Chi tiết | |---|---| | Người dùng cụ thể (email + mật khẩu) | hợp với đề này | | Công khai qua liên kết | ai có link cũng xem được | | Qua SSO provider | tổ chức lớn |

⚠ Không chọn "công khai qua liên kết" cho dữ liệu sự cố:

Liên kết công khai = bất kỳ ai có URL
    → log sự cố thường chứa tên máy chủ,
      đường dẫn nội bộ, đôi khi cả dữ liệu
        ↓
    Chọn chia sẻ theo email cụ thể

Đưa widget log vào dashboard:

{"type": "log",
 "properties": {
   "query": "SOURCE '/ung-dung/san-xuat'\n
             fields @timestamp, @message\n
             | filter @message like /ERROR/\n
             | sort @timestamp desc\n
             | limit 200",
   "region": "ap-southeast-1",
   "title": "Loi trong tuan xay ra su co"}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không tạo tài khoản IAM nào | | | Không phải thu hồi quyền sau này | | | Người xem thấy đúng thứ cần, không hơn | |

⚠ Đề nói log "có thể cần lại trong tương lai" — nhớ đặt retention:

aws logs put-retention-policy \
  --log-group-name /ung-dung/san-xuat --retention-in-days 90

Mặc định log group giữ VĨNH VIỄN
    → tốn tiền
        ↓
    Nhưng đặt quá ngắn thì mất log lúc cần điều tra lại
    → 90 ngày là mức thường dùng

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

• **B. Tạo IAM user với CloudWatchReadOnlyAccess — đây là phương án gần nhất và hoàn toàn khả thi, nhưng cấp quyền xem mọi metric, log group và alarm của cả tài khoản, rộng hơn nhiều so với "xem một dashboard".
• **D. Tạo IAM user với ViewOnlyAccess — còn rộng hơn B: cho phép liệt kê tài nguyên của mọi dịch vụ AWS trong tài khoản.
• **C. Dựng bastion server với trình duyệt đã cache credential — vừa phức tạp vừa nguy hiểm: chia sẻ credential dùng chung, không truy vết được ai làm gì, và thêm một máy chủ phải bảo trì.

Ghi nhớ

⚠ Ba mức chia sẻ dữ liệu quan sát — bảng phải thuộc: | Cách | Phạm vi | |---|---| | Chia sẻ CloudWatch dashboard | chỉ dashboard đó | | IAM policy hẹp trên một log group | một log group | | Managed policy CloudWatchReadOnlyAccess | toàn bộ CloudWatch |

⚠ Nếu bắt buộc dùng IAM, hãy giới hạn tới đúng tài nguyên:

{"Version":"2012-10-17","Statement":[
 {"Effect":"Allow",
  "Action":["logs:GetLogEvents","logs:FilterLogEvents",
            "logs:DescribeLogStreams"],
  "Resource":"arn:aws:logs:ap-southeast-1:123456789012:log-group:/ung-dung/san-xuat:*"},
 {"Effect":"Allow",
  "Action":["cloudwatch:GetDashboard"],
  "Resource":"arn:aws:cloudwatch::123456789012:dashboard/su-co-thang-8"}]}

Đây là cách đúng khi cần cấp quyền IAM
    → không bao giờ gắn managed policy rộng
      cho một nhu cầu hẹp

Từ khoá nhận diện:

"share a dashboard with someone without AWS access" → dashboard sharing "least privilege for one log group" → IAM policy giới hạn tài nguyên "temporary access" → vai trò IAM có hạn phiên "external auditor" → cross-account role

Ba lưu ý về chia sẻ dashboard: | Lưu ý | Chi tiết | |---|---| | Có phí theo người xem mỗi tháng | | | Người xem thấy dữ liệu THỜI GIAN THỰC | | | Thu hồi được bất cứ lúc nào | |

⚠ Người xem thấy dữ liệu trực tiếp, không phải ảnh chụp:

Dashboard hiện metric và log HIỆN TẠI
    → thêm widget nhạy cảm vào sau này
    → người đã được chia sẻ cũng thấy luôn
        ↓
    Rà lại danh sách người xem khi sửa dashboard

Ba lưu ý về CloudWatch Logs Insights: | Lưu ý | Chi tiết | |---|---| | Truy vấn log không cần chuyển đi đâu | | | Tính phí theo GB quét | | | Lưu truy vấn để dùng lại | |

fields @timestamp, @message
| filter @message like /Exception/
| stats count() by bin(1h)

Ba lưu ý về chi phí CloudWatch Logs: | Khoản | Chi tiết | |---|---| | Phí nạp theo GB | khoản lớn nhất | | Phí lưu trữ theo GB-tháng | | | Phí truy vấn Insights theo GB quét | |

⚠ Log Class Infrequent Access rẻ hơn cho log ít đọc:

aws logs create-log-group --log-group-name /ung-dung/chi-tiet \
  --log-group-class INFREQUENT_ACCESS

Rẻ hơn ~50% phí nạp
    → nhưng không dùng được với alarm và Live Tail

Ba lưu ý về quyền tối thiểu: | Nguyên tắc | Chi tiết | |---|---| | Bắt đầu từ không có gì, thêm dần | | | Giới hạn theo tài nguyên cụ thể | | | Đặt hạn cho quyền tạm thời | |

⚠ Access Analyzer tìm được quyền cấp thừa:

aws accessanalyzer create-analyzer \
  --analyzer-name phan-tich-quyen-thua \
  --type ACCOUNT_UNUSED_ACCESS

Ba lưu ý về truy cập của bên thứ ba: | Lưu ý | Chi tiết | |---|---| | Dùng vai trò có ExternalId | | | Không bao giờ chia sẻ access key | | | Ghi log mọi phiên | |

Ba lưu ý về bastion (nếu buộc phải có): | Lưu ý | Chi tiết | |---|---| | Dùng Session Manager thay bastion | | | Không cache credential dùng chung | | | Ghi log toàn bộ phiên | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người được chia sẻ mở link, xem được | | | Thử truy cập console AWS | phải không vào được | | Thu hồi rồi kiểm tra lại | |

Và một lời khuyên: hãy rà lại danh sách người được chia sẻ dashboard mỗi khi thêm widget mới. Dashboard chia sẻ hiển thị dữ liệu trực tiếp chứ không phải ảnh chụp, nên một widget metric thêm vào tháng sau sẽ tự động lộ ra cho tất cả những người bạn đã cấp quyền từ tháng trước.

Đáp án

A — Dùng Amazon Transcribe để nhận diện nhiều người nói, và Amazon Athena để phân tích tệp bản ghi.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp này khớp từng cái: | Yêu cầu | Dịch vụ | |---|---| | Chuyển giọng nói thành văn bản | Transcribe | | Nhận diện NHIỀU người nói | Transcribe speaker diarization | | Truy vấn bản ghi để phân tích | Athena chạy SQL trên S3 |

⚠ Speaker diarization là tính năng có sẵn, chỉ cần bật:

aws transcribe start-transcription-job \
  --transcription-job-name cuoc-goi-12345 \
  --language-code vi-VN \
  --media MediaFileUri=s3://ghi-am/cuoc-goi-12345.wav \
  --output-bucket-name ban-ghi-cuoc-goi \
  --settings 'ShowSpeakerLabels=true,MaxSpeakerLabels=2'

Kết quả tách được ai nói gì:

{"speaker_labels": {"segments": [
  {"speaker_label": "spk_0", "start_time": "0.0", "end_time": "3.5"},
  {"speaker_label": "spk_1", "start_time": "3.6", "end_time": "8.2"}]}}

⚠ MaxSpeakerLabels phải đặt đúng — tối đa 30:

Đặt quá thấp: hai người bị gộp làm một
Đặt quá cao:  một người bị tách thành nhiều
        ↓
    Với tổng đài thường là 2 (nhân viên + khách)

Bảng Athena trên tệp bản ghi:

CREATE EXTERNAL TABLE ban_ghi (
  jobName    string,
  results    struct<
    transcripts: array<struct<transcript: string>>,
    speaker_labels: struct<speakers: int>>)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://ban-ghi-cuoc-goi/';

SELECT results.transcripts[1].transcript AS noi_dung
FROM ban_ghi
WHERE results.transcripts[1].transcript LIKE '%huy dich vu%';

⚠ Hai tính năng của Transcribe rất hợp tổng đài: | Tính năng | Việc | |---|---| | Custom vocabulary | dạy tên sản phẩm, thuật ngữ riêng | | Vocabulary filtering | che hoặc gắn cờ từ nhạy cảm | | PII redaction | tự che số thẻ, số CMND |

aws transcribe start-transcription-job \
  --transcription-job-name cuoc-goi-12345 \
  --content-redaction 'RedactionType=PII,
                       RedactionOutput=redacted' \
  ...

⚠ Che PII gần như bắt buộc với ghi âm tổng đài:

Khách đọc số thẻ tín dụng qua điện thoại
    → nằm nguyên văn trong bản ghi trên S3
        ↓
    Bật content redaction → tự thay bằng [PII]

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không huấn luyện mô hình nào | | | Athena không cần hạ tầng | | | Trả tiền theo phút âm thanh và dữ liệu quét | |

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

• **D. Dùng Rekognition nhận diện người nói, lưu S3, dùng Textract phân tích — sai hai chỗ: Rekognition xử lý ẢNH và VIDEO, không xử lý âm thanh; Textract trích văn bản từ TÀI LIỆU quét, không truy vấn được dữ liệu.
• **B. Dùng Rekognition rồi mô hình học máy tự dựng — cũng sai dịch vụ ở bước đầu, và tự dựng mô hình là công vận hành lớn khi Athena đủ dùng.
• **C. Dùng Translate nhận diện người nói, lưu Redshift — Translate là dịch ngôn ngữ, không phải nhận dạng giọng nói; và Redshift là cụm phải quản lý.

Ghi nhớ

⚠ Các dịch vụ AI của AWS — bảng phải thuộc: | Dịch vụ | Đầu vào → Đầu ra | |---|---| | Transcribe | âm thanh → văn bản | | Polly | văn bản → âm thanh | | Translate | văn bản → văn bản ngôn ngữ khác | | Comprehend | văn bản → cảm xúc, thực thể, chủ đề | | Rekognition | ảnh/video → nhãn, khuôn mặt | | Textract | tài liệu quét → văn bản có cấu trúc |

⚠ Cách nhớ nhanh nhất — nhìn vào ĐẦU VÀO:

Âm thanh    → Transcribe
Ảnh/video   → Rekognition
Tài liệu    → Textract
Văn bản     → Comprehend / Translate

Từ khoá nhận diện:

"speech to text, multiple speakers" → Transcribe + diarization "sentiment of customer calls" → Transcribe rồi Comprehend "query transcript files with SQL" → Athena "scanned invoices, forms" → Textract "detect objects in images" → Rekognition

⚠ Comprehend là bước tiếp theo tự nhiên cho đề này:

aws comprehend batch-detect-sentiment \
  --language-code vi --text-list "Toi rat hai long" "Dich vu qua te"

Transcribe → văn bản
    → Comprehend → cảm xúc, chủ đề, thực thể
        ↓
    Athena truy vấn cả hai
    → "cuộc gọi tiêu cực nào nhắc tới sản phẩm X?"

Ba lưu ý về Transcribe: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ hơn 100 ngôn ngữ, có tiếng Việt | | | Có chế độ streaming thời gian thực | | | Channel identification cho âm thanh 2 kênh | |

⚠ Channel identification chính xác hơn diarization khi có sẵn 2 kênh:

Tổng đài thường ghi 2 kênh riêng:
    kênh trái = nhân viên, kênh phải = khách
        ↓
    ChannelIdentification=true chính xác tuyệt đối
    → hơn hẳn đoán theo giọng

--settings 'ChannelIdentification=true'

Ba lưu ý về Transcribe Call Analytics: | Tính năng | Việc | |---|---| | Phân tích cảm xúc theo từng đoạn | | | Đo thời gian nói và thời gian im lặng | | | Phát hiện ngắt lời | |

⚠ Call Analytics là API chuyên cho tổng đài — làm sẵn nhiều thứ mà tự ghép Transcribe + Comprehend mới có.

Ba lưu ý về Athena trên JSON: | Lưu ý | Chi tiết | |---|---| | JSON lồng nhau truy vấn được bằng struct | | | Chuyển sang Parquet để rẻ hơn nhiều | | | Phân vùng theo ngày | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Transcribe | ~0,024 USD mỗi phút | | Athena | ~5 USD mỗi TB quét | | S3 | theo GB lưu |

⚠ Transcribe tính theo phút — chi phí tăng theo lưu lượng cuộc gọi:

10.000 cuộc gọi × 5 phút = 50.000 phút
    → ~1.200 USD mỗi tháng
        ↓
    Cân nhắc chỉ chuyển đổi mẫu ngẫu nhiên,
    hoặc chỉ cuộc gọi bị đánh dấu

Ba lưu ý về custom vocabulary: | Lưu ý | Chi tiết | |---|---| | Dạy tên sản phẩm và viết tắt riêng | | | Cải thiện độ chính xác rõ rệt | | | Custom language model cho lĩnh vực đặc thù | |

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Bật PII redaction | | | Mã hoá bucket bằng KMS | | | Đặt lifecycle xoá ghi âm cũ | |

Ba lưu ý về tự động hoá: | Bước | Cách | |---|---| | S3 event khi có ghi âm mới | | | Lambda gọi Transcribe | | | Step Functions cho luồng nhiều bước | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nghe lại một cuộc gọi, so bản ghi | | | Kiểm tra nhãn người nói có đúng | | | Chạy truy vấn Athena thử | |

Và một lời khuyên: hãy dùng channel identification thay vì speaker diarization nếu hệ thống tổng đài ghi hai kênh riêng. Đoán người nói theo đặc trưng giọng luôn có sai sót, nhất là khi hai người nói chồng lời — còn tách theo kênh thì đúng tuyệt đối và không tốn thêm gì.