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

Đáp án

C và E.

• C — Dùng Route 53 geolocation routing policy để chỉ phân phối nội dung tới các vị trí có bản quyền
• E — Dùng georestriction để chặn người dùng ở khu vực địa lý cụ thể truy cập nội dung phân phối qua CloudFront

Vì sao đúng

Đề yêu cầu ràng buộc theo vị trí địa lý, và hai đáp án là hai cơ chế địa lý duy nhất trong danh sách.

E — CloudFront Geo Restriction là biện pháp CHẶN thật sự:

Bật danh sách cho phép chỉ gồm Hoa Kỳ
    → CloudFront kiểm tra IP người xem ở ĐIỂM BIÊN
    → không phải Hoa Kỳ → trả về 403 NGAY
    → nội dung KHÔNG rời khỏi CloudFront

aws cloudfront update-distribution --id E1ABC --distribution-config '{
  "Restrictions": {"GeoRestriction": {
    "RestrictionType": "whitelist",
    "Quantity": 1, "Items": ["US"]}}}'

C — Route 53 geolocation routing định tuyến theo vị trí:

Truy vấn DNS từ Hoa Kỳ  → trả IP của hệ thống phát trực tiếp
Truy vấn từ nơi khác     → trả IP của trang "không khả dụng ở khu vực này"

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes": [
    {"Action":"CREATE","ResourceRecordSet":{
      "Name":"xem.congty.com","Type":"A","SetIdentifier":"hoa-ky",
      "GeoLocation":{"CountryCode":"US"},
      "AliasTarget":{"HostedZoneId":"Z2FDTNDATAQYW2",
                     "DNSName":"d123.cloudfront.net","EvaluateTargetHealth":false}}},
    {"Action":"CREATE","ResourceRecordSet":{
      "Name":"xem.congty.com","Type":"A","SetIdentifier":"mac-dinh",
      "GeoLocation":{"ContinentCode":"*"},
      "AliasTarget":{"HostedZoneId":"Z2FDTNDATAQYW2",
                     "DNSName":"d456.cloudfront.net","EvaluateTargetHealth":false}}}]}'

Hai cơ chế này ở hai tầng khác nhau và bổ sung nhau: | Cơ chế | Tầng | Sức mạnh | |---|---|---| | Route 53 geolocation | DNS | định tuyến, vòng qua được nếu biết IP | | CloudFront geo restriction | HTTP, ở điểm biên | chặn thật, không vòng qua được bằng cách đổi DNS |

Luôn phải có bản ghi mặc định trong geolocation routing — nếu không, truy vấn từ vị trí không khớp sẽ không nhận được câu trả lời nào.

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

• **A. Dùng latency-based routing để giới hạn phân phối — đây là phương án gần nhất vì nó cũng là một routing policy dựa trên vị trí gián tiếp, nhưng nó định tuyến theo ĐỘ TRỄ, không theo biên giới: người dùng ở Canada có thể có độ trễ thấp nhất tới Region ở Hoa Kỳ và được gửi tới đó. Nó tối ưu hiệu năng, không thực thi bản quyền.
• **B. Dùng failover routing policy — sai mục đích hoàn toàn: failover chuyển lưu lượng sang endpoint dự phòng khi endpoint chính hỏng. Không liên quan tới vị trí địa lý.
• **D. Dùng weighted routing policy — chia lưu lượng theo TỶ LỆ, dùng cho thử nghiệm A/B và triển khai dần. Không có khái niệm vị trí.

Ghi nhớ

Bảy loại routing policy của Route 53 — bảng cần thuộc: | Policy | Định tuyến theo | |---|---| | Simple | một bản ghi, không điều kiện | | Weighted | tỷ lệ phần trăm — thử nghiệm A/B | | Latency-based | độ trễ mạng thấp nhất | | Failover | sức khoẻ endpoint — chính/dự phòng | | Geolocation | VỊ TRÍ NGƯỜI DÙNG (quốc gia, châu lục, bang của Mỹ) ← câu này | | Geoproximity | vị trí TÀI NGUYÊN + hệ số thiên vị (bias) | | Multivalue answer | tới 8 bản ghi khoẻ mạnh, ngẫu nhiên | | IP-based | theo khối CIDR của người dùng |

Geolocation và Geoproximity hay bị nhầm: | | Geolocation | Geoproximity | |---|---|---| | Dựa trên | vị trí NGƯỜI DÙNG | khoảng cách tới TÀI NGUYÊN | | Dùng cho | tuân thủ, bản quyền, ngôn ngữ | tối ưu độ trễ, cân bằng tải theo vùng | | Có bias | ❌ | ✅ mở rộng hoặc thu hẹp vùng phục vụ |

Ba mức chi tiết của geolocation: | Mức | Ví dụ | |---|---| | Châu lục | NA, EU, AS | | Quốc gia | US, VN, JP | | Bang của Hoa Kỳ | CA, NY, TX | | Mặc định (*) | BẮT BUỘC PHẢI CÓ |

Thiếu bản ghi mặc định là lỗi cấu hình phổ biến nhất — người dùng ở vị trí không khớp nhận NXDOMAIN và website "biến mất" với họ.

Ba cách chặn theo địa lý — theo sức mạnh: | Cách | Sức mạnh | |---|---| | CloudFront Geo Restriction | chặn ở điểm biên, mạnh | | AWS WAF GeoMatch | mạnh, linh hoạt hơn (kết hợp quy tắc khác) | | Route 53 geolocation | yếu — chỉ định tuyến DNS |

Vì sao Route 53 một mình không đủ:

Người dùng ở nước ngoài:
    → dùng DNS công cộng của Mỹ (8.8.8.8 với EDNS, hoặc VPN DNS)
    → nhận được IP của hệ thống phát
    → truy cập thẳng bằng IP đó
        ↓
    → Cần lớp chặn ở tầng ứng dụng

Đó là lý do câu hỏi yêu cầu HAI đáp án — chúng bổ sung nhau.

Ba lựa chọn của CloudFront Geo Restriction: | Lựa chọn | Chi tiết | |---|---| | Whitelist | chỉ các nước trong danh sách được vào ← phù hợp với đề | | Blacklist | chặn các nước trong danh sách | | None | không hạn chế |

Với "chỉ Hoa Kỳ", whitelist là lựa chọn đúng — blacklist đòi liệt kê gần 200 quốc gia.

Và WAF GeoMatch linh hoạt hơn Geo Restriction: | | CloudFront Geo Restriction | WAF GeoMatch | |---|---|---| | Chi phí | miễn phí | có phí | | Kết hợp với điều kiện khác | ❌ | ✅ (IP, đường dẫn, rate limit) | | Ngoại lệ theo đường dẫn | ❌ | ✅ | | Tuỳ chỉnh trang lỗi | qua custom error response | ✅ |

Ngoại lệ theo đường dẫn hữu ích cho trang thông báo:

Chặn /xem-truc-tiep/* cho mọi nước ngoài Mỹ
Cho phép /thong-bao và trang chủ với mọi người

Ba biện pháp bổ sung cho nội dung có bản quyền: | Biện pháp | Chi tiết | |---|---| | Signed URL hoặc signed cookie | chỉ người đã xác thực xem được | | DRM và mã hoá luồng | ngăn tải xuống và phát lại | | Watermark động | truy vết nguồn rò rỉ |

Signed URL là lớp quan trọng nhất về mặt hợp đồng:

Không có signed URL:
    Ai biết đường dẫn manifest HLS đều xem được
    → chia sẻ link là chia sẻ nội dung

Ba lưu ý về độ chính xác định vị: | Lưu ý | Chi tiết | |---|---| | VPN vòng qua được | không phải rào cản tuyệt đối | | Sai số với mạng di động và IP doanh nghiệp | | | Cần cơ chế xử lý khiếu nại | người dùng hợp lệ bị chặn nhầm |

Và một lời khuyên về hợp đồng phân phối: hãy ghi log mọi request bị chặn và giữ lại. Bên nắm bản quyền thường yêu cầu bằng chứng rằng biện pháp hạn chế đang hoạt động — và số lượng request bị chặn theo quốc gia theo thời gian chính là báo cáo họ cần.

Đáp án

D — Dùng SQS FIFO queue ở chế độ GOM LÔ 4 THÔNG ĐIỆP mỗi thao tác để xử lý ở tốc độ đỉnh.

Vì sao đúng

Đây là câu tính toán dựa trên hạn mức thông lượng của SQS FIFO.

Hạn mức cần nhớ:

SQS FIFO (chế độ tiêu chuẩn):
    → 300 THAO TÁC API mỗi giây cho mỗi loại thao tác
    → mỗi thao tác gửi được TỐI ĐA 10 thông điệp khi gom lô
        ↓
    Không gom lô: 300 × 1 = 300 thông điệp/giây
    Gom lô 10:    300 × 10 = 3.000 thông điệp/giây

Áp vào yêu cầu 1.000 thông điệp mỗi giây: | Cỡ lô | Thông lượng | Đủ 1.000/giây? | |---|---|---| | 1 (không gom) | 300 × 1 = 300 | ❌ | | 2 | 300 × 2 = 600 | ❌ | | 3 | 300 × 3 = 900 | ❌ | | 4 | 300 × 4 = 1.200 | ✅ |

Vậy cỡ lô nhỏ nhất đủ dùng là 4 — và đó là đáp án D.

Và vì sao phải là FIFO chứ không phải Standard:

Đề nêu: "It is important that the messages are processed IN ORDER"
    ↓
    SQS Standard: KHÔNG đảm bảo thứ tự
    SQS FIFO:     đảm bảo thứ tự trong mỗi message group

Ví dụ gửi theo lô:

sqs.send_message_batch(QueueUrl=url, Entries=[
    {'Id': '1', 'MessageBody': tin1, 'MessageGroupId': ma_tai_khoan,
     'MessageDeduplicationId': ma_giao_dich_1},
    {'Id': '2', 'MessageBody': tin2, 'MessageGroupId': ma_tai_khoan,
     'MessageDeduplicationId': ma_giao_dich_2},
    # ... tối đa 10 mục
])

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

• **C. FIFO queue với lô 2 thông điệp — đây là phương án gần nhất và cùng cách tiếp cận đúng, nhưng nó không đủ thông lượng: 300 × 2 = 600 thông điệp/giây, thiếu 400 so với yêu cầu 1.000.
• **A. FIFO queue không gom lô — chỉ đạt 300 thông điệp/giây, thiếu rất nhiều.
• **B. Dùng SQS Standard queue — thông lượng thì thừa sức (gần như không giới hạn), nhưng vi phạm yêu cầu về thứ tự: Standard không đảm bảo thứ tự xử lý.

Ghi nhớ

Hạn mức thông lượng của SQS — bảng cần thuộc: | Loại | Thông lượng | |---|---| | Standard | gần như KHÔNG GIỚI HẠN | | FIFO (tiêu chuẩn) | 300 thao tác/giây, 3.000 thông điệp/giây khi gom lô 10 | | FIFO high-throughput | tới 70.000 thông điệp/giây (tuỳ Region) |

Công thức: thông lượng = 300 × cỡ lô (tối đa 10).

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

Con số 300 là hạn mức của FIFO ở chế độ TIÊU CHUẨN, và nó không còn là trần duy nhất. Từ năm 2021, AWS có high-throughput mode cho FIFO queue:

aws sqs set-queue-attributes --queue-url <url> --attributes '{
  "DeduplicationScope": "messageGroup",
  "FifoThroughputLimit": "perMessageGroupId"}'

Với chế độ này, một FIFO queue dùng nhiều message group đạt tới 70.000 thông điệp/giây ở một số Region — dư sức cho 1.000/giây mà không cần gom lô.

Với ngân hàng xử lý giao dịch theo tài khoản, dùng mã tài khoản làm MessageGroupId là thiết kế tự nhiên: thứ tự được giữ trong từng tài khoản, và hàng nghìn tài khoản xử lý song song. Đó là kiến trúc nên chọn trong thực tế.

(Đáp án D vẫn đúng theo cách tính của bộ đề, dựa trên hạn mức tiêu chuẩn.)

Ba đảm bảo của SQS FIFO: | Đảm bảo | Cơ chế | |---|---| | Đúng thứ tự | MessageGroupId | | Đúng một lần | MessageDeduplicationId, cửa sổ 5 phút | | Không mất | lưu bền, xoá khi consumer xác nhận |

MessageGroupId là tham số quan trọng nhất về hiệu năng:

Một message group cho toàn hệ thống:
    → mọi thông điệp xử lý TUẦN TỰ, một cái một lúc
    → thông lượng thực tế rất thấp

Nhiều message group (theo mã tài khoản, mã khách hàng):
    → xử lý SONG SONG giữa các nhóm
    → thứ tự vẫn được giữ TRONG mỗi nhóm

Đây là quyết định thiết kế quan trọng nhất khi dùng FIFO.

SQS Standard và FIFO — bảng phân biệt: | | Standard | FIFO | |---|---|---| | Thứ tự | cố gắng, không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | không | | Thông lượng | không giới hạn | có hạn mức | | Tên hàng đợi | bất kỳ | phải kết thúc bằng .fifo | | Giá | rẻ hơn | đắt hơn ~25% |

Dòng "tên hàng đợi" là chi tiết dễ quên:

aws sqs create-queue --queue-name giao-dich-ngan-hang.fifo   --attributes '{"FifoQueue":"true","ContentBasedDeduplication":"true"}'

Ba cách gom lô trong SQS: | Thao tác | Tối đa | |---|---| | SendMessageBatch | 10 thông điệp | | ReceiveMessage | 10 thông điệp | | DeleteMessageBatch | 10 thông điệp |

Gom lô vừa tăng thông lượng vừa giảm chi phí — SQS tính phí theo số request, không theo số thông điệp.

Ba cấu hình quan trọng của SQS: | Cấu hình | Chi tiết | |---|---| | Visibility timeout | dài hơn thời gian xử lý | | Long polling (WaitTimeSeconds = 20) | giảm request rỗng và chi phí | | Dead-letter queue | thông điệp hỏng không kẹt mãi |

Long polling nên bật mặc định:

Short polling: liên tục hỏi, phần lớn trả về rỗng → tốn tiền
Long polling:  chờ tới 20 giây cho tới khi có thông điệp
    → ít request hơn, độ trễ thấp hơn, rẻ hơn

Ba lưu ý về ContentBasedDeduplication: | Lưu ý | Chi tiết | |---|---| | Bật thì SQS tự hash NỘI DUNG làm dedup id | tiện | | Nội dung giống hệt trong 5 phút bị bỏ | cẩn thận với giao dịch hợp lệ trùng nội dung | | Khai MessageDeduplicationId tường minh thì chặt hơn | dùng mã giao dịch nghiệp vụ |

Với giao dịch ngân hàng, hãy khai tường minh — hai lần chuyển 100.000 đồng cho cùng người trong 5 phút là hoàn toàn hợp lệ, và dedup theo nội dung sẽ âm thầm nuốt mất giao dịch thứ hai.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | Số thông điệp trong DLQ | phải là 0 |

Và một lời khuyên cho hệ thống ngân hàng: hãy kiểm chứng thông lượng thật bằng thử tải trước khi lên sản xuất. Con số 300 là hạn mức mặc định, nhưng thông lượng thực tế còn phụ thuộc vào phân bố message group — nếu 80% giao dịch thuộc về vài tài khoản lớn, những nhóm đó sẽ trở thành nút thắt bất kể cấu hình gom lô ra sao.

Đáp án

A — Nhà khoa học không phải trả bất kỳ khoản phí truyền dữ liệu nào cho lần tải ảnh này.

Vì sao đúng

Câu này kiểm tra một chính sách giá rất cụ thể của S3 Transfer Acceleration:

S3TA CHỈ tính phí khi việc truyền THỰC SỰ NHANH HƠN
    so với tải lên qua endpoint S3 thông thường
        ↓
    Không nhanh hơn → KHÔNG tính phí S3TA

Và phần còn lại của hoá đơn cũng bằng 0:

Truyền dữ liệu VÀO S3 (data transfer IN):
    → MIỄN PHÍ từ Internet, ở mọi Region
        ↓
    Không có phí S3TA + không có phí truyền vào = 0

Vì sao AWS thiết kế chính sách này:

S3TA không phải lúc nào cũng có lợi:
    → client gần Region đích thì không cải thiện gì
    → nghẽn ở đường truyền của chính bạn thì S3TA không nới được
        ↓
    Tính phí cho thứ không mang lại lợi ích là bất hợp lý
    → AWS đo và chỉ tính khi có cải thiện thật

Và có công cụ đo trước khi dùng:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
    en/accelerate-speed-comparsion.html

Nó so tốc độ tải lên có và không có S3TA từ đúng vị trí của bạn tới mọi Region.

Cách bật và dùng:

aws s3api put-bucket-accelerate-configuration   --bucket kho-anh-thien-van --accelerate-configuration Status=Enabled

aws s3 cp tinh-van.tif s3://kho-anh-thien-van/   --endpoint-url https://kho-anh-thien-van.s3-accelerate.amazonaws.com

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

• **B. Chỉ phải trả phí truyền dữ liệu của S3 — đây là phương án gần nhất và là bẫy chính: nhiều người quên rằng truyền dữ liệu VÀO AWS là miễn phí. Phí truyền dữ liệu của S3 áp cho chiều RA Internet, không phải chiều vào.
• **C. Phải trả cả phí S3 lẫn phí S3TA — sai cả hai vế.
• **D. Chỉ phải trả phí S3TA — sai vì S3TA không thu phí khi không nhanh hơn.

Ghi nhớ

Nguyên tắc giá truyền dữ liệu của AWS — bảng cần thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS từ Internet | MIỄN PHÍ | | RA Internet | ~0,09 USD/GB (có 100 GB miễn phí mỗi tháng) | | Giữa các Region | ~0,02 USD/GB | | Giữa các AZ trong Region | ~0,01 USD/GB mỗi chiều | | Trong cùng AZ, dùng IP riêng | miễn phí | | Từ CloudFront ra Internet | rẻ hơn từ S3 |

Nguyên tắc chung: AWS thu tiền dữ liệu ĐI RA, không thu dữ liệu ĐI VÀO.

Ba đặc điểm giá của S3 Transfer Acceleration: | Đặc điểm | Chi tiết | |---|---| | Chỉ tính khi thực sự nhanh hơn | ← câu này | | Giá theo GB, thay đổi theo điểm biên | ~0,04–0,08 USD/GB | | Cộng THÊM vào phí S3 thông thường | khi có tính |

Ba trường hợp S3TA KHÔNG mang lại lợi ích: | Trường hợp | Lý do | |---|---| | Client ở cùng Region với bucket | đã gần rồi | | Tệp rất nhỏ | chi phí thiết lập lấn át | | Nghẽn ở băng thông cuối cùng của bạn | S3TA không nới được đường truyền |

Trường hợp cuối đáng chú ý với tình huống trong đề: phòng thí nghiệm có thể có đường truyền chậm, và khi đó không kỹ thuật nào tăng tốc được.

Ba yêu cầu kỹ thuật của S3TA: | Yêu cầu | Chi tiết | |---|---| | Tên bucket KHÔNG chứa dấu chấm | ràng buộc của endpoint | | Tên bucket tuân thủ quy tắc DNS | | | Phải bật trên bucket trước | mất tới 20 phút để có hiệu lực |

Các khoản chi phí của S3 — bảng đầy đủ: | Khoản | Chi tiết | |---|---| | Lưu trữ | theo GB-tháng, khác nhau theo lớp | | Request | ~0,005 USD/1.000 PUT, ~0,0004 USD/1.000 GET | | Truyền RA Internet | ~0,09 USD/GB | | Truy xuất (lớp IA, Glacier) | theo GB | | Chuyển đổi lifecycle | theo số object | | Tính năng thêm | S3TA, replication, Storage Lens nâng cao |

Ba khoản hay gây bất ngờ trên hoá đơn: | Khoản | Vì sao bất ngờ | |---|---| | Phần multipart dở dang | không hiện trong danh sách nhưng vẫn tính tiền | | Phí truy xuất lớp IA | chuyển sang IA rồi đọc nhiều | | Phí request với hàng triệu tệp nhỏ | có thể vượt phí lưu trữ |

Ba cách giảm chi phí truyền dữ liệu: | Cách | Tiết kiệm | |---|---| | Dùng CloudFront cho nội dung ra Internet | rẻ hơn S3 trực tiếp | | VPC endpoint cho S3 | tránh phí NAT Gateway | | Giữ compute cùng Region với dữ liệu | tránh phí xuyên Region |

VPC endpoint cho S3 là tối ưu dễ bị bỏ qua:

Không có gateway endpoint:
    EC2 trong private subnet → NAT Gateway → S3
    → trả ~0,045 USD/GB phí xử lý của NAT

Có gateway endpoint (MIỄN PHÍ):
    EC2 → gateway endpoint → S3
    → không qua NAT, không phí xử lý

Gateway endpoint cho S3 và DynamoDB hoàn toàn miễn phí — nên tạo ở mọi VPC.

Ba công cụ theo dõi chi phí: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích theo dịch vụ, thẻ, thời gian | | S3 Storage Lens | phân bố dung lượng và request theo prefix | | AWS Budgets | cảnh báo khi vượt ngưỡng | | Cost Anomaly Detection | phát hiện tăng bất thường |

Ba lựa chọn cho tệp rất lớn: | Lựa chọn | Phù hợp | |---|---| | Multipart + S3TA | vài GB, có đường truyền tốt | | AWS DataSync | nhiều tệp, cần lịch và báo cáo | | Snowball Edge | hàng chục TB, băng thông kém |

Với dữ liệu thiên văn — thường là hàng trăm TB — Snow Family là lựa chọn nghiêm túc:

100 TB qua đường 1 Gbps: ~9 ngày liên tục (lý thuyết)
100 TB qua Snowball:     vài ngày, gồm cả vận chuyển
    → và không chiếm băng thông của phòng thí nghiệm

Và một lời khuyên: hãy chạy công cụ so sánh tốc độ trước khi bật S3TA cho một quy trình thường xuyên. Nó miễn phí và cho con số thật từ đúng vị trí của bạn — và nếu kết quả là "không nhanh hơn", bạn biết ngay rằng nút thắt nằm ở đường truyền chứ không ở AWS, và tiền nên đầu tư vào chỗ khác.

Đáp án

D — Lắp AWS Outposts rack trong trung tâm dữ liệu của công ty, chạy container cục bộ trên đó trong khi vẫn tích hợp với API của AWS.

Vì sao đúng

Đề nêu một mâu thuẫn tưởng chừng không giải được, và Outposts là dịch vụ sinh ra để giải nó:

Muốn: dịch vụ được quản lý của AWS, tự động nâng cấp Kubernetes,
       tích hợp CloudWatch, dùng IAM
Nhưng: MỌI dữ liệu và tải tính toán phải Ở LẠI trung tâm dữ liệu
    ↓
    → Không di chuyển gì lên đám mây
    → nhưng vẫn muốn trải nghiệm AWS
        ↓
    AWS Outposts: MANG HẠ TẦNG AWS VỀ TRUNG TÂM DỮ LIỆU CỦA BẠN

AWS Outposts là gì:

Tủ rack phần cứng do AWS thiết kế, lắp trong phòng máy của bạn
    ✓ AWS sở hữu, cài đặt, giám sát, bảo trì, vá lỗi
    ✓ chạy CÙNG hạ tầng và API như Region thật
    ✓ nối về Region cha qua đường mạng (service link)
    ✓ DỮ LIỆU nằm lại trên rack, trong toà nhà của bạn

Và Outposts hỗ trợ chạy các dịch vụ AWS cục bộ: | Dịch vụ | Trên Outposts | |---|---| | EC2, EBS | ✅ | | Amazon EKS (local cluster) | ✅ — control plane chạy TRÊN Outposts | | Amazon ECS | ✅ | | S3 on Outposts | ✅ | | RDS on Outposts | ✅ | | Application Load Balancer | ✅ |

EKS trên Outposts có hai chế độ: | Chế độ | Control plane | Chịu được mất kết nối | |---|---|---| | Extended cluster | ở Region | ❌ | | Local cluster | TRÊN Outposts | ✅ vẫn hoạt động khi đứt mạng |

Với ngân hàng, local cluster là lựa chọn đúng — cụm vẫn chạy khi đường về Region gặp sự cố.

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

• **A. Direct Connect tới Region, triển khai EKS trên đám mây và nối với cụm Kubernetes cục bộ — đây là phương án gần nhất vì nó cũng dựng kết nối lai, nhưng nó vi phạm ràng buộc cốt lõi: EKS chạy trong đám mây nghĩa là tải tính toán và dữ liệu rời khỏi trung tâm dữ liệu. Đề nói rõ mọi thứ phải ở lại tại chỗ.
• **C. Triển khai ECS Fargate trong AWS Local Zone, kết nối VPN, mount file share từ tại chỗ — Local Zone vẫn là hạ tầng AWS ở BÊN NGOÀI toà nhà của bạn. Dữ liệu được xử lý ở đó là đã rời khỏi trung tâm dữ liệu.
• **B. Dùng Snowball Edge Compute Optimized chạy container tại chỗ, xuất log định kỳ ra S3 — sai mục đích thiết bị: Snowball Edge dùng cho di chuyển dữ liệu và tính toán ở biên tạm thời (tàu biển, giàn khoan, hiện trường). Nó không phải nền tảng chạy hệ thống sản xuất lâu dài, và không có EKS được quản lý.

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

Cách diễn đạt của đáp án có một điểm không chính xác: "Amazon EKS Anywhere trên Outposts".

Đây là hai sản phẩm khác nhau: | Sản phẩm | Chạy ở đâu | Ai vận hành | |---|---|---| | EKS on Outposts | trên rack Outposts | AWS quản lý phần cứng, tích hợp API AWS | | EKS Anywhere | phần cứng CỦA BẠN (VMware, bare metal) | BẠN vận hành, không tích hợp sẵn IAM/CloudWatch |

Dịch vụ đúng cho tình huống trong đề là Amazon EKS on Outposts (local cluster) — nó cho đúng những gì đề yêu cầu: nâng cấp Kubernetes tự động, tích hợp CloudWatch, dùng IAM. EKS Anywhere thì không có tích hợp IAM và CloudWatch dựng sẵn, và bạn phải tự nâng cấp.

Dù vậy, D vẫn là đáp án đúng vì nó là lựa chọn duy nhất giữ được cả dữ liệu lẫn tải tính toán trong trung tâm dữ liệu mà vẫn dùng hạ tầng do AWS quản lý. Ba phương án còn lại đều vi phạm ràng buộc đó.

Ghi nhớ

Bốn lựa chọn hạ tầng lai của AWS — bảng cần thuộc: | Lựa chọn | Vị trí | Phù hợp | |---|---|---| | Outposts | trung tâm dữ liệu CỦA BẠN | dữ liệu bắt buộc ở tại chỗ, độ trễ rất thấp ← câu này | | Local Zones | thành phố lớn, gần người dùng | độ trễ một chữ số mili giây | | Wavelength | trong mạng 5G của nhà mạng | ứng dụng di động độ trễ cực thấp | | Snow Family | thiết bị di động | di chuyển dữ liệu, tính toán ở hiện trường | | EKS/ECS Anywhere | phần cứng của bạn | dùng công cụ AWS trên hạ tầng tự quản |

Từ khoá nhận diện:

"data must remain on premises", "regulatory", "in our data center" → Outposts "single-digit millisecond to end users in a metro" → Local Zones "5G", "mobile edge" → Wavelength "ship data", "disconnected environment", "temporary" → Snow Family

Hai dạng của Outposts: | Dạng | Kích thước | |---|---| | Outposts rack | 42U — cho khối lượng lớn ← câu này | | Outposts server | 1U hoặc 2U — cho chi nhánh, cửa hàng |

Ba yêu cầu để lắp Outposts: | Yêu cầu | Chi tiết | |---|---| | Không gian, điện, làm mát đạt chuẩn | AWS khảo sát trước | | Kết nối mạng ổn định về Region cha | service link — cho quản lý và giám sát | | Cam kết 3 năm | trả trước một phần hoặc trả theo tháng |

Service link là chi tiết quan trọng:

Outposts CẦN kết nối về Region để:
    ✓ nhận cập nhật và bản vá
    ✓ gửi metric và log
    ✓ đồng bộ control plane (với extended cluster)

Mất kết nối:
    → EC2 và EBS đang chạy VẪN hoạt động
    → nhưng KHÔNG tạo mới hay thay đổi được
    → EKS local cluster vẫn điều phối được pod

Ba lợi ích của Outposts với ngành tài chính: | Lợi ích | Chi tiết | |---|---| | Dữ liệu không rời cơ sở | đáp ứng quy định về vị trí dữ liệu | | Độ trễ rất thấp tới hệ thống cũ | mainframe, hệ thống giao dịch | | Cùng API và công cụ như đám mây | một bộ kỹ năng, một bộ mã |

Điểm cuối là giá trị lớn nhất: cùng kubectl, cùng CloudFormation, cùng IAM policy — đội ngũ không phải học hai hệ thống.

Ba hạn chế của Outposts: | Hạn chế | Chi tiết | |---|---| | Năng lực CỐ ĐỊNH | không co giãn vô hạn như đám mây | | Không phải mọi dịch vụ AWS đều có | danh sách hạn chế | | Chi phí cam kết dài hạn | không phải trả theo dùng thuần tuý |

Dòng đầu là thay đổi tư duy quan trọng: trên Outposts, hết năng lực là hết — phải lên kế hoạch dung lượng như với hạ tầng truyền thống.

Ba mẫu kiến trúc lai với Outposts: | Mẫu | Chi tiết | |---|---| | Xử lý cục bộ, phân tích trên đám mây | dữ liệu thô ở lại, số liệu tổng hợp gửi lên | | Tràn năng lực lên đám mây (bursting) | phần không nhạy cảm chạy ở Region | | Khôi phục thảm hoạ | Outposts chính, Region dự phòng |

Mẫu đầu tiên rất phù hợp với ngân hàng: dữ liệu giao dịch xử lý tại chỗ, còn báo cáo tổng hợp đã ẩn danh thì phân tích trên đám mây.

Ba lựa chọn Kubernetes cho môi trường tại chỗ: | Lựa chọn | Phần cứng | Ai quản lý | |---|---|---| | EKS on Outposts | của AWS, đặt tại chỗ | AWS ← câu này | | EKS Anywhere | của bạn | bạn (có hỗ trợ trả phí) | | Kubernetes tự cài | của bạn | bạn hoàn toàn |

Và một lời khuyên về lập kế hoạch: hãy tính dung lượng Outposts với dự phòng đáng kể cho tăng trưởng ba năm. Mở rộng Outposts đòi đặt hàng thêm rack và chờ lắp đặt — không phải một lời gọi API như trong đám mây, và với hệ thống ngân hàng thì thiếu năng lực là sự cố chứ không phải bất tiện.

Đáp án

C và D — hai chuyển đổi lifecycle KHÔNG HỢP LỆ.

• C — S3 One Zone-IA ⇒ S3 Standard-IA
• D — S3 Intelligent-Tiering ⇒ S3 Standard

Vì sao đúng

Lifecycle transition của S3 chỉ đi theo MỘT CHIỀU: xuống dưới thác nước, không bao giờ đi ngược lên.

Thứ tự thác nước — nội dung cốt lõi của câu hỏi:

S3 Standard
    ↓
S3 Intelligent-Tiering
    ↓
S3 Standard-IA
    ↓
S3 One Zone-IA
    ↓
S3 Glacier Instant Retrieval
    ↓
S3 Glacier Flexible Retrieval
    ↓
S3 Glacier Deep Archive

Lifecycle chỉ chuyển được TỪ TRÊN XUỐNG DƯỚI.

Áp vào từng phương án: | Chuyển đổi | Hướng | Hợp lệ | |---|---|---| | A. Standard ⇒ Intelligent-Tiering | xuống | ✅ | | B. Standard-IA ⇒ One Zone-IA | xuống | ✅ | | C. One Zone-IA ⇒ Standard-IA | NGƯỢC LÊN | ❌ | | D. Intelligent-Tiering ⇒ Standard | NGƯỢC LÊN | ❌ | | E. Standard-IA ⇒ Intelligent-Tiering | ⚠ xem ghi chú | ✅ |

Vì sao chỉ đi một chiều:

Lifecycle được thiết kế cho vòng đời dữ liệu TỰ NHIÊN:
    dữ liệu mới → truy cập nhiều → truy cập ít dần → lưu trữ lâu dài
        ↓
    Đi ngược lên nghĩa là "dữ liệu đang nóng trở lại"
    → đó là quyết định theo NGỮ CẢNH, không theo TUỔI
    → lifecycle chỉ biết tuổi, không biết mẫu truy cập

Muốn đưa dữ liệu ngược lên lớp nóng hơn thì phải SAO CHÉP:

aws s3 cp s3://kho/tep.dat s3://kho/tep.dat   --storage-class STANDARD --metadata-directive COPY

Đây là thao tác thủ công, không phải lifecycle rule.

(Lưu ý về E: Standard-IA ⇒ Intelligent-Tiering được AWS cho phép — nó là ngoại lệ so với quy tắc thác nước thuần tuý, và câu hỏi cũng không liệt kê nó vào nhóm không hợp lệ.)

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

• **B. Standard-IA ⇒ One Zone-IA — đây là phương án gần nhất vì trông giống một chuyển đổi kỳ lạ (từ ba AZ xuống một AZ), nhưng nó hoàn toàn hợp lệ: One Zone-IA nằm dưới Standard-IA trong thác nước và rẻ hơn khoảng 20%.
• **A. Standard ⇒ Intelligent-Tiering — hợp lệ, và là chuyển đổi rất phổ biến.
• **E. Standard-IA ⇒ Intelligent-Tiering — hợp lệ theo tài liệu của AWS.

Ghi nhớ

Sơ đồ thác nước lifecycle — nội dung phải thuộc:

Standard ──┬─▶ Intelligent-Tiering ──┐
           ├─▶ Standard-IA ──────────┤
           ├─▶ One Zone-IA ──────────┤
           ├─▶ Glacier IR ───────────┤
           ├─▶ Glacier Flexible ─────┤
           └─▶ Deep Archive ◀────────┘

    Mọi mũi tên đi XUỐNG. KHÔNG có mũi tên đi lên.

Ba chuyển đổi KHÔNG hợp lệ hay bị hỏi: | Không hợp lệ | Lý do | |---|---| | Bất kỳ lớp nào ⇒ Standard | đi ngược lên | | One Zone-IA ⇒ Standard-IA | đi ngược lên | | Glacier ⇒ bất kỳ lớp IA nào | đi ngược lên |

Và ràng buộc thời gian của chuyển đổi: | Chuyển sang | Ràng buộc | |---|---| | Standard-IA hoặc One Zone-IA | object phải ở Standard ÍT NHẤT 30 NGÀY | | Glacier (mọi loại) | KHÔNG có ràng buộc — Days: 0 hợp lệ | | Intelligent-Tiering | không có ràng buộc |

Đây là hai loại ràng buộc khác nhau — phân biệt rõ:

Ràng buộc CHUYỂN ĐỔI:  bao lâu ở Standard trước khi chuyển
Ràng buộc LƯU TỐI THIỂU: xoá trước hạn vẫn bị tính đủ phí

Bảng thời gian lưu tối thiểu: | Lớp | Lưu tối thiểu | |---|---| | Standard, Intelligent-Tiering | không có | | Standard-IA, One Zone-IA | 30 ngày | | Glacier IR, Glacier Flexible | 90 ngày | | Deep Archive | 180 ngày |

Ví dụ lifecycle rule hoàn chỉnh:

{"Rules": [{
  "ID": "vong-doi-tai-lieu",
  "Status": "Enabled",
  "Filter": {"Prefix": "tai-lieu/", "ObjectSizeGreaterThan": 131072},
  "Transitions": [
    {"Days": 30,   "StorageClass": "STANDARD_IA"},
    {"Days": 90,   "StorageClass": "GLACIER_IR"},
    {"Days": 365,  "StorageClass": "DEEP_ARCHIVE"}],
  "Expiration": {"Days": 2555},
  "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Bốn loại thao tác trong lifecycle rule: | Thao tác | Việc | |---|---| | Transitions | chuyển lớp lưu trữ | | Expiration | xoá object hiện hành | | NoncurrentVersion* | quản lý phiên bản cũ | | AbortIncompleteMultipartUpload | dọn phần tải lên dở dang |

Dòng cuối nên có ở MỌI bucket — phần dở dang không hiện trong danh sách nhưng vẫn tính tiền vô thời hạn.

Ba bộ lọc của lifecycle rule: | Bộ lọc | Chi tiết | |---|---| | Prefix | theo tiền tố khoá | | Tags | theo thẻ của object — linh hoạt nhất | | ObjectSizeGreaterThan/LessThan | tránh chuyển tệp nhỏ hơn 128 KB |

Lọc theo kích thước rất đáng dùng:

Lớp IA tính phí tối thiểu 128 KB mỗi object
    → chuyển tệp 10 KB sang IA là TĂNG chi phí
    → và còn tốn phí chuyển đổi mỗi object

Intelligent-Tiering là lựa chọn thay thế cho lifecycle: | | Lifecycle rule | Intelligent-Tiering | |---|---|---| | Quyết định theo | TUỔI | MẪU TRUY CẬP thật | | Phí truy xuất | có (lớp IA) | KHÔNG | | Đi ngược lên tầng nóng | ❌ | ✅ TỰ ĐỘNG | | Phí giám sát | không | nhỏ, theo object |

Điểm thứ ba là lợi thế quyết định: Intelligent-Tiering tự đưa dữ liệu trở lại tầng nóng khi có truy cập — thứ mà lifecycle rule về nguyên tắc không làm được.

Năm tầng của Intelligent-Tiering: | Tầng | Sau bao lâu không truy cập | |---|---| | Frequent Access | mặc định | | Infrequent Access | 30 ngày | | Archive Instant Access | 90 ngày | | Archive Access (tuỳ chọn) | 90–730 ngày | | Deep Archive Access (tuỳ chọn) | 180–730 ngày |

Ba tầng đầu là TỰ ĐỘNG và truy xuất tức thì — hai tầng cuối phải bật thủ công và cần restore.

Ba lưu ý khi triển khai lifecycle: | Lưu ý | Chi tiết | |---|---| | Chạy MỘT LẦN mỗi ngày | không chính xác theo giờ | | Kiểm chứng bằng S3 Inventory | xem object thực sự ở lớp nào | | Đo mẫu truy cập trước bằng Storage Class Analysis | tránh chọn sai số ngày |

Và một lời khuyên: hãy dùng S3 Storage Class Analysis vài tháng trước khi chốt các mốc thời gian. Nó cho biết dữ liệu thực sự ngừng được truy cập sau bao lâu — và nếu bạn chuyển sang IA ở ngày 30 trong khi dữ liệu vẫn được đọc tới ngày 60, phí truy xuất sẽ ăn hết phần tiết kiệm được.

Đáp án

B — Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu một từ khoá quyết định: Microsoft Distributed File System (DFS).

DFS là công nghệ của MICROSOFT WINDOWS
    → DFS Namespaces: gộp nhiều máy chủ tệp thành một không gian tên chung
    → DFS Replication: sao chép dữ liệu giữa các máy chủ
        ↓
    Chỉ dịch vụ dựa trên Windows Server mới hỗ trợ được

Và FSx for Windows File Server là Windows Server thật:

FSx for Windows chạy Windows Server nguyên bản
    ✓ hỗ trợ DFS Namespaces và DFS Replication
    ✓ giao thức SMB
    ✓ tích hợp Active Directory
    ✓ ACL của NTFS, shadow copy, quota người dùng

Ba khả năng DFS mà FSx hỗ trợ: | Khả năng | Chi tiết | |---|---| | DFS Namespaces | gộp nhiều file system thành một không gian tên duy nhất | | DFS Replication | sao chép giữa hai FSx, hoặc giữa FSx và máy chủ tại chỗ | | Mở rộng vượt giới hạn một file system | dùng namespace để ghép nhiều FSx |

Và đây chính là cách hỗ trợ hàng trăm petabyte:

Một FSx file system có giới hạn dung lượng
    → dùng DFS Namespaces ghép nhiều file system
    → người dùng thấy MỘT không gian tên thống nhất
    → mở rộng gần như không giới hạn

Về vế "hybrid" và "phân tích dữ liệu":

Kết nối tại chỗ ⟷ AWS qua Direct Connect hoặc VPN
    → DFS Replication đồng bộ dữ liệu hai chiều
    → tải phân tích chạy trên EC2 truy cập FSx qua SMB
    → chuyển đổi DẦN DẦN, không phải cắt một lần

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

• **C. Amazon FSx for Lustre — đây là phương án gần nhất vì cũng thuộc họ FSx và cũng cho phân tích hiệu năng cao, nhưng nó không hỗ trợ DFS: Lustre là hệ thống tệp song song cho Linux và HPC, dùng giao thức Lustre chứ không phải SMB. Nó không hiểu gì về DFS Namespaces hay Active Directory.
• **D. AWS Managed Microsoft AD — sai tầng dịch vụ: đây là dịch vụ thư mục danh tính, không phải lưu trữ tệp. Nó là thành phần đi kèm (FSx for Windows cần AD để xác thực), nhưng bản thân nó không lưu dữ liệu nào.
• **A. Microsoft SQL Server trên AWS — sai loại hệ thống hoàn toàn: SQL Server là database quan hệ, không phải hệ thống tệp phân tán.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — bảng cần thuộc: | Dịch vụ | Giao thức | Đặc trưng | |---|---|---| | FSx for Windows File Server | SMB | DFS, Active Directory, ACL của NTFS ← câu này | | FSx for Lustre | Lustre (POSIX) | HPC, học máy, tích hợp S3 | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, snapshot, cloning, tiering | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

Từ khoá nhận diện:

"Windows", "SMB", "Active Directory", "DFS", "NTFS" → FSx for Windows "HPC", "parallel", "machine learning", "genomics" → FSx for Lustre "multi-protocol", "NetApp", "SnapMirror", "dedup" → FSx for ONTAP "simple Linux NFS, auto-scaling" → Amazon EFS

Ba tính năng riêng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Tích hợp Active Directory | AWS Managed AD hoặc AD tại chỗ tự quản | | Shadow Copy (Previous Versions) | người dùng tự khôi phục tệp đã xoá | | User quota | giới hạn dung lượng theo người dùng | | Data deduplication | tiết kiệm 50–60% cho dữ liệu văn phòng |

Data deduplication rất đáng bật:

Enable-FSxDedup -FileSystemId fs-0abc123

Với hàng trăm petabyte dữ liệu doanh nghiệp, tỷ lệ trùng lặp thường rất cao.

Hai kiểu triển khai của FSx for Windows: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, không chịu được mất AZ | | Multi-AZ | standby ở AZ khác, tự chuyển đổi — cho sản xuất |

Ba lựa chọn lưu trữ: | Loại | Phù hợp | |---|---| | SSD | chia sẻ tệp thông thường, cơ sở dữ liệu | | HDD | dữ liệu lạnh, dung lượng lớn, rẻ hơn | | SSD cache cho HDD | cân bằng |

Ba cách di chuyển dữ liệu tại chỗ lên FSx: | Cách | Phù hợp | |---|---| | AWS DataSync | nhanh, giữ ACL và metadata của NTFS | | DFS Replication | đồng bộ liên tục hai chiều ← phù hợp với mô hình lai | | Robocopy | thủ công, cho khối lượng nhỏ |

DataSync giữ được ACL là chi tiết quan trọng:

Sao chép bằng công cụ thường:
    → mất ACL của NTFS
    → mọi quyền truy cập phải cấu hình lại từ đầu

DataSync:
    → giữ nguyên ACL, timestamp, chủ sở hữu

Và với hàng trăm petabyte, Snow Family là bắt buộc cho lần chuyển đầu:

100 PB qua đường 10 Gbps: khoảng 2,5 năm liên tục
    → Snowball hoặc Snowmobile cho khối lượng ban đầu
    → DataSync hoặc DFS Replication cho phần tăng thêm

Ba yêu cầu để triển khai FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD, hoặc AD tại chỗ tự quản | | Subnet trong VPC | hai subnet nếu Multi-AZ | | Security group mở cổng SMB (445) và các cổng AD | |

Và tích hợp với AD tại chỗ là lựa chọn thường dùng cho mô hình lai:

FSx tham gia CHÍNH domain AD tại chỗ
    → người dùng đăng nhập bằng tài khoản quen thuộc
    → ACL hiện có áp dụng nguyên vẹn
    → cần đường mạng tới domain controller

Ba dịch vụ liên quan cho tải phân tích: | Dịch vụ | Việc | |---|---| | EC2 Windows | truy cập FSx qua SMB, chạy công cụ phân tích | | Amazon EMR | phân tích quy mô lớn (thường đọc từ S3) | | FSx File Gateway | truy cập FSx từ tại chỗ với cache cục bộ |

FSx File Gateway đáng biết cho mô hình lai:

Người dùng tại chỗ truy cập FSx trên AWS
    → gateway cache dữ liệu nóng ở địa phương
    → độ trễ như file server nội bộ

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Dung lượng CẤP PHÁT | không phải dung lượng dùng thật | | Thông lượng cấp phát | khai riêng, ảnh hưởng giá đáng kể | | Backup | tính theo dung lượng backup |

Và một lời khuyên cho tổ chức tài chính: hãy bật Shadow Copy và đặt lịch chụp thường xuyên. Nó cho phép người dùng tự khôi phục tệp bị xoá hoặc sửa nhầm mà không cần mở phiếu hỗ trợ — và với hàng nghìn người dùng, đó là khoản giảm tải rất lớn cho đội vận hành.

Đáp án

C — Path-based Routing (định tuyến theo đường dẫn).

Vì sao đúng

Đề mô tả chính xác định nghĩa của path-based routing: định tuyến theo phần ĐƯỜNG DẪN của URL.

https://www.example.com/orders    → dịch vụ đơn hàng
https://www.example.com/products  → dịch vụ sản phẩm
        ↑
    Cùng HOST, khác PATH
    → phân biệt bằng path-based routing

Cấu hình bằng listener rule của ALB:

aws elbv2 create-rule --listener-arn <arn-listener> --priority 10   --conditions '[{"Field":"path-pattern","Values":["/orders","/orders/*"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<arn-tg-don-hang>"}]'

aws elbv2 create-rule --listener-arn <arn-listener> --priority 20   --conditions '[{"Field":"path-pattern","Values":["/products","/products/*"]}]'   --actions '[{"Type":"forward","TargetGroupArn":"<arn-tg-san-pham>"}]'

Kiến trúc kết quả:

                    Application Load Balancer
                            │
        ┌───────────────────┼───────────────────┐
        │ /orders/*         │ /products/*       │ mặc định
        ▼                   ▼                   ▼
   Target group        Target group        Target group
   đơn hàng            sản phẩm            giao diện

Và đây là mẫu chuẩn cho kiến trúc microservice:

Một tên miền duy nhất cho người dùng
    → một chứng chỉ TLS
    → một điểm vào để giám sát và bảo vệ
        ↓
    Nhưng phía sau là nhiều dịch vụ độc lập
    → mỗi dịch vụ triển khai và co giãn riêng

Lưu ý về path-pattern: phải khai cả hai mẫu /orders và /orders/* — mẫu có dấu sao không khớp chính đường dẫn gốc không có dấu gạch chéo cuối.

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

• **D. Host-based Routing — đây là phương án gần nhất và cũng là một khả năng định tuyến nội dung của ALB, nhưng nó phân biệt theo TÊN MIỀN, không phải đường dẫn: nó dùng cho orders.example.com và products.example.com. Trong đề, cả hai URL có cùng host www.example.com.
• **A. HTTP header-based routing — định tuyến theo giá trị header tuỳ chỉnh (ví dụ X-Phien-Ban: v2). Có tồn tại, nhưng không phải cơ chế cho đường dẫn.
• **B. Query string parameter-based routing — định tuyến theo tham số sau dấu ? (ví dụ ?loai=don-hang). Cũng có tồn tại, nhưng đề nêu rõ khác biệt nằm ở đường dẫn.

Ghi nhớ

Bảy điều kiện định tuyến của ALB — bảng cần thuộc: | Điều kiện | Khớp theo | |---|---| | path-pattern | đường dẫn URL ← câu này | | host-header | tên miền | | http-header | header tuỳ ý | | query-string | tham số truy vấn | | http-request-method | GET, POST... | | source-ip | IP nguồn (CIDR) | | Kết hợp nhiều điều kiện | tối đa 5 điều kiện mỗi rule |

Ba khả năng chỉ ALB có (NLB không có): | Khả năng | Chi tiết | |---|---| | Định tuyến theo nội dung | ← nhóm điều kiện ở trên | | Xác thực dựng sẵn | Cognito hoặc OIDC ngay tại load balancer | | Sticky session theo cookie ứng dụng | |

ALB, NLB và GWLB — bảng phân biệt: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng OSI | 7 (HTTP) | 4 (TCP/UDP) | 3 (IP) | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | Giao thức | HTTP, HTTPS, gRPC | TCP, UDP, TLS | mọi giao thức IP | | IP tĩnh | ❌ | ✅ mỗi AZ một IP | — | | Hiệu năng | rất tốt | hàng triệu request/giây, độ trễ cực thấp | — | | WAF | ✅ | ❌ | ❌ | | Dùng cho | web, microservice | game, IoT, độ trễ thấp | thiết bị bảo mật |

Ba hành động của listener rule: | Hành động | Việc | |---|---| | forward | chuyển tới target group (chia trọng số được) | | redirect | chuyển hướng HTTP → HTTPS, hoặc đổi đường dẫn | | fixed-response | trả về nội dung cố định, không cần backend | | authenticate-cognito / authenticate-oidc | xác thực tại ALB |

Chuyển hướng sang HTTPS là cấu hình nên có:

aws elbv2 create-rule --listener-arn <arn-listener-80> --priority 1   --conditions '[{"Field":"path-pattern","Values":["/*"]}]'   --actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Và forward với trọng số cho phép triển khai xanh–lam:

{"Type": "forward", "ForwardConfig": {"TargetGroups": [
   {"TargetGroupArn": "<tg-cu>",  "Weight": 90},
   {"TargetGroupArn": "<tg-moi>", "Weight": 10}]}}

Đây là cách chuyển dần lưu lượng sang phiên bản mới mà không cần công cụ ngoài.

Ba lưu ý về priority của rule: | Lưu ý | Chi tiết | |---|---| | Số NHỎ hơn được xét TRƯỚC | | | Rule đầu tiên khớp sẽ thắng | không xét tiếp | | Default action là fallback | khi không rule nào khớp |

Đặt rule cụ thể trước rule chung:

Priority 10: /orders/express/*  → dịch vụ giao nhanh
Priority 20: /orders/*          → dịch vụ đơn hàng
    → nếu đảo ngược, rule /orders/* nuốt hết

Ba loại target của ALB: | Loại | Chi tiết | |---|---| | instance | EC2 instance | | ip | địa chỉ IP — dùng cho container, máy tại chỗ | | lambda | gọi thẳng Lambda function |

Target type lambda cho phép kiến trúc lai:

/orders/*   → target group EC2
/api/bao-cao → target group Lambda
    → serverless và EC2 sau cùng một ALB

Ba cấu hình health check quan trọng: | Cấu hình | Chi tiết | |---|---| | Đường dẫn riêng cho mỗi target group | /orders/health, /products/health | | Kiểm tra ĐƯỜNG ĐI THẬT | không chỉ trả 200 tĩnh | | Interval và threshold hợp lý | không quá nhạy, không quá chậm |

Và mỗi microservice nên có health check riêng — dịch vụ đơn hàng hỏng thì chỉ target group của nó bị đánh dấu, dịch vụ sản phẩm vẫn phục vụ bình thường.

Ba lựa chọn khác cho định tuyến microservice: | Lựa chọn | Đặc điểm | |---|---| | ALB path-based routing | đơn giản nhất, ít công nhất ← câu này | | API Gateway | thêm throttling, usage plan, xác thực, caching | | Service mesh (App Mesh) | định tuyến giữa các dịch vụ nội bộ |

Và một lời khuyên: hãy bật access log của ALB ra S3. Với kiến trúc nhiều đường dẫn, khi có ai đó báo "trang đơn hàng lỗi", log cho biết ngay request đã tới target group nào và nhận mã trạng thái gì — thông tin đó thu hẹp phạm vi chẩn đoán từ cả hệ thống xuống một dịch vụ.

Đáp án

D — Triển khai EC2 instance trong cluster placement group để tải công việc hưởng lợi từ độ trễ mạng thấp và thông lượng mạng cao.

Vì sao đúng

Đề nêu từ khoá quyết định: High Performance Computing (HPC).

Ứng dụng HPC:
    → nhiều node tính toán TRAO ĐỔI DỮ LIỆU LIÊN TỤC với nhau
    → thường dùng MPI (Message Passing Interface)
    → mỗi bước tính toán cần đồng bộ giữa mọi node
        ↓
    ĐỘ TRỄ MẠNG giữa các node là yếu tố quyết định hiệu năng

Và cluster placement group tối ưu đúng điều đó:

Cluster placement group:
    → đặt instance RẤT GẦN NHAU về mặt vật lý
    → cùng một rack hoặc các rack liền kề trong MỘT AZ
        ↓
    ✓ độ trễ mạng THẤP NHẤT (dưới 50 micro giây)
    ✓ băng thông tới 100 Gbps giữa các instance
    ✓ tỷ lệ mất gói gần như bằng 0

Ba loại placement group — mỗi loại tối ưu một thứ khác nhau: | Loại | Tối ưu cho | Cách đặt máy | |---|---|---| | Cluster | HIỆU NĂNG MẠNG | rất gần nhau, MỘT AZ ← câu này | | Spread | KHẢ NĂNG CHỊU LỖI | mỗi máy một phần cứng riêng, nhiều AZ | | Partition | cân bằng cả hai | nhóm phân vùng độc lập về phần cứng |

Và đánh đổi của cluster placement group phải được chấp nhận:

Mọi instance ở MỘT AZ
    → AZ hỏng = mất toàn bộ cụm
        ↓
    Với HPC chạy theo đợt, đó là đánh đổi hợp lý:
    → chạy lại đợt tính toán, không mất dữ liệu bền vững

aws ec2 create-placement-group --group-name cum-hpc --strategy cluster

aws ec2 run-instances --image-id ami-0abc --instance-type c6in.32xlarge   --count 16 --placement GroupName=cum-hpc   --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa","SubnetId":"subnet-a"}]'

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

• **B. Triển khai trong spread placement group để không có lỗi tương quan — đây là phương án gần nhất và spread thực sự là một placement group hợp lệ, nhưng nó tối ưu ngược lại: nó trải máy ra XA NHAU trên phần cứng khác biệt để giảm rủi ro hỏng cùng lúc. Điều đó tăng độ trễ mạng — đúng thứ mà HPC không chịu được.
• **C. Partition placement group cho tải phân tán — cũng là loại có thật, nhưng nó dành cho hệ thống phân tán lớn nhận biết topology (HDFS, Cassandra, Kafka), nơi mục tiêu là giới hạn phạm vi ảnh hưởng khi một phân vùng phần cứng hỏng. Không tối ưu độ trễ.
• **A. Triển khai trong Auto Scaling group để đạt sẵn sàng cao — không phải khái niệm cùng loại: ASG quản lý số lượng và vòng đời instance, nó không quyết định vị trí vật lý. Và HPC là tải chạy theo đợt, không phải dịch vụ cần sẵn sàng liên tục.

Ghi nhớ

Ba loại placement group — bảng phải thuộc: | Loại | Mục tiêu | Phạm vi | Giới hạn | |---|---|---|---| | Cluster | độ trễ thấp, thông lượng cao | MỘT AZ | nên dùng cùng loại instance | | Spread | tối đa hoá cách ly lỗi | nhiều AZ | 7 instance mỗi AZ | | Partition | giới hạn phạm vi ảnh hưởng | nhiều AZ | 7 phân vùng mỗi AZ |

Từ khoá nhận diện:

"HPC", "MPI", "low latency between instances", "tightly coupled" → cluster "critical instances must not share hardware", "reduce correlated failures" → spread "HDFS", "Cassandra", "Kafka", "large distributed workload" → partition

Ba đặc điểm của cluster placement group: | Đặc điểm | Chi tiết | |---|---| | Một AZ duy nhất | không trải Region | | Nên dùng CÙNG loại instance | giảm nguy cơ thiếu năng lực | | Khởi động HẾT cùng lúc | một lời gọi API duy nhất |

Dòng cuối là lời khuyên vận hành quan trọng:

Khởi động từng máy một:
    → có thể hết năng lực giữa chừng
    → nhận lỗi InsufficientInstanceCapacity
    → cụm không đủ số node

Khởi động cả 16 máy trong MỘT lời gọi:
    → AWS tìm đủ chỗ trước khi bắt đầu

Và EFA là thứ bổ sung cho cluster placement group: | | ENA | EFA | |---|---|---| | Băng thông | tới 100+ Gbps | tương đương | | Bỏ qua kernel (OS bypass) | ❌ | ✅ | | Độ trễ | vài chục micro giây | dưới 20 micro giây | | Hỗ trợ MPI và NCCL | ❌ | ✅ | | Hệ điều hành | mọi loại | CHỈ LINUX |

EFA là lựa chọn chuẩn cho HPC trên AWS:

Elastic Fabric Adapter:
    → ứng dụng MPI nói chuyện trực tiếp với phần cứng mạng
    → không qua kernel của hệ điều hành
    → cho phép mở rộng tới hàng nghìn lõi hiệu quả

Lưu ý: EFA chỉ chạy trên Linux — với cụm HPC Windows phải dùng ENA.

Ba nhóm instance cho HPC: | Nhóm | Tối ưu | |---|---| | hpc6a, hpc7a, hpc7g | thiết kế riêng cho HPC, giá theo lõi tốt nhất | | c6in, c7gn | mạng băng thông rất cao | | p5, p4d | GPU cho học máy và mô phỏng |

Họ hpc* đáng biết: chúng có giá theo hiệu năng tốt hơn cho tải HPC và không tính phí truyền dữ liệu giữa các instance trong cùng placement group.

Ba thành phần của một cụm HPC hoàn chỉnh trên AWS: | Thành phần | Lựa chọn | |---|---| | Tính toán | EC2 trong cluster placement group + EFA | | Lưu trữ chia sẻ | FSx for Lustre | | Bộ lập lịch | AWS ParallelCluster (Slurm) hoặc AWS Batch |

AWS ParallelCluster đáng biết cho tình huống trong đề:

ParallelCluster:
    ✓ dựng cụm HPC hoàn chỉnh từ một tệp cấu hình
    ✓ tự cấu hình cluster placement group và EFA
    ✓ tích hợp Slurm — bộ lập lịch quen thuộc với giới nghiên cứu
    ✓ tự co giãn node theo hàng đợi công việc

Ba lưu ý khi dùng placement group: | Lưu ý | Chi tiết | |---|---| | Có thể gặp InsufficientInstanceCapacity | cụm càng lớn càng dễ | | Chuyển instance đang chạy vào group phải STOP trước | | | Không trộn nhiều loại instance khác nhau | tăng nguy cơ thiếu chỗ |

Và có thể dùng Capacity Reservation để đảm bảo:

aws ec2 create-capacity-reservation --instance-type hpc7a.96xlarge   --instance-platform Linux/UNIX --availability-zone ap-northeast-1a   --instance-count 16 --placement-group-arn <arn-placement-group>

Với cụm lớn chạy vào thời điểm cố định, đặt trước năng lực là cách tránh thất bại vào đúng lúc cần.

Ba lưu ý về chi phí HPC: | Lưu ý | Chi tiết | |---|---| | Spot Instance rất phù hợp nếu có checkpoint | giảm tới 90% | | Truyền dữ liệu trong cùng placement group | thường miễn phí với họ hpc* | | Tắt cụm khi không chạy | HPC là tải theo đợt |

Và một lời khuyên: hãy đo hiệu năng mạng thực tế bằng công cụ như iperf hoặc bài kiểm tra MPI ngay sau khi dựng cụm. Cluster placement group không phải lúc nào cũng đặt được mọi máy tối ưu, và biết con số thật giúp bạn phân biệt "mã chạy chậm" với "mạng không như kỳ vọng" — hai vấn đề có cách xử lý hoàn toàn khác nhau.

Đáp án

B — Dùng Application Load Balancer phân phối lưu lượng tới EC2 instance trải qua nhiều AZ; cấu hình Auto Scaling group để che lỗi của bất kỳ instance nào.

Vì sao đúng

Đề nêu hai yêu cầu, và đáp án đáp ứng cả hai bằng hai thành phần đúng vai: | Yêu cầu | Thành phần | |---|---| | Sẵn sàng cao | ALB trải nhiều AZ + ASG thay máy hỏng | | Định tuyến theo NỘI DUNG | ALB — chỉ nó làm được ở tầng 7 |

Và điểm mấu chốt là phân vai đúng:

Auto Scaling group:  QUẢN LÝ vòng đời instance
    → thay máy hỏng, co giãn theo tải
    → KHÔNG phân phối lưu lượng

Load balancer:       PHÂN PHỐI lưu lượng
    → nhận request và chuyển tới instance khoẻ mạnh
    → KHÔNG tạo hay xoá instance

Hai thứ này bổ sung nhau, không thay thế nhau — đó là lỗi của các phương án khác.

Vì sao phải là ALB chứ không phải NLB:

"content-based routing" nghĩa là quyết định dựa trên NỘI DUNG HTTP:
    → đường dẫn URL
    → tên miền
    → header
    → tham số truy vấn
        ↓
    Chỉ load balancer TẦNG 7 đọc được những thứ này
    → ALB (tầng 7) ✅
    → NLB (tầng 4) ❌ chỉ thấy IP và cổng

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

                    Internet
                        │
              Application Load Balancer
              (subnet công khai, ≥ 2 AZ)
                   ┌────┴────┐
              AZ-a │         │ AZ-c
            ┌──────▼──┐   ┌──▼──────┐
            │ EC2     │   │ EC2     │  ← Auto Scaling group
            │ EC2     │   │ EC2     │     (health check = ELB)
            └─────────┘   └─────────┘

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

• **A. Dùng Auto Scaling group để phân phối lưu lượng và Elastic IP để che lỗi instance — đây là phương án gần nhất vì nó có nhắc tới cơ chế xử lý lỗi, nhưng nó sai vai của ASG: ASG không phân phối lưu lượng. Và Elastic IP gắn với một instance duy nhất — nó không cân bằng tải, và gán lại EIP khi máy hỏng là thao tác thủ công có gián đoạn.
• **D. ASG phân phối lưu lượng và dùng Public IP để che lỗi — cùng lỗi về vai của ASG, và public IP còn thay đổi mỗi lần instance khởi động lại.
• **C. Dùng Network Load Balancer và Private IP để che lỗi — NLB thực sự cân bằng tải được và có sẵn sàng cao, nhưng nó không định tuyến theo nội dung vì hoạt động ở tầng 4. Và "private IP để che lỗi instance" không phải cơ chế có ý nghĩa.

Ghi nhớ

Ba thành phần của kiến trúc web sẵn sàng cao: | Thành phần | Vai trò | |---|---| | Load balancer | phân phối lưu lượng, kiểm tra sức khoẻ | | Auto Scaling group | thay máy hỏng, co giãn theo tải | | Nhiều Availability Zone | chịu được mất một AZ |

Thiếu bất kỳ thành phần nào thì kiến trúc không sẵn sàng cao.

ALB, NLB và GWLB — bảng phân biệt cốt lõi: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (IP) | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | IP tĩnh | ❌ | ✅ | — | | Hiệu năng | rất tốt | cực cao, độ trễ thấp nhất | — | | Giữ IP nguồn của client | qua X-Forwarded-For | ✅ nguyên bản | ✅ | | WAF | ✅ | ❌ | ❌ | | Xác thực dựng sẵn | ✅ Cognito, OIDC | ❌ | ❌ | | Phù hợp | web, microservice | game, IoT, TCP tuỳ ý | thiết bị bảo mật |

Từ khoá nhận diện:

"content-based routing", "path", "host header", "HTTP" → ALB "static IP", "UDP", "extreme performance", "millions of requests" → NLB "third-party firewall", "inspect all traffic" → GWLB

Sáu điều kiện định tuyến của ALB: | Điều kiện | Ví dụ | |---|---| | path-pattern | /api/* | | host-header | api.example.com | | http-header | X-Phien-Ban: v2 | | query-string | ?loai=beta | | http-request-method | POST | | source-ip | 10.0.0.0/8 |

Ba cấu hình quan trọng của ASG cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay máy mà LOAD BALANCER đánh giá hỏng | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động ứng dụng | | Trải qua ít nhất HAI AZ | chịu lỗi cấp AZ |

HealthCheckType = ELB là cấu hình bị bỏ sót nhiều nhất:

Mặc định là EC2:
    → chỉ kiểm tra status check của instance
    → ứng dụng treo nhưng OS chạy → coi là khoẻ
    → ALB ngừng gửi lưu lượng, nhưng ASG KHÔNG thay máy
        ↓
    → Máy nằm đó không phục vụ, không ai xử lý

Ba tính năng của ALB nâng cao sẵn sàng: | Tính năng | Chi tiết | |---|---| | Cross-zone load balancing | mặc định BẬT với ALB | | Connection draining (deregistration delay) | hoàn tất request đang xử lý trước khi gỡ máy | | Sticky session | giữ người dùng ở cùng một máy nếu cần |

Cross-zone load balancing là khác biệt đáng nhớ: | | ALB | NLB | |---|---|---| | Mặc định | BẬT | TẮT | | Phí truyền chéo AZ | miễn phí | tính phí khi bật |

Ba cách cải thiện thêm: | Cách | Lợi ích | |---|---| | Trải qua BA AZ thay vì hai | mất một AZ chỉ giảm 1/3 năng lực | | Đặt MinSize đủ chịu tải khi mất một AZ | | | Dùng CloudFront trước ALB | giảm tải, chống DDoS, tăng tốc |

Nguyên tắc N+1 cho nhiều AZ:

Cần 6 máy để phục vụ tải đỉnh:
    2 AZ → mỗi AZ 6 máy (tổng 12) để chịu được mất một AZ
    3 AZ → mỗi AZ 3 máy (tổng 9)  để chịu được mất một AZ
        ↓
    Ba AZ TIẾT KIỆM HƠN hai AZ cho cùng mức chịu lỗi

Đây là lý do AWS khuyến nghị ba AZ.

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Cần subnet ở ít nhất 2 AZ | yêu cầu bắt buộc | | IP của ALB THAY ĐỔI | luôn dùng tên DNS, không dùng IP | | Idle timeout mặc định 60 giây | tăng nếu có request chạy lâu |

Và một lời khuyên: hãy thử chấm dứt một instance trong giờ thấp điểm và quan sát. Bạn sẽ thấy chính xác ALB mất bao lâu để ngừng gửi lưu lượng và ASG mất bao lâu để đưa máy mới vào phục vụ — hai con số quyết định trải nghiệm người dùng khi sự cố thật xảy ra, và chúng thường dài hơn dự đoán.

Đáp án

C — Dùng AWS Glue job hằng ngày để biến đổi và làm sạch dữ liệu trên S3; nạp vào Amazon Redshift Serverless (có MPP ở mô hình không máy chủ); cho nhà phân tích dùng Amazon Redshift ML để dựng và huấn luyện mô hình.

Vì sao đúng

Đề nêu năm yêu cầu, và đáp án là lựa chọn duy nhất thoả cả năm: | Yêu cầu | Cơ chế | |---|---| | Biến đổi và nạp dữ liệu hằng ngày | Glue job theo lịch | | Kho dữ liệu cho truy vấn phân tích nhanh | Redshift | | Nhà phân tích dựng mô hình học máy bằng SQL quen thuộc | Redshift ML — cú pháp CREATE MODEL | | Xử lý song song ồ ạt (MPP) | Redshift là kiến trúc MPP | | Serverless để giảm công vận hành | Glue và Redshift Serverless đều không máy chủ |

Redshift ML là thứ đáp ứng vế "học máy bằng SQL":

CREATE MODEL du_doan_khach_hang_roi_bo
FROM (SELECT tuoi, so_don_hang, tong_chi_tieu, so_ngay_khong_mua, da_roi_bo
      FROM sch_phan_tich.khach_hang)
TARGET da_roi_bo
FUNCTION du_doan_roi_bo
IAM_ROLE default
SETTINGS (S3_BUCKET 'kho-mo-hinh');

Và dùng mô hình cũng bằng SQL:

SELECT ma_khach_hang, du_doan_roi_bo(tuoi, so_don_hang, tong_chi_tieu, so_ngay_khong_mua)
FROM sch_phan_tich.khach_hang_moi;

Bên dưới, Redshift ML tự gọi SageMaker Autopilot:

CREATE MODEL
    → Redshift xuất dữ liệu ra S3
    → SageMaker Autopilot tự chọn thuật toán, tinh chỉnh siêu tham số
    → mô hình được biên dịch và đưa NGƯỢC vào Redshift
        ↓
    Nhà phân tích KHÔNG viết dòng Python nào

Và Redshift là MPP đúng nghĩa:

Massively Parallel Processing:
    → dữ liệu chia trên nhiều node
    → mỗi node xử lý phần của mình SONG SONG
    → lưu trữ theo CỘT, nén cao
        ↓
    Tổng hợp trên hàng tỷ dòng trong vài giây

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

• **B. Glue job xử lý dữ liệu, đăng ký thành bảng Athena trong Glue Data Catalog, dùng Athena ML dự đoán bằng SQL ngay trên S3 — đây là phương án gần nhất và Athena ML thực sự tồn tại, nhưng nó thiếu vế kho dữ liệu MPP: đề yêu cầu rõ "load into a data warehouse to support fast analytical queries" và "must support MPP". Athena truy vấn trực tiếp trên S3, chậm hơn nhiều so với Redshift cho truy vấn tổng hợp lặp lại.
• **D. Chạy cụm EMR hằng ngày với Spark, nạp vào Redshift provisioned, dùng SageMaker notebook — vi phạm hai yêu cầu: EMR và Redshift provisioned không phải serverless, và SageMaker notebook đòi viết Python — trái với "familiar SQL syntax without writing custom Python code".
• **A. Nạp vào RDS for PostgreSQL và dùng Aurora ML — sai kiến trúc: RDS PostgreSQL là database giao dịch (OLTP), không phải MPP. Nó không xử lý được tải phân tích trên khối lượng lớn. Và Aurora ML là tính năng của Aurora, không phải RDS PostgreSQL thường.

Ghi nhớ

Ba dịch vụ ML tích hợp SQL trên AWS: | Dịch vụ | Chạy trên | Cú pháp | |---|---|---| | Redshift ML | Redshift | CREATE MODEL ← câu này | | Athena ML | Athena (dữ liệu S3) | USING FUNCTION gọi endpoint SageMaker | | Aurora ML | Aurora MySQL/PostgreSQL | gọi SageMaker hoặc Comprehend từ SQL |

Khác biệt quan trọng:

Redshift ML: HUẤN LUYỆN được mô hình mới ngay từ SQL
Athena ML và Aurora ML: chỉ GỌI mô hình SageMaker đã có

Đề yêu cầu "build and TRAIN ML models" — chỉ Redshift ML làm được hoàn toàn bằng SQL.

Redshift Serverless và Redshift provisioned: | | Serverless | Provisioned | |---|---|---| | Quản lý node | ❌ không có | ✅ chọn loại và số node | | Tính phí | theo RPU-giây khi có truy vấn | theo node-giờ | | Tự co giãn | ✅ | thủ công hoặc concurrency scaling | | Phù hợp | tải không đều, khó đoán | tải ổn định 24/7 |

Với công việc chạy mỗi sáng rồi truy vấn theo nhu cầu, Serverless thường rẻ hơn nhiều.

Ba khái niệm của Redshift Serverless: | Khái niệm | Việc | |---|---| | RPU (Redshift Processing Unit) | đơn vị năng lực | | Base capacity | năng lực tối thiểu (8–512 RPU) | | Max RPU-hours | trần chi phí — nên đặt |

Bốn dịch vụ phân tích của AWS — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Redshift | kho dữ liệu MPP, truy vấn phức tạp lặp lại ← câu này | | Athena | truy vấn ad-hoc trên S3, không cần nạp | | EMR | Spark, Hadoop, xử lý tuỳ biến | | OpenSearch | tìm kiếm và phân tích log |

Từ khoá nhận diện:

"data warehouse", "MPP", "complex joins", "BI dashboards" → Redshift "query data in place", "ad-hoc", "no ETL" → Athena "Spark", "custom code", "Hadoop ecosystem" → EMR "SQL-based ML", "analysts without Python" → Redshift ML

Ba loại mô hình Redshift ML hỗ trợ: | Loại | Ví dụ | |---|---| | Phân loại nhị phân | khách hàng có rời bỏ không | | Phân loại nhiều lớp | phân nhóm sản phẩm | | Hồi quy | dự báo doanh số |

Và ba chế độ tạo mô hình: | Chế độ | Chi tiết | |---|---| | AUTO (mặc định) | SageMaker Autopilot tự chọn mọi thứ | | AUTO OFF với MODEL_TYPE | chỉ định XGBoost, MLP, Linear Learner | | BYOM (Bring Your Own Model) | dùng mô hình SageMaker đã có |

Ba tính năng của Redshift đáng biết: | Tính năng | Việc | |---|---| | Redshift Spectrum | truy vấn dữ liệu Ở LẠI S3, không cần nạp | | Data Sharing | chia sẻ dữ liệu giữa các cụm, không sao chép | | Zero-ETL với Aurora | dữ liệu giao dịch tự đồng bộ sang Redshift |

Zero-ETL là hướng đi mới đáng chú ý:

Trước: Aurora → DMS hoặc Glue → Redshift (có độ trễ, phải bảo trì)
Zero-ETL: Aurora → Redshift gần như tức thì, không có đường ống nào

Ba tối ưu hiệu năng cho Redshift: | Tối ưu | Chi tiết | |---|---| | Chọn đúng distribution key | giảm việc di chuyển dữ liệu giữa node khi JOIN | | Chọn sort key theo cột hay lọc | bỏ qua block không cần đọc | | Dùng định dạng cột (Parquet) ở S3 | cho Spectrum và Glue |

Distribution style là quyết định quan trọng nhất: | Style | Dùng khi | |---|---| | KEY | bảng lớn hay JOIN với nhau — dùng chung khoá | | ALL | bảng chiều nhỏ, sao chép ra mọi node | | EVEN | không có mẫu JOIN rõ ràng | | AUTO | để Redshift tự chọn — mặc định |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Đặt max RPU-hours cho Serverless | tránh hoá đơn bất ngờ | | Redshift ML tính phí SageMaker huấn luyện | mô hình lớn có thể đáng kể | | Nén và phân vùng dữ liệu ở S3 | giảm chi phí quét |

Và một lời khuyên: hãy giới hạn thời gian huấn luyện của Redshift ML bằng MAX_RUNTIME khi thử nghiệm. Mặc định Autopilot có thể chạy rất lâu để tìm mô hình tốt nhất, và với nhà phân tích đang thử nghiệm ý tưởng, một mô hình đủ tốt trong 30 phút giá trị hơn mô hình hoàn hảo sau 8 giờ.