服務定位

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

本文是跨 vendor migration playbook、cross-link HashiCorp Vault 跟 AWS Secrets Manager。本文同時是 #128 self-aware limitation 第 1 點「6 維仍可能漏類（identity / consistency / residency 三軸候選）」的 identity 軸驗證。

「secret」不是「secret」：兩家對「secret」的定義不同

把 Vault → AWS Secrets Manager 當成「secret store 替換」是最常見的誤判 — 兩家的「secret」概念跨完全不同的 identity model：

核心差異不在「存 secret 的地方」、在「身份從哪來、怎麼 enforce、怎麼 audit」。 Migration 的真實工作量在 identity model 重設計、不是 secret 搬遷。

跑 6 維 diff dimension audit：

6 維 audit 抓不到「Identity model = High」這軸 — 用既有 6 維歸類、會走 Type C operational redesign + Application change 高維獨立段；但實際工作量分佈：

• Operational redesign（vault cluster 拆 / Lambda 配 / 監控換）：~25%
• Application change（SDK / retry / token 換 IAM credential）：~30%
• Identity model 重設計（每個 secret 對應的 principal / policy / 跨 service auth chain）：~45%

最大工作量塊在 identity model 重設計、不在既有 6 維任一個。Identity 是 候選的第 7 維。

Identity axis 是否獨立：4 個論據

Yes、identity 是獨立軸：

1. Identity 不變 → operational 仍可變：Vault on-prem → Vault on-EKS、operational 變 high 但 identity model 不變（仍 Vault token）；可分開 audit
2. Operational 不變 → identity 仍可變：Vault namespace 重組（管理 50 個 namespace → 5 個 namespace + namespace-level policy）、operational 不變但 identity boundary 重劃；可分開 audit
3. Application change 不變 → identity 仍可變：純 infrastructure-level rotation（手動 → 自動）、application code 不變但 identity issuance flow 變；可分開 audit
4. Paradigm 不變 → identity 仍可變：同樣是 secret store paradigm、Vault token vs IAM principal 是 identity model 差、不是 paradigm 差

No、identity 可塞 application change：

• 反論：application code 改 SDK + IAM signer 都算 application change
• 拒絕：application change 是 consequence、不是 root cause；identity model 變動才是驅動 application change 的原因

實證上、本文 migration 工作量 45% 在 identity 對位、確認 identity 是 獨立的工作量主軸、不該被壓進 application change 軸。

結構：Type C + identity model 對位獨立段

跟既有 Type C PostgreSQL → Aurora 對照、本文多出 identity model 對位 獨立段：

11. 「secret」不是「secret」（identity axis paradox 開頭）
22. Identity axis 是否獨立的論據
33. 結構 differentiator（Type C + identity 獨立段）
44. Identity model 對位（Vault → AWS principal mapping）
55. Operational migration（4 phase）
66. Application change（SDK + retry pattern）
77. Production 故障演練
88. Capacity / cost
99. 整合 / 下一步

9 章節、260-280 行。比標準 Type C 多 1 段（identity model 對位）+ 1 段（axis 獨立論據）。

Identity model 對位

 1Vault concept                    →  AWS Secrets Manager 對應
 2─────────────────────────────────   ────────────────────────────
 3Vault token (auth 結果)           →  AWS STS temporary credential
 4AppRole (auth method)             →  IAM role + AssumeRoleWithWebIdentity
 5Kubernetes auth method            →  IAM Role for Service Account (IRSA)
 6LDAP auth method                  →  IAM Identity Center (formerly SSO)
 7Vault policy (capabilities)       →  IAM policy + Resource policy
 8Path-level ACL (secret/db/*)      →  Resource ARN pattern (arn:aws:secretsmanager:...:secret:db/*)
 9Namespace                         →  AWS account + resource-based isolation
10Audit device                      →  CloudTrail event
11Database secrets engine           →  Lambda rotation function

每行對位都有 語意差、不是 1:1 mapping：

• Vault token TTL vs AWS STS credential expiration：Vault token TTL 可由 application 主動 renew；STS credential 不能 renew、必須 re-assume
• Vault policy capabilities vs IAM action：Vault read capability 對應 AWS secretsmanager:GetSecretValue、但 AWS 還要 resource policy 允許；雙層授權
• Vault Kubernetes auth vs IRSA：兩者都是 K8s service account → secret access、但 IRSA 需要 EKS + OIDC provider 設置、Vault K8s auth 不需要

Migration scope 包含每行對位的 application-level 適配、不是 secret 搬。

Operational migration (4 phase)

Phase 0：Audit + design

• 列所有 Vault secret + path + 使用 application
• 每個 secret 對應 AWS principal（IAM role / IRSA / federation）
• 設計 ARN 命名規則（按 namespace / application / environment）
• 規劃 AWS account boundary（dev / staging / prod 分 account）

Phase 1：AWS Secrets Manager + IAM 設置

• Terraform / CloudFormation 建 secret + IAM role + resource policy
• 設 IRSA / WebIdentity provider
• 預先建 staging secret、跑 application test

Phase 2：Application dual-read

1# Application 同時讀 Vault + AWS Secrets Manager
2def get_db_password():
3    aws_value = boto3.client('secretsmanager').get_secret_value(SecretId='myapp/db')['SecretString']
4    vault_value = vault_client.read('secret/data/myapp/db')['data']['data']['password']
5
6    if aws_value != vault_value:
7        logger.warning(f"Secret diff between Vault and AWS!")
8
9    return aws_value  # Use AWS as source of truth

跑 1-2 週、確認兩端一致 + AWS API latency / error rate 接受。

Phase 3：Cutover + cleanup

• Application 端切到 AWS Secrets Manager only
• Vault read-only 1-2 週 standby
• 之後 decommission Vault cluster

Application change

Application 端必改的 4 個 pattern：

1# Before: Vault SDK
2import hvac
3vault_client = hvac.Client(url='https://vault.internal', token=vault_token)
4secret = vault_client.read('secret/data/myapp/db')['data']['data']['password']
5
6# After: AWS SDK + IAM
7import boto3
8sm = boto3.client('secretsmanager')
9secret = sm.get_secret_value(SecretId='myapp/db')['SecretString']

關鍵差異點：

• Authentication：Vault token 由 application 自管 / refresh；AWS SDK 自動處理 STS credential（透過 IAM role / instance profile / IRSA）
• Caching：Vault secret read 通常 cache 5-15 分鐘；AWS Secrets Manager 有 cache library（aws-secretsmanager-caching-python）需顯式啟用
• Retry pattern：Vault 用 exponential backoff；AWS SDK 自帶 retry but boto3 default 跟 application requirement 不一定 match
• Rotation hook：Vault 用 SDK 端 lease renewal；AWS 用 Lambda rotation function、application 端只需要 re-read

Production 故障演練

Case 1：IAM principal 對位錯、production application 拿不到 secret

徵兆：cutover 後 application 啟動失敗、log 顯示 AccessDeniedException: User: arn:aws:sts::...:assumed-role/EKS-NodeRole/i-xxx is not authorized to perform: secretsmanager:GetSecretValue。

根因：EKS pod 用 node role 而非 pod IRSA role；Phase 0 audit 沒設 service account 對應的 OIDC trust。

修法：

1. 預先設 IRSA：建 IAM OIDC provider for EKS、設 service account annotation
2. 驗證 principal：aws sts get-caller-identity 從 pod 內跑、確認 returned role 是預期的
3. Resource policy + IAM policy 雙層：確認 secret 的 resource policy allow 該 role、IAM policy 也 allow

Case 2：Dynamic credential 對等失敗、application 連 DB 失敗

徵兆：Vault 端用 database secrets engine 自動 rotate DB password、application 透過 Vault SDK 拿 lease；切到 AWS Secrets Manager + Lambda rotation 後、Lambda rotation 完成、但 application 端仍用 cached old password、連 DB 拒絕。

根因：Vault SDK 自帶 lease renewal logic、application 知道 password 即將過期會主動 re-read；AWS SDK 沒 lease 概念、application 自己決定多久 re-read 一次。

修法：

1. 設 cache TTL 短於 rotation interval：rotation 24 小時、cache TTL 1 小時、最壞情況 1 小時 stale
2. 顯式 cache invalidation：rotation Lambda 跑完發 SNS、application subscribe 主動 refresh
3. Connection-level retry：DB connection 認證失敗時 application 重 fetch secret 跟重連
4. 重新評估 rotation cadence：AWS Lambda rotation 不是 Vault dynamic、是 scheduled rotation；不能假設兩者同 semantic

Case 3：Audit log 結構差、SOC dashboard 失效

徵兆：cutover 後 SOC 端 dashboard 顯示 secret access metric 全 0；舊 Vault audit log 結構在 Splunk 端 parse 過、AWS CloudTrail 結構完全不同、search query 全失效。

根因：Vault audit log 是 Vault-specific JSON 結構（含 lease_id / policy / token）；CloudTrail event 是 AWS-specific（含 eventName / requestParameters / userIdentity）；SOC parse rule 不能搬。

修法：

1. Pre-cutover 重寫 SOC rule：CloudTrail event 對應 Vault audit log 的 detection coverage 必須 1:1 mapping
2. GuardDuty integration：AWS GuardDuty 自動 surface secret access anomaly、降低自寫 rule 工作量
3. CloudTrail → S3 → Athena：long-term audit query 走 Athena、tooling 跟 Vault 完全不同、SOC re-training

Case 4：Calling cost 反轉、AWS 比 Vault 自管貴

徵兆：Vault on-prem 跑了 $200 / month（EC2 + ops），切到 AWS Secrets Manager 後 $1500 / month；帳單拆解後 GetSecretValue API call 是大頭。

根因：AWS Secrets Manager $0.05 per 10K API call — application 高頻 read（每 request 都讀 secret + 沒 cache）會爆 cost；Vault 端 application 自管 cache + token TTL 內無 API call。

修法：

1. 強制 application-side cache：用 aws-secretsmanager-caching library、cache TTL 5-15 分鐘、API call 從 100M/month 降到 10K/month
2. Re-architect application：把 high-frequency secret read 改 connection-level（建 DB connection 時讀一次、connection lifecycle 內復用）
3. Cost monitoring：對 secret access 設 CloudWatch alarm、過 threshold 立即 alert

Case 5：跨 region replication 對位失敗、DR 演練失效

徵兆：DR drill 切 region 後、application 連不到 secret；發現 us-west-2 的 Secrets Manager 沒有 us-east-1 的 secret。

根因：AWS Secrets Manager 不是 global resource、是 region-scoped；Vault 自管 multi-DC replication；cutover 漏設 cross-region replication。

修法：

1. 設 secret replication：AWS Secrets Manager 內建 replication 到其他 region（ReplicaRegions）
2. DR drill 必跑：cutover 前 + cutover 後各 drill 一次、驗證 region failover 順
3. 架構：考慮用 AWS Backup 對 Secrets Manager 做 cross-region backup 補強

Capacity / cost

判讀：少 secret + 中頻 read 走 AWS Secrets Manager；高頻 read + multi-cloud / on-prem 約束走 Vault。

整合 / 下一步

跟 Vault Dynamic Credential 對比

Vault dynamic credential 是 Vault 特有 feature、AWS Secrets Manager 用 Lambda rotation 對應、但 semantic 不同：

• Vault: per-application lease、application-aware lifecycle
• AWS: scheduled rotation、application 不知道何時被 rotate

Migration scope 應該 降級 dynamic credential 場景、用 Lambda rotation 替代、application logic 改 cache + retry pattern。

跟 IAM Identity Center 整合

人類存取 secret（emergency break-glass）走 IAM Identity Center + temporary role assumption；不要直接給 user IAM key。

下一步議題

• Reverse migration（AWS → Vault）：通常是 multi-cloud / on-prem 約束驅動、cost 在大 scale 反轉
• Hybrid pattern：cloud-native secret 走 AWS、cross-cloud / on-prem secret 走 Vault；應用程式根據 secret 來源 routing
• identity axis 驗證：本文認為 identity 是獨立軸、未來累積 LDAP → OIDC / 自管 RBAC → IAM 等 migration 驗證

相關連結

• Source vendor：HashiCorp Vault
• Target vendor：AWS Secrets Manager
• 平行 deep article：Vault Dynamic Credential
• 平行 migration playbook (Type C)：PostgreSQL → Aurora（標準 Type C） / MongoDB → Atlas
• 平行 axis 候選驗證 (sibling)：DynamoDB Consistency Model（consistency 候選） / PostgreSQL Multi-Region GDPR Rollout（residency 候選）
• Methodology：Migration playbook methodology / #128 self-aware limitation 第 1 點（identity axis 候選驗證、本文是該驗證的 dogfood）