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

Đáp án

C — Dựng bảng DynamoDB ở chế độ on-demand capacity mode.

Vì sao đúng

Đề nêu ba đặc điểm tải, và cả ba đều dẫn tới on-demand: | Đặc điểm | Kết luận | |---|---| | KHÔNG dùng vào ban đêm | provisioned vẫn tính tiền dù không dùng | | Lưu lượng KHÓ ĐOÁN ban ngày | không tính trước được số WCU/RCU | | Đỉnh tải xảy ra RẤT NHANH | auto scaling phản ứng không kịp |

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

Provisioned với auto scaling:
    → CloudWatch alarm phát hiện tải tăng
    → mất vài phút để điều chỉnh dung lượng
        ↓
    Đỉnh tải "xảy ra rất nhanh" → bị THROTTLE trước khi kịp mở rộng

On-demand:
    → tự thích ứng NGAY LẬP TỨC
    → không có ngưỡng, không có alarm, không có độ trễ

Và on-demand không tính tiền khi không dùng:

Ban đêm không có request:
    Provisioned: vẫn trả tiền cho WCU/RCU đã cấp
    On-demand:   trả 0 đồng

Tạo bảng ở chế độ on-demand:

aws dynamodb create-table --table-name chuyen-di   --attribute-definitions AttributeName=ma_chuyen,AttributeType=S   --key-schema AttributeName=ma_chuyen,KeyType=HASH   --billing-mode PAY_PER_REQUEST

Và on-demand mở rộng rất nhanh:

On-demand tự thích ứng tới GẤP ĐÔI đỉnh tải trước đó
    → và mở rộng thêm nếu tải tiếp tục tăng
        ↓
    Với tải tăng đột ngột hơn gấp đôi, vẫn có thể bị throttle tạm thời
    → nhưng nhanh hơn nhiều so với auto scaling của provisioned

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

• **B. Provisioned capacity mode với auto scaling — đây là phương án gần nhất và thực sự co giãn được, nhưng nó phản ứng quá chậm với đỉnh tải đột ngột: auto scaling dựa trên CloudWatch alarm, cần vài phút để điều chỉnh. Và nó vẫn tính tiền cho dung lượng tối thiểu suốt đêm.
• **A. Global table ở chế độ provisioned — giải quyết vấn đề khác: global table là sao chép đa Region, không liên quan tới việc co giãn theo tải. Và provisioned vẫn có vấn đề phản ứng chậm.
• **D. Bảng với global secondary index — cũng giải quyết vấn đề khác: GSI cho phép truy vấn theo thuộc tính khác khoá chính, không liên quan tới quản lý dung lượng.

Ghi nhớ

Hai chế độ dung lượng của DynamoDB — bảng phải thuộc: | | On-demand (PAY_PER_REQUEST) | Provisioned | |---|---|---| | Tính phí | theo REQUEST thực tế | theo WCU/RCU đã cấp | | Không dùng thì trả | 0 đồng | vẫn trả đủ | | Phản ứng với đỉnh tải | tức thì | chậm (auto scaling) | | Cần dự đoán tải | ❌ | ✅ | | Chi phí khi tải ổn định | cao hơn ~5–7 lần | thấp hơn |

Quy tắc chọn — rất hay được hỏi:

Tải KHÓ ĐOÁN, đỉnh đột ngột, hoặc mới bắt đầu → on-demand Tải ỔN ĐỊNH và dự đoán được → provisioned + auto scaling

Ba trường hợp dùng on-demand: | Trường hợp | Chi tiết | |---|---| | Tải khó đoán | ← câu này | | Ứng dụng mới, chưa biết mẫu tải | | | Tải rất thưa hoặc theo đợt | không trả tiền lúc nhàn rỗi |

Và đổi chế độ được:

aws dynamodb update-table --table-name chuyen-di   --billing-mode PROVISIONED   --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=100

Lưu ý: chỉ đổi được MỘT LẦN mỗi 24 giờ.

Ba đơn vị dung lượng của DynamoDB: | Đơn vị | Nghĩa | |---|---| | 1 RCU | 1 đọc nhất quán mạnh mỗi giây cho item tới 4 KB | | 1 RCU | hoặc 2 đọc nhất quán cuối cùng | | 1 WCU | 1 ghi mỗi giây cho item tới 1 KB |

Ba giới hạn cần nhớ: | Giới hạn | Giá trị | |---|---| | Kích thước item | 400 KB | | Thông lượng mỗi partition | 3.000 RCU hoặc 1.000 WCU | | Số GSI mỗi bảng | 20 |

Dòng giữa liên quan tới hot partition:

Một partition key nhận quá nhiều lưu lượng
    → vượt 3.000 RCU hoặc 1.000 WCU của partition đó
    → bị throttle dù bảng còn dung lượng
        ↓
    Adaptive capacity của DynamoDB giảm nhẹ vấn đề này,
    nhưng thiết kế khoá tốt vẫn là căn bản

Ba nguyên tắc thiết kế partition key: | Nguyên tắc | Chi tiết | |---|---| | Giá trị phân bố ĐỀU | tránh hot partition | | Số giá trị đủ nhiều | không dùng trường chỉ có vài giá trị | | Kết hợp với sort key | cho truy vấn theo khoảng |

Với ứng dụng gọi xe, mã chuyến đi hoặc mã tài xế là khoá tốt — phân bố tự nhiên.

Ba tính năng nên bật cho bảng sản xuất: | Tính năng | Chi tiết | |---|---| | Point-in-time recovery (PITR) | khôi phục về bất kỳ giây nào trong 35 ngày | | Deletion protection | chặn xoá bảng nhầm | | TTL | tự xoá dữ liệu cũ, MIỄN PHÍ |

aws dynamodb update-continuous-backups --table-name chuyen-di   --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

aws dynamodb update-table --table-name chuyen-di --deletion-protection-enabled

Ba cách theo dõi và tối ưu: | Cách | Việc | |---|---| | CloudWatch ConsumedReadCapacityUnits | mức dùng thật | | ThrottledRequests | bị giới hạn — cần xem lại dung lượng hoặc khoá | | Cost Explorer | so chi phí giữa hai chế độ |

Ba lưu ý khi chuyển từ on-demand sang provisioned: | Lưu ý | Chi tiết | |---|---| | Đo mức dùng thật vài tuần trước | | | Đặt auto scaling với biên độ rộng | | | Chỉ đổi khi tải đã ổn định | |

Và DynamoDB có chế độ warm throughput:

On-demand tự thích ứng tới gấp đôi đỉnh trước
    → nếu biết trước sẽ có đỉnh rất lớn (ví dụ chiến dịch)
    → khai trước warm throughput để chuẩn bị

Và một lời khuyên: hãy bắt đầu với on-demand cho mọi bảng mới, rồi so chi phí sau vài tháng. Nếu mức dùng hoá ra rất ổn định, chuyển sang provisioned tiết kiệm đáng kể — nhưng đoán sai theo chiều ngược lại (chọn provisioned rồi bị throttle vào giờ cao điểm) gây thiệt hại lớn hơn nhiều so với khoản tiền tiết kiệm được.

Đáp án

D — Dùng Auto Scaling Group.

Vì sao đúng

Đề cho một dữ kiện quyết định: nội dung RẤT ĐỘNG và thay đổi liên tục.

"content of your website is HIGHLY DYNAMIC and CHANGES VERY OFTEN"
        ↓
    Đệm ở CDN gần như vô dụng
    → mỗi request đều phải tới máy chủ ứng dụng
        ↓
    Cần THÊM MÁY CHỦ để chịu tải gấp 10 lần

Và Auto Scaling group làm đúng điều đó:

Auto Scaling group:
    ✓ tự thêm instance khi tải tăng
    ✓ tự bớt khi tải giảm
    ✓ thay instance hỏng
        ↓
    Hạ tầng co giãn theo lưu lượng thật

Chuẩn bị cho đợt bán hàng có lịch biết trước:

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-web   --scheduled-action-name mo-rong-truoc-flash-sale   --start-time 2026-09-05T01:00:00Z   --min-size 20 --desired-capacity 30 --max-capacity 100

Và scheduled scaling quan trọng hơn target tracking ở đây:

Target tracking phản ứng SAU KHI tải đã tăng
    → với đợt bán hàng chớp nhoáng, lưu lượng nhảy vọt trong vài giây
    → phản ứng sau là quá muộn
        ↓
    Scheduled scaling mở rộng TRƯỚC giờ mở bán

Nên kết hợp cả hai:

Scheduled scaling: đặt nền cao trước giờ mở bán
Target tracking:   điều chỉnh tinh theo tải thật

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

• **C. Dùng CloudFront trước website — đây là phương án gần nhất và là công cụ tuyệt vời cho lưu lượng lớn, nhưng nó kém hiệu quả với nội dung động thay đổi liên tục: CloudFront giảm tải bằng cách đệm, và nội dung đổi liên tục thì tỷ lệ trúng cache rất thấp. (CloudFront vẫn giúp về mặt kết thúc TLS ở biên và mạng riêng của AWS, nhưng không giải quyết được vấn đề năng lực tính toán.)
• **B. Triển khai website lên Amazon S3 — không phục vụ được nội dung động: S3 chỉ phục vụ tệp tĩnh, không thực thi mã.
• **A. Dùng Route 53 Multivalue record — không co giãn hạ tầng: multivalue answer trả về tới 8 bản ghi khoẻ mạnh để cân bằng đơn giản, nhưng nó chỉ phân phối lưu lượng tới các máy đã có, không tạo thêm máy nào.

Ghi nhớ

Ba cách xử lý lưu lượng tăng đột biến — bảng phải thuộc: | Cách | Giải quyết | |---|---| | Auto Scaling group | thêm NĂNG LỰC TÍNH TOÁN ← câu này | | CloudFront | giảm tải bằng ĐỆM — cho nội dung TĨNH | | ElastiCache | giảm tải database |

Ba cách này bổ sung nhau, không thay thế nhau.

Từ khoá nhận diện:

"highly dynamic content", "scale infrastructure" → Auto Scaling group "static content", "global users", "reduce origin load" → CloudFront "repeated database queries" → ElastiCache

Năm loại scaling policy — bảng cần thuộc: | Loại | Bạn khai gì | |---|---| | Target tracking | một giá trị metric mục tiêu — đơn giản nhất | | Step scaling | ngưỡng + các bậc điều chỉnh | | Simple scaling | ngưỡng + một hành động (cũ) | | Scheduled scaling | thời điểm và dung lượng — cho sự kiện BIẾT TRƯỚC | | Predictive scaling | học máy dự báo, mở rộng TRƯỚC |

Với đợt bán hàng có lịch, scheduled scaling là công cụ đúng.

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | EstimatedInstanceWarmup | bỏ qua instance mới khi tính metric cho tới khi sẵn sàng | | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | MaxSize đủ lớn | chạm trần thì không mở rộng thêm được |

Dòng cuối là lỗi hay gặp trong ngày cao điểm:

ASG chạm MaxSize mà tải vẫn tăng
    → không có lỗi rõ ràng
    → chỉ thấy trong Activity history
        ↓
    Đặt alarm cho GroupInServiceInstances chạm MaxSize

Ba cách rút ngắn thời gian mở rộng: | Cách | Chi tiết | |---|---| | AMI dựng sẵn (golden AMI) | không cài đặt lúc khởi động | | Warm pool | máy đã cấu hình ở trạng thái Stopped, vào phục vụ trong vài giây | | Giảm thời gian khởi động ứng dụng | |

Warm pool rất phù hợp với đợt bán hàng:

aws autoscaling put-warm-pool --auto-scaling-group-name asg-web   --min-size 20 --pool-state Stopped

Máy ở trạng thái Stopped:
    ✓ KHÔNG tính phí instance
    ✓ chỉ tính phí EBS
    ✓ vào phục vụ trong vài chục giây

Ba tầng cần chuẩn bị cho đợt bán hàng: | Tầng | Chuẩn bị | |---|---| | Web/ứng dụng | ASG mở rộng trước | | Database | read replica, hoặc ElastiCache | | Tệp tĩnh | CloudFront |

Và tầng database thường là nút thắt thật sự:

Mở rộng web tier lên 10 lần
    → database nhận gấp 10 lần truy vấn
    → trở thành nút thắt mới
        ↓
    Phải chuẩn bị cả tầng dữ liệu

Ba lưu ý về hạn mức: | Lưu ý | Chi tiết | |---|---| | Kiểm tra hạn mức vCPU của tài khoản | hạn mức thấp chặn mở rộng | | Yêu cầu nâng hạn mức TRƯỚC vài ngày | AWS cần thời gian xử lý | | Kiểm tra hạn mức của cả dịch vụ khác | ENI, Elastic IP |

Dòng đầu là nguyên nhân thất bại phổ biến trong ngày cao điểm:

aws service-quotas get-service-quota   --service-code ec2 --quota-code L-1216C47A

Ba việc nên làm trước ngày bán hàng: | Việc | Chi tiết | |---|---| | Thử tải với quy mô dự kiến | phát hiện nút thắt thật | | Đóng băng thay đổi vài ngày trước | không triển khai gì mới | | Có kế hoạch quay lại đã diễn tập | |

Ba metric cần theo dõi trong ngày: | Metric | Ý nghĩa | |---|---| | GroupInServiceInstances | số máy đang phục vụ | | TargetResponseTime của ALB | độ trễ người dùng cảm nhận | | Tỷ lệ hoàn tất đơn hàng | chỉ số nghiệp vụ quan trọng nhất |

Và một lời khuyên: hãy kết hợp scheduled scaling với warm pool cho đợt bán hàng chớp nhoáng. Scheduled scaling đảm bảo có đủ máy trước giờ G, còn warm pool khiến việc mở rộng thêm trong lúc bán diễn ra trong vài chục giây thay vì vài phút — khác biệt đó quyết định người dùng có đặt được hàng hay nhận trang lỗi.

Đáp án

B và D.

• B — Đường dẫn health check bị cấu hình sai
• D — Security group của EC2 không cho phép lưu lượng từ security group của ALB

Vì sao đúng

Đề nêu một nghịch lý: truy cập trực tiếp bằng IP thì được, nhưng ALB báo unhealthy. Hai đáp án giải thích chính xác nghịch lý đó.

B — đường dẫn health check sai:

Lập trình viên mở http://<ip>/ trong trình duyệt → thấy trang web ✓

ALB gọi health check tới /health (ví dụ)
    → đường dẫn đó KHÔNG TỒN TẠI
    → trả về 404
        ↓
    ALB đánh dấu target là unhealthy

Kiểm tra và sửa:

aws elbv2 describe-target-groups --target-group-arns <arn>   --query 'TargetGroups[].{Path:HealthCheckPath,Port:HealthCheckPort,Codes:Matcher}'

aws elbv2 modify-target-group --target-group-arn <arn>   --health-check-path / --matcher HttpCode=200

D — security group không cho phép từ ALB:

Lập trình viên truy cập TỪ MÁY CỦA MÌNH
    → IP của họ có thể nằm trong dải được phép ✓

ALB gọi từ IP RIÊNG của subnet chứa ALB
    → security group của EC2 KHÔNG cho phép nguồn đó
    → health check không tới được máy
        ↓
    ALB đánh dấu unhealthy

Cấu hình đúng:

aws ec2 authorize-security-group-ingress --group-id sg-ec2   --protocol tcp --port 80 --source-group sg-alb

Tham chiếu security group của ALB — an toàn hơn và tự thích ứng khi ALB đổi IP.

Và xem lý do cụ thể:

aws elbv2 describe-target-health --target-group-arn <arn>

"Target.FailedHealthChecks"        → health check thất bại
"Target.Timeout"                    → không kết nối được (thường là security group)
"Target.ResponseCodeMismatch"       → mã trả về không khớp matcher

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

• **A. Ứng dụng web dùng runtime mà ALB không hỗ trợ — đây là phương án gần nhất vì nghe có vẻ liên quan tới ứng dụng, nhưng nó không phải khái niệm có thật: ALB hoạt động ở tầng HTTP, nó không quan tâm ngôn ngữ hay runtime của ứng dụng. Miễn là ứng dụng trả về HTTP hợp lệ.
• **C. EBS volume mount sai — không liên quan: nếu volume mount sai thì ứng dụng đã không chạy, mà lập trình viên vẫn truy cập được website.
• **E. Cần gắn Elastic IP cho các EC2 instance — không cần thiết: ALB gọi target qua IP RIÊNG trong VPC, không cần IP công cộng.

Ghi nhớ

Bốn nguyên nhân phổ biến khiến target unhealthy — bảng chẩn đoán: | Nguyên nhân | Dấu hiệu | |---|---| | Security group không cho phép từ ALB | Target.Timeout | | Đường dẫn health check sai | Target.ResponseCodeMismatch hoặc 404 | | Ứng dụng chưa khởi động xong | thất bại rồi khoẻ lại | | NACL của subnet chặn | Target.Timeout |

Sáu tham số của health check: | Tham số | Chi tiết | |---|---| | HealthCheckPath | đường dẫn ALB gọi tới | | HealthCheckPort | mặc định là cổng của target | | Matcher | mã HTTP coi là khoẻ (mặc định 200) | | HealthCheckIntervalSeconds | tần suất kiểm tra | | HealthyThresholdCount | số lần thành công liên tiếp để coi là khoẻ | | UnhealthyThresholdCount | số lần thất bại để coi là hỏng |

Ba nguyên tắc thiết kế endpoint health check: | Nguyên tắc | Chi tiết | |---|---| | Kiểm tra ĐƯỜNG ĐI THẬT của ứng dụng | không chỉ trả 200 tĩnh | | Nhưng đừng kiểm tra quá sâu | phụ thuộc bên ngoài hỏng làm mọi máy bị đánh dấu hỏng | | Phản hồi nhanh | dưới thời gian timeout |

Cân bằng giữa hai dòng đầu:

Quá nông: /health trả 200 tĩnh
    → ứng dụng hỏng logic vẫn được coi là khoẻ

Quá sâu: /health kiểm tra cả database và API bên ngoài
    → database chậm → MỌI máy bị đánh dấu hỏng
    → ASG thay hết → sự cố lan rộng
        ↓
    Vừa phải: kiểm tra ứng dụng khởi tạo xong và xử lý được request

Ba lưu ý về security group với ALB: | Lưu ý | Chi tiết | |---|---| | Tham chiếu SG của ALB, không dùng CIDR | tự thích ứng khi ALB đổi IP | | Cổng health check phải được mở | có thể khác cổng phục vụ | | ALB gọi bằng IP RIÊNG | không cần IP công cộng của target |

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | STATEFUL | phản hồi tự động được phép | | CHỈ có Allow | không có Deny | | Tham chiếu SG khác được | ← khuyến nghị |

Ba cấu hình ASG liên quan: | Cấu hình | Chi tiết | |---|---| | HealthCheckType = ELB | thay máy mà ALB đánh giá hỏng | | HealthCheckGracePeriod | đủ dài cho thời gian khởi động ứng dụng | | Deregistration delay | hoàn tất request đang xử lý |

Grace period quá ngắn gây vòng lặp:

Ứng dụng cần 4 phút khởi động, grace period 60 giây
    → máy mới bị đánh giá hỏng trước khi sẵn sàng
    → ASG chấm dứt và khởi động máy khác
    → LẶP VÔ TẬN

Ba công cụ chẩn đoán: | Công cụ | Việc | |---|---| | describe-target-health | lý do cụ thể của từng target | | VPC Reachability Analyzer | kiểm tra đường đi từ ALB tới EC2 | | VPC Flow Logs | thấy gói bị từ chối (REJECT) |

Reachability Analyzer chỉ ra chính xác thành phần chặn:

aws ec2 create-network-insights-path   --source <arn-alb> --destination i-0abc   --destination-port 80 --protocol tcp

Ba bước chẩn đoán thủ công:

# ① Từ một EC2 trong cùng VPC, thử gọi target
curl -v http://<ip-rieng-cua-target>/health

# ② Kiểm tra security group
aws ec2 describe-security-groups --group-ids sg-ec2

# ③ Xem lý do từ ALB
aws elbv2 describe-target-health --target-group-arn <arn>

Ba lưu ý về NLB health check: | Lưu ý | Chi tiết | |---|---| | Mặc định là TCP | chỉ kiểm tra cổng có mở không | | Nên đổi sang HTTP/HTTPS | kiểm tra ứng dụng thật | | NLB truyền thống không có security group | cho phép theo CIDR |

Và một lời khuyên: hãy xem describe-target-health đầu tiên khi gặp vấn đề này. Nó nói rõ lý do — Target.Timeout nghĩa là mạng chặn (security group hoặc NACL), còn Target.ResponseCodeMismatch nghĩa là mạng thông nhưng ứng dụng trả sai mã. Biết ngay hướng nào cần điều tra tiết kiệm rất nhiều thời gian.

Đáp án

B — Đặt Amazon ElastiCache for Redis giữa ứng dụng và Aurora; đệm kết quả truy vấn hay dùng để giảm số request đọc lặp lại tới database.

Vì sao đúng

Đề nêu một dữ kiện quyết định: truy vấn LẶP LẠI về vị trí gói hàng.

"frequent REPEATED queries about package locations and delivery history"
        ↓
    Cùng một câu hỏi được hỏi đi hỏi lại
    → nhiều người cùng tra một mã vận đơn
    → và mỗi người tra lại nhiều lần
        ↓
    Đệm loại bỏ HẦU HẾT các lần đọc đó

Và đề nói rõ thêm replica chỉ giảm nhẹ tạm thời:

"added an Aurora read replica, which TEMPORARILY alleviated the load,
 but read traffic CONTINUES TO SPIKE"
        ↓
    Thêm replica là chia nhỏ cùng một lượng tải
    → không giảm SỐ LƯỢNG truy vấn
    → tải tiếp tục tăng thì lại phải thêm replica nữa
        ↓
    Đệm giảm hẳn số truy vấn chạm tới database

Và về chi phí, đệm rẻ hơn nhiều:

Thêm Aurora replica: một instance database đầy đủ
Thêm node ElastiCache: rẻ hơn đáng kể cho cùng lượng request phục vụ
        ↓
    Với truy vấn lặp lại, tỷ lệ trúng cache thường trên 90%

Mẫu cache-aside:

def tra_cuu_vi_tri(ma_van_don):
    khoa = f'vi-tri:{ma_van_don}'
    ket_qua = redis.get(khoa)
    if ket_qua is None:                    # trượt cache
        ket_qua = aurora.query(ma_van_don)
        redis.setex(khoa, 60, json.dumps(ket_qua))  # TTL 60 giây
    return json.loads(ket_qua)

Và TTL ngắn là phù hợp với dữ liệu vận chuyển:

Vị trí gói hàng cập nhật vài phút một lần
    → TTL 60 giây cho dữ liệu đủ mới
    → mà vẫn loại bỏ phần lớn truy vấn

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

• **C. Thêm một Aurora read replica nữa và cân bằng tải phía client — đây là phương án gần nhất và thực sự chia được tải, nhưng nó không giải quyết nguyên nhân gốc: số truy vấn vẫn tăng, và mỗi lần tăng lại phải thêm replica. Đề nói rõ cách này chỉ giảm nhẹ tạm thời. Và cân bằng tải phía client là công việc tự viết không cần thiết — Aurora đã có reader endpoint.
• **D. Bật Aurora Serverless v2 và định tuyến mọi lưu lượng qua cluster endpoint — hai vấn đề: cluster endpoint trỏ tới writer, nên định tuyến mọi thứ qua đó làm tải đọc dồn hết vào writer. Và Serverless v2 tăng năng lực tính toán chứ không giảm số truy vấn.
• **A. Chuyển sang multi-writer bằng Aurora Global Database — sai về mặt kỹ thuật: Aurora Global Database chỉ có MỘT writer ở Region primary, Region phụ là chỉ đọc. Nó không phải cấu hình multi-writer.

Ghi nhớ

Ba cách giảm tải đọc — theo thứ tự nên thử: | Thứ tự | Cách | Hiệu quả | |---|---|---| | ① | Tối ưu truy vấn và index | rẻ nhất, thường hiệu quả nhất | | ② | Đệm kết quả (ElastiCache) | giảm SỐ LƯỢNG truy vấn | | ③ | Thêm read replica | chia nhỏ cùng lượng tải |

Khác biệt cốt lõi giữa ② và ③:

Read replica: chia cùng một lượng truy vấn cho nhiều máy
ElastiCache:  LOẠI BỎ phần lớn truy vấn
        ↓
    Với truy vấn LẶP LẠI, đệm hiệu quả hơn nhiều

Ba mẫu đệm phổ biến: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database ← phổ biến nhất | | Write-through | ghi vào cache và database cùng lúc | | TTL | tự hết hạn tránh dữ liệu cũ |

Ba đánh đổi của lazy loading: | Ưu | Nhược | |---|---| | Chỉ đệm dữ liệu THỰC SỰ được dùng | lần đọc đầu luôn trượt | | Node cache hỏng không gây lỗi | dữ liệu có thể cũ trong khoảng TTL | | Đơn giản | |

Redis và Memcached — bảng phân biệt: | | Redis / Valkey | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú (sorted set, hash, list) | chỉ key-value | | Bền vững | có (snapshot, AOF) | ❌ | | Sao chép và Multi-AZ | ✅ | ❌ | | Đa luồng | có I/O threading từ v6 | ✅ từ đầu |

Với ứng dụng cần sẵn sàng cao, Redis là lựa chọn đúng.

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, có replica | | Cluster mode enabled | chia dữ liệu qua nhiều shard | | Serverless | tự co giãn, trả theo lượng dùng |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | thấp nghĩa là đệm không hiệu quả | | Evictions | cao nghĩa là bộ nhớ không đủ | | DatabaseConnections của Aurora | phải giảm sau khi bật cache |

Evictions là chỉ báo quan trọng:

Evictions tăng:
    → Redis phải xoá key để lấy chỗ
    → tỷ lệ trúng cache giảm
        ↓
    Cần node lớn hơn hoặc thêm shard

Ba nguyên tắc thiết kế khoá cache: | Nguyên tắc | Chi tiết | |---|---| | Khoá phản ánh đúng truy vấn | vi-tri:{ma_van_don} | | TTL phù hợp với độ tươi cần thiết | vị trí gói hàng: 30–120 giây | | Vô hiệu hoá khi dữ liệu đổi | hoặc dựa vào TTL |

Ba lưu ý về tính nhất quán: | Lưu ý | Chi tiết | |---|---| | Cache luôn có thể cũ hơn database | trong khoảng TTL | | Với dữ liệu quan trọng, dùng write-through | | | Xoá khoá khi có cập nhật | đảm bảo đọc-sau-ghi |

def cap_nhat_vi_tri(ma_van_don, vi_tri):
    aurora.update(ma_van_don, vi_tri)
    redis.delete(f'vi-tri:{ma_van_don}')   # vô hiệu hoá ngay

Ba endpoint của Aurora — nhắc lại: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance GHI ← phương án D dùng sai cái này | | Reader | cân bằng tải qua mọi replica | | Custom | nhóm instance do bạn định nghĩa |

Ba cấu hình cho ElastiCache sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | chịu được mất một node | | Bật snapshot tự động | khôi phục khi cần |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo node-giờ | như EC2 | | Reserved node giảm tới 55% | cho tải ổn định | | Rẻ hơn nhiều so với thêm Aurora replica | cho cùng lượng request |

Và một lời khuyên: hãy đo tỷ lệ trúng cache sau một tuần thay vì chỉ giả định. Với truy vấn tra cứu vận đơn, tỷ lệ thường rất cao — nhưng nếu nó chỉ đạt 40%, nghĩa là mỗi người dùng tra một mã khác nhau và đệm không phải công cụ đúng; khi đó tối ưu index và thêm replica mới là hướng đi.

Đáp án

A — Dựng AWS Global Accelerator, đăng ký các ALB ở các Region khác nhau vào đó, và cấu hình tường lửa tại chỗ cho phép các địa chỉ IP TĨNH của Global Accelerator.

Vì sao đúng

Đề nêu vấn đề rõ: cần cho phép IP của ALB trong tường lửa, nhưng IP của ALB thay đổi.

ALB KHÔNG có IP tĩnh
    → AWS thay đổi IP khi co giãn hoặc bảo trì
    → và lưu lượng thay đổi trong năm càng làm nó co giãn nhiều
        ↓
    Danh sách IP trong tường lửa liên tục hỏng

Global Accelerator giải quyết triệt để:

Global Accelerator cho HAI ĐỊA CHỈ IP ANYCAST TĨNH
    → đại diện cho MỌI ALB ở MỌI Region
    → IP KHÔNG BAO GIỜ đổi
        ↓
    Tường lửa chỉ cần cho phép HAI IP
    → không phải cập nhật nữa

Cấu hình:

aws globalaccelerator create-accelerator --name diem-vao-tinh --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol TCP --port-ranges FromPort=443,ToPort=443

# Đăng ký ALB của từng Region
aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-northeast-1   --endpoint-configurations EndpointId=<arn-alb-tokyo>,Weight=100

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region eu-west-1   --endpoint-configurations EndpointId=<arn-alb-ireland>,Weight=100

Và ba lợi ích phụ: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ | lưu lượng đi qua mạng riêng của AWS | | Chuyển vùng tự động ~30 giây | Region hỏng thì tự chuyển | | Thêm Region mới không phải sửa tường lửa | ← "scalable" đúng nghĩa |

Điểm cuối là ý nghĩa của "MOST scalable":

Mở Region mới:
    → chỉ thêm endpoint group vào accelerator
    → tường lửa KHÔNG phải đổi gì

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

• **B. Dựng NLB ở một Region, đăng ký IP riêng của các ALB ở Region khác làm target — đây là phương án gần nhất vì NLB thực sự có Elastic IP tĩnh, nhưng nó không hoạt động xuyên Region: NLB chỉ định tuyến tới target trong cùng Region (hoặc qua peering trong cùng Region). Và IP riêng của ALB thay đổi, nên target group sẽ hỏng.
• **C. Chuyển tất cả ALB thành NLB và cho phép Elastic IP của chúng — mất khả năng định tuyến theo nội dung của ALB, và vẫn để lại nhiều IP phải quản lý (mỗi NLB một IP mỗi AZ, nhân với số Region).
• **D. Viết Lambda lấy IP của ALB rồi cập nhật tường lửa — giải pháp chắp vá: IP đổi bất cứ lúc nào, nên luôn có khoảng thời gian danh sách sai. Và phải viết, bảo trì và giám sát mã tự viết.

Ghi nhớ

IP của các load balancer — bảng phải thuộc: | Load balancer | Địa chỉ IP | |---|---| | Application Load Balancer | ĐỘNG, thay đổi — CHỈ dùng tên DNS | | Network Load Balancer | có thể gán Elastic IP TĨNH (một mỗi AZ) | | Global Accelerator | 2 IP anycast TĨNH, TOÀN CẦU |

Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP và UDP, mọi cổng | chỉ HTTP/HTTPS | | Caching | ❌ | ✅ | | Địa chỉ | 2 IP anycast TĨNH | tên miền | | Chuyển vùng | ~30 giây, không đụng DNS | theo origin | | Phù hợp | IP tĩnh, UDP, game, API | web, nội dung tĩnh |

Từ khoá nhận diện:

"static IP", "whitelist in firewall", "UDP", "fast regional failover" → Global Accelerator "cache content", "HTTP", "reduce origin load" → CloudFront

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Đưa vào danh sách trắng tường lửa | ← lý do chính trong câu này | | Không phụ thuộc bộ đệm DNS | chuyển vùng tức thì | | Giữ nguyên khi đổi kiến trúc phía sau | |

Và bạn mang IP của mình vào được (BYOIP):

Nếu công ty đã có dải IP công cộng riêng
    → đưa vào AWS và dùng cho Global Accelerator
    → khách hàng không phải cập nhật danh sách trắng

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | tài nguyên gốc, mang hai IP tĩnh | | Listener | cổng và giao thức | | Endpoint group | một Region, có traffic dial | | Endpoint | ALB, NLB, EC2, Elastic IP |

Các loại endpoint được hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | Application Load Balancer | ✅ ← câu này | | Network Load Balancer | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ | | S3 bucket | ❌ |

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ ← câu này | | Custom routing | ánh xạ cố định IP+cổng → instance |

Ba yếu tố quyết định định tuyến: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Và traffic dial cho triển khai dần:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 10

Hoặc đặt 0 để rút một Region ra tức thì.

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB, khác nhau theo Region | | Không có phí request | khác CloudFront |

Ba biện pháp bảo mật đi kèm: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | WAF trên từng ALB phía sau | lọc tầng 7 | | — | WAF KHÔNG gắn được vào Global Accelerator |

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Dùng health check của chính endpoint | ALB, NLB | | Health check phải kiểm tra ĐƯỜNG ĐI THẬT | không chỉ trả 200 tĩnh | | Endpoint hỏng bị rút khỏi định tuyến | tự động |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NewFlowCount | số kết nối mới | | ProcessedBytesIn/Out | lưu lượng | | HealthyEndpointCount | Region nào đang phục vụ |

Và một lời khuyên: hãy ghi hai địa chỉ IP tĩnh vào tài liệu vận hành và chia sẻ với đội mạng. Đó chính là giá trị lớn nhất của giải pháp này — thay vì gửi cho họ một danh sách IP thay đổi liên tục và một quy trình cập nhật, bạn gửi hai con số không bao giờ đổi.

Đáp án

A — Tạo EFS mount target ở MỖI AZ và mount file system từ EC2 vào mount target trong CÙNG AZ với instance đó.

Vì sao đúng

Đề nêu yêu cầu rõ: độ trễ thấp nhất có thể cho tải HPC đọc ghi thường xuyên.

Mount target là ENI trong một subnet của MỘT AZ
    ↓
EC2 mount vào mount target CÙNG AZ:
    → lưu lượng KHÔNG rời AZ
    → độ trễ thấp nhất
    → KHÔNG tốn phí truyền chéo AZ

EC2 mount vào mount target ở AZ KHÁC:
    → mỗi thao tác tệp phải vượt qua AZ
    → độ trễ cao hơn
    → và tính phí truyền chéo AZ

Và NFS rất nhạy với độ trễ:

Mỗi thao tác tệp là một vòng lượt mạng
    → mở một tệp có thể cần hàng chục thao tác
        ↓
    Với tải HPC đọc ghi thường xuyên,
    chênh lệch độ trễ giữa các AZ tích tụ rất nhanh

Tạo mount target ở mọi AZ:

for subnet in subnet-a subnet-b subnet-c; do
  aws efs create-mount-target --file-system-id fs-0abc123     --subnet-id $subnet --security-groups sg-efs
done

Và mount bằng tên DNS của file system:

sudo mount -t efs -o tls fs-0abc123:/ /du-lieu

Tên DNS fs-0abc123.efs.<region>.amazonaws.com
    → TỰ ĐỘNG phân giải về IP của mount target
      TRONG CÙNG AZ với instance
        ↓
    Không phải cấu hình gì thêm

Đây là hành vi quan trọng: miễn là có mount target ở AZ đó, EFS tự chọn đúng cái gần nhất.

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

• **D. Tạo MỘT mount target duy nhất ở một AZ và cho mọi EC2 ở AZ khác truy cập qua đó — đây là phương án gần nhất và hoạt động được về mặt kỹ thuật, nhưng nó đi ngược yêu cầu về độ trễ: instance ở AZ khác phải vượt qua AZ cho mọi thao tác tệp, và còn tốn phí truyền chéo AZ.
• **B. Tạo mount target trên một EC2 instance ở mỗi AZ để làm điểm truy cập cho các máy khác — hiểu sai khái niệm: mount target là tài nguyên của EFS trong một SUBNET, không phải thứ tạo trên EC2. Và dùng một EC2 làm cầu nối tạo ra điểm hỏng và nút thắt.
• **C. Dùng Mountpoint for Amazon S3 — không phải hệ thống tệp POSIX đầy đủ: Mountpoint hỗ trợ một tập con thao tác tệp, không có ngữ nghĩa POSIX hoàn chỉnh (không sửa tại chỗ, không khoá tệp), và độ trễ cao hơn EFS nhiều cho thao tác nhỏ.

Ghi nhớ

Ba đặc điểm của EFS mount target — bảng phải thuộc: | Đặc điểm | Chi tiết | |---|---| | MỘT mount target mỗi AZ | không tạo được hai cái trong cùng AZ | | Là một ENI có IP riêng | gắn security group vào đây | | Tên DNS tự chọn mount target CÙNG AZ | ← hành vi quan trọng |

Và thiếu mount target ở một AZ có hai hậu quả:

① Instance ở AZ đó phải đi CHÉO AZ
    → độ trễ cao hơn
② Tốn phí truyền chéo AZ
    → ~0,01 USD/GB mỗi chiều

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định mới) | tự co giãn, trả theo lượng dùng thật | | Provisioned | khai trước, tính phí dù không dùng | | Bursting | theo dung lượng, có credit |

Hai chế độ hiệu năng: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất — dùng cho hầu hết trường hợp | | Max I/O | thông lượng cao hơn nhưng độ trễ CAO HƠN |

Với yêu cầu "độ trễ thấp nhất", General Purpose là đúng — Max I/O đánh đổi độ trễ lấy thông lượng.

Ba cách tăng hiệu năng EFS: | Cách | Chi tiết | |---|---| | Mount target cùng AZ | ← câu này | | Dùng Elastic throughput | bỏ trần theo dung lượng | | Tham số nconnect khi mount | nhiều kết nối TCP song song |

nconnect đáng biết:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,nconnect=16   fs-0abc123.efs.ap-northeast-1.amazonaws.com:/ /du-lieu

Tăng thông lượng đáng kể cho một client.

Ba lưu ý về bảo mật EFS: | Lớp | Cơ chế | |---|---| | Mạng | security group của mount target, cổng 2049 (NFS) | | Danh tính | IAM policy + file system policy | | Hệ thống tệp | quyền POSIX + Access Point |

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | |---|---| | Standard | ~0,30 USD/GB-tháng | | Standard-IA | ~0,025 USD/GB-tháng | | Archive | ~0,008 USD/GB-tháng | | One Zone (và IA) | rẻ hơn ~47% |

Lưu ý: One Zone chỉ có mount target ở MỘT AZ — không phù hợp với tải trải nhiều AZ như trong đề.

Ba lựa chọn lưu trữ chia sẻ cho HPC: | Lựa chọn | Đặc điểm | |---|---| | EFS | NFS đơn giản, tự co giãn ← câu này | | FSx for Lustre | thông lượng CAO NHẤT, độ trễ dưới mili giây | | Instance store | nhanh nhất nhưng không chia sẻ |

FSx for Lustre đáng cân nhắc cho HPC thật sự:

FSx for Lustre:
    → hàng trăm GB/giây thông lượng
    → độ trễ dưới mili giây
    → thiết kế riêng cho HPC
        ↓
    Nhưng chỉ ở MỘT AZ — đánh đổi với yêu cầu đa AZ của đề

Ba lưu ý về EFS Access Point: | Lợi ích | Chi tiết | |---|---| | Ép POSIX user | không phụ thuộc uid của client | | Ép thư mục gốc | client chỉ thấy phần của mình | | Đơn giản hoá phân quyền | một access point cho một ứng dụng |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Truyền chéo AZ với EFS | MIỄN PHÍ (khác EC2 chéo AZ) | | Nhưng độ trễ vẫn cao hơn | ← lý do vẫn nên cùng AZ | | Lifecycle sang IA | giảm ~90% cho tệp cũ |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% = chạm trần chế độ hiệu năng | | MeteredIOBytes | thông lượng thực tế | | ClientConnections | số máy đang mount |

Ba lưu ý khi mount EFS: | Lưu ý | Chi tiết | |---|---| | Cài amazon-efs-utils | để dùng -t efs với TLS và IAM | | Thêm vào /etc/fstab với _netdev | mount lại sau khi khởi động | | Mở cổng 2049 trong security group | |

fs-0abc123:/ /du-lieu efs _netdev,tls,iam 0 0

Và một lời khuyên: hãy kiểm chứng instance đang mount vào mount target cùng AZ bằng cách so IP mà tên DNS phân giải ra với IP của mount target trong AZ đó. Nếu thiếu mount target ở một AZ, EFS vẫn hoạt động bình thường — chỉ chậm hơn và tốn hơn, và không có cảnh báo nào cho bạn biết.

Đáp án

D — Bật deletion protection trên các bảng DynamoDB.

Vì sao đúng

Đề nêu chính xác vấn đề: kỹ sư XOÁ NHẦM một bảng sản xuất, và cần ngăn tái diễn với ít công vận hành nhất.

Deletion protection:
    → chặn HOÀN TOÀN lời gọi DeleteTable
    → kể cả từ tài khoản có toàn quyền
        ↓
    Một công tắc, không có công vận hành nào

Bật:

aws dynamodb update-table --table-name giao-dich   --deletion-protection-enabled

Và muốn xoá thật thì phải tắt trước — hai bước có chủ đích:

aws dynamodb update-table --table-name giao-dich --no-deletion-protection-enabled
aws dynamodb delete-table --table-name giao-dich

Bước thừa này chính là biện pháp bảo vệ — không ai xoá nhầm bằng một lệnh nữa.

Và vì sao đây là "least operational overhead":

✓ một tham số, bật một lần
✓ không có mã nào để viết
✓ không có quy trình nào để bảo trì
✓ không tốn thêm chi phí

Điểm quan trọng: PITR KHÔNG cứu được bảng đã bị XOÁ.

Xoá bảng:
    → point-in-time recovery của bảng đó MẤT THEO
        ↓
    PITR bảo vệ khỏi GHI SAI dữ liệu
    Deletion protection bảo vệ khỏi XOÁ BẢNG
        ↓
    Hai vấn đề khác nhau — và đề nói về vấn đề thứ hai

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

• **A. Bật point-in-time recovery (PITR) trên mỗi bảng — đây là phương án gần nhất và là biện pháp bảo vệ dữ liệu rất quan trọng, nhưng nó không giải quyết đúng sự cố trong đề: PITR cho phép khôi phục về bất kỳ giây nào trong 35 ngày, nhưng nó bị xoá cùng với bảng. Nó bảo vệ khỏi ghi hỏng dữ liệu, không phải khỏi xoá bảng.
• **C. Dùng CloudTrail + EventBridge + Lambda tự tạo lại bảng khi phát hiện DeleteTable — phức tạp và phản ứng SAU khi thiệt hại đã xảy ra: bảng đã bị xoá, dịch vụ đã ngừng, và việc tạo lại từ backup vẫn mất dữ liệu giữa lần backup gần nhất và thời điểm xoá.
• **B. Xuất bảng ra S3 hằng tuần và khôi phục thủ công — RPO tệ nhất: mất tới một tuần dữ liệu, và khôi phục thủ công là công việc lớn.

Ghi nhớ

Ba cơ chế bảo vệ dữ liệu DynamoDB — bảng phải thuộc: | Cơ chế | Chống lại | |---|---| | Deletion protection | XOÁ BẢNG nhầm ← câu này | | Point-in-time recovery (PITR) | ghi hỏng dữ liệu, xoá item nhầm | | On-demand backup | lưu trữ dài hạn, tuân thủ | | AWS Backup | quản lý tập trung nhiều dịch vụ |

Ba cơ chế này bổ sung nhau — nên bật cả ba cho bảng sản xuất.

Và điểm mấu chốt cần nhớ:

Xoá bảng → PITR và automated backup của bảng đó MẤT THEO
    → chỉ on-demand backup (snapshot thủ công) còn lại
        ↓
    Đó là lý do deletion protection là lớp bảo vệ đầu tiên

PITR và on-demand backup — bảng phân biệt: | | PITR | On-demand backup | |---|---|---| | Độ chi tiết | từng GIÂY | thời điểm chụp | | Thời gian giữ | 35 ngày | không giới hạn | | Sống sót khi xoá bảng | ❌ | ✅ | | Chi phí | theo dung lượng bảng | theo dung lượng backup |

Ba lớp bảo vệ nên có cho bảng sản xuất:

# ① Chặn xoá bảng
aws dynamodb update-table --table-name giao-dich --deletion-protection-enabled

# ② Khôi phục về bất kỳ giây nào trong 35 ngày
aws dynamodb update-continuous-backups --table-name giao-dich   --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# ③ Backup dài hạn qua AWS Backup
aws backup create-backup-plan --backup-plan file://ke-hoach.json

Ba biện pháp phòng ngừa ở tầng quyền: | Biện pháp | Chi tiết | |---|---| | SCP chặn dynamodb:DeleteTable | cho cả tài khoản, kể cả root | | IAM policy Deny cho vai trò không cần | | | Tách tài khoản prod và dev | cách ly mạnh nhất |

SCP chặn xoá bảng sản xuất:

{"Effect": "Deny",
 "Action": ["dynamodb:DeleteTable"],
 "Resource": "arn:aws:dynamodb:*:*:table/prod-*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/vai-tro-quan-tri-db"}}}

Ba lưu ý về deletion protection: | Lưu ý | Chi tiết | |---|---| | Chặn DeleteTable hoàn toàn | kể cả root | | Không ảnh hưởng việc xoá ITEM | chỉ bảo vệ bảng | | Bật và tắt được bất cứ lúc nào | qua update-table |

Dòng giữa quan trọng: deletion protection không ngăn ai đó xoá hết dữ liệu trong bảng — đó là việc của PITR.

Ba tính năng tương tự ở dịch vụ khác: | Dịch vụ | Tính năng | |---|---| | RDS | --deletion-protection | | S3 | MFA Delete, Object Lock | | CloudFormation | DeletionPolicy: Retain hoặc Snapshot | | EC2 | disableApiTermination |

Ba cách khôi phục bảng DynamoDB: | Cách | Điều kiện | |---|---| | PITR restore | bảng còn tồn tại | | Restore từ on-demand backup | backup còn | | AWS Backup restore | có kế hoạch backup |

aws dynamodb restore-table-to-point-in-time   --source-table-name giao-dich   --target-table-name giao-dich-khoi-phuc   --restore-date-time 2026-08-30T14:32:16Z

Lưu ý: khôi phục tạo BẢNG MỚI, không ghi đè bảng cũ.

Ba lưu ý về AWS Backup cho DynamoDB: | Lưu ý | Chi tiết | |---|---| | Quản lý tập trung nhiều dịch vụ | RDS, EFS, EBS, DynamoDB | | Backup vault có thể khoá | Vault Lock chống xoá backup | | Sao chép xuyên Region | cho khôi phục thảm hoạ |

Vault Lock đáng biết:

AWS Backup Vault Lock:
    → khoá backup, không ai xoá được
    → kể cả root
        ↓
    Bảo vệ cuối cùng chống ransomware và xoá cố ý

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Deletion protection | MIỄN PHÍ | | PITR | ~0,20 USD/GB-tháng | | On-demand backup | theo dung lượng backup |

Deletion protection hoàn toàn miễn phí — không có lý do gì để không bật.

Ba việc nên làm ngay: | Việc | Chi tiết | |---|---| | Bật deletion protection cho MỌI bảng sản xuất | | | Bật PITR cho MỌI bảng sản xuất | | | Rà soát ai có quyền DeleteTable | |

Và một lời khuyên: hãy bật deletion protection cho mọi bảng ngay hôm nay, kể cả bảng ở môi trường thử nghiệm. Nó miễn phí, mất vài giây, và không có nhược điểm nào — thao tác duy nhất bị ảnh hưởng là việc xoá bảng, vốn nên là một quyết định có chủ đích chứ không phải một lệnh gõ nhầm.

Đáp án

D — Đặt ElastiCache for Redis trước database PostgreSQL; sửa ứng dụng để đệm việc đọc và cập nhật vị trí gần đây trong Redis, dùng chiến lược đuổi theo TTL.

Vì sao đúng

Đề nêu ba đặc điểm, và cả ba dẫn tới Redis: | Đặc điểm | Kết luận | |---|---| | HÀNG NGHÌN cập nhật và đọc MỖI GIÂY | database quan hệ không chịu nổi tải ghi này | | Dữ liệu vị trí thay đổi liên tục | giá trị cũ nhanh chóng vô nghĩa → TTL ngắn | | Độ trễ tối thiểu | Redis cho micro giây |

Vì sao PostgreSQL là nút thắt:

Mỗi tài xế cập nhật vị trí mỗi vài giây
    → hàng nghìn UPDATE mỗi giây
    → mỗi UPDATE ghi WAL, cập nhật index, tạo tuple mới
        ↓
    Read replica KHÔNG giúp gì cho tải GHI
    → primary vẫn là nút thắt

Và Redis xử lý loại tải này rất tốt:

Redis:
    ✓ trong bộ nhớ, độ trễ micro giây
    ✓ hàng trăm nghìn thao tác mỗi giây trên một node
    ✓ có kiểu dữ liệu GEO dựng sẵn

Redis có lệnh địa lý nguyên bản:

GEOADD vi-tri-tai-xe 106.700 10.776 "tai-xe-001"
GEOSEARCH vi-tri-tai-xe FROMLONLAT 106.702 10.778 BYRADIUS 3 km ASC COUNT 10

Tìm tài xế gần nhất trong bán kính 3 km — đúng nghiệp vụ của ứng dụng gọi xe.

Và TTL xử lý dữ liệu cũ tự nhiên:

redis.geoadd('vi-tri-tai-xe', (kinh_do, vi_do, ma_tai_xe))
redis.setex(f'hoat-dong:{ma_tai_xe}', 30, '1')   # hết hạn sau 30 giây

Tài xế ngừng cập nhật
    → khoá hết hạn
    → tự động biến mất khỏi danh sách khả dụng

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

• **B. Tạo chính sách auto scaling cho read replica và phân phối qua RDS Proxy — đây là phương án gần nhất và giúp được tải đọc, nhưng nó không giải quyết tải GHI: hàng nghìn cập nhật vị trí mỗi giây vẫn dồn vào primary. Read replica chỉ chia được phần đọc.
• **C. Chuyển dữ liệu vị trí sang OpenSearch Service dùng geospatial index — không tối ưu cho tải ghi rất cao: OpenSearch là công cụ tìm kiếm, việc lập chỉ mục có độ trễ và nó không thiết kế cho hàng nghìn cập nhật mỗi giây trên cùng một tài liệu.
• **A. Bật Multi-AZ cho instance chính và dùng standby để phân phối đọc — sai về mặt kỹ thuật: standby của Multi-AZ KHÔNG phục vụ đọc. Và Multi-AZ là cơ chế sẵn sàng cao, không liên quan tới hiệu năng.

Ghi nhớ

Ba loại tải và database phù hợp — bảng cần thuộc: | Loại tải | Database | |---|---| | Ghi rất cao, dữ liệu ngắn hạn | ElastiCache Redis, MemoryDB | | Ghi cao, cần bền vững, key-value | DynamoDB | | Giao dịch quan hệ | RDS, Aurora | | Phân tích | Redshift |

Ba kiểu dữ liệu Redis hay dùng: | Kiểu | Dùng cho | |---|---| | GEO (GEOADD, GEOSEARCH) | toạ độ địa lý ← câu này | | Sorted set | bảng xếp hạng | | String với TTL | phiên, đệm | | Hash | hồ sơ đối tượng |

Ba lệnh GEO của Redis: | Lệnh | Việc | |---|---| | GEOADD | thêm hoặc cập nhật toạ độ | | GEOSEARCH | tìm trong bán kính hoặc hộp chữ nhật | | GEODIST | khoảng cách giữa hai điểm |

Ba dịch vụ in-memory của AWS: | Dịch vụ | Đặc điểm | |---|---| | ElastiCache Redis | bộ ĐỆM — mất dữ liệu chấp nhận được | | MemoryDB for Redis | DATABASE CHÍNH — bền vững đa AZ | | DynamoDB + DAX | bộ đệm cho DynamoDB |

MemoryDB đáng cân nhắc:

Nếu vị trí tài xế là NGUỒN DỮ LIỆU DUY NHẤT:
    → ElastiCache mất dữ liệu khi node hỏng
    → MemoryDB bền vững, độ trễ đọc micro giây
        ↓
    An toàn hơn cho dữ liệu vận hành thời gian thực

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, có replica | | Cluster mode enabled | chia dữ liệu qua nhiều shard — mở rộng ngang | | Serverless | tự co giãn |

Với hàng nghìn thao tác mỗi giây và đang tăng, cluster mode là hướng đúng.

Ba mẫu đệm: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database | | Write-through | ghi vào cache và database cùng lúc | | Write-behind | ghi cache trước, đẩy xuống database sau |

Với vị trí thời gian thực, mẫu phù hợp là:

Ghi vị trí mới nhất → CHỈ Redis (với TTL)
Ghi lịch sử di chuyển → hàng đợi → database hoặc S3 (bất đồng bộ)
        ↓
    Database không còn nhận hàng nghìn UPDATE mỗi giây

Ba cấu hình cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | | | Bật snapshot nếu dữ liệu cần giữ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | EngineCPUUtilization | CPU của tiến trình Redis (chính xác hơn CPUUtilization) | | Evictions | bộ nhớ không đủ | | CurrConnections | số kết nối |

EngineCPUUtilization là metric đúng cho Redis:

Redis chủ yếu đơn luồng cho xử lý lệnh
    → CPUUtilization của cả instance có thể thấp
    → nhưng EngineCPUUtilization đã gần 100%
        ↓
    Dùng metric thứ hai để biết khi nào cần thêm shard

Ba lưu ý về mở rộng Redis: | Cách | Chi tiết | |---|---| | Thêm replica | mở rộng ĐỌC | | Thêm shard (cluster mode) | mở rộng GHI | | Node lớn hơn | thêm bộ nhớ và CPU |

Ba lưu ý khi thiết kế cho ứng dụng gọi xe: | Lưu ý | Chi tiết | |---|---| | Vị trí hiện tại: Redis với TTL ngắn | | | Lịch sử chuyến đi: DynamoDB hoặc S3 | qua hàng đợi | | Dữ liệu nghiệp vụ: PostgreSQL | hồ sơ, thanh toán |

Kiến trúc phân tầng theo loại dữ liệu:

Vị trí thời gian thực → Redis (TTL 30 giây)
Sự kiện chuyến đi     → Kinesis → DynamoDB + S3
Hồ sơ và thanh toán   → Aurora PostgreSQL
        ↓
    Mỗi kho làm đúng việc của nó

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo node-giờ | | | Reserved node giảm tới 55% | | | Rẻ hơn nhiều so với mở rộng RDS | cho cùng lượng thao tác |

Và một lời khuyên: hãy đưa cả việc GHI vị trí vào Redis, không chỉ việc đọc. Nếu vẫn ghi mọi cập nhật xuống PostgreSQL, nút thắt ghi vẫn còn nguyên — và với ứng dụng gọi xe, vị trí của một phút trước không có giá trị lưu trữ nào, nên để nó chỉ tồn tại trong bộ nhớ là hoàn toàn hợp lý.

Đáp án

B — Dùng Amazon DynamoDB Accelerator (DAX).

Vì sao đúng

Đề nêu ba dữ kiện, và DAX là lựa chọn phù hợp nhất: | Dữ kiện | Kết luận | |---|---| | Vận động viên nổi tiếng được đọc rất nhiều | truy vấn LẶP LẠI trên cùng vài item | | Tăng RCU không giải quyết được | hot partition — giới hạn ở mức PARTITION | | KHÔNG muốn refactor nhiều | DAX tương thích API, chỉ đổi client |

Vì sao tăng RCU không giúp:

DynamoDB giới hạn mỗi partition ở 3.000 RCU
    → tăng RCU của BẢNG không nâng được trần của một PARTITION
        ↓
    Item của vận động viên nổi tiếng nằm trong một partition
    → partition đó bị throttle dù bảng còn dư dung lượng

Và DAX loại bỏ phần lớn lượt đọc đó:

DAX là bộ đệm trong bộ nhớ ĐƯỢC QUẢN LÝ cho DynamoDB
    → item nóng được phục vụ TỪ CACHE
    → không chạm tới partition của DynamoDB
        ↓
    Hot partition được giải toả
    Và độ trễ từ mili giây xuống MICRO GIÂY

Và "không refactor nhiều" là lợi thế riêng của DAX:

# Trước
import boto3
bang = boto3.resource('dynamodb').Table('van-dong-vien')

# Sau — CHỈ đổi client
from amazondax import AmazonDaxClient
dax = AmazonDaxClient.resource(endpoint_url='dax://cum.abc.dax-clusters.amazonaws.com')
bang = dax.Table('van-dong-vien')

Mọi lời gọi get_item, query, put_item giữ nguyên — đó là điều ElastiCache không có.

Tạo cụm DAX:

aws dax create-cluster --cluster-name cum-dax   --node-type dax.r5.large --replication-factor 3   --iam-role-arn <arn-role>   --subnet-group-name nhom-subnet --security-group-ids sg-dax

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

• **D. Dùng Amazon ElastiCache — đây là phương án gần nhất và cũng là bộ đệm trong bộ nhớ giải quyết được vấn đề, nhưng nó đòi refactor đáng kể: phải tự viết logic kiểm tra cache, nạp khi trượt, và vô hiệu hoá khi ghi. DAX làm hết những việc đó. Đề nêu rõ "without a lot of application refactoring".
• **A. Dùng DynamoDB Global Tables — giải quyết vấn đề khác: global table sao chép dữ liệu sang Region khác cho độ trễ thấp toàn cầu và khôi phục thảm hoạ. Hot partition vẫn tồn tại ở mọi Region.
• **C. Dùng DynamoDB Streams — cũng sai mục đích: Streams ghi lại luồng thay đổi để các dịch vụ khác phản ứng. Nó không đệm việc đọc.

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

Đề nói "DynamoDB đã tăng RCU nhưng vẫn còn hot partition" — và cần biết DynamoDB có cơ chế tự xử lý một phần vấn đề này.

Từ 2018, DynamoDB có adaptive capacity:

Adaptive capacity:
    ✓ tự phân bổ lại dung lượng cho partition bị quá tải
    ✓ hoạt động TỨC THÌ (từ 2019)
    ✓ có thể tách partition nóng thành nhiều partition
        ↓
    Giảm đáng kể vấn đề hot partition so với trước

Nhưng nó không xoá bỏ hoàn toàn giới hạn: trần 3.000 RCU và 1.000 WCU mỗi partition vẫn còn, và một item duy nhất được đọc cực nhiều vẫn vượt được trần đó. Với vận động viên siêu nổi tiếng, DAX vẫn là giải pháp đúng.

Và giải pháp căn bản nhất là thiết kế khoá:

Write sharding: thêm hậu tố ngẫu nhiên vào partition key
    van-dong-vien#001-1, van-dong-vien#001-2, ... #001-10
        ↓
    Trải một thực thể nóng qua 10 partition
    → nhưng đòi refactor, trái yêu cầu của đề

Ghi nhớ

DAX và ElastiCache — bảng phân biệt cốt lõi: | | DAX | ElastiCache | |---|---|---| | Dùng cho | CHỈ DynamoDB | mọi nguồn dữ liệu | | Sửa mã ứng dụng | chỉ đổi client | phải viết logic đệm | | Vô hiệu hoá cache | TỰ ĐỘNG khi ghi qua DAX | tự lo | | Cấu trúc dữ liệu | chỉ item DynamoDB | phong phú (sorted set, geo) | | Độ trễ | micro giây | micro giây |

Quy tắc: đệm DynamoDB thì dùng DAX, trừ khi cần cấu trúc dữ liệu của Redis.

Hai loại cache trong DAX: | Loại | Đệm gì | TTL mặc định | |---|---|---| | Item cache | GetItem, BatchGetItem | 5 phút | | Query cache | Query, Scan | 5 phút |

Và query cache bị xoá sạch khi có ghi vào bảng:

Ghi một item bất kỳ
    → toàn bộ query cache của bảng bị vô hiệu
        ↓
    Bảng ghi nhiều thì query cache gần như vô dụng
    → nhưng item cache vẫn hiệu quả

Ba lưu ý quan trọng về DAX: | Lưu ý | Chi tiết | |---|---| | Nhất quán CUỐI CÙNG | ConsistentRead=True đi thẳng tới DynamoDB, bỏ qua cache | | Chỉ chạy trong VPC | không gọi từ Internet | | Có phí theo node-giờ | như ElastiCache |

Ba nguyên nhân gây hot partition: | Nguyên nhân | Ví dụ | |---|---| | Một thực thể được truy cập cực nhiều | ← câu này | | Partition key có ít giá trị | ví dụ dùng "loại" làm khoá | | Khoá theo thời gian tăng dần | mọi ghi mới vào cùng partition |

Ba cách xử lý hot partition: | Cách | Chi tiết | |---|---| | DAX cho hot READ | ← câu này, ít refactor nhất | | Write sharding cho hot WRITE | thêm hậu tố ngẫu nhiên | | Thiết kế lại partition key | giải pháp căn bản |

Ba giới hạn của DynamoDB cần nhớ: | Giới hạn | Giá trị | |---|---| | Kích thước item | 400 KB | | Thông lượng mỗi partition | 3.000 RCU hoặc 1.000 WCU | | Số GSI mỗi bảng | 20 |

Ba metric để phát hiện hot partition: | Metric | Ý nghĩa | |---|---| | ThrottledRequests | bị giới hạn dù bảng còn dung lượng | | ConsumedReadCapacityUnits | so với dung lượng đã cấp | | CloudWatch Contributor Insights | partition key nào bị truy cập nhiều nhất |

Contributor Insights rất hữu ích:

aws dynamodb update-contributor-insights --table-name van-dong-vien   --contributor-insights-action ENABLE

Nó cho biết:
    ✓ partition key nào được truy cập nhiều nhất
    ✓ key nào bị throttle nhiều nhất
        ↓
    Xác nhận chính xác item nào là "nóng"

Ba metric của DAX cần theo dõi: | Metric | Ý nghĩa | |---|---| | ItemCacheHits và ItemCacheMisses | tỷ lệ trúng cache | | QueryCacheHits | hiệu quả của query cache | | CPUUtilization của node DAX | |

Ba cấu hình cho DAX sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Ít nhất 3 node | trải qua nhiều AZ | | Subnet group ở nhiều AZ | | | Security group cho phép từ ứng dụng | cổng 8111 (hoặc 9111 cho TLS) |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | DAX tính theo node-giờ | | | Nhưng giảm RCU cần thiết của DynamoDB | có thể bù lại | | Với tải đọc rất cao, thường tiết kiệm tổng thể | |

Và một lời khuyên: hãy bật Contributor Insights trước khi triển khai DAX. Nó xác nhận vấn đề thật sự là hot partition do vài item cụ thể — và nếu hoá ra lưu lượng phân bố đều mà vẫn bị throttle, nguyên nhân là thiết kế khoá chứ không phải độ nóng, và DAX sẽ không giải quyết được.

Đáp án

D — Bật chế độ thông lượng BURSTING trên file system, dùng cùng General Purpose performance mode và EFS Standard storage class.

Vì sao đúng

Đề nêu hai đặc điểm tải, và bursting khớp với cả hai: | Đặc điểm | Cơ chế | |---|---| | Đợt tải nặng KHÔNG ĐOÁN TRƯỚC | burst credit cho phép vượt baseline | | Thông lượng TRUNG BÌNH hằng ngày THẤP | tích luỹ credit trong lúc nhàn rỗi |

Cách chế độ bursting hoạt động:

Khi dùng DƯỚI baseline:
    → TÍCH LUỸ burst credit

Khi cần thông lượng cao:
    → TIÊU credit để vượt baseline
        ↓
    Tải theo đợt với trung bình thấp = mô hình lý tưởng

Công thức của chế độ Bursting:

Baseline = 50 KB/giây × số GiB lưu trữ
Burst    = 100 MB/giây × số TiB (tối thiểu 100 MB/giây)

Và vì sao "không cấp phát thủ công":

"without provisioning throughput manually"
    ↓
    Bursting: tự động, không khai gì
    Provisioned: phải khai con số cụ thể

Cấu hình:

aws efs create-file-system   --throughput-mode bursting   --performance-mode generalPurpose   --encrypted

Và General Purpose là chế độ hiệu năng đúng:

General Purpose: độ trễ THẤP NHẤT
Max I/O:         thông lượng cao hơn nhưng ĐỘ TRỄ CAO HƠN
        ↓
    Với tải xử lý tệp thông thường, General Purpose phù hợp hơn

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

• **A. Đổi sang chế độ provisioned và khai giá trị thông lượng — đây là phương án gần nhất và đảm bảo thông lượng cao, nhưng nó vi phạm yêu cầu rõ ràng nhất: đề nói "without provisioning throughput manually". Và provisioned tính phí liên tục dù thông lượng trung bình thấp — không tối ưu chi phí.
• **C. Bật lớp Infrequent Access (IA) để giảm chi phí lưu trữ — giải quyết vấn đề khác: IA giảm chi phí lưu trữ, không liên quan tới chế độ thông lượng. Và IA có phí truy xuất làm tăng chi phí khi có đợt đọc nhiều.
• **B. Đổi sang EFS One Zone để giảm chi phí, "việc này tự bật burst throughput" — sai nhân quả: lớp lưu trữ và chế độ thông lượng là hai cấu hình độc lập. One Zone không tự bật gì cả, và nó còn giảm độ bền xuống một AZ.

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

Câu này phản ánh cách phân loại trước khi có Elastic throughput, và AWS đã đổi khuyến nghị.

Từ 2023, EFS có chế độ Elastic throughput và AWS đặt nó làm mặc định được khuyến nghị: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định mới) | tự co giãn tới hàng GB/giây, trả theo lượng dùng THẬT | | Bursting | theo dung lượng, có credit — HẾT CREDIT thì tụt về baseline | | Provisioned | khai trước, tính phí dù không dùng |

Elastic throughput:
    ✓ KHÔNG có credit để hết
    ✓ KHÔNG có trần theo dung lượng
    ✓ trả theo lượng dữ liệu đọc ghi thật
        ↓
    Với tải "đợt bùng phát, trung bình thấp" như trong đề,
    Elastic thường RẺ HƠN và AN TOÀN HƠN Bursting

Điểm yếu của Bursting là hết credit: nếu đợt bùng phát kéo dài hơn lượng credit tích luỹ, thông lượng tụt về baseline (có thể chỉ vài MB/giây với file system nhỏ) và tải chậm đột ngột.

(Đáp án D vẫn đúng theo các phương án cho sẵn — trong ba chế độ được nêu, Bursting là chế độ tự động không cần cấp phát thủ công.)

Ghi nhớ

Ba chế độ thông lượng của EFS — bảng phải thuộc: | Chế độ | Cách tính | Có credit | |---|---|---| | Elastic | theo lượng đọc ghi thật | ❌ | | Bursting | theo dung lượng lưu trữ | ✅ | | Provisioned | khai trước, tính phí liên tục | ❌ |

Và hai chế độ HIỆU NĂNG (khác với chế độ thông lượng): | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất | | Max I/O | thông lượng cao hơn, độ trễ cao hơn |

Nhầm lẫn giữa "performance mode" và "throughput mode" là bẫy phổ biến — chúng là hai cấu hình độc lập.

Công thức của Bursting — nên nhớ:

Baseline = 50 KB/giây mỗi GiB
    ↓
    File system 100 GiB → baseline chỉ 5 MB/giây
    File system 1 TiB   → baseline ~50 MB/giây

Metric quan trọng với Bursting:

BurstCreditBalance
    → giảm dần khi vượt baseline
    → về 0 → thông lượng TỤT về baseline
        ↓
    Phải đặt alarm cho metric này

aws cloudwatch put-metric-alarm --alarm-name efs-het-credit   --metric-name BurstCreditBalance --namespace AWS/EFS   --dimensions Name=FileSystemId,Value=fs-0abc   --statistic Average --period 300 --threshold 1000000000000   --comparison-operator LessThanThreshold

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | Phí truy xuất | |---|---|---| | Standard | ~0,30 USD/GB-tháng | KHÔNG | | Standard-IA | ~0,025 USD/GB-tháng | CÓ | | Archive | ~0,008 USD/GB-tháng | CÓ | | One Zone (và IA) | rẻ hơn ~47% | |

Và lifecycle tự phân tầng:

aws efs put-lifecycle-configuration --file-system-id fs-0abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Quy tắc thứ hai đưa tệp trở lại Standard khi được đọc — tránh tích tụ phí truy xuất.

Ba cách tăng hiệu năng EFS: | Cách | Chi tiết | |---|---| | Dùng Elastic throughput | bỏ trần theo dung lượng | | Mount target cùng AZ với instance | giảm độ trễ | | Tham số nconnect khi mount | nhiều kết nối TCP song song |

Ba lưu ý về PercentIOLimit: | Lưu ý | Chi tiết | |---|---| | Gần 100% = chạm trần chế độ HIỆU NĂNG | không phải chế độ thông lượng | | Chỉ áp cho General Purpose | | | Nếu thường xuyên gần 100% | cân nhắc Max I/O hoặc FSx for Lustre |

Ba lựa chọn lưu trữ chia sẻ: | Lựa chọn | Phù hợp | |---|---| | EFS | NFS đơn giản, tự co giãn ← câu này | | FSx for Lustre | HPC, thông lượng cao nhất | | S3 | object, rẻ nhất |

FSx for Lustre đáng cân nhắc cho tải phân tích gen:

FSx for Lustre:
    → hàng trăm GB/giây
    → tích hợp S3 (lazy loading)
    → dựng theo đợt rồi xoá
        ↓
    Phù hợp với "đợt tải nặng, trung bình thấp"

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BurstCreditBalance | chỉ với Bursting — về 0 là tụt tốc | | MeteredIOBytes | thông lượng thực tế | | PercentIOLimit | chạm trần chế độ hiệu năng |

Ba cách giảm chi phí EFS: | Cách | Tiết kiệm | |---|---| | Lifecycle sang IA | ~90% cho tệp cũ | | Elastic throughput | không trả cho thông lượng không dùng | | One Zone cho dữ liệu tái tạo được | ~47% |

Và một lời khuyên: hãy đo BurstCreditBalance trong vài tuần nếu quyết định dùng Bursting. Với tải theo đợt, credit có thể vừa đủ hoặc cạn giữa chừng — và nếu thấy nó chạm 0 trong lúc đang xử lý, chuyển sang Elastic throughput sẽ giải quyết mà vẫn không phải cấp phát thủ công.