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

Đáp án

C — Tạo EC2 instance dựa trên Nitro với MỘT EBS Provisioned IOPS SSD (io1) gắn vào, cấp 64.000 IOPS cho volume đó.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều dẫn tới cùng một cấu hình: | Yêu cầu | Cơ chế | |---|---| | 64.000 IOPS | io1 đạt tối đa 64.000 IOPS | | Nếu được thì trên MỘT volume duy nhất | io1 làm được, không cần RAID |

Và "Nitro" là điều kiện bắt buộc, không phải chi tiết trang trí:

io1 đạt 64.000 IOPS CHỈ trên instance dựa trên hệ thống Nitro
    → instance thế hệ cũ trần ở 32.000 IOPS
        ↓
    Đây là lý do phương án C nêu rõ "Nitro-based"

Tạo volume:

aws ec2 create-volume --availability-zone ap-northeast-1a   --size 1300 --volume-type io1 --iops 64000 --encrypted

⚠ Và tỷ lệ IOPS trên dung lượng phải thoả:

io1: tối đa 50 IOPS mỗi GB
    → 64.000 IOPS cần ít nhất 1.280 GB
        ↓
    Cấp volume nhỏ hơn sẽ bị từ chối

Và băng thông EBS của instance cũng là trần:

Volume cấp 64.000 IOPS
    → nhưng instance chỉ có băng thông EBS cho 30.000 IOPS
        ↓
    Trả tiền cho 64.000 mà dùng được 30.000
    → phải chọn loại instance TƯƠNG XỨNG

Ba họ instance có băng thông EBS cao: | Họ | Đặc điểm | |---|---| | r5b | băng thông EBS cao nhất trong họ r | | m6i, c6i, r6i | Nitro thế hệ mới | | x2idn, x2iedn | bộ nhớ lớn cho database |

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

• **B. Hai volume io1 mỗi cái 32.000 IOPS, gộp bằng logical volume — đây là phương án gần nhất và đạt được tổng 64.000 IOPS, nhưng nó vi phạm yêu cầu "nếu có thể thì dùng MỘT volume": đề nêu rõ ưu tiên đó, và io1 trên Nitro đáp ứng được nên không cần gộp.
• **D. Bốn volume gp2 RAID 0 — không đạt IOPS: gp2 tối đa 16.000 IOPS mỗi volume, bốn cái là 64.000 về lý thuyết nhưng gp2 có cơ chế credit và không đảm bảo mức đó liên tục. Và vẫn là nhiều volume.
• **A. Dùng họ I3 với instance store — KHÔNG BỀN VỮNG: đề nói rõ đây là database persistent, mà instance store mất dữ liệu khi stop hoặc hỏng phần cứng.

Ghi nhớ

Các loại EBS volume — bảng phải thuộc: | Loại | IOPS tối đa | Ghi chú | |---|---|---| | gp3 | 16.000 | 3.000 IOPS baseline miễn phí | | gp2 | 16.000 | có credit | | io1 | 64.000 (Nitro) | 50 IOPS/GB | | io2 | 64.000 (Nitro) | 500 IOPS/GB, độ bền 99,999% | | io2 Block Express | 256.000 | 1.000 IOPS/GB | | st1 / sc1 | 500 / 250 | HDD |

io2 tốt hơn io1 ở mọi mặt với giá NGANG NHAU — không có lý do chọn io1 cho thiết kế mới.

Ba giới hạn cần nhớ về io1/io2: | Giới hạn | Giá trị | |---|---| | IOPS tối đa trên Nitro | 64.000 | | IOPS tối đa trên instance cũ | 32.000 | | Tỷ lệ IOPS trên GB | io1: 50, io2: 500 |

io2 dễ đạt IOPS cao hơn nhiều:

64.000 IOPS với io1: cần ≥ 1.280 GB
64.000 IOPS với io2: cần ≥ 128 GB
        ↓
    io2 tiết kiệm dung lượng không cần thiết

Ba yếu tố quyết định IOPS thực tế: | Yếu tố | Chi tiết | |---|---| | IOPS cấp cho volume | | | Băng thông EBS của instance | thường là trần thật sự | | Kích thước khối I/O | |

Kiểm tra băng thông EBS của loại instance:

aws ec2 describe-instance-types --instance-types r5b.4xlarge   --query 'InstanceTypes[].EbsInfo.EbsOptimizedInfo'

Ba lý do ưu tiên một volume thay vì RAID: | Lý do | Chi tiết | |---|---| | Đơn giản hơn | không phải cấu hình RAID | | Snapshot nhất quán dễ hơn | RAID cần đồng bộ nhiều volume | | Ít chỗ hỏng hơn | |

Snapshot với RAID là vấn đề thật:

Snapshot nhiều volume KHÔNG đồng thời
    → khôi phục ra RAID không nhất quán
        ↓
    Phải dừng ghi hoặc dùng multi-volume snapshot

Multi-volume snapshot giải quyết:

aws ec2 create-snapshots --instance-specification InstanceId=i-0abc   --description "Snapshot dong bo moi volume"

Ba tính năng riêng của io1/io2: | Tính năng | Chi tiết | |---|---| | Multi-Attach | gắn vào tới 16 instance cùng AZ | | Đảm bảo IOPS 99,9% thời gian | | | io2 có độ bền 99,999% | gấp 100 lần io1 |

Ba metric để đánh giá: | Metric | Ý nghĩa | |---|---| | VolumeReadOps + VolumeWriteOps | IOPS thực tế | | VolumeQueueLength | cao liên tục = thiếu IOPS | | VolumeThroughputPercentage | |

VolumeQueueLength là chỉ báo tốt nhất:

Queue length > 1 cho mỗi 1.000 IOPS đã cấp
    → volume không theo kịp
Queue length gần 0 mà IOPS cấp cao
    → đang trả tiền thừa

Ba lưu ý về chi phí io1/io2: | Khoản | Giá tham khảo | |---|---| | Dung lượng | ~0,125 USD/GB-tháng | | IOPS | ~0,065 USD mỗi IOPS-tháng | | — | 64.000 IOPS ≈ 4.160 USD/tháng chỉ phần IOPS |

Con số này rất lớn — nên đo IOPS thật trước khi cấp.

Ba cách tối ưu chi phí lưu trữ database: | Cách | Tiết kiệm | |---|---| | Đo IOPS thật rồi cấp đúng mức | thường rất nhiều | | Cân nhắc gp3 nếu dưới 16.000 IOPS | rẻ hơn nhiều | | Dùng RDS thay vì tự quản | ít công vận hành |

Ba lưu ý khi chạy database trên EC2: | Lưu ý | Chi tiết | |---|---| | Chọn instance EBS-optimized | mặc định trên thế hệ mới | | Snapshot phải nhất quán với database | dùng cơ chế của database | | Tự lo Multi-AZ và sao lưu | |

Ba lựa chọn thay thế: | Lựa chọn | Đặc điểm | |---|---| | RDS | ít công vận hành nhất | | Aurora | lưu trữ tự co giãn, không cần cấp IOPS | | EC2 tự quản | ← câu này, kiểm soát nhiều nhất |

Aurora đáng cân nhắc:

Aurora không có khái niệm cấp IOPS
    → lưu trữ tự co giãn, I/O tính theo lượng dùng
        ↓
    Bỏ hẳn bài toán chọn loại volume và số IOPS

Và một lời khuyên: hãy kiểm tra băng thông EBS của loại instance trước khi cấp 64.000 IOPS. Rất nhiều hệ thống trả tiền cho mức IOPS mà instance không bao giờ đẩy tới được — và đó là khoản lãng phí hàng nghìn USD mỗi tháng mà không có cảnh báo nào chỉ ra.

Đáp án

D — EBS General Purpose SSD (gp2).

Vì sao đúng

Đề nêu ba đặc điểm tải, và cả ba khớp với gp2: | Đặc điểm | Kết luận | |---|---| | 250 GB dung lượng | gp2 cho baseline 750 IOPS ở mức này | | Ứng dụng ÍT dùng, có đỉnh nhỏ buổi sáng và chiều | tích luỹ credit lúc nhàn, bùng phát khi cần | | Đỉnh tối đa 3.000 IOPS | gp2 bùng phát ĐÚNG tới 3.000 IOPS |

Con số 3.000 IOPS là chữ ký của gp2:

gp2 baseline = 3 IOPS mỗi GB
    → 250 GB × 3 = 750 IOPS baseline

gp2 burst = tới 3.000 IOPS
    → cho volume dưới 1.000 GB
        ↓
    Đỉnh 3.000 IOPS khớp CHÍNH XÁC khả năng bùng phát của gp2

Và mẫu tải "ít dùng, có đỉnh ngắn" là mô hình lý tưởng cho credit:

Ứng dụng nhàn rỗi phần lớn thời gian
    → TÍCH LUỸ burst credit
    → đỉnh buổi sáng và chiều tiêu credit
        ↓
    Đỉnh ngắn → credit không bao giờ cạn

Tạo volume:

aws ec2 create-volume --availability-zone ap-northeast-1a   --size 250 --volume-type gp2 --encrypted

Và io1 là lãng phí lớn ở đây:

io1 cấp 3.000 IOPS:
    Dung lượng: 250 GB × 0,125 = 31 USD
    IOPS: 3.000 × 0,065 = 195 USD
        ↓
    Tổng ~226 USD/tháng

gp2 250 GB: 250 × 0,10 = 25 USD/tháng
        ↓
    Rẻ hơn khoảng 9 lần cho cùng hiệu năng đỉnh

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

• **B. Provisioned IOPS SSD (io1) — đây là phương án gần nhất và chắc chắn đạt 3.000 IOPS ổn định, nhưng nó đắt hơn nhiều lần một cách không cần thiết: tải chỉ có đỉnh ngắn, không cần IOPS đảm bảo liên tục. Đề hỏi "MOST cost-effective".
• **C. Throughput Optimized HDD (st1) — IOPS quá thấp: st1 tối ưu cho thông lượng tuần tự, IOPS chỉ khoảng 500. Không đạt 3.000.
• **A. Cold HDD (sc1) — chậm nhất trong mọi lựa chọn, dành cho dữ liệu hiếm truy cập.

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

Đáp án là gp2, nhưng gp3 mới là lựa chọn đúng ngày nay.

Với đúng bài toán trong đề:
    gp2 250 GB: baseline 750 IOPS, burst 3.000 (tốn credit)
    gp3 250 GB: 3.000 IOPS LIÊN TỤC, không credit
        ↓
    gp3 vừa RẺ HƠN 20% vừa cho 3.000 IOPS ổn định
        ↓
    AWS khuyến nghị gp3 làm mặc định cho mọi tải mục đích chung

Điểm yếu của gp2 là hết credit: nếu đỉnh kéo dài hơn lượng credit tích luỹ, IOPS tụt về 750 và ứng dụng chậm đột ngột. Với mô tả "spikes" ngắn thì gp2 vẫn đủ, nhưng gp3 loại bỏ hẳn rủi ro đó mà còn rẻ hơn.

(Đáp án D vẫn đúng theo các phương án cho sẵn — gp3 không có trong danh sách.)

Ghi nhớ

Các loại EBS volume — bảng phải thuộc: | Loại | IOPS | Phù hợp | |---|---|---| | gp3 | 3.000 baseline, tới 16.000 | mặc định khuyến nghị | | gp2 | 3 IOPS/GB, burst 3.000 | thế hệ trước | | io1 / io2 | tới 64.000 | IOPS cao liên tục | | st1 | ~500 | thông lượng tuần tự | | sc1 | ~250 | lưu trữ lạnh |

Từ khoá nhận diện:

"general purpose", "cost-effective", "occasional spikes" → gp3 (hoặc gp2) "sustained high IOPS", "critical database" → io2 | "big data, sequential, throughput" → st1 "lowest cost, rarely accessed" → sc1

Cơ chế burst credit của gp2 — nên hiểu rõ:

Baseline = 3 IOPS × số GB (tối thiểu 100, tối đa 16.000)
Burst    = tới 3.000 IOPS cho volume dưới 1.000 GB
        ↓
Dùng DƯỚI baseline → tích luỹ credit
Dùng TRÊN baseline → tiêu credit
Hết credit         → TỤT về baseline

Metric cần theo dõi với gp2:

BurstBalance
    → giảm dần khi vượt baseline
    → về 0 → IOPS tụt về baseline
        ↓
    Đặt alarm cho metric này

aws cloudwatch put-metric-alarm --alarm-name gp2-het-credit   --metric-name BurstBalance --namespace AWS/EBS   --dimensions Name=VolumeId,Value=vol-0abc   --statistic Average --period 300 --threshold 20   --comparison-operator LessThanThreshold

Ba volume gp2 lớn hơn 1.000 GB:

Volume trên 1.000 GB có baseline ≥ 3.000 IOPS
    → KHÔNG còn cơ chế burst
    → luôn chạy ở baseline
        ↓
    3.334 GB trở lên đạt trần 16.000 IOPS

Chuyển gp2 sang gp3:

aws ec2 modify-volume --volume-id vol-0abc --volume-type gp3

Chuyển đổi trực tuyến, không cần ngừng.

Chuyển hàng loạt:

aws ec2 describe-volumes --filters Name=volume-type,Values=gp2   --query 'Volumes[].VolumeId' --output text |   xargs -n1 -I{} aws ec2 modify-volume --volume-id {} --volume-type gp3

Ba metric để đánh giá volume: | Metric | Ý nghĩa | |---|---| | VolumeReadOps + VolumeWriteOps | IOPS thực tế | | BurstBalance | chỉ gp2 | | VolumeQueueLength | cao liên tục = thiếu IOPS |

Ba lưu ý về thay đổi volume: | Lưu ý | Chi tiết | |---|---| | Đổi loại, tăng dung lượng, đổi IOPS — không cần ngừng | | | Phải chờ 6 giờ giữa hai lần đổi | | | KHÔNG giảm dung lượng được | |

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | AWS Compute Optimizer | khuyến nghị loại volume theo mức dùng thật | | Cost Explorer | chi phí theo loại | | CloudWatch | metric IOPS |

Ba cách tối ưu chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20% | | Bỏ io1/io2 nếu không cần IOPS cao liên tục | rất nhiều | | Xoá volume và snapshot không dùng | |

Và một lời khuyên: hãy chuyển toàn bộ gp2 sang gp3 ngay cả khi gp2 đang đáp ứng đủ. Đó là một lệnh duy nhất cho mỗi volume, không cần ngừng, rẻ hơn 20%, và loại bỏ hẳn rủi ro cạn credit — hiếm có thay đổi nào vừa rẻ hơn vừa tốt hơn mà không có đánh đổi nào.

Đáp án

B và C.

• B — Thêm origin cho bucket ap-southeast-1 vào CloudFront
• C — Tạo origin group với bucket us-east-1 làm chính và ap-southeast-1 làm phụ

Vì sao đúng

Đề yêu cầu tăng tính sẵn sàng của website, và CloudFront có cơ chế dựng sẵn cho việc này.

Origin group (origin failover):
    → khai origin CHÍNH và origin PHỤ
    → origin chính trả lỗi hoặc timeout
    → CloudFront TỰ CHUYỂN sang origin phụ
        ↓
    Người dùng không thấy gián đoạn

Và hai đáp án là hai bước của cùng một việc:

B: thêm origin thứ hai vào distribution
C: gộp hai origin thành origin group với thứ tự ưu tiên
        ↓
    Thiếu bước B thì không có gì để gộp

Cấu hình origin group:

{"OriginGroups": {"Quantity": 1, "Items": [{
  "Id": "nhom-origin",
  "FailoverCriteria": {"StatusCodes": {
    "Quantity": 4, "Items": [403, 404, 500, 503]}},
  "Members": {"Quantity": 2, "Items": [
    {"OriginId": "s3-us-east-1"},
    {"OriginId": "s3-ap-southeast-1"}]}}]}}

FailoverCriteria quyết định khi nào chuyển: | Mã | Ý nghĩa | |---|---| | 403, 404 | object không truy cập được | | 500, 502, 503, 504 | origin lỗi | | — | cũng chuyển khi timeout kết nối |

Và cache behavior trỏ tới origin group thay vì origin đơn:

{"DefaultCacheBehavior": {"TargetOriginId": "nhom-origin", ...}}

⚠ Ba lưu ý quan trọng về origin failover: | Lưu ý | Chi tiết | |---|---| | CHỈ áp cho request GET, HEAD, OPTIONS | không cho PUT, POST | | Cần OAC cho CẢ HAI bucket | | | Cross-region replication phải đang hoạt động | nội dung phải có ở cả hai |

Và vì sao Route 53 không phải lựa chọn ở đây:

Website đã phục vụ qua CloudFront
    → Route 53 chỉ phân giải tên miền tới CloudFront
    → nó KHÔNG biết origin nào hỏng
        ↓
    Failover phải xảy ra Ở TẦNG CLOUDFRONT

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

• **D. Tạo origin cho CẢ HAI bucket trong CloudFront — đây là phương án gần nhất và thực chất trùng với đáp án B, nhưng nó thiếu bước quyết định: chỉ tạo hai origin mà không gộp thành origin group thì CloudFront vẫn chỉ dùng origin được khai trong cache behavior, không có failover nào.
• **A. Thiết lập failover routing trong Route 53 — sai tầng: Route 53 định tuyến tên miền, nó không phát hiện được bucket origin phía sau CloudFront có hỏng hay không.
• **E. Trỏ Route 53 tới bucket bản sao bằng một bản ghi — cũng sai tầng, và trỏ thẳng tới bucket sẽ bỏ qua CloudFront hoàn toàn.

Ghi nhớ

Ba cơ chế sẵn sàng của CloudFront: | Cơ chế | Việc | |---|---| | Origin group (origin failover) | chuyển sang origin phụ khi origin chính hỏng | | Origin Shield | thêm lớp đệm trước origin | | Edge caching | phục vụ từ cache khi origin chậm |

Ba điều kiện để origin failover hoạt động: | Điều kiện | Chi tiết | |---|---| | Hai origin đã khai trong distribution | ← đáp án B | | Origin group với thứ tự ưu tiên | ← đáp án C | | Cache behavior trỏ tới origin GROUP | |

Ba mã lỗi thường đưa vào FailoverCriteria: | Mã | Khi nào | |---|---| | 403 | quyền hoặc bucket không truy cập được | | 404 | object không tồn tại | | 500, 502, 503, 504 | origin lỗi |

⚠ Cẩn thận với 404:

Đưa 404 vào tiêu chí failover
    → mọi request tới object không tồn tại
      đều thử origin phụ
        ↓
    Tăng độ trễ cho lỗi 404 hợp lệ
    → cân nhắc chỉ dùng 5xx

Ba yêu cầu của Cross-Region Replication: | Yêu cầu | Chi tiết | |---|---| | Versioning bật ở CẢ HAI bucket | bắt buộc | | IAM role cho S3 sao chép | | | Chỉ sao chép object MỚI | object cũ cần Batch Replication |

Dòng cuối là điểm hay bị bỏ sót:

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject":{}}'   --manifest-generator file://manifest.json --priority 10 --role-arn <arn>

Ba lưu ý về OAC với hai bucket: | Lưu ý | Chi tiết | |---|---| | Mỗi bucket cần bucket policy riêng | cho phép CloudFront | | Dùng CÙNG một OAC được | | | Cả hai bucket giữ Block Public Access | |

Bucket policy cho bucket phụ:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::ban-sao-ap-southeast-1/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

Ba lựa chọn khác cho sẵn sàng cao của website tĩnh: | Lựa chọn | Đặc điểm | |---|---| | Origin group | ← câu này, đơn giản nhất | | S3 Multi-Region Access Point | một endpoint, tự định tuyến | | Route 53 failover tới hai CloudFront distribution | phức tạp hơn |

Multi-Region Access Point đáng biết:

Một endpoint toàn cầu cho nhiều bucket
    → tự định tuyến tới bucket gần nhất và khoẻ mạnh
    → dùng làm origin của CloudFront được
        ↓
    Kết hợp cả định tuyến theo độ trễ lẫn failover

Ba lưu ý về Origin Shield: | Lưu ý | Chi tiết | |---|---| | Thêm một lớp đệm trung gian | | | Giảm số request tới origin | | | Có phí riêng | |

Ba lưu ý về cache khi có failover: | Lưu ý | Chi tiết | |---|---| | Nội dung đã đệm vẫn phục vụ được khi origin hỏng | | | Cache-Control dài giúp chịu lỗi tốt hơn | | | Stale-while-revalidate hữu ích | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | OriginLatency | origin chậm | | 5xxErrorRate | origin hỏng | | CacheHitRate | tỷ lệ phục vụ từ cache |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Bucket thứ hai tính phí lưu trữ đầy đủ | | | Phí sao chép xuyên Region | ~0,02 USD/GB | | Origin group KHÔNG tính phí thêm | |

Ba việc nên làm để kiểm chứng: | Việc | Chi tiết | |---|---| | Tạm chặn quyền của bucket chính | xem có chuyển không | | Kiểm tra nội dung ở bucket phụ đầy đủ | | | Đo thời gian chuyển đổi | |

Và một lời khuyên: hãy kiểm tra bucket bản sao có đủ nội dung không trước khi tin vào origin group. Cross-Region Replication chỉ sao chép object được tạo sau khi bật — và nếu website đã có sẵn hàng nghìn tệp trước đó, origin phụ sẽ trả 404 cho phần lớn nội dung đúng lúc bạn cần nó nhất.

Đáp án

A — Dùng S3 Intelligent-Tiering để tự điều chỉnh chi phí theo tần suất truy cập, giữ độ bền cao nhất.

Vì sao đúng

Đề nêu ba yêu cầu, và Intelligent-Tiering đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Một số dữ liệu dùng hằng ngày, số khác nằm im hàng tháng | mẫu truy cập KHÁC NHAU giữa các object | | Độ bền CAO NHẤT | S3 cho 11 số 9, trải ≥3 AZ | | Giảm chi phí, không ảnh hưởng dữ liệu hay dùng | tự phân tầng, KHÔNG phí truy xuất |

Vế đầu là điều kiện lý tưởng cho Intelligent-Tiering:

Không đoán được dataset nào sẽ nóng
    → không đặt được một quy tắc lifecycle chung
        ↓
    S3 theo dõi truy cập của TỪNG object
    → tự chuyển tầng theo hành vi thật
    → object được đọc lại TỰ QUAY VỀ tầng nóng

Và điểm quan trọng nhất: KHÔNG có phí truy xuất.

Standard-IA: rẻ hơn nhưng phí truy xuất ~0,01 USD/GB
    → dataset bất ngờ được dùng lại → ĐẮT HƠN Standard

Intelligent-Tiering: KHÔNG phí truy xuất
    → đoán sai cũng không bị phạt

Bốn tầng: | Tầng | Chuyển sau | Giá tham khảo | |---|---|---| | Frequent Access | — | ~0,023 USD/GB | | Infrequent Access | 30 ngày | ~0,0125 USD/GB | | Archive Instant Access | 90 ngày | ~0,004 USD/GB | | Archive / Deep Archive (tuỳ chọn) | 90/180 ngày | rẻ hơn nữa |

Ba tầng đầu đều truy xuất TỨC THÌ — nhà nghiên cứu không cảm nhận khác biệt.

Bật:

aws s3api put-bucket-intelligent-tiering-configuration   --bucket du-lieu-nghien-cuu --id tu-phan-tang   --intelligent-tiering-configuration '{
    "Id":"tu-phan-tang","Status":"Enabled","Filter":{},
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"}]}'

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

• **D. Dùng Glacier Instant Retrieval cho TẤT CẢ dataset — đây là phương án gần nhất và cũng lấy được tức thì với độ bền cao, nhưng nó sai với phần dữ liệu dùng HẰNG NGÀY: GIR có phí truy xuất cao gấp ba lần Standard-IA, nên dataset được đọc mỗi ngày sẽ đắt hơn nhiều so với để ở Standard.
• **C. Dùng EFS với lifecycle — đắt hơn S3 nhiều lần và không cần thiết: đề không nêu yêu cầu hệ thống tệp POSIX.
• **B. Dùng FSx for Lustre tích hợp S3 — giải quyết vấn đề khác: Lustre là hệ thống tệp hiệu năng cao cho HPC, đắt hơn nhiều và chỉ nằm ở một AZ.

Ghi nhớ

Quy tắc chọn giữa Lifecycle và Intelligent-Tiering: | Tình huống | Chọn | |---|---| | Mẫu truy cập ĐOÁN ĐƯỢC | Lifecycle (rẻ hơn) | | Mẫu truy cập KHÔNG đoán được | Intelligent-Tiering ← câu này | | Nhiều bucket, ít nhân lực | Intelligent-Tiering |

Ba đặc điểm của Intelligent-Tiering: | Đặc điểm | Chi tiết | |---|---| | Phí giám sát ~0,0025 USD/1.000 object/tháng | | | KHÔNG có phí truy xuất | ưu điểm lớn nhất | | Object tự quay về tầng nóng khi được đọc | |

Tính điểm hoà vốn:

Phí giám sát: 0,0025 USD mỗi 1.000 object/tháng
Tiết kiệm khi xuống IA: ~0,0105 USD/GB/tháng
        ↓
    Object trung bình phải lớn hơn ~250 KB
        ↓
    Dataset khoa học (thường rất lớn) → rất phù hợp

Ba trường hợp KHÔNG nên dùng: | Trường hợp | Lý do | |---|---| | Rất nhiều object NHỎ | phí giám sát vượt tiết kiệm | | Dữ liệu chắc chắn không đọc lại | Deep Archive rẻ hơn | | Dữ liệu sống dưới 30 ngày | không kịp xuống tầng |

Độ bền các lớp lưu trữ: | Lớp | Độ bền | Số AZ | |---|---|---| | Standard, IA, Intelligent-Tiering, Glacier | 99,999999999% | ≥3 | | One Zone-IA | 99,999999999% nhưng 1 AZ | 1 ⚠ |

Mọi lớp đều có 11 số 9 về độ bền — khác biệt nằm ở số AZ, tức là khả năng chịu mất một AZ.

Ba tuỳ chọn tầng lưu trữ sâu: | Tầng | Chuyển sau | Thời gian lấy | |---|---|---| | Archive Instant Access | 90 ngày, TỰ ĐỘNG | tức thì | | Archive Access | 90 ngày, tuỳ chọn | 3–5 giờ | | Deep Archive Access | 180 ngày, tuỳ chọn | 12 giờ |

Hai tầng cuối phải BẬT tường minh và KHÔNG lấy tức thì được.

Với dữ liệu nghiên cứu có thể được dùng bất chợt, chỉ nên bật tới Archive Instant Access.

Ba công cụ theo dõi: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố dung lượng theo tầng | | Cost Explorer | chi phí theo lớp | | S3 Storage Class Analysis | mẫu truy cập theo tuổi |

Ba quy tắc lifecycle nên có kèm: | Quy tắc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần dở dang | | Xoá phiên bản cũ | với versioning | | Xoá delete marker mồ côi | |

Ba lưu ý về dataset khoa học: | Lưu ý | Chi tiết | |---|---| | Tệp thường rất lớn | dùng multipart upload | | Nên nén nếu định dạng cho phép | | | Cân nhắc định dạng cột nếu cần phân tích | Parquet |

Ba cách phân tích dữ liệu trên S3: | Cách | Đặc điểm | |---|---| | Amazon Athena | SQL, serverless | | EMR / Glue | biến đổi phức tạp | | FSx for Lustre liên kết S3 | HPC, thông lượng cao |

FSx for Lustre đáng cân nhắc cho phần TÍNH TOÁN:

Giữ dữ liệu ở S3 (rẻ, bền)
    → dựng FSx for Lustre khi cần chạy phân tích
    → liên kết bucket, lazy loading
    → xoá cụm sau khi xong
        ↓
    Kết hợp cả hai thay vì chọn một

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Intelligent-Tiering rẻ hơn Standard sau 30 ngày | | | Phí giám sát nhỏ với object lớn | | | Không có phí truy xuất | quan trọng nhất |

Và một lời khuyên: hãy bật S3 Storage Lens sau vài tháng để xem tỷ lệ dữ liệu đã tự xuống tầng lạnh. Nếu con số thấp hơn nhiều so với dự đoán, nghĩa là dataset được truy cập thường xuyên hơn bạn tưởng — và đó là thông tin quan trọng cho cả việc lập kế hoạch chi phí lẫn việc hiểu cách các nhà nghiên cứu thực sự làm việc.

Đáp án

D — Dùng IAM Roles Anywhere cấp credential tạm thời cho ứng dụng; thiết lập quan hệ tin cậy và cấu hình ứng dụng assume role bằng credential đó.

Vì sao đúng

Đề nêu ba yêu cầu, và IAM Roles Anywhere được thiết kế đúng cho tình huống này: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng chạy TẠI CHỖ, không phải trên AWS | Roles Anywhere dành riêng cho workload ngoài AWS | | KHÔNG lưu credential dài hạn | credential tạm qua STS | | Quyền tối thiểu | IAM role với policy hẹp |

Cơ chế:

Máy chủ tại chỗ có CHỨNG CHỈ X.509
    → do một CA mà AWS tin cậy cấp
        ↓
    Ứng dụng dùng chứng chỉ đó gọi Roles Anywhere
    → nhận credential AWS TẠM THỜI
        ↓
    KHÔNG có access key nào được lưu ở đâu cả

Ba thành phần cần thiết lập: | Thành phần | Việc | |---|---| | Trust anchor | CA mà AWS tin cậy (ACM Private CA hoặc CA riêng) | | Profile | role nào được assume và session policy | | IAM role | quyền thật sự |

Thiết lập:

aws rolesanywhere create-trust-anchor --name ca-cong-ty   --source sourceType=CERTIFICATE_BUNDLE,sourceData={x509CertificateData=<pem>}

aws rolesanywhere create-profile --name ho-so-phan-tich   --role-arns arn:aws:iam::123456789012:role/vai-tro-doc-s3

Và ứng dụng lấy credential:

aws_signing_helper credential-process   --certificate chung-chi.pem --private-key khoa-rieng.pem   --trust-anchor-arn <arn-trust-anchor>   --profile-arn <arn-profile>   --role-arn arn:aws:iam::123456789012:role/vai-tro-doc-s3

Và cấu hình trong ~/.aws/config:

[profile phan-tich]
credential_process = /usr/bin/aws_signing_helper credential-process   --certificate /etc/pki/chung-chi.pem   --private-key /etc/pki/khoa-rieng.pem   --trust-anchor-arn ... --profile-arn ... --role-arn ...

SDK tự gọi và tự làm mới credential — ứng dụng không phải sửa gì.

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

• **A. Lưu access key và secret key trong Systems Manager Parameter Store — đây là phương án gần nhất và có mã hoá bí mật, nhưng nó vẫn là credential DÀI HẠN: đề nói rõ "avoid long-term credential storage". Và bản thân việc lấy được từ Parameter Store lại cần một credential khác — bài toán con gà quả trứng.
• **C. Triển khai Storage Gateway File Gateway truy cập qua NFS hoặc SMB — giải quyết vấn đề khác: nó cho truy cập tệp, nhưng đề nói ứng dụng cần truy cập tạm thời và an toàn với quyền tối thiểu, không phải một cổng truy cập thường trực.
• **B. Bucket policy cho phép theo dải IP công cộng của máy chủ tại chỗ — kiểm soát rất yếu: địa chỉ IP giả mạo được, IP có thể đổi, và không có danh tính nào để audit hay áp quyền tối thiểu.

Ghi nhớ

Ba cách cấp quyền AWS cho workload ngoài AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | IAM Roles Anywhere | chứng chỉ X.509 → credential tạm | | IAM user với access key | credential DÀI HẠN — tránh | | Web identity federation | cho ứng dụng có OIDC provider |

Từ khoá nhận diện:

"on-premises application", "temporary credentials", "no long-term keys" → IAM Roles Anywhere "EC2 instance" → instance profile "EKS Pod" → IRSA hoặc Pod Identity "Lambda" → execution role

Ba thành phần của IAM Roles Anywhere: | Thành phần | Việc | |---|---| | Trust anchor | CA được tin cậy | | Profile | role được phép assume | | IAM role | quyền, với trust policy cho rolesanywhere |

Trust policy của role:

{"Effect": "Allow",
 "Principal": {"Service": "rolesanywhere.amazonaws.com"},
 "Action": ["sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity"],
 "Condition": {"ArnEquals": {"aws:SourceArn": "<arn-trust-anchor>"}}}

Ba lựa chọn cho CA: | Lựa chọn | Chi tiết | |---|---| | AWS Private CA | được quản lý, tích hợp sẵn | | CA nội bộ của công ty | tải bundle chứng chỉ lên | | — | chứng chỉ phải còn hạn và không bị thu hồi |

Ba lợi ích so với access key: | Lợi ích | Chi tiết | |---|---| | Credential có hạn (mặc định 1 giờ) | | | Thu hồi bằng cách thu hồi chứng chỉ | | | Audit qua CloudTrail | thấy chứng chỉ nào assume role nào |

Ba cách áp quyền tối thiểu: | Cách | Chi tiết | |---|---| | IAM policy trên role | quyền cơ bản | | Session policy trong profile | thu hẹp thêm | | Condition theo thuộc tính chứng chỉ | |

Điều kiện theo chứng chỉ đáng biết:

{"Condition": {"StringEquals": {
  "aws:PrincipalTag/x509Subject/CN": "may-chu-phan-tich-01"}}}

Roles Anywhere gắn thuộc tính chứng chỉ thành session tag
    → policy phân biệt được từng máy chủ
        ↓
    Quyền tối thiểu tới cấp máy

Ba lưu ý về quản lý chứng chỉ: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ có hạn — phải gia hạn | | | Bảo vệ khoá riêng trên máy chủ | quyền tệp chặt | | Có quy trình thu hồi | CRL |

Ba dịch vụ liên quan: | Dịch vụ | Việc | |---|---| | AWS Private CA | cấp và quản lý chứng chỉ | | IAM Identity Center | cho CON NGƯỜI, không cho ứng dụng | | Secrets Manager | lưu bí mật, có xoay vòng |

Phân biệt quan trọng:

IAM Identity Center: nhân viên truy cập AWS
IAM Roles Anywhere:  ỨNG DỤNG ngoài AWS truy cập AWS
        ↓
    Đề nhắc Identity Center vì công ty đã dùng nó cho người,
      nhưng ứng dụng cần cơ chế khác

Ba lưu ý về signing helper: | Lưu ý | Chi tiết | |---|---| | Là công cụ mã nguồn mở của AWS | | | Tích hợp qua credential_process | SDK tự gọi | | Hỗ trợ PKCS#11 cho HSM | khoá không rời phần cứng |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Khoá riêng là bí mật quan trọng nhất | cân nhắc TPM hoặc HSM | | Đặt session duration ngắn | | | Theo dõi CloudTrail cho lời gọi bất thường | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | IAM Roles Anywhere MIỄN PHÍ | | | AWS Private CA có phí | ~400 USD/tháng mỗi CA | | Dùng CA nội bộ nếu đã có | tiết kiệm |

Ba việc nên làm khi triển khai: | Việc | Chi tiết | |---|---| | Thử với một máy chủ trước | | | Kiểm tra CloudTrail thấy đúng danh tính | | | Lập quy trình gia hạn chứng chỉ | |

Và một lời khuyên: hãy lập quy trình gia hạn chứng chỉ ngay khi triển khai. Credential tạm thời là ưu điểm lớn, nhưng nó phụ thuộc vào một chứng chỉ có hạn — và một chứng chỉ hết hạn lúc nửa đêm sẽ khiến toàn bộ ứng dụng mất quyền truy cập mà không có access key dự phòng nào để cứu.

Đáp án

B — Dùng Kinesis Data Streams nạp dữ liệu, xử lý bằng AWS Lambda.

Vì sao đúng

Đề nêu vấn đề rõ: lỗi 503 khi năng lực tính toán chạm trần lúc có đỉnh dữ liệu.

Nguyên nhân:
    → đối tác gửi thẳng vào EC2
    → EC2 không co giãn kịp
    → hết năng lực → trả 503
        ↓
    Cần TÁCH việc NHẬN khỏi việc XỬ LÝ

Kinesis Data Streams giải quyết vế nhận:

Kinesis on-demand tự co giãn tới 200 MB/giây
    → nhận được mọi đỉnh dữ liệu
    → KHÔNG bao giờ trả 503
        ↓
    Dữ liệu được giữ 1–365 ngày

Và Lambda giải quyết vế xử lý:

Lambda tự co giãn theo số shard
    → không có máy chủ nào để chạm trần
        ↓
    Xử lý theo nhịp của nó, dữ liệu chờ trong stream

Và "near-real time" là lý do chọn Kinesis:

Kinesis Data Streams: độ trễ dưới một giây
    → phù hợp với "near-real time" trong đề

Triển khai:

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

aws lambda create-event-source-mapping   --function-name xu-ly-du-lieu   --event-source-arn <arn-stream>   --starting-position LATEST   --batch-size 100 --maximum-batching-window-in-seconds 1   --parallelization-factor 4

Và ba lợi ích phụ: | Lợi ích | Chi tiết | |---|---| | Nhiều consumer đọc độc lập | thêm ứng dụng phân tích sau này | | Phát lại được dữ liệu | xử lý lại khi có lỗi logic | | Giữ thứ tự trong shard | |

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

• **A. Dùng SQS nạp dữ liệu, EC2 xử lý từ hàng đợi — đây là phương án gần nhất và cũng tách rời tốt, nhưng nó vẫn giữ EC2 làm tầng xử lý: phải tự co giãn ASG, và SQS không cho nhiều consumer đọc lại cùng dữ liệu. (Đây là kiến trúc hợp lệ, chỉ kém hơn về mức tự động và khả năng mở rộng phân tích sau này.)
• **C. Dùng SNS nạp dữ liệu rồi gọi Lambda — SNS KHÔNG giữ dữ liệu: nếu Lambda bị throttle hoặc lỗi, thông điệp mất. Nó là dịch vụ phát tán, không phải đệm.
• **D. Đặt API Gateway trước ứng dụng với usage plan giới hạn quota — giải quyết bằng cách TỪ CHỐI dữ liệu: giới hạn tần suất sẽ chặn đối tác gửi, đúng điều họ đang phàn nàn. Đó không phải cải thiện khả năng co giãn.

Ghi nhớ

Ba dịch vụ nạp dữ liệu — bảng phải thuộc: | Dịch vụ | Giữ dữ liệu | Nhiều consumer | |---|---|---| | Kinesis Data Streams | 1–365 ngày | ✅ | | SQS | tới 14 ngày | ❌ (một consumer lấy) | | SNS | ❌ không giữ | ✅ phát tán |

Từ khoá nhận diện:

"near-real time", "multiple consumers", "replay" → Kinesis Data Streams "decouple, one worker per message" → SQS "fan out notifications" → SNS

Hai chế độ dung lượng của Kinesis: | Chế độ | Đặc điểm | |---|---| | On-demand | tự co giãn tới 200 MB/giây | | Provisioned | khai shard, rẻ hơn khi tải ổn định |

Giới hạn của một shard: | Chiều | Giới hạn | |---|---| | Ghi | 1.000 bản ghi/giây HOẶC 1 MB/giây | | Đọc chia sẻ | 2 MB/giây | | Enhanced fan-out | 2 MB/giây riêng mỗi consumer |

Ba lưu ý về Lambda đọc từ Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard (mặc định) | | | ParallelizationFactor tới 10 | nhiều Lambda mỗi shard | | Lỗi CHẶN cả shard | phải cấu hình DLQ |

Cấu hình chống chặn shard:

{"MaximumRetryAttempts": 3,
 "BisectBatchOnFunctionError": true,
 "MaximumRecordAgeInSeconds": 3600,
 "DestinationConfig": {"OnFailure": {"Destination": "<arn-sqs>"}}}

Không có nó: một bản ghi lỗi chặn toàn bộ shard
    → dữ liệu phía sau không được xử lý

Ba lưu ý về partition key: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Phân bố ĐỀU tránh hot shard | | | Cùng key = cùng shard = giữ THỨ TỰ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại — quan trọng nhất | | WriteProvisionedThroughputExceeded | throttle phía ghi | | IncomingRecords | |

Ba mẫu kiến trúc thường thấy: | Mẫu | Chi tiết | |---|---| | Kinesis → Lambda → DynamoDB | thời gian thực | | Kinesis → Firehose → S3 | lưu trữ lâu dài | | Kinesis → Managed Flink | phân tích cửa sổ thời gian |

Nên làm cả hai mẫu đầu song song:

Kinesis Data Streams
    ├─→ Lambda: xử lý thời gian thực
    └─→ Firehose: đẩy vào S3 cho phân tích sau
        ↓
    Đúng yêu cầu "process and store for later analysis"

Ba cách đối tác gửi dữ liệu vào Kinesis: | Cách | Chi tiết | |---|---| | API Gateway → Kinesis (tích hợp trực tiếp) | giữ giao diện REST | | SDK gọi PutRecords | cần credential | | Kinesis Agent | cho tệp log |

Cách đầu giữ được giao diện REST hiện tại:

aws apigateway put-integration --rest-api-id abc --resource-id res   --http-method POST --type AWS --integration-http-method POST   --uri "arn:aws:apigateway:ap-northeast-1:kinesis:action/PutRecord"   --credentials <arn-role>

Đối tác vẫn gọi REST API như cũ
    → nhưng dữ liệu vào Kinesis thay vì EC2
        ↓
    Không phải đổi phía đối tác

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | On-demand đắt hơn provisioned khi tải cao ổn định | | | PUT payload unit tính theo đơn vị 25 KB | gộp lô tiết kiệm | | Lambda tính theo GB-giây | |

Ba lưu ý về gộp lô ở producer: | Lưu ý | Chi tiết | |---|---| | PutRecords tới 500 bản ghi mỗi lời gọi | | | Kiểm tra FailedRecordCount | có thể thành công MỘT PHẦN | | KPL aggregation gộp thành một bản ghi | |

Và một lời khuyên: hãy dùng tích hợp trực tiếp API Gateway với Kinesis để đối tác không phải đổi gì. Họ vẫn gọi cùng một REST endpoint, nhưng phía sau dữ liệu đi vào một hệ thống co giãn vô hạn thay vì một đội EC2 có trần — và bạn giải quyết được lỗi 503 mà không cần một cuộc đàm phán tích hợp nào.

Đáp án

C — Khởi động container trên Amazon EKS với worker node EC2.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều dẫn tới Kubernetes: | Yêu cầu | Cơ chế | |---|---| | CÙNG cấu hình và công cụ quản trị ở mọi môi trường | Kubernetes chạy được ở mọi nơi | | Không phụ thuộc một nhà cung cấp đám mây | Kubernetes là chuẩn MÃ NGUỒN MỞ |

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

ECS là dịch vụ RIÊNG của AWS
    → task definition, service, cluster đều là khái niệm của AWS
    → KHÔNG chuyển sang đám mây khác được
        ↓
EKS chạy Kubernetes gốc
    → manifest YAML, Helm chart, kubectl
    → dùng y hệt ở tại chỗ, Azure, Google Cloud

Và "same configuration and administrative tools" chính là mô tả Kubernetes:

Đội vận hành dùng:
    ✓ kubectl
    ✓ manifest YAML
    ✓ Helm chart
    ✓ operator và CRD
        ↓
    Giống hệt nhau ở trung tâm dữ liệu và trên AWS

Tạo cụm:

eksctl create cluster --name cum-ung-dung   --region ap-northeast-1 --version 1.30   --nodegroup-name nhom-node --node-type m6i.large   --nodes 3 --nodes-min 2 --nodes-max 10 --managed

Và cùng một manifest chạy ở cả hai nơi:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ung-dung
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: ung-dung
          image: registry.vidu.com/ung-dung:1.4.2

Ba mức quản lý node của EKS: | Mức | Đặc điểm | |---|---| | Self-managed node | bạn quản lý hoàn toàn | | Managed node group | AWS lo vá lỗi và nâng cấp | | Fargate | không quản node nào |

Đề nói "EKS worker nodes" — dùng EC2 node cho phép kiểm soát giống môi trường tại chỗ.

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

• **D. Khởi động container trên ECS với EC2 worker node — đây là phương án gần nhất và là dịch vụ container hoàn toàn hợp lệ, nhưng nó là công nghệ riêng của AWS: cấu hình và công cụ không mang sang đám mây khác được, trái yêu cầu "cloud agnostic" và "align with open-source software".
• **B. ECS với Fargate — cùng vấn đề về tính riêng biệt, và còn thêm một tầng riêng của AWS nữa.
• **A. Khởi động container trên fleet EC2 trong cluster placement group — không phải giải pháp được quản lý: phải tự dựng và vận hành toàn bộ nền tảng điều phối container.

Ghi nhớ

ECS và EKS — bảng phải thuộc: | | Amazon ECS | Amazon EKS | |---|---|---| | Công nghệ | RIÊNG của AWS | Kubernetes mã nguồn mở | | Cloud agnostic | ❌ | ✅ | | Độ phức tạp | thấp hơn | cao hơn | | Chi phí control plane | miễn phí | ~0,10 USD/giờ (~73 USD/tháng) | | Tích hợp AWS | sâu và đơn giản | qua controller và add-on |

Từ khoá nhận diện:

"open-source", "cloud agnostic", "Kubernetes", "same tools everywhere" → EKS "simplest", "deep AWS integration", "no Kubernetes expertise" → ECS

Ba lựa chọn tính toán cho EKS: | Lựa chọn | Công vận hành | |---|---| | Self-managed node | cao nhất | | Managed node group | vừa — AWS lo vá lỗi | | Fargate | thấp nhất — không quản node |

Ba lựa chọn tính toán cho ECS: | Lựa chọn | Đặc điểm | |---|---| | EC2 launch type | kiểm soát instance | | Fargate launch type | serverless | | ECS Anywhere | chạy trên máy tại chỗ |

ECS Anywhere đáng biết:

Chạy ECS agent trên máy tại chỗ
    → quản lý bằng control plane của ECS
        ↓
    Nhưng vẫn là công nghệ riêng của AWS
    → không giải quyết yêu cầu cloud agnostic

Và EKS cũng có bản tương ứng: | Sản phẩm | Chi tiết | |---|---| | EKS Anywhere | Kubernetes tại chỗ, hỗ trợ bởi AWS | | EKS Distro | bản phân phối Kubernetes của AWS | | EKS trên Outposts | trong trung tâm dữ liệu của bạn |

EKS Anywhere phù hợp với đề:

Cụm Kubernetes tại chỗ + EKS trên AWS
    → cùng bản phân phối, cùng công cụ
    → quản lý tập trung qua EKS Connector
        ↓
    Đúng "same configuration and administrative tools"

Ba thành phần của EKS: | Thành phần | Ai quản lý | |---|---| | Control plane | AWS — dư thừa qua nhiều AZ | | Worker node | bạn hoặc managed node group | | Add-on (VPC CNI, CoreDNS, kube-proxy) | AWS quản lý được |

Ba add-on quan trọng: | Add-on | Việc | |---|---| | AWS Load Balancer Controller | tạo ALB/NLB từ Ingress | | EBS CSI Driver | cấp volume cho Pod | | Cluster Autoscaler hoặc Karpenter | co giãn node |

Karpenter đáng biết:

Thay Cluster Autoscaler:
    → chọn loại instance tối ưu cho Pod đang chờ
    → khởi động nhanh hơn
    → tự gộp Pod để giảm số node
        ↓
    AWS khuyến nghị Karpenter cho cụm mới

Ba lưu ý về phân quyền AWS cho Pod: | Cách | Chi tiết | |---|---| | IRSA | IAM role theo service account | | EKS Pod Identity | mới hơn, đơn giản hơn | | Instance profile | quyền dùng chung cả node — tránh |

Ba lưu ý về chi phí EKS: | Khoản | Chi tiết | |---|---| | Control plane | ~73 USD/tháng mỗi cụm | | Worker node | như EC2 | | Cân nhắc một cụm cho nhiều môi trường | dùng namespace |

Ba lưu ý về tính di động thật sự: | Lưu ý | Chi tiết | |---|---| | Manifest Kubernetes thì di động | | | Nhưng tích hợp AWS thì không | ALB Controller, EBS CSI | | Dùng abstraction chuẩn khi được | Ingress, PVC |

Dòng giữa quan trọng:

Dùng annotation riêng của AWS trong Ingress
    → manifest không chạy được ở đám mây khác
        ↓
    Tính di động là mục tiêu cần chủ động duy trì,
      không tự có chỉ vì dùng Kubernetes

Ba lưu ý khi vận hành EKS: | Lưu ý | Chi tiết | |---|---| | Nâng cấp phiên bản Kubernetes định kỳ | AWS hỗ trợ khoảng 14 tháng mỗi bản | | Kiểm tra tương thích add-on trước khi nâng | | | Dùng managed node group để giảm việc vá lỗi | |

Và một lời khuyên: hãy hạn chế dùng annotation và CRD riêng của AWS trong manifest nếu tính di động là mục tiêu thật. Chọn EKS mới chỉ là bước đầu — điều quyết định là những gì bạn viết trong manifest, và một Ingress đầy annotation của ALB Controller cũng khó chuyển đi không kém một task definition của ECS.

Đáp án

C — Chuyển database sang Aurora Global Database ở chế độ tương thích MySQL, cấu hình tầng ứng dụng ở châu Âu dùng reader endpoint ĐỊA PHƯƠNG.

Vì sao đúng

Đề nêu vấn đề rõ: tầng ứng dụng đã ở châu Âu, nhưng database vẫn ở us-west-1.

Người dùng châu Âu → tầng ứng dụng châu Âu (gần) ✓
    → nhưng mỗi truy vấn phải vượt Đại Tây Dương
        ↓
    Độ trễ vòng lượt ≈ 140–160 mili giây
    → một trang cần 10 truy vấn = hơn 1,5 giây chờ mạng

Aurora Global Database đưa dữ liệu tới gần người dùng:

Cluster phụ ở Region châu Âu
    → ứng dụng đọc từ cluster ĐỊA PHƯƠNG
    → độ trễ từ 150ms xuống vài mili giây
        ↓
    Sao chép xuyên Region thường dưới MỘT GIÂY

Và cơ chế sao chép ở tầng lưu trữ:

KHÔNG dùng binlog như MySQL thường
    → dùng hạ tầng sao chép riêng của AWS
        ↓
    Độ trễ thấp hơn nhiều, và KHÔNG tốn CPU
      của cluster chính

Triển khai:

aws rds create-global-cluster   --global-cluster-identifier cum-toan-cau   --source-db-cluster-identifier arn:aws:rds:us-west-1:...:cluster:cum-chinh

aws rds create-db-cluster --db-cluster-identifier cum-eu   --engine aurora-mysql --region eu-west-1   --global-cluster-identifier cum-toan-cau

aws rds create-db-instance --db-instance-identifier reader-eu   --db-cluster-identifier cum-eu --engine aurora-mysql   --db-instance-class db.r6g.large --region eu-west-1

Và "local reader endpoint" là chi tiết quan trọng:

Mỗi cluster có reader endpoint RIÊNG
    cum-eu.cluster-ro-xyz.eu-west-1.rds.amazonaws.com
        ↓
    Ứng dụng châu Âu phải trỏ tới endpoint của cluster EU
    → dùng nhầm endpoint của cluster Mỹ = không cải thiện gì

⚠ Và giới hạn cần biết: chỉ MỘT writer.

Lệnh GHI từ châu Âu vẫn phải đi tới us-west-1
    → đề nói vấn đề là "poor performance when running QUERIES"
    → tải ĐỌC, nên giải pháp phù hợp

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

• **B. Tạo RDS Read Replica ở Region châu Âu và cho ứng dụng dùng nó — đây là phương án gần nhất và thực sự đưa bản sao tới gần người dùng, nhưng nó kém hơn ở độ trễ sao chép: RDS cross-Region replica dùng binlog, độ trễ thường tính bằng giây tới phút và tốn tài nguyên của primary. Aurora Global Database sao chép ở tầng lưu trữ, dưới một giây.
• **D. Chuyển sang RDS for MySQL với Multi-AZ ở Region châu Âu — hiểu sai Multi-AZ: nó hoạt động trong MỘT Region và standby không phục vụ đọc.
• **A. Chuyển sang Redshift và đồng bộ bằng DMS — sai loại database: Redshift là kho dữ liệu phân tích, không phù hợp cho truy vấn giao dịch của ứng dụng web.

Ghi nhớ

Ba lựa chọn database đa Region — bảng phải thuộc: | Lựa chọn | Độ trễ sao chép | Ghi đa Region | |---|---|---| | Aurora Global Database | < 1 giây | ❌ một writer | | RDS cross-Region replica | giây tới phút | ❌ | | DynamoDB global table | thường < 1 giây | ✅ |

Từ khoá nhận diện:

"global users", "low-latency reads", "relational" → Aurora Global Database "write from multiple Regions", "NoSQL" → DynamoDB global table

Aurora Global Database và RDS replica — bảng phân biệt: | | Aurora Global | RDS cross-Region replica | |---|---|---| | Cơ chế sao chép | tầng LƯU TRỮ | binlog | | Độ trễ | < 1 giây | giây tới phút | | Ảnh hưởng primary | gần như không | tốn CPU | | Số Region phụ | 5 | 5 | | Chuyển vùng | managed, < 1 phút | promote thủ công |

Ba khái niệm của Aurora Global Database: | Khái niệm | Việc | |---|---| | Global cluster | tài nguyên bao ngoài | | Primary cluster | DUY NHẤT được GHI | | Secondary cluster | chỉ đọc, sẵn sàng thăng cấp |

Ba loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi | | Reader | cân bằng qua replica TRONG cùng cluster | | Custom | nhóm tự định nghĩa |

Mỗi cluster có bộ endpoint riêng — đây là điểm ứng dụng phải cấu hình đúng.

Ba lưu ý về write forwarding: | Lưu ý | Chi tiết | |---|---| | Cluster phụ nhận được lệnh ghi | khi bật | | Nhưng CHUYỂN TIẾP về primary | | | Độ trễ ghi KHÔNG cải thiện | |

Ba lợi ích của Aurora Global Database: | Lợi ích | Chi tiết | |---|---| | Đọc độ trễ thấp ở nhiều Region | ← câu này | | Khôi phục thảm hoạ RTO < 1 phút | | | Không ảnh hưởng hiệu năng primary | |

Ba cách di chuyển từ MySQL trên EC2: | Cách | Đặc điểm | |---|---| | Snapshot rồi restore thành Aurora | có ngừng | | AWS DMS với CDC | ngừng tối thiểu | | Percona XtraBackup lên S3 | cho khối lượng lớn |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraGlobalDBReplicationLag | độ trễ xuyên Region | | AuroraReplicaLag | trong cùng cluster | | CPUUtilization của writer | |

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Cluster phụ có độ trễ dưới 1 giây | | | Đọc-sau-ghi có thể chưa thấy dữ liệu | dùng writer khi cần | | Với truy vấn hiển thị thì chấp nhận được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Instance ở mỗi Region tính phí đầy đủ | | | Phí sao chép ~0,20 USD mỗi triệu request I/O | | | Headless secondary rẻ hơn | chỉ lưu trữ |

Ba lưu ý về Route 53 trong kiến trúc này: | Lưu ý | Chi tiết | |---|---| | Latency-based routing đã đưa người dùng tới đúng ứng dụng | | | Database không cần Route 53 | ứng dụng khai endpoint địa phương | | Cân nhắc Global Accelerator cho chuyển vùng nhanh | |

Ba việc nên làm sau khi triển khai: | Việc | Chi tiết | |---|---| | Xác nhận ứng dụng EU dùng endpoint địa phương | | | Đo độ trễ truy vấn trước và sau | | | Đặt alarm cho độ trễ sao chép | |

Và một lời khuyên: hãy kiểm tra chuỗi kết nối của ứng dụng châu Âu sau khi triển khai. Toàn bộ giá trị của Aurora Global Database nằm ở việc ứng dụng đọc từ cluster địa phương — và một tệp cấu hình còn sót endpoint cũ sẽ khiến bạn trả tiền cho một cluster thứ hai mà độ trễ không cải thiện chút nào.

Đáp án

A — Xử lý và lưu ảnh bằng thiết bị AWS Snowball Edge.

Vì sao đúng

Đề nêu ba ràng buộc, và Snowball Edge đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Kết nối mạng CHẬP CHỜN và không tin cậy | Snowball hoạt động HOÀN TOÀN NGOẠI TUYẾN | | Laptop thiếu dung lượng và năng lực tính toán | Snowball Edge có cả lưu trữ LẪN tính toán | | Cần xử lý ảnh để đánh giá tiến độ | chạy EC2 và Lambda ngay trên thiết bị |

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

Snowball Edge Compute Optimized:
    ✓ ~28 TB lưu trữ NVMe
    ✓ 52 vCPU, 208 GB RAM
    ✓ tuỳ chọn GPU
    ✓ chạy EC2 instance và Lambda function TẠI CHỖ
        ↓
    Đội khảo sát xử lý ảnh NGAY tại công trường
    → không cần mạng

Và đó là ý nghĩa của "edge computing":

Đưa TÍNH TOÁN tới nơi có DỮ LIỆU
    → thay vì đưa dữ liệu tới nơi có tính toán
        ↓
    Đúng khi mạng là nút thắt

Quy trình:

① Đặt Snowball Edge, AWS gửi tới công trường
② Drone chép ảnh vào thiết bị
③ Chạy EC2 instance trên thiết bị xử lý ảnh
④ Xem kết quả ngay tại chỗ
⑤ Gửi trả thiết bị, AWS nhập dữ liệu vào S3

Đặt thiết bị:

aws snowball create-job --job-type LOCAL_USE   --snowball-type EDGE_C   --resources '{"Ec2AmiResources":[{"AmiId":"ami-0abc"}]}'   --address-id <id-dia-chi> --role-arn <arn-role>

--job-type LOCAL_USE cho phép dùng thiết bị tại chỗ thay vì chỉ vận chuyển dữ liệu.

Và chạy instance trên thiết bị:

aws ec2 run-instances --image-id s.ami-0abc   --instance-type sbe-c.large --count 1   --endpoint http://<ip-snowball>:8008

Tiền tố s. và endpoint riêng — đó là API EC2 chạy ngay trên Snowball.

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

• **C. Dùng Storage Gateway trên phần cứng chuyên dụng đệm ảnh tại chỗ rồi xử lý khi có mạng — đây là phương án gần nhất và thật sự có cache cục bộ, nhưng nó không xử lý được ảnh tại chỗ: Storage Gateway chỉ là lớp lưu trữ, việc xử lý vẫn phải chạy trên EC2 ở AWS, tức là vẫn cần mạng.
• **B. Tải ảnh lên SQS trong lúc có kết nối — SQS giới hạn 256 KB mỗi thông điệp, không chứa được ảnh. Và vẫn phụ thuộc mạng.
• **D. Dùng Kinesis Data Firehose với nhiều delivery stream — cũng phụ thuộc hoàn toàn vào mạng, và Firehose không phải công cụ xử lý ảnh.

Ghi nhớ

Họ AWS Snow — bảng phải thuộc: | Thiết bị | Lưu trữ | Tính toán | |---|---|---| | Snowcone | 8 TB (HDD) / 14 TB (SSD) | 2 vCPU, 4 GB | | Snowball Edge Storage Optimized | ~80 TB | 40 vCPU, 80 GB | | Snowball Edge Compute Optimized | ~28 TB | 52 vCPU, 208 GB, tuỳ chọn GPU |

Từ khoá nhận diện:

"process data at the edge", "intermittent connectivity", "no compute on site" → Snowball Edge Compute Optimized "move large data, network too slow" → Snowball Edge Storage Optimized "very small, portable, rugged" → Snowcone

Ba loại job của Snowball: | Loại | Việc | |---|---| | IMPORT | chuyển dữ liệu VÀO AWS | | EXPORT | chuyển dữ liệu TỪ AWS ra | | LOCAL_USE | dùng tính toán tại chỗ ← câu này |

Ba khả năng tính toán của Snowball Edge: | Khả năng | Chi tiết | |---|---| | EC2-compatible instance | loại sbe-c, sbe-g (GPU) | | AWS Lambda | qua IoT Greengrass | | S3-compatible storage | API S3 tại chỗ |

Ba đặc điểm về bảo mật: | Đặc điểm | Chi tiết | |---|---| | Mã hoá 256-bit, khoá do KMS quản lý | | | Vỏ chống va đập, chống bụi nước | | | Chống giả mạo phần cứng (TPM) | |

Ba lựa chọn cho môi trường mạng kém: | Lựa chọn | Đặc điểm | |---|---| | Snowball Edge | ← câu này, tính toán và lưu trữ | | AWS Outposts | hạ tầng AWS đầy đủ, cần mạng ổn định | | IoT Greengrass | chạy Lambda trên thiết bị nhỏ |

Outposts và Snowball — bảng phân biệt: | | Snowball Edge | Outposts | |---|---|---| | Thời gian dùng | theo đợt, thuê ngắn hạn | thường trực | | Cần mạng | KHÔNG | CÓ, ổn định | | Di động | ✅ mang ra công trường | ❌ đặt trong trung tâm dữ liệu | | Quy mô | vài chục TB | rack đầy đủ |

Ba trường hợp dùng Snowball Edge Compute: | Trường hợp | Chi tiết | |---|---| | Xử lý dữ liệu tại nơi xa | công trường, tàu biển, giàn khoan | | Tiền xử lý trước khi gửi lên AWS | giảm khối lượng | | Suy luận học máy tại biên | với bản GPU |

Ba lưu ý khi lập kế hoạch: | Lưu ý | Chi tiết | |---|---| | Đặt thiết bị trước vài ngày | thời gian vận chuyển | | Chuẩn bị AMI trước | AMI phải tương thích với Snowball | | Tính dung lượng cần | có thể đặt nhiều thiết bị |

Chuẩn bị AMI:

AMI phải dựa trên bản Linux được hỗ trợ
    → export sang Snowball khi tạo job
        ↓
    Không tải AMI mới xuống thiết bị lúc đang ở công trường

Ba cách chuyển dữ liệu lên AWS: | Cách | Quy mô | |---|---| | Tải trực tiếp | tới vài TB, cần mạng tốt | | DataSync | TB tới PB, qua mạng | | Snowball | hàng chục TB tới PB, KHÔNG cần mạng |

Quy tắc ước lượng:

Thời gian (ngày) = Dung lượng (TB) × 8.000 ÷ (Băng thông Mbps × 86,4)
        ↓
    Nếu > 1 tuần → cân nhắc Snowball
    Nếu mạng chập chờn → Snowball bất kể dung lượng

Ba lưu ý về vận hành thiết bị: | Lưu ý | Chi tiết | |---|---| | Cần nguồn điện và mạng cục bộ | để laptop kết nối tới thiết bị | | Mở khoá bằng manifest và unlock code | tách riêng để an toàn | | Theo dõi tiến độ qua Snowball client | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí thuê mỗi thiết bị theo job | | | Phí ngày thêm nếu giữ lâu | | | Nhập dữ liệu VÀO AWS miễn phí | phí mạng |

Ba việc nên làm khi dùng lần đầu: | Việc | Chi tiết | |---|---| | Thử quy trình với dữ liệu nhỏ | | | Đào tạo đội tại công trường | | | Chuẩn bị script tự động hoá | giảm thao tác tay |

Và một lời khuyên: hãy chuẩn bị và thử AMI trước khi thiết bị được gửi đi. Snowball Edge chỉ chạy được AMI đã được export cùng job — và phát hiện AMI thiếu một thư viện khi đang ở công trường không có mạng nghĩa là cả chuyến đi trở nên vô ích.

Đáp án

C — Cấu hình website tĩnh trên Amazon S3 và tạo Route 53 failover routing policy.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án C đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Trang dự phòng có thông tin liên hệ | trang tĩnh đơn giản trên S3 | | Tự chuyển khi website chính hỏng | Route 53 failover + health check | | Tiết kiệm chi phí | S3 tĩnh gần như miễn phí |

Và "cost-effectively" là điểm phân biệt quyết định:

Trang dự phòng chỉ hiện khi có sự cố
    → chạy EC2 và ALB ở Region khác 24/7 để chờ
    → tốn hàng chục USD mỗi tháng cho thứ hiếm khi dùng
        ↓
    S3 static website: vài xu mỗi tháng

Cấu hình gồm ba phần:

① Health check theo dõi ALB
② Bản ghi PRIMARY  → ALB, gắn health check
③ Bản ghi SECONDARY → S3 static website

Tạo health check:

aws route53 create-health-check --caller-reference kiem-tra-alb   --health-check-config '{
    "Type":"HTTPS","FullyQualifiedDomainName":"alb.vidu.com",
    "Port":443,"ResourcePath":"/health",
    "RequestInterval":30,"FailureThreshold":3}'

Và hai bản ghi failover:

{"Changes": [
  {"Action":"UPSERT","ResourceRecordSet":{
     "Name":"www.vidu.com","Type":"A",
     "SetIdentifier":"chinh","Failover":"PRIMARY",
     "HealthCheckId":"<id>",
     "AliasTarget":{"DNSName":"<dns-alb>","HostedZoneId":"<zone-alb>",
                    "EvaluateTargetHealth":true}}},
  {"Action":"UPSERT","ResourceRecordSet":{
     "Name":"www.vidu.com","Type":"A",
     "SetIdentifier":"du-phong","Failover":"SECONDARY",
     "AliasTarget":{"DNSName":"s3-website-ap-northeast-1.amazonaws.com",
                    "HostedZoneId":"<zone-s3>","EvaluateTargetHealth":false}}}]}

⚠ Điều kiện bắt buộc với S3 static website:

Tên BUCKET phải TRÙNG với tên miền
    → bucket tên "www.vidu.com"
        ↓
    Đây là yêu cầu của S3 website endpoint
    → và là lỗi cấu hình hay gặp nhất

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

• **D. Website tĩnh trên S3 với Route 53 WEIGHTED routing — đây là phương án gần nhất và chỉ khác một chính sách định tuyến, nhưng weighted routing gửi một phần lưu lượng tới trang lỗi NGAY CẢ KHI website chính hoạt động bình thường. Failover mới là chính sách đúng cho mẫu chính–dự phòng.
• **A. Triển khai website dự phòng trên EC2 và ALB ở Region khác — đắt hơn nhiều: phải chạy hạ tầng đầy đủ 24/7 cho một trang chỉ hiện khi có sự cố.
• **B. Website dự phòng trên EC2 và ALB, dùng Global Accelerator — cùng vấn đề chi phí, cộng thêm phí Global Accelerator.

Ghi nhớ

Bảy chính sách định tuyến của Route 53 — bảng phải thuộc: | Chính sách | Việc | |---|---| | Simple | một bản ghi, không health check | | Failover | active-passive: chính và dự phòng ← câu này | | Weighted | chia theo tỷ lệ — canary, blue/green | | Latency-based | Region có độ trễ thấp nhất | | Geolocation | theo quốc gia người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | tới 8 bản ghi khoẻ mạnh |

Từ khoá nhận diện:

"backup site", "standby", "when primary fails" → failover "percentage of traffic", "canary" → weighted "lowest latency" → latency-based

Ba loại health check: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ | | Calculated | kết hợp nhiều health check | | CloudWatch alarm | dựa trên trạng thái alarm |

Ba tham số của health check: | Tham số | Mặc định | |---|---| | RequestInterval | 30 giây (hoặc 10) | | FailureThreshold | 3 lần | | — | phát hiện ≈ interval × threshold |

Tính thời gian chuyển vùng:

Phát hiện:   30 × 3 = 90 giây
TTL của DNS: 60 giây
        ↓
    Khoảng 2,5 phút trước khi người dùng thấy trang dự phòng

Ba điều kiện cho S3 static website: | Điều kiện | Chi tiết | |---|---| | Tên bucket TRÙNG tên miền | bắt buộc | | Bật static website hosting | | | Block Public Access TẮT + bucket policy công khai | |

aws s3 website s3://www.vidu.com/   --index-document index.html --error-document error.html

⚠ Ba lưu ý về S3 website endpoint: | Lưu ý | Chi tiết | |---|---| | CHỈ hỗ trợ HTTP, KHÔNG có HTTPS | | | Bucket phải công khai | không dùng OAC được | | Đặt CloudFront trước nếu cần HTTPS | |

Dòng đầu là vấn đề thật:

Người dùng đang ở HTTPS
    → chuyển sang trang HTTP
    → trình duyệt cảnh báo bảo mật
        ↓
    Đặt CloudFront trước S3 để có HTTPS

Ba lưu ý về alias record: | Lưu ý | Chi tiết | |---|---| | MIỄN PHÍ (khác CNAME) | | | Dùng được ở đỉnh tên miền | CNAME không được | | EvaluateTargetHealth tự kiểm tra ALB | |

Ba lưu ý về trang lỗi tĩnh: | Lưu ý | Chi tiết | |---|---| | Giữ thật đơn giản | không phụ thuộc gì bên ngoài | | Có thông tin liên hệ và thời gian dự kiến | ← yêu cầu của đề | | Không gọi API hay tải tài nguyên ngoài | |

Ba cách cải thiện thiết kế này: | Cách | Lợi ích | |---|---| | CloudFront trước S3 | HTTPS và độ trễ thấp | | Calculated health check | phản ánh cả tầng dữ liệu | | Cảnh báo SNS khi chuyển vùng | biết ngay khi xảy ra |

Đặt cảnh báo cho health check:

aws cloudwatch put-metric-alarm --alarm-name website-chinh-hong   --metric-name HealthCheckStatus --namespace AWS/Route53   --dimensions Name=HealthCheckId,Value=<id>   --statistic Minimum --period 60 --threshold 1   --comparison-operator LessThanThreshold --alarm-actions <arn-sns>

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = chuyển vùng nhanh | 60 giây hợp lý | | TTL thấp = nhiều truy vấn DNS hơn | tốn hơn chút ít | | Trình phân giải có thể bỏ qua TTL rất thấp | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Hosted zone | ~0,50 USD/tháng | | Health check | ~0,50 USD/tháng | | S3 static website | vài xu cho trang nhỏ |

Tổng chi phí giải pháp dưới 2 USD mỗi tháng — đó là ý nghĩa của "cost-effectively".

Ba việc nên làm định kỳ: | Việc | Chi tiết | |---|---| | THỬ chuyển vùng thật | --inverted trên health check | | Kiểm tra trang lỗi hiển thị đúng | | | Đo thời gian chuyển vùng thực tế | |

Và một lời khuyên: hãy thử chuyển vùng bằng cách đảo ngược health check ít nhất mỗi quý. Đó là cách duy nhất biết chắc tên bucket khớp tên miền, trang dự phòng hiển thị đúng, và thời gian chuyển vùng đúng như tính toán — cả ba đều có thể sai mà không có dấu hiệu nào cho tới lúc cần dùng.