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

Đáp án

D — Tạo Service Catalog product từ template môi trường và thêm launch constraint dùng chính role đã có; cấp cho đội kiểm thử quyền dùng API của Service Catalog; hướng dẫn họ khởi chạy từ console Service Catalog.

Vì sao đúng

Đề đòi cho đội kiểm thử dựng được môi trường nhiều lần mà không cấp quyền rộng cho từng người. Launch constraint là cơ chế dựng riêng cho việc đó.

⚠ Điểm mấu chốt: launch constraint cho phép người dùng KHÔNG có quyền vẫn dựng được tài nguyên:

Người dùng chỉ có quyền gọi API Service Catalog
        ↓
    Bấm "Launch" trên product
        ↓
    Service Catalog KHÔNG dùng quyền của người dùng
        ↓
    Nó assume vào IAM role khai trong launch constraint
        ↓
    CloudFormation dựng API Gateway, EC2, ELB, DynamoDB bằng quyền của ROLE
        ↓
    → người dùng không bao giờ cần quyền tạo các tài nguyên đó

Đây chính là điều đề mô tả: "don't want to grant broad permissions to each user".

aws servicecatalog create-constraint \
  --portfolio-id port-abc --product-id prod-xyz --type LAUNCH \
  --parameters '{"RoleArn":"arn:aws:iam::111122223333:role/DeveloperDeployRole"}'

⚠ Không có launch constraint thì Service Catalog dùng quyền của chính người dùng — và mô hình sụp đổ:

Product không gắn launch constraint
        ↓
    Người dùng phải có đủ quyền tạo MỌI tài nguyên trong template
        ↓
    → nghĩa là họ cũng tạo được chúng trực tiếp, ngoài mọi khuôn khổ
    → Service Catalog trở thành một lớp trang trí

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

• B (Service Catalog product — đúng; nhưng thêm STACK SET constraint với role đã có) — đây là phương án gần nhất và nó chỉ khác đáp án đúng một loại constraint. Nhưng stack set constraint dùng để khai product sẽ được triển khai ra những tài khoản và Region nào khi dùng với CloudFormation StackSets — nó không phải cơ chế uỷ quyền. Loại constraint cho phép người dùng mượn quyền của role là launch constraint. Đây là bẫy kiểm tra xem có nhớ chính xác bốn loại constraint hay không.

• A (tải template lên S3, cấp quyền dùng CloudFormation và S3 với điều kiện giới hạn, hướng dẫn khởi chạy từ console CloudFormation) — không giải quyết vấn đề gốc. CloudFormation dựng tài nguyên bằng quyền của người gọi (trừ khi khai service role), nên người dùng vẫn cần quyền tạo EC2, ELB, DynamoDB, API Gateway — đúng thứ đề muốn tránh. Điều kiện giới hạn theo template cũng rất khó viết chính xác.

• C (tải template lên S3, cho đội kiểm thử assume role của Developer, thêm policy giới hạn) — cho họ assume một role có quyền rộng, rồi cố thu hẹp bằng policy bổ sung. Cách này mong manh và khó kiểm soát; nó cũng cho họ toàn bộ quyền của role đó cho mọi mục đích khác, không chỉ để dựng môi trường kiểm thử.

Ghi nhớ

⚠ Bốn loại constraint của Service Catalog — bảng phải thuộc: | Loại | Việc | |---|---| | Launch | chỉ định IAM role mà Service Catalog assume để dựng tài nguyên | | Template | giới hạn giá trị tham số người dùng nhập được | | Notification | gửi thông báo SNS khi có sự kiện stack | | Stack set | khai tài khoản và Region đích khi triển khai bằng StackSets |

Từ khoá nhận diện:

"không cấp quyền rộng cho người dùng" + họ vẫn dựng được → launch constraint "pre-approved templates" → Service Catalog "stack set constraint" để uỷ quyền → SAI loại constraint "cho người dùng chạy CloudFormation trực tiếp" → họ phải có đủ quyền tạo tài nguyên "assume role của developer" → cấp quá rộng, khó thu hẹp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Launch constraint có hoạt động không | đăng nhập bằng chính người dùng cuối và bấm launch | | Role có đủ quyền không | đọc sự kiện stack thất bại trong CloudFormation | | Người dùng có dựng được ngoài danh mục không | thử tạo tài nguyên trực tiếp — phải bị từ chối |

Và một lời khuyên: hãy thử launch bằng chính danh tính của một thành viên đội kiểm thử, không thử bằng tài khoản quản trị. Đây là chỗ cấu hình Service Catalog hay hỏng mà không lộ ra trong lúc dựng: quản trị viên tạo product, bấm launch thử và thấy chạy hoàn hảo — nhưng nó chạy bằng quyền quản trị của chính họ, không đi qua launch constraint chút nào. Trust policy thiếu servicecatalog.amazonaws.com, hoặc role thiếu một quyền cụ thể, đều không lộ ra ở phép thử đó. Chúng chỉ lộ ra vào ngày người kiểm thử thật bấm nút và nhận về một stack thất bại giữa chừng.

Đáp án

A — Tạo DynamoDB global table sao chép giữa us-west-1 và eu-central-1; bật continuous backup cho bảng ở us-west-1; thiết lập S3 cross-Region replication từ us-west-1 sang eu-central-1.

Vì sao đúng

Đề đòi bảo vệ trước hai mối đe doạ khác nhau, và điều đó cần hai cơ chế khác nhau cho mỗi kho dữ liệu.

⚠ Điểm mấu chốt: sao chép KHÔNG bảo vệ khỏi hỏng dữ liệu — nó nhân bản luôn cả cái hỏng:

Một lỗi ứng dụng ghi đè dữ liệu sai
        ↓
    Global table sao chép thay đổi đó sang Region kia trong vòng một giây
        ↓
    → cả hai Region đều hỏng như nhau
        ↓
Continuous backup (point-in-time recovery)
        ↓
    Cho phép khôi phục về BẤT KỲ giây nào trong 35 ngày qua
        ↓
    → đây mới là thứ chống hỏng dữ liệu

Đây là lý do phương án A đúng còn C và D thiếu: chúng có sao chép nhưng thiếu hoặc yếu ở vế khôi phục thời điểm.

aws dynamodb update-continuous-backups --table-name khach-hang \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

aws dynamodb restore-table-to-point-in-time \
  --source-table-name khach-hang --target-table-name khach-hang-khoi-phuc \
  --restore-date-time 2026-09-02T08:30:00Z

⚠ Với S3, cơ chế chống hỏng dữ liệu là VERSIONING — và CRR đòi versioning bật sẵn:

S3 Cross-Region Replication yêu cầu versioning ở cả hai bucket
        ↓
    Nên khi bật CRR, bạn tự động có luôn versioning
        ↓
    → versioning cho phép quay về phiên bản trước của một object bị ghi đè
    → đó là lý do phương án A không cần nhắc versioning riêng: CRR đã kéo theo

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

• C (global table; continuous backup cho DynamoDB; bật versioning cho bucket S3) — đây là phương án gần nhất và vế DynamoDB của nó chính xác bằng đáp án đúng. Nhưng nó thiếu S3 cross-Region replication: versioning chống được hỏng dữ liệu nhưng không bảo vệ trước việc mất kết nối tới Region — nếu us-west-1 không truy cập được, tệp vẫn chỉ nằm ở đó. Đề đòi bảo vệ trước cả hai mối đe doạ, cho cả hai kho dữ liệu.

• D (global table; bật versioning cho S3; áp ACL nghiêm ngặt cho bucket) — thiếu continuous backup cho DynamoDB (không chống được hỏng dữ liệu ở tầng bảng) và thiếu CRR cho S3. ACL nghiêm ngặt là kiểm soát truy cập, không liên quan tới bảo vệ dữ liệu trước hỏng hóc hay mất Region.

• B (Lambda theo lịch sao lưu DynamoDB; S3 CRR; bật MFA delete cho bucket) — sao lưu theo lịch cho RPO bằng chu kỳ sao lưu, kém hơn hẳn continuous backup vốn cho phép quay về từng giây. Nó cũng thiếu global table nên DynamoDB không sẵn sàng ở Region thứ hai. MFA delete chống xoá nhầm nhưng không chống ghi đè sai.

Ghi nhớ

⚠ Hai mối đe doạ khác nhau, hai nhóm giải pháp — bảng phải thuộc: | Mối đe doạ | DynamoDB | S3 | |---|---|---| | Mất Region | global table | cross-Region replication | | Hỏng dữ liệu | point-in-time recovery | versioning | | Xoá nhầm | PITR | versioning + MFA delete |

Từ khoá nhận diện:

"data corruption" → PITR cho DynamoDB, versioning cho S3 "loss of connectivity to a Region" → global table, CRR "sao chép" như biện pháp chống hỏng dữ liệu → SAI, sao chép nhân bản luôn cái hỏng "backup theo lịch" khi có PITR → RPO kém hơn nhiều cần cả hai → phương án phải có đủ bốn mảnh cho hai kho

Ba việc kiểm chứng: | Việc | Cách | |---|---| | PITR đã bật chưa | describe-continuous-backups | | CRR có chạy không | ReplicationLatency và OperationsPendingReplication | | Khôi phục có hoạt động không | thử khôi phục về một thời điểm trong môi trường thử |

Và một lời khuyên: hãy thử khôi phục về một thời điểm ít nhất một lần, đừng chỉ bật PITR rồi coi như xong. Point-in-time recovery tạo ra một bảng mới chứ không ghi đè bảng đang chạy — nghĩa là quy trình khôi phục thật sự gồm cả việc chuyển ứng dụng sang bảng mới, hoặc chép dữ liệu ngược lại, và cả hai đều cần thời gian cùng kế hoạch. Phát hiện điều đó trong một lần diễn tập tốn nửa giờ; phát hiện nó giữa một sự cố hỏng dữ liệu, khi đồng hồ đang chạy và mọi người đang chờ, thì tốn hơn nhiều.

Đáp án

B, E, D — ba bước chuyển 25 TB MySQL trong hai tuần với downtime ít nhất:

• B — Xuất dữ liệu bằng công cụ gốc của cơ sở dữ liệu và đưa lên AWS bằng AWS Snowball.
• E — Dựng Aurora MySQL và nạp dữ liệu từ bản xuất Snowball; cấu hình sao chép từ cơ sở dữ liệu tại chỗ sang Aurora qua VPN.
• D — Khi Aurora đã đồng bộ hoàn toàn, đổi bản ghi DNS sang Aurora và dừng sao chép.

Vì sao đúng

Một phép tính quyết định toàn bộ: 25 TB qua đường 50 Mbps.

⚠ Điểm mấu chốt: 50 Mbps không thể chuyển 25 TB trong hai tuần — Snowball là bắt buộc:

25 TB ÷ (50 Mbps × 70%) ≈ 60 ngày
        ↓
    Thời hạn chỉ có 14 ngày
        ↓
    → mọi phương án chuyển toàn bộ qua mạng đều bất khả thi
        ↓
    → nhưng đường VPN vẫn đủ cho phần THAY ĐỔI phát sinh sau đó

Đây là mẫu kết hợp: khối dữ liệu lớn đi bằng thiết bị vật lý, phần thay đổi đi qua mạng.

Ngày 1–5:   xuất dữ liệu, chép vào Snowball, gửi đi
Ngày 6–9:   AWS nhập vào S3, nạp vào Aurora
Ngày 10–13: bật sao chép từ cơ sở dữ liệu tại chỗ qua VPN, chờ bắt kịp
Ngày 14:    đổi DNS, dừng sao chép — downtime chỉ vài phút

⚠ Bước sao chép sau khi nạp là thứ làm cho downtime ngắn:

Chỉ dùng Snowball, không sao chép
        ↓
    Dữ liệu chỉ tới thời điểm xuất
        ↓
    → phải dừng cơ sở dữ liệu nguồn suốt quá trình vận chuyển → downtime nhiều ngày
        ↓
Snowball + sao chép qua VPN
        ↓
    Nguồn vẫn chạy trong lúc thiết bị đang đi đường
    Sao chép bắt kịp phần chênh lệch
        ↓
    → downtime chỉ bằng thời gian đổi DNS

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

• C (dựng Aurora MySQL và dùng DMS chuyển toàn bộ cơ sở dữ liệu tại chỗ) — đây là phương án gần nhất và DMS là công cụ đúng cho việc di chuyển cơ sở dữ liệu, thường là câu trả lời cho dạng câu này. Nhưng ở đây nó vướng đúng phép tính băng thông: DMS chuyển dữ liệu qua mạng, và 25 TB qua 50 Mbps mất khoảng hai tháng — vượt xa thời hạn hai tuần. DMS vẫn hữu ích ở giai đoạn CDC, nhưng nó không thể gánh phần nạp ban đầu.

• A (dựng DMS instance, sao chép qua VPN) — cùng lỗi băng thông với C, và mô tả lại chính bước mà C đã nêu.

• F (dùng AWS SMS nhập cơ sở dữ liệu tại chỗ vào AWS rồi dùng DMS đồng bộ với Aurora) — sai công cụ. Server Migration Service di chuyển MÁY CHỦ, không di chuyển cơ sở dữ liệu — nó tạo AMI từ máy ảo. Và SMS đã được thay bằng Application Migration Service (MGN). Kể cả nếu dùng MGN thì kết quả là một EC2 chạy MySQL, không phải Aurora.

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

⚠ AWS Server Migration Service (SMS) đã được thay bằng MGN:

Phương án F nhắc tới AWS SMS
        ↓
    AWS đã ngừng nhận khách mới cho SMS, khuyến nghị dùng MGN
        ↓
    → phương án này vốn đã sai vì dùng công cụ di chuyển máy chủ cho cơ sở dữ liệu

Ghi nhớ

⚠ Phép tính băng thông — bảng phải thuộc, đây là kỹ năng ra thi liên tục: | Băng thông | Thời gian chuyển 25 TB (hiệu suất ~70%) | |---|---| | 50 Mbps | khoảng 60 ngày | | 100 Mbps | khoảng 30 ngày | | 1 Gbps | khoảng 3 ngày | | 10 Gbps | khoảng 8 giờ |

Công thức: thời gian ≈ dung lượng ÷ (băng thông × hiệu suất).

Từ khoá nhận diện:

dung lượng lớn + băng thông nhỏ + thời hạn ngắn → Snow Family "least downtime" → Snow cho khối lớn + sao chép cho phần chênh "DMS cho toàn bộ 25 TB qua 50 Mbps" → SAI, không kịp thời hạn "AWS SMS" cho cơ sở dữ liệu → SAI công cụ, và đã bị MGN thay thế luôn tính thời gian trước khi chọn → con số quyết định phương án

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sao chép đã bắt kịp chưa | độ trễ sao chép về gần 0 | | Dữ liệu có khớp không | so số dòng và checksum các bảng lớn | | DNS đổi mất bao lâu | kiểm TTL trước khi cắt chuyển |

Và một lời khuyên: hãy hạ TTL của bản ghi DNS xuống 60 giây ít nhất vài ngày trước ngày cắt chuyển. Đây là chi tiết nhỏ quyết định downtime thật sự: nếu TTL đang là một giờ, thì sau khi bạn đổi bản ghi, các resolver và client vẫn tiếp tục gửi lưu lượng tới cơ sở dữ liệu cũ trong tối đa một giờ nữa — và bạn phải chọn giữa việc để hai cơ sở dữ liệu cùng nhận ghi, hoặc chấp nhận một giờ gián đoạn. Hạ TTL trước thì cửa sổ đó thu về một phút, và nó là thay đổi duy nhất trong toàn bộ kế hoạch mà bạn phải làm trước chứ không phải trong ngày cắt chuyển.

Đáp án

C — Liên kết private hosted zone với TẤT CẢ các VPC; tạo Route 53 inbound resolver trong shared services VPC; gắn mọi VPC vào transit gateway; tạo forwarding rule trên DNS tại chỗ trỏ tới inbound resolver.

Vì sao đúng

Đề có hai yêu cầu phân giải và một tiêu chí: hiệu năng cao nhất.

⚠ Điểm mấu chốt: private hosted zone chỉ phân giải được từ VPC đã LIÊN KẾT — liên kết hết là đường ngắn nhất:

Liên kết zone với TẤT CẢ VPC (phương án C)
        ↓
    Mỗi VPC hỏi resolver tại chỗ của chính nó (CIDR + 2)
        ↓
    → không có chặng mạng nào thêm

Chỉ liên kết với shared services VPC (phương án B, D)
        ↓
    Các VPC khác phải chuyển tiếp truy vấn qua transit gateway
        ↓
    → thêm chặng, thêm độ trễ, thêm điểm hỏng

Đây là lý do C thắng B: cả hai đều dùng inbound resolver đúng, nhưng B bắt các VPC khác đi vòng.

Vì sao inbound resolver (không phải outbound). Nhớ theo chiều của truy vấn:

Đề cần hệ thống tại chỗ hỏi vào AWS, nên là inbound.

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

⚠ Inbound resolver endpoint phải có IP ở ít nhất hai AZ, và security group phải mở cổng 53:

Chỉ một IP → mất AZ đó là mất phân giải DNS cho toàn bộ mạng tại chỗ
Security group thiếu cổng 53 TCP và UDP → truy vấn timeout

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

• B (liên kết zone chỉ với shared services VPC; inbound resolver; gắn shared services VPC vào transit gateway) — đây là phương án gần nhất và nó dùng đúng inbound resolver. Nhưng nó chỉ liên kết zone với một VPC, nên các VPC còn lại không phân giải được internal.company.local — vi phạm yêu cầu thứ hai của đề. Ngoài ra nó chỉ gắn shared services VPC vào transit gateway, nên các VPC khác cũng không nối được vào mạng chung.

• D (liên kết zone chỉ với shared services VPC; OUTBOUND resolver; forwarding rule ở DNS tại chỗ trỏ tới outbound resolver) — sai hướng. Outbound resolver dùng khi VPC cần hỏi ra ngoài, không phải khi bên ngoài hỏi vào. DNS tại chỗ không trỏ tới outbound endpoint được. Cộng thêm lỗi chỉ liên kết một VPC.

• A (liên kết zone với tất cả VPC — đúng; nhưng dùng một EC2 làm conditional forwarder trong shared services VPC) — tự dựng thứ Route 53 Resolver cung cấp sẵn: một EC2 phải vá, phải giám sát, phải tự lo tính sẵn sàng, và là một điểm hỏng đơn lẻ nếu chỉ có một máy. Đề đòi hiệu năng cao nhất, và một máy trung gian tự quản không bằng dịch vụ có quản lý.

Ghi nhớ

⚠ Hai hướng của Route 53 Resolver endpoint — bảng phải thuộc: | Hướng | Truy vấn đi từ | Dùng khi | |---|---|---| | Inbound | mạng tại chỗ → VPC Resolver | on-premises phân giải tên trong AWS | | Outbound | VPC → DNS bên ngoài | AWS phân giải tên của mạng tại chỗ | | Cả hai | môi trường lai hai chiều | phổ biến nhất trong thực tế |

Từ khoá nhận diện:

"on-premises resolve AWS names" → inbound resolver "VPC resolve on-premises names" → outbound resolver + forwarding rule "tất cả VPC phải phân giải được" → liên kết zone với TẤT CẢ VPC "HIGHEST performance" → mỗi VPC hỏi resolver của chính nó, không đi vòng EC2 làm conditional forwarder → tự dựng, thêm điểm hỏng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VPC có phân giải được không | dig internal.company.local từ instance trong từng VPC | | Tại chỗ có phân giải được không | dig @<ip-inbound-endpoint> internal.company.local | | Zone đã liên kết VPC nào | aws route53 get-hosted-zone --id <id>, xem VPCs |

Và một lời khuyên: hãy đưa bước liên kết VPC với private hosted zone vào chính template dựng VPC. Đây là thao tác dễ quên nhất trong toàn bộ thiết lập DNS lai, và nó hỏng theo cách khó chẩn đoán: VPC mới được dựng đúng, gắn transit gateway đúng, mạng thông hoàn toàn — chỉ có tên miền nội bộ là không phân giải được. Người gỡ lỗi sẽ kiểm route table, security group, transit gateway attachment, tất cả đều đúng, vì phần sai là một liên kết chưa tồn tại và không có màn hình nào liệt kê những thứ lẽ ra phải được liên kết.

Đáp án

A — Tạo một bucket S3 cho pipeline; cấu hình S3 caching cho các CodeBuild project; cập nhật buildspec và thêm thư mục dữ liệu vào định nghĩa cache.

Vì sao đúng

Vấn đề của đề rất cụ thể: nhiều project cùng tải một tập dữ liệu marketing lớn từ S3, và pipeline ngày càng chậm. Cache là cách bỏ bớt việc tải lại.

⚠ Điểm mấu chốt: S3 cache dùng chung được giữa các build và các project — local cache thì không:

S3 caching
        ↓
    Cache lưu trong bucket, mọi máy build đều lấy được
        ↓
    → project A build xong, project B tận dụng được
    → build chạy trên máy mới vẫn có cache

LOCAL_SOURCE_CACHE (phương án D)
        ↓
    Cache nằm trên chính máy build đó
        ↓
    → CodeBuild thường cấp máy mới cho mỗi build
    → cache biến mất, gần như không bao giờ trúng

# buildspec.yml
version: 0.2
phases:
  build:
    commands:
      - ./chay-build.sh
cache:
  paths:
    - 'du-lieu-marketing/**/*'

⚠ Cache chỉ có ích nếu dữ liệu ít thay đổi — với dữ liệu đổi mỗi lần build thì nó thành gánh nặng:

Dữ liệu marketing do bên thứ ba cung cấp, ít thay đổi
        ↓
    Tỷ lệ trúng cache cao → tiết kiệm thật
        ↓
Nếu dữ liệu đổi hằng ngày
        ↓
    Mỗi build vừa tải mới vừa ghi lại cache → chậm hơn cả không cache

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

• B (tạo bucket S3 cho pipeline; cấu hình bucket đó làm SECONDARY SOURCE cho các project; thêm bucket và thư mục dữ liệu vào định nghĩa cache) — đây là phương án gần nhất và nó cũng dùng S3, cũng nhắc tới cache. Nhưng nó lẫn hai khái niệm: secondary source là nguồn đầu vào bổ sung, được tải xuống mỗi lần build — tức là đúng thứ đang gây chậm, chỉ đổi chỗ lấy dữ liệu. Và câu "thêm bucket vào định nghĩa cache" không có nghĩa: cache khai theo đường dẫn trong thư mục build, không khai theo bucket.

• D (đặt cache của project là LOCAL_SOURCE_CACHE) — sai loại cache. Local cache nằm trên máy build, mà CodeBuild thường cấp máy mới cho mỗi lần chạy — nên tỷ lệ trúng rất thấp. Ngoài ra LOCAL_SOURCE_CACHE dành riêng cho việc cache lịch sử Git, không phải cho thư mục dữ liệu tuỳ ý.

• C (tạo VPC mới, dựng EFS trong đó, cho CodeBuild chạy trong VPC và mount EFS vào chỗ thư mục dữ liệu) — chạy được nhưng nặng nề và chậm hơn: đặt CodeBuild vào VPC làm tăng thời gian khởi động build đáng kể vì phải cấp phát ENI. Thêm một EFS file system phải vận hành và trả tiền, cho một bài toán mà cache giải quyết được bằng cấu hình.

Ghi nhớ

⚠ Ba loại cache của CodeBuild — bảng phải thuộc: | Loại | Lưu ở | Dùng chung giữa các build | |---|---|---| | S3 cache | bucket S3 | có — mọi máy, mọi project | | Local cache | máy build | không | | Không cache | — | — |

Từ khoá nhận diện:

"nhiều project dùng chung dữ liệu lớn" → S3 cache "build chậm dần khi thêm project" → đang tải lại cùng một thứ nhiều lần "secondary source" → nguồn đầu vào, tải MỖI lần build "LOCAL_SOURCE_CACHE" cho thư mục dữ liệu → sai loại, và không dùng chung được đặt CodeBuild vào VPC → tăng thời gian khởi động build

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cache có trúng không | log build hiện dòng khôi phục cache | | Thời gian build có giảm không | so duration trước và sau | | Cache có phình không | kiểm dung lượng bucket cache, đặt lifecycle dọn |

Và một lời khuyên: hãy đặt lifecycle rule dọn bucket cache, và đo tỷ lệ trúng trước khi kết luận là đã tối ưu. Cache trong CodeBuild không tự hết hạn: mỗi project ghi phiên bản cache của nó, và với hàng chục project cùng cache một tập dữ liệu lớn, bucket phình lên rất nhanh — bạn tiết kiệm được thời gian build và trả lại bằng chi phí lưu trữ. Tệ hơn, nếu định nghĩa cache trỏ vào một đường dẫn thay đổi mỗi lần build, cache sẽ không bao giờ trúng nhưng vẫn được ghi lại mỗi lần: bạn có toàn bộ chi phí và không có lợi ích nào, và log build không nói gì về điều đó trừ khi bạn đọc kỹ.

Đáp án

A, C — hai bước cho kết nối bắc cầu đầy đủ giữa 15 VPC và trung tâm dữ liệu, với ít phức tạp nhất:

• C — Tạo transit gateway và gắn tất cả các VPC vào; cấu hình route table của các VPC gửi lưu lượng tới transit gateway.
• A — Tạo Direct Connect gateway và gắn nó vào transit gateway; bật route propagation với BGP.

Vì sao đúng

Hai từ khoá của đề quyết định tất cả: transitive peering và 15 VPC.

⚠ Điểm mấu chốt: VPC peering KHÔNG bắc cầu — đó là lý do nó không dùng được ở quy mô này:

VPC peering
        ↓
    A ↔ B và B ↔ C KHÔNG cho A nói chuyện với C
        ↓
    Muốn 15 VPC nói chuyện với nhau → cần n(n-1)/2 = 105 kết nối
        ↓
    Cộng với 105 mục route table phải quản
        ↓
Transit gateway
        ↓
    Mỗi VPC gắn MỘT lần vào trung tâm
        ↓
    → 15 attachment thay vì 105 peering

Phép tính này là nội dung chính của câu hỏi.

Vì sao Direct Connect gateway gắn vào transit gateway (A). Để trung tâm dữ liệu nối vào cùng mạng đó, bạn dùng transit VIF tới Direct Connect gateway, rồi liên kết nó với transit gateway.

aws ec2 create-transit-gateway --description "mang-chung"
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-abc --vpc-id vpc-1 --subnet-ids subnet-a
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id dxgw-abc --gateway-id tgw-abc

⚠ Direct Connect gateway gắn với VGW thì KHÔNG bắc cầu — chỉ gắn với transit gateway mới bắc cầu:

DX gateway + virtual private gateway (phương án E)
        ↓
    Mỗi VPC nối riêng tới DX gateway
        ↓
    → trung tâm dữ liệu tới được từng VPC
    → nhưng các VPC KHÔNG nói chuyện được với nhau
        ↓
    → không đạt yêu cầu "full transitive peering"

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

• E (tạo Direct Connect gateway và liên kết với một VGW ở MỖI VPC, bật route propagation với BGP) — đây là phương án gần nhất và nó thật sự nối được trung tâm dữ liệu với cả 15 VPC. Nhưng nó không tạo ra kết nối bắc cầu giữa các VPC với nhau: DX gateway cho phép mạng tại chỗ tới từng VPC, nhưng lưu lượng không đi xuyên qua nó từ VPC này sang VPC khác. Đề đòi "full transitive peering between the VPCs and the on-premises data center" — cả hai chiều.

• B (VPC peering lưới đầy đủ giữa các VPC) — 105 kết nối và hàng trăm mục route table cho 15 VPC, và peering vẫn không bắc cầu nên mỗi cặp phải có kết nối riêng. Đây là phương án phức tạp nhất, trái thẳng tiêu chí "LEAST complexity".

• D (IPSec VPN lưới đầy đủ giữa các VPC) — cùng vấn đề quy mô như B, cộng thêm chi phí và độ phức tạp của việc quản lý hàng trăm đường hầm VPN, mỗi cái có hai tunnel.

Ghi nhớ

⚠ Bốn cách nối nhiều VPC — bảng phải thuộc: | Cách | Bắc cầu | Số kết nối cho n VPC | |---|---|---| | VPC peering | không | n(n-1)/2 | | Transit gateway | có | n | | Transit VPC (mẫu cũ) | có | n, nhưng tự quản router | | PrivateLink | không áp dụng — phơi một dịch vụ | — |

Từ khoá nhận diện:

"transitive peering" → transit gateway, peering không làm được nhiều VPC + "LEAST complexity" → transit gateway nối trung tâm dữ liệu vào cùng mạng đó → DX gateway gắn vào transit gateway "DX gateway + VGW ở mỗi VPC" → tới được từng VPC nhưng KHÔNG bắc cầu giữa chúng lưới đầy đủ peering hoặc VPN → phức tạp nhất, loại ngay

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tuyến có lan truyền không | kiểm route table của transit gateway | | VPC có nói chuyện được với nhau không | ping giữa instance ở hai VPC khác nhau | | BGP có lên không | describe-direct-connect-gateway-associations |

Và một lời khuyên: hãy dùng nhiều route table của transit gateway để phân đoạn mạng, đừng để mọi VPC nói chuyện được với mọi VPC. Transit gateway mặc định cho kết nối bắc cầu hoàn toàn, và đó thường là điều bạn muốn ở mức kỹ thuật nhưng không phải ở mức bảo mật: một VPC thử nghiệm giờ có đường tới VPC production, và không có gì ngăn nó ngoài security group. Route table riêng cho từng nhóm — production, phi production, dịch vụ chung — cho bạn kiểm soát ở tầng định tuyến, nơi một cấu hình sai security group không phá vỡ được.

Đáp án

B — Tạo cross-Region read replica ở us-west-1; dùng EventBridge kích hoạt Lambda thăng cấp replica thành primary và cập nhật DNS endpoint của cơ sở dữ liệu.

Vì sao đúng

Hai chỉ tiêu — RPO 5 phút và RTO 15 phút — cùng yêu cầu hoàn toàn tự động chỉ có một lời giải.

⚠ Điểm mấu chốt: chỉ sao chép liên tục mới đạt RPO tính bằng phút — mọi cách theo chu kỳ đều thua:

Cross-Region read replica
        ↓
    Sao chép bất đồng bộ liên tục
        ↓
    → RPO tính bằng giây

Sao chép snapshot (phương án A)
        ↓
    RPO bằng chu kỳ chụp, và khôi phục mất hàng chục phút
        ↓
    → không đạt cả hai chỉ tiêu

def handler(su_kien, ngu_canh):
    rds.promote_read_replica(DBInstanceIdentifier='du-phong-us-west')
    # cập nhật bản ghi DNS trỏ tới endpoint mới
    route53.change_resource_record_sets(...)

⚠ Ứng dụng phải trỏ tới một tên DNS trung gian, không trỏ thẳng endpoint của RDS:

Ứng dụng dùng thẳng endpoint RDS
        ↓
    Chuyển vùng đổi cơ sở dữ liệu nhưng ứng dụng vẫn gọi endpoint cũ
        ↓
    → phải sửa cấu hình và triển khai lại — mất RTO
        ↓
Dùng một bản ghi CNAME riêng (ví dụ db.congty.vn)
        ↓
    Lambda chỉ cần trỏ CNAME sang endpoint mới
        ↓
    → ứng dụng không cần đổi gì

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

• A (Lambda sao chép snapshot RDS sang us-west-1; EventBridge kích hoạt Lambda tạo cơ sở dữ liệu mới từ snapshot) — đây là phương án gần nhất và nó cũng tự động hoá bằng EventBridge và Lambda. Nhưng nó thua ở cả hai chỉ tiêu: RPO bằng chu kỳ sao chép snapshot (khó xuống 5 phút), và khôi phục từ snapshot mất hàng chục phút tới hàng giờ tuỳ kích thước — vượt RTO 15 phút. Đây là mẫu backup-restore, phù hợp khi RTO tính bằng giờ.

• C (dùng RDS Multimaster trên cả hai Region, EC2 ở us-west-1 ghi vào writer endpoint tại chỗ) — mô tả một thứ không tồn tại theo cách này. RDS không có chế độ multi-master xuyên Region; Aurora từng có multi-master nhưng chỉ trong một Region và đã ngừng phát triển. Với MySQL trên RDS, lựa chọn đa Region là read replica.

• D (cron chạy mysqldump xuất ra S3; EventBridge kích hoạt Lambda nhập vào cơ sở dữ liệu chờ ở us-west-1) — chậm và thủ công. mysqldump trên cơ sở dữ liệu production gây tải nặng, và chu kỳ xuất quyết định RPO. Việc nhập lại cũng mất rất nhiều thời gian, phá vỡ RTO.

Ghi nhớ

⚠ Bốn cách bảo vệ cơ sở dữ liệu xuyên Region — bảng phải thuộc: | Cách | RPO | RTO | |---|---|---| | RDS cross-Region read replica | vài giây | vài phút (promote) | | Aurora Global Database | ~1 giây | dưới 1 phút | | Sao chép snapshot | bằng chu kỳ chụp | hàng chục phút tới giờ | | Xuất/nhập thủ công | bằng chu kỳ xuất | rất chậm |

Từ khoá nhận diện:

"RPO 5 phút" + "RTO 15 phút" → read replica, không phải snapshot "fully automated" → EventBridge + Lambda "RDS Multimaster xuyên Region" → LUÔN SAI, không tồn tại "mysqldump theo cron" → RPO và RTO đều kém Aurora + đa Region → Global Database thay vì read replica

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép | chỉ số ReplicaLag | | RTO thật | diễn tập promote trên một replica dựng riêng để thử | | DNS có đổi được không | kiểm TTL và thử đổi bản ghi |

Và một lời khuyên: hãy hạ TTL của bản ghi DNS trỏ tới cơ sở dữ liệu xuống 60 giây, và giữ nó ở mức đó. Với một kế hoạch chuyển vùng tự động, thời gian Lambda chạy xong chỉ là một nửa câu chuyện — nửa còn lại là bao lâu thì ứng dụng thật sự bắt đầu gọi vào cơ sở dữ liệu mới. Nếu TTL đang là một giờ, thì dù Lambda đổi bản ghi trong ba giây, các máy ứng dụng vẫn kiên trì kết nối tới endpoint cũ cho tới khi cache DNS của chúng hết hạn. RTO thực tế của bạn không phải là thời gian promote, mà là thời gian promote cộng với TTL.

Đáp án

B — Triển khai AWS Global Accelerator với cấu hình standard accelerator; gắn ALB của từng Region vào accelerator và cung cấp cho khách hàng các địa chỉ IP tĩnh của nó.

Vì sao đúng

Đề đòi hai thứ mà chỉ một dịch vụ cho cả hai: địa chỉ IP cố định để khách whitelist và tự động đưa người dùng tới Region gần nhất.

⚠ Điểm mấu chốt: hai địa chỉ anycast KHÔNG đổi khi bạn thêm Region — đó là điều khiến nó thắng mọi phương án khác:

Global Accelerator
        ↓
    Cấp hai IP tĩnh từ dải anycast của AWS
        ↓
    Thêm Region mới → chỉ thêm endpoint group
        ↓
    → khách hàng KHÔNG phải cập nhật tường lửa lần nào nữa
        ↓
Route 53 hoặc CloudFront
        ↓
    Địa chỉ thay đổi hoặc là cả một dải rất lớn
        ↓
    → khách hàng phải cập nhật liên tục

Với kế hoạch mở rộng ra nhiều Region mà đề nêu, đây là khác biệt quyết định.

aws globalaccelerator create-accelerator --name crm-toan-cau
aws globalaccelerator create-endpoint-group \
  --listener-arn <listener> --endpoint-group-region ap-southeast-1 \
  --endpoint-configurations EndpointId=<alb-arn>,Weight=100

⚠ Anycast định tuyến theo mạng, không theo địa lý — nên nó tối ưu ĐỘ TRỄ thật:

Người dùng gửi gói tin tới IP anycast
        ↓
    Mạng Internet đưa tới điểm biên AWS gần nhất về mặt MẠNG
        ↓
    Từ đó lưu lượng đi trên xương sống AWS tới Region đích
        ↓
    → phần lớn quãng đường nằm trong mạng AWS, không phải Internet công cộng

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

• A (Route 53 geolocation routing; đưa cho khách IP của các ALB) — đây là phương án gần nhất và nó thật sự định tuyến được theo vị trí. Nhưng nó vỡ ở vế IP cố định: ALB không có địa chỉ IP tĩnh — nó chỉ có tên DNS, và các địa chỉ đằng sau thay đổi theo thời gian khi AWS co giãn hạ tầng. Đưa cho khách một danh sách IP của ALB nghĩa là danh sách đó sẽ lỗi thời, và khách bị chặn ngẫu nhiên. Ngoài ra geolocation định tuyến theo quốc gia, không theo độ trễ thật.

• C (CloudFront distribution cho từng Region; đưa cho khách dải IP của các điểm biên) — hai vấn đề. Dải IP của CloudFront rất lớn và thay đổi liên tục — không thể là danh sách whitelist ổn định. Và dải đó dùng chung cho mọi khách hàng AWS, nên whitelist nó không có nhiều ý nghĩa bảo mật.

• D (Transit Gateway với inter-region peering; nối ALB của từng Region vào; chia sẻ IP cho khách) — sai công cụ hoàn toàn. Transit gateway nối các mạng riêng với nhau, nó không phải điểm vào cho lưu lượng từ Internet và không cấp địa chỉ công cộng cho khách hàng kết nối.

Ghi nhớ

⚠ Global Accelerator so với CloudFront — bảng phải thuộc: | | Global Accelerator | CloudFront | |---|---|---| | Việc chính | tối ưu đường mạng, IP tĩnh | cache nội dung tại biên | | Giao thức | TCP và UDP | HTTP/HTTPS | | Địa chỉ | hai IP anycast tĩnh | tên DNS, dải IP lớn | | Hợp với | API động, game, IoT, cần IP tĩnh | nội dung tĩnh và động qua HTTP | | Chuyển vùng | vài giây, không phụ thuộc DNS | theo origin group |

Từ khoá nhận diện:

"fixed IP addresses for firewall allow lists" → Global Accelerator "route to nearest regional deployment" → anycast của Global Accelerator "IP của ALB" để whitelist → LUÔN SAI, ALB không có IP tĩnh "dải IP của CloudFront" để whitelist → quá lớn, đổi liên tục, dùng chung cần IP tĩnh trong MỘT Region → NLB với Elastic IP là đủ, rẻ hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP có cố định không | describe-accelerator, xem IpSets | | Người dùng đi tới Region nào | log của ALB ở từng Region | | Chuyển vùng có chạy không | tắt endpoint group một Region và quan sát |

Và một lời khuyên: hãy cung cấp cho khách hàng cả hai địa chỉ IP của accelerator, không chỉ một. Global Accelerator luôn cấp hai địa chỉ anycast từ hai dải mạng khác nhau, và điều đó là có chủ đích: nếu một dải gặp sự cố định tuyến ở một nhà mạng nào đó, địa chỉ còn lại vẫn tới được. Nếu khách hàng chỉ whitelist một, họ mất toàn bộ khả năng dự phòng đó — và sự cố sẽ xuất hiện dưới dạng "chỉ một số khách hàng không kết nối được", tuỳ nhà mạng của họ, một triệu chứng gần như không thể tái hiện từ phía bạn.

Đáp án

C — Điều chỉnh cấu hình workload để dùng topology spread constraint theo Availability Zone.

Vì sao đúng

Đề đòi tối ưu khả năng chịu lỗi của các node cho một workload sinh ra rất nhiều pod stateless trong thời gian ngắn. Vấn đề là phân bố, và Kubernetes có cơ chế khai báo riêng cho nó.

⚠ Điểm mấu chốt: bộ lập lịch mặc định của Kubernetes KHÔNG đảm bảo trải đều theo AZ:

Hàng trăm pod được tạo trong vài giây
        ↓
    Scheduler xếp chúng lên các node còn chỗ, theo thứ tự nó thấy
        ↓
    Rất dễ dồn phần lớn pod vào các node của cùng một AZ
        ↓
    Mất AZ đó → mất phần lớn công suất cùng lúc
        ↓
Topology spread constraint
        ↓
    Khai báo: chênh lệch số pod giữa các AZ không quá N
        ↓
    → scheduler buộc phải trải đều

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: xu-ly

⚠ whenUnsatisfiable quyết định hành vi khi không trải đều được: | Giá trị | Nghĩa | |---|---| | DoNotSchedule | không xếp pod nếu vi phạm ràng buộc — chặt, nhưng pod có thể nằm chờ | | ScheduleAnyway | cố gắng trải đều, nhưng vẫn xếp nếu không được — hợp với workload co giãn nhanh |

Với workload sinh nhiều pod trong thời gian ngắn, ScheduleAnyway tránh được tình trạng pod bị kẹt.

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

• B (giảm số node group nhưng dùng instance lớn hơn trong đó) — đây là phương án gần nhất và instance lớn hơn thật sự chứa được nhiều pod hơn, giảm áp lực lên scheduler. Nhưng nó làm giảm khả năng chịu lỗi, đúng thứ đề muốn tối ưu: ít node hơn nghĩa là mất một node là mất một tỷ lệ lớn công suất. Với pod stateless, nhiều node nhỏ luôn chịu lỗi tốt hơn ít node lớn.

• D (cấu hình Cluster Autoscaler giữ công suất của node group ở mức thường xuyên THIẾU) — đi ngược mục tiêu. Cố ý thiếu công suất nghĩa là pod phải chờ node mới khởi động mỗi khi có đợt tạo pod — chậm và kém tin cậy. (Cách đúng cho vấn đề đó là over-provisioning: giữ sẵn một ít node dư bằng các pod ưu tiên thấp.)

• A (dùng launch template riêng để triển khai EKS control plane ở một cluster phụ) — mô tả một thứ không tồn tại. Control plane của EKS do AWS quản lý hoàn toàn — bạn không triển khai nó, không có launch template cho nó, và nó đã sẵn sàng cao trên nhiều AZ theo mặc định.

Ghi nhớ

⚠ Bốn cơ chế phân bố pod trong Kubernetes — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Topology spread constraint | trải đều theo AZ, node, hoặc nhãn tuỳ ý | | Pod anti-affinity | không xếp hai pod cùng loại lên cùng node | | Node affinity / selector | chỉ xếp lên node có nhãn nhất định | | Taint và toleration | dành riêng node cho một loại workload |

Từ khoá nhận diện:

"resilience of the nodes" + nhiều pod stateless → topology spread constraint "trải đều theo AZ" → topologyKey: topology.kubernetes.io/zone "triển khai EKS control plane" → LUÔN SAI, AWS quản lý control plane "ít node group, instance lớn hơn" → giảm khả năng chịu lỗi "cố ý thiếu công suất" → pod phải chờ, kém tin cậy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pod có trải đều không | kubectl get pods -o wide rồi đếm theo node và AZ | | Có pod nào pending không | kubectl get pods --field-selector status.phase=Pending | | Mất một AZ có sao không | cordon và drain toàn bộ node của một AZ |

Và một lời khuyên: hãy thêm Pod Disruption Budget bên cạnh topology spread constraint. Hai thứ này bảo vệ hai kịch bản khác nhau: spread constraint lo việc pod được xếp ra sao, còn PDB lo việc bao nhiêu pod được phép biến mất cùng lúc trong các thao tác tự nguyện — nâng cấp node group, drain node, Cluster Autoscaler thu gọn cụm. Không có PDB, một lần nâng cấp node group hoàn toàn bình thường có thể drain nhiều node cùng lúc và đưa số pod đang phục vụ xuống dưới mức tối thiểu, dù pod của bạn đã được trải đều hoàn hảo trước đó.

Đáp án

C — Triển khai một bản thu nhỏ của môi trường production ở Region khác đảm bảo khoảng cách tối thiểu; môi trường DR gồm một instance cho tầng web và một cho tầng ứng dụng; tạo một cơ sở dữ liệu khác và cấu hình sao chép source-replica cho MySQL; bật Auto Scaling cho tầng web và app; dùng Route 53 chuyển lưu lượng sang Region DR.

Vì sao đúng

Ba chỉ tiêu của đề — RTO 5 phút, RPO 1 giờ, chi phí hợp lý — chỉ thẳng tới warm standby.

⚠ Điểm mấu chốt: RTO 5 phút không cho phép dựng bất cứ thứ gì từ đầu:

RTO 5 phút
        ↓
    Trừ thời gian phát hiện và quyết định → còn rất ít
        ↓
    Không đủ để chạy CloudFormation dựng web server, app server, load balancer
        ↓
    → hạ tầng phải ĐANG CHẠY, chỉ cần nhận tải và co giãn lên

Đây là lý do phương án B (pilot light với CloudFormation dựng khi có sự cố) không đạt.

⚠ Auto Scaling ở Region DR phải được cấu hình sẵn và đã kiểm chứng:

Môi trường DR chạy một instance mỗi tầng
        ↓
    Chuyển vùng → tải production đổ sang
        ↓
    Auto Scaling phải nhân lên rất nhanh
        ↓
    → cần đủ hạn mức vCPU ở Region đó, và AMI đã sao chép sẵn

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

• B (đa Region với chiến lược pilot light; dùng CloudFormation dựng web server, app server và load balancer khi có sự cố) — đây là phương án gần nhất và pilot light là một chiến lược DR hoàn toàn hợp lệ, rẻ hơn warm standby. Nhưng nó không đạt RTO 5 phút: dựng load balancer, khởi động instance, chờ health check qua — tất cả sau khi sự cố đã bắt đầu — thường mất từ mười phút trở lên. Pilot light hợp với RTO tính bằng chục phút tới giờ.

• D (đa Region với hạ tầng ĐẦY ĐỦ, công suất tương đương ở cả hai; chỉ kích hoạt cơ sở dữ liệu chính ở một Region) — đạt RTO nhưng đắt nhất: bạn trả tiền cho một bản sao production đầy đủ chạy không tải. Đề nói "cost-efficient", nên đây là mức đầu tư quá lớn cho RTO 5 phút mà warm standby cũng đạt được.

• A (đa Region; snapshot EC2 định kỳ và sao chép sang Region DR; cross-Region read replica; CloudFormation dựng web và app tier khi có sự cố) — cùng vấn đề với B ở vế tính toán: dựng khi sự cố xảy ra thì không kịp RTO 5 phút. Câu "fail over the RDS DB to the standby instance" cũng lẫn giữa Multi-AZ (trong Region) và cross-Region replica.

Ghi nhớ

⚠ Bốn chiến lược DR và RTO tương ứng — bảng phải thuộc: | Chiến lược | Tầng dữ liệu | Tầng tính toán | RTO | Chi phí | |---|---|---|---|---| | Backup & Restore | sao lưu | không có gì | giờ | thấp nhất | | Pilot Light | replica chạy | tắt | chục phút | thấp | | Warm Standby | replica chạy | chạy quy mô nhỏ | phút | trung bình | | Active/Active | multi-master | đầy đủ | gần 0 | cao nhất |

Từ khoá nhận diện:

"RTO 5 phút" → hạ tầng phải đang chạy — warm standby trở lên "cost-efficient" + RTO phút → warm standby, không phải active/active "dựng bằng CloudFormation khi có sự cố" → pilot light, RTO chục phút "công suất tương đương ở cả hai Region" → đắt, chỉ cần khi RTO gần 0 "khoảng cách tối thiểu 150 dặm" → Region khác, không phải AZ khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RTO thật | diễn tập chuyển vùng, bấm giờ từ lúc alarm kêu | | Region DR có gánh nổi không | chuyển toàn bộ tải sang và để chạy thật vài giờ | | Sao chép có bắt kịp không | độ trễ sao chép MySQL |

Và một lời khuyên: hãy chuyển toàn bộ tải sang Region DR và để nó chạy thật vài giờ, ít nhất mỗi quý. Warm standby chạy ở quy mô nhỏ suốt thời gian bình thường, nghĩa là nó chưa bao giờ được kiểm chứng dưới tải thật. Auto Scaling có nhân lên kịp không, hạn mức có đủ không, cơ sở dữ liệu replica có chịu nổi tải ghi không — tất cả đều là giả định cho tới khi bạn thử. Và nếu lần đầu tiên chúng được thử lại chính là lúc Region chính đang cháy, thì bạn đang gỡ hai sự cố cùng một lúc.