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

Đáp án

B — Đăng ký AWS Shield Advanced để có bảo vệ DDoS chủ động; huy động AWS DDoS Response Team (DRT) phân tích mẫu lưu lượng và áp biện pháp giảm thiểu; dùng khả năng ghi log và báo cáo dựng sẵn để duy trì nhật ký kiểm toán.

Vì sao đúng

Đề nêu ba yêu cầu, và Shield Advanced đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giảm thiểu DDoS | Shield Advanced bảo vệ tầng 3, 4 và 7 | | Nhật ký chi tiết phục vụ kiểm toán | báo cáo và metric dựng sẵn | | THAY ĐỔI TỐI THIỂU kiến trúc hiện có | chỉ đăng ký và gắn vào ALB — không đổi gì |

Vế thứ ba là điểm phân biệt quyết định:

Shield Advanced:
    → bảo vệ ALB HIỆN CÓ, không phải thêm thành phần nào
    → không đổi DNS, không đổi luồng lưu lượng
        ↓
    Đúng "minimal changes to the existing architecture"

Ba khả năng riêng của Shield Advanced: | Khả năng | Chi tiết | |---|---| | DDoS Response Team (DRT) | đội chuyên gia AWS hỗ trợ 24/7 trong lúc bị tấn công | | Bảo vệ chi phí | hoàn lại phí co giãn do DDoS gây ra | | Báo cáo và metric chi tiết | ← yêu cầu về kiểm toán | | WAF được bao gồm | không tính phí WAF riêng |

Bảo vệ chi phí là lợi ích tài chính đáng kể:

Tấn công DDoS làm ASG mở rộng ồ ạt
    → hoá đơn EC2 và truyền dữ liệu tăng vọt
        ↓
    Shield Advanced hoàn lại phần chi phí phát sinh do tấn công

Bật Shield Advanced:

aws shield create-subscription

aws shield create-protection --name bao-ve-alb   --resource-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/portal/abc

aws shield associate-drt-role --role-arn <arn-role-cho-drt>

Và associate-drt-role là bước cho phép DRT hành động thay bạn — đúng vế "engage the DDoS Response Team".

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

• **C. Đặt CloudFront trước ALB, bật WAF với quy tắc lọc IP và địa lý, dùng access log để phân tích — đây là phương án gần nhất và thực sự là một kiến trúc chống DDoS rất tốt, nhưng nó thay đổi kiến trúc: thêm một tầng CDN, đổi bản ghi DNS, và phải cấu hình lại origin. Đề yêu cầu rõ "minimal changes to the existing architecture". Nó cũng không có DRT hay bảo vệ chi phí.
• **D. Dùng GuardDuty rồi thủ công chặn IP ở ALB hoặc security group — không mở rộng được: DDoS đến từ hàng nghìn IP thay đổi liên tục, chặn thủ công luôn chậm hơn kẻ tấn công. Và security group không có quy tắc Deny.
• **A. Dùng Amazon Inspector để phát hiện vector tấn công DDoS và vá lỗi — sai dịch vụ hoàn toàn: Inspector quét lỗ hổng phần mềm, nó không liên quan gì tới lưu lượng mạng hay DDoS.

Ghi nhớ

Shield Standard và Shield Advanced — bảng phải thuộc: | | Shield Standard | Shield Advanced | |---|---|---| | Chi phí | MIỄN PHÍ, tự động | ~3.000 USD/tháng | | Tầng bảo vệ | 3 và 4 | 3, 4 và 7 | | DDoS Response Team | ❌ | ✅ 24/7 | | Bảo vệ chi phí | ❌ | ✅ | | Báo cáo chi tiết | ❌ | ✅ | | WAF được bao gồm | ❌ | ✅ | | Health-based detection | ❌ | ✅ |

Các tài nguyên Shield Advanced bảo vệ: | Tài nguyên | Hỗ trợ | |---|---| | CloudFront | ✅ | | Route 53 hosted zone | ✅ | | Application Load Balancer | ✅ ← câu này | | Network Load Balancer, Classic LB | ✅ | | Elastic IP (EC2) | ✅ | | Global Accelerator | ✅ |

Ba lớp chống DDoS trên AWS: | Lớp | Chống gì | |---|---| | Shield Standard | tấn công thể tích tầng 3/4 phổ biến | | AWS WAF | tấn công tầng 7 — rate limiting, lọc mẫu | | Shield Advanced | cả hai + hỗ trợ chuyên gia + bảo vệ chi phí |

Ba loại tấn công DDoS: | Loại | Ví dụ | Chống bằng | |---|---|---| | Thể tích (tầng 3/4) | UDP flood, DNS amplification | Shield | | Giao thức (tầng 3/4) | SYN flood | Shield | | Tầng ứng dụng (tầng 7) | HTTP flood, slowloris | WAF + Shield Advanced |

Và tấn công tầng 7 khó nhất:

HTTP flood trông giống lưu lượng thật
    → mỗi request hợp lệ về mặt giao thức
    → chỉ số lượng là bất thường
        ↓
    Cần rate-based rule và phân tích hành vi

Rate-based rule của WAF:

{"Name": "gioi-han-tan-suat", "Priority": 10,
 "Action": {"Block": {}},
 "Statement": {"RateBasedStatement": {
   "Limit": 2000, "AggregateKeyType": "IP"}}}

Tự chặn IP vượt ngưỡng trong cửa sổ 5 phút — không cần ai can thiệp.

Ba biện pháp kiến trúc chống DDoS: | Biện pháp | Chi tiết | |---|---| | CloudFront trước ứng dụng | hấp thụ tấn công ở biên | | Global Accelerator | phân tán qua mạng anycast | | Auto Scaling | hấp thụ đỉnh tải |

Ba nguồn nhật ký cho kiểm toán: | Nguồn | Ghi gì | |---|---| | Shield Advanced report | chi tiết sự kiện tấn công | | WAF logging | request bị chặn và quy tắc nào khớp | | ALB access log | mọi request tới ứng dụng | | VPC Flow Logs | lưu lượng ở tầng mạng |

Ba việc nên làm khi đăng ký Shield Advanced: | Việc | Chi tiết | |---|---| | Gắn protection cho MỌI tài nguyên công khai | ALB, EIP, CloudFront | | Cấu hình DRT role | để DRT hành động được thay bạn | | Bật proactive engagement | DRT chủ động liên hệ khi phát hiện tấn công |

aws shield enable-proactive-engagement
aws shield associate-proactive-engagement-details   --emergency-contact-list 'EmailAddress=bao-mat@congty.com,PhoneNumber=+84...'

Ba lưu ý về chi phí Shield Advanced: | Lưu ý | Chi tiết | |---|---| | ~3.000 USD/tháng, cam kết 1 NĂM | tính cho cả Organization | | Bao gồm phí WAF | bù lại một phần | | Bảo vệ chi phí khi bị tấn công | có thể hoàn lại đáng kể |

Với cơ quan giao thông công cộng có lưu lượng lớn, khoản này thường được biện minh bằng chi phí của một lần ngừng dịch vụ.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | DDoSDetected | đang có tấn công | | DDoSAttackBitsPerSecond | quy mô tấn công thể tích | | DDoSAttackRequestsPerSecond | quy mô tấn công tầng 7 |

Và một lời khuyên: hãy kết hợp Shield Advanced với CloudFront nếu kiến trúc cho phép, chứ không chỉ chọn một. Shield Advanced bảo vệ tài nguyên hiện có ngay lập tức với thay đổi tối thiểu; CloudFront thì hấp thụ tấn công ở biên trước khi chúng chạm tới hạ tầng của bạn — và hai thứ đó bổ sung nhau chứ không thay thế nhau.

Đáp án

A và D.

• A — Tạo outbound endpoint trên Route 53 Resolver để Resolver chuyển tiếp có điều kiện truy vấn tới máy chủ DNS tại chỗ
• D — Tạo inbound endpoint trên Route 53 Resolver để máy chủ DNS tại chỗ chuyển tiếp truy vấn tới Route 53 Resolver

Vì sao đúng

Đề cần CẢ HAI CHIỀU, và mỗi chiều dùng một loại endpoint: | Chiều truy vấn | Endpoint | |---|---| | Từ VPC hỏi tên miền TẠI CHỖ | OUTBOUND | | Từ tại chỗ hỏi tên miền của VPC | INBOUND |

Mẹo nhớ: đứng ở vị trí VPC.

Truy vấn ĐI RA khỏi VPC  → outbound endpoint
Truy vấn ĐI VÀO VPC      → inbound endpoint

A — outbound endpoint cho chiều VPC → tại chỗ:

EC2 trong VPC hỏi: he-thong-cu.noi-bo.congty.local
    ↓
Route 53 Resolver (VPC+2) nhận truy vấn
    ↓ khớp forwarding rule
Outbound endpoint (ENI trong VPC)
    ↓ qua Direct Connect
Máy chủ DNS tại chỗ trả lời

aws route53resolver create-resolver-endpoint   --name ra-ngoai --direction OUTBOUND   --security-group-ids sg-dns   --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

aws route53resolver create-resolver-rule   --name chuyen-tiep-noi-bo --rule-type FORWARD   --domain-name noi-bo.congty.local   --resolver-endpoint-id rslvr-out-abc   --target-ips Ip=10.100.0.10,Port=53 Ip=10.100.0.11,Port=53

D — inbound endpoint cho chiều tại chỗ → VPC:

Máy chủ tại chỗ hỏi: db.ap-northeast-1.rds.amazonaws.com
    ↓ máy chủ DNS tại chỗ có conditional forwarder
Inbound endpoint (ENI có IP riêng trong VPC)
    ↓
Route 53 Resolver trả lời với IP RIÊNG của tài nguyên

aws route53resolver create-resolver-endpoint   --name vao-trong --direction INBOUND   --security-group-ids sg-dns   --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

Sau đó cấu hình máy chủ DNS tại chỗ chuyển tiếp tới IP của inbound endpoint.

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

• **B. Tạo inbound endpoint để Resolver chuyển tiếp truy vấn tới máy chủ tại chỗ — đây là phương án gần nhất và là bẫy chính: nó ghép đúng loại endpoint với sai chiều. Inbound endpoint nhận truy vấn từ ngoài vào, không gửi truy vấn ra.
• **C. Tạo outbound endpoint để máy chủ tại chỗ chuyển tiếp truy vấn tới Resolver — cùng lỗi ở chiều ngược lại.
• **E. Tạo "universal endpoint" nhận và chuyển tiếp cả hai chiều — không tồn tại loại endpoint nào tên như vậy. Route 53 Resolver chỉ có inbound và outbound.

Ghi nhớ

Hai loại endpoint của Route 53 Resolver — bảng phải thuộc: | Loại | Chiều | Dùng khi | |---|---|---| | Outbound | VPC → tại chỗ | tài nguyên trong VPC phân giải tên miền tại chỗ | | Inbound | tại chỗ → VPC | máy tại chỗ phân giải tên miền của AWS | | Cả hai | hai chiều | DNS lai đầy đủ ← câu này |

Ba thành phần của Route 53 Resolver: | Thành phần | Việc | |---|---| | Resolver mặc định (VPC+2) | có sẵn mọi VPC | | Inbound / Outbound endpoint | ENI cho lưu lượng DNS xuyên biên giới | | Resolver rule | quyết định miền nào chuyển đi đâu |

Địa chỉ VPC+2 là chi tiết đáng nhớ:

VPC CIDR 10.0.0.0/16 → Resolver ở 10.0.0.2
    → cũng truy cập được qua 169.254.169.253

Ba loại resolver rule: | Loại | Việc | |---|---| | FORWARD | chuyển truy vấn cho miền này tới IP chỉ định | | SYSTEM | NGOẠI LỆ — không chuyển tiếp miền con này | | RECURSIVE | dùng resolver mặc định |

Rule SYSTEM hữu ích cho ngoại lệ:

FORWARD:  congty.local        → máy chủ DNS tại chỗ
SYSTEM:   aws.congty.local    → dùng Route 53 (không chuyển đi)
    → rule CỤ THỂ HƠN thắng

Ba yêu cầu của endpoint: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 2 địa chỉ IP ở 2 AZ khác nhau | để chịu lỗi | | Security group mở cổng 53 (UDP VÀ TCP) | | | Có đường mạng tới đích | Direct Connect hoặc VPN |

Nhớ mở CẢ UDP LẪN TCP cổng 53:

UDP 53: truy vấn thông thường
TCP 53: phản hồi lớn hơn 512 byte
        ↓
    Chỉ mở UDP là lỗi khiến truy vấn lớn thất bại khó hiểu

Ba tính năng khác của Route 53 Resolver: | Tính năng | Việc | |---|---| | Resolver Query Logging | ghi lại mọi truy vấn DNS từ VPC | | Resolver DNS Firewall | chặn truy vấn tới miền độc hại | | Chia sẻ rule qua AWS RAM | dùng chung giữa nhiều tài khoản |

Chia sẻ rule qua RAM là mẫu tiết kiệm quan trọng:

Tài khoản mạng:
    → tạo endpoint và rule MỘT LẦN
    → chia sẻ rule qua RAM
        ↓
Các tài khoản khác chỉ gắn rule vào VPC của mình
    → tiết kiệm phí endpoint (~0,125 USD/giờ mỗi ENI)

Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Cần bật enableDnsSupport và enableDnsHostnames | trên VPC | | Phải GẮN hosted zone với VPC | | | Máy tại chỗ phân giải được qua inbound endpoint | ← ứng dụng của câu này |

Thứ tự phân giải DNS trong VPC:

① Private hosted zone đã gắn với VPC
② Resolver rule (forwarding rule)
③ DNS công cộng

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Endpoint | ~0,125 USD/giờ mỗi ENI (hai ENI ≈ 180 USD/tháng) | | Truy vấn | theo triệu truy vấn | | Query logging | phí CloudWatch Logs hoặc S3 |

Với cả inbound lẫn outbound (4 ENI), chi phí khoảng 360 USD/tháng — nên chia sẻ qua RAM nếu có nhiều tài khoản.

Ba lệnh chẩn đoán DNS lai:

# Từ EC2: hỏi thẳng resolver của AWS
dig @10.0.0.2 he-thong-cu.noi-bo.congty.local

# Từ máy tại chỗ: hỏi inbound endpoint
dig @10.0.1.50 db.ap-northeast-1.rds.amazonaws.com

# Xem rule đang gắn với VPC nào
aws route53resolver list-resolver-rule-associations

Ba lưu ý về sẵn sàng: | Lưu ý | Chi tiết | |---|---| | Hai IP ở hai AZ cho mỗi endpoint | | | Hai máy chủ DNS tại chỗ làm target | tránh điểm hỏng duy nhất | | Đường dự phòng cho Direct Connect | VPN backup |

Và một lời khuyên: hãy bật Resolver Query Logging ngay khi thiết lập DNS lai. Khi có ai đó báo "không kết nối được tới hệ thống cũ", câu hỏi đầu tiên luôn là "tên miền có phân giải được không" — và log truy vấn trả lời câu đó ngay lập tức thay vì phải đoán.

Đáp án

A — Dùng Amazon CloudFront với Amazon S3 làm nơi lưu trữ tài sản tĩnh.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp S3 + CloudFront thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Tài sản TĨNH (báo cáo, tài liệu chiến thuật) | S3 — kho object cho tệp tĩnh | | KHÔNG cần cấp phát hạ tầng | cả hai đều không có máy chủ | | Tối ưu chi phí | S3 rẻ nhất, CloudFront giảm phí truyền và tải origin |

Vì sao đây là kiến trúc đúng cho tài sản tĩnh:

Hiện tại: ứng dụng phục vụ tệp tĩnh
    → mỗi lần tải tài liệu chiếm tài nguyên máy chủ ứng dụng
    → ứng dụng "đóng băng" vì tài nguyên bị chiếm hết
        ↓
Tách tài sản tĩnh ra S3 + CloudFront:
    → máy chủ ứng dụng chỉ lo logic nghiệp vụ
    → tệp tĩnh phục vụ từ điểm biên, không chạm tới ứng dụng

Và về chi phí:

S3:         ~0,023 USD/GB-tháng lưu trữ
CloudFront: ~0,085 USD/GB truyền ra, có bậc giảm giá
Từ S3 tới CloudFront: MIỄN PHÍ
        ↓
    Với tỷ lệ trúng cache cao, phần lớn request không chạm S3

Cấu hình:

aws s3 cp bao-cao/ s3://tai-san-tinh/bao-cao/ --recursive

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-tai-san,OriginAccessControlOriginType=s3,SigningBehavior=always,SigningProtocol=sigv4'

Và đặt mã băm nội dung vào tên tệp để TTL dài:

bang-xep-hang.a1b2c3.pdf  → TTL 1 năm, không bao giờ phải invalidate

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

• **D. Dùng CloudFront với DynamoDB để truy cập tài sản tĩnh — đây là phương án gần nhất vì vế CloudFront đúng, nhưng nó sai nơi lưu trữ: DynamoDB là database NoSQL với giới hạn 400 KB mỗi item, không phù hợp cho tệp báo cáo hay tài liệu. Và CloudFront không lấy nội dung trực tiếp từ DynamoDB được.
• **C. Dùng Lambda với ElastiCache và RDS để phục vụ tài sản tĩnh — thừa và sai công cụ: dùng cả một chuỗi tính toán và database chỉ để trả về tệp tĩnh là lãng phí, và ElastiCache là bộ đệm trong VPC chứ không phục vụ người dùng cuối.
• **B. Dùng Lambda với RDS cho kiến trúc serverless — không giải quyết vấn đề: RDS là database quan hệ, không phù hợp lưu tệp. Và phục vụ tệp qua Lambda đắt và chậm hơn S3.

Ghi nhớ

Kiến trúc chuẩn cho tài sản tĩnh:

Người dùng
    ↓ DNS (Route 53 alias)
CloudFront (đệm ở biên, TLS, WAF)
    ↓ Origin Access Control
S3 bucket (riêng tư hoàn toàn)

Chọn nơi lưu trữ theo loại dữ liệu — bảng phải thuộc: | Loại dữ liệu | Nơi lưu | |---|---| | Tệp tĩnh (ảnh, PDF, video, JS, CSS) | S3 | | Bản ghi có cấu trúc, truy vấn theo khoá | DynamoDB | | Dữ liệu quan hệ | RDS hoặc Aurora | | Kết quả tạm, phiên | ElastiCache |

Ba lợi ích của việc tách tài sản tĩnh: | Lợi ích | Chi tiết | |---|---| | Máy chủ ứng dụng nhẹ hơn | ← giải quyết vấn đề "đóng băng" | | Chi phí thấp hơn | S3 rẻ hơn EC2 phục vụ tệp | | Hiệu năng tốt hơn | đệm ở biên toàn cầu |

Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Mã băm nội dung trong tên tệp | TTL rất dài mà vẫn cập nhật ngay khi đổi | | Chỉ chuyển tiếp header cần thiết | header thừa giảm tỷ lệ trúng | | Bật nén tự động | Gzip và Brotli |

Mẫu tên tệp có mã băm:

tai-lieu.a1b2c3d4.pdf   → TTL 1 năm
index.html              → TTL ngắn, trỏ tới tệp có mã băm mới
        ↓
    Loại bỏ hẳn nhu cầu invalidation (vốn tốn phí và mất thời gian)

Ba cấu hình CloudFront quan trọng: | Cấu hình | Chi tiết | |---|---| | Origin Access Control (OAC) | khoá bucket, chỉ CloudFront đọc được | | Cache policy CachingOptimized | cho nội dung tĩnh | | Compress objects automatically | giảm băng thông |

OAC thay thế OAI (đã lỗi thời): | | OAI (cũ) | OAC (khuyến nghị) | |---|---|---| | Hỗ trợ SSE-KMS | ❌ | ✅ | | Mọi Region | ❌ | ✅ | | Mọi phương thức HTTP | chỉ GET, HEAD | ✅ |

Ba lớp lưu trữ S3 phù hợp: | Lớp | Dùng khi | |---|---| | Standard | tài sản truy cập thường xuyên | | Intelligent-Tiering | mẫu truy cập khó đoán — không có phí truy xuất | | Standard-IA | báo cáo cũ, ít xem |

Intelligent-Tiering đáng cân nhắc:

Báo cáo bảng xếp hạng lịch sử:
    → mới thì xem nhiều, cũ thì gần như không ai xem
    → nhưng thỉnh thoảng có người tra lại
        ↓
    Intelligent-Tiering tự phân tầng, KHÔNG có phí truy xuất

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront Free Tier | 1 TB truyền và 10 triệu request mỗi tháng, vĩnh viễn | | Price class | bỏ điểm biên đắt nếu người dùng tập trung một vùng | | Origin Shield | giảm request tới S3 |

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM phải ở us-east-1 | yêu cầu của CloudFront | | Distribution mất 5–15 phút triển khai | | | Route 53 alias record miễn phí | trỏ tên miền tới distribution |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | nên trên 90% với nội dung tĩnh | | 4xxErrorRate, 5xxErrorRate | lỗi phục vụ | | OriginLatency | thời gian lấy từ S3 |

Ba việc nên làm thêm: | Việc | Chi tiết | |---|---| | Bật access log ra S3 | phân tích lưu lượng và nội dung phổ biến | | Gắn WAF nếu cần bảo vệ | | | Đặt lifecycle rule cho báo cáo cũ | chuyển sang lớp rẻ hơn |

Và một lời khuyên: hãy kiểm tra CloudFront access log để biết tài sản nào được tải nhiều nhất. Với ứng dụng game, thường một vài báo cáo hoặc hướng dẫn chiếm phần lớn lưu lượng — và biết chúng là gì giúp bạn tối ưu đúng chỗ, ví dụ nén kỹ hơn hoặc chia nhỏ để tải dần.

Đáp án

B, C và D.

• B — XOÁ hàng đợi Standard hiện có và TẠO LẠI dưới dạng FIFO
• C — Đảm bảo thông lượng của hàng đợi FIFO không vượt 3.000 thông điệp mỗi giây
• D — Đảm bảo tên hàng đợi FIFO kết thúc bằng hậu tố .fifo

Vì sao đúng

Ba đáp án là ba ràng buộc kỹ thuật khi chuyển từ Standard sang FIFO:

B — không chuyển đổi tại chỗ được:

SQS KHÔNG cho đổi loại hàng đợi sau khi tạo
    → Standard và FIFO là hai loại khác nhau ở tầng hạ tầng
        ↓
    Phải TẠO hàng đợi FIFO mới
    → chuyển producer và consumer sang
    → rồi xoá hàng đợi cũ

D — tên bắt buộc kết thúc bằng .fifo:

aws sqs create-queue --queue-name don-hang.fifo   --attributes '{"FifoQueue":"true","ContentBasedDeduplication":"false"}'

Thiếu hậu tố .fifo thì lệnh tạo thất bại — đây là ràng buộc cứng.

C — hạn mức thông lượng với gom lô:

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 hoặc nhận TỚI 10 thông điệp khi gom lô
        ↓
    300 × 10 = 3.000 thông điệp/giây

Và đề nêu rõ "FIFO queues WITH BATCHING" — nên con số đúng là 3.000, không phải 300.

Ba bước chuyển đổi:

① Tạo hàng đợi FIFO mới với tên .fifo
② Cập nhật producer: thêm MessageGroupId và MessageDeduplicationId
③ Chuyển consumer sang hàng đợi mới, rồi xoá hàng đợi cũ

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

• **F. Đảm bảo thông lượng không vượt 300 thông điệp mỗi giây — đây là phương án gần nhất và là con số đúng cho FIFO KHÔNG gom lô, nhưng đề nói rõ "with batching". Với gom lô 10, thông lượng là 3.000.
• **A. Chuyển đổi hàng đợi Standard hiện có thành FIFO — không làm được: SQS không hỗ trợ đổi loại hàng đợi.
• **E. Đặt tên hàng đợi FIFO giống hệt hàng đợi Standard — không làm được: tên FIFO bắt buộc có hậu tố .fifo, nên không thể trùng tên với hàng đợi Standard.

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

Con số 3.000 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 — cao hơn con số 3.000 rất nhiều.

Với thương mại điện tử xử lý đơn hàng, dùng mã đơn hàng hoặc mã khách hàng làm MessageGroupId là thiết kế tự nhiên, và khi đó nên bật high-throughput ngay từ đầu.

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

Ghi nhớ

SQS Standard và FIFO — bảng phải thuộc: | | Standard | FIFO | |---|---|---| | Thứ tự | cố gắng, không đảm bảo | ✅ trong message group | | Trùng lặp | có thể (at-least-once) | ❌ exactly-once | | Thông lượng | gần như không giới hạn | 300 (3.000 gom lô), high-throughput tới 70.000 | | Tên hàng đợi | bất kỳ | phải kết thúc .fifo | | Giá | rẻ hơn | đắt hơn ~25% |

Hai id bắt buộc của FIFO: | Id | Việc | |---|---| | MessageGroupId | BẮT BUỘC — nhóm giữ thứ tự, các nhóm xử lý SONG SONG | | MessageDeduplicationId | bắt buộc trừ khi bật ContentBasedDeduplication |

MessageGroupId là quyết định thiết kế quan trọng nhất:

Một group cho toàn hệ thống:
    → xử lý TUẦN TỰ, thông lượng rất thấp

Nhiều group (theo mã đơn hàng, mã khách hàng):
    → song song cao
    → vẫn giữ thứ tự trong từng nhóm

Ba lưu ý về ContentBasedDeduplication: | Lưu ý | Chi tiết | |---|---| | Bật thì SQS 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 tường minh thì chặt hơn | dùng mã nghiệp vụ |

Với đơn hàng, nên khai tường minh:

sqs.send_message(
    QueueUrl=url, MessageBody=json.dumps(don_hang),
    MessageGroupId=ma_khach_hang,
    MessageDeduplicationId=ma_don_hang)

Hai đơn hàng giống hệt nội dung trong 5 phút là hoàn toàn hợp lệ
    → dedup theo nội dung sẽ NUỐT MẤT đơn thứ hai

Ba thao tác gom lô của 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 request, không theo thông điệp.

Ba cấu hình nên có cho hàng đợi FIFO: | Cấu hình | Giá trị | |---|---| | ReceiveMessageWaitTimeSeconds | 20 (long polling) | | VisibilityTimeout | dài hơn thời gian xử lý | | Dead-letter queue | sau 3–5 lần thử |

Ba lưu ý khi dùng Lambda với FIFO: | Lưu ý | Chi tiết | |---|---| | Số lượt đồng thời = số message group | KHÔNG phải hạn mức Lambda | | Mỗi lô chỉ chứa thông điệp của MỘT group | | | ReportBatchItemFailures | chỉ trả lại thông điệp hỏng |

Ba bước chuyển đổi an toàn: | Bước | Chi tiết | |---|---| | Chạy song song hai hàng đợi một thời gian | producer ghi vào cả hai | | Kiểm chứng consumer mới xử lý đúng thứ tự | | | Chuyển hẳn rồi mới xoá hàng đợi cũ | |

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: hãy thử tải với phân bố message group thật trước khi chuyển sang sản xuất. Thông lượng của FIFO phụ thuộc rất nhiều vào việc thông điệp phân bố đều giữa các group hay không — nếu 80% đơn hàng thuộc về vài khách hàng lớn, những group đó sẽ thành nút thắt bất kể cấu hình gom lô ra sao.

Đáp án

D — Dùng VPC endpoint để truy cập Amazon SQS.

Vì sao đúng

Đề nêu mối lo rõ ràng: thành phần trong VPC truy cập SQS qua Internet công cộng.

Mặc định, SQS chỉ có endpoint CÔNG KHAI
    → EC2 ở private subnet phải qua NAT Gateway
    → lưu lượng đi ra Internet rồi quay lại AWS
        ↓
    VPC endpoint (PrivateLink) loại bỏ điều đó

Cách VPC endpoint hoạt động:

Tạo interface VPC endpoint cho SQS
    → một ENI có IP RIÊNG được tạo trong subnet của bạn
    → SDK gọi endpoint của SQS
    → private DNS phân giải về IP riêng đó
        ↓
    Lưu lượng KHÔNG rời khỏi mạng của AWS

aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface   --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.sqs   --subnet-ids subnet-a subnet-b   --security-group-ids sg-endpoint   --private-dns-enabled

--private-dns-enabled là tuỳ chọn quan trọng:

Có bật:
    sqs.ap-northeast-1.amazonaws.com
    → tự phân giải thành IP riêng của endpoint
        ↓
    SDK và mã ứng dụng KHÔNG phải sửa gì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | ← yêu cầu của đề | | Không cần NAT Gateway cho SQS | tiết kiệm phí xử lý dữ liệu | | Kiểm soát bằng endpoint policy | giới hạn hàng đợi nào truy cập được |

Và endpoint policy cho phép siết chặt thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage"],
  "Resource": "arn:aws:sqs:ap-northeast-1:123456789012:hang-doi-ung-dung"}]}

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

• **A. Dùng NAT instance để truy cập SQS — đây là phương án gần nhất và thực sự cho EC2 ở private subnet gọi được SQS, nhưng nó không giải quyết mối lo của đề: lưu lượng vẫn đi ra Internet công cộng rồi quay lại AWS. Và NAT instance là công nghệ cũ phải tự quản lý.
• **B. Dùng Internet Gateway — tệ hơn: nó đòi instance có IP công cộng và nằm ở public subnet, phơi chúng ra Internet.
• **C. Dùng VPN connection để truy cập SQS — sai mục đích: VPN nối VPC với mạng tại chỗ, không phải cách truy cập dịch vụ AWS.

Ghi nhớ

Ba loại VPC endpoint — bảng phải thuộc: | Loại | Dịch vụ | Cơ chế | Chi phí | |---|---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table | MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS | ENI có IP riêng | có phí | | Gateway Load Balancer endpoint | thiết bị bảo mật | chuyển hướng lưu lượng | có phí |

Đây là bảng được hỏi rất thường xuyên.

Ba dịch vụ dùng interface endpoint phổ biến: | Dịch vụ | Tên service | |---|---| | SQS | com.amazonaws.<region>.sqs ← câu này | | SNS | com.amazonaws.<region>.sns | | Systems Manager | ssm, ssmmessages, ec2messages | | ECR | ecr.api, ecr.dkr | | Secrets Manager, KMS | | | CloudWatch Logs | logs |

Ba đặc điểm của interface endpoint: | Đặc điểm | Chi tiết | |---|---| | Là ENI có IP riêng trong subnet của bạn | | | Gắn security group được | kiểm soát ai gọi tới | | Private DNS | tên miền chuẩn tự trỏ vào endpoint |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Interface endpoint | ~0,01 USD/giờ mỗi ENI mỗi AZ | | Dữ liệu xử lý | ~0,01 USD/GB | | So với NAT Gateway | thường RẺ HƠN cho lưu lượng lớn |

So sánh với NAT Gateway:

NAT Gateway:  ~0,045 USD/giờ + 0,045 USD/GB
Interface endpoint: ~0,01 USD/giờ mỗi AZ + 0,01 USD/GB
        ↓
    Với lưu lượng lớn tới dịch vụ AWS, endpoint rẻ hơn nhiều

Gateway endpoint cho S3 và DynamoDB là MIỄN PHÍ:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-private

Nên tạo ở mọi VPC — không có lý do gì để không tạo.

Lưu ý quan trọng: gateway endpoint KHÔNG truy cập được từ tại chỗ:

Gateway endpoint hoạt động qua ROUTE TABLE của VPC
    → chỉ tài nguyên TRONG VPC dùng được
    → máy tại chỗ qua Direct Connect KHÔNG dùng được
        ↓
    Muốn truy cập S3 riêng tư từ tại chỗ:
        → interface endpoint cho S3

Ba cách kiểm soát truy cập qua endpoint: | Cách | Chi tiết | |---|---| | Endpoint policy | giới hạn hành động và tài nguyên qua endpoint | | Security group của endpoint ENI | ai trong VPC gọi được | | aws:SourceVpce trong resource policy | chỉ cho phép qua endpoint cụ thể |

Điều kiện aws:SourceVpce rất mạnh:

{"Effect": "Deny", "Principal": "*", "Action": "sqs:*",
 "Resource": "arn:aws:sqs:...:hang-doi-ung-dung",
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

Hàng đợi chỉ truy cập được qua đúng endpoint đó — kể cả từ ngoài cũng không gọi được.

Ba lưu ý khi VPC không có đường ra Internet: | Lưu ý | Chi tiết | |---|---| | Cần endpoint cho MỌI dịch vụ AWS dùng tới | SSM, ECR, CloudWatch Logs... | | Gateway endpoint cho S3 là bắt buộc | ECR lưu layer image trong S3 | | Kiểm tra bằng cách thử gọi | dễ sót một dịch vụ |

Ba lưu ý về cạm bẫy của aws:SourceIp: | Cạm bẫy | Chi tiết | |---|---| | KHÔNG hoạt động qua VPC endpoint | dùng aws:SourceVpce thay | | Chính sách chặn theo IP có thể chặn nhầm | khi chuyển sang endpoint | | Nhớ kiểm tra lại chính sách hiện có | |

Ba lợi ích bảo mật của PrivateLink: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | | | Không cần Internet Gateway hay NAT | giảm bề mặt tấn công | | Kiểm soát chi tiết bằng endpoint policy | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesProcessed | lưu lượng qua endpoint | | ActiveConnections | số kết nối | | PacketsDropped | gói bị bỏ |

Và một lời khuyên: hãy liệt kê mọi dịch vụ AWS mà ứng dụng gọi tới trước khi bỏ NAT Gateway. Rất dễ sót một dịch vụ ít dùng — ví dụ Secrets Manager chỉ gọi lúc khởi động — và phát hiện ra điều đó khi ứng dụng không khởi động được ở môi trường sản xuất là tình huống không dễ chịu.

Đáp án

A, D và E.

• A — Sao chép AMI dựa trên snapshot ĐÃ MÃ HOÁ thì KHÔNG thể cho ra snapshot đích chưa mã hoá
• D — CÓ THỂ chia sẻ AMI với tài khoản AWS khác
• E — CÓ THỂ sao chép AMI giữa các Region

Vì sao đúng

Ba đáp án mô tả ba khả năng cốt lõi của AMI:

E — sao chép xuyên Region:

aws ec2 copy-image --source-region us-east-1   --source-image-id ami-0abc123 --region eu-west-1 --name "ban-sao"

Sao chép AMI cũng SAO CHÉP snapshot nền
    → AMI mới có ID KHÁC ở Region đích
    → dùng để chuẩn hoá instance giữa các Region

D — chia sẻ với tài khoản khác:

aws ec2 modify-image-attribute --image-id ami-0abc   --launch-permission "Add=[{UserId=444455556666}]"

# BẮT BUỘC chia sẻ CẢ snapshot nền
aws ec2 modify-snapshot-attribute --snapshot-id snap-0abc   --attribute createVolumePermission   --operation-type add --user-ids 444455556666

Thiếu bước thứ hai là tài khoản kia thấy AMI nhưng khởi động thất bại.

A — mã hoá chỉ đi theo một chiều:

Quy tắc mã hoá khi sao chép AMI và snapshot:
    chưa mã hoá → chưa mã hoá   ✓
    chưa mã hoá → ĐÃ mã hoá     ✓ (thêm --kms-key-id)
    ĐÃ mã hoá  → ĐÃ mã hoá      ✓ (đổi khoá được)
    ĐÃ mã hoá  → CHƯA mã hoá    ✗ KHÔNG BAO GIỜ

Đây là ràng buộc bảo mật cố ý:

Nếu cho phép gỡ mã hoá bằng thao tác sao chép
    → bất kỳ ai có quyền sao chép đều gỡ được bảo vệ
        ↓
    AWS chặn hoàn toàn chiều này

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

• **C. Sao chép AMI dựa trên snapshot đã mã hoá CHO RA snapshot chưa mã hoá — đây là phương án gần nhất và là bẫy chính: nó đảo ngược đáp án A. Mã hoá không gỡ được bằng thao tác sao chép.
• **B. KHÔNG THỂ sao chép AMI giữa các Region — sai, đảo ngược E.
• **F. KHÔNG THỂ chia sẻ AMI với tài khoản khác — sai, đảo ngược D.

Ghi nhớ

Quy tắc mã hoá khi sao chép — bảng phải thuộc: | Nguồn | Đích | Được không | |---|---|---| | Chưa mã hoá | chưa mã hoá | ✅ | | Chưa mã hoá | đã mã hoá | ✅ thêm --encrypted --kms-key-id | | Đã mã hoá | đã mã hoá (đổi khoá) | ✅ | | Đã mã hoá | CHƯA mã hoá | ❌ KHÔNG BAO GIỜ |

Sao chép là cách duy nhất THÊM mã hoá cho AMI hoặc snapshot chưa mã hoá:

aws ec2 copy-image --source-region us-east-1 --source-image-id ami-0abc   --region us-east-1 --name "ban-ma-hoa"   --encrypted --kms-key-id arn:aws:kms:us-east-1:123456789012:key/abc

Ba mức chia sẻ AMI: | Mức | Chi tiết | |---|---| | Riêng tư (mặc định) | chỉ tài khoản sở hữu | | Chia sẻ với tài khoản cụ thể | ← câu này | | Công khai | mọi tài khoản AWS — cẩn thận |

Ba lưu ý khi chia sẻ AMI: | Lưu ý | Chi tiết | |---|---| | Phải chia sẻ CẢ snapshot nền | thiếu là khởi động thất bại | | AMI mã hoá bằng khoá aws/ebs KHÔNG chia sẻ được | phải dùng customer managed key | | Phải chia sẻ cả khoá KMS | qua key policy |

Dòng giữa là ràng buộc hay gây bất ngờ:

Khoá AWS managed (aws/ebs):
    → không sửa được key policy
    → không chia sẻ được
        ↓
    Muốn chia sẻ AMI mã hoá: phải dùng customer managed key

Chia sẻ khoá KMS:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::444455556666:root"},
 "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant",
            "kms:ReEncrypt*", "kms:GenerateDataKey*"],
 "Resource": "*"}

Phạm vi của các tài nguyên EC2 — bảng cần thuộc: | Tài nguyên | Phạm vi | |---|---| | AMI | REGION | | Snapshot EBS | REGION | | EBS volume | AVAILABILITY ZONE | | Instance | AZ | | Security group, key pair | Region (VPC) | | IAM | TOÀN CẦU |

Ba lưu ý khi sao chép AMI xuyên Region: | Lưu ý | Chi tiết | |---|---| | AMI mới có ID KHÁC | tự động hoá phải tra lại theo Region | | Khoá KMS có phạm vi REGION | phải khai khoá của Region đích | | Tốn phí truyền dữ liệu | với AMI lớn thì đáng kể |

Dòng giữa là nguồn lỗi phổ biến:

aws ec2 copy-image --source-region us-east-1 --source-image-id ami-0abc   --region eu-west-1 --name "ban-sao"   --encrypted --kms-key-id arn:aws:kms:eu-west-1:123456789012:key/xyz

Khoá phải thuộc Region ĐÍCH — khoá của Region nguồn không dùng được.

Ba cách quản lý AMI ở quy mô lớn: | Cách | Chi tiết | |---|---| | EC2 Image Builder | tự dựng, kiểm thử, phân phối AMI theo lịch | | SSM Parameter Store | lưu id AMI mới nhất theo tên chuẩn | | Data Lifecycle Manager | tự tạo và dọn snapshot |

EC2 Image Builder rất phù hợp với tình huống trong đề:

aws imagebuilder create-distribution-configuration   --name phan-phoi-da-region   --distributions '[
    {"region":"ap-northeast-1","amiDistributionConfiguration":{
      "targetAccountIds":["444455556666"]}},
    {"region":"eu-west-1","amiDistributionConfiguration":{
      "targetAccountIds":["444455556666"]}}]'

Image Builder tự:
    ✓ dựng AMI theo công thức
    ✓ kiểm thử
    ✓ SAO CHÉP sang nhiều Region
    ✓ CHIA SẺ với nhiều tài khoản
        ↓
    Giải quyết đúng bài toán chuẩn hoá của công ty đa quốc gia

Và Parameter Store cho tự động hoá:

aws ssm get-parameter --name /cong-ty/ami/chuan/moi-nhat   --query Parameter.Value --output text

Launch template trỏ vào parameter thay vì id cứng — cập nhật AMI chỉ cần đổi giá trị.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | AMI bản thân | MIỄN PHÍ | | Snapshot nền | ~0,05 USD/GB-tháng, ở MỖI Region | | Truyền dữ liệu khi sao chép | tính một lần |

Ba việc nên làm định kỳ: | Việc | Chi tiết | |---|---| | Dọn AMI cũ VÀ snapshot của chúng | huỷ đăng ký AMI không tự xoá snapshot | | Rà soát AMI đang chia sẻ ra ngoài | IAM Access Analyzer | | Kiểm tra không có AMI công khai ngoài ý muốn | AWS Config rule |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "ami-khong-duoc-cong-khai",
  "Source": {"Owner":"AWS","SourceIdentifier":"EC2_AMI_PUBLIC_ACCESS_CHECK"}}'

Và một lời khuyên: hãy dùng EC2 Image Builder thay vì sao chép và chia sẻ AMI thủ công. Với công ty đa quốc gia có nhiều tài khoản và nhiều Region, việc giữ AMI đồng bộ bằng tay sẽ nhanh chóng trở nên không kiểm soát được — và Image Builder biến nó thành một tệp cấu hình chạy theo lịch.

Đáp án

D — Dùng Amazon Kinesis Data Streams để nạp dữ liệu, xử lý bằng Lambda hoặc chạy phân tích bằng Kinesis Data Analytics.

Vì sao đúng

Đề nêu bốn yêu cầu, và Kinesis Data Streams là lựa chọn duy nhất thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | Dữ liệu sức khoẻ THỜI GIAN THỰC | Kinesis nạp và xử lý theo luồng | | Có cơ chế THỬ LẠI | dữ liệu giữ trong stream, đọc lại được | | Đưa vào quy trình PHÂN TÍCH | Kinesis Data Analytics truy vấn luồng bằng SQL | | Mở rộng được, ít công triển khai | dịch vụ được quản lý |

Vế "cơ chế thử lại" là điểm mấu chốt:

Hệ thống hiện tại không có retry
    → dữ liệu bệnh nhân bị mất khi xử lý hỏng
        ↓
Kinesis Data Streams:
    → dữ liệu GIỮ LẠI trong stream 24 giờ (tới 365 ngày)
    → consumer đọc lại từ vị trí bất kỳ
    → xử lý hỏng thì thử lại từ checkpoint

Và khả năng ĐỌC LẠI là thứ SQS không có:

SQS: thông điệp bị XOÁ sau khi consumer xác nhận
    → không đọc lại được

Kinesis: dữ liệu nằm trong stream tới hết thời gian giữ
    → đọc lại bao nhiêu lần cũng được
    → nhiều consumer độc lập

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

Thiết bị y tế → Kinesis Data Streams
                    ├── Lambda (xử lý và cảnh báo thời gian thực)
                    ├── Kinesis Data Analytics (truy vấn SQL trên luồng)
                    └── Kinesis Data Firehose → S3 (lưu trữ để phân tích sau)

aws kinesis create-stream --stream-name du-lieu-suc-khoe   --stream-mode-details StreamMode=ON_DEMAND

Chế độ on-demand tự co giãn — không phải tính số shard.

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

• **A. Dùng SQS để nạp dữ liệu và Lambda xử lý — đây là phương án gần nhất và thực sự có cơ chế thử lại và mở rộng tốt, nhưng nó kém phù hợp với phân tích thời gian thực: SQS không đọc lại được dữ liệu đã xử lý, không hỗ trợ nhiều consumer độc lập, và không có công cụ phân tích luồng như Kinesis Data Analytics.
• **C. Dùng SNS để nạp dữ liệu — không lưu bền: SNS là mô hình đẩy, subscriber không nhận được thì thông điệp mất. Không có cơ chế thử lại theo nghĩa giữ dữ liệu.
• **B. Dùng API Gateway với giao diện REST hiện có — không giải quyết vấn đề gốc: API Gateway là cổng vào, nó không cung cấp vùng đệm hay cơ chế thử lại cho việc xử lý phía sau.

Ghi nhớ

Bốn dịch vụ nạp dữ liệu — bảng phải thuộc: | Dịch vụ | Đọc lại được | Nhiều consumer | Thứ tự | |---|---|---|---| | Kinesis Data Streams | ✅ tới 365 ngày | ✅ độc lập | ✅ trong shard | | SQS Standard | ❌ | ❌ một consumer nhận | ❌ | | SQS FIFO | ❌ | ❌ | ✅ trong group | | SNS | ❌ | ✅ phát tán | ❌ |

Từ khoá nhận diện:

"real-time analytics", "replay", "multiple consumers", "streaming" → Kinesis Data Streams "decouple", "buffer", "simple" → SQS "fan-out notifications" → SNS "deliver to S3/Redshift/OpenSearch" → Kinesis Data Firehose

Ba dịch vụ trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Data Streams | nạp và GIỮ luồng, nhiều consumer ← câu này | | Data Firehose | giao thẳng vào S3, Redshift, OpenSearch — KHÔNG giữ lại | | Managed Service for Apache Flink | phân tích luồng bằng SQL hoặc Java | | Video Streams | luồng video |

(Kinesis Data Analytics nay được gọi là Amazon Managed Service for Apache Flink.)

Ba đặc điểm của Kinesis Data Streams: | Đặc điểm | Chi tiết | |---|---| | Shard là đơn vị thông lượng | 1 MB/giây ghi, 2 MB/giây đọc mỗi shard | | Giữ dữ liệu 24 giờ mặc định | mở rộng tới 365 ngày | | Nhiều consumer đọc ĐỘC LẬP | mỗi cái có vị trí đọc riêng |

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | bạn chọn số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn, không phải tính toán |

Với ứng dụng y tế có lượng người dùng tăng nhanh, on-demand là lựa chọn an toàn.

Ba lưu ý khi chọn partition key: | Lưu ý | Chi tiết | |---|---| | Phân bố ĐỀU giữa các shard | key lệch tạo "hot shard" | | Cùng key = cùng shard = giữ thứ tự | dùng mã bệnh nhân | | Số key phải nhiều hơn số shard | |

Hot shard là vấn đề hiệu năng phổ biến nhất:

Dùng "loai-thiet-bi" làm partition key với 3 loại và 10 shard
    → chỉ 3 shard nhận dữ liệu
    → thông lượng thực tế chỉ 30% năng lực đã trả tiền

Ba cấu hình của Lambda event source mapping với Kinesis: | Cấu hình | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi | | ParallelizationFactor | xử lý song song tới 10 lô trên MỘT shard | | MaximumRetryAttempts | tránh "poison pill" chặn cả shard |

Poison pill là bẫy kinh điển:

Một bản ghi gây lỗi
    → Lambda thử lại MÃI MÃI
    → shard đó KẸT HOÀN TOÀN
        ↓
    → Đặt MaximumRetryAttempts và on-failure destination

aws lambda update-event-source-mapping --uuid <id>   --maximum-retry-attempts 3 --bisect-batch-on-function-error   --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge | bản ghi nằm trong stream bao lâu — tăng = xử lý không kịp | | WriteProvisionedThroughputExceeded | producer bị throttle | | GetRecords.Success | consumer đọc thành công |

IteratorAge là metric quan trọng nhất:

IteratorAge tăng dần và vượt thời gian giữ dữ liệu
    → MẤT DỮ LIỆU VĨNH VIỄN
    → và không có lỗi nào báo

Ba lưu ý cho dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc pháp lý cho PHI | | Mã hoá at rest bằng KMS | bật trên stream | | Mã hoá in transit | HTTPS mặc định |

aws kinesis start-stream-encryption --stream-name du-lieu-suc-khoe   --encryption-type KMS --key-id alias/aws/kinesis

Ba lựa chọn consumer: | Consumer | Đặc điểm | |---|---| | Lambda | đơn giản nhất, tự co giãn | | Managed Service for Apache Flink | phân tích luồng phức tạp | | KCL trên EC2/ECS | kiểm soát nhiều nhất |

Và một lời khuyên: hãy đặt alarm cho IteratorAge ngay từ đầu. Với dữ liệu sức khoẻ thời gian thực, việc xử lý tụt lại phía sau không chỉ là vấn đề hiệu năng — nếu độ trễ vượt thời gian giữ dữ liệu, bạn mất vĩnh viễn dữ liệu bệnh nhân mà không có bất kỳ thông báo lỗi nào.

Đáp án

C — Cấu hình Amazon SQS queue để tách rời microservice chạy tiến trình NHANH khỏi microservice chạy tiến trình CHẬM.

Vì sao đúng

Đề mô tả chính xác bài toán mà hàng đợi giải quyết: hai bên có TỐC ĐỘ XỬ LÝ KHÁC NHAU.

Không có hàng đợi:
    Dịch vụ nhanh gọi trực tiếp dịch vụ chậm
        → phải CHỜ dịch vụ chậm trả lời
        → dịch vụ nhanh bị kéo xuống theo
        → dịch vụ chậm quá tải khi có đỉnh tải

Có SQS ở giữa:

Dịch vụ nhanh → SQS → dịch vụ chậm
        ↓
    ✓ dịch vụ nhanh gửi rồi tiếp tục ngay
    ✓ hàng đợi hấp thụ chênh lệch tốc độ
    ✓ dịch vụ chậm xử lý theo năng lực của mình
    ✓ dịch vụ chậm ngừng thì thông điệp vẫn nằm đó

Đây là mẫu "queue-based load levelling" — hàng đợi làm phẳng chênh lệch giữa tốc độ sản xuất và tốc độ tiêu thụ.

Và SQS phù hợp vì mô hình một–một:

Microservice A gửi công việc cho microservice B
    → MỘT người nhận
    → mỗi thông điệp được xử lý MỘT lần
        ↓
    Đó là mô hình HÀNG ĐỢI, không phải phát tán

Cấu hình co giãn dịch vụ chậm theo độ sâu hàng đợi:

aws cloudwatch put-metric-alarm --alarm-name hang-doi-day   --metric-name ApproximateNumberOfMessagesVisible   --namespace AWS/SQS --dimensions Name=QueueName,Value=cong-viec-cham   --statistic Average --period 300 --threshold 1000   --comparison-operator GreaterThanThreshold

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

• **D. Dùng Amazon SNS để tách rời — đây là phương án gần nhất và cũng là dịch vụ nhắn tin tách rời, nhưng nó sai mô hình: SNS là phát tán (pub/sub), đẩy thông điệp tới mọi subscriber. Nó không lưu bền — subscriber không nhận được thì thông điệp mất, và không có vùng đệm để hấp thụ chênh lệch tốc độ.
• **B. Dùng Amazon EventBridge — là bus định tuyến sự kiện, phù hợp cho kiến trúc hướng sự kiện với nhiều nguồn và nhiều đích theo quy tắc. Nó không phải vùng đệm cho chênh lệch tốc độ giữa hai dịch vụ cụ thể.
• **A. Dùng Kinesis Data Streams — quá nặng cho bài toán này: Kinesis dành cho luồng dữ liệu lớn cần đọc lại và nhiều consumer độc lập. Với việc tách rời hai microservice, nó phức tạp hơn cần thiết và đòi quản lý shard.

Ghi nhớ

Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Lưu bền | Dùng khi | |---|---|---|---| | SQS | hàng đợi, một consumer nhận | ✅ tới 14 ngày | tách rời, đệm tải ← câu này | | SNS | phát tán, nhiều subscriber | ❌ | thông báo tới nhiều nơi | | EventBridge | bus định tuyến theo quy tắc | ❌ | kiến trúc hướng sự kiện | | Kinesis Data Streams | luồng, đọc lại được | ✅ | phân tích thời gian thực |

Từ khoá nhận diện:

"decouple", "buffer", "different processing speeds", "one consumer" → SQS "fan-out to multiple subscribers" → SNS "route events by rules", "SaaS integration" → EventBridge "real-time analytics", "replay", "multiple independent consumers" → Kinesis

Và mẫu SNS + SQS rất phổ biến:

SNS topic
    ├─▶ SQS queue A → dịch vụ A
    ├─▶ SQS queue B → dịch vụ B
    └─▶ SQS queue C → dịch vụ C
        ↓
    Phát tán tới nhiều dịch vụ
    Mỗi dịch vụ có vùng đệm riêng
    Lỗi ở một nhánh không ảnh hưởng nhánh khác

Ba lợi ích của việc tách rời bằng hàng đợi: | Lợi ích | Chi tiết | |---|---| | Hấp thụ chênh lệch tốc độ | ← câu này | | Chịu lỗi | dịch vụ chậm ngừng thì thông điệp vẫn còn | | Co giãn độc lập | mỗi bên mở rộng theo nhu cầu riêng |

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

SQS Standard và FIFO: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như không giới hạn | có hạn mức | | Thứ tự | không đảm bảo | ✅ trong group | | Trùng lặp | có thể | ❌ |

Với việc tách rời microservice thông thường, Standard là đủ — trừ khi thứ tự xử lý quan trọng.

Ba cách co giãn consumer theo hàng đợi: | Metric | Đặc điểm | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | Backlog mỗi instance | chuẩn xác nhất cho target tracking | | ApproximateAgeOfOldestMessage | cảnh báo khi xử lý không kịp |

Công thức backlog mỗi instance:

Backlog mỗi instance = số thông điệp chờ ÷ số instance đang chạy
    → đặt target tracking giữ con số này ở mức mong muốn

Ba nguyên tắc thiết kế microservice tách rời: | Nguyên tắc | Chi tiết | |---|---| | Giao tiếp bất đồng bộ khi có thể | qua hàng đợi hoặc sự kiện | | Idempotency ở tầng nghiệp vụ | thông điệp có thể được giao hai lần | | Timeout và circuit breaker cho lời gọi đồng bộ | |

Idempotency là bắt buộc với SQS Standard:

def xu_ly(thong_diep):
    ma = thong_diep['ma_cong_viec']
    if da_xu_ly(ma):        # kiểm tra trong DynamoDB hoặc database
        return
    thuc_hien(thong_diep)
    danh_dau_da_xu_ly(ma)

Ba lựa chọn cho consumer: | Lựa chọn | Đặc điểm | |---|---| | Lambda với SQS event source | ít công nhất, tự co giãn | | ECS hoặc EC2 với ASG | cho việc chạy lâu quá 15 phút | | Fargate | container, không quản lý máy |

Ba metric cần đặt alarm: | Metric | Ngưỡng | |---|---| | ApproximateAgeOfOldestMessage | vượt SLA xử lý | | Số thông điệp trong DLQ | > 0 | | Độ sâu hàng đợi | tăng liên tục |

Ba bước chuyển từ monolith sang microservice: | Bước | Chi tiết | |---|---| | Tách dần từng chức năng | không viết lại toàn bộ cùng lúc | | Đặt hàng đợi giữa các dịch vụ mới | ← điểm của câu này | | Giữ monolith chạy song song | chuyển lưu lượng dần |

Và một lời khuyên: hãy đặt dead-letter queue ngay khi tạo hàng đợi, không để sau. Khi microservice chậm gặp lỗi với một loại thông điệp cụ thể, DLQ giữ chúng lại để bạn xem xét — còn không có DLQ thì thông điệp sẽ quay vòng mãi và cuối cùng bị xoá khi hết thời gian giữ, mất luôn dấu vết của lỗi.

Đáp án

B và D.

• B — Instance được khôi phục giống hệt instance gốc, gồm cả instance ID, IP riêng, Elastic IP và mọi metadata
• D — Nếu instance có địa chỉ IPv4 công cộng, nó GIỮ NGUYÊN địa chỉ đó sau khi khôi phục

Vì sao đúng

Hai đáp án mô tả đúng điều làm auto-recovery khác với việc tạo instance mới:

B — mọi thứ được giữ nguyên:

Khôi phục = khởi động lại instance TRÊN PHẦN CỨNG KHÁC
    ✓ instance ID không đổi
    ✓ IP riêng không đổi
    ✓ Elastic IP vẫn gắn
    ✓ EBS volume và dữ liệu nguyên vẹn
    ✓ metadata, placement group giữ nguyên
        ↓
    Ứng dụng và cấu hình DNS không phải sửa gì

D — kể cả IP công cộng tự động cũng được giữ:

Thông thường, stop rồi start một instance:
    → IP công cộng TỰ ĐỘNG bị thu hồi và cấp mới

Nhưng auto-recovery thì KHÁC:
    → IPv4 công cộng ĐƯỢC GIỮ NGUYÊN
        ↓
    Đây là điểm phân biệt quan trọng với stop/start thủ công

Và một thứ KHÔNG được giữ:

Dữ liệu trong RAM MẤT
    → instance khởi động lại như sau khi stop/start
    → ứng dụng phải chịu được việc khởi động lại

Cấu hình alarm khôi phục:

aws cloudwatch put-metric-alarm --alarm-name khoi-phuc-instance   --metric-name StatusCheckFailed_System --namespace AWS/EC2   --dimensions Name=InstanceId,Value=i-0abc   --statistic Maximum --period 60 --threshold 1   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 2   --alarm-actions arn:aws:automate:ap-northeast-1:ec2:recover

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

• **C. Nếu instance có IPv4 công cộng thì nó KHÔNG giữ địa chỉ đó sau khôi phục — đây là phương án gần nhất và là bẫy chính: nó đúng với stop/start thủ công nhưng sai với auto-recovery. Auto-recovery giữ nguyên IP công cộng.
• **E. Trong quá trình khôi phục, instance được di chuyển qua một lần reboot và dữ liệu trong RAM ĐƯỢC GIỮ — sai: dữ liệu RAM MẤT. Muốn giữ RAM thì phải dùng hibernate, không phải auto-recovery.
• **A. Instance đã bị TERMINATE có thể khôi phục nếu cấu hình lúc khởi động — không làm được: terminate là thao tác vĩnh viễn. Auto-recovery chỉ áp cho instance bị lỗi phần cứng, không cho instance đã bị chấm dứt.

Ghi nhớ

Ba trạng thái dừng của EC2 — bảng phải thuộc: | Trạng thái | RAM | IP công cộng tự động | Khôi phục lại được | |---|---|---|---| | Reboot | giữ nguyên | giữ | ✅ | | Auto-recovery | MẤT | GIỮ NGUYÊN | ✅ | | Stop/Start thủ công | MẤT | THU HỒI, cấp IP mới | ✅ | | Hibernate | LƯU vào EBS | thu hồi | ✅ | | Terminate | mất | mất | ❌ vĩnh viễn |

Dòng thứ hai và ba là điểm phân biệt của câu hỏi này.

Hai status check của EC2: | Check | Kiểm tra gì | Auto-recovery phản ứng | |---|---|---| | StatusCheckFailed_System | phần cứng, mạng, nguồn của MÁY CHỦ VẬT LÝ | ✅ | | StatusCheckFailed_Instance | hệ điều hành, cấu hình mạng, đĩa đầy | ❌ |

Auto-recovery CHỈ phản ứng với system check — đây là giới hạn quan trọng nhất.

Ba điều kiện của auto-recovery: | Điều kiện | Chi tiết | |---|---| | CHỈ dùng EBS volume | không có instance store | | Loại instance được hỗ trợ | hầu hết thế hệ hiện hành | | Không phải Dedicated Host hoặc Spot | |

Lưu ý quan trọng: AWS đã bật auto-recovery MẶC ĐỊNH.

Từ tháng 3 năm 2022, "simplified automatic recovery"
    → bật MẶC ĐỊNH cho hầu hết loại instance đủ điều kiện
        ↓
    Kiểm tra bằng:

aws ec2 describe-instances --instance-ids i-0abc   --query 'Reservations[].Instances[].MaintenanceOptions.AutoRecovery'

Giá trị default nghĩa là đã bật. (Alarm thủ công vẫn hữu ích khi cần tuỳ chỉnh ngưỡng hoặc thêm thông báo.)

Bốn hành động của CloudWatch alarm cho EC2: | Hành động | ARN | |---|---| | Recover | arn:aws:automate:<region>:ec2:recover | | Stop | arn:aws:automate:<region>:ec2:stop | | Terminate | arn:aws:automate:<region>:ec2:terminate | | Reboot | arn:aws:automate:<region>:ec2:reboot |

Nên thêm thông báo SNS song song:

--alarm-actions arn:aws:automate:ap-northeast-1:ec2:recover                 arn:aws:sns:ap-northeast-1:123456789012:canh-bao

Để biết đã có sự cố, không chỉ để nó tự khắc phục im lặng.

Ba cơ chế phục hồi — theo mức độ: | Cơ chế | Phục hồi được gì | |---|---| | EC2 auto-recovery | lỗi phần cứng của máy chủ | | ASG (min=max=1) với HealthCheckType=ELB | lỗi phần cứng VÀ lỗi ứng dụng | | ASG nhiều máy + ALB | mọi thứ, không gián đoạn |

Khác biệt quan trọng giữa auto-recovery và ASG:

Auto-recovery:
    ✓ giữ instance ID, IP, dữ liệu EBS
    ✗ không phát hiện lỗi ứng dụng

ASG thay instance:
    ✓ phát hiện cả lỗi ứng dụng (với health check ELB)
    ✗ instance MỚI có ID và IP khác, dữ liệu EBS gốc không theo

Ba lưu ý về IP công cộng của EC2: | Loại IP | Hành vi | |---|---| | IPv4 công cộng tự động | thu hồi khi stop/start, GIỮ khi auto-recovery | | Elastic IP | giữ trong mọi trường hợp | | IP riêng | luôn giữ nguyên trong vòng đời instance |

Với ứng dụng cần địa chỉ ổn định, luôn dùng Elastic IP — không phụ thuộc vào hành vi của IP tự động.

Ba việc nên làm cho ứng dụng đơn lẻ: | Việc | Chi tiết | |---|---| | Xác nhận auto-recovery đang bật | | | Đảm bảo ứng dụng tự khởi động cùng OS | systemctl enable | | Chụp snapshot EBS định kỳ | Data Lifecycle Manager |

Dòng giữa rất quan trọng: khôi phục instance mà ứng dụng không tự chạy lại thì máy lên nhưng dịch vụ vẫn ngừng.

Ba metric nên đặt alarm: | Metric | Ý nghĩa | |---|---| | StatusCheckFailed_System | kích hoạt khôi phục | | StatusCheckFailed_Instance | cảnh báo lỗi OS | | Metric ứng dụng tuỳ chỉnh | phát hiện lỗi mức ứng dụng |

Và một lời khuyên: hãy kiểm chứng ứng dụng khởi động lại được sạch sẽ bằng cách stop rồi start instance trong giờ thấp điểm. Auto-recovery về bản chất là một lần khởi động lại — và nếu ứng dụng cần thao tác thủ công để chạy lại, cơ chế khôi phục tự động sẽ đưa máy lên nhưng dịch vụ vẫn ngừng.

Đáp án

C — Dùng Amazon Kinesis Data Streams để xử lý luồng dữ liệu và tách rời producer khỏi consumer.

Vì sao đúng

Đề nêu một cụm từ quyết định: "xây ứng dụng TUỲ CHỈNH để xử lý và phân tích dữ liệu luồng".

"build CUSTOM APPLICATIONS that process and analyze the streaming data
 for its SPECIALIZED NEEDS"
        ↓
    Cần toàn quyền kiểm soát logic xử lý
    → Kinesis Data Streams cho phép viết consumer riêng

Và Kinesis Data Streams là dịch vụ duy nhất trong các phương án cho điều đó:

Kinesis Data Streams:
    ✓ giữ dữ liệu 24 giờ tới 365 ngày
    ✓ NHIỀU consumer đọc ĐỘC LẬP
    ✓ đọc lại được từ vị trí bất kỳ
    ✓ bạn viết ứng dụng xử lý theo cách của mình
        ↓
    Vừa tách rời producer và consumer
    vừa cho toàn quyền với logic xử lý

So với Firehose:

Kinesis Data Firehose:
    → giao thẳng vào S3, Redshift, OpenSearch, Splunk
    → CHỈ biến đổi được bằng Lambda ở mức đơn giản
    → KHÔNG giữ lại dữ liệu để đọc lại
        ↓
    Không phù hợp cho "ứng dụng tuỳ chỉnh"

Cấu hình:

aws kinesis create-stream --stream-name luong-du-lieu   --stream-mode-details StreamMode=ON_DEMAND

Và nhiều ứng dụng đọc độc lập:

Kinesis Data Streams
    ├── Ứng dụng A (phát hiện bất thường) — vị trí đọc riêng
    ├── Ứng dụng B (tính toán tổng hợp)  — vị trí đọc riêng
    └── Ứng dụng C (lưu vào kho dữ liệu)  — vị trí đọc riêng
        ↓
    Mỗi ứng dụng đọc TOÀN BỘ luồng theo tốc độ của mình

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

• **A. Dùng Kinesis Data Firehose — đây là phương án gần nhất và cùng họ Kinesis, nhưng nó không cho xây ứng dụng tuỳ chỉnh: Firehose là dịch vụ giao hàng, nó nạp dữ liệu rồi đẩy thẳng vào đích được hỗ trợ. Không giữ lại dữ liệu, không cho nhiều consumer độc lập.
• **D. Dùng SQS — không phù hợp cho xử lý luồng: SQS xoá thông điệp sau khi consumer xác nhận, không đọc lại được, và không hỗ trợ nhiều consumer độc lập cùng đọc toàn bộ dữ liệu.
• **B. Dùng SNS — không lưu bền và không có khái niệm luồng: SNS đẩy thông báo tới subscriber, không giữ dữ liệu và không cho phân tích theo thứ tự.

Ghi nhớ

Ba dịch vụ trong họ Kinesis — bảng phải thuộc: | Dịch vụ | Việc | Giữ dữ liệu | |---|---|---| | Data Streams | nạp luồng, NHIỀU consumer tuỳ chỉnh | ✅ 24 giờ – 365 ngày | | Data Firehose | giao thẳng vào S3, Redshift, OpenSearch | ❌ | | Managed Service for Apache Flink | phân tích luồng bằng SQL hoặc Java | qua nguồn |

Từ khoá nhận diện:

"custom applications", "process and analyze", "multiple consumers", "replay" → Data Streams "deliver to S3/Redshift/OpenSearch", "no code" → Data Firehose "SQL on streaming data", "windowed aggregation" → Managed Service for Apache Flink

Data Streams và Firehose — bảng phân biệt: | | Data Streams | Data Firehose | |---|---|---| | Giữ dữ liệu | ✅ đọc lại được | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Quản lý shard | có (hoặc on-demand) | KHÔNG — tự co giãn | | Độ trễ | ~200ms (real-time) | tối thiểu 60 giây (near real-time) | | Đích | consumer tự viết | S3, Redshift, OpenSearch, Splunk, HTTP | | Công vận hành | cao hơn | thấp nhất |

Ba đặc điểm của Data Streams: | Đặc điểm | Chi tiết | |---|---| | Shard là đơn vị thông lượng | 1 MB/giây ghi, 2 MB/giây đọc mỗi shard | | Thứ tự đảm bảo trong shard | qua partition key | | Nhiều consumer | mỗi cái có vị trí đọc riêng |

Hai chế độ dung lượng: | Chế độ | Đặc điểm | |---|---| | Provisioned | chọn số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/giây, không phải tính toán |

Hai loại consumer: | Loại | Đặc điểm | |---|---| | Shared throughput (mặc định) | 2 MB/giây CHIA SẺ giữa mọi consumer của shard | | Enhanced fan-out | 2 MB/giây RIÊNG cho mỗi consumer, độ trễ ~70ms |

Enhanced fan-out quan trọng khi có nhiều ứng dụng:

5 consumer đọc chung một shard (shared):
    → mỗi cái chỉ được ~400 KB/giây
    → và độ trễ tăng

Enhanced fan-out:
    → mỗi consumer có 2 MB/giây riêng
    → độ trễ thấp hơn
    → đổi lại: có phí thêm

aws kinesis register-stream-consumer   --stream-arn <arn-stream> --consumer-name ung-dung-a

Ba cách viết consumer: | Cách | Đặc điểm | |---|---| | Lambda với event source mapping | đơn giản nhất | | Kinesis Client Library (KCL) | tự quản lý checkpoint và phân chia shard | | SDK trực tiếp | kiểm soát nhiều nhất, phức tạp nhất |

KCL là lựa chọn chuẩn cho ứng dụng tuỳ chỉnh:

KCL tự lo:
    ✓ phân chia shard giữa các worker
    ✓ lưu checkpoint vào DynamoDB
    ✓ xử lý khi shard tách hoặc gộp
    ✓ cân bằng lại khi thêm bớt worker

Ba lưu ý khi chọn partition key: | Lưu ý | Chi tiết | |---|---| | Phân bố ĐỀU giữa các shard | key lệch tạo "hot shard" | | Cùng key = cùng shard = giữ thứ tự | | | Số key nhiều hơn số shard | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAge | bản ghi nằm bao lâu — tăng = xử lý không kịp | | WriteProvisionedThroughputExceeded | producer bị throttle | | ReadProvisionedThroughputExceeded | consumer bị throttle |

IteratorAge là metric quan trọng nhất:

IteratorAge vượt thời gian giữ dữ liệu
    → MẤT DỮ LIỆU VĨNH VIỄN
    → và không có lỗi nào báo

Ba cách gửi dữ liệu vào stream: | Cách | Đặc điểm | |---|---| | Kinesis Producer Library (KPL) | gom lô, thử lại, hiệu quả nhất | | SDK PutRecords | gửi tới 500 bản ghi mỗi lần | | Kinesis Agent | đọc tệp log và gửi tự động |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Shard-giờ (provisioned) | ~0,015 USD/shard/giờ | | PUT payload unit | theo đơn vị 25 KB | | Enhanced fan-out | tính theo consumer-shard-giờ | | Thời gian giữ dữ liệu kéo dài | phí thêm |

Ba lựa chọn kết hợp phổ biến:

Kinesis Data Streams (nạp và giữ)
    ├── ứng dụng tuỳ chỉnh (KCL hoặc Lambda) — xử lý thời gian thực
    ├── Managed Service for Apache Flink — phân tích cửa sổ
    └── Firehose → S3 — lưu trữ lâu dài

Và một lời khuyên: hãy bắt đầu với chế độ on-demand rồi chuyển sang provisioned khi đã hiểu rõ mẫu tải. Tính số shard đúng ngay từ đầu rất khó, và cấp thiếu shard sẽ gây throttle ở producer — thứ có thể dẫn tới mất dữ liệu nếu producer không xử lý lỗi cẩn thận.