跟 GoReplay 比、Service Mesh Mirroring 在 proxy / sidecar 層、是 K8s mesh-native 的 L7 HTTP request mirror、不需要 application 或 host 端 capture binary；GoReplay 在 application host 層、適合無 mesh 的環境或要 capture artifact 離線 replay。跟 AWS VPC Traffic Mirroring 比、Service Mesh Mirroring 在 L7（HTTP route / header / subset 可控）、VPC Traffic Mirroring 在 L3-L4 packet 層、見度更底層但缺 application 語意。三者組合常見於 K8s + 多 cloud 混合環境。

最短判讀路徑

判斷 Service Mesh Mirroring 部署是否健康、最少看四件事：

• Mesh implementation 對齊：用哪套 mesh（Istio / Linkerd / Envoy gateway / Consul Connect）、control plane 版本、sidecar injection coverage、跨 namespace policy 邊界是否清楚
• VirtualService mirror config：mirror destination 是否限制在同 namespace / 同 cluster、mirror_percent 是否從 1% 漸進、route / header filter 是否排除 write-heavy 或 PII path
• Target service capacity：shadow target deployment 是否有獨立 HPA、跟 primary 同 node pool 還是隔離、DB / cache / external API 是否導 mock 或 sandbox、不會 share connection pool 造成 primary 飽和
• Response handling：mirrored response 是 fire-and-forget（Istio 預設）還是有 logging、shadow 端是否能辨識 mirrored request（X-Envoy-Internal / custom header）、side effect（payment / notification / webhook）是否走 dry-run

四件事任一缺失、就是 9.10 Production-Side 驗證 shadow traffic 治理的待補項目。

定位

Service mesh mirroring 適合平台已經有 proxy control plane 的團隊。當 service-to-service traffic 都經過 sidecar 或 gateway，mirror policy 可以把部分 production request 複製到新版本，不需要在 application code 中加 capture / replay 邏輯。

這個定位讓 service mesh mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 與 canary perf check。它比 host capture 更貼近 service routing，但也依賴 mesh 的觀測、policy、資源隔離與治理能力。

適用場景

新版本 shadow validation 適合 service mesh mirroring。平台可以把 1%、5% 或特定 route 的流量 mirror 到 shadow deployment，觀察新版本 CPU、memory、latency、DB read 與 error。

Service-to-service migration 適合 service mesh mirroring。當下游服務準備換 runtime、framework、DB client 或 cache client，mirror 可以讓新路徑吃到 production upstream pattern。

多 region / 多 version 對照適合 service mesh mirroring。Mesh policy 能按 namespace、host、route、header 或 subset 控制 mirror target，讓平台在小 blast radius 下收集 production-shaped evidence。

選型判準

Proxy 層控制價值來自一致性。當所有 service 都走 mesh，mirror policy 可以用同一套控制面管理，避免每個 application 自行實作 replay。

Mesh observability 價值來自對照能力。Shadow service 的 latency、error、resource saturation 與 dependency call 可以直接跟 primary path 對比，但 dashboard 要清楚標記 mirrored traffic，避免混入正式 SLO。

跟其他方式的取捨

Service mesh mirroring 和 GoReplay 的主要差異是控制面。Service mesh mirroring 依賴既有 proxy / mesh，適合服務間流量；GoReplay 適合 HTTP capture artifact、離線 replay 與沒有 mesh 的環境。

Service mesh mirroring 和 AWS VPC Traffic Mirroring 的主要差異是語意層級。Mesh 在 L7 routing 層，能按 route、host、header 與 subset 控制；VPC mirroring 在網路層，能見度更底層但應用語意控制較少。

Service mesh mirroring 和 canary 的主要差異是使用者影響。Mirrored request 的回應不回給使用者，適合 capacity / correctness observation；canary 會讓真實使用者走新版本，適合最終放量。

操作成本

Service mesh mirroring 的主要成本是下游容量。Shadow traffic 雖然不回應使用者，但仍會消耗 shadow service、DB、cache、third-party mock、queue 與 observability pipeline 的資源。

Policy 成本來自控制面治理。Mirror rule、route、subset、namespace、owner 與 rollout window 都要可審查；錯誤的 mirror policy 可能把過大比例流量導到未準備好的 target。

Side effect 成本來自 application 行為。Shadow service 要能辨識 mirrored request，並把 write、external API call、notification、payment 與 queue publish 導到 sandbox、mock 或 dry-run。

Evidence Package

Service mesh mirroring 結果應回寫到 evidence package。最小欄位包括 mesh policy version、source service、route、mirror ratio、target subset、time range、shadow target resource、data / side effect isolation、p95 / p99、error rate、dependency saturation、known gap 與 owner。

Evidence package 的核心用途是讓 mirror 實驗可關閉。Reviewer 要能看到 mirror policy 何時啟動、何時停止、覆蓋哪些 route、消耗哪些下游資源，以及 shadow target 是否接近 production。

進階主題

Istio VirtualService mirror / mirror_percent：Istio 用 VirtualService 的 mirror 欄位指定 shadow destination、mirrorPercentage（v1.7+；舊版 mirror_percent）控制比例。production 操作慣例是從 1% 起步、每 30-60min 觀察 shadow target latency / error / saturation 再放大、達到 100% 後維持一週收 evidence 才 promote。route-level config 比 mesh-wide policy 安全、blast radius 限定在指定 host / path。

Linkerd traffic split：Linkerd 用 SMI TrafficSplit CRD 或 native HTTPRoute 分流、走 active-active shadow 模式而非 fire-and-forget。Linkerd mirror 預設較輕量、proxy overhead 比 Istio 低、適合資源敏感的 K8s cluster；但 L7 policy 表達力不如 Istio EnvoyFilter。

Envoy MirrorPolicy：直接寫 Envoy config（不透過 Istio control plane）時、route.RouteAction.request_mirror_policies 是底層 primitive。多 cluster 邊緣 gateway（Contour / Emissary-Ingress / Gloo）都是這層的 abstraction、適合不想引入 full Istio 但要 mirror 能力的場景。

跟 Argo Rollouts canary 整合 — shadow deployment：Argo Rollouts 的 analysis step 可以接 mesh mirror — shadow stage 先用 mirror 收 evidence、canary stage 才放真實流量。對應 9.10 Production-Side 驗證 的「shadow 先於 canary」原則、避免把使用者當小白鼠。

跟 Datadog APM trace correlation：mirrored request 應該有獨立的 trace tag（env:shadow 或 traffic.mirror:true）、讓 Datadog APM / observability stack 能 filter 出 shadow path 的 p95 / error rate、不混入 primary SLO dashboard。trace propagation header 要保留、否則 distributed trace 斷在 mesh 邊界。

排錯與失敗快速判讀

• Mirror target capacity 不足 / shadow service OOM：shadow deployment 沒獨立 HPA、跟 primary 共用 node pool — 拆 node pool、shadow 設獨立 resource request、mirror_percent 從 1% 起步
• Mirrored response 漏處理（fire-and-forget 副作用）：Istio 預設丟棄 mirrored response、shadow 端的 error 沒被 collect — shadow service 自己 emit metric / log、不依賴 mirror response、加 X-Shadow-Request header 讓 shadow 端可辨識並走 dry-run 路徑
• PII / sensitive data 進 staging：mirrored request 帶真實 user token / payment info 打到 staging — header / body filter 走 EnvoyFilter 做 PII redaction、或在 mesh 邊界跑 data masking proxy 再 mirror
• Side effect 真的發生（payment double charge / notification 真寄）：shadow service 沒辨識 mirrored request 就走正式邏輯 — 強制 shadow 端用 sandbox credential、external API client 走 mock / dry-run mode、write 改 read-only replica
• Mesh control plane 飽和 / mirror policy drift：mirror rule 散落各 namespace 沒 owner、policy version 不一致 — 走 GitOps（Argo CD / Flux）+ policy as code、定期 audit kubectl get virtualservice -A
• Cross-cluster mirror blast radius 失控：mirror destination 指向其他 cluster 導致跨 cluster 流量爆增 — mirror destination 限 same-cluster、跨 cluster 要走獨立的 gateway 並設 quota
• Shadow trace 混進 SLO dashboard：APM 沒分 primary / shadow tag、p95 看起來變差但其實是 shadow 拖累 — trace tag env:shadow 強制、observability dashboard filter

何時改走其他服務

不在本頁內的主題

• Istio / Linkerd / Envoy 完整 install / 升級 / control plane HA 細節
• Service mesh 安全模型（mTLS / SPIFFE / authorization policy）— 屬 7 security 邊界
• Mesh-level retry / timeout / circuit breaker 等 resilience pattern
• Multi-cluster mesh federation（Istio multi-primary、Linkerd multicluster）

案例回寫

Service mesh mirroring 適合回寫平台遷移與新版本 shadow validation 案例。它可接 Miro managed EKS migration、Tradeshift self-managed K8s to EKS、9.C28 FanDuel 雙峰 workload 的逐步驗證需求、9.C12 Riot Games 246 EKS cluster 的 single-tenant per game 跨 cluster 流量 shadow，以及 9.C7 Lyft 100+ 微服務 跨服務的 mirror 範圍治理。

這些案例的重點是 routing policy 與 blast radius。Service mesh mirroring 頁引用案例時，要把 case 轉成 route、mirror ratio、target subset、dependency isolation 與 abort condition — 例如 Riot Games 的 single-tenant 模式下、mirror policy 必須限制在 同遊戲 cluster 內、不能跨 game 否則 blast radius 失控。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：5.6 Traffic, Config and Control Plane Boundary
• 平行：GoReplay
• 平行：AWS VPC Traffic Mirroring
• 知識卡：Shadow Traffic

定位

AWS VPC Traffic Mirroring 適合需要網路層能見度的 AWS workload。當 application code、service mesh 或 host capture 都不適合改動時，VPC 層 mirror 可以從 ENI 複製封包到 analysis appliance、IDS、packet capture 或自管處理服務。

這個定位讓 AWS VPC Traffic Mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 前置觀測。它偏封包觀察與樣本收集，若要做應用層 replay、filter、rewrite 或 side effect 隔離，通常還需要 GoReplay、proxy、custom processor 或測試環境配合。

跟 GoReplay 比、VPC Traffic Mirroring 走 無侵入 L3 packet copy、GoReplay 走 application-level HTTP capture / rewrite；跟 Service Mesh Mirroring 比、VPC Mirror 在 ENI 層、Mesh Mirror 在 K8s pod 層；跟 AWS Network Firewall 比、Firewall 是 inline 阻擋、Mirror 是 side-channel 觀察、兩者目的不同但 packet path 相近。

最短判讀路徑

判斷 VPC Traffic Mirroring deployment 是否健康、最少看四件事：

• Source ENI selection：哪些 ENI 被 mirror（per-instance / per-subnet / 用 tag 自動選）、是否覆蓋瓶頸路徑上的關鍵節點（ALB target / NAT Gateway / RDS proxy / cross-AZ ENI）、漏掉哪個 ENI 就是 evidence 盲區
• Filter rule 收斂：mirror filter 用 protocol / port / CIDR / direction 限定、避免「全 ENI 全 traffic」這種失控設定；filter 太寬會把 cross-AZ cost + target 處理量直接炸上去
• Target NLB capacity：mirror target 是 ENI 或 NLB、target capacity（NLB flow / bandwidth）跟 source 流量比例要對得起來、target overload 會 drop 封包讓 evidence 失真
• Sampling rate / packet length truncation：高流量服務不必 1:1 mirror、要設 packet_length 截斷（只取 header）跟 mirror session ratio；忘設 sampling 等於整條 production 流量複製兩份、AWS bill 月底會出事

四件事任一缺失、就是 9.10 Production-Side 驗證 邊界的待補項目。

適用場景

網路層瓶頸定位適合 VPC Traffic Mirroring。當 latency、packet loss、TLS handshake、connection reset、NAT、load balancer 或 cross-AZ traffic 是疑點時，封包 mirror 能提供 application metrics 看不到的證據。

低侵入 traffic sampling 適合 VPC Traffic Mirroring。團隊可以在不改 application code 的情況下收集 production flow，作為 workload model、security analysis 或 replay pipeline 的輸入。

受管 AWS 網路環境適合 VPC Traffic Mirroring。當服務主要跑在 EC2 / ENI 可 mirror 的環境中，VPC 原生能力可以讓網路團隊用既有安全與觀測流程管理。

選型判準

網路層鏡像價值來自低侵入。團隊可以在不調整 application 或 service mesh 的情況下取得 flow evidence，但也要承擔 L7 語意不足的限制。

安全分析價值來自封包細節。對容量工程而言，封包證據能幫忙確認 connection、TLS、NAT、load balancer 與跨區流量成本；對資安而言，則能支援 IDS 與 forensic workflow。

跟其他方式的取捨

AWS VPC Traffic Mirroring 和 GoReplay 的主要差異是層級。VPC mirroring 在 L3 / L4 觀察封包；GoReplay 更接近 HTTP application replay，對 request rewrite 與 target control 更直接。

AWS VPC Traffic Mirroring 和 service mesh mirroring 的主要差異是控制範圍。VPC mirroring 由網路層控制，適合低侵入封包觀察；service mesh mirroring 由 L7 route policy 控制，適合服務版本與 route 對照。

AWS VPC Traffic Mirroring 和 synthetic load test 的主要差異是用途。VPC mirroring 提供 production traffic evidence；synthetic load test 提供可控壓力。兩者常搭配：先用 mirror 校正 workload model，再用 k6 / Gatling / Locust 產生可控負載。

操作成本

AWS VPC Traffic Mirroring 的主要成本是資料治理。Mirror target 可能收到 payload、token、cookie、internal identifiers 與敏感資料，因此保存、查詢、保留期限、存取權與刪除責任要先定義。

網路成本來自複製 traffic。Mirror session 會增加網路流量與 target processing 成本，高流量服務要先估算 mirror ratio、filter、target capacity 與跨 AZ 費用。

加密成本來自 L7 可讀性。TLS traffic 在網路層 mirror 後通常仍是加密封包；若需要 application payload，要搭配解密點、proxy、key 管理或 application-level capture。

Evidence Package

AWS VPC Traffic Mirroring 結果應回寫到 evidence package。最小欄位包括 mirror source ENI、filter rule、mirror target、session number、time range、sampling / truncation、target capacity、payload handling、packet metrics、known gap 與 owner。

Evidence package 的核心用途是把網路層觀察接回效能判斷。Reviewer 要能知道 mirror 覆蓋哪些 ENI、哪些封包被 filter、target 是否有 capacity，以及封包證據如何對應到 application latency 或 saturation。

進階主題

Filter rule 設計：mirror filter 支援 source CIDR / dest CIDR / protocol / port range / direction（ingress / egress）、rule number 決定 evaluation 順序。production 慣例是 最小覆蓋原則 — 先用 port 443 + dest CIDR = ALB target group 限定到關鍵 path、再依需要擴張。filter 寫太寬會把 control-plane heartbeat、health check、internal RPC 全部 mirror 進來、target 處理量瞬間爆掉。

跟 IDS / packet analyzer 整合：mirror target 接 ENI 後常見的下游堆疊是 Zeek（前 Bro、生成 connection log / protocol log）、Suricata（rule-based IDS / IPS 偵測）、Wireshark / tshark（離線封包分析）。實務上 mirror → NLB → 自管 EC2 跑 Zeek 產 JSON log → 進 Datadog / Splunk 做 correlation。容量工程關心 connection reset 跟 retransmit、資安關心 protocol anomaly、共用同一份 mirror feed。

Replay 到 staging cluster：mirror feed 不能直接 replay（沒有 stateful 重組），但可以接 packet replayer（tcpreplay / GoReplay packet mode）把樣本送到 staging。要注意 side effect 隔離 — staging 的 DB / external API 不應該真的執行寫入、否則 mirror 變成 production fanout。

Traffic analysis platform 整合：mirror 取得的 packet evidence 通常進 Datadog Network Performance Monitoring 做 NPM dashboard、或進 Splunk Stream app 做 SIEM correlation。整合的關鍵是 時間軸對齊 — packet timestamp、application log、metrics 三者要同步、否則 root cause 拼不回去。

排錯與失敗快速判讀

• Target NLB capacity 不夠 / drop packet：mirror traffic 量超過 NLB flow limit、packet 被 silently drop — 拆 mirror session 到多個 target、開 NLB flow log 看 drop reason、必要時改用 Gateway Load Balancer
• Filter rule 太寬導致流量爆：「mirror 所有 traffic」設定上線後 target ENI 跟 cross-AZ bandwidth 雙重炸 — 立刻關掉 session、改用 dest CIDR / port 收斂、加 packet_length 截斷只取 header
• Cross-AZ mirror cost 暴增：source ENI 跟 target 在不同 AZ、每個封包複製都收 cross-AZ traffic 費 — target NLB 部署到每個 AZ、用 AZ-affinity routing、或把 mirror target 限定在 source 同 AZ
• TLS payload 看不到：mirror 拿到加密封包、L7 內容無法分析 — 把解密點移到 ALB / NLB-TLS termination、或在 application 層加 capture（不再用 VPC mirror）
• Mirror session 漏掉新 instance：autoscaling 起新 instance 沒自動加入 mirror — 用 mirror target by tag、Terraform / CloudFormation 把 mirror session 寫進 ASC launch template
• Packet timestamp 不對齊 application log：mirror packet 時間是 source ENI capture 時間、不是 application processing 時間、做 latency 分析會偏差 — 用 packet 5-tuple + request ID 對齊 application log、不要直接相減 timestamp

案例回寫

AWS VPC Traffic Mirroring 適合回寫網路與平台層效能案例。它可接 9.C34 GCP 130K node GKE cluster 的大規模網路觀測需求（雖在 GCP、但網路證據的層次拆解可類比）、9.C22 Wayfair GCP burst capacity 的跨雲容量觀測、9.C1 Prime Day readiness 的 pre-event network evidence、9.C12 Riot Games 246 EKS cluster 跨 cluster 的網路流量觀測、以及 9.C24 Genesys DynamoDB 15-region 的 99.999% 可用性下封包層 evidence 補強。

這些案例的重點是網路層 evidence。VPC Traffic Mirroring 頁引用案例時，要把 case 轉成 mirror source、filter、target capacity、packet metric、cross-AZ cost 與 L7 correlation — 例如 Riot Games 35ms 延遲門檻下、cross-AZ traffic mirror 本身會增加成本、必須先用 filter 收斂到關鍵 ENI。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：9.5 瓶頸定位流程
• 平行：GoReplay
• 平行：Service Mesh Mirroring
• 知識卡：Shadow Traffic
• 官方：AWS VPC Traffic Mirroring documentation