網路監控、疑難排解與成本優化

AWS Certified Advanced Networking — Specialty (ANS-C01) 考試將成本優化視為一項核心的網路工程技能，而非事後的想法。網域 3 任務 3.3 明確要求你「針對效能、可靠性和成本效益優化 AWS 網路」，而與成本相關的技能點則點出了減少頻寬利用率 (CloudFront、多播 vs 單播)、選擇具備成本效益的混合連線、根據成本在 VPC 對等連接 (VPC Peering) 與 Transit Gateway 之間做出選擇，以及優化子網路以防止 IP 枯竭。考試會編寫四種架構皆可運作，但只有一種在經濟上合理的情境 — 而識別出那條最省錢的路徑就是正確答案。

本主題綜合了整個網域 3 的跨領域成本與營運故事。我們涵蓋了 AWS 資料傳輸定價模型，包括區域內/跨 AZ/區域間/網際網路傳出等層級；NAT 閘道中跨 AZ 資料傳輸被重複計費的陷阱及其按 AZ 部署的解決方案；VPC 對等連接與 Transit Gateway 的決策矩陣，其中對等連接本身是「免費」的，但 TGW 提供的集中化管理價值值得其按連接收取的費用；利用 CloudFront 卸載昂貴的網際網路傳出流量；用於免費私有存取 S3 和 DynamoDB 的閘道端點；PrivateLink 介面端點的成本權衡；能在問題變成帳單前捕捉到它們的 CloudWatch 指標與警示；用於藍綠 DNS 遷移的 Route 53 加權路由；子網路優化 (包含針對 IP 枯竭的次要 CIDR)；以及當帳單意外激增時的規範化疑難排解流程。

為什麼網路成本是 ANS-C01 的核心

在大多數 AWS 帳單中，網路是第二大支出項目 (僅次於運算)，而在網路支出中，最大的項目通常是 NAT 閘道、跨 AZ 資料傳輸以及跨區域複寫。考試之所以重視這一點，是因為錯誤的網路架構可能會在不改變功能的情況下使帳單翻 5 到 10 倍 — 而識別出這些架構陷阱正是進階網路專家 (Specialty) 與解決方案架構師助理 (Associate) 的區別所在。

ANS-C01 的成本優化涵蓋範圍：

• NAT 閘道按小時收費 ($0.045/小時) 加上處理的每 GB 資料費用 ($0.045/GB)。在 24×7×30 天且有適度傳出的情況下，單個 NAT 閘道在產生任何流量前就輕鬆超過 $200/月。乘以 AZ 數量 (標準建議是每個 AZ 一個 NAT 以實現高可用性)，成本會迅速累積。
• 跨 AZ 資料傳輸在每個方向收費 $0.01/GB — 意味著來回每 GB 需要 $0.02 — 許多設計會無意中為透過單個 NAT 閘道在 AZ 之間彈跳的流量支付雙倍費用。
• 區域間流量更貴：北美地區跨區域每 GB $0.02，跨洲則更高。跨區域 VPC 對等連接並非免費。
• VPC 對等連接本身是免費的；透過它傳輸的資料則按適用的跨 AZ 或區域間費率計費。
• Transit Gateway 按每個連接每小時收費 ($0.05/小時) 加上處理的每 GB 資料費用 ($0.02/GB)。對於許多支點 (spoke) VPC 而言，TGW 比全網狀對等連接更經濟；對於兩三個 VPC 而言，對等連接在成本上勝出。
• 用於 S3 和 DynamoDB 的閘道端點完全免費 — 無小時費，無每 GB 處理費。它們是 AWS 網路中單一槓桿率最高的成本優化工具。
• 介面端點 (PrivateLink) 按每個 ENI 每個 AZ 每小時收費 ($0.01/小時/ENI/AZ) 加上處理的每 GB 資料費用 ($0.01/GB) — 在大規模環境下具有顯著意義，對於 AWS 服務流量，通常比 NAT 閘道替代方案更便宜。
• CloudFront 將網際網路傳出卸載到其邊緣網路，其每 GB 費率低於直接從 EC2/S3 傳出，並提供區域和基於用量的階梯折扣。

ANS-C01 期望你內化此定價模型，並識別出那些透過微小架構調整即可產生 50% 以上成本節省的模式。

白話文解釋網路監控、疑難排解與成本優化

這個心理模型分為三個層次：帳單由拓撲結構決定 (流量流向何處)，拓撲結構由路由決策決定 (每個子網路使用哪個閘道)，而路由決策可透過指標和流程日誌 (Flow Logs) 觀察到 (以便診斷成本激增)。以下三個類比會有幫助。

類比一：城市高速公路收費系統

將你的 VPC 想像成一個擁有多個行政區 (AZ) 的城市，連接著它們的高速公路 (子網路和路由表)，以及特定橋樑上的過路費 (每 GB 費用)。NAT 閘道是通往郊區 (網際網路) 的收費橋樑 — 每輛車 (封包) 在出城時都要支付過路費，並且有一個固定費率來維持橋樑 24×7 開放。如果你在每個行政區都建一座收費橋 (每個 AZ 一個 NAT GW)，並引導 A 區的車只走 A 橋，那麼流量只需過一次橋、付一次錢。如果你只在 A 區建一座收費橋，並強迫 B 區的車先穿過跨區公路 (跨 AZ 資料傳輸) 來到 A 橋，那麼每輛車都要同時支付跨區公路費和過路費 — 這就是雙重計費陷阱。考試中的規範化修正方案是「每個 AZ 部署一個 NAT GW」，讓每輛車都使用當地的橋樑。

VPC 對等連接是兩個特定行政區之間的專用私有道路 — 道路本身不收費，但仍需支付跨區費用。Transit Gateway 是一個中央樞紐，有一個入口、一套過路費，但一旦加入，每個行政區都可以透過它路由。對於一個只有 3 個行政區的城市，直接的私有道路 (全網狀 = 3 條路) 比建中央樞紐更便宜。對於一個有 30 個行政區的城市，中央樞紐 (30 個連接) 顯然比全網狀的 435 條路便宜得多。S3/DynamoDB 的閘道端點是免費的私有地鐵站 — 無過路費，無車資；對於主要前往中央圖書館 (S3) 的行政區，地鐵完全消除了橋樑過路費。CloudFront 是全城配送服務，從中央圖書館取件並透過社區倉庫分發，每件的配送費用比直接郵寄便宜。

類比二：電網

網路成本就像電費單。NAT 閘道的小時費是每月電表租金 — 無論用電量多少都是固定的。每 GB 資料處理費是每度電的單價 — 隨流量變化。跨 AZ 資料傳輸是單獨計費的變電站間傳輸損耗 — 電力雖然送到了，但電力公司會為遠距離傳輸收費。閘道端點就像現場太陽能發電 — 就地生產/消費，無傳輸費，無電表費。CloudFront 是全城屋頂太陽能網絡 — 社區倉庫的在地發電減少了遠距離傳輸需求。

類比三：貨櫃物流

將每個封包視為一個貨櫃。NAT 閘道是中央出口港，具有固定營運成本和按貨櫃收取的裝卸費。跨 AZ 運輸是同一個港口內航站間的卡車接駁。直接的 VPC 對等連接是兩個特定倉庫之間的鐵路連線 (軌道免費，但按貨櫃收費)。Transit Gateway 是所有倉庫都連接的中央鐵路樞紐 (適度的樞紐費加上按貨櫃收取的費用)。CloudFront 是預付的批發運輸加盟店，彙總許多寄件人以獲得更低的按貨櫃費率。S3 的閘道端點是每個倉庫與中央圖書館之間專用的免費氣動管 (Pneumatic tube) — 無費用，無摩擦。

AWS 資料傳輸定價模型

定價模型根據位元組流向何處分為不同的層級。ANS-C01 期望你一看到就能識別出這些層級。

區域內、AZ 內 (In-region, intra-AZ)

兩個 ENI 在同一個 AZ 透過私有 IPv4 (使用當地 RFC 1918 地址) 進行的流量是免費的。這就是為什麼 AWS 架構師總是建議將對延遲敏感且頻寬需求大的組件保持在同一個 AZ 中 — 無論是出於效能還是成本考量。

區域內、跨 AZ (私有 IP)

同一個區域內不同 AZ 之間透過私有 IPv4 的流量費用為每個方向 $0.01/GB = 來回 $0.02/GB。這就是「跨 AZ 稅」 — 每位元組看起來很少，但在大規模情況下非常驚人。一個每天在 AZ 間複寫 1 TB 資料的資料庫，僅跨 AZ 費用每個月就約為 $300。

區域內、公有 IP (或透過 NAT)

流向同一個區域內另一個 EC2 執行個體的公有 IP (或透過 NAT 閘道出去再回來) 的流量比私有 IP 流量更貴。這就是為什麼區域內通訊應始終使用私有 IP — 架構更便宜，安全邊界也更嚴密。

區域間 (Inter-region)

透過區域間 VPC 對等連接或 Transit Gateway 對等連接在 AWS 區域之間傳輸的流量，在北美和歐洲境內費用為 $0.02/GB；跨洲 (亞太地區、南美洲) 則更高。重要提示：區域間對等連接並非免費，即便同區域對等連接的連接本身是免費的。

網際網路傳出 (Internet egress)

從 EC2/NAT/IGW 傳出到公有網際網路的流量，前 10 TB/月費用為 $0.09/GB，更高月傳輸量級距會有階梯折扣 (10–50 TB 為 $0.085，$50–150 TB 為 $0.07，$150 TB 以上為 $0.05)。從網際網路傳入的流量不收費。

CloudFront 傳出 (CloudFront egress)

透過 CloudFront 傳出的費用低於直接從 EC2 傳出的每 GB 費率，且具備顯著的階梯折扣 — 低用量時為 $0.085/GB，極高用量時降至約 $0.02/GB。CloudFront 還提供「區域邊緣快取 (Regional Edge Cache)」，將已快取回應的源傳出 (origin egress) 降至約 $0.02/GB。CloudFront + S3 源伺服器模式可為高流量網頁應用程式減少 50–80% 的傳出成本。

NAT 閘道：最常被誤解的成本中心

NAT 閘道是規範化的 AWS 成本陷阱。它是不可或缺的 (私有子網路需要傳出網際網路來進行 OS 更新、套件下載、以及在沒有端點的情況下呼叫 AWS 服務)，它很貴 (在大多數區域每個閘道約 $0.045/小時外加每處理 1 GB 資料約 $0.045)，且部署模式會極大程度地影響帳單。

按 AZ 部署 NAT GW

具備成本效益的高可用性 (HA) 模式：每個 AZ 一個 NAT 閘道，每個 AZ 的私有子網路路由表將 0.0.0.0/0 指向當地的 NAT GW。來自 AZ-1 執行個體的流量流向 NAT-1 (無跨 AZ 費用)；來自 AZ-2 執行個體的流量流向 NAT-2 (無跨 AZ 費用)。每小時成本：約 $0.045/小時 × 3 個 AZ × 730 小時 = 每月僅閘道本身就約 $98，外加按 GB 計費的處理費。

單個 AZ 部署 NAT GW 的陷阱

錯誤模式：在 AZ-1 部署一個 NAT GW，並將 AZ-2 和 AZ-3 的私有子網路路由指向它。現在，來自 AZ-2 執行個體的每個位元組都會經歷：(a) 跨 AZ 到達 NAT-1 ($0.01/GB)，(b) 由 NAT-1 處理 ($0.045/GB)，(c) 傳出到網際網路 ($0.09/GB)。對於單個位元組：總計 $0.145，而按 AZ 部署 NAT 只需 $0.135 (僅 NAT 處理 + 傳出)。聽起來差別很小，但在 TB 等級下，跨 AZ 成本會不斷累積 — 且此架構的可用性也較低 (NAT-1 所在 AZ 故障也會導致 AZ-2 和 AZ-3 斷網)。

NAT GW SNAT 連接埠耗盡

NAT 閘道針對每個閘道使用具有固定連接埠範圍的來源 NAT (SNAT)。CloudWatch 指標 ErrorPortAllocation 會計算 SNAT 失敗次數，當太多指向相同目的地 IP+連接埠的並行連線耗盡連接埠範圍時，就會發生這種情況。解決方法：將連線分散到多個目的地 IP (前面放負載平衡器)、使用多個 NAT 閘道並拆分路由，或將工作負載移至不需要 NAT 的服務 (針對 AWS 服務使用 VPC 端點)。

以端點取代 NAT

減少 NAT 成本單一影響力最高的操作：消除 AWS 服務流量的 NAT 需求。(1) S3 流量 → 閘道端點 (免費)。(2) DynamoDB → 閘道端點 (免費)。(3) KMS、Secrets Manager、STS、Systems Manager、ECR、SQS、SNS、EventBridge 等 → 介面端點 (按 AZ ENI 小時收費，但無每 GB 的 NAT 處理費)。對於 80% 傳出流量為 AWS 服務呼叫的工作負載，切換到端點可以讓 NAT 帳單降低 80%，以較小的介面端點固定小時費取代變動的每 GB 處理費。

VPC 對等連接 vs Transit Gateway：成本決策

常見的 ANS-C01 題目模式：「你有 N 個 VPC 需要相互通訊。哪種連線選項能將成本降至最低？」。答案取決於 N。

VPC 對等連接經濟學

VPC 對等連接本身是免費的；你只需按標準的跨 AZ 或區域間費率支付資料傳輸費用。對於同一個區域內的兩個 VPC，對等連接是最便宜的選項 — 無小時費，只有資料傳輸費。

N 個 VPC 的全網狀連接需要 N(N-1)/2 個對等連接 — 當 N=3 時需 3 個對等連接；N=10 時需 45 個；N=30 時需 435 個。每個對等連接都必須手動接受，且每個 VPC 的路由表都必須針對所有其他 VPC 的 CIDR 進行更新。當 N 較小 (2–4 個 VPC) 時，對等連接在成本和簡易性上勝出；超過此範圍，路由表維護負擔就會變成營運上的痛苦，即便原始成本仍然較低。

VPC 對等連接不支援遞移路由 (transitive routing) — VPC-A 與 VPC-B 建立對等連接，VPC-B 與 VPC-C 建立對等連接，並不代表 VPC-A 可以存取 VPC-C。這是一個硬性限制。

Transit Gateway 經濟學

TGW 按每個連接每小時收費 ($0.05/小時) 加上處理的每 GB 資料費用 ($0.02/GB)。對於一個連接著 10 個 VPC 的 TGW，單是這 10 個連接每個月就約需 $365，外加資料處理費。對於高流量的工作負載，每 GB 處理費通常是主要成本。

但 TGW 在規模化時具有壓倒性的營運優勢：集中式路由管理 (每個安全區段一個 TGW 路由表)、支援遞移路由、與 AWS RAM 整合以進行跨帳戶共享、支援區域間對等連接、與 Site-to-Site VPN 和 Direct Connect Gateway 整合，以及透過 TGW Connect 支援 SD-WAN。對於超過約 5 個 VPC 的情況，TGW 在營運上要簡單得多，且成本差異是合理的。

損益平衡點

粗略的啟發式規則：對於 2 到 4 個 VPC，對等連接更便宜且更簡單。對於 5 到 10 個 VPC，TGW 在營運上變得更好；成本相當。對於 10 個以上 VPC，TGW 具有統治地位。對於多帳戶或全組織環境，配合 AWS RAM 使用 TGW 是唯一實際的選擇 — 對等連接在營運上根本無法擴展開來。

何時混用

常見模式：以 TGW 作為樞紐，並在流量極高的一對 VPC 之間建立直接的 VPC 對等連接。例如，一個資料庫 VPC 和一個分析 VPC 之間每個月傳輸數百 TB 的資料，它們會直接對等連接以繞過 TGW 的每 GB 處理費，而組織的其他部分則透過 TGW 連接。考試可能會將此編寫為成本優化問題。

閘道端點與 PrivateLink：免費路徑

閘道端點 — 僅限 S3 和 DynamoDB

閘道端點是免費的 — 無小時費，無每 GB 處理費。在每個使用 S3 或 DynamoDB 的 VPC 中都應該添加它們。該端點是一個指向受管字首清單 (Managed prefix list) 的路由表項目，攔截流向服務公有 IP 範圍的流量，並透過 AWS 骨幹網路路由。無 ENI，無安全性群組，無 DNS 覆蓋。

對於讀寫大量 S3 資料的工作負載 (讀取資料集進行 ML 訓練、日誌歸檔、備份)，閘道端點每月可節省數百至數千美元的 NAT 處理費。

介面端點 (PrivateLink) 經濟學

介面端點按 每個 AZ 的 ENI 每小時 收費 ($0.01/小時) 加上 處理的每 GB 資料費用 ($0.01/GB)。對於一個 3-AZ 部署、一個指向 KMS 的介面端點，每月費用約為 $22 外加每 GB 處理費。

經濟上的甜蜜點：當呼叫 AWS 服務的每 GB 流量高到足以攤銷每個 AZ 的 ENI 小時費時，介面端點就比 NAT GW 更便宜。對於每個月進行數百萬次 KMS 呼叫的工作負載，介面端點物超所值；對於每天只進行幾次 KMS 呼叫的工作負載，NAT 就足夠了。

對於 SCS-C02 風格的「資料周邊 (Data perimeter)」架構，無論成本如何，介面端點都是強制性的 — 它們提供了周邊的網路層強制執行。ANS-C01 的成本問題假設先滿足安全性要求，然後再進行優化。

集中式介面端點模式

對於擁有數百個 VPC 的組織，在每個 VPC 中重複部署介面端點代價高昂。集中式端點模式：在一個共用服務 VPC 中部署介面端點，並使用 Route 53 Resolver (配合條件轉發規則) 將針對這些 AWS 服務的 VPC 私有 DNS 查詢導向中央端點。支點 VPC 透過 TGW 路由到達中央端點。成本：一組端點費用由多個 VPC 攤銷；代價：呼叫 AWS 服務時產生的跨 VPC TGW 費用。

利用 CloudFront 降低傳出成本

Amazon CloudFront 是 AWS 的內容分發網路 (CDN)，在全界各地設有邊緣節點。其效能優勢 (降低終端使用者延遲) 廣為人知；而其成本優勢同樣重要且受 ANS-C01 測試。

CloudFront 如何降低傳出成本

CloudFront 有其獨立的每 GB 傳出定價，在所有用量階梯下都低於直接從 EC2/S3 傳出，並提供區域用量折扣，大規模下可累積成可觀的節省。對於可快取的內容 (靜態內容、影片、軟體下載)，CloudFront 可以從邊緣快取提供服務，而無需觸及源伺服器 — 這意味著針對快取命中部分的源伺服器傳出成本為零。即便對於不可快取的流量，透過 CloudFront 傳出的費率也低於直接傳出。

源伺服器保護與定價模式

當 CloudFront 作為 S3 的前端時，配置 源存取控制 (Origin Access Control, OAC) 使 S3 儲存貯體保持私有，僅允許 CloudFront 讀取。這可以：(a) 加強安全性，(b) 確保所有傳出都走 CloudFront 較低的定價，以及 (c) 防止繞過機制產生直接的 S3 傳出費用。

對於以 ALB 為前端的動態內容，CloudFront 仍然可以透過邊緣的 TLS 終止 (卸載 ALB 負擔) 以及回傳給使用者時較低的傳出費率層級提供幫助。

何時 CloudFront 不是解決方案

當滿足以下條件時，CloudFront 具備經濟意義：(a) 回應是可快取的，(b) 使用者群體地理位置分散 (延遲優勢有意義)，或 (c) 傳出量大到足以觸發階梯折扣。對於每天只服務一個區域內幾千個請求的低流量內部 API，CloudFront 的開銷並不合理。

CloudFront 不支援 UDP 源伺服器或非 HTTP 協定。對於 UDP/TCP 非 HTTP 工作負載 (遊戲、VoIP、金融交易)，Global Accelerator 是對應的選擇 — 提供 Anycast 靜態 IP、流量分配以及低延遲路由，但不具備快取功能。

CloudWatch 指標、警示與營運模式

值得設定警示的網路指標

• NAT 閘道 — ErrorPortAllocation > 0 (SNAT 耗盡)、BytesOutToDestination 持續激增 (成本激增預警)、IdleTimeoutCount (連線集區大小調整)。
• Transit Gateway — PacketDropCountBlackhole > 0 (發生意圖外的丟包 = 配置錯誤)、BytesIn / BytesOut 激增 (成本警示)。
• Direct Connect — ConnectionState = 0 (鏈路中斷)、ConnectionLightLevelTx / Rx 超出額定範圍 (物理層預警)。
• VPN 連線 — TunnelState = 0 (通道中斷)、TunnelDataIn / Out 用於驗證主動/主動負載平衡。
• Application Load Balancer — HTTPCode_Target_5XX_Count、UnHealthyHostCount、TargetResponseTime p99。
• VPC Flow Logs — 基於 REJECT 計數、按 CIDR 劃分的主要位元組消耗者的衍生指標篩選條件。

成本激增警示模式

針對 AWS/Billing 命名空間的 CloudWatch 帳單警示可以針對整體帳戶或單項服務支出超過閾值發出警示。對於特定網路支出，具備每日粒度的 AWS Cost Explorer 以及「成本異常偵測 (Cost Anomaly Detection)」更為精細。可採取行動的指標：NAT 閘道處理位元組數週同比翻倍，通常是導致帳單飆升的架構變更的訊號。

透過 Network Manager 獲得網路洞察

對於 TGW 部署，TGW Network Manager 彙總了多個 TGW 的指標，並將其作為註冊「全球網路 (Global Network)」的 CloudWatch 指標呈現。針對每個連接的 BytesProcessed 設定警示可以標記出行為異常的支點。

利用 Route 53 進行藍綠 DNS 遷移

規範化的網域 3.3 技能：Route 53 加權路由 用於流量遷移。模式：將工作負載的新版本部署到新的 ALB 或執行個體集；建立具有加權路由的 Route 53 記錄 — 95% 指向舊版，5% 指向新版；在監控指標的同時，在數小時或數天內逐漸調整權重；在 100% 流量都在新版後完成遷移，並停用舊版。

加權路由經濟學

Route 53 按查詢次數收費 (前 10 億次查詢約每百萬次 $0.40)。對於大多數應用程式而言，這可以忽略不計。健康檢查 (HTTPS 每個健康檢查每月約 $0.50) 會增加費用，但對於容錯移轉路由是必要的。

用於高可用性的容錯移轉路由

主要記錄指向主站點；次要記錄指向待命站點。主要記錄上的健康檢查決定路由 — 如果主要站點故障，查詢將返回次要站點。適用於主從式災難復原；對於主主式，使用帶有健康檢查的加權記錄。

用於地理優化的延遲路由

Route 53 延遲策略會根據使用者解析器的測量值，將每位使用者引導至延遲最低的 AWS 區域。在不更改應用程式的情況下縮短回應時間；對於全球使用者群體特別有用。延遲路由自然地與區域 ALB/NLB 搭配。

子網路優化與 IP 枯竭

常見的任務 3.3 技能：更新和優化子網路以防止 VPC 內可用 IP 地址耗盡，並支援透過自動調整規模增加的應用程式負載。

偵測 IP 枯竭

CloudWatch 不會直接針對子網路 IP 枯竭發出警示，但透過排程呼叫 EC2 API 並發佈 AvailableIpAddressCount 的自訂指標，可以針對關鍵子網路的剩餘 IP 設定警示。帶有「InsufficientFreeAddressesInSubnet」錯誤的自動調整規模失敗是顯而易見的症狀 — 但到那時，擴展已經失效了。

緩解措施

• 為 VPC 添加次要 CIDR 區塊。AWS 支援每個 VPC 最多 5 個 CIDR (可調高)。添加一個不重疊的範圍並在其中建立新子網路。現有子網路保持不變；新工作負載進入新子網路。
• 使用 RFC 6598 (100.64.0.0/10) 作為共用地址空間 — 當全組織的 RFC 1918 (10/8, 172.16/12, 192.168/16) 空間都枯竭時非常有用。RFC 6598 預留給 CGNAT，但在私有 VPC 內使用技術上不會產生衝突。
• 更大的子網路 — 在可行時將 /24 (256 個 IP) 重構為 /22 (1024 個 IP)；這需要遷移，因為 AWS 不支援就地調整子網路大小。
• 針對 IPv6 的字首委派 (Prefix delegation) — 為 ENI 分配 /80 而非個別 IPv6 地址；支援極大規模擴展。
• 將無狀態工作負載移至受管服務，由服務內部處理 IP — 如 Fargate、Lambda — 從而降低每副本的 IP 消耗率。

IP 規劃模式

對於大規模的新 VPC，規劃 CIDR 時應預留 5 倍的成長空間。例如，將 10.x.0.0/16 (6.5 萬個地址) 劃分為每個 AZ /20 的區段 (每個 4 千個)，可提供數年的成長空間。對於使用 VPC CNI (如 Cilium, Calico-with-VPC-IPAM) 的高密度 EKS 叢集，應預先分配次要 CIDR。

常見陷阱總結 — ANS-C01 網路成本

考試在成本優化方面最常編寫的陷阱。

陷阱 1：VPC 對等連接總是免費的

錯。對等連接本身是免費的；區域間對等連接資料傳輸費用為 $0.02/GB，且同區域透過對等連接的跨 AZ 流量仍需支付每個方向 $0.01/GB。只有透過私有 IP 進行的 AZ 內對等流量是免費的。

陷阱 2：NAT 閘道是唯一的外出選項

錯。許多工作負載可以利用閘道端點 (S3/DynamoDB) 和介面端點 (其他 AWS 服務) 來取代 NAT GW，從而消除大部分或全部 NAT 處理費。

陷阱 3：透過 NAT GW 的跨 AZ 流量只收一次費

錯。跨 AZ 到 NAT GW 的費用 + NAT 處理費 = 雙重收費。解決方案是按 AZ 部署 NAT GW。

陷阱 4：Transit Gateway 總是比對等連接貴

錯。對於超過約 5 個 VPC 的情況，TGW 在營運上，且通常在經濟上都更好。大規模的全網狀對等連接具有隱藏的營運成本。

陷阱 5：CloudFront 僅對靜態內容有幫助

錯。CloudFront 也能透過較低的每 GB 定價和 TLS 終止卸載，降低動態內容的傳出成本，即便快取命中率很低。

陷阱 6：介面端點總是比 NAT 便宜

錯。介面端點有按每個 AZ ENI 計算的小時費。對於低用量的 AWS 服務使用，NAT 更便宜。損益平衡點大約是每服務每 AZ 每月 155 GB。

陷阱 7：AvailableIpAddressCount 會自動發出警示

錯。CloudWatch 原生不提供每個子網路的 IP 可用性指標；你必須透過 Lambda/EventBridge 發佈自訂指標，或者依賴自動調整規模失敗作為滯後指標。

陷阱 8：添加次要 CIDR 會調整現有子網路的大小

錯。次要 CIDR 會建立新的 IP 範圍；現有子網路不受影響。新工作負載必須放置在次要 CIDR 中建立的新子網路。

陷阱 9：VPC 對等連接支援遞移路由

錯。硬性限制；A-B 和 B-C 並不代表 A-C。請使用 TGW 來實現遞移路由。

陷阱 10：Route 53 健康檢查隨託管區域免費提供

錯。健康檢查是單獨計費的 (HTTPS 每個檢查每月約 $0.50，延遲測量和字串匹配等進階功能則更高)。

陷阱 11：透過 Direct Connect 傳出的區域間流量是免費的

錯。Direct Connect 資料傳輸是收費的 (低於網際網路傳出，但並非免費)。跨越 AWS 區域在 Direct Connect Gateway 上的區域間流量有其專門定價。

陷阱 12：多個 NAT 閘道總是比一個大的貴

錯。AWS NAT GW 沒有「大小」之分 — 頻寬會自動擴展到 100 Gbps。多個 NAT GW 在每 GB 處理費上不會更貴；無論有多少個閘道，每 GB 的費用都一樣。小時費會翻倍，但節省下來的跨 AZ 費用通常會超過這一點。

決策矩陣 — ANS-C01 每個目標對應的成本組件

FAQ — 網路監控、疑難排解與成本優化

Q1：我的 NAT 閘道帳單這個月翻倍了 — 診斷程序是什麼？

步驟如下：(1) 識別激增點 — 打開 Cost Explorer，篩選「Service: EC2-Other」、「Usage Type: NatGateway-Bytes」和「NatGateway-Hours」。Bytes 行就是按 GB 計費的處理費 — 這就是翻倍的地方。(2) 尋找來源 — 在 NAT GW ENI 上查詢過去 30 天的 VPC 流程日誌，按 pkt-srcaddr (NAT 之前的原始執行個體 IP) 分組，按總位元組數排序。最大的消費者就是罪魁禍首。(3) 目的地分類 — 檢查前幾名流量的 dstaddr。如果目的地是 AWS 服務的 IP 範圍 (S3, DynamoDB 等)，答案是添加閘道端點或介面端點。如果目的地是公有網際網路 (第三方 API、套件鏡像、容器註冊表)，檢查該用量是合法的還是失控了 (例如一個拼命呼叫 API 的異常排程任務)。(4) 檢查跨 AZ 放大效應 — 如果 AZ-2 的私有子網路導向 AZ-1 的 NAT GW，每個位元組都在支付跨 AZ 費用和 NAT 處理費。應按 AZ 部署 NAT GW 並配合在地路由。(5) 驗證修復 — 部署端點或按 AZ 配置 NAT 後，監控每個 NAT GW 的 BytesOutToDestination 幾天；對於典型以 AWS 為主的工作負載，預計會減少 50–80%。

Q2：何時 Transit Gateway 在成本上優於 VPC 對等連接，反之亦然？

對於單純的同區域內部 VPC 流量，VPC 對等連接總是更便宜，因為它沒有小時費和每 GB 處理費 — 你只需支付標準的跨 AZ 資料傳輸費。TGW 則增加了約 $0.05/小時的連接費 (每個 VPC $36/月) 加上 $0.02/GB 處理費。因此對於 2 到 4 個 VPC，對等連接便宜得多。損益平衡點隨規模移動：一個 10 個 VPC 的 TGW 僅連接費每個月就約 $365，但等效的 10 個 VPC 全網狀連接 則需要維護 45 個對等連接，每次變更都要更新路由表，在營運上難以維持。對於全組織的多帳戶多區域環境，TGW 是唯一實際的選擇 — 對等連接根本無法擴展。成本最優的混用模式：以 TGW 作為一般連線的樞紐，並針對高流量的一對 VPC 建立直接的 VPC 對等連接，以繞過這些流量的 TGW 每 GB 處理費 (例如，承載每個月數 TB 流量的資料庫 VPC 到分析 VPC 的對等連接，而組織的其他部分則使用 TGW)。

Q3：如何架構 Lambda 傳出到 AWS 服務而不支付 NAT 費用？

將 Lambda 放在 VPC 中，給予私有子網路，並使用 VPC 端點。 針對 Lambda 呼叫的每個 AWS 服務 (Secrets Manager, STS, KMS, Systems Manager Parameter Store, 透過閘道端點的 S3, 透過閘道端點的 DynamoDB)，在該函數的 VPC 中布建對應的端點。Lambda 透過端點的傳出路徑完全不涉及 NAT，也無 NAT 處理費；只需支付每 GB 的端點處理費 (S3/DynamoDB 的閘道端點則為零)。對於同時需要呼叫非 AWS 網際網路端點 (第三方 API) 的 Lambda，添加一個嚴格限縮範圍的 NAT 閘道 — 但端點模式會大幅降低總 NAT 流量。ANS-C01 期望在任何「Lambda 在 VPC 中且具備成本最優傳出路徑」的問題中看到這種模式。當 Lambda 只 呼叫 AWS 服務時的變體：完全不需要 NAT，只需端點 — 該函數的子網路是純私有的，無網際網路路由，網路成本最低。

Q4：我應該在網路基礎設施上設定哪些 CloudWatch 警示？

不可協商的組合：(1) NAT GW ErrorPortAllocation > 0 — SNAT 連接埠耗盡是最常見的 NAT 故障模式，會立即影響生產。(2) NAT GW BytesOutToDestination 週同比警示 — 在帳單寄達前對成本激增發出預警。(3) Direct Connect ConnectionState = 0 — 鏈路中斷是等級最高的混合雲事件。(4) VPN 通道 TunnelState = 0 — 任何 VPN 的兩條通道中有一條中斷。(5) TGW PacketDropCountBlackhole > 0 — 意圖內的丟包是設計使然，但高發生率預示著路由配置錯誤或新支點衝突。(6) TGW PacketDropCountNoRoute > 0 — 封包到達但沒有匹配路由，預示著路由傳播缺失。(7) ALB HTTPCode_Target_5XX_Count 和 UnHealthyHostCount — 後端健康狀況。(8) 針對來自組織 CIDR 以外的 REJECT 計數的 VPC Flow Logs 指標篩選器 — 可能的掃描或攻擊。(9) 自訂指標：子網路 IP 可用性 < 20% — 預防性 IP 枯竭警告，需要 Lambda + EventBridge 透過 DescribeSubnets 發佈。

Q5：集中式 vs 分散式 VPC 端點模式如何影響成本？

分散式模式 — 每個 VPC 都有自己使用的 AWS 服務的介面端點。成本：每個 VPC 每個服務每個 AZ 的 ENI 小時費 ≈ $7/月/服務/AZ × VPC 數 × AZ 數。對於在 3 個 AZ 中使用 5 個服務的 50 個 VPC：50 × 3 × 5 × $7 = 每月 $5,250 的固定端點費用。優點：簡單，端點呼叫無跨 VPC 流量。集中式模式 — 一個共用服務 VPC 擁有所有的介面端點；支點 VPC 透過 TGW 搭配針對 AWS 服務 DNS 名稱的 Route 53 Resolver 條件轉發來到達它們。成本：1 × 3 × 5 × $7 = 每月 $105 的固定端點費用，外加跨 VPC 流量的 TGW 每 GB 處理費。優點：大規模下固定小時費大幅降低；缺點：TGW 增加了延遲和每 GB 成本，且 DNS 轉發設置具備營運複雜性。損益平衡點：少於約 10 個 VPC 時分散式勝出；多於約 20 個時集中式勝出。ANS-C01 期望你識別出這種權衡，特別是在全組織多帳戶的問題中。

Q6：CloudFront 是否曾是傳出優化的錯誤答案？

是的。當滿足以下條件時，CloudFront 是錯誤的：(a) 工作負載是非 HTTP 的 (UDP, 原始 TCP) — CloudFront 僅處理 HTTP/HTTPS；替代方案是具備 Anycast IP 的 Global Accelerator。(b) 使用者群體在單一區域且資料多為不可快取的動態內容 — 延遲效益微小，且 CloudFront 的每請求費用加上源傳出 (未快取) 在低用量時可能超過直接傳出費用。(c) 合規性或資料在地化規則禁止邊緣快取 — 某些受規管的工作負載不允許在邊緣 PoP 留存副本，必須由源伺服器直接交付。(d) 傳出量太低，無法觸發階梯折扣 — 每天幾 GB 的標準層級傳出節省非常有限。考試中規範化的 CloudFront 案例是全球使用者群體、可快取內容 (靜態資源、圖片、影片)，或任何 OAC + CloudFront 可將 S3 傳出費用轉換為 CloudFront 較低階梯傳出的 S3 源伺服器情境。

Q7：如何在不觸發 IP 枯竭的情況下規劃全組織規模的 VPC CIDR？

分層法。(1) 在 AWS Organizations 層級分配大型超網 (Supernets) — 例如，整個組織使用 10.0.0.0/8，利用 AWS IPAM 劃分為每個帳戶一個 /16。(2) 在每個帳戶內，規劃至少為目前規模 5 倍的 VPC CIDR — 生產環境使用一個 /16 (6.5 萬個 IP)，開發環境使用一個 /20 (4 千個)，並考慮使用 VPC CNI 時的 EKS Pod IP 密度。(3) 在每個 VPC 中預留次要 CIDR 空間 以供未來擴展 — RFC 6598 100.64.0.0/10 被廣泛用於共用服務或經 NAT 轉換的 EKS Pod 範圍，以避免耗盡 RFC 1918 空間。(4) 規劃子網路大小 — 對於自動調整規模的背景工作子網路，使用 /22 (1024 個 IP) 或 /20 (4k) 而非 /24 (256)，為 ASG 提供空間。(5) 針對無狀態工作負載利用 Fargate / Lambda — 它們內部管理 IP，減輕了 VPC 子網路的壓力。(6) 透過自訂 CloudWatch 指標監控可用 IP — 由排程啟動的 Lambda 查詢 DescribeSubnets，發佈每個子網路的 AvailableIpAddressCount，並在低於 20% 時觸發 CloudWatch 警示。ANS-C01 期望這種主動規劃，而非出事後才添加次要 CIDR 的被動反應。

Q8：為什麼 NAT 跨 AZ 陷阱會收這麼多錢？

因為透過 NAT 閘道的每個跨 AZ 位元組都要支付三項費用而非一項。流程：AZ-2 的執行個體發送一個封包到 AZ-1 的 NAT GW。(1) 從 AZ-2 到 AZ-1 的傳出跨 AZ 資料傳輸：$0.01/GB。(2) NAT GW 資料處理費：$0.045/GB。(3) 網際網路傳出：$0.09/GB。加上回應部分：(4) 網際網路傳入：免費。(5) NAT GW 處理回應：同樣的 $0.045/GB。(6) 從 AZ-1 到 AZ-2 的傳回跨 AZ 資料傳輸：$0.01/GB。總計：來回每 GB $0.20。如果按 AZ 部署 NAT (AZ-2 的執行個體使用 AZ-2 內的 NAT GW)，跨 AZ 步驟就消失了：只需支付兩次 NAT 處理費 ($0.09/GB) 加上網際網路傳出 ($0.09/GB) = 來回每 GB $0.18。節省：$0.02/GB。每個月傳輸 1 TB 可省下 $20 — 100 TB 則省下 $2,000。隨著工作負載增長，節省的金額會急劇增加，這就是為什麼 ANS-C01 強調按 AZ 部署 NAT 是規範化答案。

Q9：多 AZ NAT 閘道架構的正確營運指標是什麼？

針對每個 NAT GW 的警示：ErrorPortAllocation > 0 (SNAT 耗盡需立即修復)、IdleTimeoutCount 基準趨勢 (連線集區大小調整)、帶有異常偵測的 BytesOutToDestination p95 基準 (成本預警)、持續的 PacketsDropCount > 0 (容量或後端問題)。跨 NAT 比較：AZ 之間的位元組比例應追蹤你工作負載的 AZ 分佈 — 如果 AZ-2 的 NAT GW 處理量是 AZ-3 的 10 倍，儘管兩者的自動調整規模群組大小相同，那肯定有問題 (通常是 VPC 路由表配置錯誤，將所有流量都導向了 AZ-2)。NAT GW ENI 上的 VPC 流程日誌透過 pkt-srcaddr 提供按執行個體的歸因。將所有 NAT GW 指標彙總到一個視圖的 CloudWatch 儀表板，外加按 NAT GW 用量類型篩選的 Cost Explorer 每月匯出，能提供完整視圖。ANS-C01 期望你將 NAT 閘道視為關鍵基礎設施組件，而非被動的公用程式。

Q10：如何優化多區域主主式 (Active-Active) 應用程式的成本？

三個槓桿，按優先級排序。(1) 最小化區域間流量 — 為各區域當地資料和副本設計架構；盡可能避免跨區域資料庫查詢。DynamoDB 全球資料表和 S3 跨區域複寫 (CRR) 是 AWS 受管的複寫基元，能最小化區域間位元組傳輸 (複寫僅限差異部分，且為最終一致性)。(2) 使用 Route 53 延遲路由 將使用者導向最近的區域，縮短傳出路徑長度並利用當地資源。在區域 ALB 前面部署 CloudFront 可進一步在邊緣層級卸載傳出。(3) 針對高流量混合雲流量使用 Direct Connect Gateway，否則流量會以 $0.09/GB 走網際網路；一旦攤銷了連接埠小時費，DX 在大規模下明顯更便宜。對於區域間複寫本身，區域間的 TGW 對等連接 或 區域間 VPC 對等連接 是每 GB $0.02 的 AWS 內部路徑。(4) 快取層 — 區域性的 ElastiCache、邊緣的 CloudFront — 可減少跨區域的重複擷取。ANS-C01 將此框架化為「設計一個在滿足 RTO/RPO 的同時最小化資料傳輸成本的多區域架構」 — 答案結合了這四個槓桿與情境強調的具體服務。

進階閱讀與相關營運模式

• NAT 閘道
• Amazon VPC 定價
• AWS Transit Gateway 定價
• CloudWatch 指標
• 閘道端點
• CloudFront 使用案例
• Route 53 路由策略
• 配置子網路
• AWS ANS-C01 考試指南

理解成本優化後，ANS-C01 自然的下一個營運層級是：用於透過流量歸因診斷成本激增的 VPC 流程日誌與 Reachability Analyzer；追求每美元最大吞吐量的 ENA/EFA/巨型框架網路效能；包含 BGP 路由限制、Direct Connect 容錯移轉以及 PrivateLink 維護在內的混合連線維護；以及將一切連繫在一起的中央織網 Transit Gateway 路由與連接。

• VPC 流程日誌、Reachability Analyzer 與流量鏡像 — ANS-C01 學習筆記
• 網路效能 — ENA、EFA、巨型框架 — ANS-C01 學習筆記
• 混合連線維護 — BGP 限制與路由管理 — ANS-C01 學習筆記
• Transit Gateway — 路由表、連接與 Connect — ANS-C01 學習筆記