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

Đáp án

A — Tạo MỘT SNS topic và cấu hình các SQS queue đăng ký (subscribe) vào topic đó. Đặt filter policy trong SNS subscription để thông điệp được gửi tới đúng queue theo loại yêu cầu báo giá.

Vì sao đúng

Đề nêu ba yêu cầu, và A đáp ứng cả ba với cấu hình gọn nhất: | Yêu cầu | Cơ chế | |---|---| | Lọc thông điệp | SNS subscription filter policy | | Mỗi loại yêu cầu một SQS queue riêng | fan-out từ một topic | | Xử lý không quá 24 giờ | SQS giữ thông điệp tới 14 ngày |

Filter policy là tính năng dựng sẵn của SNS — nó lọc NGAY TẠI SNS:

Publisher gửi MỘT thông điệp với thuộc tính:
    MessageAttributes: {"loai_bao_gia": {"DataType": "String",
                                          "StringValue": "xe-hoi"}}
    ↓
SNS topic đánh giá filter policy của TỪNG subscription
    ├─ queue-xe-hoi   (filter: loai_bao_gia = xe-hoi)     → NHẬN
    ├─ queue-nha-cua  (filter: loai_bao_gia = nha-cua)    → bỏ qua
    └─ queue-suc-khoe (filter: loai_bao_gia = suc-khoe)   → bỏ qua

{"loai_bao_gia": ["xe-hoi"]}

Ba lợi ích so với việc gửi mọi thông điệp tới mọi queue: | Lợi ích | Chi tiết | |---|---| | Mỗi queue chỉ nhận thông điệp liên quan | consumer không phải lọc và bỏ đi | | Tiết kiệm chi phí | không trả tiền cho thông điệp bị vứt | | Publisher không cần biết có bao nhiêu queue | thêm loại mới chỉ cần thêm subscription |

Dòng cuối là giá trị kiến trúc lớn nhất — đây chính là mục đích của mô hình pub/sub.

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

• **B. Tạo một SNS topic, các SQS queue subscribe; publish CÙNG thông điệp tới MỌI queue rồi lọc trong từng queue — đây là phương án gần nhất và hoạt động được, nhưng nó lãng phí: mọi queue nhận mọi thông điệp, consumer phải đọc rồi vứt đi phần lớn. Tốn chi phí SQS request và công xử lý vô ích.
• **C. Tạo NHIỀU SNS topic và các SQS queue subscribe vào chúng; publish tới queue phù hợp theo loại — đẩy gánh nặng sang publisher: nó phải biết có bao nhiêu loại và chọn đúng topic. Thêm một loại mới là phải sửa mã publisher — mất hẳn lợi ích tách rời.
• **D. Tạo Kinesis Data Stream; dùng Kinesis Client Library đưa bản ghi tới đúng SQS queue — phức tạp và tốn kém không cần thiết: bạn phải tự viết và vận hành ứng dụng KCL để làm việc mà SNS filter policy làm sẵn. Và Kinesis tính phí theo shard-giờ chạy liên tục.

Ghi nhớ

Mẫu fan-out SNS + SQS — kiến trúc nên thuộc:

Publisher → SNS topic → nhiều SQS queue → nhiều consumer độc lập
                      ↑ filter policy quyết định queue nào nhận

Cú pháp filter policy — các toán tử hay dùng:

{"loai": ["xe-hoi", "xe-may"]}                    // khớp một trong các giá trị
{"gia": [{"numeric": [">=", 1000000]}]}            // so sánh số
{"ten": [{"prefix": "BH-"}]}                       // tiền tố
{"trang_thai": [{"anything-but": "huy"}]}          // loại trừ
{"khu_vuc": [{"exists": true}]}                    // thuộc tính tồn tại

Hai phạm vi lọc của SNS: | Phạm vi | Lọc theo | |---|---| | MessageAttributes (mặc định) | thuộc tính thông điệp | | MessageBody | nội dung JSON của thông điệp |

Phạm vi thứ hai đáng biết: nó cho phép lọc theo trường trong chính payload, nên publisher không cần đặt thuộc tính riêng.

SNS và SQS — phân biệt cốt lõi: | | SNS | SQS | |---|---|---| | Mô hình | push (đẩy), pub/sub | poll (kéo), hàng đợi | | Số người nhận | nhiều | một consumer mỗi thông điệp | | Lưu giữ | KHÔNG — gửi rồi thôi | 1–14 ngày |

Kết hợp cả hai lấy được ưu điểm của cả hai: SNS phát tán, SQS đệm để consumer chết cũng không mất thông điệp.

Ba cấu hình quan trọng khi dùng SNS → SQS: | Cấu hình | Việc | |---|---| | SQS queue policy cho phép SNS gửi vào | thiếu là thông điệp không tới | | RawMessageDelivery = true | bỏ lớp bọc JSON của SNS — consumer đọc payload gốc | | Redrive policy (DLQ) | thông điệp gửi thất bại |

Queue policy bắt buộc:

{"Effect": "Allow", "Principal": {"Service": "sns.amazonaws.com"},
 "Action": "SQS:SendMessage", "Resource": "arn:aws:sqs:...:queue-xe-hoi",
 "Condition": {"ArnEquals": {"aws:SourceArn": "arn:aws:sns:...:bao-gia"}}}

Ba lưu ý về "không quá 24 giờ" mà đề nhắc tới: | Lưu ý | Chi tiết | |---|---| | SQS giữ thông điệp mặc định 4 ngày | đặt được từ 1 phút tới 14 ngày | | VisibilityTimeout phải dài hơn thời gian xử lý | nếu không thông điệp bị xử lý lặp | | Dùng DLQ để tách thông điệp lỗi | không để chúng chặn hàng đợi |

Và một lựa chọn thay thế đáng biết: EventBridge cũng làm được mẫu này với khả năng lọc mạnh hơn (khớp theo bất kỳ trường nào, có toán tử phức tạp hơn) và nhiều loại target hơn. Với hệ thống định tuyến sự kiện phức tạp, EventBridge thường là lựa chọn tốt hơn SNS — nhưng với việc lọc đơn giản theo một thuộc tính như đề mô tả, SNS filter policy là đủ và rẻ hơn.

Đáp án

C — Tạo một endpoint policy cho các S3 bucket tin cậy.

Vì sao đúng

Đề nêu rõ: dùng gateway endpoint và muốn chỉ cho phép truy cập tới các bucket tin cậy — đó chính là công việc của endpoint policy.

Endpoint policy kiểm soát những gì ĐI QUA endpoint:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": [
      "arn:aws:s3:::bucket-tin-cay-1/*",
      "arn:aws:s3:::bucket-tin-cay-2/*"
    ]
  }]
}

Hiệu quả: mọi request qua endpoint này chỉ chạm được tới hai bucket đó.

EC2 trong VPC → gateway endpoint → CHỈ bucket-tin-cay-1 và 2
    → gọi bucket khác → BỊ TỪ CHỐI ngay tại endpoint
    → kể cả khi IAM policy của instance cho phép

Đây là lớp phòng thủ theo chiều sâu rất giá trị: | Tình huống | Kết quả | |---|---| | Instance bị xâm nhập, kẻ tấn công có IAM role rộng | vẫn không chạm tới bucket ngoài danh sách | | Nhân viên vô tình cấu hình sai IAM policy | endpoint policy chặn lại | | Ngăn rò rỉ dữ liệu ra bucket của người khác | không copy sang bucket lạ được |

Dòng cuối là ứng dụng quan trọng nhất trong thực tế: nó ngăn việc dữ liệu bị sao chép sang một bucket thuộc tài khoản ngoài — một kênh rò rỉ dữ liệu khó phát hiện.

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

• **D. Tạo endpoint policy cho các VPC tin cậy — đây là phương án gần nhất và dùng đúng loại policy, nhưng nó nhầm chiều kiểm soát: endpoint policy gắn vào chính endpoint đó, vốn đã nằm trong một VPC cụ thể. Nó kiểm soát tài nguyên nào truy cập được, không phải "VPC nào được dùng endpoint".
• **A. Tạo bucket policy cho các VPC tin cậy — đúng cơ chế nhưng sai chiều với yêu cầu của đề: bucket policy với aws:SourceVpce ràng buộc bucket chỉ nhận request từ endpoint nào. Đề muốn ngược lại: endpoint chỉ tới được bucket nào.
• **B. Tạo bucket policy cho các S3 bucket tin cậy — mơ hồ và không đúng phạm vi: bucket policy nằm trên từng bucket và kiểm soát ai truy cập bucket đó. Nó không kiểm soát được hành vi của một endpoint dùng chung.

Ghi nhớ

Hai loại VPC endpoint: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway | CHỈ S3 và DynamoDB | route table entry | MIỄN PHÍ | | Interface | hầu hết dịch vụ khác | ENI (PrivateLink) | theo giờ + GB |

Hai chiều kiểm soát — hiểu rõ để không nhầm:

① ENDPOINT POLICY (gắn trên endpoint)
   → "qua endpoint này, được làm gì với tài nguyên nào"
   → BẢO VỆ: ngăn instance trong VPC chạm tới bucket lạ

② BUCKET POLICY với aws:SourceVpce (gắn trên bucket)
   → "bucket này chỉ nhận request từ endpoint nào"
   → BẢO VỆ: ngăn người ngoài truy cập bucket

Kết hợp cả hai tạo thành khoá hai chiều:

// Trên bucket: chỉ nhận từ endpoint của mình
{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-du-lieu/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Kết quả: bucket chỉ nhận request qua endpoint này, và endpoint này chỉ tới được bucket đó — một instance bị xâm nhập cũng không đi đâu được.

Ba condition key ràng buộc nguồn mạng cho S3: | Key | Ràng buộc theo | Độ chặt | |---|---|---| | aws:SourceVpce | một VPC endpoint cụ thể | chặt nhất | | aws:SourceVpc | một VPC | vừa | | aws:SourceIp | dải IP công khai | KHÔNG dùng được cho lưu lượng qua endpoint |

Dòng cuối là bẫy hay gặp: đặt aws:SourceIp cho lưu lượng qua VPC endpoint sẽ chặn hết — request không mang IP công khai nào.

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ROUTE TABLE | endpoint tạo xong mà không gắn thì không có tác dụng | | Chỉ dùng được TRONG VPC | không truy cập được từ tại chỗ qua Direct Connect/VPN | | Miễn phí và giảm chi phí NAT | lưu lượng S3 không qua NAT Gateway nữa |

Dòng giữa là lý do đôi khi vẫn dùng Interface endpoint cho S3 — khi cần truy cập riêng tư từ trung tâm dữ liệu.

Endpoint policy mặc định cho phép mọi thứ — nếu bạn không đặt policy, mọi request qua endpoint đều được phép (vẫn phải qua IAM và bucket policy). Nên việc đặt policy hẹp là bước siết chặt chủ động.

Và một lưu ý khi viết endpoint policy: nhớ khai cả hai dạng ARN nếu cần liệt kê object lẫn thao tác trên bucket:

arn:aws:s3:::bucket      → cho s3:ListBucket
arn:aws:s3:::bucket/*    → cho s3:GetObject, s3:PutObject

Thiếu một trong hai là một nửa thao tác thất bại với lỗi AccessDenied khó chẩn đoán.

Đáp án

C — Dùng AWS Config để thiết lập một rule trong tài khoản.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Config là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cơ chế | |---|---| | Đánh giá và kiểm toán MỌI cấu hình trong tài khoản | Config ghi lịch sử cấu hình tài nguyên | | Theo dõi mọi thay đổi cấu hình của S3 bucket | configuration history + timeline | | Tự động phát hiện bucket công khai | managed rule s3-bucket-public-read-prohibited |

Ba khả năng của Config, và cả ba đều cần cho đề này:

① Configuration history
   → ảnh chụp cấu hình từng tài nguyên theo thời gian
   → trả lời "bucket này trông thế nào vào ngày 15 tháng trước"

② Config rules
   → đánh giá LIÊN TỤC xem tài nguyên có tuân thủ không
   → managed rule có sẵn cho hầu hết nhu cầu

③ Remediation action
   → TỰ ĐỘNG sửa tài nguyên vi phạm qua SSM Automation

Các managed rule liên quan tới S3 — có sẵn, chỉ cần bật: | Rule | Kiểm tra | |---|---| | s3-bucket-public-read-prohibited | bucket có cho đọc công khai không ← câu này | | s3-bucket-public-write-prohibited | bucket có cho ghi công khai không | | s3-bucket-server-side-encryption-enabled | có bật mã hoá không | | s3-bucket-versioning-enabled | có bật versioning không | | s3-bucket-ssl-requests-only | có bắt buộc HTTPS không |

Và remediation action biến phát hiện thành tự động sửa:

aws configservice put-remediation-configurations   --remediation-configurations '[{
    "ConfigRuleName": "s3-bucket-public-read-prohibited",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-DisableS3BucketPublicReadWrite",
    "Automatic": true}]'

Bucket bị đặt công khai sẽ tự động bị khoá lại trong vài phút — không cần ai can thiệp.

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

• **D. Dùng AWS CloudTrail và xem lịch sử sự kiện của tài khoản — đây là phương án gần nhất và CloudTrail là nguồn dữ liệu thiết yếu, nhưng nó trả lời câu hỏi khác: "AI đã làm gì, khi nào". Nó không đánh giá xem cấu hình có ĐÚNG CHUẨN hay không, và không tự phát hiện bucket công khai.
• **A. Dùng AWS Trusted Advisor phân tích môi trường — hạn chế về phạm vi và tần suất: Trusted Advisor đưa ra khuyến nghị về chi phí, hiệu năng, giới hạn dịch vụ và một số kiểm tra bảo mật cơ bản. Nó chạy theo chu kỳ, không đánh giá liên tục, và không có lịch sử cấu hình.
• **B. Dùng AWS IAM tạo credential report — sai phạm vi hoàn toàn: credential report liệt kê trạng thái thông tin đăng nhập của IAM user (mật khẩu, access key, MFA). Nó không liên quan gì tới cấu hình S3.

Ghi nhớ

Bốn dịch vụ quản trị và tuân thủ — bảng phân biệt cốt lõi: | Dịch vụ | Trả lời | |---|---| | AWS Config | "Tài nguyên có cấu hình ĐÚNG CHUẨN không?" ← câu này | | CloudTrail | "AI đã làm gì, khi nào?" | | Security Hub | "Tổng hợp mọi cảnh báo, tôi ở mức tuân thủ nào?" | | Trusted Advisor | "Tôi có đang lãng phí tiền không?" |

Cả bốn nên dùng cùng nhau trong một khung quản trị đầy đủ:

CloudTrail   → ghi mọi hoạt động
Config       → đánh giá tuân thủ liên tục + tự khắc phục
Security Hub → tổng hợp và chấm điểm theo CIS, PCI DSS
EventBridge  → kích hoạt phản ứng tức thì

Hai chế độ kích hoạt của Config rule: | Chế độ | Chạy khi | |---|---| | Configuration change | NGAY khi tài nguyên thay đổi | | Periodic | theo lịch: 1, 3, 6, 12 hoặc 24 giờ |

Chế độ đầu cho đúng nghĩa "continuously assessing" mà đề yêu cầu.

Ba cách viết Config rule: | Cách | Công sức | |---|---| | Managed rule | thấp nhất — AWS viết sẵn hàng trăm cái | | Custom rule bằng Guard policy | vừa — ngôn ngữ khai báo, không cần mã | | Custom rule bằng Lambda | cao nhất — linh hoạt nhất |

Conformance pack đáng biết cho ngành chịu quản lý: thay vì bật từng rule, bạn triển khai một gói chuẩn sẵn (PCI DSS, HIPAA, NIST) và có ngay bảng điểm tuân thủ.

Nhưng biện pháp NGĂN CHẶN vẫn tốt hơn phát hiện: | Lớp | Vai trò | |---|---| | S3 Block Public Access ở mức TÀI KHOẢN | NGĂN CHẶN — mạnh nhất | | SCP chặn s3:PutAccountPublicAccessBlock | không ai tắt được lớp trên | | Config rule + remediation | phát hiện và sửa ← câu này |

Block Public Access ở mức tài khoản khiến mọi ACL và bucket policy công khai bị vô hiệu hoá — nó biến vấn đề từ "phát hiện và sửa" thành "không thể xảy ra".

Ba lưu ý về chi phí Config: | Lưu ý | Chi tiết | |---|---| | Tính phí theo số configuration item được ghi | môi trường lớn tốn đáng kể | | Giới hạn loại tài nguyên cần ghi | thay vì "record all resources" | | Rule evaluation cũng tính phí | cân nhắc số rule và tần suất |

Và với tổ chức nhiều tài khoản: dùng Config aggregator để xem dữ liệu tuân thủ của mọi tài khoản và Region ở một chỗ — mà không phải chia sẻ thông tin đăng nhập của tài khoản quản lý.

Đáp án

A — Gán một Elastic IP address cho Network Load Balancer.

Vì sao đúng

Đề nêu ràng buộc quyết định: khách hàng chỉ truy cập được các địa chỉ IP đã được đưa vào danh sách trắng trên tường lửa của họ — tức là cần địa chỉ IP TĨNH.

Chỉ NLB hỗ trợ địa chỉ IP tĩnh:

Application Load Balancer:
    → chỉ có TÊN DNS
    → địa chỉ IP phía sau THAY ĐỔI khi ALB co giãn
    → không đưa vào danh sách trắng được

Network Load Balancer:
    → gán được MỘT Elastic IP cho MỖI Availability Zone
    → địa chỉ CỐ ĐỊNH vĩnh viễn
    → khách hàng đưa vào tường lửa một lần là xong

aws elbv2 create-load-balancer   --name nlb-api-cong-khai --type network --scheme internet-facing   --subnet-mappings     SubnetId=subnet-0aaa,AllocationId=eipalloc-0111     SubnetId=subnet-0bbb,AllocationId=eipalloc-0222

Và đây là trường hợp sử dụng cổ điển của NLB: API công khai phục vụ khách hàng doanh nghiệp có chính sách tường lửa nghiêm ngặt.

Ba đặc điểm khác của NLB cũng phù hợp với API: | Đặc điểm | Chi tiết | |---|---| | Độ trễ cực thấp | hoạt động ở tầng 4 | | Giữ IP nguồn của client | backend thấy IP thật | | Chịu được hàng triệu request mỗi giây | không cần "làm nóng" |

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

• **C. Gán một Elastic IP cho Application Load Balancer — đây là phương án gần nhất và là bẫy chính của câu hỏi: ALB KHÔNG hỗ trợ Elastic IP. Nó chỉ có tên DNS, và AWS chủ động thay đổi các địa chỉ phía sau khi mở rộng.
• **D. Tạo Alias Record trong Route 53 trỏ tới tên DNS của load balancer — không giải quyết vấn đề: alias record cho một tên miền đẹp, nhưng nó vẫn phân giải ra các IP thay đổi của ALB. Tường lửa của khách hàng lọc theo IP, không theo tên miền.
• **B. Tạo CloudFront distribution với origin trỏ tới IP RIÊNG của web server — hai lỗi: CloudFront không kết nối được tới IP riêng trong VPC (nó cần origin công khai hoặc qua VPC origin); và CloudFront cũng dùng dải IP thay đổi, không cho địa chỉ tĩnh.

Ghi nhớ

Ba loại Elastic Load Balancer — bảng cần thuộc: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (GENEVE) | | Địa chỉ IP tĩnh | ❌ | ✅ Elastic IP mỗi AZ | — | | Path/host-based routing | ✅ | ❌ | ❌ | | Tích hợp WAF | ✅ | ❌ | ❌ | | Giữ IP nguồn client | qua X-Forwarded-For | ✅ nguyên bản | ✅ | | Độ trễ | cao hơn | cực thấp | — |

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

"static IP", "IP whitelisting", "firewall rules", "extreme performance" → NLB "path-based", "host-based", "WAF", "gRPC" → ALB

Và nếu cần CẢ HAI — IP tĩnh lẫn tính năng tầng 7:

Client → NLB (Elastic IP tĩnh) → ALB (path/host routing, WAF) → target

NLB hỗ trợ ALB làm target — đây là mẫu kiến trúc chuẩn khi khách hàng cần whitelist IP nhưng bạn vẫn muốn định tuyến tầng 7.

Một lựa chọn khác cho IP tĩnh: AWS Global Accelerator. | | NLB + Elastic IP | Global Accelerator | |---|---|---| | IP tĩnh | một EIP mỗi AZ | hai IP ANYCAST toàn cầu | | Phạm vi | một Region | nhiều Region | | Định tuyến | trong Region | tự chuyển sang Region khoẻ mạnh | | Chi phí | thấp hơn | cao hơn |

Global Accelerator đáng cân nhắc nếu API triển khai ở nhiều Region — khách hàng chỉ cần whitelist hai địa chỉ cho toàn bộ hệ thống.

Ba lưu ý về Elastic IP trên NLB: | Lưu ý | Chi tiết | |---|---| | Gán lúc TẠO NLB | không thêm được sau | | Một EIP cho mỗi subnet/AZ | dùng nhiều AZ thì cần nhiều EIP | | Khách hàng phải whitelist TẤT CẢ | tài liệu rõ danh sách IP cho họ |

Dòng đầu là ràng buộc quan trọng: nếu quên gán EIP lúc tạo, bạn phải tạo lại NLB.

Ba lưu ý khi công bố API cho khách hàng doanh nghiệp: | Lưu ý | Chi tiết | |---|---| | Công bố danh sách IP rõ ràng và ổn định | thay đổi IP là khách hàng mất kết nối | | Báo trước khi thêm AZ | thêm AZ nghĩa là thêm một IP mới | | Cân nhắc Global Accelerator nếu cần mở rộng đa Region | tránh phải cập nhật danh sách sau này |

Và một biện pháp bảo mật đáng làm song song: NLB truyền thống không có security group, nên hãy kiểm soát ở tầng target — security group của EC2 chỉ cho phép lưu lượng từ dải subnet của NLB, và cân nhắc mutual TLS nếu API phục vụ khách hàng cần xác thực mạnh.

Đáp án

C — Cài CloudWatch agent trên mỗi instance và theo dõi metric SwapUtilization.

Vì sao đúng

Đề cần giám sát dung lượng swap còn trống — và đó là thông tin bên trong hệ điều hành, không phải thứ hypervisor nhìn thấy.

Nguyên tắc quyết định:

CloudWatch lấy metric từ HYPERVISOR
    → thấy: CPU, mạng, I/O đĩa
    → KHÔNG nhìn được vào bên trong hệ điều hành khách

Swap là vùng nhớ ảo do HỆ ĐIỀU HÀNH quản lý
    → hypervisor không biết gì về nó
    → phải có AGENT chạy trong máy để báo ra

Cấu hình agent để thu thập metric swap:

{
  "metrics": {
    "metrics_collected": {
      "swap": {"measurement": ["swap_used_percent", "swap_free", "swap_used"]},
      "mem": {"measurement": ["mem_used_percent"]}
    },
    "append_dimensions": {"InstanceId": "${aws:InstanceId}"}
  }
}

Và nên thu thập cả metric bộ nhớ cùng lúc — vì swap cạn thường là triệu chứng, còn nguyên nhân gốc là RAM không đủ:

RAM đầy → hệ điều hành đẩy dữ liệu sang swap
        → swap cũng đầy → tiến trình bị OOM killer giết
        → instance "hỏng" theo cách đề mô tả

Triển khai ở quy mô Auto Scaling group:

aws ssm send-command --document-name "AWS-ConfigureAWSPackage"   --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}'   --targets "Key=tag:aws:autoscaling:groupName,Values=asg-ung-dung"

Lưu cấu hình trong SSM Parameter Store để mọi instance mới tự nạp — thay vì cấu hình từng máy.

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

• **A. Bật detailed monitoring trên mỗi instance và theo dõi SwapUtilization — đây là phương án gần nhất và tên metric đúng, nhưng detailed monitoring chỉ giảm chu kỳ từ 5 phút xuống 1 phút cho các metric đã có sẵn. Nó không thêm metric mới nào — SwapUtilization vẫn không tồn tại nếu chưa cài agent.
• **D. Tạo CloudWatch dashboard và theo dõi metric SwapUsed — sai cả tên metric lẫn cách tiếp cận: metric của CloudWatch agent tên là swap_used_percent hoặc swap_used (chữ thường, có gạch dưới). Và dashboard chỉ hiển thị metric đã tồn tại — nó không thu thập gì.
• **B. Tạo trail trong CloudTrail và cấu hình CloudWatch Logs theo dõi log của trail — sai loại dữ liệu hoàn toàn: CloudTrail ghi lời gọi API quản lý AWS. Nó không biết gì về tài nguyên bên trong hệ điều hành.

Ghi nhớ

Quy tắc phân biệt — thuộc lòng cái này là trả lời được cả nhóm câu hỏi:

Hypervisor nhìn thấy được → CloudWatch có sẵn Chỉ hệ điều hành bên trong biết → cần agent

Chú ý khác biệt tinh tế: hoạt động đọc ghi đĩa có sẵn, nhưng dung lượng còn trống thì không — hypervisor đếm được thao tác I/O nhưng không biết hệ thống tệp bên trong đầy bao nhiêu.

Ba khả năng của unified CloudWatch agent: | Khả năng | Chi tiết | |---|---| | Metric hệ thống | bộ nhớ, swap, đĩa, tiến trình, kết nối TCP | | Log | tệp log ứng dụng, Windows Event Log | | Trace | qua OpenTelemetry, X-Ray |

Quyền cần cho agent — managed policy CloudWatchAgentServerPolicy:

cloudwatch:PutMetricData
ec2:DescribeVolumes, ec2:DescribeTags
logs:CreateLogGroup, CreateLogStream, PutLogEvents, DescribeLogStreams
ssm:GetParameter

Cùng nguyên tắc áp cho các dịch vụ khác: | Dịch vụ | Công cụ cho metric mức hệ điều hành | |---|---| | EC2 | CloudWatch agent ← câu này | | RDS | Enhanced Monitoring | | ECS / EKS | Container Insights | | Lambda | Lambda Insights |

Và với vấn đề gốc mà đề mô tả — instance hỏng vì thiếu swap — giám sát chỉ là bước đầu. Ba hướng xử lý thật: | Hướng | Chi tiết | |---|---| | Tăng RAM (đổi loại instance) | swap cạn thường nghĩa là RAM không đủ | | Tăng dung lượng swap | biện pháp tạm, và swap trên EBS rất chậm | | Tìm rò rỉ bộ nhớ trong ứng dụng | nguyên nhân gốc phổ biến |

Dòng cuối đáng nghi nhất khi sự cố lặp lại: nếu instance chạy tốt vài ngày rồi mới hết swap, đó là dấu hiệu điển hình của rò rỉ bộ nhớ — thêm RAM chỉ kéo dài thời gian tới lần hỏng tiếp theo.

Và một cấu hình đáng đặt kèm: CloudWatch alarm trên swap_used_percent và mem_used_percent với action gửi SNS — để biết trước khi instance thực sự hỏng, thay vì phát hiện qua việc Auto Scaling thay máy.

Đáp án

A — Tạo một subnet IPv4 mới với dải CIDR lớn hơn. Gắn subnet mới vào VPC rồi khởi chạy instance.

Vì sao đúng

Đề mô tả lỗi cụ thể: "no available IP addresses on the subnet" — đó là cạn địa chỉ ở mức SUBNET, và giải pháp trực tiếp là tạo subnet có dải lớn hơn.

Vì sao subnet cạn địa chỉ nhanh hơn tưởng:

Mỗi subnet, AWS GIỮ LẠI 5 địa chỉ:
    .0    → địa chỉ mạng
    .1    → router của VPC
    .2    → DNS của AWS
    .3    → dành riêng cho tương lai
    .255  → địa chỉ broadcast (không dùng nhưng vẫn giữ)

Subnet /28 = 16 địa chỉ → chỉ dùng được 11
Subnet /24 = 256 địa chỉ → dùng được 251

Và mỗi ENI chiếm một địa chỉ — nên số instance thực tế còn ít hơn nếu có nhiều ENI, NAT Gateway, hay endpoint trong subnet.

Cách xử lý đầy đủ:

# Nếu VPC CIDR còn chỗ: tạo subnet mới lớn hơn
aws ec2 create-subnet --vpc-id vpc-0abc   --cidr-block 10.0.16.0/20 --availability-zone ap-northeast-1a

# Nếu VPC CIDR đã cạn: THÊM CIDR block phụ vào VPC trước
aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc   --cidr-block 10.1.0.0/16

Bước thứ hai là điều đề ám chỉ khi nói "IPv4 CIDR blocks are nearing exhaustion" — VPC hỗ trợ tối đa 5 CIDR block IPv4 (tăng được tới 50), nên bạn mở rộng không gian địa chỉ mà không phải dựng lại VPC.

Và vế "allowing future scalability" được đáp ứng bằng cách chọn dải đủ rộng ngay từ đầu — /20 cho 4.091 địa chỉ dùng được, thay vì /24 chỉ 251.

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

• **C. Tạo một subnet CHỈ IPv6 với dải CIDR lớn và khởi chạy instance ở đó — đây là phương án gần nhất và là hướng đi hợp lệ về lâu dài (VPC đã có IPv6), nhưng nó có nhiều ràng buộc thực tế: subnet IPv6-only chỉ hỗ trợ instance thế hệ Nitro, và mọi dịch vụ chỉ có IPv4 (nhiều endpoint, một số AMI, phần mềm bên thứ ba) sẽ không truy cập được nếu không dựng thêm NAT64 và DNS64. Đây là thay đổi kiến trúc, không phải cách khắc phục nhanh.
• **B. Đảm bảo VPC chỉ có CIDR IPv6, gỡ mọi CIDR IPv4 — không thực hiện được: không gỡ được CIDR IPv4 chính của VPC. Nó được gán lúc tạo và tồn tại suốt vòng đời VPC.
• **D. Tắt hỗ trợ IPv4 trong VPC và dùng địa chỉ IPv6 — cùng vấn đề: không có tuỳ chọn "tắt IPv4" cho một VPC đã có CIDR IPv4.

Ghi nhớ

Năm địa chỉ AWS giữ lại trong mỗi subnet — con số cần thuộc: | Địa chỉ | Việc | |---|---| | .0 | địa chỉ mạng | | .1 | router của VPC | | .2 | máy chủ DNS của AWS | | .3 | dành riêng cho tương lai | | .255 | broadcast (AWS không hỗ trợ broadcast nhưng vẫn giữ) |

Số địa chỉ dùng được theo kích thước subnet: | CIDR | Tổng | Dùng được | |---|---|---| | /28 | 16 | 11 | | /24 | 256 | 251 | | /20 | 4.096 | 4.091 | | /16 | 65.536 | 65.531 |

Giới hạn kích thước subnet của AWS: nhỏ nhất /28, lớn nhất /16.

Ba cách mở rộng không gian địa chỉ của VPC: | Cách | Chi tiết | |---|---| | Thêm CIDR block phụ vào VPC | tối đa 5 (tăng được tới 50) | | Tạo subnet mới lớn hơn | trong không gian còn trống | | Dùng IPv6 | không gian gần như vô hạn |

Lưu ý về CIDR phụ: nó không được chồng lấn với CIDR hiện có, và phải nằm trong cùng nhóm địa chỉ RFC 1918 hoặc là dải công khai bạn sở hữu.

Không thể thay đổi kích thước một subnet đã tạo — bạn phải tạo subnet mới và di chuyển tài nguyên sang.

Khác biệt căn bản giữa IPv4 và IPv6 trong VPC: | | IPv4 | IPv6 | |---|---|---| | Địa chỉ riêng | có (10.x, 172.16-31.x, 192.168.x) | KHÔNG — mọi địa chỉ đều công khai | | Không gian | hữu hạn, dễ cạn | gần như vô hạn | | Cần NAT để ra Internet | ✅ | ❌ (dùng Egress-Only IGW để chặn chiều vào) | | Hỗ trợ dịch vụ AWS | đầy đủ | chưa đầy đủ ở một số dịch vụ |

Dòng cuối là lý do IPv6-only chưa phải lựa chọn mặc định — nhưng nó đang được cải thiện nhanh.

Ba cách quy hoạch địa chỉ tốt hơn cho tương lai: | Cách | Lợi ích | |---|---| | Chọn VPC CIDR đủ rộng ngay từ đầu (/16) | không phải mở rộng sau | | Chia subnet theo AZ và tầng, mỗi cái /20 hoặc /22 | dư chỗ cho tăng trưởng | | Dùng Amazon VPC IP Address Manager (IPAM) | quản lý tập trung, tránh chồng lấn giữa các VPC |

IPAM đáng dùng cho tổ chức nhiều VPC — nó cấp phát dải địa chỉ tự động và ngăn xung đột, thứ hay xảy ra khi cần VPC peering hoặc Transit Gateway về sau.

Và một lưu ý khi khắc phục gấp: kiểm tra xem subnet có bị chiếm bởi ENI mồ côi không. Lambda trong VPC, endpoint đã xoá, hoặc instance đã terminate đôi khi để lại ENI — dọn chúng có thể giải phóng đủ địa chỉ mà không cần đổi gì.

Đáp án

B — Tạo một Amazon EMR cluster và lưu dữ liệu đã xử lý vào Amazon Redshift.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp EMR + Redshift đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Dùng big data processing framework để phân tích | EMR — Hadoop, Spark, Hive, Presto | | Truy cập bằng công cụ BI | Redshift tích hợp sẵn với QuickSight, Tableau, Power BI | | Truy vấn SQL chuẩn | Redshift là kho dữ liệu SQL |

Cụm "big data processing frameworks" chỉ thẳng tới EMR:

Amazon EMR = cụm Hadoop/Spark ĐƯỢC QUẢN LÝ
    → Apache Spark, Hive, Presto, HBase, Flink
    → xử lý dữ liệu bán cấu trúc và có cấu trúc ở quy mô lớn
    → AWS lo việc dựng cụm, vá lỗi, mở rộng

Và "high-performing" cùng "standard SQL queries" chỉ tới Redshift: | Đặc điểm | Chi tiết | |---|---| | Lưu trữ theo CỘT | tối ưu cho truy vấn tổng hợp | | Xử lý song song hàng loạt (MPP) | phân tán truy vấn qua nhiều node | | Tương thích PostgreSQL | công cụ BI kết nối được ngay | | Result caching | truy vấn lặp lại trả về gần như tức thì |

Luồng đầy đủ:

Nguồn dữ liệu đa dạng
    ↓
S3 data lake (dữ liệu thô)
    ↓ EMR xử lý và chuyển đổi
Redshift (dữ liệu đã sẵn sàng phân tích)
    ↓
Công cụ BI + truy vấn SQL

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

• **A. Dùng AWS Glue và lưu dữ liệu đã xử lý vào Amazon S3 — đây là phương án gần nhất và Glue là dịch vụ ETL tốt, nhưng nó thua ở vế hiệu năng truy vấn: dữ liệu để nguyên trên S3 thì truy vấn bằng Athena — nhanh, tiện, nhưng không sánh được với Redshift cho truy vấn phân tích phức tạp lặp lại nhiều lần. Đề hỏi "MOST high-performing".
• **C. Dùng Managed Service for Apache Flink Studio và lưu vào DynamoDB — sai cả hai đầu: Flink dành cho xử lý LUỒNG thời gian thực, không phải phân tích lô trên data lake; và DynamoDB không hỗ trợ SQL chuẩn cũng như không phải kho dữ liệu phân tích.
• **D. Tạo một EC2 instance và lưu dữ liệu vào EBS — không phải kiến trúc big data: một máy đơn lẻ với ổ đĩa gắn kèm không xử lý được khối lượng của một data lake, và không có khả năng song song nào.

Ghi nhớ

Bốn dịch vụ phân tích của AWS — bảng phân biệt cốt lõi: | Dịch vụ | Là gì | Dùng cho | |---|---|---| | Amazon EMR | Hadoop/Spark được quản lý | xử lý big data quy mô lớn, cần kiểm soát framework | | AWS Glue | ETL không máy chủ (Spark bên dưới) | ETL đơn giản, ít công vận hành | | Amazon Athena | SQL không máy chủ trên S3 | truy vấn không thường xuyên, trả tiền theo lượt | | Amazon Redshift | kho dữ liệu MPP | truy vấn phân tích phức tạp, lặp lại, hiệu năng cao |

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

"big data framework", "Spark", "Hadoop", "custom processing" → EMR "ETL", "least operational overhead", "serverless" → Glue "query data in S3 occasionally", "pay per query" → Athena "data warehouse", "BI tools", "complex SQL", "high performance" → Redshift

Athena và Redshift — khi nào chọn cái nào: | | Athena | Redshift | |---|---|---| | Mô hình | không máy chủ, trả theo dữ liệu quét | cụm chạy liên tục | | Chi phí khi không dùng | gần bằng 0 | trả tiền cho cụm | | Hiệu năng truy vấn lặp lại | vừa | cao — có cache và tối ưu hoá | | Phù hợp | truy vấn thỉnh thoảng | bảng điều khiển BI chạy liên tục |

Với "business intelligence tools" như đề mô tả — tức là truy vấn thường xuyên và cần độ trễ thấp — Redshift là lựa chọn đúng.

Ba khả năng đáng biết của Redshift: | Khả năng | Chi tiết | |---|---| | Redshift Spectrum | truy vấn dữ liệu Ở NGUYÊN TRÊN S3 mà không nạp vào cụm | | Redshift Serverless | không quản lý cụm, tự co giãn | | Zero-ETL integration | tự sao chép từ Aurora, DynamoDB sang Redshift |

Redshift Serverless đáng cân nhắc cho triển khai mới: nó giữ được hiệu năng của Redshift mà bỏ được gánh nặng quản lý cụm và trả tiền khi nhàn rỗi.

Redshift Spectrum là cầu nối hay: dữ liệu nóng nạp vào Redshift, dữ liệu lịch sử để trên S3 — một câu SQL truy vấn được cả hai.

Ba lựa chọn compute cho EMR: | Lựa chọn | Đặc điểm | |---|---| | EMR trên EC2 | kiểm soát đầy đủ, dùng Spot tiết kiệm được nhiều | | EMR Serverless | không quản lý cụm — ít công nhất | | EMR trên EKS | chạy Spark trong cụm Kubernetes có sẵn |

Và một tối ưu chi phí lớn cho EMR: dùng Spot Instance cho task node. Task node không lưu dữ liệu HDFS nên mất chúng không mất gì — kết hợp với core node On-Demand, bạn tiết kiệm được 60–90% chi phí compute cho phần dung lượng co giãn.

Đáp án

A — Gắn tag cho tài nguyên với tên phòng ban và bật cost allocation tag.

Vì sao đúng

Đề cần báo cáo tổng chi phí theo từng phòng ban — và cost allocation tag là cơ chế được thiết kế đúng cho việc đó.

Quy trình gồm hai bước, và cả hai đều bắt buộc:

① Gắn tag cho tài nguyên
   Key: PhongBan    Value: KeToan / MarketingIT / ...

② KÍCH HOẠT tag đó làm cost allocation tag
   Billing Console → Cost Allocation Tags → Activate
   ↓
Tag xuất hiện thành CỘT trong Cost and Usage Report
   → nhóm và lọc chi phí theo phòng ban

Bước ② là chỗ hay bị bỏ sót: gắn tag thôi chưa đủ — tag chỉ trở thành chiều phân tích chi phí sau khi được kích hoạt tường minh trong Billing Console.

aws ce update-cost-allocation-tags-status   --cost-allocation-tags-status TagKey=PhongBan,Status=Active

Và có một ràng buộc về thời gian cần biết:

Cost allocation tag CHỈ áp cho chi phí phát sinh SAU KHI kích hoạt
    → dữ liệu chi phí trước đó KHÔNG được gắn nhãn hồi tố
    → nên kích hoạt càng sớm càng tốt

Sau khi có tag, bạn xem báo cáo bằng nhiều cách: | Công cụ | Đặc điểm | |---|---| | Cost Explorer | nhóm theo tag, xem biểu đồ, dự báo | | Cost and Usage Report (CUR) | dữ liệu chi tiết nhất, xuất ra S3 | | AWS Budgets | đặt ngân sách theo tag, cảnh báo khi vượt |

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

• **C. Dùng Cost Explorer xem chi tiêu và lọc dữ liệu sử dụng theo Resource — đây là phương án gần nhất và Cost Explorer là công cụ đúng để XEM, nhưng lọc theo từng tài nguyên không nhóm được theo phòng ban: bạn sẽ có danh sách hàng nghìn instance và bucket mà không biết cái nào của ai. Cần tag mới nhóm được.
• **D. Tạo Cost and Usage Report cho các dịch vụ mà mỗi phòng ban đang dùng — nhầm chiều phân tách: CUR nhóm theo dịch vụ (EC2, S3, RDS), không theo phòng ban. Nhiều phòng ban cùng dùng EC2 thì không tách ra được nếu không có tag.
• **B. Gắn tag cho tài nguyên và cấu hình budget action trong AWS Budgets — có vế tag đúng nhưng sai công cụ: budget action là hành động tự động khi vượt ngân sách (dừng instance, gắn policy hạn chế). Nó không tạo báo cáo tổng hợp chi phí.

Ghi nhớ

Hai loại cost allocation tag: | Loại | Đặc điểm | |---|---| | AWS-generated | aws:createdBy, aws:cloudformation:stack-name — AWS tự gắn | | User-defined | tag bạn tự đặt — phải KÍCH HOẠT thủ công |

Cả hai đều phải kích hoạt trong Billing Console mới dùng được để phân bổ chi phí.

Bốn công cụ quản lý chi phí của AWS: | Công cụ | Việc | |---|---| | Cost Explorer | xem, phân tích, DỰ BÁO chi phí — có API | | Cost and Usage Report (CUR) | dữ liệu chi tiết nhất, xuất ra S3 để phân tích | | AWS Budgets | đặt ngân sách, cảnh báo, hành động tự động | | Cost Anomaly Detection | phát hiện chi phí bất thường bằng học máy |

Dòng cuối đáng bật cho mọi tài khoản — nó cảnh báo khi chi phí lệch khỏi mẫu bình thường, thường phát hiện sớm hơn việc nhìn hoá đơn.

Ba thực hành để chiến lược gắn tag thực sự hiệu quả: | Thực hành | Lý do | |---|---| | Bắt buộc gắn tag khi TẠO tài nguyên | tài nguyên không tag = chi phí không quy được về ai | | Chuẩn hoá tên và giá trị tag | PhongBan khác phongban khác Phong_Ban | | Dùng Tag Policy trong Organizations | thực thi chuẩn trên toàn tổ chức |

Bắt buộc gắn tag bằng SCP hoặc IAM policy:

{"Effect": "Deny", "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"Null": {"aws:RequestTag/PhongBan": "true"}}}

Không có statement này, tag sẽ luôn thiếu ở một phần tài nguyên — và phần đó chính là phần khó quy trách nhiệm nhất.

Tag Policy trong AWS Organizations đi xa hơn: nó định nghĩa giá trị hợp lệ cho từng khoá tag và báo cáo tài nguyên không tuân thủ:

{"tags": {"PhongBan": {
  "tag_value": {"@@assign": ["KeToan", "Marketing", "IT", "NhanSu"]}}}}

Ba hạn chế của tag cần biết: | Hạn chế | Chi tiết | |---|---| | Không hồi tố | chỉ áp cho chi phí sau khi kích hoạt | | Một số dịch vụ không hỗ trợ tag | phần chi phí đó không quy được | | Tối đa 50 tag mỗi tài nguyên | |

Và một cách phân tách mạnh hơn tag cho tổ chức lớn: mỗi phòng ban một TÀI KHOẢN AWS riêng trong AWS Organizations. Thanh toán hợp nhất tự động tách chi phí theo tài khoản, không phụ thuộc vào việc ai đó có nhớ gắn tag hay không — và nó còn cho cách ly bảo mật tốt hơn nhiều.

Đáp án

A — Dùng Amazon Kinesis Video Streams để nhận luồng trực tiếp từ camera. Dùng Amazon Rekognition để nhận diện nhân sự được phép. Đăng ký số điện thoại của đội bảo vệ làm subscriber của một SNS topic.

Vì sao đúng

Đề nêu ba bước, và mỗi dịch vụ trong đáp án phục vụ đúng một bước: | Bước | Dịch vụ | |---|---| | Nhận luồng video từ camera giám sát | Kinesis Video Streams | | Nhận diện người bằng AI | Amazon Rekognition | | Cảnh báo đội bảo vệ qua SMS | Amazon SNS |

Kinesis Video Streams là dịch vụ chuyên cho video:

Camera → Kinesis Video Streams
    → nhận, lập chỉ mục và lưu trữ luồng video
    → mã hoá khi truyền và khi lưu
    → phát lại theo thời gian được
    → tích hợp SẴN với Rekognition Video

Và Rekognition Video có tính năng nhận diện khuôn mặt theo thời gian thực:

Tạo một FACE COLLECTION chứa khuôn mặt nhân sự được phép
    ↓
Rekognition Stream Processor đọc từ Kinesis Video Streams
    ↓ so khuôn mặt phát hiện được với collection
    ├─ KHỚP     → nhân sự được phép, bỏ qua
    └─ KHÔNG khớp → người lạ → gửi kết quả ra Kinesis Data Streams
                    ↓ Lambda
                  SNS → SMS cho đội bảo vệ

aws rekognition create-stream-processor   --name giam-sat-khu-vuc-han-che   --input '{"KinesisVideoStream": {"Arn": "arn:aws:kinesisvideo:..."}}'   --output '{"KinesisDataStream": {"Arn": "arn:aws:kinesis:..."}}'   --settings '{"FaceSearch": {"CollectionId": "nhan-su-duoc-phep",
                              "FaceMatchThreshold": 90}}'

Và SNS hỗ trợ SMS trực tiếp — không cần dịch vụ trung gian nào.

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

• **B. Dùng Elastic Transcoder nhận luồng từ camera; dùng Amazon Kendra để nhận diện nhân sự — sai cả hai dịch vụ: Elastic Transcoder chuyển đổi định dạng tệp video (không nhận luồng trực tiếp); và Kendra là dịch vụ TÌM KIẾM DOANH NGHIỆP cho tài liệu văn bản, không phân tích hình ảnh.
• **D. Dùng Managed Service for Prometheus nhận luồng video; dùng Fraud Detector nhận diện người lạ — sai hoàn toàn: Prometheus là hệ thống giám sát metric hạ tầng; Fraud Detector phát hiện gian lận giao dịch bằng học máy trên dữ liệu giao dịch.
• **C. Thay camera bằng thiết bị AWS IoT, tải mô hình nhận diện khuôn mặt lên thiết bị và gửi sang AWS Control Tower để kiểm tra — hai lỗi: thay toàn bộ camera là thay đổi tốn kém và không cần thiết; và Control Tower quản trị môi trường nhiều tài khoản AWS, nó không xử lý dữ liệu hay gửi thông báo.

Ghi nhớ

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

Bốn dịch vụ trong họ Kinesis: | Dịch vụ | Dữ liệu | |---|---| | Kinesis Video Streams | VIDEO và âm thanh ← câu này | | Kinesis Data Streams | bản ghi dữ liệu, phát lại được | | Data Firehose | giao dữ liệu vào S3, Redshift, OpenSearch | | Managed Service for Apache Flink | xử lý luồng bằng SQL hoặc Flink |

Hai chế độ của Rekognition: | Chế độ | Đặc điểm | |---|---| | Image API | phân tích một ảnh tĩnh | | Video API | phân tích luồng thời gian thực hoặc video đã lưu |

Ba khả năng của Rekognition liên quan tới nhận diện người: | Khả năng | Việc | |---|---| | DetectFaces | phát hiện có khuôn mặt và thuộc tính (tuổi, cảm xúc) | | SearchFacesByImage | so khuôn mặt với một collection | | CompareFaces | so hai khuôn mặt với nhau | | Stream processor | nhận diện liên tục trên luồng video ← câu này |

FaceMatchThreshold là tham số quan trọng: đặt quá thấp gây báo động giả (nhận nhầm người lạ thành nhân viên), đặt quá cao gây bỏ sót. Giá trị 90–99 thường phù hợp cho kiểm soát ra vào.

Ba lưu ý về Kinesis Video Streams: | Lưu ý | Chi tiết | |---|---| | Thời gian lưu giữ cấu hình được | từ 1 giờ tới 10 năm | | Camera cần hỗ trợ producer SDK hoặc GStreamer | không phải camera nào cũng cắm vào là chạy | | Tính phí theo dữ liệu nạp vào và lưu trữ | video tốn dung lượng lớn |

Và một cân nhắc quan trọng về quyền riêng tư mà đề không nhắc tới: hệ thống nhận diện khuôn mặt chịu ràng buộc pháp lý ở nhiều nơi. Trước khi triển khai, cần xác định cơ sở pháp lý cho việc thu thập dữ liệu sinh trắc học, thông báo cho người bị giám sát, và có chính sách lưu trữ rõ ràng cho cả video lẫn face collection.

Ba biện pháp giảm chi phí cho hệ thống giám sát video: | Biện pháp | Lợi ích | |---|---| | Chỉ phân tích khi có chuyển động | không xử lý 24/7 | | Giảm độ phân giải cho luồng phân tích | Rekognition không cần 4K | | Đặt thời gian lưu giữ ngắn cho video thường | giữ lâu chỉ những đoạn có sự kiện |

Đáp án

B — Cấu hình Auto Scaling group trải trên ba Availability Zone. Dùng AWS DMS với replication server và ongoing replication task để di chuyển cơ sở dữ liệu NoSQL nhúng sang Amazon DynamoDB.

Vì sao đúng

Đề nêu ba yêu cầu, và B đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Cơ sở dữ liệu nhất quán cuối cùng (eventually consistent) | DynamoDB — mặc định là eventually consistent | | Sẵn sàng cao | DynamoDB tự sao chép trên nhiều AZ + ASG ba AZ | | Ít công vận hành nhất | DynamoDB được quản lý hoàn toàn |

Vấn đề gốc: cơ sở dữ liệu NHÚNG trong instance ứng dụng.

Kiến trúc hiện tại:
    Mỗi EC2 instance chứa một bản NoSQL nhúng
        → dữ liệu gắn với vòng đời instance
        → mở rộng ứng dụng = nhân bản cả cơ sở dữ liệu
        → tải cơ sở dữ liệu chính là nút thắt

Tách cơ sở dữ liệu ra khỏi tầng ứng dụng là thay đổi kiến trúc đúng:

Sau khi di chuyển:
    EC2 instance (chỉ chạy ứng dụng, KHÔNG trạng thái)
        ↓
    DynamoDB (dịch vụ được quản lý, tự mở rộng)
        → mở rộng ứng dụng không ảnh hưởng cơ sở dữ liệu
        → hai tầng co giãn độc lập

Và DynamoDB khớp chính xác hai đặc tính đề yêu cầu: | Đặc tính | DynamoDB | |---|---| | Eventually consistent | mặc định — đọc nhất quán cuối cùng, rẻ hơn một nửa | | Sẵn sàng cao | dữ liệu tự sao chép trên ba AZ, không cần cấu hình |

Và "least operational overhead" là điểm quyết định: DynamoDB không có máy chủ để vá, không có replica để cấu hình, không có chuyển đổi dự phòng để thiết kế.

DMS hỗ trợ DynamoDB làm đích và có ongoing replication (CDC) để đồng bộ liên tục trong lúc chuyển đổi — nên không phải dừng dịch vụ.

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

• **D. Cấu hình ASG trải trên ba AZ; sao chép cơ sở dữ liệu NoSQL giữa các EC2 instance để phân tán tải — đây là phương án gần nhất và có vế ASG đúng, nhưng nó giữ nguyên vấn đề gốc: bạn phải tự vận hành cụm NoSQL — cấu hình sao chép, xử lý chia tách mạng, giám sát, vá lỗi. Đó là công vận hành lớn nhất trong các phương án.
• **C. Đổi ALB thành NLB; dùng DMS di chuyển sang DynamoDB — có vế DynamoDB đúng nhưng vế load balancer sai: NLB không giải quyết vấn đề tải cơ sở dữ liệu. Và đổi từ ALB sang NLB làm mất các tính năng tầng 7 (path routing, WAF) mà ứng dụng web thường cần.
• **A. Đổi ALB thành NLB, tích hợp Global Accelerator; sao chép NoSQL giữa các EC2 instance — kết hợp mọi vấn đề: sai load balancer, thêm một dịch vụ không liên quan, và vẫn tự vận hành cơ sở dữ liệu.

Ghi nhớ

Nguyên tắc kiến trúc quan trọng nhất từ câu này:

Tách trạng thái ra khỏi tầng tính toán. Instance ứng dụng phải KHÔNG LƯU TRẠNG THÁI để mở rộng ngang được.

Hai mô hình nhất quán của DynamoDB: | Mô hình | Đặc điểm | Chi phí đọc | |---|---|---| | Eventually consistent | mặc định — có thể trả dữ liệu hơi cũ | 1 đơn vị | | Strongly consistent | luôn trả dữ liệu mới nhất | 2 đơn vị |

Đề nói rõ "eventually consistent" — nên mô hình mặc định của DynamoDB là đúng và rẻ hơn một nửa.

Ba đặc điểm sẵn sàng cao của DynamoDB: | Đặc điểm | Chi tiết | |---|---| | Tự sao chép trên ba AZ | không cần cấu hình gì | | Không có instance để chuyển đổi dự phòng | không có khái niệm downtime cho bảo trì | | Global Tables cho đa Region | tuỳ chọn thêm |

Ba khả năng của DMS liên quan: | Khả năng | Chi tiết | |---|---| | Hỗ trợ DynamoDB làm đích | từ nhiều loại nguồn | | Full load + CDC | sao chép ban đầu rồi đồng bộ liên tục | | Không đổi cơ sở dữ liệu nguồn | hệ thống cũ vẫn chạy suốt quá trình |

CDC là mảnh ghép cho phép chuyển đổi không gián đoạn: hai hệ thống chạy song song cho tới khi bạn sẵn sàng chuyển hẳn.

Ba lưu ý khi chuyển sang DynamoDB: | Lưu ý | Chi tiết | |---|---| | Thiết kế khoá theo MẪU TRUY CẬP | đổi khoá chính sau này đòi tạo bảng mới | | Partition key phải có độ phân biệt CAO | tránh hot partition và throttling | | Không có JOIN | phải phi chuẩn hoá hoặc dùng nhiều truy vấn |

Dòng cuối là công việc thật khi chuyển từ cơ sở dữ liệu quan hệ — nhưng ở đây nguồn đã là NoSQL, nên mô hình dữ liệu thường chuyển sang dễ dàng hơn.

Ba tính năng của DynamoDB nên cân nhắc bật: | Tính năng | Lợi ích | |---|---| | On-demand capacity | không phải dự báo dung lượng — hợp với tải tăng dần | | DAX | cache trong bộ nhớ, độ trễ microgiây cho item nóng | | Point-in-time recovery | khôi phục về bất kỳ giây nào trong 35 ngày |

Và với ASG trải ba AZ như đáp án nêu: nhớ đặt MinSize đủ để chịu được mất một AZ — với ba AZ, mất một AZ chỉ mất một phần ba dung lượng, nên yêu cầu dự phòng nhẹ hơn so với chỉ dùng hai AZ.