examlab .net 用最有效率的方法,考取最有價值的證照
本篇導覽 約 27 分鐘

VPC Flow Logs、Reachability Analyzer 與 Traffic Mirroring

5,400 字 · 約 27 分鐘閱讀 ·

ANS-C01 領域 3.2 深入解析:VPC Flow Logs (v2-v5 欄位、ACCEPT/REJECT、Athena 分區)、Reachability Analyzer 路徑模擬、Network Access Analyzer 信任存取範圍、基於 Nitro ENI 的 VPC 流量鏡像、鏡像篩選器與工作階段,以及在後設資料、封包擷取與可達性模擬之間的陷阱選擇。

立即做 20 題練習 → 免費 · 不用註冊 · ANS-C01

當 AWS Certified Advanced Networking — Specialty (ANS-C01) 進入領域 3 的任務 3.2「監控並分析網路流量以排除故障並最佳化連線模式」時,它不再詢問抽象的設計問題,而是向你展示一個出現問題的網路,並提供三到四個可能的診斷方案。在診斷平面中,有三個工具佔據主導地位:VPC Flow Logs 用於獲取每個 ENI 的連線後設資料 (metadata)、VPC Reachability Analyzer 用於模擬穿過 VPC 圖形的路徑而不發送真實封包,以及 VPC 流量鏡像 (Traffic Mirroring) 用於將完整的封包副本路由到頻外分析器。考試期望你能辨認出哪個工具適合哪種症狀,每個工具看不見什麼內容,以及精確的陷阱限制——僅限 Nitro 的鏡像來源、Reachability Analyzer 是模擬而非即時,以及 VPC Flow Logs 靜默排除的一長串流量清單。

本主題涵蓋了任務 3.2 的全部內容,並具備專家級考試要求的深度。我們將探討 Flow Log 架構 (擷取類型、目的地、v2 到 v5 的記錄格式、pkt-srcaddrflow-directiontraffic-path 等擴展欄位);如何使用 Athena 和 CloudWatch Logs Insights 查詢 Flow Logs;Reachability Analyzer 實際上模擬了什麼 (以及它無法評估的組件);Reachability Analyzer、Network Access Analyzer 和 Transit Gateway Route Analyzer (一個常見的 ANS-C01 干擾項叢集) 之間的區別;流量鏡像的來源/目標/篩選器/工作階段模型;Nitro 需求;以及症狀與正確診斷工具之間的 SCS-C02 風格對應。貫穿始終的重點是考試編寫的那種多行情境題——「工程師看到執行個體 X 上間歇性的 SSH 逾時,但僅在高峰負載時發生在子網路 Y」——以及哪個工具能最快回答這個問題。

為什麼網路監控在 ANS-C01 領域 3 中佔主導地位

領域 3 (網路管理與營運) 佔 ANS-C01 考試的 20% —— 大約 65 題中的 13 題,其中大約一半落在任務說明 3.2 中。該單一任務在知識要點中列出了 CloudWatch、VPC Flow Logs、VPC 流量鏡像、Reachability Analyzer 和 Transit Gateway Network Manager,並要求你分析工具輸出、映射拓撲、識別封包整形問題、排除配置錯誤、驗證網路設計以及自動化驗證。其中每一個技能要點都是考試可以出的題目。

Security Specialty (SCS-C02) 將 VPC Flow Logs 視為饋送 GuardDuty 的 SIEM 輸入不同,Advanced Networking Specialty (ANS-C01) 將其視為網路工程師的主要診斷工具 —— 相當於真實網路上的 tcpdump 加上配置審核軌跡。考試中「SG 和 NACL 是否允許此封包?」的答案是 Reachability Analyzer。而「是什麼 HTTP 請求主體觸發了 500 錯誤?」的答案是流量鏡像。「在過去 24 小時內,此 NAT 閘道與這些 spoke VPC 之間的位元組分佈是什麼樣子?」的答案是 Flow Logs + Athena。知道正確答案只是成功的一半;知道為什麼其他三個答案行不通是另一半。

白話文解釋 VPC Flow Logs, Reachability Analyzer 與流量鏡像

這三個工具生活在網路診斷抽象的不同層級,三個類比有助於理解。

類比一 — 大樓安防監控、建築圖紙與刑事監聽

想像一棟辦公大樓的安防基礎設施。VPC Flow Logs大廳的監視器日誌 —— 它們記錄了誰進入和離開、什麼時間、透過哪扇門,並帶有時間戳記和門號,但沒有音訊,也沒有人臉辨識酬載。這些片段儲存成本低廉,可保存數月,對於「昨天凌晨 2 點到 3 點誰在這裡?」是不可或缺的,但對於「他們在會議中說了什麼?」則毫無用處。VPC Reachability Analyzer大樓的建築圖紙審查員 —— 給定門、鎖、識別證讀取器、安全門和租戶清單的藍圖,審查員可以告訴你「如果辦公室 4B 的人帶著 X 類型的識別證試圖走到辦公室 7C,他們會被攔住嗎?」而無需真的派人去走廊走一遍。審查員讀取配置,遵循規則,並回報結果。VPC 流量鏡像刑事監聽 —— 當你懷疑某扇門被用於非法活動時,你在該門上接一條重複的音訊/視訊線路到單獨的取證辦公室進行完整的酬載分析,而該門仍繼續正常運作。監聽成本昂貴、具備針對性且有時間限制;監視器覆蓋面廣、便宜且持續;建築審查是離線且詳盡的。

類比二 — 醫院日誌、平面圖與病患錄音

醫院的診斷堆疊也能清晰映射。Flow Logs病患出入院名單 —— 姓名、時間、病房 ID、分診台的接收/拒絕。Reachability Analyzer覆蓋了門禁卡規則的醫院平面圖 —— 給定任何一對房間,特定的員工識別證能否在不被任何一扇門拒絕的情況下從 A 走到 B?平面圖不會在即時系統上測試識別證;它讀取規則並報告路徑。流量鏡像床邊錄音機,將病患諮詢內容複製到外部逐字稿服務進行完整內容審查,而諮詢過程則不受干擾地繼續進行。

類比三 — 公路流量:收費站記錄、地圖導航軟體與行車記錄器

公路管理局使用三種工具。Flow Logs收費站記錄 —— 每輛經過的車輛、時間、車牌號碼、車道、已支付或被拒絕;非常適合流量分析和對帳,但沒有關於車內人員的資訊。Reachability Analyzer帶有封路資訊的地圖導航軟體 —— 給定任何兩個城市,考慮到目前的封路、高度限制和重量限制,特定的車輛類型 (卡車、巴士、摩托車) 實際上能從 A 開到 B 嗎?地圖在不派遣車輛的情況下給出答案。流量鏡像特定車輛的行車記錄器錄影,複製到取證實驗室 —— 旅程的完整視訊和音訊,在每輛車上啟用的成本都很高,僅在需要調查時有選擇地使用。

對於 ANS-C01,監視器 / 建築審查 / 刑事監聽三位一體是效益最高的心智模型 —— 它捕捉了成本不對稱性 (便宜、免費、昂貴) 和抽象層 (後設資料、配置、酬載)。當問題涉及成本或全天候遙測時,想監視器 (Flow Logs)。當涉及路徑驗證或部署前設計審核時,想建築審查 (Reachability Analyzer)。當涉及解碼特定酬載或匹配 Suricata 特徵時,想刑事監聽 (流量鏡像)。參考資料:https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

VPC Flow Logs 架構

VPC Flow Logs 擷取流經 ENI 的 IP 流量後設資料。它們是每位 AWS 網路工程師工具箱中的基礎遙測,是 Amazon GuardDuty、Amazon Detective、AWS Network Access Analyzer 發現項以及大多數第三方 SIEM 的數據源。

範圍:ENI、子網路或 VPC

Flow Log 可以在三個層級之一建立。ENI 層級擷取一個特定的彈性網路介面 —— 用於調查單一執行個體。子網路層級擷取子網路中的每個 ENI —— 安全審計的實際預設選項。VPC 層級擷取 VPC 每個子網路中的每個 ENI —— 詳盡無遺,是集中收集的 AWS 安全參考架構預設選項。

Flow Logs 不具備追溯性:現在啟用它們會擷取從現在開始的數據。沒有歷史回放。對於事件回應,「在 VPC 層級始終開啟 Flow Logs」是強制性的基準。Flow Logs 按擷取的 GB 以及標準儲存收費;在開發環境中關閉它們以節省資金是常見的維運錯誤,這會在需要時破壞取證能力。

擷取類型:ACCEPT、REJECT、ALL

Flow Log 可以擷取 ACCEPT 記錄 (允許的流量)、REJECT 記錄 (被 SG 或 NACL 阻擋) 或 ALL。ACCEPT 是體量 —— 健康 VPC 中的大多數流量。REJECT 是訊號 —— 連接埠掃描、配置錯誤的用戶端、嘗試存取的經 IAM 鎖定之主體、橫向移動嘗試。考試預設預期為 ALL:你同時需要安全性與效能基準分析。

目的地:CloudWatch Logs、S3、Kinesis Firehose

三個目的地。CloudWatch Logs 用於透過 Logs Insights 進行近乎即時的互動式查詢,以及針對指標篩選器設置 CloudWatch 警示。S3 用於廉價的長期存儲和 Athena 查詢 —— 是全組織聚合和隨機分析的正確目的地。Kinesis Data Firehose 用於串流傳輸到 SIEM、數據湖或第三方日誌分析管道。

S3 目的地支持 Hive 相容分區 (year=YYYY/month=MM/day=DD/hour=HH/) 和 Parquet 格式作為純文字的替代方案。Parquet 分區將選擇性查詢的 Athena 查詢成本降低 10-20 倍,因為 Athena 僅掃描相關分區。

記錄格式版本:v2, v3, v4, v5

每個版本都新增了欄位,且不移除先前的欄位。

  • v2 — 原始 14 個欄位:version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status。
  • v3 — 新增 vpc-id, subnet-id, instance-id, tcp-flags, type (IPv4 vs IPv6), pkt-srcaddr, pkt-dstaddr (NAT 之前的實際封包來源/目的地,與可能是 NAT 轉換後地址的 srcaddr/dstaddr 形成對比)。
  • v4 — 新增 region, az-id, sublocation-type, sublocation-id, pkt-src-aws-service, pkt-dst-aws-service, flow-direction, traffic-pathtraffic-path 欄位編碼了封包的路由方式 (1=VPC 內部, 2=透過 IGW 或閘道端點, 3=透過 VGW, 4=透過跨區域對等互連, 5=透過跨 AZ, 6=透過 VPC 對等互連, 7=透過 VPC 端點, 8=透過網際網路閘道出口)。
  • v5 — 新增 ecs-cluster-arn, ecs-cluster-name, ecs-container-instance-arn 等針對 ECS 工作負載的容器層級註釋。

當你需要完整的功能覆蓋時,請選擇 v5 —— 每擷取位元組的成本與 v2 相同。只有在你受到無法解析新欄位的舊版日誌分析工具限制時,舊的 v2 日誌才足夠。

tcp-flags 解讀

tcp-flags 欄位是流程窗口中看到的 TCP 控制位元的位圖。常見值:2 = 僅 SYN,18 = SYN-ACK,16 = ACK,4 = RST,1 = FIN,19 = SYN-ACK-PSH,24 = ACK-PSH。僅具有 tcp-flags=2 且無回應的 18 的流程是半開連線,通常診斷為目的地未回應 (回程路徑上的防火牆丟棄,或目的地執行個體已停止)。包含 4 在內的 tcp-flags 表示重設 —— 通常是已關閉的連線被終止或目的地核心關閉了連接埠。

srcaddrdstaddr 欄位顯示的是 ENI 看到的 地址。pkt-srcaddrpkt-dstaddr 欄位 (v3+) 顯示的是 原始 封包在任何 NAT 轉換之前的地址。對於 NAT 閘道,這種差異揭示了哪個底層執行個體產生了流程,即使 NAT GW ENI 將自身顯示為 srcaddr。對於 VPC 對等互連和 Transit Gateway 流程,即使中間跳轉重寫了可見來源,pkt-srcaddr 也能讓你追蹤到實際來源執行個體。ANS-C01 經常測試這一點:「給定 NAT 閘道 ENI 處的此行 Flow Log,哪個私有執行個體發起了連線?」——答案在 pkt-srcaddr 中,而不是 srcaddr。參考資料:https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html

ACCEPT vs REJECT 以及 Flow Logs 看不見的內容

當入站流程被安全群組 (SG) 或 NACL 丟棄時,會產生 REJECT 記錄。在 Flow Log 中,安全群組丟棄看起來與 NACL 丟棄完全相同 —— 兩者都產生 REJECT。要區分兩者,你需要推理:如果來源被 SG 入站規則允許且 SG 是具備狀態的,則丟棄是 NACL (通常是缺少臨時連接埠的離站允許規則)。如果來源不在任何 SG 入站規則中,則丟棄是 SG 造成的。

Flow Logs 不擷取某些流量類別。詳盡的排除清單:

  • 到達及來自 Amazon DNS 伺服器的流量 (VPC CIDR 的 .2 IP 或 169.254.169.253)。
  • 到達及來自 IMDS 端點 169.254.169.254 的流量 (包含 IMDSv2)。
  • 位於 169.254.169.123 的 Amazon Time Sync。
  • Windows 授權啟用流量。
  • DHCP 流量。
  • 到達 VPC 路由器保留位址 (子網路 CIDR 的 .1) 的流量。
  • 由 VPC 流量鏡像工作階段產生的鏡像流量。
  • 與 Gateway Load Balancer 透明內嵌插入模式相關的部分流程。

AWS Network Firewall 丟棄的封包不會作為 REJECT 出現在 VPC Flow Logs 中。 Network Firewall 有其自身的警示日誌和流程日誌,是單獨的來源。一個描述「Network Firewall 正在丟棄封包,但 VPC Flow Logs 顯示沒有 REJECT」的情境完全是按預期運作的;答案是查閱 Network Firewall 自身的日誌。

考生常假設 Flow Logs 是完整的網路記錄。它們不是。上述排除清單是最常見的 ANS-C01 陷阱領域。描述「我們在 Flow Logs 中看不到對內部解析器的 DNS 查詢」的情境反映了記錄的 .2 解析器流量排除 —— 答案是 Route 53 Resolver Query Logging,而非 Flow Logs。描述「執行個體正在存取 IMDS 但 Flow Logs 顯示什麼都沒有」的情境是正確的行為 —— 位於 169.254.169.254 的 IMDS 被排除了。要完整擷取其中任何一項,請使用流量鏡像 (它可以看見包含 IMDS 連結本地流量在內的第 2 層以上內容) 或基於主機的擷取。參考資料:https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html

使用 Athena 與 Logs Insights 查詢 Flow Logs

在 S3 目的地的 Flow Logs 上使用 Athena

Athena 透過與所選格式和分區匹配的 CREATE EXTERNAL TABLE DDL 從 S3 讀取 Flow Logs。對於 Hive 分區的 S3 佈局,DDL 宣告 PARTITIONED BY (region string, year int, month int, day int, hour int) 並使用 MSCK REPAIR TABLE (或分區投影) 來註冊分區。常見查詢:

  • 位元組消耗大戶SELECT srcaddr, dstaddr, SUM(bytes) AS total FROM flow_logs WHERE day = '2026-05-02' GROUP BY srcaddr, dstaddr ORDER BY total DESC LIMIT 10
  • 跨 /16 的 REJECT 模式SELECT srcaddr, COUNT(*) AS rejects FROM flow_logs WHERE action = 'REJECT' AND dstaddr LIKE '10.10.%' GROUP BY srcaddr ORDER BY rejects DESC
  • 使用 sublocation-id (v4+) 辨識跨 AZ 流量:篩選來源和目的地 az-id 不同的位置;乘以每 GB 跨 AZ 定價以進行成本歸屬。

分區投影 (Glue Data Catalog 的一項功能) 透過從 S3 金鑰計算分區值,消除了對 MSCK REPAIR 的需求;建議用於長期執行的查詢工作負載。

CloudWatch Logs Insights

對於 CloudWatch Logs 目的地,Logs Insights 提供具有 parsefilterstatssortlimit 的互動式查詢語法。典型查詢:

parse @message "* * * * * * * * * * * * * *"
  as version, account, eni, srcaddr, dstaddr, srcport, dstport,
     protocol, packets, bytes, start, end, action, status
| filter action = "REJECT"
| stats count(*) as rejects by srcaddr
| sort rejects desc
| limit 20

Logs Insights 查詢最適合臨機調查;持久性儀表板最好由 S3 + Athena + QuickSight 提供,它們可以擴展到組織級體量,且不具備 Logs Insights 的每次查詢成本。

跨帳號聚合模式

AWS 安全參考架構模式:每個成員帳號的 VPC 將 Flow Logs 寫入 Log Archive 帳號中集中式的 S3 儲存貯體,按 account/region/day 分區。儲存貯體是不可變的 (S3 Object Lock 加上拒絕刪除的儲存貯體政策)。Security Tooling 帳號透過 Athena 跨所有分區進行查詢。對於 ANS-C01,同樣的模式也適用;考試將其框架化為「在整個組織內集中網路遙測」。

  • ENI 層級 / 子網路層級 / VPC 層級:擷取範圍,廣度遞增。
  • ACCEPT / REJECT / ALL:用於允許流程、拒絕流程或兩者的篩選器。
  • v2 / v3 / v4 / v5:記錄格式版本;v5 最豐富。
  • pkt-srcaddr / pkt-dstaddr:NAT 轉換之前的原始封包位址。
  • traffic-path:編碼的路由路徑 (1=VPC 內部, 2=IGW, 3=VGW, 4=跨區域對等互連, 5=跨 AZ, 6=VPC 對等互連, 7=VPC 端點, 8=IGW 出口)。
  • flow-direction:相對於 ENI 的入站或出站。
  • NODATA / SKIPDATA / OK:日誌狀態值;NODATA 表示時間窗口內沒有流量,SKIPDATA 表示擷取緩衝區溢出。
  • 參考資料:https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html

VPC Reachability Analyzer

VPC Reachability Analyzer 使用靜態配置分析模擬 VPC 圖形中兩個端點之間的路徑可達性。它讀取安全群組、NACL、路由表、對等連線、Transit Gateway 連接、網際網路閘道和 VPN 連線,建模封包的假設路徑,並報告路徑是否可達、逐跳順序以及哪個組件 (如果有) 阻斷了路徑。

Reachability Analyzer 模擬的內容

  • 來源和目的地資源類型:VPC、子網路、執行個體、ENI、網際網路閘道、虛擬私有閘道、傳輸閘道、傳輸閘道連接、對等連線、網路分析端點。
  • 評估的路徑組件:路由表、安全群組、NACL、Transit Gateway 路由表、VPC 對等連線、VPN 連線、閘道端點、網際網路閘道路由。
  • 路徑輸出:帶有組件 ID 的有序躍點列表、每個躍點的動作以及解釋字串 (例如「ENI_INGRESS — 安全群組 sg-abc 允許連接埠 443 上的流量」)。

Reachability Analyzer 不測試的內容

  • 即時流量 — Reachability Analyzer 是模擬而非探測。它不發送封包;它不偵測間歇性故障、擁塞、MTU 不匹配或 BGP 工作階段狀態。
  • 應用層可達性 — 它停留在第 4 層 (連接埠層級) 可達性;目的地連接埠上的應用程式是否回應不在範圍內。
  • AWS Network Firewall、GWLB 後方的第三方設備或任何 Suricata/IDS 規則 — 這些未被建模;Reachability Analyzer 假設任何通過 SG/NACL/路由的路徑都會到達其目的地,除非它明確是不受支持的組件。
  • DNS 解析 — Reachability Analyzer 接受 IP/ENI/執行個體輸入,而不接受 DNS 名稱;如果 DNS 解析是故障點,此工具看不見它。

自動化模式

高回報的 ANS-C01 模式:Reachability Analyzer + EventBridge + Lambda 用於在每次基礎設施變更後驗證預期的連線性是否保持完好。EventBridge 在配置變更時觸發 (新的 SG 規則、路由表更新或 VPC 對等連線修改);Lambda 為一組預存的「必須始終可達」路徑測試調用 Reachability Analyzer API;失敗時透過 SNS 發出警示或開啟 Security Hub 發現項。這是「隨著配置變更自動驗證連線性意圖」的答案 —— 完全符合 ANS-C01 技能要點的措辭。

成本與限制

每次路徑分析按次計費。每個帳號每個區域的並行分析存在配額 (預設為幾十個,可提高)。對於組織級自動化,請分批進行分析並限制 EventBridge 的展開率 (fan-out)。

關於此工具單一測試最頻繁的 ANS-C01 陷阱。情境描述間歇性 SSH 故障,並提供 Reachability Analyzer 作為四個可能診斷答案之一。Reachability Analyzer 無法診斷間歇性故障,因為它不測試即時流量 —— 它只讀取配置。如果配置正確但流量仍有時失敗,症狀指向 MTU 黑洞、擁塞的 NAT GW、BGP 抖動、路由傳播延遲或目的地執行個體健康狀況 —— 這些 Reachability Analyzer 都看不見。間歇性問題的正確答案是 Flow Logs (尋找非對稱丟棄或 NODATA 期間)、NAT 閘道或 TGW 的 CloudWatch 指標,或用於酬載調查的流量鏡像。參考資料:https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html

Network Access Analyzer vs Reachability Analyzer vs Route Analyzer

ANS-C01 經常將這三個工具作為干擾項選項。必須區分它們。

VPC Reachability Analyzer

兩個指定端點之間的路徑模擬。回答「A 能到達 B 嗎?」。回傳路徑判定和跳轉追蹤。用於連線性意圖驗證。

Network Access Analyzer

跨帳號和 VPC 的基於範圍的信任存取政策分析。定義一個「範圍」描述允許什麼樣的可達性 (例如「僅標記為 Production 的資源可以透過 NAT 閘道到達網際網路」,或「帳號 A 中的任何資源都不得到達帳號 B 中的 S3 儲存貯體」)。Network Access Analyzer 根據範圍評估整個 AWS Organization,並針對任何違反範圍的存取路徑產生發現項 —— 從敏感子網路到網際網路的路徑、隔離的 VPC 之間的路徑、透過 PrivateLink 端點到達非預期服務的路徑。用於合規性和存取基準審計,與 Security Hub 整合。

Transit Gateway Route Analyzer

Transit Gateway Network Manager 綁定,Route Analyzer 針對給定的來源和目的地追蹤穿過 TGW 路由表的封包路徑。它回答「給定此來源連接和此目的地 CIDR,匹配了哪些 TGW 路由表條目,以及封包從何處流出?」—— 這是 TGW 特有的,不擴展到 VPC SG 或 NACL。

  • Reachability AnalyzerA 現在能到達 B 嗎? (點對點模擬)
  • Network Access Analyzer是否有任何資源具備非預期的存取權限? (跨組織的基於範圍的審計)
  • TGW Route Analyzer此封包如何透過 TGW 路由? (TGW 特有的路徑追蹤) ANS-C01 將這些作為干擾項集進行測試 —— 知道每個工具回答哪個問題是區分關鍵。參考資料:https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-network-access-analyzer.html

VPC 流量鏡像 (Traffic Mirroring)

VPC 流量鏡像將封包從來源 ENI 複製到目標以進行頻外分析。當需要封包內容檢查時,它是首選工具 —— IDS/IPS 特徵匹配、DLP 掃描、應用層除錯或合規性封包保留。

組件:鏡像來源、目標、篩選器、工作階段

  • 鏡像來源 — 基於 Nitro 的 EC2 執行個體上的 ENI。舊的非 Nitro 執行個體類型 (m4, c4, r4, t2 等) 不支援作為來源。
  • 鏡像目標 — Network Load Balancer、Gateway Load Balancer 端點或另一個 ENI。通常目標指向安全分析設備、Suricata IDS 叢集、Zeek 感測器或 Wireshark/tshark 收集器。
  • 鏡像篩選器 — 定義要鏡像哪些流量,具有規則編號排序和 5 元組匹配 (來源/目的 CIDR、協定、連接埠範圍)。篩選器按方向套用 (相對於來源 ENI 的入站 vs 出站)。
  • 鏡像工作階段 — 將來源 + 目標 + 篩選器綁定在一起。鏡像工作階段具有工作階段編號,用於在 ENI 匹配多個工作階段時決定優先順序 (編號越低優先順序越高)。

流量鏡像擷取的內容

從第 2 層往上的完整封包內容,封裝在 VXLAN 風格的標頭中 (預設為 UDP 目的地連接埠 4789),以便目標可以對多個鏡像工作階段進行解多工。原始來源/目的 MAC 和 IP 保留在封裝內部;分析工具必須解碼 VXLAN。

使用案例

  • 事件期間的取證擷取 — 將被懷疑受損的執行個體鏡像到取證 VPC 進行離線分析。
  • 威脅搜查 — 將鏡像流量饋送到 Suricata IDS,以進行超出 GuardDuty 或 AWS Network Firewall 提供的特徵和行為檢測。
  • 合規性封包保留 — 某些受監管產業要求保留 N 天的完整封包擷取;流量鏡像 + 自訂收集器 + S3 (透過 Kinesis Firehose 或 EC2 擷取精靈) 是規範模式。
  • 深層效能除錯 — 擷取並回放 TCP 流程以調查重傳、MTU 問題或協定級延遲。

限制與考量

  • 僅限 Nitro 來源 — 非 Nitro 執行個體不能作為鏡像來源。這是測試最頻繁的限制。
  • 單一執行個體頻寬預算 — 鏡像流量共用來源執行個體的網路頻寬預算;鏡像飽和的執行個體可能導致生產流量丟失。
  • 工作階段限制 — 每個 ENI 的鏡像工作階段數量較少;按區域配額適用 (可提高)。
  • 鏡像流量不包含在 Flow Logs 中 — 鏡像副本不會出現在 VPC Flow Logs 中 (避免重複計算)。
  • 無酬載修改 — 鏡像工作階段是唯讀副本;生產流程不受修改地繼續。
  • 不支援跨區域鏡像 — 來源和目標必須在同一個區域 (區域內跨 AZ 是可以的)。

鏡像篩選器設計

篩選器編寫中最常見的錯誤:未同時配置入站和出站篩選規則。預設情況下,鏡像工作階段不擷取任何內容;你必須為所需的方向和 5 元組新增規則。一個典型的「鏡像此 ENI 的所有流量」篩選器有兩條規則:入站 0.0.0.0/0 → 0.0.0.0/0 所有協定 accept;出站 0.0.0.0/0 → 0.0.0.0/0 所有協定 accept。選擇性篩選器 (例如僅指向特定目的地的 TCP/443) 可大幅減輕目標 NLB 的負載。

一個規範性的 ANS-C01 干擾項會將這三者放在一起,好像它們是替代方案一樣。它們是在三個抽象層級上的補充。流量鏡像 = 封包內容。Flow Logs = 連線後設資料。Reachability Analyzer = 靜態路徑驗證。對於「我們需要檢查 HTTP 請求主體中已知的 XSS 酬載」的正確答案是流量鏡像。對於「偵測來自資料庫子網路的異常體量出站 TCP/22」的正確答案是 Flow Logs。對於「驗證此變更後,從網頁層到資料層的路徑是否被 SG 和路由表允許」的正確答案是 Reachability Analyzer。參考資料:https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html

CloudWatch 指標、警示與 Network Manager 整合

網路相關的 CloudWatch 指標

VPC 及鄰近服務會發出許多與維運診斷相關的 CloudWatch 指標:

  • NAT 閘道BytesInFromDestination, BytesInFromSource, ConnectionAttemptCount, ErrorPortAllocation (監控 SNAT 連接埠耗盡)。
  • VPN 連線TunnelState (1 = up, 0 = down), TunnelDataIn, TunnelDataOut
  • Direct ConnectConnectionState, ConnectionBpsEgress, ConnectionBpsIngress, ConnectionLightLevelTx/Rx (光信號強度)。
  • Transit GatewayBytesIn, BytesOut, PacketDropCountBlackhole, PacketDropCountNoRoute
  • Application Load BalancerRequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count, HealthyHostCount

警示模式

  • Direct Connect 上的 BGP 工作階段中斷 — 針對 ConnectionState < 1 設置警示。
  • VPN 隧道抖動 — 針對 5 分鐘內 TunnelState 平均值 < 1 設置警示。
  • NAT GW 連接埠耗盡 — 針對 ErrorPortAllocation > 0 設置警示。
  • TGW 黑洞丟棄 — 針對 PacketDropCountBlackhole > 0 設置警示。

Transit Gateway Network Manager

TGW Network Manager 將 Transit Gateway 註冊到一個具有拓撲圖、路徑分析、事件通知和 CloudWatch 指標聚合的「全球網路」抽象中。對於多區域、多 TGW 部署,Network Manager 是維運控制台 —— 提供拓撲、配置和事件的單一窗口。Network Manager 事件流向 CloudWatch Events / EventBridge 以實現自動化 (例如,在連接狀態變更時發出通知)。

  • Flow Log 範圍:ENI、子網路或 VPC。
  • 擷取類型:ACCEPT、REJECT、ALL。
  • 目的地:CloudWatch Logs、S3、Kinesis Firehose。
  • 記錄格式:v2 (預設 14 欄位), v3 (+VPC/子網路/執行個體/tcp-flags/pkt-src/pkt-dst), v4 (+區域/az-id/次要位置/aws-服務/流向/路徑), v5 (+ECS 欄位)。
  • Flow Logs 排除內容:到 .2 解析器的 DNS、IMDS 連結本地、Time Sync、Windows 啟用、DHCP、鏡像流量。
  • Network Firewall 丟棄項:不在 Flow Logs 中;單獨位於 NFW 警示/流程日誌中。
  • Reachability Analyzer:僅限模擬,第 3/4 層路徑驗證,不測試即時流量。
  • Reachability Analyzer:不建模 AWS Network Firewall 或第三方 GWLB 設備。
  • Network Access Analyzer:跨組織的基於範圍的信任存取審計。
  • TGW Route Analyzer:透過 Network Manager 進行 TGW 特有的路徑追蹤。
  • 流量鏡像:來源 ENI 必須在 Nitro 執行個體上;不支援非 Nitro。
  • 鏡像目標:NLB、GWLB 端點或 ENI;與來源同區域。
  • 鏡像流量封裝:VXLAN 風格,預設 UDP/4789。
  • 參考資料:https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-considerations.html

症狀對應工具決策矩陣

回答 ANS-C01 任務 3.2 題目的最快方法是症狀→工具查閱。請背熟此表。

症狀或目標 主要工具 為什麼
24 小時內 VPC 體量前 N 名的位元組消耗者 Flow Logs (S3 + Athena) 跨體量數據的聚合;分區列式存儲快速且便宜。
偵測來自外部 IP 的連接埠掃描 Flow Logs (REJECT 記錄) 來自同一來源跨連接埠的 REJECT 模式。
在 SG 變更後驗證網頁層到資料庫子網路的路徑 Reachability Analyzer 配置時驗證,而非即時測試。
審計「開發 VPC 中的任何資源都不得到達生產 VPC」 Network Access Analyzer 跨組織的基於範圍的審計,而非點對點。
追蹤給定來源/目的地的 TGW 路徑 TGW Route Analyzer (Network Manager) TGW 特有的路由。
為取證解碼 HTTP 請求主體 流量鏡像 → Suricata/Zeek 需要酬載,第 7 層。
診斷間歇性 SSH 逾時 Flow Logs + CloudWatch 指標 尋找非對稱 REJECT、NODATA 期間或 NAT GW 連接埠耗盡;不是 Reachability Analyzer (即時問題而非配置)。
辨識哪個私有執行個體正在透過 NAT 產生離站流量 帶有 pkt-srcaddr 的 NAT GW Flow Logs NAT GW srcaddr 顯示 NAT IP;pkt-srcaddr 顯示真實執行個體。
偵測 NAT GW 上的 SNAT 連接埠耗盡 CloudWatch ErrorPortAllocation 指標 特定的 SNAT 失敗指標。
Direct Connect 上的 BGP 工作階段抖動 CloudWatch ConnectionState 警示 BGP/連線狀態變更是指標而非 Flow Logs。
擷取 DNS 查詢酬載以進行惡意軟體 C2 偵測 Route 53 Resolver Query Logging 或流量鏡像 Flow Logs 排除 .2 解析器流量。
合規性:90 天完整封包擷取 流量鏡像 → S3 透過自訂收集器 Flow Logs 僅限後設資料。
在所有變更中驗證連線性意圖 Reachability Analyzer + EventBridge + Lambda 自動化的變更後驗證。
調查為什麼 Network Firewall 規則阻斷流量 Network Firewall 警示/流程日誌 NFW 丟棄項不會出現在 VPC Flow Logs 中。
多區域 TGW 的拓撲圖 TGW Network Manager 單一全球網路視圖。

常見陷阱複習 — 領域 3.2

考試在該領域最常編寫的陷阱。

陷阱 1:Reachability Analyzer 可以偵測間歇性故障

錯誤。它是靜態配置模擬。間歇性故障屬於 Flow Logs 和 CloudWatch 指標。

陷阱 2:Flow Logs 擷取 ENI 上的所有流量

錯誤。到 .2 解析器的 DNS、IMDS 連結本地、Time Sync、Windows 啟用、DHCP 和鏡像流量都被排除了。對這些內容使用流量鏡像或 Resolver Query Logging。

陷阱 3:Network Firewall 丟棄項出現在 VPC Flow Logs 中

錯誤。NFW 有其自身的警示和流程日誌。

陷阱 4:流量鏡像適用於所有執行個體類型

錯誤。來源 ENI 必須在 Nitro 執行個體上。m4/c4/r4/t2 不能作為鏡像來源。

陷阱 5:Flow Logs 中的 srcaddr 始終是原始封包來源

錯誤。對於經過 NAT 的流程,srcaddr 是 NAT 後的地址;pkt-srcaddr (v3+) 才是原始地址。

陷阱 6:Reachability Analyzer 評估 Network Firewall 規則

錯誤。NFW、經 GWLB 路由的第三方設備和 Suricata 規則未被建模。

陷阱 7:Network Access Analyzer 是 Reachability Analyzer 的同義詞

錯誤。Reachability 是點對點模擬;Network Access Analyzer 是跨組織的基於範圍的審計。

陷阱 8:為了節省成本選擇 v2 Flow Logs

錯誤。v2 和 v5 每擷取 GB 的成本相同。除非你有無法解析新欄位的下游工具,否則請始終選擇 v5。

陷阱 9:鏡像流量出現在來源 ENI 的 Flow Logs 中

錯誤。鏡像流量被排除在 Flow Logs 之外,以避免重複計算。

陷阱 10:Logs Insights 比 Athena 更適合組織級查詢

錯誤。Logs Insights 定價隨每次查詢掃描的位元組數擴展;在分區的 Parquet S3 上的 Athena 對於大型歷史聚合要便宜得多。對隨機查詢使用 Logs Insights,對體量查詢使用 Athena。

陷阱 11:flow log 狀態中的 NODATA 意味著流量被丟棄

錯誤。NODATA 表示在聚合窗口內未看到任何流量 —— 這是關於缺席的資訊,而非拒絕。SKIPDATA 表示擷取緩衝區溢出,丟失了一些流程。

陷阱 12:流量鏡像可以跨區域擷取

錯誤。鏡像來源和目標必須在同區域。

FAQ — VPC Flow Logs, Reachability Analyzer 與流量鏡像

Q1:我應該使用哪個 Flow Logs 版本,是否有理由選擇 v2?

預設使用 v5。每擷取 GB 的成本與 v2 相同,且 v5 包含 v2/v3/v4 的每個欄位加上 ECS 容器欄位。選擇較低版本的唯一理由是下游解析器 (舊版 SIEM) 在不修改的情況下無法讀取新欄位 —— 即便如此,正確的做法通常是升級解析器。v3 是包含 pkt-srcaddrpkt-dstaddr 的最低版本,這對於 NAT、對等互連和 TGW 流程歸屬至關重要。v4 增加了 traffic-path (1=VPC 內部, 2=IGW, 3=VGW, 4=跨區域對等互連, 5=跨 AZ, 6=對等互連, 7=VPC 端點, 8=IGW 出口) —— 對於跨 AZ 成本分析非常有價值。ANS-C01 預設預期:v5 + ALL 動作 + S3 目的地 + Hive 分區 + Athena。

Q2:為什麼 Reachability Analyzer 偵測不到我間歇性的 SSH 逾時?

因為 Reachability Analyzer 是模擬,而非即時網路探測。它讀取路由表、安全群組、NACL、對等連線和 TGW 連接的當前配置,並報告配置的路徑在理論上是否允許封包從 A 到 B。間歇性故障是由 Reachability Analyzer 看不見的運行時條件引起的:NAT 閘道 SNAT 連接埠耗盡、MTU 黑洞 (PMTUD 失敗)、BGP 工作階段抖動、路由表變更後的路由傳播延遲、NLB 目標健康狀況抖動、擁塞的跨 AZ 鏈路或目的地執行個體核心層級的丟包。間歇性診斷的正確工具是:VPC Flow Logs (尋找受影響 ENI 上的 NODATA 期間,或非對稱 REJECT 模式)、針對 NAT 閘道 ErrorPortAllocation、ALB 目標健康狀況或 TGW PacketDropCountNoRouteCloudWatch 指標,以及當後設資料不足時用於協定層級調查的流量鏡像

Q3:Flow Logs 和 Network Firewall 日誌有什麼關係,為什麼 NFW 丟棄項不顯示為 REJECT?

VPC Flow Logs 和 AWS Network Firewall 日誌是不同層級的獨立來源。VPC Flow Logs 記錄在 ENI 層級採取的行動 —— ACCEPT (被 SG 和 NACL 允許) 或 REJECT (被 SG 或 NACL 拒絕)。Network Firewall 作為路徑中的獨立檢查設備,具有其自身的決策邏輯 (先是無狀態規則,然後是相容 Suricata 的有狀態規則) 和其自身的日誌串流:警示日誌 (匹配的有狀態規則) 和流程日誌 (防火牆看到的每個流程)。當 NFW 丟棄封包時,封包在防火牆處被消耗 —— 來源 ENI 的 VPC Flow Log 將顯示 ACCEPT (因為 SG 和 NACL 允許它進入線路),而 NFW 自身的日誌將顯示丟棄。要調查「NFW 是否正在阻斷此流量?」,你必須諮詢 S3、CloudWatch Logs 或 Kinesis Firehose 中的 NFW 日誌 —— 絕不應假設 Flow Log REJECT 能涵蓋它。這同樣適用於透過 Gateway Load Balancer 部署的第三方防火牆:其丟棄決策在設備內部,在 VPC Flow Logs 中不可見。

Q4:考慮到成本不對稱性,我何時該選擇流量鏡像而非 Flow Logs?

每當需要封包內容且 Flow Logs (僅限後設資料) 不足時,請選擇流量鏡像。具體觸發點:(a) 酬載模式偵測 —— Suricata 特徵、惡意軟體 C2 模式、文件上傳的 DLP 掃描;(b) 協定層除錯 —— TCP 重傳調查、MTU 黑洞重現、應用層錯誤重現;(c) 合規性封包保留 —— 當監管機構要求 N 天的完整 PCAP 而非連線後設資料時;(d) 事件取證擷取 —— 當執行個體被懷疑受損且你需要查看流量中實際說了什麼。對於其他所有情況,請選擇 Flow Logs:大流量分析、REJECT 模式偵測、基準效能、GuardDuty 輸入、Athena 歷史查詢。大規模流量鏡像會使你的有效網路頻寬翻倍 (鏡像副本與原始副本並行)、使目標 NLB 飽和,並產生額外的每 GB 處理費 —— 在目標調查期間將其限制在特定 ENI 和特定篩選器規則,然後停用。

Q5:如何為變更後的持續驗證建構 Reachability Analyzer?

模式是 Reachability Analyzer + EventBridge + Lambda + Security Hub 或 SNS。(1) 定義「始終必須可達」的路徑測試清單 —— 例如「網頁層 ALB ENI 必須能透過 TCP 8080 到達應用層 ENI」、「應用層必須能透過 TCP 5432 到達資料庫」、「公共子網路不得到達僅限內部的 S3 端點」。將測試輸入 (來源 ARN、目的地 ARN、連接埠) 編碼為 S3 中的 JSON 文件。(2) 建立在配置變更時觸發的 EventBridge 規則 —— 針對 AuthorizeSecurityGroupIngress、路由表修改、對等連線變更、TGW 連接事件和 Network Firewall 政策更新的 aws.ec2 事件。(3) 由 EventBridge 觸發的 Lambda 讀取測試輸入,為每個測試調用 CreateNetworkInsightsAnalysis,輪詢完成情況並檢查結果。(4) 分析失敗時,Lambda 向 SNS 發送通知進行呼叫,或為安全團隊建立 Security Hub 發現項。由於 Reachability Analyzer 具有區域並行配額,請限制 Lambda 調用速率。此模式完全滿足了 ANS-C01 技能要點「隨著網路配置變更自動驗證連線性意圖」的要求。

Q6:跨組織規模查詢 Flow Logs 的 Athena 模式是什麼?

使用具有 region/year/month/day/hour 的 Hive 相容分區的 S3 目的地,並對 Flow Log 記錄使用 Parquet 格式。使用 PARTITIONED BY (region string, year int, month int, day int, hour int) 建立 Athena 外部表,並定期執行 MSCK REPAIR TABLE 或 —— 更好的是 —— 使用分區投影 (Glue Data Catalog 功能),讓 Athena 從 S3 金鑰計算分區,而無需註冊開銷。撰寫帶有顯式分區篩選器的查詢 (例如 WHERE year = 2026 AND month = 5 AND day = 2),以便 Athena 僅掃描相關子集;沒有分區篩選器,Athena 會讀取整個儲存貯體,成本會激增。對於可重複的儀表板,將常用查詢具現化為單獨的 Glue 表或 QuickSight 數據集。對於組織規模,儲存貯體應位於 Log Archive 帳號中,並由 Security Tooling 帳號進行跨帳號讀取;這是 AWS 安全參考架構的規範佈局。

Q7:Reachability Analyzer 說我的路徑可達,但我的應用程式仍無法連線 —— 怎麼回事?

Reachability Analyzer 看不見的幾種可能性。(1) AWS Network Firewall 規則 — NFW 和經 GWLB 路由的設備未被 Reachability Analyzer 建模;諮詢 NFW 自身的日誌查看是否有狀態規則正在丟棄。(2) 應用程式接聽程式未綁定 — 目的地執行個體可能通過了網路可達性,但應用程式程序未在預期連接埠上接聽。(3) 主機級防火牆iptables、Windows 防火牆或容器級網路政策 (Calico, Cilium) 對 Reachability Analyzer 是不可見的。(4) MTU 黑洞 — Reachability Analyzer 不建模 PMTUD;VPC 對等互連或 VPN 之間的不對稱 MTU 可能會靜默丟棄大封包。(5) DNS 解析失敗 — Reachability Analyzer 接受 IP/ENI 輸入;如果你的應用程式透過名稱連線且 DNS 解析失敗,網路沒問題但連線從未開始。診斷階梯是:確認 Reachability Analyzer 顯示可達 → 檢查 NFW 日誌 → SSH 到來源執行個體並直接 curl 目的地 IP/連接埠 → 如果 curl 成功,問題在應用層;如果失敗,在來源上執行 tcpdump 並在目的地 ENI 上使用流量鏡像以查看 SYN 是否到達。

Q8:為什麼流量鏡像需要 Nitro?如果我有舊版執行個體該怎麼辦?

Nitro 管理程式將網路處理卸載到 Nitro 卡,提供了鏡像工作階段所需的線速封包複製路徑。在舊的基於 Xen 的執行個體世代 (m4, c4, r4, t2, m3, c3, r3) 上,管理程式無法在不影響效能的情況下以線速複製封包,因此 AWS 不支持在這些執行個體上設置鏡像來源。舊世代的後備方案:遷移到當前世代 (m6i, c6i, r6i, m5/c5/r5, t3/t4g —— 全都是 Nitro)。對於確實無法遷移的工作負載,替代方案是基於主機的擷取 (作業系統內部的 tcpdump 或 pktcap,導出到 S3 或邊車容器),或放置在路由路徑中的內嵌擷取設備 (具有第三方設備的 Gateway Load Balancer 可以記錄流量)。對於 ANS-C01,規範答案仍是「Nitro 上的流量鏡像」和「非 Nitro 的基於主機擷取」 —— 考試不會要求你為遺留執行個體類型設計奇特的擷取方案。

Q9:對於 Flow Log 查詢,CloudWatch Logs Insights 與 Athena 相比如何?

CloudWatch Logs Insights 最適合對近期數據 (過去幾小時到幾天) 進行互動式臨機查詢,其中開發人員體驗很重要:解析後的欄位、排序/限制、點擊篩選,並與你開啟日誌群組的主控台集成。定價是按每次查詢掃描的位元組計費,這對於 KB 到 MB 級別的臨機查詢沒問題,但在 GB 級別的查詢規模下會變得昂貴。在 S3 存儲的 Flow Logs 上的 Athena 最適合組織級、歷史性、儀表板化的查詢 —— Parquet 列式存儲、分區剪裁和 SQL 語意使其對於大體量分析顯著便宜。預設的 ANS-C01 架構:將 Flow Logs 同時發送到 CloudWatch Logs (短期保留、臨機查詢) 和 S3 (長期保留、Athena、分區)。使用 Logs Insights 查詢「此 ENI 在過去 30 分鐘內發生了什麼」,使用 Athena 查詢「顯示上個季度按來源服務分組的跨 AZ 流量」。兩者都可以透過 start-query / start-query-execution API 進行腳本化自動化。

Q10:我的組織要求保留 7 年的網路流量以符合監管合規 —— 架構是什麼?

Flow Logs 到 S3 配合生命週期政策和 Object Lock,外加針對需要完整 PCAP 的事件使用流量鏡像。具體而言:(1) VPC Flow Logs (v5, action=ALL, Parquet, Hive 分區) 寫入集中式的 Log Archive 儲存貯體,並開啟合規模式的 Object Lock (在保留期滿前,任何人包含 root 都無法刪除);90 天後轉換到 S3 Glacier Deep Archive 以節省成本;生命週期保留 7 年後過期。(2) 對於需要更深層封包內容的事件,在可疑 ENI 上啟用流量鏡像到取證 VPC,執行 Suricata/Zeek 收集器將 PCAP 轉儲到單獨的唯寫 S3 儲存貯體;僅在調查窗口加監管寬限期內保留 PCAP。(3) AWS Config 和 CloudTrail 日誌加入同一個 Log Archive 儲存貯體以提供配置審核軌跡。(4) Security Tooling 帳號中的 Athena 工作群組允許受控的跨帳號查詢,而無需授予原始儲存貯體讀取權限。此模式正是 AWS 安全參考架構,對於任何框架為「監管」或「合規」加「長期保留」的 ANS-C01 題目,這都是最高分的答案。

延伸閱讀與相關維運模式

一旦監控就緒,ANS-C01 的自然維運層級包括:網路效能最佳化,使用 ENA、EFA、巨量框架和置放群組;網路成本最佳化,包含 NAT GW 的按 AZ 部署、VPC 對等互連 vs TGW 經濟學,以及用於減少出口的 CloudFront;混合連線性維護,用於 BGP 路由限制、彙總和 Direct Connect 故障轉移測試;以及在檢查 VPC 進行狀態流量過濾的 AWS Network Firewall 深層檢查

官方資料來源

更多 ANS-C01 主題