本文是 AWS ElastiCache overview 的 implementation-layer deep article。選型層（為何用 managed、engine 選擇、跟自管取捨）見 overview；本文只處理「決定用 ElastiCache 後，哪些是 AWS 的責任、哪些仍是你的」。CLI 與計費以 AWS ElastiCache 官方文件、ElastiCache 定價 為準、最後檢查日 2026-06-16（managed 服務的引數與價格會變、以官方為準）。

managed 不等於 hands-off

把 cache 換成 ElastiCache 之後，最危險的心態是「現在 AWS 全包了」。AWS 確實接走了一大塊運維——它幫你做 failover、patching、snapshot、跨 AZ 複製，你不用再自己部署 Sentinel、不用半夜起來手動切 master。但有一類問題 ElastiCache 一個都沒幫你解，而且因為「以為 AWS 會處理」，這些問題在 managed 環境反而更容易被忽略到上線才爆。

Tinder 的配對引擎跑在 ElastiCache for Valkey 上、4700 萬月活、sub-millisecond 延遲——這證明 managed 撐得起極大規模，但 Tinder 仍要自己設計 key、處理 cache miss、控制 client 行為。ElastiCache for Redis 7.1 在 r7g.4xlarge 上單 node 可達約 100 萬 RPS、單 cluster 約 5 億 RPS（引自 AWS Database Blog）——這個吞吐是 AWS 給的，但用不用得好取決於你的 key 分布與 client 設計。

理解 ElastiCache 就是劃清這條責任邊界。本文按 shared responsibility 展開：AWS 管什麼、你管什麼、邊界上的踩坑在哪。

核心概念：shared responsibility 的兩側

ElastiCache 的責任劃分可以列成一張清楚的表，這張表是判讀所有 ElastiCache 事故的起點：

左欄是用 managed 換到的，右欄是用 managed 換不掉的。2.C9 cache stampede 的雪崩、連線風暴、eviction 選錯 在 ElastiCache 上跟自管 Redis 一模一樣會發生——因為這些是 cache 使用方式的問題，不是運維的問題。

engine 選擇與 cluster mode

ElastiCache 的兩個結構性決策：

engine：2024 起 default 是 Valkey（成本約低 20%、OSI 開源、Redis 7.2.4 fork、API 相容）；Redis OSS 仍可選但 AWS 不推；Memcached 是另一條線（純 KV、無 cluster mode 概念）。新部署或既有 Redis 遷移都走 Valkey（相容、便宜），純 cache 才考慮 Memcached。

cluster mode：disabled 是 1 primary + 最多 5 replica、單 shard、上限約 340GB；enabled 是多 shard（最多 500）、自動 sharding、橫向擴展。判讀：dataset < 300GB 且不需 sharding 用 disabled（簡單），> 300GB 或要橫向擴展用 enabled（但 client 要 cluster-aware）。

配置：建立與治理的設定路徑

 1# 建立 Valkey replication group（Multi-AZ、auto failover、cluster mode disabled）
 2aws elasticache create-replication-group \
 3  --replication-group-id prod-cache \
 4  --replication-group-description "prod cache" \
 5  --engine valkey \
 6  --cache-node-type cache.r7g.large \
 7  --num-cache-clusters 3 \           # 1 primary + 2 replica
 8  --automatic-failover-enabled \
 9  --multi-az-enabled \
10  --snapshot-retention-limit 7 \     # 自動 snapshot 保留 7 天
11  --at-rest-encryption-enabled \
12  --transit-encryption-enabled
13
14# 自訂 parameter group（maxmemory-policy 等仍是你的責任）
15aws elasticache create-cache-parameter-group \
16  --cache-parameter-group-name prod-params \
17  --cache-parameter-group-family valkey8 \
18  --description "prod cache params"
19aws elasticache modify-cache-parameter-group \
20  --cache-parameter-group-name prod-params \
21  --parameter-name-values "ParameterName=maxmemory-policy,ParameterValue=allkeys-lru"

配置判讀：

• --automatic-failover-enabled + --multi-az-enabled 是 HA 的核心，把 Sentinel 那條 failover 時序鏈託管掉
• maxmemory-policy 透過 parameter group 設定——AWS 給旋鈕、選哪個是你的責任（見 eviction 調校）
• --transit-encryption-enabled 加 TLS，但 TLS 增加 client 建連成本，連線池更重要
• IAM authentication（Redis 7+）取代 AUTH password，對應 security 模組

Production 故障演練

Case 1：failover 期間 client 持續 error

徵兆：ElastiCache 觸發 failover（看 describe-events），AWS 端 replica 晉升完成，但 application 持續 30 秒到幾分鐘大量連線 error。

根因：failover 時 primary endpoint 的 DNS 切到新 primary，但 client 的連線池還握著舊 primary 的連線、DNS 也可能有快取。AWS 完成了 failover，但 client 重連是你的責任——ElastiCache 不會幫你的 application 重連。

修法：

1. client 用支援自動重連的 library，設合理的 socket timeout 與 retry（見 連線調校）
2. 連到 primary endpoint（會跟著 failover 更新 DNS），不要連到特定 node 的 endpoint
3. 縮短 client 的 DNS 快取 TTL，讓 failover 後的 DNS 切換更快被看到
4. failover 期間的寫入中斷無法完全避免（非同步複製 + 重連時間），latency-sensitive 服務要設計降級

Case 2：跨 AZ replication lag 造成 stale read

徵兆：寫入 primary 後立刻從 replica 讀，偶爾讀到舊值；CloudWatch 的 ReplicationLag 在高寫入時段上升。

根因：ElastiCache 的跨 AZ 複製是非同步的，replica 有 lag。AWS 保證複製會發生，但不保證即時——read-from-replica 在寫後立即讀的場景會看到 stale window。這跟自管 Redis 的 replica 行為一致，managed 沒有消除它。

修法：

1. 寫後需要立即一致讀的路徑，強制 read from primary
2. 監控 CloudWatch ReplicationLag，持續高代表寫入超過複製能力，要 scale up node 或降寫入
3. 接受 cache 的最終一致性——這是 cache copy 的本質，不是 bug（見 cache copy boundary）
4. 需要強一致 + durability 走 MemoryDB（見本文 Capacity / cost 邊界段）

Case 3：Serverless 計費超出預期

徵兆：用了 ElastiCache Serverless 想省容量規劃，月底帳單遠超預期。

根因：Serverless 按 ECPU（運算）+ storage 計費，流量尖峰或低效的 access pattern（大量小命令、大 value）會推高 ECPU 消耗。Serverless 解的是「不想規劃容量」，不是「一定更便宜」——可預測的穩態流量用 node-based + Reserved Instance 通常更省。

修法：

1. 流量可預測、穩態高的 workload 用 node-based + Reserved Instance（1/3 年承諾、折扣約 30-60%）
2. 流量不可預測、有大量閒置時段的才適合 Serverless
3. 監控 ECPU 消耗，找出推高成本的 access pattern（用 pipeline 合併小命令降 ECPU）
4. 成本模型對比要算實際 workload，不要假設 Serverless 一定划算

Case 4：cluster mode enabled 但 client 不是 cluster-aware

徵兆：建了 cluster mode enabled 的 cluster，application 連線報 MOVED redirect 或連不上某些 key。

根因：cluster mode enabled 把 keyspace 分到多 shard，client 必須 cluster-aware（懂 CLUSTER SLOTS、處理 MOVED/ASK redirect）才能正確路由。普通 standalone client 連 cluster mode enabled 會失敗。

修法：

1. cluster mode enabled 一律用 cluster-aware client（連 configuration endpoint 不是單一 node）
2. 確認 application 的多 key 操作用 hash tag 把相關 key co-locate 同 slot（見 cluster re-sharding）
3. dataset < 300GB 且不需 sharding，用 cluster mode disabled 省掉這層複雜度
4. 從 disabled 升 enabled 是有成本的架構變更，初期規劃就要決定

Case 5：snapshot 期間記憶體尖峰、node 不穩

徵兆：自動 snapshot 時段 node 延遲上升、DatabaseMemoryUsagePercentage 衝高，偶爾 snapshot 失敗。

根因：Redis engine 的 snapshot 靠 fork（見 persistence / fork latency），fork 期間 copy-on-write 推高記憶體。如果 node 記憶體已吃緊，snapshot 的 fork 把它推爆。AWS 託管了 snapshot 排程，但 fork 的記憶體成本仍在 engine 層存在。

修法：

1. node 記憶體留 headroom（不要長期 > 80%），給 snapshot 的 fork copy-on-write 空間
2. snapshot window 設在低流量時段，減少 fork 期間被改的 page
3. 監控 CloudWatch DatabaseMemoryUsagePercentage，> 80% 考慮 scale up node type
4. Valkey engine 繼承 Redis 的 fork 模型，這個成本換 engine 到 Valkey 也還在（fork-less 要 DragonflyDB、但 ElastiCache 不提供）

Capacity / cost 邊界

ElastiCache 的容量判讀，混合了 AWS 的 metric 與 engine 層的行為：

撞牆後的路由判斷：

• 需要 source-of-truth 的 Redis API（不是 cache）：ElastiCache 是 cache 語意（資料可重建）。需要 durability 走 AWS MemoryDB——Redis-compatible 但有 multi-AZ transaction log、提供 source-of-truth 語意，成本約 ElastiCache 的 2-3 倍。判讀：Tubi 把 feature store 從 ScyllaDB 遷到 ElastiCache 的前提是「feature 可重新計算」——可重建選 ElastiCache，不可重建選 MemoryDB 或 database。
• 跨雲 / 不在 AWS 生態：ElastiCache 綁 AWS，跨雲走自管 Redis / Valkey 或 GCP Memorystore / Azure Cache。
• 極端單機 throughput：要榨單機多核走自管 DragonflyDB（ElastiCache 不提供 Dragonfly engine）。
• 跨 region active-passive DR：ElastiCache 的 Global Datastore（1 primary region + 多 secondary read replica、跨 region lag < 1 秒），不支援 active-active multi-master。

整合 / 下一步

ElastiCache 的 deep article 本質是「劃清 managed 邊界」，它跟 engine 層的調校知識緊密相連：

• 跟 Redis 全系列 deep article：eviction、persistence/fork、連線的調校在 ElastiCache 上仍適用（engine 是 Redis/Valkey），AWS 託管的是 failover/patching/snapshot 排程，不是這些 engine 行為。
• 跟 Valkey 相容性：ElastiCache 的 default engine 就是 Valkey，相容性與 io-threads 的判讀直接適用。
• 跟 Netflix EVCache：EVCache 是 Netflix 自管的 Memcached-based 全域 cache，對照 ElastiCache for Memcached + Global Datastore——展示了自管跨區 vs managed 跨區的取捨。
• 跟 Tinder / Tubi：兩個 ElastiCache 規模化案例，一個是 sub-ms 配對引擎、一個是 ML feature store p99<10ms，都展示了「AWS 給吞吐、你給設計」的邊界。

相關連結

• 上游 vendor 頁：AWS ElastiCache
• engine 層 deep article：Redis 記憶體與淘汰、persistence 與 fork latency、Sentinel 與 failover 時序、Valkey 相容性
• 上游能力：0.6 成本取捨、cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是跨 vendor migration playbook、cross-link Redis / Valkey（source、自管）跟 AWS ElastiCache（target、managed）。跑 migration-playbook-methodology 6 維 audit 對映 Operational model = High（自管 → managed）、其他 Low → Type C operational hybrid。ElastiCache 是 managed SaaS、AWS 操作依官方文件（未本機驗證、引數以官方為準）、最後檢查日 2026-06-16。

engine 不變、變的是誰運維

多數 vendor 遷移會換掉某個本質的東西——協定、data model、paradigm。自管 Redis/Valkey → ElastiCache 一個都沒換：ElastiCache 跑的就是 Redis 或 Valkey engine，同樣的 RESP 協定、同樣的 data types、同樣的 client library、同樣的命令。application code 幾乎不用動。

那遷的是什麼？運維責任的歸屬。自管時要自己部署、自己打 patch、自己設 replication、自己半夜處理 failover。ElastiCache 把這些接走——AWS 做 failover、patching、snapshot、跨 AZ 複製。這個遷移的全部工作量集中在「把運維交出去」這件事上：網路（VPC）、安全（IAM / Security Group）、cutover 的資料連續性，以及想清楚交出運維的同時、交出了哪些控制權（不再能 SSH 進機器、不能改任意 config、parameter group 限定可調項）。

這對映 migration 方法論 的 Type C operational hybrid——operational model 是唯一的 High 維度，其他全 Low。本文展開這個「engine 不變、運維轉移」遷移的實際工作與責任邊界。

6 維 diff dimension audit

唯一 High 是 operational model，對映 Type C operational hybrid。Type C 的結構是「operational audit 前置 + drop-in cutover」——因為 engine/API 不變，cutover 本身接近 drop-in（換 endpoint），重點在前置的網路/安全/責任邊界盤點。

operational audit：cutover 前要盤點的

ElastiCache 把運維接走，但也劃下新的邊界。cutover 前必盤：

audit 的關鍵 output：(1) 目前改了哪些 redis.conf 項、ElastiCache parameter group 是否支援；(2) client 是否有 failover reconnect 邏輯（managed failover 不會代為重連）；(3) 監控要從自管工具搬到 CloudWatch。這三項是 Type C 的核心工作。詳細的 managed 責任邊界見 ElastiCache 責任邊界 deep article。

cutover：資料連續性的兩條路

因為 engine/API 不變，cutover 接近 drop-in（換 endpoint）。資料連續性有兩條路：

 1路徑 A：re-warm（cache 可重建、最簡單）
 2  1. 建 ElastiCache cluster（空的、選 Valkey / Redis engine、設 parameter group）
 3  2. application 雙寫（自管 + ElastiCache）、讀仍走自管
 4  3. 讀切到 ElastiCache endpoint、cache miss 回源 warm up
 5  4. 命中率追上 → 停寫自管 → 下線自管
 6
 7路徑 B：RDB seed（要 cache 連續性、避免 warm-up origin 衝擊）
 8  1. 自管端 BGSAVE 產生 RDB
 9  2. RDB 上傳 S3、ElastiCache 從 S3 seed 建 cluster（依官方 restore 流程）
10  3. application 換 endpoint cutover
11  （ElastiCache 也提供 self-managed Redis online migration、見官方文件）

判讀：

• 純 cache、能接受短暫 warm-up → 路徑 A（最簡單、無資料遷移）
• 大 dataset、warm-up 會打爆 origin → 路徑 B（RDB seed 保連續性）
• AWS CLI 建 cluster 與 restore 細節依 ElastiCache 官方文件（未本機驗證）
• engine 選 Valkey（AWS default、約低 Redis 20%）除非有 Redis 商業 module 依賴

Production 故障演練

Case 1：parameter group 不支援自管時改的 config

徵兆：自管時改了某個 redis.conf 項（例如特定 client-output-buffer-limit 或某個進階參數），遷到 ElastiCache 後該設定無法套用或行為不同。

根因：ElastiCache 只允許改 parameter group 開放的項，部分 config 被 AWS 鎖死（為了 managed 穩定性）。自管時的任意 config 自由度在 managed 後收窄。

修法：

1. pre-migration 列出自管端所有非預設 config，逐項對照 ElastiCache parameter group 支援度
2. 不支援的項要評估影響——有些是 AWS 已用更好的方式處理、有些要調整 application 適應
3. 把這個盤點放在 operational audit（cutover 前），不要遷完才發現
4. 高度依賴特殊 config 調校的場景，managed 可能不適合、留自管

Case 2：failover 後 client 不重連（managed 不代為重連）

徵兆：ElastiCache Multi-AZ failover 完成，但 application 持續連舊 primary、寫入失敗。

根因：ElastiCache 接走了 failover（自動晉升 replica），但 application 的 client 重連仍是 application 端的責任——這是 managed 責任邊界 的核心：AWS 換 primary，client 要自己跟上。

修法：

1. client 連 primary endpoint（會跟著 failover 更新 DNS）、不寫死 node IP
2. client 設合理 socket timeout + retry + 縮短 DNS 快取
3. 遷移前就驗證 client 有 failover reconnect 行為（自管 Sentinel 時可能靠不同機制）
4. 對應 Redis Sentinel failover 時序：自管與 managed 的 failover 機制不同、client 處理要重驗

Case 3：endpoint 只在 VPC 內、cutover 後連不上

徵兆：cutover 後 application 完全連不上 ElastiCache、連線逾時。

根因：ElastiCache endpoint 只在 VPC 內可達、不對公網開放。Security Group 沒開 6379、subnet group 配置錯、或 application 不在同 VPC / 沒有 VPC peering，就連不上。

修法：

1. cutover 前確認 Security Group 開 6379 給 application 的來源、subnet group 正確
2. application 不在同 VPC 要設 peering / Transit Gateway
3. 從 VPC 內 EC2 先 redis-cli -h <endpoint> ping 驗證連通，再切 application
4. 這是自管（自己的網路）→ managed（AWS VPC 模型）最常見的卡點

Case 4：監控斷層（自管工具 → CloudWatch）

徵兆：cutover 後原本的 Prometheus / Grafana dashboard 全空、告警失效。

根因：自管時用 redis_exporter + Prometheus，ElastiCache 的指標在 CloudWatch、指標名與維度不同。直接搬 dashboard 不會動。

修法：

1. cutover 前把關鍵告警在 CloudWatch 重建（DatabaseMemoryUsagePercentage / ReplicationLag / CurrConnections 等）
2. 要保留 Grafana 可用 CloudWatch data source 接
3. 把監控遷移納入 operational audit、不要遷完才發現沒監控
4. 核心指標語意相同（記憶體 / 命中 / 連線 / 複製延遲）、只是來源與命名變了

Case 5：以為 managed 就不會 OOM / stampede / 熱 key

徵兆：遷到 ElastiCache 後仍然 OOM、cache stampede、熱 key 打爆單 shard。

根因：ElastiCache 接走的是運維（failover/patch/snapshot），不是 cache 使用方式的問題。記憶體淘汰、stampede、熱 key、key 設計仍是 application 端的責任——managed 不等於 hands-off。

修法：

1. 記憶體 / eviction 調校仍要做（透過 parameter group 設 maxmemory-policy），見 記憶體調校
2. stampede / 熱 key 的 application 端防護（jitter / singleflight / 兩層 cache）照舊
3. 釐清 managed 的責任邊界——左欄 AWS 管、右欄 application 端管，見 責任邊界 deep article
4. 遷 managed 是減運維、不是免設計

Capacity / cost 對照

判讀：在 AWS 生態、要把運維交出去、能接受 config 自由度收窄 → 遷 ElastiCache（engine 不變、Type C 低風險）；要極致控制 / 跨雲 / 依賴特殊 config → 留自管。engine 選 Valkey 省約 20%。

整合 / 下一步

self-managed → ElastiCache 是運維轉移，它跟 managed 邊界與 engine 調校交織：

• 跟 ElastiCache 責任邊界 deep article：遷過去後哪些 AWS 管、哪些仍 application 端管，是這個遷移的核心後果。
• 跟 Redis Sentinel failover：自管 failover（Sentinel）→ managed failover（Multi-AZ），client 重連邏輯要重驗。
• 跟 Valkey：ElastiCache default engine 是 Valkey，自管 Redis 遷 ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位（見 Redis → Valkey 遷移）。
• 跟能力級買 vs 建：自管 vs managed 的上層取捨見該章，本文是「決定買（managed）之後」的遷移執行。

相關連結

• Source vendor：Redis / Valkey（自管）
• Target vendor：AWS ElastiCache
• 對應 deep article：ElastiCache 責任邊界
• 相關 migration：Redis → Valkey（換授權 + 可同時轉 managed）
• Methodology：Migration playbook methodology（Type C operational hybrid）