網路故障排除：VPC Flow Logs、ELB Logs 與連線診斷

VPC 網路疑難排解是 SOA-C02 的招牌技能。Task Statement 5.3——「對網路連線問題進行疑難排解」——白紙黑字出現在官方 Exam Guide v2.3，且是整個 AWS 準工程師考試家族中唯一這麼要求的考試。SAA-C03 負責設計網路；DVA-C02 負責使用網路；只有 SOA-C02 要求考生在一個視窗看著 VPC Flow Logs、另一個視窗看著 ELB access logs、同時在背景執行 Reachability Analyzer 來診斷故障的網路。TS 5.3 的每一道情境題讀起來都像一張作業單：EC2 無法連到 S3、ALB 間歇性回傳 502、VPN tunnel 顯示 UP 但流量歸零、Reachability Analyzer 報告「封鎖」卻沒說原因。VPC 網路疑難排解是唯一一個不熟悉流程就只能靠猜的主題。

本指南帶領 SysOps 工程師走完完整的診斷工具鏈：Flow Logs 在封包元資料層的 ACCEPT 與 REJECT 動作、ELB access logs 在 HTTP 層的 request_processing_time 與 target_status_code、CloudFront access logs 在邊緣節點的 x-edge-result-type、WAF web ACL logs 的封鎖請求調查、Reachability Analyzer 的主動路徑驗證、Network Access Analyzer 的存取範圍稽核、混合式 VPN tunnel 與 BGP 除錯、Direct Connect virtual interface 驗證，以及 ALB target group health check 調校。你也會看到 SOA-C02 反覆出現的情境型態：NACL ephemeral port 被拒、引用 peered VPC 內 SG 的安全群組、Flow Logs 不捕捉 link-local 流量，以及 health check timeout 大於 interval 的 ALB。VPC 網路疑難排解是運維偵探工作；這個主題給你完整的工具箱與作業手冊。

為什麼 TS 5.3 是 SOA-C02 的招牌 Domain

官方 SOA-C02 Exam Guide v2.3 在 TS 5.3 下列出四項技能：解讀 VPC 設定（含 subnets、route tables、NACLs、security groups）；收集與解讀日誌（含 VPC Flow Logs、ELB access logs、AWS WAF web ACL logs、CloudFront logs）；識別並修復 CloudFront 快取問題；以及排解混合式與私有連線問題。這四項技能沒有任何一項出現在其他準工程師考試中。SAA-C03 止步於「設定」；只有 SOA-C02 進一步要求「診斷設定遇上現實時發生了什麼」。

在 SysOps 層級，問題的框架是鑑識調查，而非架構設計。SAA-C03 問「架構師應該為 S3 選哪種 VPC endpoint？」SOA-C02 問「應用程式昨天還好好的，今天 03:14 停止運作；你能存取 Flow Logs 和 ALB access log bucket——第一步做什麼？」答案幾乎從來不是「重新設計 VPC」。答案是：讀 Flow Logs 裡的 REJECT 記錄，把 srcaddr 和 dstaddr 與 route tables 和 security groups 對照，然後執行 Reachability Analyzer 確認假設，或直接跳到 ELB target health 確認問題是否出在負載平衡器層。VPC 網路疑難排解是所有前面 SOA-C02 主題的匯合點：CloudWatch Logs Insights 查詢 Flow Logs（Domain 1）、EventBridge rule 在 Flow Log REJECT 激增時觸發 SSM Automation（Domain 1.2 與 3.2）、Config 標記過於寬鬆的 security groups（Domain 4.1）、ALB target health metric 驅動 Auto Scaling 決策（Domain 2）。網路疑難排解貫穿整場考試。

白話文解釋 VPC Network Troubleshooting

網路疑難排解的術語堆疊很快——five-tuple、ephemeral ports、BGP、idle timeout。三個類比能讓這些概念具體好記。

類比一：刑警辦案

VPC 網路疑難排解是刑警辦案。VPC Flow Logs 是門禁系統的錄影記錄——記錄了每個人在什麼時間從哪個方向進出、門禁系統是否放行（ACCEPT）或嗶了一聲拒絕（REJECT）。錄影不會告訴你為什麼拒絕——只記錄了拒絕這個事實——所以你必須把它和員工門禁名單（security groups）以及各樓層的進出規則（NACLs）合在一起，才能推斷出原因。ELB access logs 是警衛室的訪客登記簿：每個成功進到服務台的人都有記錄，包含到達時間、想找誰（target）、服務台花了多久打電話通報（processing time），以及最終的回應（status code）。CloudFront logs 是各地區辦事處的訪客簿。WAF logs 是門口保全的事件報告——列出所有試圖進入卻在門外就被規則擋下的人。Reachability Analyzer 是鑑識勘查——刑警從正門到金庫走一遍完整路線，打開每一扇內部門，精確回報是哪個環節卡死了。刑警從不憑感覺判斷；刑警讀日誌、走路徑，然後才能指名嫌疑人。

類比二：急診醫師的鑑別診斷

網路疑難排解是急診鑑別診斷。病患（應用程式）出現症狀（ALB 間歇性回傳 502）。醫師（SysOps 工程師）不急著下處方，而是先驗血：ELB access log 顯示 8% 的請求有 target_status_code = 502、target group health check 回報 healthy 9/10、CloudWatch 顯示 TargetResponseTime p99 飆升。醫師建立鑑別診斷：target keep-alive 比 ELB idle timeout 短（最常見）、security group 封鎖 ephemeral return port（較少見）、十台 target 中有一台崩潰（health check 已顯示）、資料庫連線池耗盡（會呈現 504 而非 502）。每個假設都可以用不同的日誌層來驗證。醫師靠資料縮小範圍，而非靠直覺。考題喜歡這個模式：給你症狀和三個日誌來源，問你第一個診斷步驟。

類比三：電工追查線路

混合式連線疑難排解是電工追查線路。VPN tunnel 是一條電線，連接機房端的交換器（客戶閘道器）與 AWS 機架（virtual private gateway 或 transit gateway）。這條電線上有幾個接線盒：Phase 1（IKE）認證是第一個接線盒，**Phase 2（IPSec SA）**是第二個，**路由設定（靜態或 BGP）**是第三個，機房端防火牆 ACL 是第四個。tunnel「狀態 UP」表示接線盒 1 和 2 成功——電線通電了——但「沒有流量」表示接線盒 3 或 4 有接點斷開。電工不會換整條電線；他從接線盒 1 開始逐一檢查，找到斷開的接點。Direct Connect 再多一層實體（機房設施的光纖跳接）和另一個路由層（每個 VIF 的 BGP session）。封包不通的時候，有系統的答案永遠是「按順序檢查每個接線盒」——絕不是「重建 tunnel」。

VPC Flow Logs 基礎：範圍、欄位與傳送目的地

在用 Flow Logs 疑難排解之前，你需要對 Flow Log 如何產生、記錄什麼、刻意省略什麼建立精確的心理模型。

三種範圍——VPC、subnet、ENI

Flow Log 可在三個範圍啟用：

• VPC 層級——捕捉 VPC 內每個 ENI 的流量。設定最簡單，但產出資料量最大。
• Subnet 層級——捕捉 subnet 內每個 ENI。適合只需要調查單一層（public、app、db）的情況。
• ENI 層級——最精準的範圍。調查範圍已縮小到單一 instance、NAT Gateway ENI、RDS ENI 或 VPC endpoint interface 時使用。

可以對同一範圍建立多個 Flow Log，設定不同的 filter 和目的地——例如一個 Flow Log 傳到 S3 做長期封存，另一個傳到 CloudWatch Logs 做即時 Logs Insights 查詢。

預設格式與自訂格式欄位

預設 Flow Log 格式記錄 14 個欄位：version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status。action 欄位值為 ACCEPT、REJECT 或 NODATA（匯總視窗內無流量）。log-status 欄位值為 OK、NODATA 或 SKIPDATA（生產者因容量問題丟棄了記錄）。

自訂格式（在預設格式之後推出）讓你可以新增最多 30 個欄位，包括：

• vpc-id, subnet-id, instance-id——新增父資源 ID，讓你可以與其他清單做 join。
• tcp-flags——位元遮罩（SYN=2, ACK=18, FIN=1, RST=4），用於 TCP 交握鑑識。
• type——IPv4、IPv6 或 EFA。
• pkt-srcaddr, pkt-dstaddr——IP 封包內部的封包層位址，不同於 srcaddr/dstaddr（ENI 層位址）。對於 NAT Gateway 和 Transit Gateway 流量，ENI 看到的是一個位址，封包 payload 裡帶的卻是另一個位址，這個差異至關重要。
• region, az-id, sublocation-type, sublocation-id——部署位置元資料。
• flow-direction——從 ENI 的視角看是 ingress（入埠）還是 egress（出埠）。
• traffic-path——整數代碼，標示封包走的路徑（through-IGW=1, through-VGW=2, through-VPC-peering=3, through-IGW-internet-gateway=4 等）。

自訂格式是 SOA-C02 的生產標準。最少要包含 vpc-id、instance-id、tcp-flags、pkt-srcaddr、pkt-dstaddr、flow-direction。

匯總間隔——預設 10 分鐘，可選 1 分鐘

Flow Logs 會在寫入記錄之前對流量進行間隔匯總。預設是 10 分鐘；另一個選項是 1 分鐘，在建立 Flow Log 時設定。1 分鐘間隔的資料量增加約三倍，但事故期間的即時排解不可或缺——等十分鐘是不現實的。

三種傳送目的地——CloudWatch Logs、S3、Kinesis Data Firehose

• CloudWatch Logs——最適合事故期間用 Logs Insights 進行即時查詢。每 GB 費用比 S3 高。
• S3——最適合長期封存與大量 Athena 查詢。支援 Parquet 格式，可降低 Athena 掃描費用。
• Kinesis Data Firehose——最適合將 Flow Logs 串流到 SIEM（Splunk、Datadog、OpenSearch）或有自訂轉換 Lambda 的資料湖。

SOA-C02 常見的雙傳送架構：一個 Flow Log 以 1 分鐘匯總傳到 CloudWatch Logs 做即時排解，另一個以 10 分鐘匯總傳到 S3（Parquet 格式）做封存與鑑識。

Flow Logs 不捕捉的流量

這份清單是考試的重點：

• 到達與來自 169.254.169.254 的流量（instance metadata service）。
• 到 Amazon DNS server 的流量（VPC CIDR 的 .2 位址）——使用 AWS 提供的 DNS 時不記錄，但到自訂 DNS resolver 的查詢會被記錄。
• DHCP 流量。
• 到預設 VPC router 保留 IP 的流量（VPC CIDR 的 .1 位址）。
• 鏡像流量（那是 VPC Traffic Mirroring 的工作）。
• Windows 授權啟用流量。

SysOps 工程師若根據「Flow Logs 無 DNS 流量」建立告警來偵測 VPC DNS 中斷，會撲空——AWS DNS resolver 的流量刻意不記錄。

Flow Log 分析：Logs Insights 與 Athena 查詢範本

捕捉 Flow Logs 只是一半的工作，另一半是在事故期間高效讀取它們。

CloudWatch Logs Insights 查詢

Flow Logs 傳到 CloudWatch Logs 時，Logs Insights 是正確的工具。選擇 Flow Log 格式後欄位會自動解析。每個 SOA 考生都應該認識的常用 Insights 查詢：

fields @timestamp, srcaddr, dstaddr, dstport, action
| filter action = "REJECT"
| stats count(*) as denies by srcaddr, dstport
| sort denies desc
| limit 20

這個查詢輸出「最近一小時被拒絕次數最多的前 20 組來源 IP 與目的 port」——連線事故第一個要跑的查詢。如果某個 ENI 主導了對 port 443 到 S3 的 REJECT，就表示 gateway endpoint 路由缺失。

fields @timestamp, srcaddr, dstaddr, bytes
| filter dstport = 443 and action = "ACCEPT"
| stats sum(bytes) as totalBytes by dstaddr
| sort totalBytes desc
| limit 10

這個查詢找出「按位元組量排序的前 10 個 443 目的地」——問題是「為什麼 NAT Gateway 資料處理費用暴增」時的正確查詢（答案通常是某個應用程式在和外部 SaaS 大量通訊，而不是使用 VPC endpoint）。

fields @timestamp, srcaddr, srcport, dstaddr, dstport, action
| filter dstport in [22, 3389] and action = "REJECT"
| stats count(*) as attempts by srcaddr
| sort attempts desc

這個查詢找出「SSH/RDP 暴力探測」——隨機來源對 port 22 或 3389 的 REJECT，用於安全加固。

透過 Athena 查詢 S3

對於跨天或跨週的長期保存與鑑識查詢，將 Flow Logs 以 Parquet 格式傳送到 S3，再用 Athena 查詢。設定步驟：

1. 啟用 Flow Log，目的地選 S3，格式選 custom，檔案格式選 Parquet，啟用 hive 相容分區。
2. 執行 MSCK REPAIR TABLE flow_logs;（或使用 partition projection）來註冊分區。
3. 透過 Athena 查詢：

SELECT srcaddr, dstaddr, dstport, sum(bytes) AS total_bytes
FROM flow_logs
WHERE action = 'REJECT'
  AND day >= '2026/04/24' AND day <= '2026/04/25'
  AND vpcid = 'vpc-0abc123'
GROUP BY srcaddr, dstaddr, dstport
ORDER BY total_bytes DESC
LIMIT 50;

Parquet 搭配 account-id/region/year/month/day 分區，相比純 JSON 或 CSV，Athena 掃描費用可降低 10 到 100 倍。

讀懂 Flow Log 記錄：ACCEPT、REJECT 的真正意涵

解讀 Flow Log 記錄是 SOA-C02 的核心技能。陷阱在於：ACCEPT 不代表「應用程式成功」，REJECT 也不一定代表「修 security group 就好」。

ACCEPT 不代表成功

ACCEPT 的意思是 security groups 與 NACLs 都放行了封包。它不代表目的地應用程式接受了連線。應用程式在交握後發出 TCP RST 仍會在 Flow Logs 裡顯示 ACCEPT，因為安全層放行了封包。應用程式層的失敗（HTTP 502、資料庫拒絕連線、TLS 交握錯誤）對 Flow Logs 來說是不可見的。這些情況需要 ELB access logs、應用程式日誌或 VPC Traffic Mirroring。

REJECT 表示 SG 或 NACL 至少一個拒絕

REJECT 不會說明是 security group 還是 NACL 拒絕了封包。分類處理流程：

1. 先檢查 security group 規則：SG 是有狀態的，允許出站流量的 SG 規則會自動允許回傳流量。如果 SG 看起來沒問題，繼續往下查。
2. 接著檢查 NACL 規則：NACL 是無狀態的，兩個方向都需要明確規則，包含 ephemeral return port（Linux 用 1024–65535，Windows/RFC 6056 用 49152–65535）。生產環境最常見的 NACL 錯誤是允許了入站 port 443，卻忘記在出站方向允許 ephemeral port 作為回傳路徑。
3. 用 Reachability Analyzer 確認：它會明確告訴你哪個規則（SG、NACL、route table 或其他）封鎖了路徑。

方向很重要

flow-direction = ingress 的 REJECT 表示入站規則拒絕了封包；flow-direction = egress 的 REJECT 表示出站規則拒絕了。沒有自訂格式的 flow-direction 欄位，你就必須從 srcaddr、dstaddr 和 ENI 主要 IP 的關係來推斷——在 Flow Log 中加上 flow-direction 可以省去一個分析步驟。

pkt-srcaddr vs srcaddr——NAT Gateway / TGW 的陷阱

預設的 srcaddr 和 dstaddr 是 ENI 所看到的位址。對於 NAT Gateway 流量，ENI 看到的是 NAT Gateway 本身的位址，而不是發起連線的 instance 私有 IP。自訂格式的 pkt-srcaddr 和 pkt-dstaddr 欄位顯示的是封包層位址，保留了原始發送方的資訊。Transit Gateway 與 VPC peering 流量也適用同樣原則。SOA-C02 直接測試過這個：「安全團隊能看到 NAT Gateway 存取 S3 一百萬次，但看不出是哪個 instance 發起的——怎麼修？」答案：在 Flow Log 自訂格式中加入 pkt-srcaddr。

ELB Access Logs：格式、狀態碼與時間欄位

症狀出現在 HTTP 層時（502、504、回應緩慢、TLS 交握失敗），Flow Logs 幫不上忙。你需要的是 ELB access logs。

啟用 ELB access logs

Access logs 預設關閉。需要針對每個 load balancer 設定 S3 bucket 目的地來啟用。ALB/NLB 每 5 分鐘寫一次日誌，CLB 則是每 5 分鐘或 60 分鐘。S3 bucket 必須設定 bucket policy，授予地區性 ELB log 傳送帳號 s3:PutObject 權限——bucket policy 設定錯誤是日誌遲遲未出現的最常見原因。

ALB access log 欄位（疑難排解關鍵欄位）

ALB access log 每行以空格分隔，重要欄位如下：

• type——http, https, h2, grpcs, ws, wss。
• time——ISO 8601 格式的請求時間戳記。
• elb——load balancer ARN 片段。
• client:port——客戶端 IP 與來源 port。
• target:port——後端 target IP 與 port。
• request_processing_time——從 ELB 收到請求到送出給 target 的秒數。應該很小（< 1ms）。數值高表示 ELB 在排隊。
• target_processing_time——從 ELB 送出請求到收到回應的秒數。即應用程式的處理時間。數值高指向後端緩慢。
• response_processing_time——從 ELB 收到回應到送給客戶端的秒數。應該很小；數值高表示網路出口競爭。
• elb_status_code——ELB 回傳給客戶端的 HTTP 碼。
• target_status_code——target 回傳給 ELB 的 HTTP 碼。
• received_bytes, sent_bytes——請求與回應大小。
• request——method、URI、協定。
• user_agent, ssl_cipher, ssl_protocol——客戶端元資料。
• target_group_arn, trace_id, domain_name, chosen_cert_arn, matched_rule_priority——路由元資料。
• error_reason——ELB 回傳 4xx/5xx 時填入；值如 LambdaThrottling、Target_FailedHealthChecks、Target_ConnectionError 會指出原因。

NLB access logs

NLB 只有 TLS 監聽器（在 NLB 終結 TLS）才支援 access logs。純 TCP/UDP 監聽器不產生 access logs，因為 NLB 不解析應用層協定。對於純 TCP 的 NLB，請在 target ENI 範圍使用 Flow Logs。

SOA-C02 常見的 ELB access log 題型

• 「ALB 回傳 502，團隊需要找出哪個 target 失敗。」→ 篩選 elb_status_code = 502 的 access log，以 target:port 做 stats count，找出失敗的 target IP。
• 「ALB 回傳 504——代表什麼？」→ target_processing_time 超過 target group 的 health check timeout 或監聽器的 idle timeout。增加 idle timeout（預設 60 秒）或修復緩慢的後端。
• 「p99 延遲偏高，但團隊不知道是 LB 還是應用程式的問題。」→ 加總 request_processing_time + target_processing_time + response_processing_time；target_processing_time 偏高就能隔離出問題在應用程式。

ALB Target Group 不健康目標——Health Check 作業手冊

ALB target health 出現症狀時，作業手冊是機械式的。按順序走完。

Health check 參數

ALB target group health check 針對每個 target group 設定，參數（與預設值）如下：

• Protocol——HTTP、HTTPS、gRPC。必須與 target 監聽 health-check endpoint 的協定一致。
• Port——traffic-port（使用已登錄的 port）或覆蓋 port。health endpoint 跑在獨立管理 port 上時用覆蓋。
• Path——HTTP/HTTPS 的 GET URI。預設 /。
• HealthCheckIntervalSeconds——兩次探測間的間隔。預設 30 秒，範圍 5–300。
• HealthCheckTimeoutSeconds——LB 等待回應的時間。預設 5 秒，範圍 2–120。
• HealthyThresholdCount——連續成功幾次才宣告健康。預設 5，範圍 2–10。
• UnhealthyThresholdCount——連續失敗幾次才宣告不健康。預設 2，範圍 2–10。
• Matcher——被視為健康的 HTTP 碼。預設 200。可設為 200-399、200,202 等。

八步診斷流程

目標不健康時，按清單逐一確認：

1. 確認 target 正在執行且應用程式正在監聽。 用 SSH/Session Manager 進入 instance，curl http://localhost:8080/health 確認應用程式有回應。
2. 確認 target 上的 security group 允許來自 ALB security group 的入站流量。 這是最常見的原因。target 的 SG 必須允許 ALB SG（而非 0.0.0.0/0——那樣雖然有效但不正確）的 health check port。
3. 確認 health check port 與已登錄的 port 一致，除非是刻意設定了覆蓋 port。
4. 確認路徑回傳 200（或 Matcher 指定的代碼）。若應用程式的 /health 因需要認證而回傳 401，LB 會視其為不健康。
5. 確認 timeout 小於 interval。 若 timeout（5s）大於 interval（3s），探測會排隊重疊，target 的健康狀態會不斷震盪。AWS 會做驗證——但考生會被考到這個關係。
6. 確認不健康閾值有考慮到合理的慢啟動。 需要 60 秒暖機的 web app，ASG 端需要更長的 HealthCheckGracePeriodSeconds，加上足夠高的不健康閾值，避免在開機期間就殺掉 target。
7. 確認 subnet/route table 允許 ALB 到 target 的連線。 跨 AZ 沒問題；跨 VPC 需要 VPC peering 以及兩側一致的 route table。
8. 確認 target 的回應內容是可接受的。 有些應用程式回傳 200 但內文顯示軟性失敗（「status:degraded」）。LB 看到 200 就標記健康。使用 Matcher 要求正確的狀態碼，並讓應用程式在降級時回傳 503。

Reason code

ALB 主控台（以及 DescribeTargetHealth API 的 Reason 欄位）回傳的代碼如下：

• Target.FailedHealthChecks——target health check 失敗（通用情況）。
• Target.Timeout——target 未在 HealthCheckTimeoutSeconds 內回應。
• Target.ResponseCodeMismatch——target 回傳的狀態碼不在 Matcher 範圍內。
• Target.NotInUse——target group 未與 load balancer 關聯。
• Target.NotRegistered——target 已取消登錄。
• Target.HealthCheckDisabled——target group 未啟用 health check。
• Elb.InitialHealthChecking——首次登錄後仍在執行初始探測。

這些代碼會直接出現在 SOA-C02 題目中：題目可能給你 Target.Timeout，問你最可能的修復方式（增加 HealthCheckTimeoutSeconds 或修復緩慢的應用程式）。

Reachability Analyzer——主動路徑驗證

VPC Reachability Analyzer 依需求計算，在目前 VPC 組態下，封包能否從來源 ENI（或 instance、internet gateway、transit gateway attachment、VPN gateway）抵達目的地 ENI。它不發送任何實際流量；它分析組態圖。

分析範圍

針對指定的來源、目的地、協定與 port，Reachability Analyzer 評估：

• 來源與目的地的 security group 規則。
• 路徑上每個 subnet 的 Network ACL 規則。
• 路徑上每個 subnet 的 route table。
• Internet gateway、NAT gateway、VPC endpoint、VPC peering、Transit Gateway、virtual private gateway 的路由。
• Prefix list 與 elastic load balancer 路由邏輯。

輸出結果是 Reachable（含逐步路徑，逐 subnet、逐跳點列出每個 ENI 與允許流量的規則），或 Not reachable（含 Explanation Codes 欄位，指出封鎖路徑的具體組態物件，例如 BLOCKED_BY_SECURITY_GROUP_RULE 加上 SG ID、BLOCKED_BY_NETWORK_ACL_RULE 加上 NACL ID、NO_ROUTE_TO_DESTINATION 加上遺失的 route table）。

何時使用 Reachability Analyzer

• 部署前驗證——在啟動新微服務之前，確認 ALB 能到達新的 target group，且 target 能到達資料庫。
• 事故分流——Flow Logs 顯示 REJECT，但需要找到具體規則才能修復。
• 合規查核——在稽核時確認「不存在從公共網際網路到 RDS 的路徑」。
• 變更管理——每次 NACL 或 route table 變更後重新執行，偵測是否發生退化。

費用

Reachability Analyzer 按分析次數收費（目前每次 $0.10）。對於每天執行數百次分析的 CI/CD pipeline 可能累積不少；對事故分流來說微不足道。

限制

Reachability Analyzer 無法分析：

• 應用層安全（WAF 規則、應用程式回傳 403）。它純粹是網路層服務。
• DNS 解析失敗。它只分析 IP 路由。
• 跨 Region 路徑。來源與目的地必須在同一 Region。
• 跨 transit firewall 的非對稱路由。它假設回傳路徑是對稱的。

應用層問題使用 ELB access logs 和 WAF logs；DNS 問題使用 Route 53 Resolver query logging。

Network Access Analyzer——存取範圍稽核

Network Access Analyzer 是 Reachability Analyzer 的稽核側補充。Reachability Analyzer 回答「A 能到達 B 嗎？」，Network Access Analyzer 回答「在整個 VPC 中，集合 X 到集合 Y 之間是否存在任何路徑？」

Access Scope

你以 JSON 定義一個 Access Scope，指定：

• Source——分析將哪組資源或位址視為起點（例如「internet gateway」或「0.0.0.0/0 的任意位址」）。
• Destination——分析將哪組資源視為目標（例如「任意 RDS instance」或「標記 tier=db 的 subnets」）。
• MatchPaths / ExcludePaths——額外的路徑限制條件。

執行 Access Scope 後，Network Access Analyzer 會列舉所有符合條件的路徑。對於「不得有從 internet 到 db 層的路徑」，預期結果是空的；任何非空結果都會指出違規的路由、SG 或 NACL。

內建 Access Scope

AWS 提供了常見稽核問題的預設 scope：

• Internet Inbound——哪些網際網路來源能到達哪些內部資源。
• Internet Outbound——哪些內部資源能到達網際網路。
• Internal Network Inbound——從機房端（透過 VPN/DX）到 AWS 資源的路徑。
• Internal Network Outbound——從 AWS 到機房端的路徑。
• Trusted Resources——定義受信任集合，找出所有從非受信任到受信任的路徑。

使用情境

• 合規稽核——以內建 Internet Inbound scope 篩選 PCI 標籤，驗證結果為空，以此證明「PCI 範圍無網際網路入站」。
• 合併前的網路審查——新增 VPC peering 或 Transit Gateway attachment 時，稽核它開啟了哪些新路徑。
• 持續合規——透過 Lambda 和 EventBridge 排程執行 Network Access Analyzer，在開發人員新增過寬的 SG 規則時偵測退化。

Reachability Analyzer vs Network Access Analyzer——最清晰的區分

CloudFront 日誌與快取問題診斷

CloudFront 有兩種日誌層級：標準 access logs（每隔幾分鐘傳送到 S3，包含所有欄位，費用低）和即時日誌（透過 Kinesis Data Streams 串流，可設定欄位子集，費用較高，延遲低於一秒）。

標準 access log 欄位（關鍵欄位）

• date, time, x-edge-location——時間與地點（例如 IAD89 = Ashburn POP）。
• c-ip——觀看者客戶端 IP。
• cs-method, cs-uri-stem, cs-uri-query——請求行。
• cs(Host), cs(User-Agent), cs(Referer)——請求 headers。
• sc-status——回傳給觀看者的狀態碼。
• sc-bytes, cs-bytes——回應與請求大小。
• time-taken——邊緣節點完整服務回應所需的總時間。
• x-edge-result-type——邊緣節點的處理結果。值：
  • Hit——從邊緣快取提供。
  • RefreshHit——快取有舊版本，重新向 origin 驗證後提供。
  • Miss——快取中沒有，從 origin 取得。
  • LimitExceeded, CapacityExceeded——反壓力。
  • Error——回傳錯誤（查看 sc-status）。
  • Redirect——CloudFront 回傳重新導向。
• x-edge-detailed-result-type——更細的細節（例如 OriginShieldHit、MissGeneratedResponse）。
• x-edge-response-result-type——回應側的結果。
• cs-protocol, ssl-protocol, ssl-cipher——TLS 元資料。

常見快取問題診斷

• 「使用者看到過期內容」——origin 已更新，但觀看者仍看到舊版本。原因：Cache-Control: max-age 過長（或 cache behavior 的預設 TTL 過長），且未執行 invalidation。修復：建立 invalidation（/path/* 模式），縮短 origin 對該路徑的 Cache-Control，或使用版本化 URL（/v2/asset.js）讓新 URL 成為全新的 cache key。
• 「Cache hit ratio 低」——x-edge-result-type 大量顯示 Miss。原因：cache policy 中未正規化 query string 差異、forwarded cookies（每個唯一的 cookie 值都建立新的 cache key）、origin 傳回 Cache-Control: no-store。修復：使用 cache policy 只正規化有意義的 query string；設定 origin 不對可快取資源傳送 no-store。
• 「部分使用者看到不同地區的內容」——這是設計使然；CloudFront 從最近的 POP 提供服務。如果沒有使用 CloudFront-Viewer-Country 請求 header，origin 回應不應依賴觀看者地理位置。
• 「CloudFront 回傳 504」——origin 回應時間超過 origin 回應 timeout（預設 30 秒，ALB origin 最高可設 60 秒，自訂 origin 更長）。修復：加快 origin 速度或增加 timeout。

即時日誌

事故期間 5 分鐘的日誌傳送太慢時，在 cache behavior 上設定即時日誌組態。選擇欄位、抽樣率（1–100%）以及 Kinesis Data Stream 目的地。即時日誌在幾秒內就會落到 Kinesis，可由 Lambda、Kinesis Data Analytics 或 OpenSearch 消費，實現亞分鐘級事故分流。

AWS WAF Web ACL 日誌

WAF 記錄 Web ACL 評估的每個請求，包含匹配的規則和採取的動作。目的地可以是 CloudWatch Logs、S3 或 Kinesis Data Firehose。

關鍵欄位

• timestamp, webaclId, terminatingRuleId, terminatingRuleType, action（ALLOW, BLOCK, COUNT, CAPTCHA, CHALLENGE）。
• httpRequest——包含客戶端 IP、國家、headers、URI、參數的區塊。
• ruleGroupList——每個被評估的 rule group，以及採取的動作。
• nonTerminatingMatchingRules——匹配但僅設定 Count 而非 Block 的規則。

診斷模式

• 「合法使用者被 WAF 封鎖」——查詢 action = BLOCK 且有該使用者 IP 的日誌，找到 terminatingRuleId。如果是 AWS 受管規則（例如 AWSManagedRulesCommonRuleSet/SizeRestrictions_BODY），評估是否要縮小規則範圍（排除特定路徑）或先設成 Count 以評估影響。
• 「速率限制規則封鎖過於激進」——調整限制值、縮小到特定 URI 模式，或為已知合作夥伴新增 IP set 例外。
• 「Bot 繞過 WAF」——將可疑規則從 Block 切換為 Challenge 或 CAPTCHA，監控日誌中的結果。
• 「需要找出 SQL injection 嘗試」——查詢 terminatingRuleId 符合 SQLiRuleSet 的記錄，依 httpRequest.clientIp 分組。

WAF logs vs Flow Logs

Flow Logs 只看到 5-tuple。WAF logs 看到完整的 HTTP 請求，包含 headers、query string 和 body 片段。對於 Layer 7 攻擊（SQLi、XSS、應用程式濫用），只有 WAF logs 能幫得上忙。

混合式連線疑難排解：Site-to-Site VPN

Site-to-Site VPN 透過兩條冗餘 IPsec tunnel（每個 VPN 連線），連接機房端網路與 VPC，終止於 virtual private gateway（VGW）或 transit gateway（TGW）。

Tunnel 狀態機

Tunnel 經歷以下階段：

1. DOWN——無 IPsec 關聯。
2. Phase 1（IKE）協商——認證與金鑰交換。常見失敗：pre-shared key 不一致、IKE 版本不一致（v1 vs v2）、加密/完整性演算法不一致、lifetime 不一致。AWS 在 tunnel 選項中公佈了支援的演算法組合。
3. Phase 2（IPsec SA）建立——實際的資料 SA。常見失敗：PFS group 不一致、加密演算法不一致、traffic selector（interesting traffic）不一致。
4. UP——tunnel 已建立。如果路由設定正確，流量現在可以通行。

aws ec2 describe-vpn-connections API 回傳每個 tunnel 的 Status 和 StatusMessage。最有診斷價值的字串是 IKE_PHASE1_DOWN、IPSEC_PHASE2_DOWN，以及協商參數不一致的訊息。

Tunnel UP 但無流量——路由問題

Tunnel UP 表示 Phase 1 和 Phase 2 成功。若流量仍無法通行，原因是以下之一：

• VPC route table 沒有指向機房端 CIDR 且目標為 VGW 或 TGW attachment 的路由。新增路由（或為動態 VPN 啟用路由傳播）。
• 機房端 route table 沒有指向 VPC CIDR 且目標為客戶閘道器 IP 的路由。這是機房端網路團隊的責任。
• 客戶閘道器防火牆在流量抵達 IPsec 介面之前就丟棄了。確認 ACL 允許 AWS 端 CIDR。
• VPC subnet 上的 NACL 封鎖了入站封包。VGW 路由將封包送到 subnet；NACL 仍然適用。
• 目的地 instance 上的 security group 封鎖了來自機房端 CIDR 的入站封包。
• BGP session DOWN（如果設定了動態路由）——Phase 2 可能 UP 但 BGP session 沒建立，此時 AWS 不會學習機房端路由。檢查 aws ec2 describe-vpn-connections 是否有 BGP_STATUS = ESTABLISHED。
• 兩條 tunnel 的非對稱路由——封包從 tunnel 1 出去，從 tunnel 2 回來；某些機房端防火牆會丟棄非對稱流量。

BGP session 診斷

動態路由時，BGP 是 AWS 與客戶閘道器用來廣告路由的協定。BGP session 與 IPsec tunnel 相互獨立——Phase 2 可以 UP 而 BGP DOWN。常見 BGP 問題：

• ASN 不一致——客戶閘道器設定了錯誤的 AWS ASN（VGW 預設 64512，可自訂）或錯誤的機房端 ASN。
• Hold timer 不一致——預設值通常沒問題，但自訂值必須兩側一致。
• 認證不一致——只有一側設定了 MD5 密碼。
• 路由廣告篩選——機房端只廣告特定前綴；AWS 無法學習到完整的機房端網路。

CloudWatch metric TunnelState（1=UP, 0=DOWN）以及每條 tunnel 的 TunnelDataIn/TunnelDataOut 位元組計數器，是監控的必備指標。

混合式連線疑難排解：Direct Connect

Direct Connect（DX）以私有光纖連線取代 VPN，連接客戶網路與 AWS Direct Connect 設施。DX 疑難排解涉及實體層、鏈路層與路由層。

三層架構

1. 實體層——機房設施的光纖跳接。AWS 主控台以 connectionState（pending, available, down 等）回報狀態，合作夥伴 DC 也會回報。常見問題：跳接尚未完成、光纖 Tx/Rx 光強度超出規格、MTU 不一致。
2. 鏈路層——每個 VIF 上的 BGP-over-Ethernet 交握。每個 VIF 的 bgpStatus 回報狀態。常見問題：VLAN ID 不一致、BGP ASN 不一致、BGP MD5 密碼不一致。
3. 路由層——即使 BGP UP，流量也只有在 AWS 端 route table 和機房端 route table 一致時才能通行。

VIF 類型

• Public VIF——用於透過 DX 連接 AWS 公共服務（S3、DynamoDB）。廣告客戶擁有的公共前綴。
• Private VIF——將 DX 連到單一 VPC 的 virtual private gateway。一個 Private VIF 對應一個 VPC。
• Transit VIF——將 DX 連到 Direct Connect Gateway，再分散到多個 Transit Gateway 與跨 Region 的多個 VPC。

DX 的 CloudWatch metrics

ConnectionState, ConnectionBpsEgress, ConnectionBpsIngress, ConnectionLightLevelTx, ConnectionLightLevelRx, ConnectionPpsEgress, ConnectionPpsIngress, ConnectionErrorCount。光強度特別有參考價值——光纖劣化或接頭髒污在連線中斷之前，就會先以 Tx/Rx 值漂移的形式顯現。

常見 DX 問題

• VIF 卡在 pending——客戶路由器尚未建立 BGP。確認客戶端的 VLAN、ASN、IP 位址設定。
• VIF available 但無流量——與 VPN 相同的路由確認清單：VPC route table、機房端 route table、NACL、SG。另外，對於 Transit VIF，Direct Connect Gateway 和 Transit Gateway 必須有傳播路由。
• DX 上的高延遲或封包遺失——檢查 ConnectionLightLevel、ConnectionErrorCount、MTU（DX 支援 jumbo frame 9001/8500，視連線類型而定——不一致會導致封包分割）。
• DX 故障切換到 VPN 備援不成功——DX 和 VPN 必須廣告相同前綴，且機房端路由器必須偏好 DX（通常透過 BGP local-preference），讓 VPN 成為備援。定期撤回 DX 前綴來測試 VPN 是否接管。

情境模式：EC2 無法透過 Gateway VPC Endpoint 到達 S3

SOA-C02 最常見的網路故障單作業手冊。

1. 確認 endpoint 存在且類型為 Gateway。 S3 同時支援 Gateway（免費，以 route table 為基礎）和 Interface（PrivateLink，付費，以 ENI 為基礎）。私有 subnet 需要低成本連接 S3 時，SOA 的預設答案是 Gateway。
2. 確認與 EC2 subnet 關聯的 route table 有指向 gateway endpoint 的 S3 prefix list 路由項目。 這是最常見的遺漏。只有在 endpoint 建立時選擇了 route table，路由才會自動新增。如果先建立 endpoint 再忘記關聯 route table，路由永遠不會被加入。
3. 確認 endpoint policy 允許對目的 S3 bucket 執行所需的 S3 動作。 預設 policy 是 *:*；收緊的 policy 常常漏掉特定的 bucket ARN。
4. 確認 EC2 上的 security group 允許對 S3 prefix list 的出站 HTTPS（port 443）（或在尚未加固時允許 0.0.0.0/0）。注意：出站 SG 規則可以引用 AWS 受管 prefix list（com.amazonaws.region.s3），這是 SOA 的標準答案。
5. 確認 bucket policy（以及任何 SCP）不拒絕存取。 常見的生產陷阱：bucket policy 設定了 Condition: aws:SourceVpce = vpce-... 要求透過特定 endpoint 請求，而 EC2 使用的 endpoint ID 與預期不符。
6. 確認 DNS 解析。 Gateway endpoint 依賴標準 S3 hostname bucket.s3.region.amazonaws.com 解析到 S3 IP，這些 IP 必須在 prefix list 內。VPC 必須啟用 enableDnsHostnames 和 enableDnsSupport。
7. 確認 Flow Logs 沒有顯示從 EC2 ENI 到 S3 IP 的 REJECT。 如果有，對 EC2 ENI 和相應的 S3 prefix list 位址執行 Reachability Analyzer。

解決方案幾乎總是步驟 2（缺少路由）或步驟 4（SG 出站封鎖）。Reachability Analyzer 可以精確指出原因，無需手動逐一排查。

情境模式：ALB 間歇性回傳 502

急診鑑別診斷作業手冊。

1. 取出 ALB access logs 並篩選 elb_status_code = 502。 依 target:port 分組，找出問題後端。如果某個 target 佔大多數，該 target 已降級；將其取消登錄並替換。
2. 檢查 error_reason。 值：
   • Target_ConnectionError——TCP 連線失敗。很可能是 target SG 或 NACL 問題，或 target 已崩潰。
   • Target_FailedHealthChecks——target 不健康但 ALB 仍嘗試連接；正常情況下不應發生（target 應已取消登錄）。檢查 health check 調校。
   • Target_TLSHandshakeError——ALB 與 target 之間的 TLS 問題（HTTPS target group）。憑證過期或憑證鏈損壞。
3. 檢查 target_status_code。
   • target_status_code = 502 表示 target 本身回傳了 502（它自己的上游損壞了）。
   • target_status_code = "-" 表示 ALB 從未收到回應——連線或 TLS 失敗。
4. 檢查 keep-alive 設定。 最常見的 502 原因是 target 的 keep-alive timeout 比 ALB 的 idle timeout 短。ALB 重用連線；後端已關閉它；ALB 在過期的連線上送出請求，得到 TCP RST；ALB 回傳 502 給客戶端。修復：將 target 的 keep-alive timeout 設定為大於 ALB idle timeout（ALB 預設 idle = 60 秒；許多後端預設 5–30 秒）。
5. 檢查 target 的 health check grace period。 Auto Scaling 期間，如果新 instance 在就緒之前就被登錄，ALB 會傳送真實流量並收到 502，直到應用程式啟動完成。增加 ASG 的 HealthCheckGracePeriodSeconds。
6. 檢查 target 上的 security group。 必須允許來自 ALB SG 對 target port 的入站流量。
7. 檢查 VPC subnets。 ALB 需要至少 2 個 AZ 各 1 個 subnet；target subnet 必須有到 ALB subnet 的路由（通常在同一個 VPC，所以是顯而易見的）。
8. 檢查應用程式日誌。 請求進行中崩潰的 target 會回傳 502 給 ALB。應用程式崩潰 dump 是最終的判斷依據。

大多數生產環境的 502 風暴追溯到步驟 4（keep-alive 不一致）——修復一次問題就消失了。

情境模式：VPN Tunnel UP 但無流量

電工追查線路作業手冊。

1. 透過 CloudWatch TunnelState = 1 確認 tunnel 確實 UP（每個 VPN 連線有 2 條 tunnel——一條可能 UP 一條 DOWN，應用程式可能雜湊到 DOWN 的那條）。
2. 確認 BGP session 是 ESTABLISHED（如果是動態路由）。若不是，流量無法通行，因為路由未被學習。
3. 確認 EC2 subnet 的 VPC route table 有指向機房端 CIDR 且目標為 VGW（VPN-to-VGW）或 TGW attachment（VPN-to-TGW）的路由。BGP 時路由應已傳播；靜態時路由必須手動新增。
4. 確認機房端 route table 有指向 VPC CIDR 且透過客戶閘道器 IP / DX VIF 的路由。
5. 確認 VPC subnet 上的 NACL 允許來自機房端 CIDR 的入站流量，以及到機房端 CIDR 的出站流量（包括回傳流量的 ephemeral port）。
6. 確認目的地 EC2 上的 security group 允許來自機房端 CIDR 的入站流量。
7. 確認機房端防火牆 允許流量到 AWS 端 CIDR；機房端防火牆是鏈路中最不透明的環節——一定要與機房端團隊確認，而不是假設。
8. 執行 Reachability Analyzer，分析從機房端 endpoint（以 VGW 或 TGW attachment 表示）到 VPC 目的地 ENI 的路徑。如果 Reachability Analyzer 說可達但流量仍失敗，問題在機房端；如果指出 AWS 端的具體封鎖者，就在那裡修復。

順序很重要。從 AWS 端向外排查（步驟 1–6）能解決 80% 的問題；其餘 20% 是機房端防火牆（步驟 7）。Reachability Analyzer（步驟 8）確認 AWS 端路徑無誤。

情境模式：Reachability Analyzer 顯示封鎖——為什麼？

Reachability Analyzer 回傳「Not reachable」時，Explanation Codes 欄位會指名原因。常見代碼及修復方式：

• BLOCKED_BY_INGRESS_NACL_RULE / BLOCKED_BY_EGRESS_NACL_RULE——指出拒絕的 NACL ID 和規則編號。修復 NACL 或將 deny 改為 allow。
• BLOCKED_BY_SECURITY_GROUP_RULE——沒有 SG 規則允許此路徑。新增規則。常見陷阱：SG 引用了另一個 SG（sg-abc），而那個 SG 在 peered VPC 中；跨 VPC peering 的 SG 引用只在同一 Region 有效，且需要明確啟用。透過 Transit Gateway 連接的 VPC 不支援跨 VPC SG 引用——必須改用 IP 位址（CIDR）。
• NO_ROUTE_TO_DESTINATION——路徑上某個 subnet 的 route table 沒有目的地 CIDR 的路由項目。新增路由或修復路由傳播。
• BLACKHOLE_ROUTE_TO_DESTINATION——路由存在但指向已刪除的目標（例如 NAT Gateway 已刪除但路由未更新）。移除或更新路由。
• MAX_TRANSIT_GATEWAY_ATTACHMENT_LIMIT_EXCEEDED / 類似的限制錯誤——服務配額問題。
• ENI_SECURITY_GROUP_RULES_DENY——ENI 本身的 SG 規則拒絕了流量。
• THROUGH_RESOURCE_NOT_REACHABLE——中繼資源（TGW、peering、endpoint）從來源無法到達。

修復方式由 explanation code 指名；不需要猜測。SOA-C02 可能在題目中給你 explanation code，問你應採取的修正動作。

常見陷阱：NACL Ephemeral Port 被拒

NACL 是無狀態的——它獨立評估入站和出站規則。客戶端發出出站 HTTPS 請求時，請求從 port 443 送出（出站規則允許），但回傳流量會回到 OS 選擇的高位 ephemeral port：

• Linux kernel 使用範圍 32768–60999（Linux ephemeral range）。
• Windows Server 2008+ 使用範圍 49152–65535（按 RFC 6056）。
• AWS NLB 在做 source NAT 時使用範圍 1024–65535。

保守的生產規則是在 NACL 入站方向允許 1024–65535 作為回傳流量。SysOps 工程師若設定了嚴格的出站規則（例如只允許 443），卻忘記入站 ephemeral allowance，就會遇到看起來像封包遺失的隨機連線失敗。Flow Logs 會顯示高位來源 port 的 REJECT——這是指紋。

這個陷阱考試重點測試。考試正確答案是「NACL 出站允許 443 但 NACL 入站不允許 ephemeral port——新增入站 1024–65535」。

常見陷阱：Security Group 跨 VPC 引用

Security group 規則可以引用另一個 security group 作為來源：允許入站 443 來自 sg-abc。這很方便——它是動態的，會跟隨來源 instance 不論其 IP 為何。但有一個微妙的限制：在 peered VPC 中引用 SG 是支援的，但跨 VPC peering 的引用只在同一 Region 有效，且不支援 Transit Gateway。如果你有 TGW 連接兩個 VPC，並試圖在 VPC B 的 SG 規則中引用 VPC A 的 SG，這會失敗——你必須改用 IP 位址（CIDR）。

Reachability Analyzer 會將此標記為 BLOCKED_BY_SECURITY_GROUP_RULE，並說明被引用的 SG 從目的地 VPC 不可見。在 TGW 環境下的修復方式是在 SG 規則中使用 CIDR 範圍而非 SG 引用。SOA-C02 直接測試過這個。

常見陷阱：Flow Logs 不捕捉 Link-Local 流量

Flow Logs 不捕捉的流量類型，因為會出現在考試中所以重複列出：

• Instance metadata service（169.254.169.254）。
• Time service（169.254.169.123）。
• Amazon DNS server（VPC CIDR 的 .2 位址）。
• DHCP（UDP 67/68）。
• VPC 預設 router（VPC CIDR 的 .1 位址）。
• 鏡像流量（改用 VPC Traffic Mirroring）。
• Windows 授權啟用（KMS）。

SysOps 工程師若在 Flow Logs 上建立「無 DNS 流量」告警來偵測 VPC DNS 中斷，會完全錯過問題——那些查詢從未被記錄。正確的工具是 Route 53 Resolver query logging（用於 DNS）和 VPC Traffic Mirroring（用於完整封包捕捉）。

常見陷阱：ALB Health Check Timeout > Interval

ALB target group health check 有兩個時間參數：

• HealthCheckIntervalSeconds——探測頻率。
• HealthCheckTimeoutSeconds——等待回應的時間。

主控台強制 Timeout < Interval。若情況相反，探測會排隊重疊，永遠無法得出乾淨的判斷。看到「interval = 5, timeout = 10」時應立即認出這是不可能的設定。修復：將 timeout 設定為嚴格小於 interval，典型 web app 用 interval = 30, timeout = 5，快速失敗的 health endpoint 用 interval = 10, timeout = 3。推論：target 在健康與不健康之間震盪時，原因通常是 health endpoint 真的需要 4–6 秒，而 timeout 是 5 秒——差異隨機地跨越閾值。

常見陷阱：ELB Idle Timeout vs 後端 Keep-Alive

ALB 的 idle timeout（預設 60 秒）是 ALB 在關閉閒置連線前保持開啟的時間。Target 的 keep-alive timeout（依應用程式而異——Apache 5 秒、NGINX 75 秒、Node.js 5 秒、Tomcat 60 秒）是 target 在關閉閒置連線前保持開啟的時間。如果 target 的 keep-alive 比 ALB 的 idle timeout 短，target 先關閉；ALB 仍認為連線開著；下一個請求收到 TCP RST，ALB 回傳 502 給客戶端。修復方式是將 target 的 keep-alive timeout 設定為大於 ALB idle timeout（例如 NGINX keepalive_timeout 75s 對應 ALB 預設 60s 並留有餘裕）。這是 SOA-C02 疑難排解中影響最大的知識點之一，解釋了生產環境中大量間歇性 502 的根本原因。

SOA-C02 vs SAA-C03：網路疑難排解屬於 SOA

SAA-C03 幾乎不測試疑難排解；SOA-C02 完全擁有這個技能領域。

SAA 考生選擇服務；SOA 考生讀日誌、排查各層，並修復原因。

考試訊號：Domain 5.3 的題型模式

TS 5.3 的題目遵循可預測的形狀。認識它們，你就能把閱讀時間砍半。

• 「診斷……的第一步是什麼」——正確答案幾乎總是 Reachability Analyzer（連線問題）或讀取對應日誌（L3/L4 用 Flow Log、HTTP 用 ELB access log、L7 用 WAF log）。避免選「重新設計網路」。
• 「應用程式可以連線但很慢……」——答案在 ELB access log 的時間欄位（request_processing_time, target_processing_time, response_processing_time）或 RDS Performance Insights 中。延遲問題很少是 security group 的問題。
• 「Tunnel UP 但無流量……」——答案是路由（VPC route table、機房端 route table、BGP session），不是 IPsec。
• 「Target 間歇性不健康……」——答案是 health check 調校（timeout vs interval、閾值計數）或 keep-alive 不一致。
• 「Cache miss ratio 過高……」——答案是 CloudFront cache policy（query strings、cookies、headers）或 origin 的 Cache-Control headers。
• 「稽核：不得有從 X 到 Y 的路徑……」——答案是 Network Access Analyzer 搭配定義的 Access Scope，而不是手動審查 VPC。
• 「團隊需要知道 NAT Gateway 後面哪個 instance 存取了 S3……」——答案是 Flow Logs 自訂格式加上 pkt-srcaddr，在 NAT Gateway ENI 上啟用。

決策矩陣——每種症狀用哪個工具

考試中作為查詢表使用。

常見陷阱回顧——VPC 網路疑難排解

每次 SOA-C02 考試都會遇到兩三個這些干擾選項。

陷阱 1：Flow Logs 會指名封鎖的規則

不會。Flow Logs 回報 ACCEPT 或 REJECT，不告訴你是哪個 SG/NACL 規則做的決定。Reachability Analyzer 才會指名規則。

陷阱 2：Flow Logs 中的 ACCEPT 代表應用程式成功

它只代表 SG 和 NACL 允許了封包。應用程式仍然可以回傳 502、中斷連線或 TLS 失敗——這些對 Flow Logs 來說是不可見的。

陷阱 3：詳細監控或預設監控會影響 Flow Logs

Flow Logs 獨立於 EC2 metric 監控。它們依 Flow Log 設定以 1 分鐘或 10 分鐘匯總，與 EC2 metric 設定無關。

陷阱 4：SG 引用可以跨 Transit Gateway 使用

不行。SG 對 SG 引用只在同一 VPC 內，或跨同一 Region VPC peering（需明確啟用）有效。對於 TGW 連接的 VPC，在 SG 規則中使用 CIDR 範圍而非 SG 引用。

陷阱 5：NACL 是有狀態的

NACL 是無狀態的。入站和出站規則都必須設定，包含 ephemeral return port（1024–65535）。

陷阱 6：VPN tunnel UP 表示流量正在通行

UP 表示 Phase 1 和 Phase 2 成功。流量還需要兩端路由設定正確，以及動態路由的 BGP session ESTABLISHED。

陷阱 7：Direct Connect 預設加密

不是。DX 是私有的，但在 AWS 服務邊緣不加密。用 VPN-over-DX 或 MACsec 才有加密。

陷阱 8：Reachability Analyzer 可以分析跨 Region 路徑

不行。來源和目的地必須在同一 Region。跨 Region 需要多次分析手動合併，或使用 Network Access Analyzer。

陷阱 9：Network Access Analyzer 與 Reachability Analyzer 相同

Reachability Analyzer 是一對一（特定來源 ENI 到特定目的地 ENI）。Network Access Analyzer 是集合對集合（Access Scope 定義的資源集合之間）。根據題型選對工具。

陷阱 10：ALB health check timeout 可以大於 interval

不行——主控台會拒絕這個設定。Timeout 永遠嚴格小於 interval。只有在干擾選項中才會看到這種設定形狀。

陷阱 11：Flow Logs 捕捉 VPC 內的所有流量

不捕捉 instance metadata、AWS DNS、DHCP、預設 router、鏡像流量或 KMS 授權啟用流量。DNS 用 Route 53 Resolver query logging；完整封包用 VPC Traffic Mirroring。

陷阱 12：CloudFront x-edge-result-type 顯示「Hit」保證內容是最新的

Hit 表示在快取 TTL 內是新鮮的。如果 TTL 過長而 origin 已更新，Hit 會繼續提供過期內容，直到快取項目過期或執行 invalidation。

FAQ——VPC 網路疑難排解

Q1：什麼時候用 Reachability Analyzer，什麼時候讀 Flow Logs？

當你需要知道路徑為什麼能通或不通——它會指名具體的允許或封鎖規則（SG、NACL、route table）——用 Reachability Analyzer。當你需要知道封包層面實際發生了什麼——哪些連線被嘗試，每個是否被接受或拒絕——用 Flow Logs。事故期間的組合工作流：Flow Logs 說「REJECT from 10.0.1.5 to 10.0.2.10:443」；Reachability Analyzer 對那兩個 ENI 說「BLOCKED_BY_SECURITY_GROUP_RULE on sg-abc rule 3」；你修復 sg-abc rule 3。Flow Logs 是回顧性的，Reachability Analyzer 是前瞻性的——兩者都有用，按這個順序。

Q2：為什麼 ALB 在 target 健康的情況下仍然回傳 502？

最常見的原因是 keep-alive 不一致：target 的 keep-alive timeout 比 ALB 的 idle timeout（預設 60 秒）短。ALB 在請求結束後保持連線；target 關閉了它；ALB 試圖重用過期的連線並得到 TCP RST；ALB 回傳 502 給客戶端。修復方式是將 target 的 keep-alive timeout 設定為大於 ALB idle timeout——例如 NGINX keepalive_timeout 75s 對應預設 ALB idle 60s。ALB access logs 中 error_reason = Target_ConnectionError 且 target_status_code = "-" 是這個問題的指紋。其他 502 原因包括：target 本身回傳 502（它的上游損壞了）、TLS 交握失敗（HTTPS target group），以及 ALB 到 target 的 SG 規則缺失。

Q3：使用者回報「網站在亞洲很慢但在美國很快」——往哪裡查？

三種可能，每種對應不同的日誌層。(a) CloudFront 邊緣選擇——亞洲的使用者被路由到遠端 POP，因為 DNS resolver 的地理位置關係。查看 CloudFront access logs 中該使用者 IP 的 x-edge-location。(b) Origin 延遲——CloudFront 必須從 origin（us-east-1）取得內容，因為快取沒有命中；查看 time-taken 和 x-edge-result-type = Miss。修復方式是改善 cache policy（提高命中率）或使用 Origin Shield（地區性快取層）。(c) 網路路徑——亞洲與 CloudFront POP 之間的網際網路路徑擁塞。CloudFront 的 POP 到 origin 段使用 AWS 骨幹，所以緩慢在使用者到 POP 的段，AWS 無法控制。修復方式是使用 AWS Global Accelerator 的靜態 IP 邊緣入口，或接受地理現實。SOA-C02 通常要求答案 (a) 或 (b)。

Q4：如何透過 Flow Logs 偵測「資料外洩」？

建立一個 Logs Insights 查詢，找出從內部 subnet 到外部目的地的高位元組量出站流：

fields @timestamp, srcaddr, dstaddr, bytes, action
| filter action = "ACCEPT" and isIpv4InSubnet(srcaddr, "10.0.0.0/8") and not isIpv4InSubnet(dstaddr, "10.0.0.0/8")
| stats sum(bytes) as totalBytes by srcaddr, dstaddr
| sort totalBytes desc
| limit 50

然後將前幾名目的地 IP 與已知合作夥伴 IP 範圍交叉比對；未知目的地伴隨高位元組量是外洩候選。要提高精準度，用 GuardDuty——它有針對異常資料外送模式和 DNS 型外洩特徵的內建偵測器。Flow Logs 單獨顯示資料移動；GuardDuty 提供威脅情報，讓你能判定是否可疑。SOA-C02 在「偵測威脅」問題上偏好 GuardDuty 答案，Flow Logs 作為支援證據層。

Q5：為什麼同一條 Flow Log 對同一個連線顯示不同的 srcaddr？

兩種模式可以解釋這個現象。(a) NAT Gateway 轉換——NAT Gateway 的 ENI 對出站流量看到的 srcaddr 是發起 instance 的私有 IP，對回傳流量看到的 srcaddr 是外部伺服器的 IP。沒有自訂格式的 pkt-srcaddr，在 NAT Gateway ENI 上轉換後無法判斷是哪個 instance 發起的；有了 pkt-srcaddr，原始 instance IP 就被保留了。(b) 流向混淆——同一個 TCP 連線產生兩筆 flow record（每個方向一筆），srcaddr 和 dstaddr 互換。自訂格式的 flow-direction 欄位可以消除歧義。一般規則：生產 Flow Logs 中永遠包含 pkt-srcaddr、pkt-dstaddr 和 flow-direction，避免事故分流時的混淆。

Q6：VPN tunnel 每隔幾小時就不斷中斷——原因是什麼？

三種常見原因。(a) DPD（Dead Peer Detection）timeout 不一致——AWS 發送 DPD 探測；如果客戶閘道器未在 timeout 內回應，AWS 拆除 tunnel 並重新協商。在客戶端增加 DPD 間隔或與 AWS 預設值對齊。(b) Phase 2 lifetime 到期未換鑰——IPsec SA 有有限的 lifetime（預設 1 小時）；換鑰過程應該是透明的，但某些實作在換鑰期間會中斷流量。查看 lifetime 邊界附近的客戶閘道器日誌。(c) 重疊 NAT 或非對稱路由——機房端網路可能對某些流量做了 NAT 到不同的 IP，破壞了 IPsec selector。用 Reachability Analyzer 確認 AWS 端路徑，然後升級給機房端網路團隊。CloudWatch metric TunnelState 隨時間的圖表顯示中斷模式；AWS 主控台每個 tunnel 的 StatusMessage 指出失敗的協商參數。

Q7：如何主動監控 Direct Connect 健康狀態？

針對每個 VIF/連線設定 CloudWatch alarms：(a) ConnectionState——在離開 up 狀態時告警。(b) ConnectionLightLevelTx 和 ConnectionLightLevelRx——在光強度超出規格範圍時告警（1G 通常 -8 到 +5 dBm，10G 通常 -10 到 -1 dBm）。數值漂移表示光纖劣化。(c) ConnectionErrorCount——在任何非零速率時告警，表示實體層錯誤。(d) ConnectionBpsEgress 和 ConnectionBpsIngress——在接近飽和時告警（例如 > 80% port 速度），以便在使用者感受到影響前規劃容量。(e) 每個 VIF 的 BgpStatus（由 describe-virtual-interfaces 回傳）——在離開 up 狀態時告警。搭配 VPN 備援連線，在 DX 失敗時接管——並每季測試一次故障切換，確保需要用到時真的能運作。

Q8：可以在 CI/CD pipeline 中使用 Reachability Analyzer 嗎？

可以，而且 SOA-C02 偏好這個答案。工作流：對網路 IaC（CloudFormation、Terraform）的 pull request 觸發 CI 任務，(a) 部署到 staging 帳號，(b) 對每個關鍵來源-目的地組合（例如 ALB-to-target、target-to-RDS、target-to-S3）執行 aws ec2 create-network-insights-path 和 aws ec2 start-network-insights-analysis，(c) 等待完成，(d) 解析結果中的 NetworkPathFound = true。如果任何必要路徑不可達，PR 被封鎖。費用是每次分析 $0.10；每天幾百次分析與生產中斷相比微不足道。這個模式是 SOA 的標準答案，用於回答「如何在到達生產前防止網路退化」。

Q9：我對 Flow Logs 的 Logs Insights 查詢很慢——如何加速？

三個最佳化方向。(a) 縮小時間範圍——Logs Insights 在時間視窗內掃描所有符合的 log group；最近 24 小時的查詢掃描資料量是最近 1 小時的 24 倍。使用涵蓋事故的最小時間視窗。(b) 盡早篩選——把最具選擇性的 filter 條件放在前面（filter action = "REJECT" 先於 filter dstport = 443），讓後續階段處理的資料更少。(c) 使用欄位投影——Logs Insights 自動只投影你引用的欄位，所以引用的欄位越少，需要移動的資料就越少。對於非常大的 Flow Log 量（每天 TB 級），偏好使用 Parquet 格式儲存到 S3 的 Athena 查詢，並按年/月/日/帳號/region 分區——在大規模環境下，Athena 掃描通常比 Logs Insights 快 5–20 倍，且每次掃描費用更低。

Q10：ALB 只在部署期間回傳 502——問題是什麼？

這是 target group 取消登錄延遲問題。instance 被取消登錄時（部署、縮減或手動終止期間），target group 進入 draining 狀態並停止傳送新請求，但進行中的請求繼續。預設取消登錄延遲是 300 秒（5 分鐘）。如果取消登錄延遲比最長的進行中請求短，連線會被強制關閉，客戶端看到 502。修復方式是將取消登錄延遲設定為大於預期最長請求——典型 web app 用 30–60 秒就夠；長時間執行的 API（影片上傳、ML 推理）可能需要 5–15 分鐘。推論：ASG 端的 HealthCheckGracePeriodSeconds 必須大於應用程式啟動時間，這樣新 instance 在就緒之前不會接收流量。取消登錄延遲和 grace period 都必須根據應用程式的實際行為調整，而不是沿用預設值。

延伸閱讀與相關運維模式

• VPC Flow Logs — User Guide
• Flow Log Record Examples
• Querying VPC Flow Logs with Athena
• VPC Reachability Analyzer
• Network Access Analyzer
• Application Load Balancer Access Logs
• Network Load Balancer Access Logs
• ALB Target Group Health Checks
• Troubleshoot Your Application Load Balancer
• CloudFront Access Logs
• AWS WAF Web ACL Logging
• Troubleshooting Site-to-Site VPN
• Troubleshooting AWS Direct Connect
• Analyzing Log Data with CloudWatch Logs Insights
• AWS SOA-C02 Exam Guide v2.3 (PDF)

VPC 網路疑難排解納入工具箱後，相關的運維層如下：VPC 設定與連線能力，涵蓋本主題所驗證的設計期控制項（subnets、route tables、NACLs、security groups、endpoints、peering、TGW、VPN）；Route 53 DNS 與 CloudFront，涵蓋 VPC 前端的 DNS 和 CDN 層，各有其故障模式；WAF、Shield 與網路保護，涵蓋你在此為誤報分類而讀取日誌的 Layer 7 控制項；以及 CloudWatch Logs 與 Logs Insights，涵蓋支撐大規模 Flow Log 和 ELB log 分析的查詢引擎。