"Aurora"
- MySQL → Aurora MySQL：storage layer 轉手到 AWS、replication / HA / backup 全部 outsource
自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit（Operational High）、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。
- Aurora Storage Architecture：quorum-based 分散式 log 與韌性即性能設計
Aurora storage / compute 分離、6-way 跨 AZ replication、4-of-6 write / 3-of-6 read quorum、韌性投資自動 amortize 成 read 性能、DraftKings 6ms 寫 / <1ms 讀 production reference
- Aurora Serverless v2 適用判斷：ACU 自動擴縮、混合 cluster 與何時不該用
Aurora Serverless v2 不是「比較便宜的 Aurora」；本文展開 ACU 計費粒度、秒級自動擴縮機制、min/max ACU 設定、serverless 與 provisioned 同 cluster 混用，以及穩定高負載下 serverless 反而更貴的成本 crossover 邊界
- Aurora 多 cluster 按業務切分：微服務私有 store、blast radius 隔離與 fleet 治理
把所有服務塞進一個大 Aurora cluster 會讓單一服務的查詢拖垮全部；本文展開按業務 / 微服務切 cluster 的判斷維度、blast radius 隔離、共用 vs 分離的成本與運維 surface 權衡，以及多 cluster fleet 的治理一致性，含 Netflix Aurora consolidation 對照
- Aurora RDS Proxy 與連線管理：connection multiplexing、pinning 陷阱與 failover 加速
RDS Proxy 不是「連上去就自動省連線」；本文展開 connection multiplexing 機制、哪些 session 操作會觸發 pinning 讓 multiplexing 失效、failover 期間 proxy 如何保持 client 連線縮短中斷，以及 RDS Proxy 與自管 pgbouncer 的責任切分
- Aurora PG/MySQL vs Aurora DSQL 取捨：何時 single-region managed 夠用、何時跨到 distributed
Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm；本文聚焦『standard Aurora（single-region managed SQL）什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策，切分『怎麼遷』（migrate-to-aurora-dsql）與『DSQL vs Spanner vs CockroachDB 三方選型』（decision-tree）兩個既有 SSoT
- Aurora Cross-AZ Failover：RTO 量測、endpoint routing 與 application reconnect 契約
Aurora cross-AZ failover lifecycle（detection / promotion / DNS update）、< 30 秒 RTO、application DNS cache 跟 connection pool 對齊、Standard Chartered 受監管場景為什麼用獨立 cluster 而非 Global Database failover
- PostgreSQL → Aurora Migration：protocol 相容、operational 重設計
Aurora 號稱 PostgreSQL-compatible 但 operational model 不同（storage decouple / cluster endpoint / instance class / 自家備份）；遷移流程是混合（protocol drop-in + operational phased）、5 個 production 踩雷（extension 不支援 / replication slot 不直通 / autovacuum 行為差 / IAM 認證強制 / cost model 換算）、跟 Patroni / read replica / DR 對位
- Aurora Read Replica Scaling：15 replica 上限、lag profile、headroom 預留與 fleet 治理
Aurora 15 replica 上限、共享 storage 為什麼能養大量 replica、事件型容量分級表、DraftKings headroom 預留判讀、FanDuel 雙 SLO 並行、fleet 治理 3 條 driver（business sharding / microservice / 合規）
- Aurora Global Database：跨 region async replication、< 1 秒 lag 與合規 anti-recommendation
Aurora Global Database 跨 region storage-level async replication、< 1 秒 typical lag、planned vs unplanned failover RTO 數量級對比、Standard Chartered 合規禁止跨境複製為什麼讓 Global Database 變反指標
- 從自管 PostgreSQL / MySQL 遷到 Aurora：operational redesign migration playbook
PostgreSQL / MySQL → Aurora 的 Type C operational redesign hybrid playbook、6 規格面（Driver / Diff audit / Phase plan / Evidence / Cutover / Cleanup）、Standard Chartered 合規 lead time 模型、Netflix 非 all-purpose store 邊界
- Aurora PostgreSQL I/O-Optimized Cost
Aurora PostgreSQL Standard 與 I/O-Optimized 的成本模型、I/O 壓力、workload 判斷、遷移與回退條件