接管的操作順序是：先拍下現況（盤點）、再理解結構（依賴）、再收斂風險（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 收斂的完整設計
• → 團隊權限分級與存取管理：接手後重新建立權限分級

為什麼需要這張對照地圖

兩種使用情境會需要這張表。第一是初次選型時，讀者已經選定主要雲廠商，要對照各能力分類找出 vendor 名稱。第二是跨雲遷移評估，讀者要對照源端跟目標端的能力 gap。沒有這張表，每次都要重新查文件、容易漏掉某個能力。

但這張表不能取代深入評估。每個 vendor 都有不在表格內的差異，例如配額、區域可用性、跨服務整合、計價模型。表格是路由起點，後續判讀要進到該 vendor 的 deep article。

能力 × 雲廠商對照表

這張表以全球 hyperscaler 三巨頭為主、不是市場全貌。Oracle Cloud (OCI) 在 enterprise / Java workload 跟金融受監管環境有顯著市佔；Alibaba Cloud 在亞太 / 跨境電商是主流；IBM Cloud 在金融 / 受監管環境仍存在；Hetzner / DigitalOcean / Vultr 在 cost-leader 區段提供完全不同的計價模型；Sovereign cloud（GDPR Schrems II 後在歐洲、JEDI / JWCC 在美國政府）是另一條獨立軸、跟資料主權合規綁定、比較對象不在這張表內。對照判讀邏輯（「對應 ≠ 等價」）可以同樣套用、但具體 vendor 名稱與差異維度要按目標廠商各自查證。

三家雲共同缺的能力分類

對照表覆蓋的能力都有 vendor 直接對應，但有兩類能力三家雲廠商都沒有提供等價的原生服務，要靠第三方工具補完。把這兩類獨立成段，避免在對照表中用「（無原生）」填空造成模板化。

壓測 / 流量重放：三家雲都沒有像 RDS 對 PostgreSQL 那樣的「managed 壓測服務」。團隊要從 k6、JMeter、Gatling、Locust、Vegeta、AWS Distributed Load Testing（這是 reference architecture 而非 managed service）這類第三方工具選擇。選型考量在於：是否支援該團隊熟悉的腳本語言（k6 用 JS / Gatling 用 Scala / Locust 用 Python）、能否分散執行、能否在 CI 整合、能否重放 production traffic（GoReplay、AWS VPC Traffic Mirroring）。各工具的選型細節見 9.3 壓測工具選型。

事故管理 / on-call 通知：三家雲都沒有原生的 incident management 平台。CloudWatch / Cloud Monitoring / Azure Monitor 只到 alert 層、不負責 escalation、on-call rotation、incident timeline 與 retrospective。這層責任目前由 PagerDuty、Opsgenie、Splunk On-Call（前 VictorOps）、Grafana OnCall 等第三方平台承擔。三家雲提供的 alert 可以 webhook 到這些平台，但 incident workflow 本身不在 cloud vendor scope 內。事故管理流程見 08 事故處理模組。

辨識這兩類「跨雲共缺」能力的價值在於：跨雲遷移時這兩層不會增加 vendor lock-in，可以保留現有第三方工具直接接到新雲；反之，cloud-native incident management 或 cloud-native 壓測這類規劃要在採購前確認是否真實存在，避免被命名類似的工具誤導。

「對應 ≠ 等價」的具體差異範例

對照表只給名稱對應，實際選型要看差異細節。下面四個常見的差異維度示範如何把名稱對應翻成選型判讀。

失效切換時間差異（RDS vs Cloud SQL vs Azure SQL）

同樣是 managed PostgreSQL，三家 vendor 文件給的 failover 時間參考值差距明顯。下列數字以各雲廠商公開文件為基準、實測長尾可能拖到更長：

• AWS RDS Multi-AZ：vendor 文件寫「typically 60–120 seconds」、P99 實測可達數分鐘
• AWS Aurora：vendor 文件寫「typically less than 30 seconds」、實測 30–90 秒常見
• GCP Cloud SQL HA：vendor 文件寫「1–2 minutes」
• Azure SQL Business Critical：vendor 文件寫「around 30 seconds」、實測 30–60 秒

選擇關鍵不是「哪個快」、而是「業務能容忍多少 downtime」。30 秒對 banking、ticketing 是不能接受的；對內部後台是無感的。失效切換時間直接影響 SLO 設定跟業務連續性 — 數字以 vendor 公開文件為參考、實際決策時要用該 vendor 自己的 SLA 條款跟 incident report 驗證。

一致性模型差異（DynamoDB vs Firestore vs Cosmos DB）

三家的 NoSQL 在一致性語意上分歧：

• DynamoDB：預設 eventual consistent read、可選 strongly consistent read（成本 2 倍）
• Firestore：strongly consistent read 是預設、跨 region 用 multi-region 配置
• Cosmos DB：五種一致性等級可選（strong / bounded staleness / session / consistent prefix / eventual）

如果應用程式假設「寫完馬上能讀到」（read-after-write），在 DynamoDB 預設模式下會撞牆。在 Cosmos DB 選 session consistency 可以保證單一 client 內 read-after-write、跨 client 仍是 eventual。這類差異要在選型階段對齊，不是事後改 code。

計價模型差異（Lambda vs Cloud Functions vs Azure Functions）

三家的 serverless 在計價單位有差異：

• Lambda：請求數 + 執行時間 (GB-秒)
• Cloud Functions：請求數 + 執行時間 + 網路流量
• Azure Functions：執行次數 + 執行時間 + 記憶體（Consumption Plan）或固定費用（Premium / Dedicated Plan）

對於低流量服務、三家差異不大；對於高頻率短時間函式、計價差異可能放大數倍（具體倍數視 memory size / 執行時間 / 流量分布、用 vendor calculator 算）。選型時要用實際 workload 估算、不能看單位價格表面數字。

跨服務整合差異（消息佇列 vs 觸發器）

AWS SQS + Lambda 整合非常成熟、有 native trigger；GCP Pub/Sub + Cloud Functions 同樣 native；Azure Service Bus + Functions 也有 trigger，但細節（dead-letter 處理、retry 策略、batch size）跟前兩家有差異。

跨服務的整合成熟度通常會在事故時放大差異。同樣的事件處理流程，在 AWS 上 90% 用 native 路徑、在另一家可能需要 30% 自己寫 glue code。

跨雲遷移的判讀重點

把這張對照表反過來讀，就是跨雲遷移的 gap 分析起點。但實際遷移要看四類風險：

第五類風險常被低估：以 AWS S3 為例、egress 約 $0.09/GB、PB 級資料即 $90k 帶寬費；GCP / Azure 同等級。跨雲遷移最大單筆成本經常是 data gravity、需要先決策資料拓樸再算其他三類風險。

跨雲遷移不是把服務名稱換掉就完成。每一個對應都要做 deep audit，這是 01 大規模 DB 遷移實戰 等模組的責任。

混合雲與多雲的情境

常見的混合或多雲組合：

• 資料留 AWS、ML 跑 GCP：因為 BigQuery、Vertex AI 在資料分析優勢
• 主要 Azure、ML 跑 AWS：因為 SageMaker 跟 Bedrock 提供的選項
• DR 在另一家雲：主要在 AWS、DR 站在 Azure 避免單一雲廠商故障

混合 / 多雲要解的核心問題是跨雲流量成本（egress）跟身分聯邦（cross-cloud IAM）。這兩個成本通常被低估，要在規劃階段就做進 cost model。

對照表使用的判讀順序

讀這張表時，避免以下兩種誤用：

第一是「看完表格就決定 vendor」。表格只給名稱對應，沒給選型理由。先確認自己的能力需求（容量、一致性、failover 時間、計價型態），再用表格找候選 vendor，再進該 vendor 的 deep article 驗證細節。

第二是「把『對應』當作可互換」。已經提到的失效時間、一致性語意、計價模型差異會直接影響業務。在做技術選型時不能假設「換家雲就行」，要驗證每一條差異。

正確的使用順序：能力需求 → 對照表找候選 → vendor deep article 驗證 → cost / failure / consistency 驗算 → 決策。

判讀訊號

常見誤區

把 vendor 對照表當「採購清單」，看完直接照表選。選型必須回到需求，不是看哪家有對應名稱就選。

把雲廠商當「commodity 商品」，假設換家就好。三家的整合生態、配額限制、計價單位都有差異、遷移成本經常被嚴重低估（特別是 data gravity / IAM / 監控重建這三類隱性成本）。

把單一雲廠商當「永遠不會變」。雲廠商會調整定價、棄用服務、改 API。設計時要有抽象邊界，避免直接綁定 vendor SDK 到業務邏輯，方便未來換家或多雲。

定位邊界

本章預設「自建於雲端基礎設施」已成立；讀者若在對照表看到 Firestore 而想問「乾脆整個用 Firebase？」、那是 BaaS / 託管平台層的交付形態判斷、見 0.21 交付形態選型。

本章專注「能力分類到 vendor 名稱的翻譯與對應差異」。當問題進入具體 vendor 配置（例如 RDS 怎麼設 backup）、跨 vendor 遷移流程（例如從 MySQL 遷到 Aurora），分別交給各模組的 vendors/ 目錄跟 migration playbook。當問題進入需求分類（這個業務需要強一致還是最終一致？）回到 0.0 後端需求分類地圖。

案例回寫

雲端服務選型可用以下案例回寫：

• 0.14 企業選型案例圖譜 — 0.14 收錄不同產業、不同規模階段企業的雲端選型決策；對照本章「跨雲遷移的判讀重點」段：合規、計價、IAM 整合是三家雲決策的主要分歧軸。
• 9.C20 Zomato：TiDB 遷到 DynamoDB — Zomato 把 SQL 介面（TiDB）換成 KV 介面（DynamoDB）、用一致性語意差異換取 4 倍吞吐 + 50% 成本；對照本章「對應 ≠ 等價」段中的一致性模型差異子段。
• 9.C23 Netflix：Aurora consolidation — 案例是 AWS 內 DB 種類整併（多 RDB → Aurora），可對照本章「對應 ≠ 等價」段中的計價模型與整合成熟度差異。雖然不涉及跨雲，但在同一家雲廠商內整併服務、跟跨雲整併共用同一條決策邏輯：權衡 vendor lock-in 代價 vs 運維碎片化代價。
• 5.C1 Tradeshift：self-managed K8s → EKS — Tradeshift 從自管 K8s control plane 遷到 EKS managed control plane、運維責任邊界從「整套 cluster」收斂到「workload + worker node」。對照本章「容器執行平台」對照行：managed 程度是同一能力分類下的主要分歧軸。

這些案例回答的是不同問題、不是同一個問題的不同切面。對照表本身只回答「叫什麼名字」；Zomato / Tradeshift 補「換掉名字後實際差多少」（介面 / 計價 / 一致性差異）；Netflix Aurora 補「同一雲內怎麼收斂」；0.14 補「真實企業在什麼壓力下選什麼」。讀者按手邊的問題進入對應案例、不需要也不適合串成同一條 narrative。

跨模組路由

1. 與 0.1 後端服務能力地圖 的交接：先確認能力分類，再用本章找 vendor 對應。
2. 與 0.6 成本、風險與選型取捨 的交接：cost model 是 vendor 選型的關鍵維度。
3. 與各模組的 vendors/ 目錄的交接：對照表只給名稱、deep article 給配置與運維。
4. 與 01 大規模 DB 遷移實戰 的交接：跨 vendor 遷移的具體流程。

下一步路由

對照表是查 vendor 名稱的第一層、進入細節要走 deep article：

• 實際企業選型案例 → 0.14 企業選型案例圖譜
• 資料庫 vendor 細節對比 → 01 模組 vendors/
• 部署平台 vendor 細節對比 → 05 模組 vendors/

本章不在規模成長路線上、是 sibling 工具型入口。要進規模成長路線、從 10.1 服務拆分 或 9.13 擴展軸 開始。

來源

Defender Pressure

Control Gap

控制缺口的核心是身份信任根的生命週期管理。當 signing key 缺少自動輪替與退役監控,且 token validator 接受跨類型金鑰時,單一遺留金鑰會升級成跨租戶風險。

Detection Route

Exercise Hook

本案例可支撐 Identity support token tabletop 的雲端變體。演練重點是確認團隊能在雲端供應商通報後,快速判讀受影響 tenant、收集 audit log 並協調金鑰相關 session 收斂。

Write-back Target

• 7.2 身分與授權邊界
• 7.B11 Vulnerability Response State Machine
• Control owner pattern
• Evidence chain pattern