網路監控與日誌設計

ANS-C01 中的網路監控與日誌記錄，是區分「網路工程師」與「SRE」的關鍵對話。Specialty 考試中充滿了這類情境：「應用程式偶爾變慢，BGP 工作階段回報為 UP，但面向客戶的 p99 延遲從 50ms 激增至 800ms — 你會關聯哪些遙測來源，以便在 10 分鐘內找到根本原因？」這是一個典型的網路工程師問題，涉及具備擴充欄位的 VPC Flow Logs v5、針對 NAT GW 錯誤與 BGP 工作階段狀態的 CloudWatch 指標、用於路徑驗證的 Reachability Analyzer、用於偵測非預期網際網路傳出的 Network Access Analyzer、用於全封包擷取的 Traffic Mirroring、用於跨區域拓撲的 Transit Gateway Network Manager、用於 HTTP 等級診斷的 ALB 存取日誌，以及針對封包遺失閾值、BGP 工作階段抖動 (flapping) 與頻寬飽和的主動警示 — ANS-C01 通常會在單個五行字的情境題中測試上述所有組件。

本主題完全涵蓋網域 1 (網路設計，佔考試 30%) 的任務陳述 1.4。官方 ANS-C01 考試指南逐字列出了相關知識點：「Amazon CloudWatch 指標、代理程式、日誌、警示、儀表板與洞察」、「AWS Transit Gateway Network Manager」、「VPC Reachability Analyzer」、「流程日誌與流量鏡像」以及「存取日誌記錄 (負載平衡器、CloudFront)」。技能要求促使你識別日誌需求、推薦可視化指標並擷取基準效能。65 題考試中約有 5 到 8 題涉及此範疇。

為什麼監控設計是 Specialty 考試的可靠性層

Specialty 考試將「網路工程師」定義為端到端掌控網路平面可觀測性的角色。沒有遙測數據，就無法驗證設計決策，無法診斷故障，也無法捍衛 SLA。考試之所以測試這些，是因為現實世界中的網路工程師花在解讀 CloudWatch 儀表板與流程日誌查詢上的時間，遠比畫架構圖的時間多。

考試獎勵的心理模型是分層遙測 (Layered Telemetry)：底部是低成本且常開的 (流程日誌元數據、CloudWatch 指標)，中間是具備針對性且詳盡的 (流量鏡像全封包、Reachability Analyzer 路徑模擬)，頂部是主動且自動化的 (CloudWatch 警示、EventBridge 規則、配置變更觸發 Reachability Analyzer)。ANS-C01 會為這種分層思考提供滿分；若候選人認為監控只是「開啟流程日誌」，則會在涉及封包負載檢測與主動警示的問題中失分。

白話文解釋網路監控與日誌設計

網路監控堆疊了五種截然不同的遙測來源 (Flow Logs, Traffic Mirroring, Reachability Analyzer, Network Access Analyzer, Network Manager)，外加 CloudWatch 指標與警示，以及來自負載平衡器 (LB) 與 CloudFront 的存取日誌。以下三個類比錨定了這些活動組件。

類比一：加護病房 (ICU) 監控室

VPC 的監控就像 ICU 的病人監控系統。

VPC Flow Logs 是生命體徵監測儀：心率、血壓、呼吸 — 持續採樣的元數據，儲存成本低，永遠在記錄，適合發現趨勢與異常。流程日誌不顯示器官間交談的內容 (封包負載)，僅顯示連線元數據 (5-tuple)。

Traffic Mirroring 是內視鏡攝影機：當出現特定疑慮時，醫生插入攝影機現場觀察完整內容。成本高且具侵入性，僅用於特定病人 (Nitro 執行個體)，但能揭示生命體徵監測儀看不到的負載級別細節。

Reachability Analyzer 是手術前的模擬：在手術開始前，手術團隊在模型上模擬程序 — 檢查從切口到器官的路徑是否暢通。不涉及實際手術刀 (線路上不發送實際封包)；分析是基於靜態圖形的。

Network Access Analyzer 是醫療權限稽核：誰擁有哪個病房的鑰匙？它會發現「這位護士無需醫生簽名即可進入藥房」 — 類比到網路，就是「這個 VPC 可以透過未經授權的路徑傳出到網際網路」。

Transit Gateway Network Manager 是醫院指揮中心儀表板：顯示全院每個側翼、每個病房、每位病人和每台設備的狀態，具備拓撲圖、路由分析與事件時間線。

CloudWatch 指標與警示 是床邊警鈴：當心率低於閾值時，鈴聲響起，護士跑進來。可配置閾值與冷卻時間。

存取日誌 (ALB, CloudFront) 是醫院櫃檯的病人掛號記錄 — 每位到達的病人、他們的要求、看診時間以及收到的回應。可用於計費、計費爭議以及行為分析。

類比二：機場空中交通管制 (ATC)

VPC 監控就像機場 ATC 與地面營運。

VPC Flow Logs 是飛行進程條 (Flight Strip)：每架飛機的起飛時間、航線、到達、被拒絕或接受的許可 — 每一次移動都會持續記錄。成本低，常開，但你聽不到駕駛艙內的談話。

Traffic Mirroring 是座艙通話記錄器 (CVR)：擷取完整音訊供事故後調查分析。僅在需要時在特定飛機 (Nitro 執行個體) 上啟用。

Reachability Analyzer 是簽派員的飛行計畫驗證：「考慮到航線、飛航公告 (NOTAM) 與燃料，這架飛機是否能從甘迺迪機場飛往東京？」 — 基於紙本的模擬，不涉及實際飛行。

Network Access Analyzer 是 TSA 安全稽核：是否有從公用航廈進入管制空側區域的未經授權路徑？發現「這個登機門具備非預期的貨運停機坪存取權限」。

Transit Gateway Network Manager 是區域空域管制中心：顯示 3 個區域 10 個機場的每架飛機，並在飛行模式偏離申請的飛行計畫時發出警示。

CloudWatch 指標 是跑道燈與氣象感測器：持續測量跑道狀況、風速、能見度，並在突破閾值時發出警示。

存取日誌 是登機口記錄：每位登機的乘客、時間、航班、機票。每一筆 ALB 或 CloudFront 請求的取證記錄。

類比三：工廠品質控制 (QC)

VPC 監控就像工廠的品質控制系統。

VPC Flow Logs 是生產線計數器：每件下線的零件、來源、去向、接受或退貨。常開，成本低，僅限元數據。

Traffic Mirroring 是顯微鏡與 X 光站：從線上取下一件零件，詳細檢查並影像化其內部結構。具針對性，成本高，針對負載等級。

Reachability Analyzer 是 CAD 中的組裝線模擬：在建造前模擬組裝路徑，以驗證沒有障礙物。

Network Access Analyzer 是工廠安全稽核：是否有未經授權的門連接著倉庫與機密的研發區？

Transit Gateway Network Manager 是廠長總覽儀表板：所有工廠、所有生產線、所有狀態指示燈，具備拓撲與路由追蹤工具。

CloudWatch 指標 是生產線感測器：溫度、壓力、轉速 — 持續採樣，可設定警示。

存取日誌 是出貨記錄：每箱離開倉庫的貨物，包含時間戳記、目的地與內容物。

VPC Flow Logs — 網路遙測的基礎

VPC Flow Logs 擷取流經 ENI、子網路或整個 VPC 的 IP 流量元數據。它們是 AWS 網際網路安全與網路營運遙測的基礎來源。

擷取範圍 (Capture scope)

流程日誌可在三個層次啟用，每個層次有不同的彙總方式：

• VPC 層級 — 擷取 VPC 中的所有 ENI。
• 子網路層級 — 擷取子網路中的所有 ENI。
• ENI 層級 — 擷取一個特定的 ENI。

較小範圍的流程日誌會覆蓋較大範圍的，因此 ENI 層級的日誌會取代該 ENI 的 VPC 層級日誌。

擷取類型 (Capture types)

流程日誌可擷取三種流量類型之一：

• ACCEPT — 僅記錄被允許的流量。
• REJECT — 僅記錄被拒絕 (由 SG 或 NACL) 的流量。
• ALL — 記錄被允許與被拒絕的所有流量。

對於安全性分析，建議將 ALL 作為預設設定 — 被拒絕的流量可以揭示配置錯誤的用戶端、連接埠掃描以及策略違規。

目的地 (Destinations)

• CloudWatch Logs — 近乎即時，可使用 Logs Insights 查詢，每 GB 成本較高，但更適合短期的即時儀表板。
• S3 — 長期儲存成本較低，可透過 Athena 按帳戶/區域/日期進行分區查詢。
• Kinesis Data Firehose — 串流至 SIEM (如 Splunk, Datadog, Sumo Logic) 或自訂資料湖。

v2 vs v3 vs v4 vs v5 記錄格式

流程日誌支援多種記錄格式版本，每個版本都會增加欄位：

• v2 (若不指定則為預設) — 原始 14 個欄位：version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status。
• v3 — 增加 VPC ID, 子網路 ID, 執行個體 ID, TCP 旗標, 流量類型, 封包來源/目的地 (pkt-src/dst) (這是「真實」的封包來源與目的地 IP，與中間跳轉點的 IP 不同 — 對於 NAT GW 分析極其有用)。
• v4 — 增加 AWS 服務識別碼 (pkt-src-aws-service, pkt-dst-aws-service 如 S3, EC2, RDS)、流量方向 (傳入/傳出) 以及流量路徑 (透過網際網路、透過 TGW 等)。
• v5 — 額外增加 6 個欄位，包括 ECS 任務 ARN、次要位置類型 (如 wavelength, outpost)、次要位置 ID — 對於容器與 Outposts 工作負載最詳盡的格式。

為了完整功能與 SIEM 擷取，請選擇 v5。無論格式為何，成本均相同。

擴充欄位 — v5 的關鍵改變

v3-v5 增加的欄位與考試高度相關：

• pkt-srcaddr / pkt-dstaddr：區分原始封包來源/目的地與跳轉點。對於 NAT GW 分析至關重要：直接來源可能是 NAT GW 的 IP，但 pkt-srcaddr 會揭示原始執行個體。
• pkt-src-aws-service / pkt-dst-aws-service：識別 AWS 服務字首 — 無需 IP 範圍查詢即可回答「這是 S3 流量嗎？」。
• flow-direction：相對於 ENI 的傳入 (ingress) 或傳出 (egress) — 對於理解方向性至關重要。
• traffic-path：透過 IGW、NAT GW、TGW、VGW、Direct Connect 等 — 對診斷路由非常有價值。

Flow Logs 不擷取的內容

流程日誌明確排除以下內容：

• 通往或來自 Amazon DNS 伺服器 (169.254.169.253) 的流量。
• Windows 授權啟用流量。
• 執行個體元數據服務 (IMDS) 請求 (169.254.169.254 — 包括 IMDSv2)。
• Amazon Time Sync (169.254.169.123)。
• DHCP 流量。
• 通往 VPC 路由器預留位址 (.1) 的流量。
• 使用 Gateway Load Balancer 時端點之間的流量 (此為鏡像流量，不符合 Flow Log 資格)。

對於這些監控盲點，請使用 Traffic Mirroring 或主機端日誌。

VPC Reachability Analyzer — 路徑驗證

VPC Reachability Analyzer 是一個靜態分析工具，可根據目前的 VPC、路由表、SG、NACL 與閘道配置，模擬流量是否能從來源到達目的地。它不會發送實際封包；它是分析配置圖形。

分析對象

你指定來源與目的地 — 執行個體、ENI、IGW、VGW、TGW、對等連接、VPC 端點。Reachability Analyzer 計算路徑：每一跳、評估的每個控制項 (SG, NACL, 路由表)，並回報 REACHABLE 或 NOT-REACHABLE，同時標出具體的阻斷控制項。

使用案例

• 部署前驗證 — 在推事變更前，模擬變更是否會破壞預期路徑。
• 合規性 — 定期排程分析以驗證「生產 VPC 無法從開發 VPC 到達」。失敗時發出警示。
• 疑難排解 — 營運人員提交「為什麼我的 Lambda 無法到達 RDS？」，Reachability Analyzer 指出缺少的路由表項目。

自動化模式

典型的 ANS-C01 情境：每當偵測到配置變更時 (透過 CloudTrail 事件)，EventBridge 規則觸發一個 Lambda，該 Lambda 為一組「意圖路徑 (Intent paths)」(例如「生產 App 必須到達 RDS」、「開發 VPC 不得到達生產 VPC」) 呼叫 Reachability Analyzer。Lambda 在路徑狀態變更時發出 SNS 警示。這是考試指南中「自動驗證連通性意圖」的技能。

限制

Reachability Analyzer 是模擬而非現場測試：

• 它分析靜態配置 — 運行時問題 (記憶體不足、主機端封包丟棄) 是看不見的。
• 它不測試延遲、吞吐量或抖動 — 僅測試連通性。
• 跨區域路徑僅限於 TGW 對等連接連通性。
• 它不分析第三方設備 (例如 GWLB 檢查 VPC 中的 Palo Alto VM-Series，其邏輯對分析器是透明的)。

Network Access Analyzer — 發現非預期存取

Network Access Analyzer 是另一種分析器：它不回答「A 能到達 B 嗎？」，而是回答「存在哪些未經授權的路徑？」。你定義一個範圍 (Scope) (例如「生產 OU 中的 VPC 除了透過檢查 VPC 外，不應具備任何 IGW 或 VPN 傳出路徑」)，分析器會標出所有違反該範圍的路徑。

範圍定義

範圍是 JSON 文件，指定來源與目的地謂詞：「來自任何生產 VPC」、「到網際網路 (0.0.0.0/0)」、「透過任何不包含檢查 VPC 的路徑」。範圍可在分析間重複使用。

調查結果分類

調查結果按嚴重性分類，並包含完整路徑。可與 Security Hub 整合以進行跨區域彙總。

與 Reachability Analyzer 的比較

• Reachability Analyzer：回答「A 能到達 B 嗎？」 — 針對特定的來源與目的地。
• Network Access Analyzer：回答「存在哪些令人驚訝的路徑？」 — 針對定義的範圍尋找違規。

兩者均為靜態配置分析；皆為考試重點。

Traffic Mirroring — 深層封包檢測 (DPI)

VPC Traffic Mirroring 將網路封包從來源 ENI 複製到目的地，以便進行頻外 (out-of-band) 分析。這是「在不中斷生產的情況下，擷取完整封包負載進行取證審查或 IDS」的答案。

組件 — 來源、目標、篩選器、工作階段

鏡像來源 (Mirror source) 是 Nitro 架構 EC2 執行個體 上的 ENI (不支援舊型執行個體)。鏡像目標 (Mirror target) 是網路負載平衡器 (NLB)、閘道負載平衡器 (GWLB) 或另一個 ENI。鏡像篩選器 (Mirror filter) 定義要複製哪些流量。鏡像工作階段 (Mirror session) 將來源 + 目標 + 篩選器綁定在一起。

僅限 Nitro 的要求

流量鏡像僅適用於基於 Nitro 的執行個體：M5/M5n/M6i, C5/C6i, R5/R6i, T3 以及類似世代。不支援舊型號 (M4, C4, R4, T2)。ANS-C01 會定期測試這一點。

使用案例

• 事件期間的取證擷取 (Forensic capture)。
• 使用 Suricata IDS 進行威脅獵捕。
• 合規性封包保留。
• 針對重傳、封包遺失的深層效能除錯。

成本

鏡像頻寬是翻倍的 — 鏡像的每一位元組都會增加網路帳單。對於高吞吐量的執行個體，這可能非常昂貴。請使用鏡像篩選器來減少鏡像量。

Transit Gateway Network Manager — 全球拓撲

Transit Gateway Network Manager 是你基於 TGW 網路在區域與帳戶間的全球視圖。在 ANS-C01 中，它是「為我們橫跨 5 個區域、47 個帳戶的 TGW 網狀網路提供單一可視化介面」的規範化答案。

全球網路 (Global Network) 註冊

全球網路是頂層構造。你在全球網路中註冊 TGW (以及本地設備、站點與鏈路)，以獲得統一的拓撲視圖。

拓撲與路由分析

Network Manager UI 顯示所有連接、路由表與傳播路由的拓撲圖。Route Analyzer 是 Network Manager 內的一個工具，可追蹤跨連接的封包 — 回答「如果我將封包從 VPC A 發送到 VPC B，會諮詢哪個 TGW 路由表，匹配哪些傳播路由，下一跳又是哪裡？」。這是 Reachability Analyzer 在 TGW 跨連接層級的對應物。

事件通知

當拓撲變更 (建立連接、修改路由表、建立對等連接) 時，Network Manager 將事件發佈至 EventBridge — 可用於在每次變更時觸發 Reachability Analyzer 或合規性檢查。

TGW 的 CloudWatch 指標

Network Manager 提供 TGW 指標：BytesIn, BytesOut, PacketsIn, PacketsOut, PacketsDropCountBlackhole, PacketsDropCountNoRoute。丟包計數器對診斷至關重要：BlackholeRoute 表示 TGW 路由表中的刻意丟棄；NoRoute 表示路由缺失 — 這是配置臭蟲。

與 Reachability Analyzer 的比較

• Reachability Analyzer：VPC 層級的路徑分析。
• Route Analyzer (在 Network Manager 中)：TGW 層級的路徑追蹤。

兩者皆為考試重點；根據問題是 VPC 內部還是跨連接來選擇。

CloudWatch 網路指標

CloudWatch 是 AWS 網路服務的指標與警示平面。每項服務都會發佈一組與監控相關的獨特指標。

NAT 閘道指標

• BytesInFromDestination, BytesOutToSource, BytesInFromSource, BytesOutToDestination — 按方向計算的位元組數。
• ConnectionAttemptCount, ConnectionEstablishedCount — 連線率。
• ErrorPortAllocation — 連接埠耗盡 (NAT GW 規範化的故障模式)。
• IdleTimeoutCount — 閒置 TCP 逾時。
• PacketsDropCount — 丟失的封包。

ErrorPortAllocation > 0 是一個關鍵警示 — 它表示 NAT GW 已耗盡暫時連接埠，新的連線將會失敗。

Direct Connect 指標

• ConnectionState — 1 表示連通，0 表示中斷。
• ConnectionBpsEgress, ConnectionBpsIngress — 頻寬。
• ConnectionPpsEgress, ConnectionPpsIngress — 封包速率。
• ConnectionLightLevelTx, ConnectionLightLevelRx — 光纖傳送/接收光等級 (光纖老化警告)。
• VirtualInterfaceBpsEgress 等 — 針對每個虛擬介面 (VIF)。

VPN 通道指標

• TunnelState — 1 表示連通，0 表示中斷。按通道計算。
• TunnelDataIn, TunnelDataOut。
• TunnelEstablished — 近期故障事件。

TGW 指標

• BytesIn, BytesOut, PacketsIn, PacketsOut。
• PacketsDropCountBlackhole, PacketsDropCountNoRoute。

ALB 指標

• RequestCount, TargetResponseTime, HealthyHostCount, UnHealthyHostCount。
• HTTPCode_Target_4XX_Count, HTTPCode_Target_5XX_Count。
• RejectedConnectionCount — 當 ALB 因容量限制而拒絕連線時。

NLB 指標

• ActiveFlowCount, NewFlowCount, ProcessedBytes。
• TCP_Client_Reset_Count, TCP_Target_Reset_Count, TCP_ELB_Reset_Count — 揭示異常行為的 RST 計數。

CloudWatch 警示 — 主動警報

針對關鍵指標設定警示：

• BGP 工作階段中斷：Direct Connect VirtualInterfaceState != UP 持續 5 分鐘 → 呼叫值班人員。
• NAT GW 連接埠耗盡：ErrorPortAllocation > 0 → 立即警報。
• VPN 通道抖動 (flap)：1 小時內 TunnelState 變更次數 > 3 → 發出警示。
• 頻寬飽和：ConnectionBpsEgress > 埠容量的 80% → 警告 (容量規劃)。
• TGW 路由丟包：PacketsDropCountNoRoute > 0 → 警報 (路由表臭蟲)。

存取日誌記錄 — ALB, NLB, CloudFront, API Gateway

存取日誌擷取負載平衡器或邊緣服務處理的每個 HTTP 請求 (或 NLB 的 TCP 連線)。它們補充了應用層的細節，是對流程日誌 (網路層) 的有力補充。

ALB 存取日誌

ALB 將存取日誌寫入 S3 (無 CloudWatch 選項)。每行日誌包含：時間、ALB ARN、用戶端 IP:port、目標 IP:port、請求處理時間、目標處理時間、回應時間、ELB 與目標狀態碼、接收與發送位元組、請求行、User Agent、SSL 加密套件與協定、目標群組 ARN、追蹤 ID、網域名稱、所選憑證 ARN、匹配規則優先級、請求建立時間、執行的動作、重導向 URL、錯誤原因、目標狀態、分類以及分類原因。

存取日誌每 5 分鐘寫入一次 S3。使用 Athena 進行查詢。

NLB 存取日誌

NLB 存取日誌 (僅限 TLS 接聽程式 — TCP/UDP 無日誌) 同樣寫入 S3。細節比 ALB 日誌少 (NLB 看不見 HTTP)。

CloudFront 存取日誌

CloudFront 有兩個日誌選項：標準日誌 (每分鐘交付至 S3) 與 即時日誌 (Kinesis Data Streams，亞秒級延遲)。即時日誌的欄位可自訂；標準日誌採用固定結構。

API Gateway 存取日誌

API Gateway 將執行日誌與存取日誌寫入 CloudWatch Logs。可按階段 (stage) 配置。

使用案例

• 安全性調查：哪個 IP 發起了惡意請求、使用什麼 User Agent、返回了什麼回應。
• 效能除錯：尾部延遲 (Tail latency) 分析、識別慢速路徑。
• 計費爭議：證明或反駁客戶關於請求量的說法。

基準效能擷取與趨勢分析

Specialty 考試期望你在事件發生前擷取基準效能 (Performance Baseline) — 這樣才能偵測到偏離現象。

基準化對象

• TCP 重傳率：健康的網路上應低於 0.1%。
• 延遲 p50, p99, p999：按區域、按 AZ、按端點計算。
• 頻寬利用率：針對每個 Direct Connect、每個 VPN 通道的峰值 vs 平均值。
• NAT GW 每秒連線數：峰值。
• Flow Logs 流程率：每個 VPC 每分鐘的流量。

工具

• CloudWatch 指標 (內建) — 用於 AWS 服務。
• CloudWatch Synthetics — 持續探測 HTTP 端點的探針 (Canaries)。
• CloudWatch Logs Insights — 查詢流程日誌以獲取衍生指標，如流量率、前幾大通訊者。
• 第三方代理程式 (Datadog, New Relic) — 用於更深層的應用層遙測。

趨勢分析與儀表板

建立結合流程日誌查詢、NAT GW 指標、BGP 工作階段狀態與警示歷史記錄的 CloudWatch 儀表板。隨架構演進更新儀表板。

常見陷阱總結 — ANS-C01 網路監控

陷阱 1：流程日誌區分 SG 還是 NACL 丟包

錯。REJECT 是二元的結果；不具備控制項歸因。

陷阱 2：Reachability Analyzer 是現場的 ping 測試

錯。它是靜態配置的模擬。

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

錯。僅限 Nitro 架構執行個體。

陷阱 4：流程日誌擷取 VPC 中的所有流量

錯。通往 AWS DNS、IMDS、NTP、授權啟用與 DHCP 的流量被排除。

陷阱 5：VPC 流程日誌包含封包負載內容

錯。僅限元數據 (5-tuple, bytes, packets)。查看內容請使用流量鏡像。

陷阱 6：Network Firewall 丟包會出現在 VPC 流程日誌中

錯。NFW 有獨立的流程日誌與警示日誌。

陷阱 7：Reachability Analyzer 可跨 AWS 帳戶工作

部分正確。跨帳戶分析需要明確的 RAM 共享資源或 AWS Organizations 整合。

陷阱 8：NAT GW 的 BytesInFromSource 表示瓶頸所在

部分正確。瓶頸訊號是 ErrorPortAllocation > 0，而非位元組數。

陷阱 9：Network Manager 的 Route Analyzer 用於 VPC 路由

錯。僅限 TGW 等級路由。若需 VPC 路由分析，請使用 Reachability Analyzer。

陷阱 10：ALB 存取日誌預設發送至 CloudWatch

錯。ALB 日誌僅發送至 S3。CloudFront 日誌發送至 S3 (標準) 或 Kinesis (即時)。

陷阱 11：v5 流程日誌比 v2 貴

錯。每 GB 成本相同。應始終選擇 v5。

陷阱 12：Reachability Analyzer 可驗證 TGW 對等連接連通性

部分正確。它可以分析透過 TGW 對等連接的路徑，但跨區域複雜性有限。

FAQ — ANS-C01 中的網路監控

Q1：我何時該使用 VPC Flow Logs vs Traffic Mirroring vs CloudWatch 指標？

流程日誌 (Flow Logs) 用於連線級別的元數據 — 成本低、常開，是安全性基準、GuardDuty 輸入與廣泛異常偵測的理想選擇。流量鏡像 (Traffic Mirroring) 用於完整封包負載 — 成本高、具針對性，是取證擷取、IDS 簽名匹配與協定等級除錯的理想選擇。CloudWatch 指標 用於服務等級的健康與頻率訊號 — 頻寬、錯誤率、BGP 工作階段狀態、連接埠耗盡。它們是互補的。Specialty 考試會結合這三者：「使用流程日誌偵測異常，使用流量鏡像檢測負載，使用 CloudWatch 指標驗證症狀」。

Q2：Reachability Analyzer 與 Network Access Analyzer 有何不同？

Reachability Analyzer 回答「根據目前配置，資源 A 能到達資源 B 嗎？」 — 針對特定來源與目的地的點對點分析。Network Access Analyzer 回答「根據定義的範圍 (例如：生產 VPC 絕不應直接到達網際網路)，存在哪些非預期的路徑？」 — 大範圍分析，標出所有違規。使用 Reachability Analyzer 來「驗證預期路徑」；使用 Network Access Analyzer 來「發現非預期路徑」。兩者均為靜態配置分析 (非實測)。Specialty 考試情境中的關鍵字：看到「預期 (intended)」選 Reachability Analyzer；看到「尋找任何未授權」選 Network Access Analyzer。

Q3：如何診斷一個回報為 UP 但正在丟失封包的 BGP 工作階段？

分層遙測。(a) 檢查 CloudWatch Direct Connect 指標：ConnectionState (1 為正常)、ConnectionBpsEgress/Ingress (是否飽和？)、LightLevelTx/Rx (光纖層健康)、ConnectionPpsEgress (封包速率)。飽和或光等級下降表示物理層問題。(b) 檢查 VPC Flow Logs (v5 欄位)，篩選 traffic-path = ThroughDX。尋找重傳現象 (TCP 旗標包含 SYN-ACK 重試) 與偏離的封包計數。(c) 如果流量跨越 TGW，檢查 TGW Network Manager 指標。(d) 設定 CloudWatch 警示 以監測 BGP 抖動 (1 小時內 VirtualInterfaceState 變更次數 > 3)。針對「BGP 正常但丟包」的考試答案：調查光纖光等級 (LightLevelTx/Rx)、調整 BGP Hold Time、啟用 BFD。

Q4：v5 流程日誌比 v2 增加了什麼內容？

關鍵欄位：pkt-srcaddr / pkt-dstaddr (真實來源/目的地 IP，與中間跳轉點 IP 不同 — 對 NAT GW 分析至關重要)、pkt-src-aws-service / pkt-dst-aws-service (不需查詢 IP 範圍即可識別 AWS 服務流量)、flow-direction (相對於 ENI 的傳入/傳出)、traffic-path (透過 IGW, NAT GW, TGW 等)、VPC ID, 子網路 ID, 執行個體 ID (跨資源關聯)、TCP 旗標，以及用於容器/Outposts 工作負載的 ECS 任務 ARN, 次要位置類型/ID。成本與 v2 相同。新部署應始終選擇 v5。

Q5：如何針對 Direct Connect BGP 工作階段中斷設定主動警報？

為每個 VIF 的 VirtualInterfaceState 指標建立 CloudWatch 警示：5 分鐘內 1 個數據點的加總 < 1。指標正常為 1，中斷為 0。將警示動作設定為發佈至 SNS 主題，繼而路由至 PagerDuty、Slack 或郵件。針對 BGP 抖動模式 (間歇性連通/中斷)，使用 MetricMath 計算「VirtualInterfaceState 近期變更次數」 — 若 1 小時內變更超過 3 次則觸發警示。同時為 ConnectionBpsEgress 飽和設定警示 (埠容量的 >80%) 用於容量規劃。設計主動 BGP 監控的 Specialty 答案：VirtualInterfaceState + LightLevelTx/Rx 下降 + ConnectionPpsEgress 飽和之警示，全部路由至 SNS。

Q6：流量鏡像何時會發生無法交付封包到目標端的情況？

常見失敗原因：

• 來源 ENI 位於非 Nitro 執行個體 (m4, c4 等) — 流量鏡像會靜默失效。
• 來源與目標位於不同帳戶 — 需要 VPC 對等連接或 TGW 連通性。
• 鏡像目標 NLB 負載過重 — 頻寬翻倍了 (原始 + 鏡像)，NLB 無法負荷。
• 鏡像篩選器過於嚴苛 — 封包在發送前就被過濾掉了。
• 鏡像目標 ENI 的安全性群組過緊 — 丟棄了 GENEVE 封裝的流量。

診斷方法：檢查鏡像工作階段的 CloudWatch 指標 (MirrorSession Bytes)、目標 NLB 指標 (ActiveFlowCount, ProcessedBytes) 以及 NLB 目標健康狀況。

Q7：如何具備成本效益地儲存流程日誌，並支援隨機查詢？

S3 搭配 Athena 是標準模式。將流程日誌設定至 S3 目的地，格式選為 Parquet (比文字格式更小且查詢更快)，並按帳戶/區域/日期進行分區。Athena 查詢僅掃描相關分區 (大幅降低成本)。針對保留 90 天以上的日誌，使用 S3 Glacier Instant Retrieval 進一步降低成本。使用 Athena 的 CTAS (CREATE TABLE AS SELECT) 將衍生表 (例如「每小時前 10 大通訊者」) 實體化，以實現快速的儀表板查詢。針對「具備成本效益地保留流程日誌 1 年並支援隨機查詢」的 Specialty 答案：S3 Parquet + Athena + 生命週期策略至 Glacier。

Q8：Route Analyzer 與 Reachability Analyzer 有何區別？

Reachability Analyzer 的範圍在 VPC 內 — 分析 VPC 內部及相鄰的路由表、SG、NACL、閘道。Route Analyzer (在 Transit Gateway Network Manager 內) 的範圍在 TGW — 分析 TGW 路由表、連接、橫跨 TGW 及其對等連接的傳播路徑。根據你懷疑問題所在的位置進行選擇。對於「VPC A 的執行個體無法到達連在同一個 TGW 的 VPC B 的 RDS」，你會兩者併用：Reachability Analyzer 確認 VPC 內部路徑，Route Analyzer 確認 TGW 路徑。ANS-C01 經常區分兩者。

Q9：如何擷取正常網路行為的基準 (Baseline) 以偵測異常？

為以下對象建立基準：(a) 每個 Direct Connect / VPN / NAT GW 的頻寬利用率 (峰值、p99、平均值)；(b) TCP 重傳率 (應 <0.1%)；(c) 區域間、AZ 間、至常見目的地 (S3, DynamoDB, 公有 API) 的延遲 p50/p99/p999；(d) NAT GW 並行連線數；(e) 每個 VPC 的流程率 (每分鐘流程數)；(f) BGP 路由公告數量。運行 2-4 週獲取典型數據，然後設定 CloudWatch 異常偵測警示 (自動調整的統計基準)。對於 30 天滾動基準，CloudWatch 異常偵測帶是簡單的答案；對於靜態基準，設定硬編碼閾值。ANS-C01 獎勵「事件前擷取基準，偏離時警報」的主動態勢。

Q10：對於流程日誌查詢，CloudWatch Logs Insights 比 Athena 多了什麼？

CloudWatch Logs Insights 最適合針對近期數據 (過去幾小時到幾天) 進行互動式隨機查詢。優點：即時 (亞秒級)、互動式、與 CloudWatch 儀表板整合。缺點：每擷取 GB 成本較高、保留期有限 (1-10 年可配置)、分區自動但顆粒度較粗。Athena 查詢 S3 儲存的流程日誌 (建議 Parquet)。優點：較便宜、支持海量歷史數據、自訂分區。缺點：查詢延遲較高 (秒級至分鐘級)、需要明確的 DDL 表結構。使用 Logs Insights 進行主動調查 (過去 1-7 天)，使用 Athena 進行歷史分析 (90 天至 7 年)。許多 SCS-C02 / ANS-C01 架構會同時使用兩者。

進階閱讀與相關營運模式

• VPC Flow Logs
• VPC Flow Logs 記錄範例
• VPC Reachability Analyzer
• Network Access Analyzer
• VPC Traffic Mirroring
• Transit Gateway Network Manager
• Amazon CloudWatch 使用者指南
• ALB 存取日誌

建立監控與日誌後，ANS-C01 的下一個營運層級為：用於深入網域 3 疑難排解的 VPC 流程日誌、Reachability Analyzer 與流量鏡像；關於監控層所觀察的吞吐量層級的網路效能 — ENA、EFA、置放群組與巨型框架；會產生自身獨立流程與警示日誌的 AWS Network Firewall — Suricata 規則、TLS 檢測與集中部署；以及將流程日誌、CloudTrail、Config 與 Firewall Manager 組合成稽核故事的合規、稽核與網路治理。

• VPC 流程日誌、Reachability Analyzer 與流量鏡像 — ANS-C01 學習筆記
• 網路效能 — ENA、EFA、置放群組與巨型框架 — ANS-C01 學習筆記
• AWS Network Firewall — Suricata 規則、TLS 檢測與集中部署 — ANS-C01 學習筆記
• 合規、稽核與網路治理 — ANS-C01 學習筆記