本文是 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 到 AWS ElastiCache（source）跟 Redis / Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type C operational redesign hybrid：engine 層相容（Low）但 operational model 差異大（IAM auth → password/ACL、CloudWatch → 自管監控、auto failover → Sentinel/自建 HA）。

為什麼從 managed 遷出

ElastiCache 遷出的 driver 通常不是 engine 層問題 — 它跑的就是 Redis 或 Valkey。常見遷出原因：

• 成本：managed premium 在大規模（數百 GB、多叢集）下比自管 + 運維人力更貴，尤其跨帳戶大量叢集時
• 跨雲或混合雲：業務需要在 GCP、Azure 或 on-prem 同時運行 cache 層，ElastiCache 只在 AWS
• 功能限制：ElastiCache 不支援所有 Redis module（RediSearch、RedisJSON 等），或 Valkey 8.x 新功能 ElastiCache 尚未上線
• 控制權：自管可以自訂 redis.conf、自選 kernel 參數、自決 upgrade 時機

資料搬遷用 RDB export + import 就完成，真正的工程量在 operational model 重建 — ElastiCache 幫你管的 HA、monitoring、backup、security，遷出後全要自建。

6 維 diff dimension audit

Operational model 是 High — 這是 Type C 的判定依據。遷移重心在重建 ElastiCache 幫你做的那些事。

階段一：盤點 ElastiCache 依賴

在動手之前，先列出 ElastiCache 幫你管的所有東西，每一項都要在自管環境重建或決定不要。

認證與網路

• IAM auth：ElastiCache 支援 IAM auth token（短效 token），自管 Redis 改用 requirepass 或 Redis 6+ ACL
• VPC / Security Group：自管 Redis 仍需 VPC 隔離，但 security group 規則要自己維護
• TLS：ElastiCache 原生 in-transit encryption，自管要自己配 redis TLS 憑證

高可用

• Auto failover：ElastiCache 自動偵測 primary failure 並 promote replica。自管用 Sentinel HA failover 或 Redis Cluster 內建 failover
• Cross-AZ replication：ElastiCache 自動跨 AZ。自管要自己在不同 AZ 部署 replica

監控與備份

• CloudWatch metrics：ElastiCache 自動發 CurrConnections、CacheHitRate、ReplicationLag 等。自管用 INFO 指令 + Prometheus redis_exporter
• Snapshot：ElastiCache 自動 daily snapshot + 手動 snapshot。自管用 BGSAVE + cron + 外部 storage

跨 region replication

• Global Datastore：ElastiCache 支援跨 region active-passive replication。自管 Redis 沒有原生跨 region replication — 若目前使用 Global Datastore，遷出前需要決定是用 application-level replication、第三方工具（Redis Enterprise Active-Active）還是放棄跨 region cache 同步

升級與維護

• Engine 升級：ElastiCache 在維護窗口自動或手動升級。自管要自己做 rolling upgrade
• Patch：安全 patch 由 AWS 負責。自管要自己追蹤 CVE

階段二：建立自管環境

部署架構

最小 production 架構：1 primary + 1 replica + 3 Sentinel（或 Redis Cluster 3 primary + 3 replica）。

1# Docker Compose 驗證用（production 用 VM 或 K8s）
2# Primary
3docker run -d --name redis-primary -p 6379:6379 redis:7 \
4  redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes
5
6# Replica
7docker run -d --name redis-replica -p 6380:6379 redis:7 \
8  redis-server --replicaof redis-primary 6379 \
9  --masterauth "$REDIS_PASSWORD" --requirepass "$REDIS_PASSWORD"

Sentinel 或 Redis Cluster 配置見 Sentinel HA Failover。

監控重建

ElastiCache CloudWatch metrics 對應的自管替代：

用 Prometheus redis_exporter 自動採集，接 Grafana dashboard。

Backup 重建

1# cron job: 每日 BGSAVE + 等完成 + 上傳 S3
2# LASTSAVE 回傳 Unix timestamp，BGSAVE 完成後 LASTSAVE 會更新
30 3 * * * BEFORE=$(redis-cli -a "$REDIS_PASSWORD" LASTSAVE) && \
4  redis-cli -a "$REDIS_PASSWORD" BGSAVE && \
5  while [ "$(redis-cli -a "$REDIS_PASSWORD" LASTSAVE)" = "$BEFORE" ]; do sleep 5; done && \
6  aws s3 cp /data/dump.rdb s3://backup-bucket/redis/$(date +\%Y\%m\%d).rdb

Production 建議搭配 persistence fork latency 的監控，確認 BGSAVE 的 fork 不會造成延遲 spike。

階段三：資料搬遷與切換

搬遷策略

ElastiCache 的資料搬遷有兩條路：

RDB export + import（適合 downtime 可接受的場景）：

1. ElastiCache 建立手動 snapshot
2. 把 snapshot export 到 S3（ElastiCache console → Export snapshot）
3. 下載 RDB 檔，放到自管 Redis 的資料目錄
4. 重啟自管 Redis 載入 RDB

雙寫期間遷移（適合零停機需求）：

1. Application 同時寫 ElastiCache 和自管 Redis（雙寫）
2. 讀取仍走 ElastiCache
3. 監控自管 Redis 的資料量與命中率追上後，切讀取到自管
4. 移除 ElastiCache 寫入
5. 下線 ElastiCache

雙寫的複雜度高於 RDB export。Cache 資料可重建的特性讓第一種策略在多數場景夠用 — 短暫 cache miss 的代價是回源到 DB，通常可接受。

Endpoint 切換

Application 用 endpoint 連 ElastiCache。切換時：

1. 把 application config 的 Redis host 改為自管 Redis endpoint
2. 確認 TLS 與認證方式對齊（IAM token → password/ACL）
3. Rolling restart application
4. 監控 cache hit rate 與 latency 回到 baseline

如果用 DNS CNAME 間接指向 ElastiCache endpoint，可以直接改 CNAME 指向自管 Redis，application 不用改 config。

階段四：驗證與回退

驗證清單

回退路徑

Cache 遷移的回退比 DB 遷移簡單 — cache 資料可重建。回退步驟：

1. Application config 改回 ElastiCache endpoint（或 CNAME 指回）
2. Rolling restart
3. Cache miss 回源到 DB，自然 warm up

ElastiCache 在遷移期間不要下線，保留 7-14 天作為回退保險。確認自管 Redis 穩定運行後再刪除 ElastiCache cluster。

成本對照

小規模（< 50 GB、< 5 cluster）通常 ElastiCache 的 managed premium 比自管人力便宜。Compute 跟 HA 的差額在小規模可忽略，但監控跟 backup 的自建成本是固定開銷 — 即使只管一個 cluster，redis_exporter + Prometheus + cron backup 的設定跟維護都要做。大規模（數百 GB、多叢集）或跨雲場景下，managed premium 累積到 cluster 數 × node 數的倍數，自管的邊際成本反而更低，遷出 ROI 才成立。

交接路由

• Source vendor overview：AWS ElastiCache
• Target vendor 操作：Redis Sentinel HA、Redis Cluster Resharding
• 監控重建：Redis Memory Eviction Tuning、Redis Persistence Fork Latency
• 反向路徑：Redis → ElastiCache