接管的操作順序是：先拍下現況（盤點）、再理解結構（依賴）、再收斂風險（credential、備份）、再建立紀律（變更紀錄）、最後才考慮 IaC 導入。每一步都在不改動 production 的前提下進行。

資源盤點：拍下雲端現況

盤點的目標是把「雲端上有什麼」轉成一份可版本控制的清單。這份清單是後續所有操作的事實基礎 — 沒有清單就無法判斷哪些資源重要、哪些可以回收、哪些的設定有風險。

盤點的工具依環境類型不同：

• VM 為主（EC2 / GCE） → 先跑 VM 快照與系統清單，再跑 CLI 資源盤點
• Managed service 為主（RDS / Lambda / S3） → 直接跑 CLI 資源盤點
• 混合（VM + managed） → 兩個都跑：先 VM 快照（拍下機器狀態），再 CLI 盤點（拍下所有雲端資源）

用 CLI 拉清單

盤點有三層工具可用，從粗到細：

全貌掃描：先用跨服務工具拿到「到底有多少資源」的量級感。AWS Resource Explorer 在 Console 開啟後可以用搜尋語法跨 region、跨 service 查資源（例如搜 resourcetype:ec2:instance 列出所有 EC2）。Steampipe 是開源的 SQL 介面雲端查詢工具，用 select * from aws_ec2_instance 這類語法查詢，對習慣 SQL 的人比 CLI flag 直覺。兩者都能在幾分鐘內拿到環境的全貌。

Tag 層掃描：AWS Resource Groups Tagging API 能跨服務撈出所有被標記的資源，但會漏掉沒有 tag 的 — 而接手環境裡沒 tag 的資源往往是風險最高的（沒人認領、不敢動）。

1aws resourcegroupstaggingapi get-resources \
2  --output json > inventory/tagged-resources.json

Per-service 細節：全貌掃描只告訴你資源存在，細節（備份設定、SG 規則、IAM policy）要用 per-service describe 拉。以下是接手時最該優先盤點的四類：

 1# EC2：哪些機器在跑、什麼規格、在哪個 subnet
 2aws ec2 describe-instances \
 3  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,SubnetId,SecurityGroups[].GroupId,Tags]' \
 4  --output json > inventory/ec2.json
 5
 6# RDS：資料庫的備份設定、刪除保護、Multi-AZ
 7aws rds describe-db-instances \
 8  --query 'DBInstances[].[DBInstanceIdentifier,Engine,DBInstanceClass,MultiAZ,BackupRetentionPeriod,DeletionProtection]' \
 9  --output json > inventory/rds.json
10
11# Security Group：哪些規則對外開放
12aws ec2 describe-security-groups \
13  --query 'SecurityGroups[].[GroupId,GroupName,IpPermissions]' \
14  --output json > inventory/security-groups.json
15
16# S3：哪些 bucket、versioning 是否開啟
17for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
18  echo "$bucket: $(aws s3api get-bucket-versioning --bucket $bucket --query 'Status' --output text)"
19done > inventory/s3-versioning.txt

把所有輸出存進一個 Git repo 的 inventory/ 目錄。這份快照的價值在於：一週後再跑一次比對差異，就能看出環境在背景長出了什麼新資源。

優先查三件事

盤點不需要一次做完所有服務，但三件事要第一天就查：

對外暴露面：security group 裡有沒有 0.0.0.0/0 入站規則指向非 HTTP/HTTPS 的 port（22、3306、5432、6379）。手動逐條查很慢 — 用安全掃描工具一次跑完更可靠。Prowler 是開源的 AWS 安全掃描工具，一次執行就能產出「哪些 SG 對外開放、哪些 S3 public、哪些 IAM 過寬」的分類報告：

1# 安裝後執行，針對最相關的服務掃描
2prowler aws --services ec2 iam s3 rds -M json-ocsf -o inventory/
3
4# 如果只想快速查 SG 暴露面，用 CLI：
5aws ec2 describe-security-groups \
6  --query 'SecurityGroups[].IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`)]' \
7  --output json | jq '[.[][] | select(.FromPort != 80 and .FromPort != 443)]'

ScoutSuite 是類似工具、支援多雲（AWS / GCP / Azure）。AWS Trusted Advisor 的免費 tier 也有基本安全檢查（S3 public access、SG 開放埠），但覆蓋面比 Prowler 窄。接手時三者選一跑一次，比手動翻 Console 快且不會漏。

備份狀態：RDS 的 BackupRetentionPeriod 是不是 0（代表沒有自動備份）。S3 的 versioning 是不是關的。如果是，這是接手後第一個要改的設定 — 改備份設定不影響服務運作，但沒有備份時任何資料操作失誤都不可逆。

誰最近在動環境：CloudTrail 記錄了所有 API 呼叫。查最近 30 天的變更事件，能看出哪些資源被頻繁修改、被誰修改。這比逐一問前團隊成員可靠——CloudTrail 不會漏記。

1aws cloudtrail lookup-events \
2  --lookup-attributes AttributeKey=ReadOnly,AttributeValue=false \
3  --start-time $(date -v-30d +%Y-%m-%dT%H:%M:%S) \
4  --max-items 50 \
5  --query 'Events[].[EventTime,Username,EventName,Resources[0].ResourceName]' \
6  --output table

VM 層級的快照

如果接手的環境包含 EC2 或 GCE 等 VM，在做任何改動之前先對每台 VM 建一個 AMI（AWS）或 machine image（GCP）。這是最粗粒度但最完整的「拍照」——整台機器的 OS、安裝的軟體、設定檔、磁碟內容全部打包成一個可重建的映像。

 1# AWS: 對 EC2 建 AMI（--no-reboot 避免服務中斷）
 2aws ec2 create-image \
 3  --instance-id i-0abc123 \
 4  --name "takeover-baseline-$(date +%Y%m%d)" \
 5  --no-reboot
 6
 7# 確認 AMI 建立完成
 8aws ec2 describe-images \
 9  --owners self \
10  --filters "Name=name,Values=takeover-baseline-*" \
11  --query 'Images[].[ImageId,Name,State]' \
12  --output table

--no-reboot 讓快照過程中服務不中斷，代價是檔案系統快照的一致性不如有 reboot 的版本（記憶體中的寫入可能還沒 flush 到磁碟），但對接手基線已經足夠。AMI 的費用是底層 EBS 快照的儲存費用（按 GB 計費、差異儲存），作為接手保險措施這筆成本值得。

除了 VM 快照，有 SSH 存取時也要拍 VM 內部的軟體環境——AMI 可以還原整台機器，但看不到「裡面裝了什麼、跑了什麼」的摘要：

 1# 作業系統與版本
 2cat /etc/os-release
 3
 4# 已安裝的套件清單
 5dpkg -l > ~/takeover/packages-$(date +%Y%m%d).txt   # Debian/Ubuntu
 6rpm -qa > ~/takeover/packages-$(date +%Y%m%d).txt    # RHEL/CentOS/Amazon Linux
 7
 8# 執行中的服務
 9systemctl list-units --type=service --state=running > ~/takeover/services.txt
10
11# 所有使用者的 cron jobs
12for user in $(cut -f1 -d: /etc/passwd); do
13  echo "=== $user ===" >> ~/takeover/crontabs.txt
14  crontab -u "$user" -l 2>/dev/null >> ~/takeover/crontabs.txt
15done
16
17# 網路監聽的 port（哪個 process 在聽哪個 port）
18ss -tlnp > ~/takeover/listening-ports.txt

把這些輸出存進盤點 repo，跟 CLI 資源盤點（describe 指令的輸出）放在一起。listening-ports.txt 跟 security group 規則對照，可以看出「哪些 port 有服務在聽但 SG 沒開」（可能是內部服務）和「哪些 port SG 開了但沒有服務在聽」（可能是殘留規則）。

依賴關係推導

盤點回答「有什麼」，依賴推導回答「改一個會連帶影響什麼」。手動環境沒有 Terraform 的依賴圖可以看，需要從資源的引用關係反推。

從 security group 開始

Security group 是依賴推導的最佳起點，因為它的引用關係最密集 — 幾乎每個資源都掛著至少一個 SG，而 SG 之間可以互相引用（app SG 的入站來源是 LB SG、DB SG 的入站來源是 app SG）。

1# 列出每個 SG 被哪些 ENI（網卡）使用
2aws ec2 describe-network-interfaces \
3  --query 'NetworkInterfaces[].[NetworkInterfaceId,Description,Groups[].GroupId]' \
4  --output json > inventory/sg-usage.json

AWS Console 的 VPC 頁面有 Resource Map 功能，可以視覺化 subnet → instance → SG 的對應關係，接手時第一次瀏覽依賴用它比 CLI 直覺。要產出可存檔的依賴圖，draw.io（有 AWS icon set）或 Lucidchart 都能畫，重點是圖要存進 repo、不是畫完就丟。

如果後續打算導入 Terraform，Former2 可以掃描現有 AWS 資源、自動產出 Terraform / CloudFormation / CDK 程式碼。產出的程式碼不會完美（屬性常漏、命名要改），但作為反推依賴關係的起點比從零寫快。Inframap 則是從 Terraform state 產出依賴關係圖（在 import 階段才用得到）。

從 SG 的引用鏈可以畫出一張粗略的依賴圖：

這張圖不需要精確到每個 port — 它的用途是在改動任何資源前，快速判斷影響範圍。例如要改 app SG 的規則時，先查它被哪些 EC2 和 ECS 引用、它的入站來源 ALB SG 是否受影響。

其他依賴面向

除了 SG，以下幾個引用關係也要記錄：

• EC2 → IAM role：instance profile 決定這台機器能存取什麼（S3 bucket、Secrets Manager、其他 AWS 服務）
• RDS → subnet group：決定資料庫在哪些 subnet 裡，改 VPC 或 subnet 時會受影響
• ALB → target group → EC2/ECS：流量路徑，改 target group 的 health check 或移除成員會影響服務可用性
• Lambda → VPC 設定：如果 Lambda 被放進 VPC，它的出站走 NAT，改 NAT 或 route table 會影響它
• Route 53 → ALB/EC2：DNS 指向哪個資源，改資源 IP 或 ALB 時要同步更新

credential 盤點與收斂

接手環境時，credential 是風險最高的一類 — 前團隊建立的 IAM user 和 access key 可能還在活躍狀態，而那些人已經不在團隊裡了。

接手後第一件事是用 aws-vault 管理自己的 credential。aws-vault 把 AWS access key 存在 OS keychain（macOS Keychain / Windows Credential Manager），而非明文放在 ~/.aws/credentials。執行 AWS 指令時由 aws-vault 注入臨時 session，本地磁碟上不留長期 key 的明文。不要沿用前人留下的 AWS CLI profile — 那些 profile 的權限範圍和用途都不確定。

1# 安裝後設定新的 profile
2aws-vault add takeover-admin
3# 用臨時 session 執行指令
4aws-vault exec takeover-admin -- aws sts get-caller-identity

產出 credential 報告

1aws iam generate-credential-report
2aws iam get-credential-report \
3  --query 'Content' --output text | base64 -d > inventory/credential-report.csv

這份 CSV 列出所有 IAM user、每把 access key 的建立時間、上次使用時間、MFA 是否啟用。從中篩出三類需要處理的：

停用（deactivate）而非直接刪除是關鍵 — 停用後如果某個自動化腳本依賴這把 key 會立刻報錯，這時候可以快速重新啟用；直接刪除就回不去了。觀察期設 7 天，涵蓋一個完整的業務週期（含週末的 cron job）。

檢查 key 散落的位置

Access key 可能被寫在不只一個地方：

 1# EC2 user data 裡是否有 hardcode 的 key
 2aws ec2 describe-instance-attribute \
 3  --instance-id i-xxx --attribute userData \
 4  --query 'UserData.Value' --output text | base64 -d | grep -i "aws_access_key\|aws_secret"
 5
 6# Lambda 環境變數
 7aws lambda list-functions --query 'Functions[].FunctionName' --output text | \
 8  xargs -I{} aws lambda get-function-configuration --function-name {} \
 9  --query 'Environment.Variables' --output json | grep -i "key\|secret\|password"
10
11# SSM Parameter Store
12aws ssm describe-parameters --query 'Parameters[].Name' --output text

找到 hardcode 的 key 後，替換路徑是改用 IAM role（EC2 用 instance profile、Lambda 用 execution role）。替換前先確認 role 的 policy 涵蓋這把 key 原本在做的操作。

備份驗證

盤點出的每個 stateful 資源（RDS、S3、EBS）都要確認備份狀態。接手環境時不能假設「前團隊應該有設定備份」— 要親自驗證。

RDS 備份

1# 檢查每個 RDS instance 的備份設定
2aws rds describe-db-instances \
3  --query 'DBInstances[].[DBInstanceIdentifier,BackupRetentionPeriod,LatestRestorableTime,DeletionProtection]' \
4  --output table

BackupRetentionPeriod 為 0 代表沒有自動備份 — 立刻改成至少 7 天。DeletionProtection 為 false 代表一個誤操作就能刪掉資料庫 — 立刻開啟。這兩項設定的修改不需要重啟、不影響服務。

備份存在不等於備份可用。接手後的第一週內，從最近的 snapshot 還原一台測試 RDS、連進去確認資料完整。這個步驟的成本是一台 RDS 跑幾小時的費用，換到的是「備份確定能用」的確認 — 等到要用備份的時候才發現不能還原，代價是另一個量級。

S3 versioning

沒有開 versioning 的 bucket，物件被覆寫或刪除後不可回復。對承載業務資料的 bucket（上傳的檔案、匯出的報表、設定檔），開啟 versioning：

1aws s3api put-bucket-versioning \
2  --bucket my-business-data \
3  --versioning-configuration Status=Enabled

開啟 versioning 不影響既有物件，但會讓後續的每次覆寫都保留舊版本。儲存成本會因為保留歷史版本而增加 — 配一條 lifecycle rule 設定 noncurrent version 的過期天數來控制。

建立變更紀律

盤點、依賴推導、credential 收斂做完後，環境的現況已經有一份可查的記錄。下一步是確保從現在開始的每一次變更都留下痕跡。

變更日誌

在 inventory repo 裡建一份 CHANGELOG.md，每次改動 production 就追加一筆：

1## 2026-06-26
2
3- **操作者**：alice
4- **資源**：rds/payments-prod
5- **變更**：BackupRetentionPeriod 0 → 14, DeletionProtection false → true
6- **原因**：接手盤點發現備份未開啟
7- **回退方式**：BackupRetentionPeriod 改回 0（不建議）

CloudTrail 確認

確認 CloudTrail 正在記錄 management events。如果沒有 trail 存在，建一個指向 S3 bucket 的 trail — 這是事後追溯「誰動了什麼」的最後防線。

1aws cloudtrail describe-trails --query 'trailList[].{Name:Name,S3:S3BucketName,IsLogging:IsLogging}'

開始標 tag

盤點過程中辨識出的每個資源，標上 env、owner、service 三個 tag。接手階段的 owner 通常標「待確認」或新接手的團隊名稱。tag 的價值在於讓後續的盤點和清理可以用查詢系統性地進行 — 沒有 tag 的資源無法被 filter 找到。

往 IaC 的銜接

盤點和紀律建立完成後，環境已經從「不知道有什麼」推進到「知道有什麼、知道誰在動、改了有紀錄」。這個狀態對應成熟度階梯的第零階到第一階之間。

成本現況

接手環境通常伴隨「這個月帳單多少」的問題。AWS Cost Explorer（免費）能看過去幾個月的花費分布，按服務類型、帳號、tag 維度拆。接手時先拉一次 Cost Explorer 的月度趨勢，看有沒有異常成長或不預期的高額服務。後續導入 IaC 後，Infracost 可以在 terraform plan 階段預估變更的成本影響（例如「升 RDS 規格會多花多少」），讓成本決策在 apply 之前就被看見。

往 IaC 的銜接不需要一次做完。按穩定度和改動風險排序：

每批 import 的操作流程是：terraform import → terraform plan 確認零變更 → 寫 HCL 補齊差異 → 再跑 plan 直到零變更。具體的 import 步驟和工具選型在模組一：最小可行 IaC。

時程參考：10-20 個資源的環境，完成盤點 + credential 收斂 + 備份驗證約需 3-5 天；往 IaC 的 import 約需 1-2 週。兩者可以平行進行但建議先完成盤點 — 沒有完整的資源清單就開始 import，容易漏掉關鍵的依賴關係。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：如果盤點過程中發現環境裡已有部分 Terraform code
• → 模組負一：還沒有 infra 的環境：盤點完成後的操作紀律對齊
• → 模組零：infra 是什麼：成熟度階梯作為接手後現況評估的座標
• → 模組一：最小可行 IaC：盤點完成後的第一步 IaC 導入
• → 模組二：身分與憑證：credential 收斂的完整設計
• → 團隊權限分級與存取管理：接手後重新建立權限分級

服務定位

Secrets Manager 的定位是 AWS-only workload 的 static secret 控制面、跟 SSM Parameter Store SecureString 在 存 secret 這層功能重疊、但設計目的不同。Parameter Store 是 parameter 管理（free tier、advanced parameter 每 10000 個約 $0.05、KMS 加密但無 staging label 與 rotation Lambda）；Secrets Manager 是 secret 管理（每個 secret per month $0.40 + API call、有 staging label / rotation Lambda / Resource Policy / Cross-Region Replica）。價差 8 倍以上、選擇基準在 是否需要 rotation 跟 cross-account sharing。

跟 Vault 比、Secrets Manager 是 單一雲、簡單、低運維、Vault 是 跨雲、dynamic credential、高表達力。AWS-only 組織用 Vault 等於多扛一個 HA cluster 運維成本只為了拿 KV engine 跟 RDS rotation、ROI 不划算；反向跨雲組織用 Secrets Manager 等於每個雲都自己一套 secret store、治理鏈會斷。跟 Google Secret Manager / Azure Key Vault 比、設計理念類似（雲廠 managed、KMS 加密、IAM 授權）但 rotation 機制各家不同 — Secrets Manager 用 built-in Lambda 四階段 flow、GSM 用 Pub/Sub event 觸發自寫 Cloud Function、Azure 用 Key Vault rotation policy + Event Grid。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 用 Secrets Manager、哪些可以下放到 Parameter Store、哪些該走 Vault 的 dynamic credential
2. Secrets Manager 的 雙層 grant 模型（Resource Policy + IAM Policy）跟 KMS encryption key custody 怎麼配
3. Built-in rotation 跟 Custom Rotation Lambda 的設計邊界、staging label 在 zero-downtime rotation 內的角色
4. 何時 Secrets Manager 已經不夠用、要往 Vault / 跨雲 broker 走

最短判讀路徑

判斷一個 Secrets Manager 部署是否健康、最少看四件事：

• 誰能 GetSecretValue：IAM Policy 那邊是不是用 secretsmanager:GetSecretValue 限定到 特定 secret ARN（不是 *）、Resource Policy 是不是只允許特定 principal（不是 Principal: *）、跨帳號 share 有沒有用 ABAC tag 限縮
• KMS key custody：secret 用 AWS-managed key（aws/secretsmanager）還是 customer-managed key（CMK）— production 應該全部 CMK、key policy 限定 only Secrets Manager service principal 可用、KMS key 持有者跟 secret 持有者要分離
• Rotation 設定：rotation 開了沒、rotation interval 多久、Lambda 過去執行 success rate、staging label 在 rotation 過程中是否依序 promote（AWSPENDING → AWSCURRENT → AWSPREVIOUS）
• CloudTrail data event：GetSecretValue 是 Data event、預設不記、要手動開 data event logging — 沒開等於事故時看不到 誰拿了 secret、只看得到 management API（CreateSecret / UpdateSecret）

四件事任一缺失、就是 Secret Management 跟 Audit Log 邊界的待補項目。

日常操作與決策形狀

Resource Policy + IAM Policy 雙層 grant：Secrets Manager 跟 S3 bucket policy 同模型 — IAM Policy 控制 principal 端能做什麼、Resource Policy 控制 secret 端允許誰來、兩者要 都同意 才放行。常見錯配：Resource Policy 寫 Principal: "*" 加 aws:SourceAccount condition 想做跨帳號 share、但 condition 漏寫或寫錯就變成公開可讀。跨帳號 share 一定要明確列 Principal: arn:aws:iam::123456789012:role/AppRole、不要靠 wildcard + condition 拼隔離。

IAM Policy 細粒度授權：secretsmanager:GetSecretValue 該限定到 specific secret ARN（不是 *）、配合 ABAC tag condition（secretsmanager:ResourceTag/team = payments）限縮 blast radius。對應 CircleCI 2023 Secrets Rotation — CI 出事時要能依 tag 快速列出 CI runner 可拿的所有 secret、沒這套 tag 就只能盲目 rotate 全部。

KMS encryption key 選 CMK 不是 default：每個 secret 用一把 KMS key 加密、預設用 AWS-managed key aws/secretsmanager、production 應該換 customer-managed key（CMK）。差別在 key policy 是不是自己控 — AWS-managed key 的 policy 同 account 任何 service 可呼叫、CMK 的 key policy 可以鎖到 only Secrets Manager service principal 加 only specific role 可 Decrypt。對應 Storm-0558 的對照啟示：key 的 blast radius 來自 key policy、用 CMK 把 policy 寫窄是減 blast radius 的關鍵動作。

Built-in Rotation Lambda 只限 AWS native DB：Secrets Manager 內建 rotation template 涵蓋 RDS（PostgreSQL / MySQL / MariaDB / Oracle / SQL Server）/ Aurora / Redshift / DocumentDB — 拿 AWS 提供的 Lambda template、設定 rotation interval（最短 1 天、最長 365 天）、Secrets Manager 自動排程觸發。其他 DB（self-hosted PostgreSQL、MongoDB Atlas、Snowflake）或 API key 要寫 Custom Rotation Lambda、走 4-step state machine：createSecret（產新 credential 存為 AWSPENDING）、setSecret（把新 credential 寫到 target system）、testSecret（用新 credential 驗證可連）、finishSecret（promote AWSPENDING → AWSCURRENT）。Lambda 任一步失敗 Secrets Manager 會 rollback、舊 credential 不受影響。

Staging Label（AWSCURRENT / AWSPENDING / AWSPREVIOUS）：staging label 是 指向 version 的 pointer、app 一律用 GetSecretValue 不帶 VersionStage 拿 AWSCURRENT、rotation 過程中 Secrets Manager 先把新 credential 標 AWSPENDING、testSecret 過後 promote 到 AWSCURRENT、舊的降到 AWSPREVIOUS。設計初衷是 zero-downtime rotation — 但 只有 app 端支援 AWSPREVIOUS fallback 期間才有意義：rotation 完成瞬間有些 app instance 還拿著舊 credential，target system 應該同時接受 AWSCURRENT 跟 AWSPREVIOUS（DB rotation template 會在 setSecret 階段保留舊 user 一段時間）。對應 Failure: Credential Rotation Without Scope：scope map 沒做、AWSPREVIOUS 窗口期太短、長尾 batch job 拿到舊 credential 就掛。

Cross-Region Replica：multi-region app 把 secret replicate 到其他 region、replica 在 replica region 有獨立 ARN、KMS key 跟 rotation 都要在 replica region 各自配（不能跨 region 共用 KMS key）。replica 是 讀副本、寫只能在 primary region、rotation 觸發後新 version 自動 sync 到 replica（有秒級延遲）。failover 時 app 直接讀 replica region ARN、不需要 cross-region call。

Cross-Account Sharing：跨帳號 share secret 走 Resource Policy + 對方帳號 IAM Policy 雙向授權 — Resource Policy 列對方 account 的具體 role ARN、對方 role 的 IAM Policy 加 GetSecretValue 對應 ARN。KMS key 也要跨帳號授權（KMS key policy 加對方 role 的 Decrypt 權限）— 漏了 KMS 授權會出現 GetSecretValue 成功但 Decrypt 失敗 的詭異錯誤。

核心取捨表

選 Secrets Manager 的核心訴求：AWS-only + 大部分 secret 是 static 或 AWS native DB credential + 需要 cross-account share 或 rotation Lambda + 不想 / 沒量能自管 Vault。如果只是要存 config（feature flag、non-sensitive endpoint）、Parameter Store 8 倍便宜；如果跨雲 + 需要 dynamic credential / transit / PKI、Vault 才能滿足。

進階主題

Custom Rotation Lambda 設計：4-step state machine 是 idempotent contract — Lambda 必須能被 Secrets Manager 重試任意步驟而不破壞狀態。常見實作陷阱：createSecret 不檢查 AWSPENDING 是否已存在、重試時又產生一把新的、AWSPENDING 對不上 setSecret 寫進去的；setSecret 沒處理「target system 已經有同名 user」的情況、第二次跑會卡住。Template 提供的 PostgreSQL rotation Lambda 用 cloning approach — 在 DB 內 clone 一份 user、改密碼、保留舊 user 跨 rotation 一個週期、下次 rotation 才 drop。

Resource Policy + ABAC tag 跨帳號：跨帳號 share 時用 ABAC tag 條件比硬列 role ARN 有彈性 — Resource Policy 寫 Condition: aws:PrincipalTag/team = payments、對方 account 任何帶該 tag 的 role 都可讀。代價是 tag 治理 變成 critical control：對方 account 內誰能 attach tag = 誰能拿 secret、IAM Policy 要鎖 iam:TagRole 跟 iam:UntagRole 權限。

Rotation 失敗的監控訊號：Lambda 執行失敗會在 CloudWatch 留 invocation error、Secrets Manager 把 rotation 標記為 failed、但 secret 仍可用（AWSCURRENT 保留舊 version）— 容易出現 半年沒 rotate 成功但 app 看起來正常 的盲區。要監控 SecretsManager.RotationFailed event（EventBridge rule）+ LastRotatedDate metric 超過 rotation interval 1.5 倍就 alert。

跟 AWS IAM 整合：誰可以 GetSecretValue 完全由 IAM 控制、最佳實踐是 workload role 拿 secret（EC2 instance role / ECS task role / Lambda execution role / EKS IRSA）、不要硬把 AWS credential 塞進 secret 再給 application read。Secret 內容應該是 DB password / API token / third-party credential、不應該是 AWS credential（AWS credential 用 IAM role 短期 STS 拿就好）。

CloudTrail data event 的成本權衡：開 GetSecretValue data event 等於每次 secret 取用都進 CloudTrail、高 QPS application 一天可能跑數百萬筆、CloudTrail 成本（每 100k events 約 $0.10）跟 S3 儲存成本會明顯上升。降本作法：在 EventBridge 用 filtering（只送特定 sensitive secret 的 data event 到 SIEM）、CloudWatch Logs 端設 retention 短一點（7-30 天熱資料、長尾走 S3 + Athena）。

排錯與失敗快速判讀

• GetSecretValue AccessDenied 但 IAM Policy 看起來對：檢查 Resource Policy 是否限定 source account / VPC、檢查 KMS key policy 是否允許該 role Decrypt — 兩層 grant + KMS 三點任一缺都會 AccessDenied
• 跨帳號 secret 拿不到：Resource Policy 沒列對方 role、或 KMS key policy 沒給對方 Decrypt 權限 — 跨帳號要同步配三處（Resource Policy + 對方 IAM + KMS key policy）
• Rotation 一直失敗但沒人發現：沒設 EventBridge alert on RotationFailed、AWSCURRENT 保持舊 version、app 正常但 secret 過期 — 必設 LastRotatedDate metric alert
• App 拿到 stale secret rotation 後爆掉：app 端用了 SDK cache（如 AWS SDK 的 Secrets Manager Cache）、rotation 完成後 cache 沒 invalidate — cache TTL 要短於 staging label 重疊窗口、或實作 retry-on-auth-fail 觸發 cache refresh
• CloudTrail 看不到誰拿 secret：沒開 data event logging — 在 CloudTrail trail 設定加上 AWS::SecretsManager::Secret 為 data resource
• 跨 region replica rotation 失效：rotation Lambda 只在 primary region 配、replica region 沒對應 Lambda — 每個 region 各自配 Lambda、或乾脆只在 primary rotate 讓 replica 自動 sync
• AWSPREVIOUS fallback 沒生效 batch job 掛：rotation Lambda finishSecret 太快 drop 舊 user、batch job 拿到舊 credential 連 DB 失敗 — DB rotation template 預設保留舊 user 一個 rotation 週期、custom Lambda 要自己實作雙軌窗口

何時改走其他服務

不在本頁內的主題

• Secrets Manager 完整 API reference 跟 SDK 用法
• 每種 RDS engine 的 rotation Lambda template 內部 SQL 細節
• AWS pricing 詳細計算（每 region 略有差異）
• Terraform / CDK 跟 Secrets Manager 的 IaC 整合
• AWS account organization / SCP 怎麼限制 secret 建立

案例回寫

Secrets Manager 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：HashiCorp Vault、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS（Secrets Manager 加密 key custodian、CMK 與 key policy 治理）
• 下游：AWS IAM（誰可以 GetSecretValue、跨帳號 share 的 principal 來源）
• 跨模組：8 事故處理 vendor 清單（secret 外洩事件如何 routing 進 IR 流程）
• 官方：AWS Secrets Manager Documentation

服務定位

AWS WAF 的核心定位是 跟 AWS 服務深度耦合的 L7 防護層。Web ACL 直接掛 AWS resource、規則用 IAM policy 管理、log 進 Kinesis Firehose / CloudWatch Logs / S3、跟 AWS Shield Standard（內含、L3/L4 DDoS）自動整合。這跟 Cloudflare WAF 在 origin 之前的 edge 攔截不同 — AWS WAF 流量 已經進到 AWS 邊界、不是擋在外部。對 origin 跑在 ALB / CloudFront / API Gateway 後的客戶、AWS WAF 是天然選項；origin 在其他雲或地端、AWS WAF 觸不到。

跟 Fastly Next-Gen WAF 相比、AWS WAF 走 signature + managed rule group 偵測模型、不像 Fastly NG-WAF 走語意 / behavioral；AWS WAF 的 Managed Rule Group 來自 AWS Managed 與 AWS Marketplace 第三方（Fortinet、F5、Imperva 等）、客戶端 看不到 rule logic、debug 時要靠 sampled request 反推。

計費模型也是關鍵差異：AWS WAF 按 per-Web-ACL + per-rule + per-request 計費（單 ACL $5/月、單 rule $1/月、$0.60 per 1M request），Managed Rule Group 算多 rule、開太多套 ruleset 與流量大時帳單會明顯漲。Cloudflare 是 plan-tier 計費（Pro / Business / Enterprise）、不會因為多開 rule 線性漲價。

本章目標

讀完本頁、讀者能判斷：

1. AWS WAF 在 AWS-internal 防護 stack 中承擔哪一段、哪些要靠 AWS Shield / VPC / CloudFront 補位
2. Web ACL scope（Regional vs CloudFront）的選擇與跨 region 部署成本
3. Managed Rule Group / Custom Rule / Rate-based Rule 的取捨、Bot Control add-on 是否值得開
4. 何時用 AWS WAF、何時走 Cloudflare WAF / Fastly NG-WAF 的判準

最短判讀路徑

判斷 AWS WAF 配置是否健康、最少看四件事：

• Web ACL scope 對不對：CloudFront distribution 必須掛 CloudFront scope（強制在 us-east-1 建立 ACL）、ALB / API Gateway 必須掛 Regional scope（每個 region 各一份）；scope 配錯掛不上去、跨 region 部署是否用 IaC（Terraform / CloudFormation）同步複製 ACL
• Managed Rule Group 與 sensitivity：是否啟用 AWSManagedRulesCommonRuleSet（CRS）、AmazonIpReputationList（已知惡意 IP）、AnonymousIpList（VPN / proxy / Tor）、KnownBadInputsRuleSet（已知 exploit pattern）、Marketplace rule 是否在 Count mode 觀察 1-2 週 FP 再切 Block
• Logging 有沒有開：Web ACL log 預設關閉、必須手動配 Kinesis Firehose / CloudWatch Logs / S3 destination；event 是否進 SIEM（見 7.13 偵測覆蓋率與訊號治理）、是否能對 sampled request 反推 rule 行為
• IAM 邊界：誰能 update Web ACL（wafv2:UpdateWebACL、wafv2:UpdateRuleGroup）、是否限定 admin role 才能改、CI 是否只有 wafv2:Get* / List* 用來 verify、敏感變更是否走 Change Management / Audit Log

四件事任一缺失、就是 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Web ACL 與 scope：Web ACL 是 AWS WAF 的 規則容器、必須 attach 到 AWS resource。Scope 兩種：Regional（給 ALB / API Gateway / App Runner / AppSync / Cognito User Pool、每 region 獨立）與 CloudFront（給 CloudFront distribution、必須在 us-east-1 建立、全球生效）。同一個 ACL 不能跨 scope 共用；跨 region 部署同一套規則必須複製 ACL、用 Terraform / CloudFormation 管理避免 drift。

Rule action 五種：每個 rule 觸發時可以做 Block（直接 403）、Allow（跳過後續 rule、放行）、Count（不擋、只記錄、用於 dry-run 觀察 FP）、CAPTCHA（出題給人類解、bot 過不去）、Challenge（silent JS challenge、無感驗證）。新 rule 上線標準動作是先 Count 1-2 週看 sample、確認 FP 在容忍範圍才切 Block。CAPTCHA / Challenge 是 Bot Control add-on 配套、要額外計費。

Managed Rule Group（managed by AWS / Marketplace）：AWS Managed（免費含在 WAF）涵蓋 Common Rule Set（OWASP top10 對應）、Known Bad Inputs、SQL Database、Linux、Unix、Windows、Anonymous IP List、Amazon IP Reputation List、Account Takeover Prevention (ATP)、Account Creation Fraud Prevention (ACFP)。AWS Marketplace（付費）來自 Fortinet / F5 / Imperva / Cyber Security Cloud 等。Marketplace 規則 不公開 rule logic、攔錯時只能用 sampled request 反推、debug 比 AWS Managed 困難。

Custom Rule（statement + 條件）：Custom Rule 用 statement（match condition + transformation）組合：IP Set match、Geo match、Regex Pattern Set、Size constraint、SQL injection match、XSS match、String match（含 header / body / URI / query 各部位）。複雜條件用 AND / OR / NOT 組合、上限是每 Web ACL 5,000 Web ACL Capacity Units（WCU）— 規則越複雜 WCU 越高、Marketplace 大型 rule group 可能直接吃掉一半 budget。

IP Set / Regex Pattern Set：IP Set 存 IPv4 / IPv6 CIDR 清單、Regex Pattern Set 存正則表達式集合。兩者都是 獨立資源、可在多個 Web ACL 引用、單獨更新（不必動 Web ACL 結構）。實務上 threat intel feed 應該 push 到 IP Set、用 Lambda 自動 sync、不用手動加。

Rate-based Rule：限制 單一 aggregate key 在滾動 5 分鐘窗口內的請求數、超過 threshold 觸發 action。aggregate key 可選 IP、Forwarded-IP（看 X-Forwarded-For）、HTTP method、URI path、Header、Cookie 或組合。關鍵陷阱：CloudFront 後 origin ALB 必須用 Forwarded-IP、否則 Rate-based Rule 看到的全是 CloudFront 邊緣節點 IP、所有真實使用者被合併計算、要嘛全擋要嘛全放。

Logging 必須手動開：Web ACL log 預設關閉、destination 三選一：Kinesis Data Firehose（推到 S3 / Splunk / Datadog）、CloudWatch Logs（簡單但貴）、S3（直寫、需自己處理 partition）。production 通常走 Kinesis Firehose → S3 + Athena query、配合 SIEM 拉 alert。沒開 log 等於 攻擊發生時沒證據、事後無法回查。

跟 AWS Shield 整合：所有 AWS WAF 客戶自動含 Shield Standard（L3/L4 DDoS、免費、SYN flood / UDP reflection 等基礎防護）。Shield Advanced 是付費 add-on（$3,000/month per organization + per-resource fee + data transfer out fee）、提供 24/7 DRT（DDoS Response Team）、cost protection（DDoS 期間 AWS service scaling fee 補貼）、進階分析。一般客戶 Shield Standard 已足夠；金融 / 政府 / 高知名度品牌需要 Shield Advanced 的 DRT 與 cost protection。

Lambda@Edge / CloudFront Functions 補位：當 WAF rule statement 表達不出複雜業務邏輯（geofencing + business hour + user tier 組合、JWT claim 解析後判斷 routing）、用 Lambda@Edge（Node.js / Python、跑在 CloudFront 邊緣節點、4 個 phase：viewer-request / origin-request / origin-response / viewer-response）或 CloudFront Functions（純 JS、輕量、低延遲、只在 viewer-request / viewer-response）補位。Lambda@Edge 適合複雜邏輯、CloudFront Functions 適合 header rewrite / 簡單 routing；兩者都不能取代 WAF managed rule、但補位 WAF 表達力上限。

跟 AWS IAM 整合：誰能改 Web ACL 是 IAM policy 決定（wafv2:CreateWebACL、wafv2:UpdateWebACL、wafv2:AssociateWebACL、wafv2:UpdateRuleGroup 等 action）。production 標準配置：admin role 才能 update、CI / 開發者只有 wafv2:Get* / List* 用來 verify、敏感變更走 Change Management + CloudTrail audit log。

核心取捨表

選 AWS WAF 的核心訴求：AWS-internal app + origin 跑在 ALB / CloudFront / API Gateway / App Runner 後 + 想跟 IAM / CloudTrail / Shield 同套 control plane 治理。Origin 不在 AWS、或要 把攻擊擋在抵達雲之前、應該走 Cloudflare WAF 或 Fastly NG-WAF。

進階主題

AWS WAF Bot Control（add-on）：付費 add-on、用 AWS 自家 bot fingerprinting 區分 verified bot（搜尋引擎）/ signal: automated browser（headless Chrome 等）/ signal: known bot（已標記 IoT / scraper），給每個請求 bot category label。Custom Rule 在 label 上做條件、決定 Block / Challenge / CAPTCHA。比 user-agent 過濾準很多、但要額外計費（per-request）。Bot Control 有兩個 inspection level：common（便宜、基礎指紋）與 targeted（貴、含 JavaScript challenge、CAPTCHA、token-based）。

Fraud Control（ATP / ACFP）：Account Takeover Prevention（ATP）跟 Account Creation Fraud Prevention（ACFP）是 Managed Rule Group 的特殊類別、需付費啟用。ATP 看登入端點的 credential stuffing、ACFP 看註冊端點的 bot signup。兩者都用 AWS 自家 threat intel（被竊憑證 list、行為模型）打 label、客戶側用 Custom Rule 處理。對有 login / signup 端點的 SaaS / 電商有價值、純內部後台不必開。

CAPTCHA / Challenge：AWS WAF 內建 CAPTCHA puzzle 與 silent JS Challenge、可在 rule action 直接呼叫。Challenge 在客戶端執行 proof-of-work、合法瀏覽器無感、headless 工具卡住；CAPTCHA 是視覺題、人類解、bot 不會。Production 標準做法：Bot Control 給 label → Custom Rule 看 label → likely bot 走 Challenge、known bad 走 Block、人類流量直接 Allow。

ACM Private CA + WAF 對 mTLS：AWS WAF 本身不做 mTLS 驗證、mTLS 是 ALB / API Gateway / CloudFront 自己的功能（搭配 AWS ACM Private CA 簽發 client cert）。WAF 在 mTLS 完成後才看 L7 流量、可以用 HTTP header match（mTLS 後 ALB 注入 client cert 資訊到 header）做進一步 rule。Internal API 用 mTLS + WAF 是常見組合。

Lambda@Edge 補 inline business logic：複雜判斷（user tier × geo × business hour × A/B test）WAF rule statement 表達不出來、用 Lambda@Edge 在 viewer-request phase 解析 JWT、查 internal risk API、回 response header 給 WAF 後續判斷。代價：Lambda@Edge 部署只能在 us-east-1、code 更新傳播到全球 edge 要幾分鐘、debug 是分散式 CloudWatch Logs。

排錯與失敗快速判讀

• Web ACL 掛不上 CloudFront：scope 配成 Regional、CloudFront 拒絕 attach — Web ACL 必須在 us-east-1 + CloudFront scope 才能掛 CloudFront；ALB / API Gateway 反過來只能掛 Regional scope
• Rate-based Rule 全擋 / 全放：CloudFront 後 origin 看到全部都是 CloudFront IP、aggregate key 沒換 Forwarded-IP — 改用 Forwarded-IP（X-Forwarded-For）作 aggregate key，並設 Fallback behavior
• Managed Rule Group 誤殺合法請求：CRS High sensitivity 開後 file upload / rich text editor 端點被 Block — 找 sampled request 看 rule_id、用 Scope-down statement 限定該 rule 在某 path 不執行、或開該 rule 為 Count、不要關整個 group
• Marketplace Rule 攔不明流量：Marketplace rule logic 不公開、sampled request 看到 rule label 但不知為何 — 切該 rule 到 Count mode 觀察、若無 attack 跡象換 AWS Managed 同類 rule
• WCU 超限：Web ACL 上限 5,000 WCU、加 Marketplace + 多個 AWS Managed 就會爆 — 看 Capacity Used、移除重疊 rule、把 Custom Rule 表達式簡化（少用 transformation chain）
• Logging 沒設 / 設錯：事件發生後沒有完整 log 可查、只有 sampled request（保留 3 小時、機率抽樣） — 必開 Logging configuration 到 Kinesis Firehose / S3 / CloudWatch Logs、確認 IAM role 有 firehose:PutRecord 權限
• IAM 權限過寬：CI account 拿到 wafv2:* 整 zone 都能改 — 收斂到 wafv2:Get* / List* 唯讀、敏感寫入限 admin role + MFA + Change Management
• 跨 region 部署 drift：手動在 console 改 us-east-1 ACL、其他 region 沒同步 — 用 Terraform / CloudFormation IaC 管理、PR review、CI plan 檢查 drift
• Shield Standard 不夠擋大型 L7 DDoS：Standard 只防 L3/L4、L7 attack 靠 WAF Rate-based Rule + Bot Control — 若反覆遭遇大型 L7 DDoS、評估 Shield Advanced 的 DRT + cost protection 是否值得

何時改走其他服務

不在本頁內的主題

• AWS WAF Classic（v1）的遷移細節 — 本頁全以 WAFv2 為準
• 完整 WCU 計算規則與每個 statement 的 WCU cost reference
• Marketplace 第三方 rule group 各家功能矩陣
• AWS WAF 在 GovCloud / China region 的差異
• Bot Control / ATP / ACFP 完整 label schema reference

案例回寫

AWS WAF 在 07 案例庫無直接 vendor-level case、但多個 case 對應 WAF 作為 修補窗口期臨時控制 與 entry point 治理 的角色：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：AWS IAM（誰能改 Web ACL）、AWS ACM（mTLS client cert）、AWS Secrets Manager（rule update 用的 API key）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件如何 routing 進 IR）
• 官方：AWS WAF Documentation

事故摘要

AWS 在 2021-12-07 發生 us-east-1 多服務退化事件。官方資訊指出，內部網路裝置的異常行為導致這個區域的 API 請求與內部服務通訊壅塞，進而造成多個服務管理與控制面能力受影響。部分資料面能力可用，但控制面操作、狀態回報與恢復節奏出現延遲。

這類事故的難點在於，使用者看到的是「很多服務一起怪」，而工程上真正要先判斷的是：共同依賴是否先失真。

判讀訊號

事故路徑

1. 區域內部網路層出現異常與壅塞。
2. 控制面 API 與內部依賴通訊受阻。
3. 多服務管理能力與狀態回報受到影響。
4. 部分服務資料面仍可運作，但操作與恢復節奏失真。
5. 團隊逐步收斂網路壓力並恢復控制面可用性。

這條路徑顯示：真正的擴散點在 shared internal network + control plane，不是某個單一服務程式。

可回寫控制面

下一步路由

• 觀測證據包： 4.20 Observability Evidence Package
• 可觀測性 operating model： 4.18 Observability Operating Model
• 可靠性準備度： 6.19 Reliability Readiness Review
• 止血與回復： 8.3 Containment / Recovery Strategy
• 事故通訊： 8.4 Incident Communication
• 影響評估： 8.20 Customer Impact Assessment

引用源

• Summary of the AWS service event in the Northern Virginia (US-EAST-1) Region

問題場景

當控制面退化時，最容易出現三種混亂：第一，內部把多個症狀拆成獨立事件；第二，對外更新把控制面和資料面混在一起；第三，決策紀錄只留結論，沒有留下假設與回退條件。這三種混亂會直接拉長復原時間。

判讀訊號

事故治理路徑（樣式）

1. 啟動單一事件線，避免按產品拆散。
2. 明確標註控制面與資料面狀態，分開追蹤。
3. 固定對外 cadence（例如每 30 分鐘）更新「已知 / 未知 / 下一步」。
4. 在 decision log 記錄假設、證據、回退條件與 owner。
5. 收斂後把通訊節奏與責任邊界回寫 runbook 與 evidence package。

可回寫控制面

下一步路由

• 事故決策紀錄： 8.19 Incident Decision Log
• 客戶影響評估： 8.20 Customer Impact Assessment
• 事故通訊： 8.4 Incident Communication
• 觀測證據包： 4.20 Observability Evidence Package

引用源

• AWS Service Health Dashboard
• AWS post-event summaries

這是 infra 工作最常見的真實入口。比起從零自學建一套環境，「接到指派、拿到帳號、搞清楚狀況」才是多數工程師第一次碰 infra 的方式。

這篇用 AWS 為主要範例。GCP 和 Azure 的判讀邏輯相同（安全底線 → 現況盤點 → 路線分流），但具體服務名稱、IAM 模型和 Console 操作位置不同。

第一小時：安全底線

登入帳號後，在做任何其他事之前先完成這些。這些步驟的共同目的是確保帳號的存取控制處於安全狀態——雲端帳號被入侵的代價遠高於本機電腦被入侵，因為雲端資源可以在幾分鐘內被大量建立（產生帳單）或被刪除（資料遺失）。

確認 root 帳號的 MFA

Root 帳號是雲端環境的最高權限，能做任何事，包括關閉整個帳號。如果 root 帳號沒有 MFA（Multi-Factor Authentication，多因子驗證），任何拿到 root 密碼的人都能完全控制整個環境。

確認路徑（AWS）：Console 右上角帳號名稱 → Security credentials → Multi-factor authentication (MFA)。如果顯示「No MFA device」，立刻設定一個——手機 app（Google Authenticator / Authy）或硬體 key（YubiKey）都可以。

如果你拿到的帳號是公司用 AWS Organizations 開出來的子帳號，子帳號 root 的密碼和 MFA 是獨立的——管理帳號無法代設。子帳號 root 通常需要先用帳號 email 做密碼重置才能首次登入。確認 root MFA 後，日常操作用 IAM Identity Center 登入。

確認你的登入身分

你登入用的是哪種身分？這決定了你的權限範圍和操作方式。

IAM user：Console 右上角會顯示 username @ account-id。這是最傳統的登入方式——帳號管理員幫你建了一個使用者，給了你一組帳密。

IAM Identity Center（SSO）：你透過一個特別的登入頁面（通常是 https://d-xxxxxxxxxx.awsapps.com/start）登入，然後選擇帳號和角色。這是較新的做法，多帳號組織常用。

Root 帳號：Console 右上角顯示帳號 email 而非 username。如果你拿到的是 root 帳號的帳密，日常操作應該換成 IAM user 或 SSO 登入——root 帳號只在需要 root-only 操作（如設定 MFA、關閉帳號）時使用。建立 IAM user 的方式見模組一的動手前的前提段。

檢查既存的 access key

帳號如果被前人用過，可能有暴露風險的 access key——之前的管理員建了 IAM user、生了 key，但那組 key 可能已經寫在某個 Git repo 或環境變數裡而沒有停用。

確認路徑：Console → IAM → Users → 逐一點每個 user → Security credentials 分頁 → Access keys。檢查每組 key 的狀態（Active / Inactive）和建立時間。超過 90 天未 rotate 的 Active key 是風險——帳號接手後優先 rotate 或停用這些 key。如果帳號裡沒有任何 IAM user，這步跳過。

確認 CloudTrail 是否開啟

CloudTrail 記錄帳號內所有 API 操作（誰在什麼時間做了什麼）。AWS 預設會開啟 90 天的事件歷史，但長期保存需要建一個 Trail 把 log 寫到 S3。

確認路徑：Console 搜尋 CloudTrail → Dashboard。如果有 Trail 已建立，表示操作紀錄有長期保存。如果只有預設的 Event history，90 天前的紀錄會消失——這是一個需要但不緊急的改善點，模組六：可觀測性會展開。

現階段只需要確認 CloudTrail 存在，不需要馬上改它。

設定帳單警報

雲端帳單是開放式的——資源跑著就持續產生費用，被入侵後被開出大量資源更可能在幾小時內累積數千美元帳單。設一個帳單警報，超過閾值時收到通知。

設定路徑（AWS）：Console 搜尋 Billing → Budgets → Create budget → Cost budget。設一個月預算（如 $50 或 $100，依你的環境規模），超過 80% 和 100% 時發 email 通知。

帳號現況判讀：空帳號還是有東西？

安全底線做完後，下一步是搞清楚帳號的現況。這決定了你接下來走哪條路線。

怎麼判斷

EC2 Dashboard 只顯示當前 region 的資源。Console 右上角有 region 選擇器——先切幾個主要 region（us-east-1、ap-northeast-1、ap-southeast-1）看一下，確認資源是否分散在不同 region。

打開 EC2 Dashboard（Console 搜尋 EC2）。如果 Running instances 是 0、沒有 volumes、沒有 security groups（除了 default）——大概率是空帳號。也檢查 Lambda（Console 搜尋 Lambda → Functions）——如果有 function 在跑但 EC2 是空的，可能是 serverless 架構，帳號不是空的。

再看 S3（Console 搜尋 S3）。S3 是全域服務，不分 region。如果沒有 bucket，或只有 CloudTrail 的 log bucket——大概率是空帳號。

如果有正在跑的 EC2 instance、有 Lambda function、有 RDS 資料庫、有 S3 bucket 存著資料——這是一個有東西的帳號，可能是前人建的、可能是其他團隊在用的。

空帳號 → 從零建置

帳號是空的，你要從零開始建基礎設施。這是最乾淨的起點。

路線：先讀模組零建立心智模型（什麼是 infra、成熟度階梯），然後照模組一到五的順序走。模組一的動手前的前提段會帶你設好本機工具和認證。

有東西的帳號 → 接手維運

帳號裡已經有資源在跑。你需要先搞清楚「有什麼」「誰建的」「哪些還在用」，再決定怎麼處理。

路線：讀接手維運模組。它按環境類型（全手動的遺留環境、部分有 IaC、多帳號結構）分篇，教你怎麼盤點、怎麼在不搞壞的前提下逐步接管。

不確定 → 先盤點再說

如果帳號裡有東西但你不確定是不是還在用、能不能動，先盤點。以下指令需要 AWS CLI 並完成認證——安裝和 aws configure 設定見模組一的前提段（macOS 快速安裝：brew install awscli && aws configure）：

 1# 列出所有 region 的 EC2 instance
 2for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
 3  echo "=== $region ==="
 4  aws ec2 describe-instances --region "$region" \
 5    --query 'Reservations[].Instances[].[InstanceId,State.Name,Tags[?Key==`Name`].Value|[0]]' \
 6    --output table
 7done
 8
 9# 列出所有 S3 bucket
10aws s3 ls
11
12# 列出所有 RDS instance
13aws rds describe-db-instances \
14  --query 'DBInstances[].[DBInstanceIdentifier,Engine,DBInstanceStatus]' \
15  --output table

這些指令只做讀取，不會改變任何東西。如果輸出很多資源，去讀接手維運再決定下一步。如果幾乎是空的，走「從零建置」路線。

雲端 Console 的基本導覽

AWS Console 列出幾百個服務，日常 infra 工作常用的集中在以下幾個：

Console 左上角的搜尋列可以直接搜服務名稱，不用從選單找。

每個服務在 Console 上的操作都有一個對應的 AWS CLI 指令和 API 呼叫。這個對應關係是 IaC 的基礎——模組一會教怎麼把 Console 上的操作轉成程式碼。

你接下來該讀什麼

根據你的情境選一條路線：

如果你不確定自己屬於哪種情境，先做完本篇的「帳號現況判讀」再決定。

服務定位

IAM Identity Center 是 人類身份進 AWS 的 portal、不是 cloud resource permission engine。它跟 AWS IAM 的分工是兩層：Identity Center 管「人是誰、能登入哪些 account」、AWS IAM 管「進到 account 後對 resource 能做什麼」。實際機制是 Identity Center 透過 Permission Set 在每個目標 account 建一個 AWSReservedSSO_* 命名的 IAM role、使用者 assume 該 role 拿短期 STS token。

跟 Okta 相比、Identity Center 的核心優勢是 跟 AWS Organizations + Control Tower 原生整合、Permission Set 可以一次發佈到數百個 account、不必每個 account 各接 SAML。代價是 SaaS app integration 量級遠少於 Okta（Okta 7000+ 預建、Identity Center 僅中等規模）、跨雲 federation（GCP / Azure）也不在原生範圍。

許多大型組織採三層架構：Okta 是 HRIS 下游的 identity source of truth、SCIM push 進 Identity Center、Identity Center 再 map 到 AWS IAM Permission Set。Okta 管「人是誰」、Identity Center 管「AWS portal 入口」、AWS IAM 管「resource 能做什麼」。中小組織可以省略 Okta、直接用 Identity Center 內建 user store、但就失去跨 SaaS 統一 SSO。

本章目標

讀完本頁、讀者能判斷：

1. Identity Center 在 人類身份 / AWS portal / resource permission 三層裡的位置、何時該交回 AWS IAM 或上游 IdP
2. Identity Source 選擇（內建 / Active Directory / 外部 SAML）對 lifecycle 與 lock-in 的長期影響
3. Permission Set / Account Assignment / Access Portal 三個核心概念的稽核重點
4. 何時 Identity Center 夠用、何時要疊 Okta 在前、何時 Identity Center 反而是錯選擇

最短判讀路徑

判斷 Identity Center 配置是否健康、最少看四件事：

• 誰能 assume 哪個 role：Permission Set 跟 Account Assignment 是否走最小權限、AdministratorAccess 範圍 Permission Set 是否限定 break-glass、是否強制 phishing-resistant 認證 才能 assume 高權限
• Permission Set 邊界：每個 Permission Set 的 session duration（預設 1 hour、可調 12 hour）、inline policy vs Customer Managed Policy reference、是否用 ABAC tag 收斂跨 account 散佈
• External IdP federation 狀態：Identity Source 是內建 / AD / 外部 SAML、若走外部 IdP SCIM push 是否監控 sync 失敗、signing certificate 是否在 rotation 排程內
• CloudTrail 是否完整：Identity Center 事件分布在 management account 跟 member account、是否有 organization trail 收齊、admin 變更 / Permission Set 變更 / failed assume 是否 alert

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Identity Source 是根信任：Identity Center 支援三種 user/group 來源 — 內建 store、AWS Managed AD / on-prem AD via AD Connector、外部 SAML IdP（Okta / Entra ID 等、SCIM 推進來）。選了之後 user lifecycle 從哪來就鎖死、換 Identity Source 是大工程（要重建所有 Permission Set assignment、舊 user GUID 不通用）。早期決定錯比 Permission Set 設錯難救。

Permission Set 是 cross-account role template：定義一次、apply 到多 account、實際在每個 account 部署成一個 AWS-Reserved 命名的 IAM role。Permission Set 本身不是 role、是 role 的部署模板 — 改 Permission Set 會 push 到所有 account 上對應的 role。Customer Managed Policy reference 比 inline policy 好維護、但要先確保每個 target account 都有同名 policy、否則 assignment 會失敗。

Account Assignment：把 user/group 綁到 Permission Set + 特定 account 的三元組。這層用 group 而不是個別 user、跟著 Identity Source 的 group 變動自動同步。臨時權限（離職員工延長、incident 應變）走 access request workflow 或 IAM Access Analyzer + Just-in-Time、不要永久 assignment。

Access Portal URL 是 phishing 目標：custom URL（https://<alias>.awsapps.com/start）設定後變成員工每天用的入口、phishing 攻擊會 mimic。要強制 phishing-resistant MFA（WebAuthn / passkey）、純 push MFA 抗不過 fatigue。CLI 走 aws sso login 自帶 browser-based flow、不要叫員工複製貼 access key。

Application assignment：Identity Center 也能管 SAML app 的 SSO assignment、但 integration 數量遠少於 Okta。大量 SaaS app 的場景應該疊 Okta 在前、Identity Center 只管 AWS portal。

核心取捨表

選 Identity Center 的核心訴求：AWS 是主要工作環境、員工 SaaS app 用量低、要統一多帳號入口而不要再付 Okta 訂閱。員工大量用 SaaS 的場景應該疊 Okta 在前。

進階主題

External IdP federation（Okta / Entra ID SCIM 進來）：Identity Center 接外部 IdP 是 push model — IdP 主動 SCIM push、Identity Center 不 pull。push provisioning 失敗會 silent（IdP 端有 log、Identity Center 端只看到 user 沒出現）、要在 IdP 端設 sync failure alert。SAML signing certificate rotation 兩邊都要排程、過期會整個 federation 斷。

Multi-account Permission Set 設計：避免每個 environment / team 各自一份 Permission Set — 用 ABAC（tag-based access control）把「Environment=Prod + Team=Payments」的條件寫進一個 Permission Set 的 policy、tag 跟著 user attribute 跑。Permission Set 數量爆炸是 Identity Center 老化最常見訊號。

Customer Managed Policy reference：Permission Set 可以 reference target account 裡的 customer managed policy（同名同 path）、policy 本身在每個 account 獨立維護。比 inline policy 適合大規模、但要靠 CI / Terraform 確保 policy 在所有 target account 同步存在、否則 assignment 失敗。

Session duration 是攻擊面：預設 1 hour、可調到 12 hour。長 session 對 dev 體驗友善、但不利於 credential rotation — 高權限 Permission Set（AdministratorAccess、production write）應該短 session（1-2 hour）、低風險 read-only 可放 8-12 hour。

IAM Identity Center API 不該當 workforce IdP 用：API 是給 admin 管 assignment 用、不是給 app 拿 user token。要 workforce app SSO 走 SAML / OIDC federation、不要叫 app 打 Identity Center API 查 user。

排錯與失敗快速判讀

• Permission Set 數量爆炸：每個 team / environment 各一份、上百個 Permission Set 沒人敢動 — 改用 ABAC + user attribute 把條件寫進 policy、收斂到十位數
• Identity Source 選錯難換：早期選內建 store、後來公司導入 Okta 要換成外部 SAML — 整個 user GUID 重新映射、Permission Set assignment 重綁、評估比建新 tenant 還久
• External SCIM sync 失敗 silent：Okta 端 push 失敗、Identity Center 沒人 — 要在上游 IdP 設 SCIM provisioning failure alert、不要等使用者反映「我登不進去」
• Access Portal URL 被 phishing：custom URL 員工記憶、phishing 站 mimic、無 phishing-resistant MFA 擋不住 — 強制 WebAuthn / passkey、員工教育只認 bookmark / SSO launcher
• CloudTrail 不完整：只開 management account trail、member account 的 role assumption 看不到 — 開 organization trail 收齊、特別 alert Permission Set 變更與失敗 assume
• Break-glass 缺席：Identity Center 控制面故障時 console 進不去 — 保留每個 account 的 root credential（離線存）跟少數 break-glass IAM User（hardware MFA、與 Identity Center 獨立 audit）、季度驗證

何時改走其他服務

不在本頁內的主題

• AWS IAM 的 policy / role / STS 機制細節（屬 AWS IAM vendor 頁）
• Permission Set 的 JSON policy 撰寫教學
• AWS Organizations / Control Tower 的完整架構
• 各 SaaS app SAML 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor（外部 IdP 疊在前）、Auth0 vendor、Keycloak vendor
• 下游：AWS IAM vendor（Permission Set 落地的 resource permission 層）、Google Cloud IAM / Azure RBAC（多雲對照）
• 跨模組：8 事故處理 vendor 清單（Identity Center 事件如何 routing 進 IR 流程）
• 官方：AWS IAM Identity Center Documentation

服務定位

AWS KMS 的核心定位是 AWS-only 的 multi-tenant managed key management，FIPS 140-2 Level 3 認證、跨服務 envelope encryption 的共同地基。跟 CloudHSM 比、KMS 是 managed + shared HSM 池、CloudHSM 是 single-tenant dedicated HSM；需要更高隔離 / 自管 cluster / FIPS Level 3 single-tenant 時走 CloudHSM、或用 KMS Custom Key Store 把 KMS 後端指向自己的 CloudHSM。跟 Google Cloud KMS / Azure Key Vault 比、設計概念相近、但 KMS 把 secret store 切出去（Secrets Manager）、Key Vault 則把兩者合一。

跟 Vault transit engine 比、行為相似（key 不離 service、app 拿 ciphertext）、但治理面完全不同：KMS 綁 AWS 控制面、IAM + Key Policy 雙層授權、CloudTrail 是稽核入口；Vault transit 是跨雲統一介面、token + policy 為主、需要自管 cluster。AWS-heavy 組織首選 KMS、跨雲組織才會把 KMS 當下游、上游用 Vault transit 抽象。

本章目標

讀完本頁、讀者能判斷：

1. 哪些資料 / 場景該用 Customer Managed KMS Key、哪些 AWS Managed Key 已經夠用、什麼時候直接走 CloudHSM
2. Key Policy + IAM + Grant 三層授權的分工、production 必開的 CloudTrail Data event 與 monitor 範圍
3. Multi-Region Key、Custom Key Store、External Key Store、BYOK 等進階形態的取捨
4. KMS 出事（IAM 過寬、Key Policy 把自己鎖死、Schedule Deletion 誤觸發）時的判讀路徑跟回退選項

最短判讀路徑

判斷一個 AWS KMS deployment 是否健康、最少看四件事：

• Key Policy 設計：是否含 root principal（不然 key 變孤兒）、是否走 least privilege（不是 kms:* 給整個 account）、admin / user / monitor 三類 principal 是否分開、policy 變更是否走 PR review
• Grant 治理：哪些 service-to-service 短期授權走 Grant（rotation Lambda / RDS / EBS）、Grant TTL 是否設、廢棄 grant 是否定期 RetireGrant
• Multi-Region 與 rotation 策略：是否啟用 annual automatic rotation（適用 symmetric encryption key）、Multi-Region Key 的 replica 是否跟 DR plan 對齊、asymmetric / signing key 的 manual rotation 流程是否有 runbook
• CloudTrail Data Event 必開：management event 預設記、但 Encrypt / Decrypt / GenerateDataKey 是 data event、預設不記 — 沒這層 forensic 沒著力點、Storm-0558 對照下完全無法回答「誰用哪把 key 簽了什麼 token」

四件事任一缺失、就回到 7.6 秘密管理與機器憑證治理 跟 Audit Log 的補丁清單。

日常操作與決策形狀

Key Type 選擇：symmetric encryption key（AES-256-GCM、最常用、S3 / EBS / RDS / Secrets Manager 都走這個）；asymmetric key pair（RSA / ECC、用於 sign / verify 或 encrypt / decrypt、JWT 簽署、CodeSign、文件簽章）；HMAC key（generate / verify MAC、API request signing）。對應 Storm-0558 signing key chain — 自己 host signing key 出事的核心教訓是 key 不該離 HSM service、所以 JWT signing 用 asymmetric KMS key 是 baseline 設計、private key 永遠不離 KMS。

Key Origin（key material 來源）：AWS_KMS（KMS 內部生成、預設）；EXTERNAL（BYOK、組織自己生成 key material、import 進 KMS、可以隨時 reimport 或刪除）；AWS_CLOUDHSM（Custom Key Store、key material 存在自己的 CloudHSM cluster）；EXTERNAL_KEY_STORE（XKS、AWS 外的 HSM、控制面在 AWS、key material 在 on-prem）。多數場景用 AWS_KMS 就夠、合規 / 主權需求才走 EXTERNAL / Custom Key Store。

Key Policy 跟 IAM 的雙層：KMS 跟其他 AWS service 最大差異是 Key Policy 是主要授權機制、IAM policy 單獨不夠。Key Policy 必含 arn:aws:iam::ACCOUNT_ID:root 給 root principal（不是 root user、是讓 IAM 能參與授權的開關）— 沒這條 key 變孤兒、即使 IAM 開了 admin 也救不回來。production 通常分三類 statement：admin（Create / Delete / Schedule、走 break-glass）、user（Encrypt / Decrypt / GenerateDataKey、給 app）、monitor（Describe / List、給 SRE）。

Grant 是程式化短期授權：service-to-service 整合（Secrets Manager rotation Lambda、RDS 自動加密、EBS volume attach）通常走 Grant 而不是改 Key Policy — 每個 grant 有自己的 grant token、可以帶 TTL、可以 RetireGrant / RevokeGrant 收回、不跟 key policy 永久綁定。沒治理時 grant 累積上千個 / 沒人 retire 是常見問題、跟 Failure: Credential Rotation Without Scope 同類 — 沒 scope map 等於沒治理。

Alias 與 Key ID 的解耦：alias（alias/my-app-prod-key）是 指向 key 的可變指標、key ID / ARN 是 不可變識別。production code 應該用 alias、要換 key 時只需要重綁 alias、不用改 deployment。Cross-account 跨帳號使用必須用 ARN（alias 不跨帳號）。

Key Rotation 的真實語義：annual automatic rotation（symmetric encryption key 才支援）換的是 KMS 內部的 backing key material、key ARN / Alias / Key ID 都不變、app 完全不需要動。舊資料仍用舊 backing key 解密、KMS 自動處理、不是「資料全部重新加密」— 這是常見誤解。asymmetric / HMAC key 不支援 automatic rotation、必須 manual 建新 key + alias 切換 + app 端雙讀容忍窗口（跟 JWT signing key rotation 同套路）。

Multi-Region Key：跨 region replicate 的 KMS key 共用 key material 跟 Key ID（後綴帶 mrk-）、不是建立新 key — 跨 region 加密的 ciphertext 在另一 region 可以直接 decrypt、不用 cross-region API call。適合 multi-region active-active app + DR scenario。代價是 replica region 跟 primary region 的權限要分別治理、Key Policy 不會自動同步。

Encryption Context 是 authenticated data：encrypt 時帶的 key-value pair（例：{"app": "billing", "tenant": "acme"}）、decrypt 必須提供同一組 context — 否則失敗。用來防 ciphertext 被 replay 到別的 context（攻擊者拿到 billing 的 ciphertext 想當 payroll 的 ciphertext 用）、所有 context 都會進 CloudTrail、是 forensic 上的關鍵欄位。production 一律帶 context、單純加密不帶 context 等於少一層防護。

Customer Managed vs AWS Managed vs AWS Owned：三層分權 — Customer Managed（CMK、自己控 Key Policy + 自選 rotation）、AWS Managed（aws/secretsmanager、aws/s3、AWS 管 Key Policy、看得到但改不了）、AWS Owned（完全看不見、AWS 自己用、無 CloudTrail）。production 高敏感資料應該用 Customer Managed、才能控 policy + 開 data event + 自選 rotation 週期。

核心取捨表

KMS 是 AWS 上的 預設選擇、CloudHSM 是合規 / 自管要求才上的 昇級、Vault transit 是跨雲統一介面、Google / Azure 對標品在各自雲一樣是預設選擇。

進階主題

KMS Custom Key Store + CloudHSM 整合：Custom Key Store 把 KMS 的 控制面（API、Key Policy、CloudTrail、IAM 整合）保留、但 key material 存在自己的 CloudHSM cluster。組織需要 FIPS 140-2 Level 3 single-tenant 但又不想放棄 KMS 的 service 整合（S3 SSE-KMS / EBS encryption）時用。代價是 CloudHSM cluster 的運維成本（cluster HA、user 管理、backup）。

External Key Store (XKS)：更激進的形態 — key material 完全在 AWS 之外（on-prem HSM 或第三方 HSM）、AWS 透過 XKS proxy 呼叫外部 HSM 做 cryptographic operation。用於 資料主權 場景（金融 / 政府 / 跨境合規要求 key 不出組織邊界）、代價是 latency 跟 availability 完全綁外部 HSM、AWS service 整合面要算清楚。

Multi-Region Replica Key 跟 DR：primary region 出事時 replica region 仍能 decrypt 既有 ciphertext、不需要 cross-region API call。但 primary 跟 replica 是各自獨立的 Key Policy、變更不會自動同步 — 跟 Audit Log 治理一樣、replica region 也要納入 CloudTrail Data Event 覆蓋範圍。

BYOK（Bring Your Own Key）：Origin = EXTERNAL 的 KMS Key、key material 由組織自己生成、用 wrapping key 加密後 import 進 KMS。優點是組織保有 master copy（KMS 出事時仍能 re-import 到別處）、缺點是 automatic rotation 不支援（必須手動 import 新 key material）、且必須自己處理 wrapping key 的生命週期。

跟 Secrets Manager 的整合：Secrets Manager 的 secret 本身用 KMS key 加密（預設 AWS Managed aws/secretsmanager、production 應該指到 Customer Managed CMK）。rotation Lambda 透過 Grant 取得 Decrypt + Encrypt 能力、跟 Secrets Manager 一起構成 static secret rotation 的證據鏈 — 跟 credential rotation scoped evidence 對齊。

Asymmetric signing 的 use cases：JWT signing（KMS Sign API 直接簽 JWT header.payload、private key 不離 KMS、跟 Storm-0558 的設計對照鮮明）；CodeSign / S3 object signing（artifact integrity）；mTLS client cert 的 private key（搭配 cert-manager AWS issuer）。代價是 latency（每次 sign 一次 KMS API call、~10ms 級別、不適合超高 QPS）跟 cost（asymmetric operation 比 symmetric 貴 ~5x）。

排錯與失敗快速判讀

• Key Policy 沒有 root principal：Schedule 時忘了寫、key 立刻變孤兒、誰都不能用 — 只能透過 AWS Support 救（流程慢）；建立流程強制 template 含 root principal
• IAM admin 改不動 KMS key：Key Policy 沒授權 IAM 介入、即使 admin policy 有 kms:* 也擋掉 — 加 Enable IAM User Permissions statement 給 root principal、IAM 才能參與授權
• Schedule Key Deletion 誤觸發：min 7 天、max 30 天的等待期、期內可 cancel — production key 必含 alert（CloudWatch Alarm on ScheduleKeyDeletion event）+ 強制 4-eyes approval
• CloudTrail Data Event 沒開：事故後想查「誰 decrypt 了什麼」、發現只有 management event — production 必開 KMS data event、預估 cost（每 100k events ~$0.10）、敏感 key 一律開
• Encryption Context 不一致：encrypt 時帶 context、decrypt 時忘了帶（或帶錯）、InvalidCiphertextException — code review 強制 context schema、用 typed wrapper 避免人手帶錯
• Grant 累積 + 沒 retire：每個 KMS key 有 50,000 grant 上限、rotation Lambda 跑久了 grant 累積 — 定期 ListGrants + RetireGrant 廢棄的、IaC 治理 grant lifecycle
• Cross-region decrypt 失敗：以為 ciphertext 跨 region 通用、結果原本不是 Multi-Region Key — production 跨 region 場景一律建 Multi-Region Key、不要事後補
• CMK rotation 後舊 ciphertext 還能 decrypt：annual rotation 不會 re-encrypt 舊資料、KMS 自動用對應 backing key — 這是設計、不是 bug；真要全量 re-encrypt 要走 application-level migration

何時改走其他服務

不在本頁內的主題

• KMS 完整 API reference 跟 SDK 範例
• 各 AWS service（S3 SSE-KMS、EBS encryption、RDS encryption、DynamoDB encryption）的詳盡設定步驟
• 跟 AWS Organizations / SCPs 的 cross-account KMS sharing 完整治理流程
• CloudHSM cluster 的完整運維（高可用、user 管理、backup）— 看 CloudHSM
• 各種 cryptographic algorithm 的數學原理跟選型細節

案例回寫

KMS 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（KMS 為 TLS / signing key 的 root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：Google Cloud KMS、Azure Key Vault、CloudHSM
• 下游：AWS Secrets Manager（後端用 KMS）、cert-manager（可用 KMS asymmetric key 當 issuer）
• 對照：HashiCorp Vault（transit engine / 跨雲統一介面）
• 跨模組：8 事故處理 vendor 清單（KMS 事件如何 routing 進 IR 流程）
• 官方：AWS KMS Documentation

觀察

DraftKings 帳本系統的關鍵數字（引自 DraftKings case study）：

服務組合：Amazon Aurora MySQL-Compatible、Aurora Replicas（讀寫分流）、Aurora I/O-Optimized（2023-05 推出）、Aurora Database Cloning（測試環境）、跨三個 AZ 儲存複製。

關鍵負載形狀：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量、payout event 時是寫爆量、雙峰錯位。

判讀

DraftKings 的工程選擇揭露三個 OLTP 容量設計重點。

1. 200 個獨立資料庫 = sharding 預先做好：按業務切 200 個 cluster、用巨型 cluster 撐全部在這個規模行不通。對應 9.5 瓶頸定位流程 把「單機極限」改成「shard 極限」、每個 shard 的容量規劃變成獨立問題。
2. Replication lag 30 秒 → 10-30 ms：這個改善不只是「快」、而是讓 read-after-write 變得可預測。Aurora 的 storage layer 多 AZ 複製是這個 lag 改善的主因。對應 01 資料庫模組 的 replication lag 影響 transaction boundary 設計。
3. Super Bowl +50% 「no sweat」：這句話的工程意義是 提前做好容量規劃、不是「Aurora 神奇」。寫 workload 預期可能 + 50%、整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。對應 9.6 容量規劃模型 的 headroom budget 與 event-driven scheduled scaling。

需要警惕：100 萬 ops / 分鐘 = ~17K ops / 秒、跨 200 個 databases 平均下來每個 DB 約 80 ops / 秒。這不是「單一 DB 撐 100 萬 ops」、而是「200 shard 加總 100 萬」。讀案例時要看「峰值是分散到多少 shard」、不只看總數。

策略

可重用的工程做法：

1. 按業務切 OLTP cluster、不要一個 DB 撐全部：DraftKings 200 個 databases 顯示「業務切片」是 OLTP 擴容的前置。對應 01 資料庫模組 的 schema design 與 partition 決策。
2. 讀寫分流是 OLTP 容量規劃的基線：6ms 寫 vs <1ms 讀的差距、加上 read replica、是 OLTP 擴容最基本的兩個槓桿。
3. 事件型峰值預測寫進 baseline：Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。事件未知（突發新聞、KOL 推廣）的情況才需要 AI 預測（對照 9.C2 GR8 Tech）。

跨平台等效：GCP Cloud SQL + read replica / Spanner、Azure Database for PostgreSQL + read replica、自建 PostgreSQL + Patroni + pgbouncer 都可以實作對等架構。Aurora 的差異是 storage layer 對 replica 的 lag 改善。

下一步路由

• 想規劃 OLTP 高峰容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備 + 01 資料庫模組
• 想搞清楚事件型 vs 突發型峰值 → 9.C2 GR8 Tech 對照
• 想做 read replica 容量設計 → 01.6 高併發資料存取 + 9.5 瓶頸定位流程
• 想理解 replication lag 對 transaction boundary 的影響 → 01.5 transaction boundary
• 想理解 6 寫 / 4 讀 quorum 跟 200 cluster fleet 治理 → Aurora 儲存層架構
• 想規劃 read replica scaling 與 reader endpoint 路由 → Aurora read replica scaling

引用源

• DraftKings Scales Its Financial Ledger with Amazon Aurora
• Aurora I/O-Optimized announcement

服務定位

AWS IAM 是 cloud resource permission engine、人類 workforce 的 SSO 與 lifecycle 應該走 AWS IAM Identity Center 或外部 IdP（Okta / Keycloak）。Identity Center 把人類映射到 Permission Set、Permission Set 在每個目標帳號裡實際上是 AWS-Reserved IAM Role — 也就是說：人類登入走 Identity Center、實際的 API 授權判斷一定回到 IAM。兩層責任分清楚、policy 才不會錯放在「誰是誰」的地方。

AWS IAM 跟 Google Cloud IAM / Azure RBAC 在 policy model 上設計差異很大。AWS 的表達力最強 — identity-based policy、resource-based policy、Service Control Policy（SCP）、Permission Boundary、Session Policy 是五個獨立的層、最終結果由 Explicit Deny > Org SCP > Resource-based > Identity-based > Permission Boundary > Session Policy 的評估順序決定。表達力換來的代價是 最容易設定錯：S3 bucket policy 設錯 = public、KMS key policy 漏一個 condition = 跨帳號可以解密、Trust Policy 沒設 ExternalID = confused deputy 攻擊面。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 IAM first-class concept（User / Group / Role / Policy / STS）對應到自己的場景、哪些要避免（例如：給人類發 IAM User access key）
2. 跨帳號信任、CI / 第三方 SaaS 連進 AWS、service-to-service 認證該走 Role assumption / OIDC trust 還是 Roles Anywhere
3. SCP、Permission Boundary、resource-based policy 三層上限的疊加方式、何時用哪一層
4. CloudTrail + Access Analyzer 的稽核 baseline、出事時的最短取證路徑

最短判讀路徑

判斷一個 AWS 帳號的 IAM 配置是否健康、最少看四件事：

• 誰能 assume 哪個 Role：所有 Role 的 Trust Policy（誰能呼叫 sts:AssumeRole）、有沒有跨帳號 trust、跨帳號 trust 是否帶 ExternalID、有沒有 * 在 Principal 裡
• Resource-based policy 暴露面：S3 bucket policy、KMS key policy、Lambda function policy、SNS / SQS policy 是否有 Principal: * 或來自非預期帳號；用 IAM Access Analyzer 找 unintended external access
• Permission Boundary 與 SCP 是否生效：開發者建的 Role 是否 attach Permission Boundary（防止 admin 自己給自己升權）、Organization 是否 attach SCP 做整個 OU 的上限
• CloudTrail 是否完整、是否進 SIEM：management event 跟 data event 都開、跨 region、跨帳號、保留期符合稽核要求、特定事件（AssumeRole 失敗、root login、CreateAccessKey）接 alert runbook

四件事任一缺失、就是 Authorization 與 Audit Log 邊界的待補項目。

日常操作與決策形狀

Role 設計（cross-account / service / OIDC trust）：所有 持續性 的身份都應該是 Role、不是 IAM User。Service Role（給 EC2 / Lambda / ECS task）是 AWS 內部 service-to-service；Cross-account Role 給 partner 帳號或自家其他帳號用 sts:AssumeRole 進來；OIDC trust 是現代 CI 必備路徑（GitHub Actions / GitLab / 自管 K8s 用短期 OIDC token 換 AWS STS 短期憑證、不在 secret store 存 long-lived access key）。

Policy 種類分工：identity-based policy attach 在 User / Group / Role 上、回答「這個身份能做什麼」。Resource-based policy attach 在 resource 上（S3 bucket、KMS key、SNS topic、Lambda function）、回答「誰能對這個 resource 做什麼」— 同帳號內 identity-based 跟 resource-based 任一個 allow 就通過、跨帳號 兩邊都要 allow。SCP 是 Organization 層級的上限、不是 grant — SCP allow 不會給任何權限、SCP deny 會擋掉整個 OU 的所有 identity。Permission Boundary 是 user 角度的上限、給 admin 用來限制「我把 admin 權限委派給 developer 後、developer 自己建的 role 不能超過這條線」。

STS 與臨時憑證：所有 cross-account、service-to-service、人類 console federation 都應該走 STS — sts:AssumeRole（跨帳號 / 跨 role）、sts:AssumeRoleWithSAML（SAML IdP）、sts:AssumeRoleWithWebIdentity（OIDC）、sts:GetFederationToken（外部 broker）。Session 預設 1 小時、最長可設 12 小時（依 Role 設定）。Debug 起手式：aws sts get-caller-identity 確認當前 caller 是誰、是 User、Role 還是 federated session。

Access Key 治理：IAM User 的 long-lived access key 是 最後手段、用於 break-glass 或無法跑 IMDS / Roles Anywhere 的 legacy。所有 access key 走 Secret Management、定期 rotation、IAM Access Analyzer 的 unused access finding 找閒置 key。

CloudTrail / Access Analyzer baseline：CloudTrail organization trail 開到所有帳號、management event 必開、data event（S3 object level、Lambda invoke）依資料敏感度開。Access Analyzer 至少跑 external access（找 resource-based policy 把資源暴露給外部帳號）跟 unused access（找閒置 Role、user、permission）。

Trust Policy / ExternalID：第三方 SaaS（監控、CSPM、備份服務）要進你的 AWS 帳號時、其 Trust Policy 必須要求 ExternalID — 否則攻擊者只要知道 Role ARN 就能假冒第三方 SaaS 的呼叫端、走 confused deputy 攻擊面（AWS confused deputy 官方說明）。自家跨帳號 trust 不一定要 ExternalID、第三方一定要。

核心取捨表

AWS IAM 是 表達力最強、最容易設定錯 的雲端 IAM。Google Cloud IAM 設計較統一、policy model 易讀但精細度有限。Azure RBAC 走 inheritance + scope、靠 Management Group 結構治理。三家都不能直接互換、跨雲環境需要在每家自己的 IAM 模型裡建等價的 least-privilege baseline。

進階主題

Service Control Policy（SCP）：Organization 層級的上限、用來宣告「整個 OU 永遠不能做什麼」 — 例如禁止 root user 操作、禁止關閉 CloudTrail、禁止在非允許 region 建 resource。SCP 是 deny-list 防護網、不是日常授權；日常授權交給 identity-based policy。SCP 過嚴會擋住合法操作、過鬆等於沒設、設計時要對齊 organization 的安全政策骨幹。

Permission Boundary：用在 委派 admin 場景 — 公司想讓 platform team 自己建 IAM Role 給應用、但又不想讓他們建出 admin role。Admin 給 platform team 一個 Permission Boundary policy、platform team 建的所有 Role 都會被這個 boundary 限制 上限、就算 attach 了 AdministratorAccess 也只能在 boundary 範圍內生效。

ABAC（attribute-based / tag-based access control）：大規模 multi-account 環境、每個 service 一個 Role 會 Role 爆炸。ABAC 用 tag（principal tag、resource tag、request tag）做 policy condition — 例如「Role 上有 team=payments tag 的人能操作 team=payments tag 的 resource」。設計成立的前提是 tag 來源可信、不能讓使用者自己改 principal tag。

IAM Roles Anywhere：給 AWS 之外的 workload（地端 K8s、其他雲、邊緣設備）用 X.509 憑證換 STS 短期憑證。前提是有一個可信的 PKI（自管 CA 或公開 CA）跟 trust anchor。比起把 IAM User access key 放在地端 secret store、Roles Anywhere 是更安全的設計。

OIDC trust（GitHub Actions / GitLab CI / 第三方 CI）：CI / CD 連 AWS 的標準做法。在 AWS 建一個 OIDC identity provider 指向 CI 的 OIDC issuer、Role 的 Trust Policy condition 限制 repo:org/repo:ref:refs/heads/main、CI workflow 直接 aws sts assume-role-with-web-identity。完全不需要在 CI secret store 存 long-lived AWS access key、token TTL 隨 job 結束自動失效。

Resource-based policy 跨帳號設計：S3 bucket policy、KMS key policy、SNS / SQS / Lambda policy 都支援跨帳號授權。設計時兩件事必查：Principal 是否包含預期的帳號 / Role ARN、condition 是否限制來源（aws:SourceAccount、aws:SourceArn、aws:PrincipalOrgID）。漏了 condition、就可能讓任何拿到「假裝是某個 service」身份的人都能呼叫 — Capital One 2019 事件本質就是 SSRF 取得 EC2 IMDS 的 Role credential、再用該 Role 的權限去 S3 列舉跟讀取資料、揭示 resource-based policy + identity-based policy 沒有最小化、就會在事故時最大化。

排錯與失敗快速判讀

• AccessDenied 但 policy 看起來 allow：先用 IAM Policy Simulator 或 aws iam simulate-principal-policy 重算、確認是 SCP 擋、Permission Boundary 擋、resource-based policy 沒 allow、還是 condition key 不匹配。Explicit Deny 永遠贏。
• 跨帳號 sts:AssumeRole 失敗：兩邊都要設 — caller 帳號的 identity-based policy 要 allow sts:AssumeRole 到目標 Role ARN、目標 Role 的 Trust Policy 要 allow caller 的 Principal。漏其一就失敗。
• S3 bucket 不小心 public：用 Access Analyzer 的 external access finding 找、用 Block Public Access 帳號級別開關擋掉（即使 bucket policy 寫了 public、Block Public Access 也會擋）。常見根因：bucket policy 寫 Principal: * 沒加 condition、或 ACL 殘留歷史設定。
• Role / access key 殘留：用 Access Analyzer 的 unused access finding、或 IAM credential report 找超過 90 天沒用的 user / role、配 Failure: Credential Rotation Without Scope 的分域分批 rotation 流程清理
• 第三方 SaaS Role 缺 ExternalID：稽核第三方 vendor 的 onboarding 文件、若沒要求 ExternalID 是 vendor 自己安全模型有破口、自己這邊也要拒絕這種 onboarding
• CloudTrail 落地不全：Organization trail 沒覆蓋新建帳號、data event 沒開、log 沒進 SIEM、保留期不足 — 這四件事都會讓事故發生時拿不到證據

何時改走其他服務

不在本頁內的主題

• IAM policy JSON 語法完整 reference 與所有 condition key 清單
• 每個 AWS service 的細部 IAM 動作對照
• AWS Organization、Control Tower、Landing Zone 完整建置流程
• KMS / Secrets Manager / Certificate Manager 的內部細節（見對應 vendor 頁）

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：AWS IAM Identity Center、Google Cloud IAM、Azure RBAC
• 下游：7.6 秘密管理與機器憑證治理（AWS KMS vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（CloudTrail / Access Analyzer 訊號如何 routing 進 IR 流程）
• 官方：AWS IAM User Guide、AWS IAM Identity Center User Guide

觀察

Amazon Ads 在 DynamoDB 的關鍵數字（引自 DynamoDB customers）：

讀寫比約 18:1。這個比例反映「曝光發生 1 次、後續查詢可能發生 18 次」的廣告計費邏輯。

判讀

這個案例最重要的不是「DynamoDB 能撐多少」、而是「為什麼可以這樣設計」。

1. 單表分散到上千個 partition：DynamoDB 把每個 table 拆成多個 partition、每個 partition 內部還可以再分散。9000 萬 reads / 秒 是上千個 partition 加總的結果、單一節點達不到這個量級。對應 9.5 瓶頸定位流程 的 sharding 邊界、跟 01 資料庫模組 的 partition 設計。
2. partition key 選擇直接決定容量上限：DynamoDB 的容量是「每 partition 上限 × partition 數量」。partition key 不均勻會出現 hot partition、實際容量遠低於名義容量。對應 9.4 Saturation Discovery 的 saturation 不一定是整體 saturation、而是 最熱的 partition saturation。
3. 99.999% availability ≈ 5 分鐘 / 年的容錯：廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入。這個 SLO 不是行銷數字、是真實的營收邊界。對應 04.16 SLI / SLO 訊號 與 9.12 SLO 與 Performance Budget。

需要警惕：「9000 萬 reads / 秒」這種敘述通常是 年度峰值的最高一秒、不是平均值。容量規劃要區分「最大瞬時」、「99 百分位平均」、「常態流量」三個不同口徑。

策略

可重用的工程做法：

1. partition key 設計是 KV 容量的第一決策：均勻分散、避免 hot partition、必要時加 random suffix 強制分散。對應 01 資料庫模組 的 schema design 章節。
2. read-heavy 跟 write-heavy 比例變化是容量警訊：當業務邏輯改變（例如新增即時報表）、讀寫比可能跳一個量級、原本的容量規劃會失效。對應 9.8 效能可觀測性 持續監控比例變化。
3. on-demand vs provisioned 是成本 vs 反應速度的取捨：on-demand 自動擴容但成本高、provisioned 便宜但需要預測。Amazon Ads 這種 sustained workload 通常用 provisioned + auto scaling、不用 on-demand。對應 9.7 成本邊界與 efficiency。

跨平台等效：GCP Cloud Bigtable + 良好 row key 設計、Azure Cosmos DB partition key 設計都是對等概念。差異是 DynamoDB 的 partition 透明度（你看不到 partition 數量）vs Bigtable 的明確 tablet 模型。

下一步路由

• 想規劃 KV 高吞吐架構 → 9.5 瓶頸定位流程 + 01 資料庫模組
• 想避免 hot partition → 01.6 高併發資料存取 + 9.4 Saturation Discovery
• 想對照其他 KV 案例 → 9.C11 Minecraft Earth Cosmos DB（Azure 全球分散）
• 想深入 DynamoDB hot partition 反模式 → DynamoDB partition key 反模式
• 想拆 access pattern 對應的 single-table design → DynamoDB single-table design
• 想評估 on-demand vs provisioned 切換時機 → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• Handle traffic spikes with Amazon DynamoDB provisioned capacity
• Demystifying Amazon DynamoDB on-demand capacity mode

觀察

Tinder 在 ElastiCache for Valkey 的關鍵數字（引自 ElastiCache customers）：

ElastiCache for Redis 7.1 在 r7g.4xlarge 上可達單節點 100 萬 RPS、單 cluster 5 億 RPS（引自 AWS Database Blog）。

判讀

Tinder 案例值得讀的是「快取在 long-running 服務的角色變化」。

1. 快取不是 DB 的補救、是主要服務面：配對引擎每次互動讀 cache 不讀 DB、cache miss 是 邊緣案例。對應 02 快取模組 的 cache-as-source-of-truth 與 02.4 cache copy freshness boundary 設計。
2. 次毫秒延遲是業務 KPI、不只是技術指標：手指滑動之後 250ms 內必須給結果、否則「卡頓」。中間整個 chain（網路、cache、序列化）的 latency budget 必須緊。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。
3. 長期 sustained growth 的容量曲線是成本曲線：47M MAU 沒有明顯峰谷、容量規劃變成「每月線性擴容 X%」的長期決策、不是峰值規劃。對應 9.7 成本邊界與 efficiency 的長期成本工程。

需要警惕：Tinder 的「configurable matching」業務邏輯複雜、快取資料的 schema 變化頻繁。一個 schema 變更可能讓既有 cache 全部 invalid、引發 cache stampede。對應 02.6 cache migration stampede rollback。

策略

可重用的工程做法：

1. cache layer 容量規劃跟 DB 容量規劃要分開：cache 容量受 working set size 影響、DB 容量受 total dataset 影響、兩者擴容邏輯不一樣。對應 02 快取模組 的 cache sizing。
2. cache 命中率變化是業務變化的訊號：突然命中率掉、可能是新功能影響 access pattern、不一定是 cache 容量問題。對應 9.8 效能可觀測性 的訊號治理。
3. Valkey vs Redis OSS vs MemoryDB 是不同 trade-off：Valkey（社群分支、AWS 主推）、Redis OSS（受授權變化影響）、MemoryDB（持久化）三者選擇影響長期 vendor lock-in。

跨平台等效：GCP Memorystore for Redis / Valkey、Azure Cache for Redis、自建 Redis Cluster + Sentinel 都可以實作對等架構。差異是 vendor 的 patch cadence 與容量擴張流程。

下一步路由

• 想設計 cache layer 容量 → 02 快取模組 + 9.5 瓶頸定位流程
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 9.1 壓測理論與系統行為
• 想理解 cache stampede 風險 → 02.6 cache migration stampede rollback
• 對照其他 cache 案例 → 9.C5 Amazon Ads DynamoDB（KV 高吞吐）

引用源

• Amazon ElastiCache Customers
• Achieve over 500 million requests per second per cluster with ElastiCache for Redis 7.1
• Optimize Redis Client Performance for ElastiCache and MemoryDB

服務定位

CloudHSM 的核心定位是 把 cryptographic root of trust 放回客戶手上 — 適合金融、政府、醫療這類有資料主權、FIPS 140-2 Level 3、PCI HSM、HIPAA 合規壓力的場景。跟 AWS KMS 比、KMS 也滿足 FIPS 140-2 Level 3、但 HSM cluster 是 AWS 多租戶共用、key material 由 AWS-controlled HSM 持有、控制面 API 也是 AWS。CloudHSM 把 HSM cluster 物理隔離給單一客戶、PKCS#11 / JCE / OpenSSL Dynamic Engine 直接打 HSM、AWS 在資料平面 沒有讀 key 的能力。

跟 自管 on-prem HSM（SafeNet / Thales 自架）比、CloudHSM 把硬體採購、機房、network、firmware patch 交還 AWS、客戶只管 key custody 跟 Crypto User policy；代價是不能完全脫離 AWS region。跟 Vault auto-unseal 整合場景中、CloudHSM 是 Vault master key 的 root custodian — Vault unseal key 用 CloudHSM 加密、CloudHSM 出事整個 Vault cluster 沒法 unseal、所以可用性設計（cross-AZ cluster、cross-region backup）很關鍵。多數一般 web app / SaaS 用 KMS 即可、不需要 CloudHSM 的物理隔離。

本章目標

讀完本頁、讀者能判斷：

1. 何時需要 CloudHSM 的 dedicated 模型、何時 AWS KMS 已足夠
2. CloudHSM cluster 的最低安全 / 可用性需求（cross-AZ、Crypto Officer 分離、Quorum、backup）
3. Crypto User credential 出事的降級路徑（AWS 不能幫忙、靠 backup + Quorum）
4. 跟 KMS Custom Key Store / Vault auto-unseal 整合的取捨

最短判讀路徑

判斷 CloudHSM deployment 是否健康、最少看四件事：

• Cluster 拓樸：production cluster 是否至少 2 個 HSM instance 跨 AZ、cluster 內自動 replicate、單一 AZ 故障時 key 是否仍可用
• Crypto User 管理：Crypto Officer（CO）跟 Crypto User（CU）是否分離、CO password 是否走 break-glass 保管、CU credential 是否走 short-lived 取得 + audit
• Quorum-based policy：高敏 operation（建 CU、改 policy、key export wrapped）是否設 M-of-N approval、避免單一 admin compromise 後 silent abuse
• Backup 治理：automatic 24h backup 跟 manual backup 是否都開、cross-region backup 是否走 explicit copy、restore 流程是否定期演練

四件事任一缺失、就是 CloudHSM deployment 待補項目 — 跟 secret management 的 evidence 邊界同類。

日常操作與決策形狀

Cluster + HSM Instance 拓樸：CloudHSM 的部署單位是 cluster、cluster 內可以有 1-N 個 HSM instance。production 場景至少 2 個 HSM instance 跨 AZ、cluster 自動把 key material replicate 在所有 instance 上、單一 AZ 失效不影響 cryptographic operation。跨 region 不自動 replicate — 跨 region DR 要靠 backup copy。

Crypto Officer (CO) vs Crypto User (CU)：CO 是 cluster 管理員、能建 / 刪 CU、設 policy、做 backup；CU 是真的做 cryptographic operation 的 identity（encrypt / decrypt / sign / verify）。production 必須分離 — CO credential 走 break-glass 保管、CU credential 給 application 使用、application compromise 只影響 CU 邊界、不能改 CO policy。

Quorum-based policy（M-of-N approval）：CloudHSM 支援把高敏操作（建 CU、改 policy、key export wrapped）綁定 M-of-N CO approval。例如 3-of-5 quorum、單一 CO 即使 credential 外洩也不能單獨建後門 CU、必須拿到另外 2 個 CO 的 signed token。對應 Storm-0558 signing key chain 啟示：高價值 key custodian 的 admin operation 不該是 單人單 token、必須有第二人簽核才能改變信任根。

Backup 治理：CloudHSM 每 24 小時自動 backup 整個 cluster state（含 key material）、backup 是 AWS-managed encrypted blob、AWS 自己也不能解密、restore 必須在 CloudHSM cluster context 內進行。可手動 backup、可 copy 到其他 region 做 DR。Backup retention 預設 90 天、可延長。Backup 不是 export — 不能把 key material 從 HSM 拿出來看 plaintext。

Key Replication 跨 region：CloudHSM cluster 綁定單一 AWS region、跨 region 走 backup → copy → restore 流程、不是 active replication。設計 DR 時要算 RTO：restore 一個 cluster 從 backup 大約小時級、不適合 hot failover、應該 primary region 跑、DR region 備好空 cluster + backup copy。

PKCS#11 / JCE / OpenSSL Dynamic Engine 整合：application 不用 AWS SDK 講 CloudHSM、而是透過 標準 cryptographic API library（PKCS#11 for C/C++、JCE Provider for Java、OpenSSL Dynamic Engine 走 TLS termination）。好處是 application code 用業界標準介面、未來換 HSM 廠也只需要換 library。代價是 client SDK 要裝在 application host、CU credential 要 deploy 到 host、host security baseline 變成 cryptographic boundary 的一部分。

跟 KMS Custom Key Store 整合：KMS Custom Key Store 把 KMS Key 的 backing material 放在 CloudHSM、API 仍透過 KMS（kms:Encrypt / kms:Decrypt）、application code 不需要改。這是 KMS 易用 + HSM dedicated 雙重：保留 KMS 的 IAM policy / key rotation / audit log（CloudTrail）、又得到 single-tenant HSM 的合規屬性。代價是 CloudHSM 失效時、Custom Key Store backing 的 KMS Key 全部不可用、需要監控 cluster health。

核心取捨表

選 CloudHSM 的核心訴求：合規明文要求 dedicated HSM（PCI HSM、某些國家資料主權法規）、或 trust model 上不接受 AWS 持 key。多數 AWS-heavy workload 用 KMS 即可、加 CloudHSM 反而引入 Crypto User credential 的單點失誤（丟了 = key 永久遺失）。需要 KMS API 但又要 dedicated HSM、走 Custom Key Store 是折衷路徑。

進階主題

Quorum Auth 設計：production 把 Quorum threshold 設為 3-of-5 或 2-of-3、五位 CO 由不同部門 / 不同地理位置持有、避免單一辦公室 / 單一網路同時被攻陷。Quorum token 有 TTL、單次 operation 用完就失效、防止 replay。建議 quarterly 演練：模擬一個 CO 不在、用剩餘 quorum 完成 emergency operation、驗證流程在事故時跑得通。

KMS Custom Key Store 整合決策：用 Custom Key Store 的關鍵問題是 availability blast radius — KMS Key 出事影響範圍是 使用該 Key 的 AWS service（S3、EBS、RDS encryption）、Custom Key Store backing 失效會讓這些 service 同步斷。設計時做 分層 key strategy：mass volume 的 S3 / EBS 用 AWS-managed KMS Key、高合規敏感的 database / secret 才用 Custom Key Store backing 的 KMS Key、降低單一 cluster 失效的影響面。

Cross-Region Backup：DR 要把 backup copy 到第二個 region、走 CopyBackupToRegion API、restore 時建空 cluster + 套 backup。整個 RTO 通常數小時、不適合熱備、設計上是 容忍小時級 outage 換到 BCDR 環境、不是 秒級 failover。對應 Azure AD Identity Control Plane 2021 對照啟示：身份 / 加密控制面的單點 outage 影響整個 platform、availability 的 topology 設計跟 confidentiality 同等重要。

跟 Vault auto-unseal 整合：Vault auto-unseal 可用 CloudHSM 作 master key custodian、走 PKCS#11 plugin、Vault unseal 時呼叫 CloudHSM Unwrap master key。比起 AWS KMS auto-unseal 多一層 dedicated HSM 保證、適合監管特別嚴的場景。代價是 CloudHSM cluster 失效 → Vault 不能 unseal → 下游所有 secret 拿不到、要設計 break-glass 流程。

合規憑證：CloudHSM 同時持有 FIPS 140-2 Level 3、PCI HSM、Common Criteria EAL4+ 多個認證、可作金融 PIN block 處理、payment 業者的 HSM 上鏈、政府機敏資料加密的 直接合規承諾、不需要客戶端再做 HSM 認證 audit。

排錯與失敗快速判讀

• Crypto User credential 丟失：CU password 全公司只有一份、保管人離職 → AWS 不能 reset、key material 永久不可用 — CU credential 要走 password manager + 多人持有、CO 有能力 revoke 舊 CU 建新 CU
• Cluster 只有單一 HSM instance：成本省了、單一 instance 故障 cluster 整個失效 — production 強制至少 2 個 instance、跨 AZ
• Backup 沒測過 restore：每天 automatic backup 跑、從未 restore 演練、DR 真要用時發現流程不通 — quarterly 演練 restore 到測試 cluster、驗證 key material 可用
• Custom Key Store 沒監控 CloudHSM health：CloudHSM cluster degraded 時、KMS Custom Key Store 跟著失效、application 看到 KMS 5xx — CloudWatch metric 監 HsmsActive / HsmTemperature、cluster health degrade 立即 alert
• PKCS#11 library 版本漂移：application host 的 client SDK 版本跟 cluster firmware 不相容、cryptographic operation 失敗 — version compatibility matrix 進 deployment pipeline、firmware upgrade 前先測 staging
• Quorum CO 全部同地點：5 個 CO 全在同一個辦公室、辦公室斷網 = quorum 不能組 — CO 跨 region / 跨組織分散
• Audit log 沒接 SIEM：CloudHSM activity 透過 CloudTrail + cluster audit log、沒接 SIEM 就無 forensic — CloudTrail 跟 cluster audit 都 push 到 SIEM（見 7.13 偵測覆蓋率與訊號治理）

何時改走其他服務

不在本頁內的主題

• CloudHSM 完整 PKCS#11 / JCE API reference
• CloudHSM Classic（舊版、已 EOL）的差異
• 每種合規法規（PCI HSM、HIPAA、FedRAMP）的逐條對應
• CloudHSM CLI 跟 cloudhsm_mgmt_util 詳細指令
• 應用層使用 HSM-bound key 做 TLS termination 的 nginx / Apache 配置細節

案例回寫

CloudHSM 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（HSM 為 CA / signing key 的 FIPS-grade root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：AWS KMS、Google Cloud KMS、Azure Key Vault
• 整合：HashiCorp Vault（CloudHSM 作為 Vault auto-unseal master key custodian）
• 整合：KMS Custom Key Store（KMS API + CloudHSM backing 雙重）
• 跨模組：8 事故處理 vendor 清單（HSM 失效如何 routing 進 IR 流程）
• 官方：AWS CloudHSM Documentation

觀察

Lyft 在 AWS 的關鍵數字（引自 Lyft case study）：

服務組合：Amazon DynamoDB（搭乘追蹤、GPS 座標）、Amazon Redshift（客戶洞察）、Amazon Kinesis（即時事件串流）、AWS Auto Scaling、Amazon EC2 Container Registry。

判讀

Lyft 的工程做法揭露三個微服務容量治理重點。

1. 微服務不是「全部 8x」、是「特定服務 8x」：8x 是 某些核心服務 在週末爆量時刻的擴容比、不是 100 個服務全部 8x。對應 9.5 瓶頸定位流程 必須先做「哪個服務是熱點」的層次定位。
2. 微服務粒度 = 擴容粒度：把 ride matching、payment、driver tracking、notification 切成獨立服務、每個服務的 autoscaling policy 可以獨立設計。對應 03 訊息佇列模組 跟 05 部署平台模組 的服務邊界。
3. GPS 座標寫入 DynamoDB 是高頻 sustained workload：每個 driver 每秒寫 1-2 次位置、200+ 城市 × 每個城市數萬司機 = 巨量持續寫入、跟峰值無關。對應 9.C5 Amazon Ads 的 KV 高吞吐設計同類。

需要警惕：「8x 峰值」是 峰值倍數、不是 尖峰持續時間。週末晚間的尖峰可能持續 3-4 小時、機場特殊事件可能持續 30 分鐘、演唱會結束可能只有 10 分鐘瞬間。容量策略要按持續時間區分。

策略

可重用的工程做法：

1. 微服務粒度切到「同性質擴容單位」：同步 vs async、stateful vs stateless、CPU-bound vs I/O-bound 不該混在同一服務、否則擴容邏輯互相衝突。對應 05 部署平台模組 的 service decomposition。
2. 預測式 + 反應式擴容混用：可預測（早晚通勤）用 scheduled scaling、不可預測（演唱會散場）用 reactive autoscaling、兩者組合。
3. GPS 類持續寫入適合 KV / time-series store：不適合放 OLTP DB、會佔用 transaction 資源。對應 01 資料庫模組 的 storage choice。

跨平台等效：GCP GKE + HPA / VPA / Karpenter、Azure AKS + KEDA、自建 Kubernetes + Cluster Autoscaler 都可以實作對等架構。

下一步路由

• 想做微服務容量治理 → 05 部署平台模組 + 9.6 容量規劃模型
• 想規劃事件型峰值 → 9.11 高峰事件準備 + 9.C2 GR8 Tech
• 想設計高頻 sustained workload → 01 資料庫模組 + 9.C5 Amazon Ads

引用源

• Lyft Case Study
• DynamoDB Customers

服務定位

ACM 的核心定位是 AWS 平台內 cert 的全託管 lifecycle。客戶不持私鑰、不跑 ACME client、不手動 renew — 但代價是 ACM public cert 只能 attach 到 AWS-managed service（ELB / CloudFront / API Gateway / App Runner / Nitro Enclaves）、不能 export 給自管 Nginx / EC2 應用。Private cert 必須有 ACM Private CA (PCA) 後端、ACM 自己不是 CA。

跟其他 cert 工具的場景重疊度低、定位是分工互補：cert-manager 走 cluster 內 K8s workload cert（Ingress / service mesh）、Let’s Encrypt 走跨平台公共 ACME cert（可 export 任何地方使用）、ACM Private CA 走自管 CA hierarchy（root + intermediate、客戶控制 policy）。常見組合：AWS-native endpoint 用 ACM、K8s workload + 自管伺服器走 cert-manager + Let’s Encrypt、內部 mTLS root 走 PCA。詳細差異見「核心取捨表」。

本章目標

讀完本頁、讀者能判斷：

1. ACM public cert vs private cert vs imported cert 各自的使用邊界（能 attach 哪些 service、能不能 export）
2. DNS validation vs Email validation 的差異、跟 auto-renewal 條件的關聯
3. 跨 region 跟 CloudFront 的 us-east-1 限制如何處理
4. 何時 ACM 不夠用、要改走 cert-manager / Let’s Encrypt / ACM Private CA

最短判讀路徑

判斷 ACM cert 部署是否健康、最少看四件事：

• Cert 跟 service 整合：cert ARN 是否真的 attach 到 ELB / CloudFront / API Gateway listener、DescribeCertificate 的 InUseBy 有沒有資源、有 cert 但沒 attach 等於 issue 失敗
• DNS validation 設定：cert 是 DNS 還是 Email validation、DNS 的 CNAME record 是否還留在 DNS（auto-renewal 需要這條 record 持續存在）、Route53 vs 外部 DNS 的責任分界
• Renewal status：DescribeCertificate 的 RenewalSummary.RenewalStatus 是 SUCCESS / PENDING_AUTO_RENEWAL / FAILED、失敗時 RenewalStatusReason 是什麼（多半是 DNS record 被刪、CNAME 不再回應）
• CloudTrail 證據：RequestCertificate / ImportCertificate / DeleteCertificate 的 caller identity、是否有非預期的 cert 建立或刪除（防誤刪 / 惡意刪）

四件事任一缺失、就是 Transport Trust and Certificate Lifecycle 的覆蓋缺口。

日常操作與決策形狀

Request public cert：對 internet-facing endpoint（網站、API）issue public cert、走 RequestCertificate API、選 DNS validation。ACM 給一組 CNAME record、放進 DNS（Route53 可一鍵 create）、ACM 自動驗證 + issue。Cert 生效後 attach 到 ELB / CloudFront / API Gateway listener。Issuer 是 Amazon Trust Services、所有主流瀏覽器 / OS trust store 都認。

Request private cert（需 PCA 後端）：內部 service mTLS root、走 RequestCertificate 但指定 PCA ARN。ACM 透過 PCA 簽 cert、cert chain 是組織內部 CA hierarchy。Trust store 必須在各 workload 手動建立（不像 public cert 自動 trust）。

DNS validation vs Email validation：DNS validation 是預設 + 推薦 — CNAME record 放進 DNS 後、ACM 持續驗證 domain ownership、auto-renewal 全自動。Email validation 是 legacy、ACM 寄信到 domain 的 WHOIS / 預設 admin email、人工點連結驗證；auto-renewal 不會自動完成、cert 到期前必須手動 re-validate。Production 一律用 DNS validation。

Auto-renewal 條件：ACM 在 cert lifetime 60 天前嘗試 renew、條件嚴格：(1) cert 是 ACM-issued（不是 imported）(2) DNS validation 走 CNAME record 仍存在且可回應 (3) cert 至少 attach 到一個 AWS service。三個條件任一不滿足、renewal 不自動觸發、cert 會 expire。Imported cert 完全不自動 renew、必須在 expiry 前手動 re-import。

跟 ELB / CloudFront / API Gateway 整合：ELB / API Gateway 用所在 region 的 ACM cert、CloudFront 例外 — 只認 us-east-1 region 的 ACM cert（CloudFront edge 是 global、cert metadata 統一從 us-east-1 拉）。Multi-region app 要在每個 region 各 request 一份 cert、CloudFront 那份固定放 us-east-1。

Imported certificate：自管 cert（外部 CA 簽的、舊系統遷移過來的）可以 import 進 ACM、拿到 ARN 後一樣 attach 到 AWS service。代價是 ACM 不會 renew、expiry 前必須手動 re-import 新版。常見事故源：imported cert 過期、AWS service 突然 serve expired cert、Browser 顯示警告。建議 imported cert 都設 CloudWatch alarm 監 DaysToExpiry。

跟 AWS IAM 整合：誰能 issue / delete cert 走 IAM policy 控制 — acm:RequestCertificate / acm:DeleteCertificate / acm:ImportCertificate。Tag-based access control 可以限定「只有帶 team=platform tag 的 cert 才能被 platform team IAM role 改」、防誤刪 production cert。Cert 是 region-scoped resource、IAM policy 可指定 Resource ARN 限定 region / cert ID。

核心取捨表

選 ACM 的核心訴求：cert 主要 attach 到 AWS-managed service、希望 cert 完全 hands-off、不需要 export 私鑰、能接受 AWS lock-in。需要 export PEM 或跨雲 / 自管 endpoint、改走 cert-manager + Let’s Encrypt。需要內部 mTLS root + CA hierarchy 控制、走 ACM Private CA。

進階主題

ACM Private CA hierarchy：PCA 支援 root CA + 多層 intermediate CA、生產建議 root CA 離線（CA 簽完 intermediate 後 disable）、日常簽發走 subordinate CA。Subordinate CA compromise 時 revoke 該層、root 不受影響。Cert policy（path length、key usage、name constraint）在 CA 建立時設定、之後無法改、設計時要算對。

Cross-region cert（CloudFront 的 us-east-1 限制）：CloudFront 是 global service、但 attach 的 ACM cert 必須在 us-east-1。Multi-region 部署：每個 region 各 issue 一份 cert 給該 region 的 ELB / API Gateway、CloudFront 的那份單獨在 us-east-1 issue。Terraform / CloudFormation 要顯式宣告 provider region。

Imported cert 跟 auto-renewal 邊界：imported cert（外部 CA 簽的）ACM 知道存在、可以 attach、但 不 renew。常見事故：團隊 import cert 後忘了；幾個月後 cert 到期；CloudFront / ELB serve expired cert；客戶看到 browser 警告。對策：所有 imported cert 設 CloudWatch alarm DaysToExpiry < 30、AlmostExpired event 推 EventBridge → PagerDuty。長期策略是把 imported cert 都遷移成 ACM-issued cert（如果 domain ownership 可驗證）。

Tag-based access control：cert 加 tag（team=platform、env=prod）後、IAM policy 用 Condition 限定：只有同 tag 的 role 才能 update / delete。防誤刪 production cert（dev IAM role 跑 cleanup script 不會誤刪 prod）。配合 AWS IAM 的 ABAC 模型運作。

Wildcard cert 跟 SAN cert：ACM 支援 wildcard（*.example.com 涵蓋一層 subdomain）跟 SAN（一張 cert 多個 domain，最多 100 個）。Wildcard 簡化部署但 blast radius 大 — 一張 cert compromise 等於整個 subdomain tree 出事；SAN cert 細粒度但管理成本高。Production 建議按服務邊界拆 — 每個 service 一張 cert、不共用 wildcard，除非確實有大量短 lifecycle subdomain。

排錯與失敗快速判讀

• Cert PENDING_VALIDATION 一直卡住：DNS validation CNAME record 沒放對、或 DNS provider 緩存太久 — 用 dig 直接查 CNAME 是否生效、Route53 + ACM 整合通常幾分鐘、外部 DNS 可能 30 分鐘以上
• Cert renewal FAILED：RenewalStatusReason 多半是 DOMAIN_VALIDATION_DENIED（CNAME record 被刪了）或 cert 沒 attach 到任何 service — 補回 CNAME record、或把 cert attach 到至少一個 resource
• CloudFront 找不到 cert：cert 在 us-east-1 以外的 region issue — 在 us-east-1 重 issue、或用 Terraform 顯式跨 provider 設定
• Imported cert expired：忘了 manual renewal、AWS service serve expired cert — CloudWatch alarm + EventBridge 推 alert、長期遷成 ACM-issued
• ACM cert 無法用在 EC2 自管 Nginx：public cert 私鑰不能 export 是設計限制 — 改用 ACM Private CA 或 Let’s Encrypt + cert-manager
• 誤刪 production cert：沒設 tag-based protection、admin script bug — 開 deletion protection（暫時無內建、用 IAM Condition 限定 delete operation + 24h cooldown via Lambda）+ CloudTrail alert 上 acm:DeleteCertificate
• Cross-account cert 共用：ACM cert 不支援 RAM 共用 — 跨 account 要在每個 account 各 issue（或用 PCA + RAM 共用 PCA、各 account 從 PCA issue）

何時改走其他服務

不在本頁內的主題

• ACM Private CA 完整 hierarchy 設計（root CA 離線儲存、HSM-backed CA key、CRL / OCSP responder 部署）
• ACM API 完整 CLI reference 跟 Terraform resource 詳盡欄位
• TLS protocol 本身（TLS 1.2 vs 1.3、cipher suite、handshake 流程）
• Certificate Transparency log 跟 SCT embedding 內部機制
• 各 browser / OS trust store 的更新週期

案例回寫

ACM 在 07 案例庫沒有直接 vendor-level 事件、以下採對照引用：

下一步路由

• 上游：7.4 傳輸信任與憑證生命週期、7.3 入口治理與伺服器防護
• 平行：cert-manager、Let’s Encrypt、SPIRE
• 下游：AWS IAM（誰能 issue / delete cert）、AWS KMS（PCA CA key 後端）
• 跨模組：8 事故處理 vendor 清單（cert expiry / mis-issuance 進 IR 流程）
• 官方：AWS Certificate Manager Documentation

觀察

Riot Games 遷移到 EKS 的關鍵數字（引自 Riot Games case study）：

服務組合：Amazon EKS（主要）、AWS Local Zones（低延遲就近部署）、AWS Outposts（on-prem edge）、Karpenter（node lifecycle）、Terraform（IaC）。

關鍵架構決策：從 multi-tenant cluster 模型改成 single-tenant per game — 每個遊戲一個獨立 cluster、避免跨遊戲互相影響。

判讀

Riot Games 案例揭露三個多 cluster K8s 容量治理重點。

1. Cluster 隔離是容量規劃的單位：246 個 cluster 看似很多、但 每個 cluster 是獨立容量單位、不互相影響。一個遊戲的擴容不會吃掉另一個遊戲的容量。對應 05 部署平台模組 的 multi-tenant vs single-tenant 取捨。
2. 延遲門檻反推 region 部署：35ms 是競技遊戲（VALORANT、League）的可接受上限、超過會「卡」。從這個門檻反推：玩家所在 region 不能跨洲、需要區域 cluster。對應 9.12 SLO 與 Performance Budget 的 latency budget。Local Zones / Outposts 是這個門檻的工程回應。
3. Karpenter + Terraform = cluster 容量自動化：246 個 cluster 手動管理會崩。Karpenter（node 動態 lifecycle）+ Terraform（IaC）讓 cluster 級操作可重複、可審查。對應 9.9 Performance Improvement Loop 的自動化迴圈。

需要警惕：「年省 1000 萬」是 vs 自管 Mesos、不是 vs 沒上雲。EKS 仍有 vendor cost、只是比自管便宜。讀案例時要看 baseline 是什麼。另外、單一 cluster 的容量上限（pod 數、node 數）仍是工程現實、超過時要做 cluster sharding（這正是 Riot 走 246 個 cluster 的部分原因）。

策略

可重用的工程做法：

1. single-tenant cluster per workload：每個高敏感度工作負載（每個遊戲、每個關鍵服務）一個獨立 cluster、避免 noisy neighbor。對應 05 部署平台模組。
2. 延遲門檻反推 region 部署數量：先訂 latency budget、再算 玩家分布 × region cluster 數量。region 增加會線性增加 ops 成本、要在 latency 跟 cost 之間找平衡。對應 9.7 成本邊界與 efficiency。
3. cluster 級 IaC + 自動化是 multi-cluster 治理前置：Terraform / Pulumi / Crossplane + Karpenter / Cluster Autoscaler 是基本工具。

跨平台等效：GCP GKE Fleet management（multi-cluster）、Azure Fleet Manager、自建 Cluster API + ArgoCD 都可以做 multi-cluster 治理。差異是 vendor 整合度跟政策。

下一步路由

• 想設計 multi-cluster K8s → 05 部署平台模組 + 9.6 容量規劃模型
• 想做延遲門檻反推部署 → 9.12 SLO 與 Performance Budget + 9.C3 Coinbase
• 想對照微服務 vs multi-cluster → 9.C7 Lyft

引用源

• Riot Games Cuts $10M Annual Infrastructure Costs by Migrating to Amazon EKS
• Riot Games on Using AWS to Improve Gaming

觀察

Hotstar IPL 直播的關鍵數字（引自 Hotstar global record）：

AWS Media Services 在大型事件的歷史記錄：Olympics、Super Bowl、IPL Cricket（引自 AWS large-scale streaming events）。

判讀

Hotstar 案例揭露三個全球直播容量重點。

1. 集中地理區 = CDN 壓力集中：Prime Day 的流量分散全球、單一地區 CDN 不會 saturate；IPL 主要觀眾在印度、所有印度 PoP 同一時間 saturate。CDN 容量規劃必須按地區獨立做、不能用「全球總容量」當保證。對應 04 可觀測性模組 的 cardinality 與地區訊號治理、跟 9.6 容量規劃模型 的「地理分片容量」。
2. 直播跟 VoD 是不同容量問題：VoD 觀眾分散時間、CDN 可預先 cache；直播觀眾集中時間、每一個 manifest / segment 都是 live 拉取、cache hit 反而是危險（拉到舊的 segment）。對應 02 快取模組 的 cache freshness boundary、跟 03 訊息佇列 的 fan-out 設計。
3. 多 bitrate 動態切換 = 真實容量是 bitrate 加權：1860 萬觀眾不是都看 1080p — 印度行動網路下大多看 720p 或 480p、bitrate 加權後的 total bandwidth 可能比想像低。對應 9.2 Workload Modeling 的真實 workload shape。

需要警惕：「1860 萬同時觀看」是 峰值瞬間、不是全程平均。決賽 4 小時、觀眾數呈鐘形曲線、峰值維持時間可能只有 10-30 分鐘（比賽關鍵時刻）。容量規劃要看峰值持續時間、不只看峰值高度。

策略

可重用的工程做法：

1. CDN 容量規劃按地理區分割：不要假設「全球 CDN 總量」夠用、要按主要觀眾分布的地區做容量保證。對應 9.6 容量規劃模型。
2. 直播必須 pre-scaling、不能依賴 reactive：直播開始之後 CDN reactive 擴容已經太晚、觀眾體驗已壞。事件型 scheduled scaling + over-provisioning 是必須。對應 9.11 高峰事件準備。
3. multi-bitrate / ABR streaming 是容量緩衝：當網路擁塞、player 自動降 bitrate、總頻寬壓力下降。這層降級是隱性容量緩衝、要在壓測時驗證。對應 9.4 Saturation Discovery 的 saturation 行為。

跨平台等效：GCP CDN + Media CDN、Azure Front Door + Media Services、Akamai / Cloudflare / Fastly 等 multi-CDN 都是對等候選。差異是 PoP 地理分布跟 manifest 處理能力。

下一步路由

• 想規劃全球直播 → 9.11 高峰事件準備 + 9.6 容量規劃模型
• 想做 CDN 容量設計 → 05 部署平台模組 + 04 可觀測性模組
• 想理解 cache freshness 在直播的影響 → 02.4 cache copy freshness boundary
• 對照其他可預期峰值 → 9.C1 AWS Prime Day（分散全球的峰值）

引用源

• In the news: Hotstar sets new global record for live viewership
• Large scale streaming events on AWS
• Direct to Consumer & Streaming on AWS

觀察

Standard Chartered 在 Aurora 的關鍵敘述（引自 AWS search results 與相關 case study）：

服務組合：Amazon Aurora（PostgreSQL 或 MySQL 相容）、加密 at rest / in transit、多 AZ 部署、跨地區複製（受監管市場各自獨立）。

判讀

受監管銀行案例揭露三個合規驅動容量規劃的重點。

1. 資料駐留限制 = 容量規劃的單位是「per 市場」：7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成「7 個獨立規劃 × 各自合規門檻」。對應 00 服務選型模組 的合規要求識別、跟 9.6 容量規劃模型 的地理分片。
2. 「韌性 + 性能」並列、不是 trade-off：傳統工程文化常把可靠性跟性能視為對立、銀行業務要求兩者同時達標。Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標。對應 06.18 reliability metrics governance 的可靠性指標。
3. 遷移本身的合規驗證 = 容量規劃延伸：受監管系統遷移不只是技術測試、還要過合規審查（中央銀行 / 金融監管機關）、每個市場各自審。這個審查 lead time（數月）必須算進遷移時程。對應 01.4 database migration playbook 的合規驅動 migration。

需要警惕：「10x throughput」是 vs 舊系統、不是 vs 競爭對手。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低。讀案例時要對標的是「自家改善幅度」、不是「絕對性能」。

策略

可重用的工程做法：

1. 資料駐留是容量規劃的硬限制、不是優化選項：受監管市場必須各自獨立 cluster、不能用「全球單一 cluster」優化。對應 00.4 traffic data scale 的合規限制。
2. 多 AZ + 跨地區複製是合規基線、不是優化：銀行業務 RPO / RTO 通常由監管要求（不能丟資料、必須 X 小時內恢復）、不是業務 SLA 選項。對應 06.7 DR rollback rehearsal。
3. 遷移時程要算合規 lead time：每個受監管市場的審查可能 3-12 個月、合計遷移時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。對應 01.4 database migration playbook。

跨平台等效：Azure SQL Hyperscale + Azure regions、GCP Cloud SQL / Spanner + regional configurations、各家雲端的受監管雲端方案（AWS GovCloud、Azure Government、GCP Assured Workloads）都是對等候選。差異是各家對特定監管框架（PCI-DSS、ISO27001、各國金融法規）的認證覆蓋。

下一步路由

• 想規劃受監管產業 OLTP → 00 服務選型模組 + 01 資料庫模組
• 想做合規驅動的容量規劃 → 00.4 traffic data scale + 9.6 容量規劃模型
• 想理解韌性跟性能的同步達成 → 06.18 reliability metrics governance
• 對照其他金融交易案例 → 9.C4 DraftKings Aurora / 9.C3 Coinbase
• 想拆解跨 AZ failover RTO 量級與合規 anti-recommendation → Aurora 跨 AZ failover RTO
• 想評估全球資料常駐與多 region 部署 → Aurora global database 多 region
• 想對照 distributed SQL（CockroachDB / Aurora DSQL / Spanner）的合規場景 → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Amazon Aurora Customer Stories
• Amazon Aurora for Core Banking Systems
• Amazon Aurora DSQL for global-scale financial transactions

觀察

拓元 Tixcraft 在 AWS 的關鍵數字（引自 tixCraft Case Study 與 AWS re:Invent 2015 簡報）：

服務組合（依用戶提供的架構圖）：

• 入口：Amazon Route 53（DNS）+ CloudFront + S3（靜態資源 static.tixcraft.com）
• UI 層：Elastic Load Balancing → EC2 跨 3 個 Availability Zone（Tixcraft UI）
• API 層：ELB → EC2 跨 3 個 AZ（API）+ ElastiCache 加速 session
• 資料層：DynamoDB 作為主要寫入目標（接 UI 寫入跟 API 寫入）
• 付款層：獨立的 EC2 Payment、連到 traditional server（合作金流、跑於企業 data center）
• 同步層：S3 Sync + EC2 Bridge 跟 corporate data center 的 backend 雙向同步

判讀

拓元案例最值得讀的、是它揭露三個 flash-sale 工程設計的非直覺事實。

1. DynamoDB 作為寫入緩衝、不是 OLTP：搶票時的「訂單」先丟進 DynamoDB、傳統 server 用自己能承受的速度消費、即時生效在此架構下不是目標。架構上 DynamoDB 扮演 durable queue 的角色、不是傳統 OLTP DB。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」、避免後端被前端拖垮。對應 03 訊息佇列模組 的 outbox / async delivery 概念、跟 01 資料庫模組 的 transaction boundary 分離。
2. DynamoDB IOPS 從 20 衝到 135,000 = partition 設計能撐：這個 6,750 倍的彈性不是 DynamoDB 魔法、是 partition key 設計均勻 的結果。partition key 不均、IOPS 上限是「最熱 partition 上限」、不是「總和」。對應 9.C5 Amazon Ads 的同一判讀重點、跟 9.4 Saturation Discovery 的 hot partition 識別。
3. 30 分鐘擴 130 倍 = 雲原生架構的存在證明：6 台 → 800 台不是手動操作、是 Auto Scaling Group + AMI prebuild + load balancer warmup 的組合。傳統 IDC 做不到。這層彈性是「30 秒內」flash-sale 的前置條件。對應 05 部署平台模組 的 autoscaling 與 9.6 容量規劃模型。

需要警惕的判讀盲點：

• 「限流到底怎麼做」這個工程社群關心的問題、架構圖上看不到明確元件。可能是「DynamoDB 寫入排隊 = 隱性限流」、也可能是 ELB / WAF / 應用層限流。沒有公開資訊不要過度推測。
• 2015 年的數字、用的還是 t2.micro 跟舊版 DynamoDB throughput model。現在等效實作可能會用 DynamoDB on-demand、AWS WAF、CloudFront WAF rules、或 SeatGeek-style Virtual Waiting Room（見 9.C16）。
• 「30,000 張 / 3 分鐘」是 票房成績、不是 系統極限。系統能撐遠不止這個量、只是票本身賣完了。

策略

可重用的工程做法：

1. flash-sale 的核心架構模式：寫入緩衝 + 慢速消費：前端把訂單塞進可彈性擴容的儲存（DynamoDB / Redis Stream / Kafka）、後端按自己能力消費。這個模式讓「短時間吸收洪峰」跟「實際處理」解耦。對應 03 訊息佇列模組 與 01 資料庫模組。
2. partition key 設計是 flash-sale 的命脈：搶票場景天然容易 hot partition（同一場演唱會 = 同一 event_id）、必須用 composite key（event_id + user_id_hash）或 write sharding（event_id + random_suffix）分散。對應 9.C5 Amazon Ads。
3. flash-sale 必須事先 ELB / Auto Scaling 預熱：開賣前 30-60 分鐘 pre-warm ELB、預先啟動最低額度的 EC2、避免 t=0 時冷啟動。對應 AWS 官方 Flash Sale 工程指引。
4. 付款層獨立、不被搶票流量影響：拓元把 Payment EC2 拉出來、直連傳統金流 server。讓「選位 + 下單」的高頻流量不會塞爆「付款」的低頻流量。對應 9.5 瓶頸定位流程 的關鍵路徑切分。
5. 限流（rate limiting）通常是隱性的、不一定看得到 component：DynamoDB 寫入排隊本身就是隱性限流；也可以加 WAF rate-based rule、ELB request throttling、或前置 Virtual Waiting Room 做明確限流（見 9.C16）。

跨平台等效：GCP Cloud Spanner / Bigtable + Cloud Pub/Sub 作 buffer + GKE autoscaling；Azure Cosmos DB + Service Bus + AKS；自建 PostgreSQL + Kafka + Kubernetes 都可以實作對等架構。差異是 vendor 整合度跟擴容速度。

下一步路由

• 想設計 flash-sale 緩衝架構 → 03 訊息佇列模組 + 01 資料庫模組 + 9.6 容量規劃模型
• 想做 partition key 設計 → 9.C5 Amazon Ads + 01.6 高併發資料存取
• 想做明確限流 / 排隊機制 → 9.C16 SeatGeek Virtual Waiting Room
• 想預熱 ELB / Auto Scaling → 05 部署平台模組 + 9.11 高峰事件準備
• 對照其他售票市場 → 9.C17 BookMyShow（印度市場、年售 2 億張）
• 想理解 flash-sale 場景的 partition key 反模式 → DynamoDB partition key 反模式
• 想評估 on-demand vs provisioned 在 flash-sale 的搭配 → DynamoDB on-demand vs provisioned

引用源

• tixCraft Case Study (AWS)
• tixCraft on AWS re:Invent 2015 Recap (SlideShare)
• tixCraft: Handling Millions of Ticketing Requests with AWS (YouTube)
• Top considerations for Flash sale events (AWS Cloud Operations Blog)
• Handle traffic spikes with Amazon DynamoDB provisioned capacity

觀察

SeatGeek Virtual Waiting Room 架構（引自 AWS Architecture Blog）：

業務動機：取代「第三方 waiting room 服務」、原因是缺乏客製化（VIP 規則、優先級）跟 metrics 可見度。

關鍵機制：

1. Token = 庫存單位：access token 總數 = 可售票數量。沒拿到 token 的用戶被導到 waiting room 頁面、看到排隊位置與預估等待時間。
2. FIFO 或 priority queue：可以按進入順序、也可以對 VIP 客戶優先發 token。
3. Token 失效機制：用戶完成購票 / 主動退出時、token 釋放回 pool、給下一位等候用戶。

判讀

SeatGeek 案例揭露三個明確限流設計重點。

1. 隱性緩衝 vs 明確排隊是兩種架構取捨：Tixcraft 模式「全部塞進 DynamoDB」、用戶以為下單成功、實際處理排隊。SeatGeek 模式「明確告訴你排隊位置」、用戶看得到等待時間。前者犧牲透明度換流量吸收、後者犧牲流量吸收換體驗。對應 9.10 Production-Side 驗證 的用戶體驗 vs 系統行為取捨。
2. WebSocket connection 是 stateful 容量單位：100 萬個 active waiting room 用戶 = 100 萬個 WebSocket connection、每個 connection 都吃記憶體跟 file descriptor。Lambda 沒辦法保持 WebSocket、需要 API Gateway WebSocket API 或 AppSync 配合。對應 05 部署平台模組 的 stateful service 容量規劃。
3. 限流粒度 = 業務粒度：「每分鐘發 N 個 token」這個參數直接決定「每分鐘成交 N 張票」。N 太小、賣不完；N 太大、後端撐不住。N 不是技術參數、是業務 × 後端容量的協商結果。對應 9.6 容量規劃模型 把容量規劃跟業務 KPI 對接。

需要警惕的判讀盲點：

• AWS Architecture Blog 沒提具體流量數字（concurrent users、queue depth、throughput）。讀者無法直接套用到自家容量規劃、必須自己壓測。
• DynamoDB 4 張表的設計 看似簡單、實際上每張表的 partition key / sort key 設計都要仔細想。複製這個架構不等於拿到 SeatGeek 的吞吐能力。
• 「token expiration」機制如果設計不好（例如用戶關閉瀏覽器、token 沒回收）、會導致「排隊很長但實際空著」、影響轉換率。

策略

可重用的工程做法：

1. 明確 vs 隱性限流的選擇：高價值門票（演唱會、限量周邊）適合明確排隊（用戶願意等）；高頻低價值商品（FCFS 折扣）適合隱性緩衝（讓用戶快速完成）。
2. Virtual Waiting Room 是 stateful service、要規劃連線容量：不是 stateless Lambda 一招到底、需要 WebSocket gateway + DynamoDB state store。對應 05 部署平台模組 的混合架構。
3. token 過期策略要寫進設計初稿：用戶離開、付款超時、瀏覽器當掉 — 三種狀況的 token 回收邏輯都不一樣、要明確設計。
4. 可觀測性是「自建 waiting room」勝過「第三方」的關鍵：SeatGeek 換掉第三方就是要 metrics 可見、知道每分鐘 token issue rate、queue depth distribution、token expiration rate、conversion funnel。對應 04 可觀測性模組。

跨平台等效：GCP Cloud Functions + Firestore + Pub/Sub；Azure Functions + Cosmos DB + SignalR；自建 Redis（INCR / TTL）+ WebSocket gateway（Soketi / Socket.IO + Redis adapter）都可以實作對等架構。AWS 還推出官方 Virtual Waiting Room on AWS Solutions、是 SeatGeek 模式的可重用版本。

下一步路由

• 想設計明確排隊限流 → 05 部署平台模組 + 9.11 高峰事件準備
• 對照隱性緩衝模式 → 9.C15 Tixcraft
• 想做 conversion funnel 可觀測性 → 04 可觀測性模組 + 04.16 SLI / SLO 訊號
• 想了解 stateful service 容量規劃 → 05 部署平台模組 + 9.5 瓶頸定位流程

引用源

• Build a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeek
• Virtual Waiting Room on AWS (Solutions)
• How to manage peak traffic on AWS using Queue-it’s virtual waiting room

觀察

BookMyShow 在 AWS 的關鍵敘述（引自 BookMyShow AWS Migration Blog）：

資料架構：

• Data Lake：Amazon S3 統一儲存
• Ingestion：Kafka consumers、AWS Glue ETL、AWS IoT Core（MQTT）
• Processing：Amazon EMR（streaming permanent cluster + batch transient cluster）
• Data Warehouse：Amazon Redshift + materialized views
• Analytics：Amazon Athena（ad-hoc）+ Amazon QuickSight（dashboard）
• ML：Amazon SageMaker（內容熱度、活動熱度、搜尋趨勢模型）
• Orchestration：Amazon MWAA + AWS Step Functions

關鍵業務支撐：「sudden spikes with new movies or events launched」靠 serverless（S3、Glue、Athena、Step Functions、Lambda）自動擴容、無需人工介入。

判讀

BookMyShow 案例揭露三個規模化 ticketing 平台的長期工程重點。

1. 單一搶票 → 常態多事件 = 架構從「為峰值設計」變「為流量分佈設計」：每天上百場電影 + 數十場演唱會 + 各種活動同時開票、每場都是 mini flash-sale。容量問題不再是「為一場演唱會準備」、而是「為每天上百個峰值同時準備」。對應 9.2 Workload Modeling 從單一 workload 變成 workload portfolio。
2. 資料層比交易層更難擴：8 TB → 80 TB 過程中、舊 analytics 系統用 15 年才走到極限。交易層擴容靠 stateless EC2 + auto-scaling 相對容易、資料層 schema migration、ETL 重寫、報表回對都是長 lead time 工作。對應 01 資料庫模組 的 schema migration 與 04 可觀測性模組 的 cost attribution。
3. 跨國市場 = 多重合規約束：印度、新加坡、印尼、中東各自有資料駐留 / 加密 / 報稅規則。S3 + EMR + Redshift 的「資料分區」不只是性能議題、也是合規議題。對應 9.C14 Standard Chartered 的合規容量規劃。

需要警惕的判讀盲點：

• 「年售 2 億張」是 年度總和、不是 峰值。實際單秒峰值（板球比賽決賽開票、寶萊塢新片首映）案例本身沒揭露。
• 案例聚焦在 資料分析層 的遷移、不是 交易層 的 flash-sale 設計。讀者若想學「單場 flash-sale 怎麼撐」、應該回 9.C15 Tixcraft 或 9.C16 SeatGeek。
• 「80% 成本下降」是 vs 15 年舊系統、不是 vs 競爭對手。舊系統的儲存效率、運維成本本來就低、改善幅度部分來自「現代化紅利」、不只是 AWS 服務本身。

策略

可重用的工程做法：

1. 大規模 ticketing 平台要分「交易層」跟「資料層」兩條容量規劃：交易層為單一 event flash-sale 設計（9.C15 / 9.C16 模式）；資料層為「上千場活動的長期分析」設計（BookMyShow 模式）。兩者用不同服務、不同 SLO。
2. 跨國平台先解決資料駐留、再規劃跨國 analytics：印度資料不能搬到新加坡分析、合規必須各國資料本地處理、再彙整 metadata。對應 9.C14 Standard Chartered。
3. serverless data stack 是 ticketing 平台的長期方向：S3 + Glue + Athena + Step Functions 的成本曲線比 EMR cluster 平穩、沒事件時近乎 0、有事件時自動擴。對應 9.7 成本邊界與 efficiency。
4. 遷移時程 4 個月 = 計畫密度極高：15 年資產 4 個月遷完不是常態、需要先把 資料模型 canonical 化、再 batch 平行遷。對應 01.4 database migration playbook 的 schema 對映先行。

跨平台等效：GCP BigQuery + Dataflow + Cloud Storage + Pub/Sub 是對等 stack；Azure Synapse + Data Lake + Event Hubs；自建 Delta Lake + Spark + Kafka 都可以實作對等架構。差異是 vendor 整合度跟 serverless 透明度。

下一步路由

• 想規劃多事件 ticketing 平台 → 9.2 Workload Modeling + 01 資料庫模組
• 想看單一 flash-sale 設計 → 9.C15 Tixcraft + 9.C16 SeatGeek
• 想做跨國合規容量規劃 → 9.C14 Standard Chartered + 00 服務選型模組
• 想做大規模 migration → 01.4 database migration playbook + 9.C9 Spotify migration

引用源

• How BookMyShow saved 80% in costs by migrating to an AWS modern data architecture
• AWS Modern Data Architecture

觀察

Zoom 在 2020 年 COVID 期間的關鍵敘述（引自 DynamoDB Customers）：

關鍵敘述：「On the backend, they were able to manage this surge with Amazon DynamoDB for Zoom Meetings.」

判讀

Zoom surge 揭露三個 SaaS 突發成長的工程重點。

1. SaaS surge 是結構性、不是暫時性：Pokemon GO 上線爆紅後流量會隨熱度消退、Zoom COVID 成長是「永久 baseline 上移」。容量規劃不能假設「過幾個月會回來」、必須假設「3 億 DAU 是新常態」。對應 9.6 容量規劃模型 的長期 baseline 重新校準。
2. DynamoDB 「無限擴容」對 SaaS 元資料層特別適用：Zoom 會議 metadata（room ID、participant list、permission state）是典型 KV 工作負載、partition key（meeting_id）天然均勻、不會 hot partition。對應 9.C5 Amazon Ads 同樣的 partition 均勻優勢。
3. 媒體串流不在 DynamoDB：Zoom 的影音流量是 P2P + edge servers、不經 DynamoDB。DynamoDB 只承擔「control plane」、不承擔「data plane」。這個分離是擴 30 倍的前提 — 控制面跟資料面解耦、控制面用 managed 服務、資料面用專屬基礎設施。對應 9.5 瓶頸定位流程 的關鍵路徑切分。

需要警惕：「nearly infinitely」是行銷敘述、不是工程承諾。實務上 Zoom 在 COVID 初期確實遇到 outage 與性能問題、後續才穩定。讀案例時要看 最終狀態 跟 過程中的 incident。

策略

可重用的工程做法：

1. 控制面跟資料面分離：高頻 metadata 操作放 managed KV（DynamoDB / Cosmos DB / Firestore）、大資料量串流放專屬基礎設施（CDN / WebRTC / 自管 servers）。對應 05 部署平台模組 與 9.5 瓶頸定位流程。
2. surge 後重新校準 SLO baseline：30x 成長之後、SLO 的「正常範圍」要更新、否則 monitoring 會誤報。對應 9.12 SLO 與 Performance Budget 的 SLO 演進。
3. 長期 surge 觸發架構重新評估：DynamoDB 是「擴大量」的好選擇、但成本也跟著放大。當 baseline 從 1000 萬永久升到 3 億、原本的 on-demand 模式可能變得貴、要考慮 provisioned + auto-scaling 組合。對應 9.7 成本邊界與 efficiency。

跨平台等效：Google Meet 也用 Spanner / Firestore、Microsoft Teams 用 Cosmos DB — 三家視訊會議都靠 managed KV 撐 metadata、是同一個架構模式的不同 vendor 實作。

下一步路由

• 對照 product surge → 9.C8 Pokemon GO
• 想理解 control plane vs data plane → 9.5 瓶頸定位流程 + 05 部署平台模組
• 想規劃 surge 後的 SLO → 9.12 SLO 與 Performance Budget + 04.16 SLI / SLO 訊號
• 想評估 surge 下的 on-demand vs provisioned 切換 → DynamoDB on-demand vs provisioned
• 想避免 surge 觸發 hot partition → DynamoDB partition key 反模式

引用源

• Amazon DynamoDB Customers
• Zoom Video Communications on AWS

觀察

Capcom 在 AWS 的關鍵敘述（引自 Capcom Case Study 與 DynamoDB Customers）：

關鍵敘述：「Capcom uses Amazon DynamoDB to meet this demand with single-digit millisecond response times」。

判讀

Capcom 案例揭露三個遊戲後端 KV 的工程重點。

1. 遊戲後端 KV = 跨遊戲共用基礎設施：Resident Evil / Street Fighter / Monster Hunter 是不同類型遊戲（單機+多人 / 對戰 / 合作打怪）、卻共用 同一套後端 KV。這個共用降低了單一遊戲的維運成本、也讓新遊戲上線時不用重做基礎設施。對應 05 部署平台模組 的 multi-tenant platform。
2. single-digit ms response time = 玩家體感「即時」的底線：戰鬥動作、技能釋放、玩家對戰都要次秒級反應、超過 10ms 就「卡」。這個延遲門檻反推 Capcom 必須用 sub-region cache（ElastiCache / 本地 game server）+ DynamoDB DAX、不能單靠 DynamoDB。對應 9.C3 Coinbase 的延遲反推。
3. 「工程資源從 DB 運維轉到遊戲品質」是 managed 服務的真實價值：Capcom 不是 IT 公司、是遊戲公司。把 DBA 時間從「Postgres patching、replication 設定、backup 排程」釋放到「遊戲機制設計、玩家行為分析」、才是 30% 成本下降的本質。對應 9.7 成本邊界與 efficiency 的人力成本工程化。

需要警惕：「billions of requests」沒指明時間單位（每秒、每天、每月）。讀案例時要找具體單位、不要直接套用到自家。

策略

可重用的工程做法：

1. 遊戲後端 KV 用 DynamoDB / Cosmos DB / Bigtable：partition key 用 player_id 天然均勻、不會 hot partition。對應 01 資料庫模組 的 schema 設計。
2. EKS 跑 game server、不直接連 DynamoDB：game server 處理遊戲邏輯（戰鬥、配對、防作弊）、DynamoDB 處理持久狀態。中間用 DAX 或 ElastiCache 減少 DynamoDB 呼叫。對應 9.5 瓶頸定位流程。
3. 多 IP / 多遊戲共用平台是降本核心：每個新遊戲不重做基礎設施、共用同一套 DynamoDB + EKS。跟 9.C12 Riot Games 的「single-tenant per game」對照 — 不同 IP 公司有不同取捨。

跨平台等效：GCP Bigtable + GKE + Memorystore、Azure Cosmos DB + AKS + Cache for Redis 都可實作對等架構。

下一步路由

• 對照其他遊戲後端 → 9.C12 Riot Games EKS（cluster 隔離 vs 共用）
• 想設計遊戲 KV → 01 資料庫模組 + 9.C5 Amazon Ads
• 想理解 sub-ms latency 反推 → 9.C3 Coinbase + 9.12 SLO 與 Performance Budget
• 想規劃遊戲 KV access pattern 與 single-table design → DynamoDB single-table design
• 想評估遊戲流量的 on-demand vs provisioned → DynamoDB on-demand vs provisioned

引用源

• CAPCOM Case Study
• Amazon DynamoDB Customers
• Powering Gaming Applications with Amazon DynamoDB

觀察

Zomato 帳單系統遷移的關鍵數字（引自 AWS Database Blog）：

關鍵動機：TiDB 必須為「突發流量峰值」提前 over-provision、付出常態成本；DynamoDB on-demand 模式「pay only for what we use」、避免 over-provisioning。

判讀

Zomato 遷移揭露三個 DB 選型決策的判讀重點。

1. NewSQL vs NoSQL 的取捨不只是 schema：TiDB 提供 SQL 介面跟 ACID、DynamoDB 提供 KV 介面跟最終一致性。Zomato 選 DynamoDB 是判斷「帳單事件本身可以接受 eventually consistent」、用一致性換性能跟成本。對應 01.5 transaction boundary 的一致性取捨。
2. TiDB 必須 over-provision 是分散式 SQL 的常態：分散式 SQL 為了支援跨節點交易、必須有預留容量、否則峰值會出現 leader election storm 或 follower lag。這跟 9.C10 Spanner 的「節點數即容量」是同類取捨、Spanner 也必須預先 scale 節點。
3. 2K → 8K RPM 是 4 倍、但延遲降 90% 才是真關鍵：吞吐改善可能來自架構優化、延遲改善才是 DB 本質差。從 baseline → 10% 通常代表少了 1-2 個 hop（例如 cross-region replication、coordinator round-trip）。對應 9.1 壓測理論與系統行為 的 Little’s Law。

需要警惕：

• 「成本降 50%」是 當下流量下的對照。如果未來流量繼續成長、DynamoDB 的 cost-per-request 成長率比 TiDB 自管 cluster 高 — 達到某規模後 TiDB 反而更便宜。讀遷移案例要看「在當下流量下划算」、不等於「永遠划算」。
• 「90% 延遲降」可能只是 p50、p99 / p999 改善幅度通常較小。

策略

可重用的工程做法：

1. DB 遷移前先確認業務一致性需求：能接受 eventually consistent 的工作負載適合 KV / NoSQL；必須 strong consistency 的工作負載必須 SQL / NewSQL。對應 01.5 transaction boundary。
2. 遷移評估要看「總成本曲線」、不是「當下 snapshot」：算未來 12-24 個月在預期流量下的成本對照、不是只算現在。對應 9.7 成本邊界與 efficiency。
3. 遷移過程要 dual-write + shadow read 驗證：避免新舊系統行為不一致導致業務問題。對應 01.3 schema migration rollout evidence。
4. on-demand vs provisioned 的選擇與業務流量形狀對應：突發流量適合 on-demand、可預測流量適合 provisioned。對應 9.C15 Tixcraft 的 on-demand 應用。

跨平台等效：MongoDB Atlas → DynamoDB、Cassandra → DynamoDB、PostgreSQL → Aurora、CockroachDB → Spanner 都是常見遷移路徑。每條路徑的取捨類似。

下一步路由

• 想做 DB 遷移評估 → 01 資料庫模組 + 01.4 database migration playbook
• 想理解一致性取捨 → 01.5 transaction boundary + 9.C10 Spanner
• 想做總成本評估 → 9.7 成本邊界與 efficiency
• 對照其他 DB 遷移 → 9.C9 Spotify Kafka→Pub/Sub
• 想拆 access pattern 對應的 DynamoDB schema → DynamoDB single-table design + DynamoDB partition key 反模式
• 想評估搬遷後的 capacity mode → DynamoDB on-demand vs provisioned

引用源

• Unlocking performance, scalability, and cost-efficiency of Zomato’s Billing Platform by switching from TiDB to DynamoDB
• How Zomato Boosted Performance 25% and Cut Compute Cost 30% Migrating Trino and Druid Workloads to AWS Graviton

定位

AWS VPC Traffic Mirroring 適合需要網路層能見度的 AWS workload。當 application code、service mesh 或 host capture 都不適合改動時，VPC 層 mirror 可以從 ENI 複製封包到 analysis appliance、IDS、packet capture 或自管處理服務。

這個定位讓 AWS VPC Traffic Mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 前置觀測。它偏封包觀察與樣本收集，若要做應用層 replay、filter、rewrite 或 side effect 隔離，通常還需要 GoReplay、proxy、custom processor 或測試環境配合。

跟 GoReplay 比、VPC Traffic Mirroring 走 無侵入 L3 packet copy、GoReplay 走 application-level HTTP capture / rewrite；跟 Service Mesh Mirroring 比、VPC Mirror 在 ENI 層、Mesh Mirror 在 K8s pod 層；跟 AWS Network Firewall 比、Firewall 是 inline 阻擋、Mirror 是 side-channel 觀察、兩者目的不同但 packet path 相近。

最短判讀路徑

判斷 VPC Traffic Mirroring deployment 是否健康、最少看四件事：

• Source ENI selection：哪些 ENI 被 mirror（per-instance / per-subnet / 用 tag 自動選）、是否覆蓋瓶頸路徑上的關鍵節點（ALB target / NAT Gateway / RDS proxy / cross-AZ ENI）、漏掉哪個 ENI 就是 evidence 盲區
• Filter rule 收斂：mirror filter 用 protocol / port / CIDR / direction 限定、避免「全 ENI 全 traffic」這種失控設定；filter 太寬會把 cross-AZ cost + target 處理量直接炸上去
• Target NLB capacity：mirror target 是 ENI 或 NLB、target capacity（NLB flow / bandwidth）跟 source 流量比例要對得起來、target overload 會 drop 封包讓 evidence 失真
• Sampling rate / packet length truncation：高流量服務不必 1:1 mirror、要設 packet_length 截斷（只取 header）跟 mirror session ratio；忘設 sampling 等於整條 production 流量複製兩份、AWS bill 月底會出事

四件事任一缺失、就是 9.10 Production-Side 驗證 邊界的待補項目。

適用場景

網路層瓶頸定位適合 VPC Traffic Mirroring。當 latency、packet loss、TLS handshake、connection reset、NAT、load balancer 或 cross-AZ traffic 是疑點時，封包 mirror 能提供 application metrics 看不到的證據。

低侵入 traffic sampling 適合 VPC Traffic Mirroring。團隊可以在不改 application code 的情況下收集 production flow，作為 workload model、security analysis 或 replay pipeline 的輸入。

受管 AWS 網路環境適合 VPC Traffic Mirroring。當服務主要跑在 EC2 / ENI 可 mirror 的環境中，VPC 原生能力可以讓網路團隊用既有安全與觀測流程管理。

選型判準

網路層鏡像價值來自低侵入。團隊可以在不調整 application 或 service mesh 的情況下取得 flow evidence，但也要承擔 L7 語意不足的限制。

安全分析價值來自封包細節。對容量工程而言，封包證據能幫忙確認 connection、TLS、NAT、load balancer 與跨區流量成本；對資安而言，則能支援 IDS 與 forensic workflow。

跟其他方式的取捨

AWS VPC Traffic Mirroring 和 GoReplay 的主要差異是層級。VPC mirroring 在 L3 / L4 觀察封包；GoReplay 更接近 HTTP application replay，對 request rewrite 與 target control 更直接。

AWS VPC Traffic Mirroring 和 service mesh mirroring 的主要差異是控制範圍。VPC mirroring 由網路層控制，適合低侵入封包觀察；service mesh mirroring 由 L7 route policy 控制，適合服務版本與 route 對照。

AWS VPC Traffic Mirroring 和 synthetic load test 的主要差異是用途。VPC mirroring 提供 production traffic evidence；synthetic load test 提供可控壓力。兩者常搭配：先用 mirror 校正 workload model，再用 k6 / Gatling / Locust 產生可控負載。

操作成本

AWS VPC Traffic Mirroring 的主要成本是資料治理。Mirror target 可能收到 payload、token、cookie、internal identifiers 與敏感資料，因此保存、查詢、保留期限、存取權與刪除責任要先定義。

網路成本來自複製 traffic。Mirror session 會增加網路流量與 target processing 成本，高流量服務要先估算 mirror ratio、filter、target capacity 與跨 AZ 費用。

加密成本來自 L7 可讀性。TLS traffic 在網路層 mirror 後通常仍是加密封包；若需要 application payload，要搭配解密點、proxy、key 管理或 application-level capture。

Evidence Package

AWS VPC Traffic Mirroring 結果應回寫到 evidence package。最小欄位包括 mirror source ENI、filter rule、mirror target、session number、time range、sampling / truncation、target capacity、payload handling、packet metrics、known gap 與 owner。

Evidence package 的核心用途是把網路層觀察接回效能判斷。Reviewer 要能知道 mirror 覆蓋哪些 ENI、哪些封包被 filter、target 是否有 capacity，以及封包證據如何對應到 application latency 或 saturation。

進階主題

Filter rule 設計：mirror filter 支援 source CIDR / dest CIDR / protocol / port range / direction（ingress / egress）、rule number 決定 evaluation 順序。production 慣例是 最小覆蓋原則 — 先用 port 443 + dest CIDR = ALB target group 限定到關鍵 path、再依需要擴張。filter 寫太寬會把 control-plane heartbeat、health check、internal RPC 全部 mirror 進來、target 處理量瞬間爆掉。

跟 IDS / packet analyzer 整合：mirror target 接 ENI 後常見的下游堆疊是 Zeek（前 Bro、生成 connection log / protocol log）、Suricata（rule-based IDS / IPS 偵測）、Wireshark / tshark（離線封包分析）。實務上 mirror → NLB → 自管 EC2 跑 Zeek 產 JSON log → 進 Datadog / Splunk 做 correlation。容量工程關心 connection reset 跟 retransmit、資安關心 protocol anomaly、共用同一份 mirror feed。

Replay 到 staging cluster：mirror feed 不能直接 replay（沒有 stateful 重組），但可以接 packet replayer（tcpreplay / GoReplay packet mode）把樣本送到 staging。要注意 side effect 隔離 — staging 的 DB / external API 不應該真的執行寫入、否則 mirror 變成 production fanout。

Traffic analysis platform 整合：mirror 取得的 packet evidence 通常進 Datadog Network Performance Monitoring 做 NPM dashboard、或進 Splunk Stream app 做 SIEM correlation。整合的關鍵是 時間軸對齊 — packet timestamp、application log、metrics 三者要同步、否則 root cause 拼不回去。

排錯與失敗快速判讀

• Target NLB capacity 不夠 / drop packet：mirror traffic 量超過 NLB flow limit、packet 被 silently drop — 拆 mirror session 到多個 target、開 NLB flow log 看 drop reason、必要時改用 Gateway Load Balancer
• Filter rule 太寬導致流量爆：「mirror 所有 traffic」設定上線後 target ENI 跟 cross-AZ bandwidth 雙重炸 — 立刻關掉 session、改用 dest CIDR / port 收斂、加 packet_length 截斷只取 header
• Cross-AZ mirror cost 暴增：source ENI 跟 target 在不同 AZ、每個封包複製都收 cross-AZ traffic 費 — target NLB 部署到每個 AZ、用 AZ-affinity routing、或把 mirror target 限定在 source 同 AZ
• TLS payload 看不到：mirror 拿到加密封包、L7 內容無法分析 — 把解密點移到 ALB / NLB-TLS termination、或在 application 層加 capture（不再用 VPC mirror）
• Mirror session 漏掉新 instance：autoscaling 起新 instance 沒自動加入 mirror — 用 mirror target by tag、Terraform / CloudFormation 把 mirror session 寫進 ASC launch template
• Packet timestamp 不對齊 application log：mirror packet 時間是 source ENI capture 時間、不是 application processing 時間、做 latency 分析會偏差 — 用 packet 5-tuple + request ID 對齊 application log、不要直接相減 timestamp

案例回寫

AWS VPC Traffic Mirroring 適合回寫網路與平台層效能案例。它可接 9.C34 GCP 130K node GKE cluster 的大規模網路觀測需求（雖在 GCP、但網路證據的層次拆解可類比）、9.C22 Wayfair GCP burst capacity 的跨雲容量觀測、9.C1 Prime Day readiness 的 pre-event network evidence、9.C12 Riot Games 246 EKS cluster 跨 cluster 的網路流量觀測、以及 9.C24 Genesys DynamoDB 15-region 的 99.999% 可用性下封包層 evidence 補強。

這些案例的重點是網路層 evidence。VPC Traffic Mirroring 頁引用案例時，要把 case 轉成 mirror source、filter、target capacity、packet metric、cross-AZ cost 與 L7 correlation — 例如 Riot Games 35ms 延遲門檻下、cross-AZ traffic mirror 本身會增加成本、必須先用 filter 收斂到關鍵 ENI。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：9.5 瓶頸定位流程
• 平行：GoReplay
• 平行：Service Mesh Mirroring
• 知識卡：Shadow Traffic
• 官方：AWS VPC Traffic Mirroring documentation

定位

AWS Cost Explorer 適合做 AWS 成本分析的 baseline。當團隊需要回答「哪個服務、帳號、tag 或 usage type 造成成本變化」，Cost Explorer 可以直接使用 AWS billing data 產生圖表、report、forecast 與 API 查詢。

這個定位讓 AWS Cost Explorer 接到三個主章。它從 9.7 成本邊界與 efficiency 接收 cost per request 與 cost curve，從 9.8 效能可觀測性 接收成本 dashboard 需求，從 04 可觀測性成本歸因 接收 tag 與 ownership 規則。

跟 CloudHealth / Vantage 等 multi-cloud FinOps 平台比、Cost Explorer 走 AWS-native + free：不另收費（API 查詢按 request 收 USD 0.01）、跟 Billing Console + CUR + Budgets + Anomaly Detection 同一 IAM 邊界、tag 與 Cost Category 設定直接從 billing data 拉。換來的限制是 只看 AWS、跨雲 / Kubernetes pod-level / SaaS license 都要外接。

最短判讀路徑

判斷 Cost Explorer 是否健康發揮、最少看四件事：

• Cost Explorer view 是否有 saved report：team-level saved report（依 service / linked account / tag 拆）、月度 review checklist、有沒有人定期看 trend、view 是否進 dashboard share
• CUR（Cost & Usage Report）設定：是否啟用 CUR 2.0 / Data Exports、S3 bucket 是否打開 Athena / QuickSight 查詢、hourly granularity 是否開、resource ID 是否開（沒開的話 tag-based allocation 拆不到 instance level）
• Budgets + Anomaly Detection alert routing：service-level / account-level budget threshold、Cost Anomaly Detection monitor 是否分 service / linked account 設定、alert 接到 Slack / PagerDuty / email、誰負責 triage
• Tag policy + Cost Category 治理：哪些 cost allocation tag 已啟用（在 Billing Console activate 才會進 CUR）、untagged resource 比例、Cost Category rule 是否覆蓋多帳號合併、誰維護 rule lifecycle

四件事任一缺失就是 9.7 成本邊界與 efficiency 邊界的待補項目 — CUR 沒開就只能看 console aggregated view、CUR 開了沒接 Athena / QuickSight 就只能看 Console 介面、不能跟 release / capacity 資料 join。

適用場景

AWS 月度成本 review 是 Cost Explorer 的主要入口。團隊可以依 service、linked account、region、tag、cost category、purchase option 或 usage type 檢視趨勢，找出 EC2、RDS、S3、NAT Gateway、Data Transfer 或 managed service 的成本變化。

Forecast 與 trend review 適合用 Cost Explorer 連到容量規劃。月中 forecast、daily cost trend、commitment utilization 與 reservation recommendation 可以讓平台團隊提前調整 autoscaling、instance family、reserved capacity 或 service 配置。

Programmatic cost query 適合接內部 dashboard。Cost Explorer API 可以把成本與用量資料拉到 release dashboard、capacity review、service scorecard 或 FinOps workflow，讓工程團隊在自己熟悉的介面看成本訊號。

選型判準

AWS baseline 價值來自資料來源直接。Cost Explorer 使用 AWS 成本與用量資料，適合作為其他 FinOps 工具導入前的共同對帳入口。

Report 價值來自快速拆解。當某月成本上升，工程團隊可以先用 service、usage type、region 與 tag 找出最大變動，再決定是否需要更細的 workload-level 或 Kubernetes-level 工具。

API 價值來自流程整合。把 cost query 接到 release note、incident review 或 capacity planning dashboard，能讓成本變化跟部署、流量與容量決策同時被檢視。

跟其他工具的取捨

AWS Cost Explorer 和 Vantage 的主要差異是範圍。Cost Explorer 是 AWS-native 成本入口；Vantage 適合跨 provider、Kubernetes 成本與工程團隊自助報表。

AWS Cost Explorer 和 CloudHealth 的主要差異是治理層級。Cost Explorer 適合 AWS account 與 service-level 分析；CloudHealth 適合 enterprise FinOps policy、showback / chargeback 與多雲治理。

AWS Cost Explorer 和 Akamas 的主要差異是行動模型。Cost Explorer 提供成本與用量事實；Akamas 把成本、SLO 與配置調校接成 optimization loop。

選 Cost Explorer 的核心訴求：AWS-only + free + 跟 Billing / Budgets / Anomaly Detection 同 IAM 邊界。當需求出現 跨雲對帳 / Kubernetes pod-level chargeback / SaaS license 整合、就改走 CloudHealth / Vantage。

進階主題

Cost Anomaly Detection：基於 ML 的 cost spike 偵測、按 service / linked account / cost category / tag 建 monitor、anomaly score 超 threshold 就 alert。實務治理：先用 AWS services monitor 全 service 跑 2-4 週看 baseline、再針對高變動 service（EC2 / Data Transfer / S3）建 dedicated monitor 拉緊 threshold、alert 接 SNS → Slack / PagerDuty。false positive 主要來自 release event 或 batch job、用 dimensional filter（exclude 特定 usage type / region）+ subscribe threshold 調 absolute USD + percentage 雙條件。

Budgets + Forecast：Budget 可設 monthly / quarterly / annual、threshold 走 actual 跟 forecast 兩條 — forecast 達 80% 先 warn、actual 達 100% 才 page。Forecast 基於過去 historical pattern + linear extrapolation、新 workload / peak event 前要手動調整或關 forecast alert 避免噪音。Budget action 可以自動執行 IAM policy / SCP（例如 dev account 超預算自動 detach attach role）、但 production 別開、誤殺風險高。

CUR (Cost & Usage Report) + S3 + Athena / QuickSight：CUR 是 hourly granularity、含 resource ID、reserved instance / savings plan attribution、cost allocation tag 全欄位的 raw billing data、寫到 S3 bucket（Parquet 格式）。標準 pipeline：CUR → S3 → Glue Crawler → Athena → QuickSight dashboard、或直接拉到 BigQuery / Snowflake 跟其他維度 join（release calendar / SLO / traffic）。CUR 2.0 / Data Exports 是新版、欄位 schema 穩定、recommend 新部署直接走 CUR 2.0。

Reserved Instance + Savings Plan recommendation：Cost Explorer 內建 RI / SP recommendation engine、看 past 7 / 30 / 60 day usage、推薦 commitment term（1yr / 3yr）+ payment option（All Upfront / Partial / No Upfront）+ break-even point。實務做法：先看 Compute Savings Plan（覆蓋 EC2 / Fargate / Lambda）的 baseline、再看 EC2 Instance Savings Plan（鎖 family + region）加深、最後看 RI 鎖 specific instance type — 三層疊加可達 60-70% saving、但 commitment 風險也疊加、要對齊 capacity planning。

排錯與失敗快速判讀

• Tag-based allocation 拆不到 instance / 比例異常：cost allocation tag 沒在 Billing Console activate（即使 EC2 tag 有設、billing 沒看到）— 進 Billing Console → Cost Allocation Tags → activate、要等 24hr CUR 才回填。Untagged resource 比例 > 10% 直接代表 tag policy 沒落地、補 AWS Config rule 或 SCP 強制 tag。
• CUR delivery lag / 資料對不上 Console：CUR delivery 是 daily、月底結算後 finalized 還要等 1-3 天、月中看 CUR 跟 Console 有 % 差是正常 — 月中 review 用 Console、月底結算用 CUR finalized。如果 CUR 過了 48hr 還沒 delivery、檢查 S3 bucket policy 跟 CUR report status。
• Anomaly Detection false positive 多：threshold 設太嚴（absolute USD 太低 / percentage 太敏感）、或 monitor scope 太寬（包含 dev / sandbox account）— 拆 monitor 按 environment 分、production 抓 absolute USD + percentage 雙條件、dev 降低敏感度或關。
• Forecast 跳水 / 跳漲不合理：forecast 用 linear extrapolation、月中 spike / drop 會被放大、release 前 / peak event 前 forecast 不準 — 用 actual + Budget threshold 校正、別只看 forecast 決策。
• API rate limit / 查詢費用爆增：內部 dashboard 沒 cache 直接打 Cost Explorer API、每 request USD 0.01 月底結算 USD 數千 — cache 層 1hr TTL、time range 對齊 daily granularity、別 per-minute polling。
• Cost Category rule 衝突 / unallocated 過多：rule 設有 overlap 但 priority 沒設、或 rule 沒覆蓋新 service — Cost Category 走 explicit priority + default rule、新 service launch 進 owner checklist。

操作成本

Cost Explorer 的主要成本是資料治理。Tag、Cost Category、account structure、reservation sharing 與 owner mapping 要先整理，報表才會對工程團隊有行動意義。

API 整合需要查詢治理。程式化查詢要控制權限、頻率、cache、time range 與 paginated request 成本，避免內部 dashboard 造成額外查詢浪費。

成本解釋需要補業務 context。Cost Explorer 可以指出哪個 service 或 usage type 變貴；真正的工程判斷還要接 release、traffic、peak event、data retention、capacity policy 與 SLO 變化。

Evidence Package

AWS Cost Explorer 結果應回寫到 AWS cost evidence package。最小欄位包括 report name、group by、filter、time range、account、service、region、tag、usage type、forecast、recommendation、owner 與 action item。

Evidence package 的核心用途是讓 AWS 成本 review 可以重跑。Cost Explorer report 要能回答「查詢條件是什麼、成本變化在哪個維度、誰負責處理、下次如何確認改善」。

案例回寫

AWS Cost Explorer 目前適合作為 AWS-first 成本案例的 baseline 工具。它可回寫到 9.C23 Netflix Aurora consolidation 的跨 DB 整併與 28% 成本下降驗證、9.C17 BookMyShow modern data architecture 的 80 TB 多副本 → 單一 source of truth + 80% 分析成本下降、9.C20 Zomato 的 on-demand vs over-provisioned 對照、以及 9.C22 Wayfair GCP burst 的 hybrid 模式 AWS-side baseline 釐清（即使是跨雲案例、AWS 側的 review 仍可用 Cost Explorer 跑）。

這些案例的重點是成本訊號到工程行動的轉換。Cost Explorer 頁引用案例時，要把 report 維度、變化原因、服務 owner、容量調整與驗證方式寫成可重跑流程 — Netflix 28% 下降要對應 Aurora cluster 數、IO-Optimized 切換時機與 reader replica 配比。

下一步路由

• 上游：9.7 成本邊界與 efficiency
• 上游：9.8 效能可觀測性
• 跨模組：04 可觀測性成本歸因
• 平行：Vantage
• 官方：AWS Cost Explorer documentation

觀察

Netflix 在 Aurora 整合的關鍵敘述（引自 Netflix consolidates relational database infrastructure on Amazon Aurora）：

Netflix 整體 AWS 使用：「Netflix uses AWS to deliver billions of hours of content monthly and runs its analytics platform for optimum performance of its global service. AWS enables Netflix to quickly deploy thousands of servers and terabytes of storage within minutes.」

判讀

Netflix Aurora 整合揭露三個大規模平台 DB 治理重點。

1. 「DB 種類太多」本身是規模化的成本：Netflix 過往用 PostgreSQL、MySQL、Oracle 等不同 RDB、每個都需要不同 DBA 知識、不同備份、不同 monitoring 流程。整合到 Aurora 不只是「換 DB」、是「降低運維 surface area」、釋放工程資源。對應 9.7 成本邊界與 efficiency 的人力成本工程化、跟 9.C19 Capcom 同類訴求。
2. 75% performance improvement 是 Aurora storage layer 的本質優勢：Aurora 把 storage 跟 compute 分離、storage 用分散式 log-based 設計、replication 在 storage 層處理、不在 compute 層 — 這讓 read replica 不會受 master 寫入壓力影響、性能曲線比傳統 RDB 平滑。對應 01 資料庫模組 與 9.5 瓶頸定位流程 的儲存層 vs 計算層分離。
3. Netflix 的 DB 工作負載大多是「微服務私有 store」：Netflix 微服務各自有自己的 Aurora cluster、不共用 — 跟 monolith 「一個大 DB 撐全部」相反。這層架構讓「DB 容量規劃」變成「每個微服務的容量規劃」、複雜度分散。對應 05 部署平台模組 的 service decomposition、跟 9.C7 Lyft 微服務。

需要警惕：

• 「effective 75% improvement」是 跨多個 workload 的最大改善幅度、不是「每個 workload 都 +75%」。實際每個 workload 改善幅度從 10% 到 75% 不等。
• Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是「需要 ACID 的 OLTP 工作負載」、不是「all-purpose store」。

策略

可重用的工程做法：

1. DB 種類整合是規模化的必要工程：每多一種 DB 就多一套運維 surface。在能合理 consolidate 的時候整合、降低 ops 複雜度。對應 00 服務選型模組 的 vendor diversity 取捨。
2. storage / compute 分離是 OLTP 擴容的關鍵：Aurora、Spanner、TiDB 都採類似設計、是現代 cloud DB 的共同特徵。對應 9.C10 Spanner 的 storage layer 設計。
3. 微服務私有 store 比共用 DB 容量規劃簡單：每個服務各自管 DB 容量、跨服務 contention 變成 network 議題 而非 DB lock 議題。
4. 大規模平台必須區分「OLTP 用 Aurora」「analytics 用 data lake」「KV 用 DynamoDB」「cache 用 EVCache」：Netflix 用各種 DB、不是一招打天下。對應 00 服務選型模組 的 polyglot persistence。

跨平台等效：GCP Spanner（替代 OLTP）+ Bigtable（替代 KV）+ BigQuery（替代 analytics）；Azure Cosmos DB（替代多 model）+ SQL Hyperscale + Synapse — 各雲商提供類似 stack。

下一步路由

• 對照其他大規模平台 → 9.C12 Riot Games EKS（不同 consolidation 策略）
• 想理解 Aurora 設計 → 9.C4 DraftKings Aurora + 01 資料庫模組
• 想做 polyglot persistence 選型 → 00 服務選型模組 + 9.7 成本邊界與 efficiency
• 想做 DB consolidation 規劃 → 01.4 database migration playbook
• 想理解 +75% 的 storage / compute 解耦根因 → Aurora 儲存層架構
• 想規劃自管 PostgreSQL / MySQL 遷入 Aurora 的步驟 → 從自管 PostgreSQL/MySQL 遷入 Aurora

引用源

• Netflix consolidates relational database infrastructure on Amazon Aurora, achieving up to 75% improved performance
• Netflix on AWS
• Netflix Case Study

觀察

Genesys Cloud 在 DynamoDB 的關鍵數字（引自 Genesys DynamoDB Case Study）：

關鍵架構決策（引述 Chief Architect Rob Gevers）：「Amazon DynamoDB is our primary data layer by default, and teams have to justify the use of something else.」

判讀

Genesys 案例揭露三個 B2B SaaS 平台容量規劃重點。

1. B2B 可用性目標跟 C2C 不同：B2C 大型網站可能接受 99.9%（年停機 8.76 小時）、B2B SaaS 經常合約規定 99.95% 或 99.99%、客服平台類甚至要 99.999%（年停機 5 分鐘）。每多一個 9、容量規劃跟運維成本指數成長。對應 9.12 SLO 與 Performance Budget 的 SLO 等級設計。
2. 「DynamoDB 為預設、用其他要 justify」是規模化平台的工程治理：跟 9.C23 Netflix 整合到 Aurora 是同樣訴求、不同實作 — Genesys 選 DynamoDB 為基準是因為「Multi-region active-active」+「自動 scaling」+「99.999% SLA」的組合最容易達成 5 個 9 目標。對應 01 資料庫模組 的 DB 預設選型。
3. 15 主 region + 5 衛星 region = 全球客戶就近接入：客戶服務有強烈延遲敏感（agent 操作介面卡 1 秒、客服效率掉一半）、必須在客戶所在地有 region。跟 9.C12 Riot Games 246 cluster 的延遲驅動 region 部署同類思維。對應 9.6 容量規劃模型 的地理分散規劃。

需要警惕：

• 「99.999% over 12 months」是 截至特定時間點的歷史值、不代表「未來持續達成」。可用性是滾動指標、不是恆久承諾。
• 案例 沒有 提具體 QPS / RPS、訊息量、延遲分布。讀者要對 策略 學習、具體數字需要自己壓測。

策略

可重用的工程做法：

1. B2B SaaS 平台優先選 multi-region active-active 資料層：DynamoDB Global Tables、Cosmos DB Multi-Region Write、Spanner multi-region 都是候選。對應 01.5 transaction boundary 的全球一致性取捨。
2. 「預設 DB」原則簡化 onboarding：新團隊不用評估十種 DB、預設用 X、特殊需求再 justify。減少團隊認知負擔、加速產品開發。對應 9.C23 Netflix 的 DB 整合。
3. 99.999% 必須有 redundancy 在每一層：DNS、load balancer、application、database、storage 都要跨 region active-active。任何一層 single-region 就破壞整體 SLO。對應 05 部署平台模組 跟 06 可靠性驗證模組。
4. 多 region 是成本 vs 可用性的硬取捨：15 個 region 的成本約是 1 個 region 的 15 倍 — 對 B2B SaaS 是合理投資、對 B2C 通常不划算。

跨平台等效：Azure Cosmos DB Multi-Region Write、GCP Spanner multi-region、Cassandra multi-DC 都可實作對等架構。差異是 region 數量、SLA 承諾、跨 region 延遲。

下一步路由

• 想設計 B2B SaaS 可用性 → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想設計多 region 資料層 → 01 資料庫模組 + 9.C10 Spanner
• 想做 DB 統一治理 → 9.C23 Netflix Aurora consolidation + 00 服務選型模組
• 想規劃跨 region 容量 → 9.6 容量規劃模型 + 9.C12 Riot Games
• 想理解 DynamoDB 99.999% 背後的 partition / GSI 設計 → DynamoDB partition key 反模式 + DynamoDB GSI / LSI 設計
• 想對應 global tables 多 region 寫衝突 → DynamoDB global tables 寫衝突

引用源

• Genesys Achieves 99.999% Availability Using Amazon DynamoDB
• Amazon DynamoDB Customers

觀察

Tubi 在 ElastiCache 的關鍵敘述（引自 ElastiCache Customers）：

判讀

Tubi 案例揭露三個 ML feature store 容量設計重點。

1. feature store 是 ML inference 的 critical path：每個推薦請求都要查 N 個 feature（user_profile、item_metadata、recent_interactions、similar_users 等）、每個 feature 查詢都吃 latency budget。對應 9.12 SLO 與 Performance Budget 的多 stage budget 分解。
2. ScyllaDB → ElastiCache 是「持久 KV → 純 cache」的權衡：ScyllaDB 是 Cassandra-compatible 高吞吐 KV、提供 durability；ElastiCache 是 in-memory cache、可以 cache miss。Tubi 選 cache 是判斷「feature 可以重新計算」、durability 不必、純 in-memory 更快。對應 02 快取模組 的 cache vs durable store 選型。
3. p99 才是 ML 系統的容量門檻：ML 系統的 user-perceived latency 是 最後完成的 inference、不是平均。p50 快沒用、p99 慢用戶就看到 loading spinner。對應 9.4 Saturation Discovery 的 latency percentile 分析、跟 9.C3 Coinbase 的長尾延遲議題同類。

需要警惕：

• 「sub-10ms p99」沒指明 p999 / p9999。p9999 通常比 p99 高一個量級、會出現在實際 user-perceived 體驗。
• ElastiCache 的 sub-10ms 是 cache hit 路徑 — cache miss 路徑會回到 ScyllaDB 或重新計算、延遲可能 100ms+。容量規劃要考慮 cache hit rate 跟 miss recovery 兩條路徑。

策略

可重用的工程做法：

1. ML feature store 用「兩層 cache」設計：L1 是 in-process cache（最熱的 features）、L2 是 ElastiCache / Memcached（次熱）、L3 才是持久 store（ScyllaDB / DynamoDB / S3 + Parquet）。對應 02 快取模組 的 cache hierarchy。
2. feature 可重算 → 用 cache、feature 必須持久 → 用 store：判斷依據是「重算成本」跟「資料一致性需求」。對應 02.4 cache copy freshness boundary。
3. p99 / p999 反推單個 stage latency 上限：每個 stage（network、cache lookup、feature aggregation、model inference、response serialization）給一個 latency budget、總和等於整體 SLO。對應 9.12 SLO 與 Performance Budget、跟 9.C3 Coinbase 同樣的反推思維。

跨平台等效：AWS ElastiCache for Redis / Valkey / MemoryDB、GCP Memorystore for Redis、Azure Cache for Redis 都可實作對等架構。專為 ML feature store 設計的還有 Feast / Tecton / Hopsworks 等開源 + 商業方案、底層常用 Redis-compatible store。

下一步路由

• 想規劃 ML feature store → 02 快取模組 + 9.12 SLO 與 Performance Budget
• 想做 p99 / p999 反推 → 9.C3 Coinbase + 9.4 Saturation Discovery
• 對照其他 cache 案例 → 9.C6 Tinder ElastiCache（配對引擎）
• 想理解 cache hierarchy → 02 快取模組

引用源

• Amazon ElastiCache Customers
• Build an ultra-low latency online feature store for real-time inferencing using Amazon ElastiCache for Redis

觀察

PayPay 在 DynamoDB 的關鍵敘述（引自 DynamoDB Customers）：

判讀

PayPay 案例揭露三個行動支付訊息系統的工程重點。

1. 支付通知是「不可丟失 + 不可延遲」雙重需求：用戶付完款 30 秒沒收到通知會懷疑系統壞了、會打客服 / 重複扣款。這層需求比 OTA 推播嚴格、必須有 durable queue + retry + 重複偵測。對應 03 訊息佇列模組 的 idempotency 設計。
2. DynamoDB 在「訊息事件」這類負載特別適合：每則訊息有獨立 message_id（partition key 天然均勻）、TTL 機制可以自動清理過期訊息（避免 storage 爆炸）。對應 9.C5 Amazon Ads 的 partition 均勻優勢、跟 02.4 cache copy freshness boundary 的 TTL 議題。
3. 3 億 / 天 ≈ 3,500 訊息 / 秒平均：聽起來不大、但這是 平均。月底、雙 11 類大促、新年紅包等場景、單秒峰值可能達 10x-50x。對應 9.2 Workload Modeling 的峰均比評估。

需要警惕：「super reliable」是行銷語言、不是工程承諾。讀此類短篇案例要把行銷敘述折扣、重點看 服務組合 與 規模量級。

策略

可重用的工程做法：

1. 訊息系統設計區分「通知」跟「訊息」：通知（payment received）是 transactional、不可丟失；訊息（marketing）可以丟失部分、重點是 throughput。兩者用不同 SLO、不同 storage。對應 03 訊息佇列模組 的訊息分類。
2. TTL 自動清理避免 storage 成本爆炸：3 億 / 天 × 30 天 = 90 億筆記錄、不清理會撐死 storage 預算。對應 02 快取模組 的 TTL 設計。
3. 訊息推送的下游（APNs、FCM、SMS gateway）是隱性瓶頸：DynamoDB 寫入可以撐 3K msg/sec、但 APNs 一天的 quota 是有限的。對應 9.5 瓶頸定位流程 的依賴鏈分析。

跨平台等效：GCP Firestore + Cloud Messaging、Azure Cosmos DB + Notification Hubs 都是對等架構。差異是 vendor 整合度跟全球分發能力。

下一步路由

• 想設計行動支付訊息 → 03 訊息佇列模組 + 9.5 瓶頸定位流程
• 對照其他 KV 高吞吐 → 9.C5 Amazon Ads / 9.C18 Zoom
• 想做訊息系統容量規劃 → 9.6 容量規劃模型 + 9.2 Workload Modeling
• 想避免訊息熱點打爆單一 partition → DynamoDB partition key 反模式
• 想評估訊息系統的 capacity mode → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• PayPay on AWS

觀察

Disney+ 在 DynamoDB 的關鍵敘述（引自 DynamoDB Customers）：

每個用戶動作（播放、暫停、跳過、加入 watchlist、評分）都是一次 DynamoDB 寫入。每次打開 app 又是多次讀（自己的 watchlist、最近播放、繼續觀看）。

判讀

Disney+ 案例揭露三個串流平台 metadata 層的工程重點。

1. 「每日數十億動作」= read + write 都要撐：跟 9.C5 Amazon Ads 的 18:1 讀寫比不同、串流 metadata 通常接近 5:1 read-heavy（每動作 1 寫、每 session 5 讀）。partition key 設計通常用 user_id、天然均勻、不會 hot partition。對應 01 資料庫模組 的 schema design。
2. 新片發布是 predictable-peak：Marvel / Star Wars / Disney 動畫 新片上線首日、metadata 流量可衝 3-5 倍 — 因為「全平台用戶同時打開該片頁面」。這比一般 Black Friday 集中、像 9.C13 Hotstar IPL 的集中型流量。對應 9.11 高峰事件準備 的內容發布事件容量規劃。
3. watchlist + 播放進度需要跨裝置即時同步：用戶在手機看到一半、晚上回家用電視繼續、進度必須跨裝置同步。這層需求對 DynamoDB Global Tables（multi-region active-active）特別適合。對應 01.5 transaction boundary 的最終一致性可接受場景。

需要警惕：「billions of actions daily」沒指明具體數字（10 億、100 億 還是 數十億？）。讀此類短篇案例只能取「量級對標」、不能套用具體數字。

策略

可重用的工程做法：

1. 串流平台分「metadata 層」「content delivery 層」：metadata（watchlist、播放進度、推薦）用 DynamoDB / Cosmos DB；content（video file）用 CDN + S3 / object storage。兩者完全分開、互不影響。對應 05 部署平台模組 的 control plane vs data plane、跟 9.C18 Zoom 的同類思維。
2. 新片發布像 mini Black Friday、要 pre-scaling：發布時間已知、流量倍數可預估（根據前幾部）、可以提前 1-2 天 pre-scale DynamoDB capacity。對應 9.11 高峰事件準備。
3. DynamoDB Global Tables 是跨裝置同步的有效方案：用戶在不同 region 登入同帳號、寫入會自動同步到其他 region。對應 9.C24 Genesys 的 multi-region active-active。

跨平台等效：Netflix 同類 metadata 用 Cassandra + EVCache（9.C23 Netflix 提及）、HBO Max 用 Aurora、Apple TV+ 用 FoundationDB + Cassandra — 各家串流的 metadata 技術棧不同、但「分層解耦」的工程哲學一致。

下一步路由

• 對照其他串流案例 → 9.C13 Hotstar IPL（live）/ 9.C29 NTT DOCOMO Lemino
• 想理解 metadata 層 → 01 資料庫模組 + 9.5 瓶頸定位流程
• 想做內容發布 pre-scaling → 9.11 高峰事件準備 + 9.C1 Prime Day
• 想做跨裝置同步設計 → 9.C24 Genesys multi-region
• 想拆 metadata 的 single-table 與 GSI 設計 → DynamoDB single-table design + DynamoDB GSI / LSI 設計
• 想做跨 region metadata 一致性 → DynamoDB global tables 寫衝突

引用源

• Amazon DynamoDB Customers
• Amazon DynamoDB use cases for media and entertainment customers

觀察

FanDuel 在 AWS 的關鍵敘述（引自 FanDuel Case Study）：

關鍵敘述：「seamlessly scale capacity 5–10 times as required for large sporting events, such as the NFL Super Bowl」。

判讀

FanDuel 案例揭露三個雙重峰值對齊的工程重點。

1. 直播跟投注是兩種完全不同 SLO：直播容忍秒級延遲（用 CDN + ABR 串流）、投注必須毫秒級成交（Super Bowl 進球瞬間、賠率變動、用戶投注必須在賠率變化前完成）。兩個服務必須各自獨立擴容、各自獨立 SLO。對應 9.12 SLO 與 Performance Budget 的多 SLO 對齊。
2. AWS Local Zones / Wavelength / Outposts 是地理 + 監管雙重需求：美國博彩受各州監管、資料必須留在州內 → 用 Local Zones 在每個州就近部署；4G/5G 用戶投注延遲敏感 → 用 Wavelength 在電信商機房內運算；on-prem 需求 → 用 Outposts。對應 9.C14 Standard Chartered 的受監管雙重需求、跟 9.C12 Riot Games 的延遲反推 region。
3. 5-10x 是「同類事件中的最高倍率」：Super Bowl 是 NFL 賽季最大事件、不是常態。平日 baseline → 季後賽 2-3x → 季冠軍賽 4-5x → Super Bowl 5-10x。容量規劃要按事件級別分段、不是一律 10x。對應 9.6 容量規劃模型 的事件型容量分級。

需要警惕：

• AWS 案例 沒有 提具體 betting transaction TPS、concurrent streams、延遲分布。讀者要對 策略 學習、不要套用具體數字。
• 「5-10x」是 峰值倍數、不是 peak 持續時間。Super Bowl 的關鍵 30 分鐘可能 8-10x、其他 3 小時可能 3-5x。

策略

可重用的工程做法：

1. 不同 SLO 的工作負載分開部署、不要混在同一 service：betting 跟 streaming 在 FanDuel 必然是兩個獨立微服務、各自有 dedicated infrastructure。對應 05 部署平台模組 的 service decomposition、跟 9.C7 Lyft 同思維。
2. 多層 edge（Local Zone / Wavelength / Outposts）服務不同延遲需求：Local Zone 服務「州內合規」需求、Wavelength 服務「電信網內超低延遲」、Outposts 服務「on-prem 監管」需求。三者組合對應跨州博彩業務。
3. 事件型容量規劃分級：建立 event tier 體系（regular game / playoff / championship / super bowl），每 tier 對應不同 pre-scale 倍數。對應 9.11 高峰事件準備 的容量分級。

跨平台等效：Azure 提供類似 stack（Stack Edge + Edge Zones + Azure for Operators）、GCP 有 Network Edge + Distributed Cloud。差異是各家 edge 覆蓋深度跟電信商合作。

下一步路由

• 對照其他事件型峰值 → 9.C2 GR8 Tech（賽事高潮 AI 預測）/ 9.C4 DraftKings
• 想設計多 SLO 對齊 → 9.12 SLO 與 Performance Budget
• 想做受監管多地區部署 → 9.C14 Standard Chartered + 9.C12 Riot Games
• 想做 edge / Local Zone 規劃 → 05 部署平台模組
• 想理解雙峰下 Aurora storage / replica scaling → Aurora 儲存層架構 + Aurora read replica scaling
• 想評估 distributed SQL 在 betting 場景的 fit → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• FanDuel Case Study
• FanDuel CloudFront Case Study

觀察

NTT DOCOMO Lemino 在 AWS 的關鍵數字（引自 Lemino Case Study）：

服務組合：AWS Media Services（Elemental Link、MediaConnect、MediaLive、MediaPackage）、Amazon Aurora、Amazon DynamoDB、DynamoDB Accelerator (DAX)、Amazon OpenSearch Service。

關鍵敘述：採用 DynamoDB 的原因 — 「connection limits became bottlenecks when experiencing a rapid increase in access」。

判讀

Lemino 案例揭露三個現代串流服務啟動的工程重點。

1. 「connection limit 是 RDB 的隱性 bottleneck」是 OLTP 在 surge 下的典型問題：傳統 RDB（PostgreSQL、MySQL）每個連線吃記憶體跟 process / thread、connection pool 上限通常 1K-5K 個。當突發流量湧入、第一個爆的不是 CPU 也不是 disk、是 連線數量。DynamoDB 的 HTTP API 模型沒有 connection state、天然解決這個問題。對應 01 資料庫模組 的 connection pool 議題、跟 9.C20 Zomato 遷移動機同類。
2. AWS Media Services 是「電視台級」串流基礎設施：Elemental Link（encoding）、MediaConnect（transport）、MediaLive（live encoding）、MediaPackage（packaging + DRM）— 這套 stack 過往是電視台才買得起的硬體設備、AWS 把它變成 pay-per-use 服務。對應 05 部署平台模組 的 vendor-specific 串流服務評估。
3. 90% 工程工時下降 = 走 managed 路線的真正價值：傳統電信商 launch 串流服務、要養 50-100 個 SRE + DBA + network 工程師、Lemino 用 managed 服務只需 5-10 個。差距不在「能不能 launch」、在「launch 後的維運成本」。對應 9.C19 Capcom 的同類訴求。

需要警惕：「tens of thousands req/sec」可能指 2 萬或 8 萬、差距 4 倍。「3 個月 5M MAU」很亮眼、但 NTT DOCOMO 自身有 8000 萬+ 電信用戶可以推、不是純自然成長。

策略

可重用的工程做法：

1. 新串流服務優先選 DynamoDB / Cosmos DB / Bigtable 撐 metadata 層：避免 connection limit、避免 schema migration、避免 DBA 維運成本。
2. AWS Media Services / GCP Media CDN / Azure Media Services 是新進入者快速 launch 的捷徑：不要重造串流 stack、直接用 vendor 提供的。
3. DAX 是 DynamoDB 讀 cache 的標準解法：當讀峰值持續高（例如熱門節目首播、Hotstar 等級）、加 DAX 減少 DynamoDB 讀次數、降低成本。對應 02 快取模組。
4. 小團隊 + managed services 是電信商雲端轉型的範本：傳統電信商過去靠人海戰術、現在改靠 managed + 工程紀律。

跨平台等效：GCP 提供 Media CDN + Anvato，Azure 提供 Media Services + Azure Front Door — 各家都有完整串流 stack。

下一步路由

• 對照其他串流案例 → 9.C13 Hotstar IPL（live 直播）/ 9.C27 Disney+（VOD metadata）
• 想理解 connection limit 議題 → 01 資料庫模組 + 9.C20 Zomato 遷移
• 想做 DAX / cache 加速 → 02 快取模組 + 9.C25 Tubi ML feature store
• 想規劃 managed-only 串流 stack → 05 部署平台模組 + 00 服務選型模組
• 想做串流 metadata 的 partition / GSI 設計 → DynamoDB partition key 反模式 + DynamoDB GSI / LSI 設計
• 想評估 on-demand vs provisioned 給直播 / VOD 用 → DynamoDB on-demand vs provisioned

引用源

• NTT Docomo Rebuilds Infrastructure for Lemino Streaming Service Launch
• Direct to Consumer & Streaming on AWS

觀察

Coinbase MongoDB 平台的關鍵數字（引自 Coinbase Engineering Blog 與 MongoDB customer case study）：

服務組合：MongoDB Atlas（主資料層）、DynamoDB（部分 workload 的 federated store）、Memcached（query result cache）、自研 mongobetween proxy（連線多工）、Ruby on Rails 單體 + 多個 Fragment APIs、ML 預測模型驅動 cluster auto-scaling。

關鍵負載形狀：「加密貨幣價格突發 + 用戶交易需求湧入」雙峰疊加。價格 alert 觸發 read 爆量（users / portfolio 查詢）、下單觸發 write 爆量（order book / wallet 寫入）。兩種峰值不像 9.C4 DraftKings 的 Super Bowl 事件型可預測、是隨外部市場波動的 low-latency-sustained 中夾雜 surge。

判讀

Coinbase MongoDB 的工程選擇揭露三個 document database 在 production 主角位置的設計重點。

1. MongoDB + Ruby 連線爆炸需要外部 connection pool：CRuby 因為 GVL 必須每 CPU core 起一個 process、blue-green 部署期間 instance 數量 ×2、連線數隨之 ×2、單一 cluster 看到 60K 連線/分鐘。原生 MongoDB driver 沒有跨 process 的 connection pool — 跟 PostgreSQL 走 pgbouncer 是同樣需求、所以 Coinbase 自建 mongobetween 做多工。對應 01.6 高併發資料存取 的 connection storm 問題、document database 不會自動解決、要主動補工具。
2. document model 撐 1.5M reads/sec 靠 cache + freshness token：直接打 MongoDB 不可能撐 1.5M reads/sec — Coinbase 在 users 服務前面加 Memcached query cache、單 document query 先查 cache。但 cache + write 會有一致性問題、所以引入 OCC version 跟 freshness token：write 成功後給 client 一個 token、client 之後 read 帶 token、server 保證返回的資料版本 ≥ token、必要時 bypass cache 直接打 DB。對應 01.5 transaction boundary 的 read-after-write 設計。
3. 加密貨幣 surge 用 ML 預測、不靠 reactive scaling：cluster 擴容要 70 分鐘、傳統 CPU / queue 觸發的 reactive scaling 在 surge 開始時才動、來不及。Coinbase 訓練 ML 模型分析價格資料、提前 60 分鐘預測流量、預先擴容。把擴容時間從 70 分鐘壓到 25 分鐘是 trigger 提前、不是擴容本身變快。對應 9.6 容量規劃模型 的 predictive scaling。

需要警惕：

• 「1.5M reads/sec」是 users 服務 加上 cache 的數字、不是 MongoDB cluster 純讀取數字。讀案例時要區分「應用層觀察到」跟「DB 層實際承擔」。
• mongobetween 是 Coinbase 特殊環境（Ruby + GVL + blue-green）的產物。Go / Java / Node.js 應用因為原生支援連線多工、通常不需要這層 proxy。
• ML 預測有 false positive / false negative — 預測錯時要嘛浪費容量、要嘛 surge 真來時擋不住。Coinbase 沒揭露準確率、所以仍保留 reactive scaling 作為 safety net。

策略

可重用的工程做法：

1. document database 撐大規模 OLTP 要主動補 connection pool：MongoDB 原生 connection 模式對「process 數多 + deploy 重」的環境會爆。應用層或 sidecar proxy 做多工是基線設計。對應 01.10 KV / Document DB 容量規劃。
2. freshness token 是 read-after-write 一致性的可重用模式：比 strong consistency（性能差）跟 eventually consistent（read 不到剛寫的）更精細的中間路徑。token 機制可以推廣到任何「主要 eventually consistent、少數 read 要求最新」的場景。
3. predictive scaling 適用於「外部訊號可預測流量」的服務：加密貨幣價格、賽事行程、票務開賣時間都是外部訊號。比 reactive scaling 早一個擴容週期出手。對應 9.C2 GR8 Tech 的 AI 預測式擴容。
4. federated DB（MongoDB + DynamoDB）按 workload 分流：document-shaped 用 MongoDB、access pattern 固定的 KV 用 DynamoDB。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload 形狀分。對應 9.C23 Netflix Aurora 的多 DB 整合反例（Netflix 走整合方向、Coinbase 走 federated）。

跨平台等效：

• AWS：MongoDB Atlas + ElastiCache + DynamoDB（Coinbase 配置）
• GCP：MongoDB Atlas on GCP + Memorystore + Firestore（document API）
• Azure：Cosmos DB MongoDB API + Cache for Redis、不需要 Atlas
• mongobetween 風格的 proxy：PostgreSQL 走 pgbouncer / pgcat、MongoDB 走 mongobetween / mongoproxy

下一步路由

• 想規劃 MongoDB 大規模 production → MongoDB vendor page + 01.10 KV / Document DB 容量規劃
• 想做 read-after-write 一致性設計 → 01.5 transaction boundary
• 想做 predictive scaling → 9.C2 GR8 Tech + 9.6 容量規劃模型
• 想對照 MongoDB 遷出 / 保留決策 → 9.C30 Microsoft 365（遷到 Cosmos DB MongoDB API）
• 想理解 connection storm 問題 → 01.6 高併發資料存取
• 想深入 connection / proxy 治理與 cache 層 → MongoDB connection 管理與 cache 層
• 想做 replica set 讀寫分離設計 → MongoDB replica set read preference

引用源

• Coinbase：Scaling connections with Ruby and MongoDB
• Coinbase：Scaling Identity - How Coinbase Serves 1.5M Reads/Second
• Coinbase：How We Do MongoDB Migrations at Coinbase
• MongoDB customer case study：Coinbase Decreases Scaling Time
• mongobetween GitHub repository

觀察

Toyota Connected 平台關鍵數字（引自 AWS case study 與 MongoDB customer case study）：

服務組合：MongoDB Atlas（document store，20 databases）、AWS Lambda（serverless 處理事件）、Amazon Kinesis Data Streams（即時資料攝取）、CloudAMQP（非同步訊息）、Redis（hot cache）、Kubernetes（microservice 編排）。

關鍵負載形狀：「車輛 sensor 持續低頻 + 緊急事件高優先低延遲」雙模式並存。

• 持續模式：900 萬車輛、每車數百 sensor、定期上報遙測資料。這是「sustained-growth + 高 throughput」的形狀、document model 比 wide-column 更適合 — 因為不同車型 / 不同年份的 sensor schema 不一樣、document 自然演進、不需要每加 sensor 就 ALTER TABLE。
• 緊急模式：SOS 按鈕、自動撞擊通報、車輛安全異常。這是 life-critical low-latency — 3 秒內 sensor 訊號要從車輛到 agent 螢幕、含網路傳輸、event routing、microservice 處理、agent UI rendering。這個 budget 倒推回 MongoDB 寫入要求是 sub-100ms。

判讀

Toyota Connected 的 MongoDB 選擇揭露三個 IoT / telematics 工程決策的判讀重點。

1. document model 適合「sensor schema 隨產品演進」的場景：車載 sensor 種類隨車型、年份、地區規範變化。RDB 走「每加 sensor 加 column」會讓 schema migration 變成發行週期的卡點；document model 走「polymorphic document」、新 sensor 只是新欄位、舊文件不需要 backfill。對應 MongoDB vendor page 的 document shape 教學段。但這個彈性的成本是：production 必須做 schema governance（validation、版本欄位、application 層相容處理），否則「schema 自由」會變「production data inconsistency」。
2. 20 個 Atlas database 不是技術上限、是業務邊界切分：18 Billion transactions / 月 ÷ 30 天 ÷ 86400 秒 ≈ 7K transactions / sec。這個數字單一 MongoDB cluster 可以撐、不需要 20 個 DB。Toyota 切 20 個 DB 是按 microservice ownership 跟 blast radius — 每個 microservice 擁有自己的 DB、單一 DB 故障不會影響其他服務。對應 9.5 瓶頸定位流程、把「總吞吐」拆成「per-DB 邊界」。
3. 99.99% target vs 99% 實測差距揭露 telematics 的可用性挑戰：99.99% 是 4 分鐘 / 月停機、99% 是 7.2 小時 / 月停機。差兩個 9 不是 MongoDB 自身可用性問題、是 end-to-end 鏈路問題 — 車輛無線網路、cellular tower、AWS network、event bus、microservice、Atlas cluster 任一環節掉都會打掉可用性。MongoDB Atlas 自身的 SLA 通常是 99.95%、達到 99.99% 必須 multi-region + 跨雲冗餘。對應 9.C24 Genesys 99.999% 的多 region active-active 設計。

需要警惕：

• 「18 Billion transactions / 月」是 平台所有服務 加總、不是 MongoDB 單一 cluster 數字。MongoDB 只承擔其中需要 document storage 的部分、其他走 Lambda 直接處理或寫到 Kinesis。
• 「3 秒延遲到 agent」包含車載、無線、雲端、UI、agent 操作多個環節。MongoDB 在這個延遲鏈裡通常分到 100-500ms 預算、不是整個 3 秒。
• MongoDB 6.0+ 有 time series collection 對 IoT 寫入有專屬優化。Toyota 揭露的 20 個 DB 沒明確說有沒有用 time series collection — 對 IoT 案例這是重要區分、但 case study 沒揭露。

策略

可重用的工程做法：

1. IoT 高頻 sensor 寫入考慮 MongoDB time series collection（6.0+）：比 regular collection 寫入吞吐高 3-5x、storage 壓縮率更好。專為 timestamp + metadata + measurement 三段式資料優化。對應 MongoDB vendor page 的容量規劃要點段。
2. mission-critical IoT 系統要做 multi-region 跟多供應商備援：99.99% 不能只靠 MongoDB Atlas 本身、要靠 region 冗餘 + 多條 cellular network + 多個 event bus 路徑。對應 9.C24 Genesys 的 multi-region active-active。
3. 按 microservice ownership 切 MongoDB cluster、不要單一巨型 cluster：blast radius 邊界 = 業務邊界、不是「能不能撐」的問題。對應 9.5 瓶頸定位流程。
4. event-driven 處理 IoT 資料、不用 request-response：sensor 寫到 Kinesis / Kafka / event bus、microservice 從 stream 消費、寫進 MongoDB。這條 path 避免「sensor 寫不進去 DB 就 retry storm」的問題。對應 03 訊息佇列模組。

跨平台等效：

• AWS：MongoDB Atlas + Kinesis + Lambda（Toyota 配置）
• GCP：MongoDB Atlas on GCP + Pub/Sub + Cloud Functions、或 Firestore + Pub/Sub（document API native）
• Azure：Cosmos DB MongoDB API + Event Hubs + Azure Functions
• 跨雲：MongoDB Atlas 是 IoT 平台保留跨雲彈性的少數選項

下一步路由

• 想規劃 IoT / telematics 資料層 → MongoDB vendor page + 01.10 KV / Document DB 容量規劃
• 想做 multi-region 高可用性 → 9.C24 Genesys 99.999%
• 想對照不同 IoT 資料層選擇 → 9.C5 Amazon Ads DynamoDB（KV）/ 9.C26 PayPay（高頻訊息）
• 想理解 event-driven IoT 架構 → 03 訊息佇列模組
• 想做 IoT 寫入吞吐的 shard key 選型 → MongoDB shard key 選型
• 想規劃 telemetry schema design → MongoDB schema design pattern
• 想處理 IoT 高 client 數的 connection storm → MongoDB connection 管理與 cache 層

引用源

• Toyota Connected Aims For At Least 99.99% Availability With MongoDB Assistance
• Toyota Connected Reimagines Mobility on AWS
• MongoDB, AWS Help Toyota Connected Move Past Legacy Database Challenges
• Toyota Connected hails efficiencies from migration of data services to MongoDB Atlas
• Data Modeling Strategies For Connected Vehicle Signal Data In MongoDB

觀察

DoorDash 從 Aurora Postgres 遷到 CockroachDB 的關鍵敘述（引自 Why DoorDash migrated from Aurora Postgres to CockroachDB / The New Stack 報導）：

服務組合：Aurora Postgres（遷移前主要 OLTP）、CockroachDB self-hosted、自製 table extraction tool、自製 lossless migration pipeline。

關鍵負載形狀：DoorDash 是 規模化外送平台 — 訂單、Dasher 派遣、餐廳 menu、新業務（grocery / convenience）並存。寫入壓力來自訂單成立、status 變更、地圖位置更新等多種 hot write path。2020 疫情前流量已大、疫情後再翻倍、且高峰集中在週末晚餐 / 週日早午餐時段。

判讀

DoorDash 的工程選擇揭露三個 OLTP 寫入容量設計重點。

1. Aurora 的「single-primary 寫入」是規模化的天花板：Aurora 把 storage 跟 compute 分離、read replica 容易擴、但寫入仍走唯一 primary。1.636 M QPS 不是均勻分佈、是 hot table 集中寫爆。對應 01.6 高併發資料存取 的寫入容量規劃。CockroachDB 改成 Raft per range、每個 node 都能服務寫入、容量隨節點線性擴。
2. Migration 工具自製是先決條件、不是 nice-to-have：DoorDash 沒「一次性遷整套」、而是先寫工具把 table 從主 cluster 拆到獨立 Aurora cluster（紓壓）、再寫第二套工具把 Aurora → CockroachDB（換引擎）。兩階段都要 lossless + 可回退。對應 01.4 database migration playbook 的「先建工具、再遷資料」原則。
3. Cluster 數量增加、alert volume 卻下降：直覺反過來、cluster 多 = 維運面變大、應該更多 alert。但每個 CockroachDB cluster 內建 Raft 自動容錯、單節點 fail 不會 page on-call、Aurora 時代的「primary failover alert」消失。對應 04 可觀測性模組 的「告警 surface 設計」與 06.x reliability 的 graceful degradation。

需要警惕：1.636 M QPS 是 主 cluster 峰值、不是「DoorDash 全部寫入 QPS」。case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster」。讀案例時不要把這個數字當成「CockroachDB 撐 1.6 M QPS」的證據、它是 Aurora 在那個時間點撞牆的痛點。

策略

可重用的工程做法：

1. single-primary 撞牆前、先評估 multi-primary 選項：Aurora / RDS Postgres 是 single-primary 為主、寫入量持續成長最終會撞天花板。轉折點不是 IOPS、是 primary CPU + WAL flush rate。對應 9.5 瓶頸定位流程 的瓶頸辨識。
2. 遷 OLTP 引擎要走「兩階段紓壓」：先在原引擎內把 hot table 拆出（降低主 cluster 壓力、爭取時間）、再規劃換引擎（架構級改造）。直接「一次性換引擎」風險過高。對應 01.4 database migration playbook。
3. PostgreSQL wire protocol 相容性是降低遷移成本的關鍵：DoorDash 保留 PostgreSQL driver / ORM、應用層改動小。CockroachDB 不是 PostgreSQL fork、是 protocol-level 相容、實際 SQL 行為（serializable default、retry semantics、partial index）仍要驗證。對應 CockroachDB vendor 的 PostgreSQL 相容性 audit 段。

跨平台等效：

• AWS Aurora DSQL（2024）解同類「multi-primary 寫入」問題、但 AWS-only
• Spanner（GCP）同類設計、GCP-only
• TiDB（MySQL wire）解同類問題、亞洲生態深
• 自管 PostgreSQL + Citus（sharded extension）走 application 層 sharding、operation burden 較高

下一步路由

• 想理解 single-primary 寫入天花板訊號 → 9.5 瓶頸定位流程 + 01.6 高併發資料存取
• 想規劃 PostgreSQL → CockroachDB migration → 01.4 database migration playbook + CockroachDB vendor
• 對照其他 OLTP 規模化案例 → 9.C4 DraftKings Aurora（按業務切 cluster）/ 9.C23 Netflix Aurora consolidation（DB 種類整合）
• 想對照其他 distributed SQL 案例 → 9.C40 Netflix CockroachDB fleet / 9.C41 Hard Rock Digital
• 想理解全球一致性 OLTP 選型 → 1.11 全球分散式 OLTP
• 想拆 CockroachDB transaction retry 與 contention 模式 → CockroachDB transaction retry pattern
• 想對比 Aurora DSQL / Spanner / CockroachDB 的選型 → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Why DoorDash migrated from Aurora Postgres to CockroachDB
• How DoorDash Migrated from Aurora Postgres to CockroachDB（The New Stack）
• How We Scaled New Verticals Fulfillment Backend with CockroachDB（DoorDash Engineering Blog）
• DoorDash Uses CockroachDB to Create Config Management Platform for Microservices（InfoQ）

觀察

Netflix CockroachDB 艦隊的關鍵數字（引自 Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters / The history of databases at Netflix）：

服務組合：CockroachDB self-managed（Netflix Database Platform Team 自運維）、跨 AWS region、與 Cassandra / EVCache / RDS 並存（polyglot persistence）。

關鍵 workload：

• Studio Cloud Drive：影視製作資產的 file-system 風格服務、需要強一致 metadata + 全球可寫
• Open Connect 控制平面：Netflix 自有 CDN、控制全球網路設備、需要跨 region 一致 control state
• Spinnaker（持續交付平台）：deployment workflow state 需要 transactional 一致
• Maestro（ML / 資料 workflow orchestration）：scheduling 與 state machine 不容許 eventual consistency
• Gaming control plane：metadata 跨 4 region、region failure 不能 downtime

判讀

Netflix CockroachDB 艦隊揭露三個「補 Cassandra 缺口」的 OLTP 工程選擇。

1. Cassandra 不是 transactional 引擎、補位需求是工程現實：Netflix 2014 全面採用 Cassandra 解 global replication、但 lightweight transaction 跟 unreliable secondary index 在 studio / control plane 等場景出問題。2019 評估後選 CockroachDB 是因為它同時滿足 multi-active topology、global consistent secondary index、global transaction、open source、SQL — 五個條件 Cassandra 在 transactional 場景下湊不齊。對應 00 服務選型模組 的 polyglot persistence 與 01.5 transaction boundary。
2. 380+ cluster ≠ 「一個巨型 DB」：Netflix 是 artery of small DBs 模型 — 每個微服務 / 應用配自己的 cluster、cluster sizing 從幾個 node 到 60 nodes 不等。容量規劃變成「每個 cluster 各自規劃」、不是「全公司一個容量曲線」。對應 9.6 容量規劃模型 跟 9.C23 Netflix Aurora 的「微服務私有 store」哲學。
3. Multi-region 是「region failure 0 downtime」、不是「更快」：Netflix 60+ multi-region cluster 主要動機是 region-level survival、不是降 latency（跨 region quorum 反而會增 latency）。Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。對應 9.12 SLO 與 Performance Budget 的 latency vs availability 取捨。

需要警惕：

• case study 沒揭露單一 cluster QPS / latency 具體數字、只揭露 艦隊規模 跟 最大 cluster 容量。讀案例時不要把「380 cluster」直接換算成「Netflix CockroachDB QPS 上限」。
• Netflix 是 self-managed、不是 Cockroach Cloud — 需要專屬 Database Platform Team 養 380+ cluster。沒這量級團隊的組織直接 self-host 380 cluster 是 ops 自殺、Cockroach Cloud 才是合理路徑。

策略

可重用的工程做法：

1. 不要試圖一個 DB 撐全部：Netflix 同時用 Cassandra（高吞吐 eventual）、CockroachDB（transactional + global）、Aurora（單區 ACID）、EVCache（cache）。每種 DB 對應不同 workload 類型、不混用。對應 00 服務選型模組 的 polyglot persistence。
2. 每個 cluster 對應一個 application boundary：避免 multi-tenant 大 cluster、改用「per-app cluster」— 容量規劃顆粒對齊 application、爆掉時 blast radius 限縮在單一 app。對應 9.5 瓶頸定位流程 的 blast radius 設計。
3. Multi-region 用於 survival、不是 latency 優化：跨 region quorum 物理上必然增 latency。把 multi-region 動機釐清成 region failure 容忍、不要混淆「跨 region = 更快」。對應 1.11 全球分散式 OLTP 的 survival goal vs latency budget 取捨。
4. Self-managed 規模化需要專屬平台團隊：Netflix 有 Database Platform Team 養 380+ cluster — 包含 backup、upgrade、incident response、capacity review。沒這量級團隊就走 managed service。對應 9.7 成本邊界與 efficiency 的人力成本權衡。

跨平台等效：

• Spanner（GCP）解同類「global transaction + secondary index」、GCP-only
• DynamoDB Global Tables 走 eventual consistency、不是 Netflix 想要的 strong consistency
• Yugabyte / TiDB 是 distributed SQL 對等候選、生態深度與 PostgreSQL wire 相容度有差

下一步路由

• 想理解 polyglot persistence 選型 → 00 服務選型模組 + 9.C23 Netflix Aurora
• 想規劃 multi-region survival goal → 1.11 全球分散式 OLTP + CockroachDB vendor
• 對照其他 distributed SQL 案例 → 9.C39 DoorDash / 9.C41 Hard Rock Digital / 9.C10 Spanner
• 想理解 transaction vs eventual consistency 邊界 → 01.5 transaction boundary
• 想深入 CockroachDB survival goal 與 region failure 取捨 → CockroachDB survival goals
• 想規劃跨 region schema 與資料本地化 → CockroachDB locality-aware schema
• 想對比 Aurora DSQL / Spanner / CockroachDB → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters（PDF）
• Now Streaming: Why Netflix Runs a Fleet of 380+ CockroachDB Clusters（cockroachlabs.com Netflix customer page）
• The history of databases at Netflix: From Cassandra to CockroachDB
• A Netflix RoachFest24 Original: The Case for Multi-Region Clusters
• How Netflix engineers choose their tech stack

觀察

Hard Rock Digital sportsbook 部署的關鍵數字（引自 Hard Rock Digital customer page / How Hard Rock Digital built a highly available and compliant sports betting app）：

服務組合：CockroachDB self-managed、AWS US-East-1（共用 control plane）、AWS Outposts（部分州合規要求設備位於州內）、AWS Local Zones（特定都會區延遲補強）。

關鍵 workload：bet placement、bet settlement、account management、cache loading、sports metadata import。

關鍵負載形狀：sports betting 是 event-driven peak — Super Bowl / World Cup 等賽事是已知時間點、流量在開賽前 30-60 分鐘飆升、賽中持續高水位、賽後 settlement 集中爆發。「100 → 33 → 100」的 scale up / down 反映賽季 vs 淡季的容量需求差。

判讀

Hard Rock Digital 的工程選擇揭露三個受監管 OLTP 的設計重點。

1. 法規顆粒決定基礎設施拓樸、不是反過來：美國 Wire Act 要求 betting data 必須在下注州內處理、所以每個營運州都要有州內運算資源。傳統路徑是「每州一個獨立 silo」— 但 silo 之間的玩家統一帳戶、跨州 reporting、欺詐偵測會撞牆。Hard Rock Digital 用 AWS Outposts 把運算放進州內、但邏輯上仍是 一個 CockroachDB cluster — region placement 配置決定哪些 range 釘在哪個 Outpost、合規與單一邏輯 DB 同時成立。對應 01.4 database migration playbook 的合規 boundary 設計與 1.11 全球分散式 OLTP 的 region placement。
2. Survival goal 「Outpost 或 AZ 失敗不丟」對應業務 SLO：sports betting 中 bet placement 不能 lose — 玩家下注後系統 crash 沒紀錄、對博彩牌照是合規事故。CockroachDB Raft 3-replica + 跨 AZ 配置讓 Outpost 失敗時其他 replica 還在、自動 failover。對應 06 reliability 的 RPO=0 設計與 CockroachDB vendor 的 Survival Goals。
3. Scale up / down 是賽季常態、不是異常事件：100 → 33 → 100 的擺盪在 sportsbook 業務是 年度循環 — NFL 季結束 / NBA 季初切換、流量結構性下降。CockroachDB 加減節點靠 range rebalance、不停服。對應 9.6 容量規劃模型 的 seasonality 與 9.11 高峰事件準備 的 event-driven scaling。

需要警惕：

• case study 沒揭露 QPS、p99 latency 具體數字。100 node × 32 vCPU 是硬體規模、不是 throughput。讀案例時要區分 容量 sizing（節點數）跟 workload throughput（每秒處理量）。
• 「省了 10-20 工程師」是 估計差距、不是已 hire 後解雇。對應的是「沒選 PostgreSQL 所以沒招那麼多 DBA」、是機會成本不是節省支出。
• Wire Act 是 美國聯邦法、各州還有獨立法規（NJ DGE、NV NGC 等）。Hard Rock Digital 模型適合 跨州 合規、不是 跨國 — 跨國牌照差異更大、不能直接套。

策略

可重用的工程做法：

1. 合規 boundary 用 region placement 表達、不是 cluster fragmentation：當法規要求資料留某地理邊界、優先看 distributed SQL 的 region placement / pin-to-region 能力、不要直接開獨立 cluster。獨立 cluster 解了合規但破壞了業務邏輯（跨州統一帳戶、欺詐偵測、reporting）。對應 CockroachDB vendor 的 multi-region table 與 Spanner vendor 的 placement。
2. 邊緣硬體（AWS Outposts / Local Zones）是合規工具、不是 latency 工具：Outposts 主要為「資料留某地理邊界」而存在、latency 改善是副作用。決策時先看合規驅動力、latency 改善列為 bonus。對應 05 部署平台模組 的 hybrid cloud 設計。
3. 賽季型擴縮容寫進 baseline 容量模型：Hard Rock Digital 100 ↔ 33 的擺盪不是「臨時 scale up」、是計畫內年度循環。容量規劃要直接把 NFL / NBA / 國際賽事曆塞進預測模型、不要當 surprise。對應 9.6 容量規劃模型 與 9.C2 GR8 Tech 體育博彩 AI 預測。
4. distributed SQL 的 ops 槓桿：team 小、cluster 大：Hard Rock Digital 50 人 tech team 養全部運維、估省了 10-20 個 DBA。distributed SQL 把「DBA 養單區、跨區 sync 養運維」的工作量壓進 系統內建 的 Raft / placement、人月支出降。對應 9.7 成本邊界與 efficiency 的人力成本工程化。

跨平台等效：

• Spanner（GCP）也支援 region placement、但 GCP-only、無 Outposts 等效
• Aurora DSQL（AWS 2024）支援跨 region 強一致、但 Outpost 部署現階段未完整覆蓋
• 自管 PostgreSQL + application 層 sharding：理論可行、operation burden 跟人力需求大幅上升、Hard Rock Digital 評估後選 CockroachDB 的主因之一

下一步路由

• 對照其他受監管金融 / 博彩 OLTP → 9.C14 Standard Chartered（銀行國家層級）/ 9.C4 DraftKings（fantasy sports）
• 對照 event-driven peak 設計 → 9.C2 GR8 Tech / 9.C28 FanDuel
• 想規劃 multi-region OLTP survival goal → 1.11 全球分散式 OLTP + CockroachDB vendor
• 對照其他 distributed SQL 案例 → 9.C39 DoorDash / 9.C40 Netflix / 9.C10 Spanner
• 想理解合規驅動的拓樸設計 → 05 部署平台模組 + 01.4 database migration playbook
• 想拆 CockroachDB survival goal 與合規拓樸對齊 → CockroachDB survival goals
• 想做 region pinning 與在地化 schema → CockroachDB locality-aware schema
• 想對比 Aurora DSQL / Spanner / CockroachDB 給博彩 OLTP → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Hard Rock Digital: scaling a performant sports betting platform（cockroachlabs.com customer page）
• Hard Rock, anytime, anywhere: scaling a performant sports betting platform（PDF case study）
• How Hard Rock Digital built a highly available and compliant sports betting app
• Building a sports betting application to handle ‘Big Game’ traffic
• CockroachDB for Gambling solutions page