成本最佳化網路架構

什麼是 AWS 上的成本最佳化網路

AWS 上的成本最佳化網路是一種以 VPC 為核心的架構，刻意將每張 AWS 帳單上反覆出現的四項網路費用降到最低：對外 data transfer（DTO）、NAT Gateway 處理費、跨可用區流量，以及跨 Region 複製費。與計算或儲存資源不同——後者通常能透過調整單一資源規格來省錢——成本最佳化網路設計的省錢方式是重塑封包在各服務之間的流動路徑。SAA-C03 考試要求你找出費用高昂的流量路徑，以免費或更便宜的替代方案取代，並從費用與架構限制兩個角度說明決策理由。

成本最佳化網路領域位於 SAA-C03 Task 4.4（「設計成本最佳化網路架構」）之中。它在佔比 20% 的 Domain 4 裡具有相當的題目份量，也最常以情境題形式出現，且正確答案往往出人意料。舉例而言，在 S3 儲存桶前面加一個 VPC Gateway Endpoint，從任何可量測的角度來看都不會提升效能——但它能消除 S3 流量的 NAT Gateway 處理費，而對於資料量龐大的工作負載而言，這筆費用往往是帳單的最大宗。SAA-C03 上的成本最佳化網路答案，幾乎都是從封包路徑中移除一個計費節點，而不是新增一項功能。

本主題將引導你逐一理解各項成本最佳化網路決策：解讀 AWS 的 data transfer 費用地圖、以 VPC endpoints 取代 NAT Gateway 流量、用 CloudFront 集中收攏來源 egress、在規模擴大時於 VPC Peering 與 Transit Gateway 之間做選擇、權衡 Direct Connect 與 Site-to-Site VPN，以及在跨帳號流量可能離開再進入 AWS 的情況下選用 PrivateLink 而非公開端點。讀完之後，你應能讀懂任何 SAA-C03 情境，找出最昂貴的流量路徑，並用一句話提出成本最佳化網路的改造方向。

白話文解釋 Cost-Optimized Network

在我們投身定價表之前，先用日常比喻來建立對成本最佳化網路的直覺。以下三個類比——便當店、電力公司、捷運系統——各自揭示 AWS 網路定價的不同面向，並會在本章中反覆出現。

類比一：便當店（Data Transfer 的方向與距離）

把 AWS data transfer 想像成一家有外送規則的便當店。送入免費：任何人寄給你的包裹、明信片，乃至一整卡車的貨物送進 AWS Region，AWS 都不收你一毛錢。送出要錢：你每寄出一個便當就要貼郵票，距離越遠、郵票越貴——同一棟樓（同 AZ，免費）不用錢，送到隔壁社區（同 Region 跨可用區，每 GB 幾分美元來回各計一次）要一點錢，送到外縣市（跨 Region）更貴，而快遞到網際網路上的顧客（DTO）是最貴的郵票。成本最佳化網路就是讓盡可能多的便當在同一棟樓內交付（同 AZ），非得送到外面時，改走批量折扣的物流平台（CloudFront），而不是在門市一件一件貼郵票。

類比二：電力公司（NAT Gateway 是計費的轉換器）

想像你的私有子網路是日本家庭（100V），而網際網路是台灣（110V）。你需要一個電壓轉換器才能和外面的電器溝通——那個轉換器就是 NAT Gateway。轉換器以兩種方式收費：一是插著就算的每小時固定費，二是每通過一度電就算的流量費。如果你家所有電器都只和外面的電器溝通，就必須使用轉換器。但如果某些電器只和同棟樓裡的其他台灣電器溝通（例如，透過 Gateway Endpoints 使用 S3 和 DynamoDB），就能完全繞過轉換器，兩種費用都省下來。成本最佳化網路就是有系統地找出所有不需要跨境的對話，將它們改走免費的內部線路。

類比三：捷運站 vs 私人通道（Transit Gateway vs VPC Peering）

假設你在一個企業園區擁有十棟相鄰的大樓（VPC）。你可以在每兩棟之間拉一條私人通道——這就是 VPC Peering：在同 Region 內每 GB 免費，但十棟樓需要 45 條通道，每條通道都是點對點、非轉遞的，維護起來是場噩夢。或者，你可以蓋一座中央捷運站（Transit Gateway），每棟樓只需一個出入口：每棟樓支付一筆小額的月租費，每位乘客搭車需要付每 GB 的票價。若只有兩棟樓且流量龐大，私人通道在費用上勝出。若有十棟樓且流量分散——或者任何流量必須通過中央防火牆審查——捷運站在總擁有成本上勝出，因為你不再需要負擔 45 條通道的維護開銷。成本最佳化網路設計根據 VPC 數量、流量大小，以及是否需要轉遞路由來做選擇，而不是憑感覺判斷哪個「看起來」比較便宜。

帶著便當店、電力公司、捷運站這三個類比，本章其餘內容就變成一道練習題：判斷哪個 SAA-C03 情境適用哪個類比。

AWS Data Transfer 費用地圖——先背這張表

每一項成本最佳化網路決策都從一個事實出發：AWS 對資料的移動收費，而非對資料的抵達收費。從網際網路流入 AWS 的 inbound（IN）流量，在幾乎所有情況下都是免費的。流出（OUT）流量以及跨越特定邊界的內部流量才會計費。如果你能內化以下這把費用階梯，就能憑直覺答對約一半的成本最佳化網路題目。

六階費用階梯（從最便宜到最貴）

1. 同一可用區內，使用私有 IPv4 位址：免費。同 AZ 的兩台 EC2 透過私有 10.x.x.x 位址通訊，完全不付費。
2. 從網際網路流入 AWS 的 inbound 流量：免費。上傳到 S3、打到 ALB 的 API 呼叫、送進 API Gateway 的用戶端請求——沒有 ingress 費用。
3. 同 Region 內跨可用區：來回各計一次 per-GB 費用（撰文時約每 GB $0.01，從來源 AZ 出去 $0.01，進入目的 AZ 再 $0.01——請查詢你所在 Region 目前的 Amazon EC2 定價頁面）。這是許多成本最佳化網路帳單上的隱形殺手。
4. 同 Region 內的 VPC Peering：費率與跨可用區相同——Peering 本身免費，但跨可用區通過 Peer 的流量仍以跨可用區費率計算。
5. 跨 Region 的資料傳輸：每 GB 費用顯著更高，確切費率依來源與目的 Region 而異。從 us-east-1 複製到 eu-west-1 的費用，遠高於在 us-east-1 內部跨可用區的費用。
6. 對外 Data Transfer（DTO）至網際網路：最貴的標準層，採量級定價（每月第一 GB 全球免費；超過 10 TB、50 TB、150 TB 後，每 GB 單價依序遞減）。

哪些是免費的——哪些仍然會咬你

流量通過 **Internet Gateway（IGW）**本身免費；只有流過它的 DTO 位元組才計費。VPC Peering 附件免費；只有它承載的資料才計費。Elastic IP 附加在運行中的執行個體時免費，未附加時每小時收費——這是常見的成本最佳化網路滲漏點。最關鍵的是：同 Region 內 EC2 執行個體透過 S3 公開端點存取 S3 儲存桶的流量不算 DTO，但若該流量必須通過 NAT Gateway，仍會按每 GB 產生 NAT Gateway 處理費。這個細節就是 VPC Gateway Endpoints 存在的主要理由。

跨可用區是隱形殺手

許多工程師知道 DTO 很貴，卻忘了跨可用區流量來回各計一次費用。若你的 Application Load Balancer 在 AZ-a，而 EC2 目標在 AZ-b，一來一回就要付 AZ-a 出去的跨可用區 egress 費加上 AZ-b 出去的跨可用區 egress 費。對於每次用戶請求就產生十次服務間呼叫的聊天式微服務架構而言，跨可用區費用可能與實際的計算費用不相上下。成本最佳化網路會在韌性允許的前提下，將緊密耦合的服務釘在同一可用區，或使用 ALB 跨可用區負載平衡控制與 EKS topology-aware routing 等功能優先路由到同 AZ 的目標。

NAT Gateway 費用及其替代方案

NAT Gateway 是許多 VPC 帳單上每 GB 費用最高的單一項目，因為它同時結合了每小時費用與對每個方向每個位元組都收取的 per-GB 資料處理費。以典型公開定價計算，NAT Gateway 約收 $0.045/小時加 $0.045/GB 處理費（各 Region 費率不同，請查詢目前的 VPC 定價頁面）。若一個工作負載每月透過 NAT 傳輸 10 TB 資料——例如，一批私有子網路的 EC2 執行個體下載容器映像、OS 補丁、S3 物件或第三方 API——光是 NAT Gateway 的資料處理費就可能超過每月每個 NAT Gateway $450，還不包括各可用區的每小時費用。

每 AZ 部署 vs 共用 NAT Gateway 的取捨

由於 NAT Gateway 是區域性（zonal）服務，高可用部署方式是每個可用區部署一個 NAT Gateway，並將每個私有子網路路由到自己所在 AZ 的 NAT Gateway。這是正式環境的建議模式。更便宜的替代方案是在一個 AZ 部署單一共用 NAT Gateway，並將所有 AZ 的所有私有子網路都路由到它。共用模式在三 AZ 部署中可節省約三分之二的每小時 NAT Gateway 費用，但有兩個缺點：（1）其他兩個 AZ 的私有子網路流往共用 NAT Gateway 時會產生跨可用區費用，往往抵消了節省的費用；（2）若共用 NAT Gateway 所在 AZ 故障，整個 VPC 的所有對外網際網路流量都會中斷，直到重新部署為止。大多數 SAA-C03 成本最佳化網路答案偏好每 AZ 部署 NAT Gateway，因為一旦流量有一定規模，NAT 流量的跨可用區費用就會超過節省的每小時費用。

VPC Gateway Endpoints——S3 與 DynamoDB 的免費替代方案

VPC Gateway Endpoint 是一條路由表條目，將一個前綴清單（例如，Region 內的 S3 IP 段）指向你 VPC 內部的一個虛擬端點。流往 S3 或 DynamoDB 的流量走這條路由，完全不會碰到 NAT Gateway。關鍵在於，VPC Gateway Endpoints 完全免費——沒有每小時費用，沒有 per-GB 費用。它們只支援兩項服務：Amazon S3 與 Amazon DynamoDB。若你的成本最佳化網路需要大量存取 S3 或 DynamoDB，加入 Gateway Endpoints 是單一改動中槓桿效益最高的一步。

VPC Interface Endpoints（PrivateLink）——有費用但仍有成本最佳化效益

對於 S3 和 DynamoDB 以外的所有 AWS 服務，從 VPC 進行私有存取需要使用 VPC Interface Endpoint，由 AWS PrivateLink 提供支援。Interface Endpoint 在你啟用的每個子網路中佈建一個 ENI，並透過私有 DNS 將 AWS 服務解析到私有 IP。Interface Endpoints 不是免費的：你大約每個端點每個可用區每小時付 $0.01，再加上約 $0.01/GB 的處理費（確切費率依 Region 而異）。那麼，這比 NAT 還省嗎？

試算看看：NAT Gateway 約收 $0.045/小時 + $0.045/GB。三個 AZ 的 Interface Endpoint 約收 3 × $0.01/小時 = $0.03/小時 + $0.01/GB。只要你的工作負載對某項 AWS 服務推送哪怕是適量的流量，Interface Endpoint 更低的 per-GB 費率就會主導費用，而且你同時避免了同一流量的 NAT Gateway 處理費。對於 KMS、Secrets Manager、SSM、SQS、SNS 和 ECR 等服務，每月只要超過幾百 GB 的流量，Interface Endpoints 可靠地勝過 NAT。此外，Interface Endpoint 讓流量保持在 AWS 私有網路上，不產生 DTO 費用；而等效的公開端點呼叫通過 NAT，即便資料從未離開 AWS，仍會產生 NAT 處理費。

NAT Instance——罕見的成本替代方案

在 NAT Gateway 變得便宜且可擴展之前，架構師會架設 NAT Instance——普通的 EC2 執行個體，停用來源/目的地檢查，並用 IPTables 規則轉發流量。NAT Instance 只需支付 EC2 執行個體費用（加上自身的 data transfer 費），不需支付 NAT Gateway 的處理費。對於流量極低、無 HA 需求的小型開發／測試 VPC，一台 t4g.nano NAT Instance 可能比 NAT Gateway 更便宜。在正式環境中，NAT Gateway 的受管韌性、自動擴展至 45 Gbps，以及消除單點故障風險等特性，使其成為預設的成本最佳化網路選擇，儘管有 per-GB 費用。SAA-C03 極少推薦 NAT Instance，除非情境明確說明是非正式環境、費用優先於一切，且流量很低。

CloudFront——成本最佳化網路中最大的 DTO 槓桿

CloudFront 是繼 VPC endpoints 之後第二大的成本最佳化網路槓桿，對於任何面向公開網際網路的工作負載，它通常是最大的槓桿。核心機制很簡單：每一個 CloudFront 從邊緣快取提供的位元組，就是一個不需要從你的來源作為 DTO 傳出的位元組。對於快取命中率達 80% 的可快取工作負載，CloudFront 將 80% 的 DTO 費用從你的來源移走，以 CloudFront DTO 取而代之——後者對大多數目的地而言，每 GB 費用低於區域性 DTO，且符合承諾用量折扣和 Free Tier 資格。

CloudFront Egress 定價優於區域性 DTO

CloudFront 的 DTO 定價依價格等級（目的地大洲）和每月流量分層計算。對於大多數目的地，CloudFront 的每 GB 費率低於從 S3 或 EC2 直接對外的等效區域性 DTO 費率。CloudFront 也包含永久 Free Tier，自 2021 年底起每月提供 1 TB 的 DTO，光是這一點就能覆蓋許多小型正式工作負載。在此之上，AWS 提供私有定價承諾（CloudFront Security Savings Bundle 及針對重度用戶的自訂定價），以承諾每月消費換取進一步降低的 per-GB 費率——這是穩定工作負載中強而有力的成本最佳化網路槓桿。

CloudFront Price Classes——關掉昂貴的 Region

CloudFront 從全球 600+ 個邊緣節點分發內容，但每 GB DTO 費率依地區差異顯著——南美洲、澳洲和部分亞洲地區的邊緣節點，每 GB 費用遠高於北美洲和歐洲。CloudFront Price Classes 讓你限制哪些邊緣節點為你的分發服務：

• Price Class All——使用全球所有邊緣節點（效能最佳，費用最高）。
• Price Class 200——排除最昂貴的邊緣節點（南美洲、澳洲、紐西蘭和部分亞洲地區）。
• Price Class 100——只使用最便宜的邊緣節點（僅限北美洲和歐洲）。

若你的受眾集中在北美洲和歐洲，切換到 Price Class 100 可在完全不修改程式碼的情況下消除昂貴的邊緣費率。納入範圍以外地區的用戶仍可取得內容，只是以略高的延遲從最近的納入邊緣節點路由。對於服務特定地區受眾的成本最佳化網路，選擇 Price Class 是一個點擊就能省錢的操作。

Origin Shield——減少跨 Region 來源抓取

CloudFront Origin Shield 在 CloudFront 的區域邊緣快取與你的來源之間插入一個額外的快取層。沒有 Origin Shield 時，每個區域邊緣快取在快取未命中時都可能獨立向你的來源抓取，這意味著一個冷物件可能觸發多次來源請求。啟用 Origin Shield 後，區域邊緣向 Origin Shield 抓取，只有 Origin Shield 向來源抓取——將多個潛在的來源請求收攏為一個。對於來源所在 Region 距離受眾很遠的情況，Origin Shield 既能減少來源 DTO 費用，又能降低來源負載。它以每百萬請求收費，因此在快取未命中的來源抓取費用高昂時（大型檔案、跨 Region 來源或高請求率），能帶來明顯效益。

CloudFront 搭配 S3——成本最佳化網路的經典模式

教科書模式：S3 作為來源，前面放 CloudFront 分發，Origin Access Control 將 S3 鎖定為只接受 CloudFront 讀取。對成本最佳化網路的效益：

1. S3 到 CloudFront 的流量免費（S3 到 CloudFront 的流量不計為 S3 的 DTO）。
2. CloudFront 到用戶的 DTO，每 GB 費用低於直接從 S3 DTO。
3. CloudFront 快取命中完全消除快取物件的 S3 請求費用。
4. Origin Shield 進一步減少所有剩餘的 S3 請求。

對於流量龐大的靜態網站，這個模式與直接從 S3 提供服務相比，可使每月網路費用降低 70%——且無需任何應用程式改動。

VPC Peering vs Transit Gateway——規模下的費用比較

成本最佳化網路必須在 VPC Peering 與 Transit Gateway 之間選擇 VPC 間連線方式，正確答案幾乎完全取決於 VPC 數量與是否需要轉遞路由。

VPC Peering——零固定費用，規模擴大後難以維護

VPC Peering 沒有每小時費用，Peering 本身也不收取超出標準跨可用區或跨 Region 費率的 per-GB 費用。若 VPC-A（位於 AZ-1a）與 VPC-B（位於 AZ-1a）Peer，同 Region 且同 AZ 的流量費用為零。跨可用區通過 Peer 的流量按標準跨可用區費率計費；跨 Region 通過 Peer 的流量按標準跨 Region 費率計費。Peering 是非轉遞的（A↔B 且 B↔C，不代表 A↔C），因此 N 個 VPC 最多需要 N×(N−1)/2 條 Peering 連線。5 個 VPC 需要 10 條，10 個 VPC 需要 45 條。大約超過四到六個 VPC 後，維護這個網狀架構——路由表、重疊 CIDR 檢查、跨帳號 IAM——的運維開銷就會遠超 Peering「免費」所帶來的任何節省。

Transit Gateway——每附件每小時固定費加 per-GB 費

Transit Gateway 以兩種方式收費：每附件每小時費用（每個 VPC、VPN 或 Direct Connect 附件約 $0.05/小時，依 Region 而異）以及流量通過 Transit Gateway 時的 per-GB 資料處理費（約 $0.02/GB）。對於兩個流量龐大的 VPC，Transit Gateway 的費用嚴格高於 VPC Peering，因為 Peering 免費承載資料，而 Transit Gateway 兩樣都收費。對於十個 VPC，Transit Gateway 的固定費用（10 個附件 × $0.05/小時 ≈ $360/月）取代了 45 條 Peering 連線的運維複雜度，並提供轉遞路由、共用服務 VPC 和集中式 egress 等 Peering 無法在任何價位提供的功能。

成本最佳化網路決策原則

• 兩到三個 VPC、穩定的配對、不需要轉遞路由 → VPC Peering（最便宜）。
• 四個或更多 VPC，或有轉遞路由、集中式防火牆檢查、共用服務 VPC 等需求 → Transit Gateway（計入運維成本後最便宜）。
• 跨 Region VPC 連線 → 跨 Region VPC Peering 或 Transit Gateway Peering 均可；per-GB 費率相近，依是否需要轉遞路由來選擇。

透過 Transit Gateway 集中 Egress

一個在規模下強而有力的成本最佳化網路模式：將所有應用程式 VPC 附加到 Transit Gateway，在 Transit Gateway 上放一個共用的 egress VPC（配有自己的 NAT Gateway 或 NAT Gateway 叢集），並將所有對外網際網路流量路由到這個 egress VPC。不再於 N 個 VPC 各自運行 NAT Gateway，只在 egress VPC 運行一組。對於擁有數十個應用程式 VPC 的組織，NAT Gateway 每小時費用的節省非常可觀，但你必須將 egress 流量穿越 Hub 時產生的 Transit Gateway per-GB 處理費納入計算。

Direct Connect vs Site-to-Site VPN——費用取捨

對於混合連線，成本最佳化網路必須在兩個維度上做取捨：固定費用 vs 變動費用，以及建置時間 vs 長期效率。

Site-to-Site VPN 費用結構

Site-to-Site VPN 收取適中的每 VPN 連線每小時費用（約 $0.05/小時，每月約 $36），再加上資料透過 VPN 隧道離開 AWS 時的標準 DTO 費率。VPN 上的 DTO 以網際網路 DTO 費率計算——與其他任何公開網際網路 egress 的定價相同。對於穩定的低流量（例如，每月往本地端不到 1 TB），VPN 每小時費用是主要費用，整體費用保持在低位。流量增加後，網際網路 DTO 費率成為主要費用，因為每個透過 VPN 離開 AWS 的 GB 都像公開網際網路的位元組一樣計費。

Direct Connect 費用結構

Direct Connect 收取兩個獨立費用：依連接埠速度計算的連接埠每小時費用（1 Gbps、10 Gbps、100 Gbps 專用；Hosted Connection 從 50 Mbps 起）以及流量透過 Direct Connect 鏈路離開 AWS 時的折扣 per-GB DTO 費率。Direct Connect 的 DTO 費率通常比等效目的地的網際網路 DTO 便宜 60-80%。因此，雖然 Direct Connect 增加了可觀的固定連接埠費用（依速度不同，每月從數百到數千美元不等），但它大幅降低了每 GB 的邊際成本。

損益平衡分析

成本最佳化網路中 VPN 與 Direct Connect 的損益平衡點大約是：

• 每月對外流量低於約 1-2 TB：VPN 在總費用上勝出。
• 超過約 5-10 TB/月：Direct Connect 在總費用上勝出，且節省金額隨流量線性增長。
• 介於 2 到 5 TB/月之間：取決於 Region、連接埠大小，以及你是否需要非費用方面的效益（穩定延遲、無公開網際網路暴露、合規要求）。

混合模式——以 VPN 作為 Direct Connect 的備援

常見的企業成本最佳化網路設計：以 Direct Connect 作為主要連線（利用其低 per-GB 費率和穩定效能），並配置低成本 Site-to-Site VPN 作為備援，只在 Direct Connect 中斷時承載流量。VPN 的每小時費用相對於所降低的風險而言微不足道，而且由於 VPN 流量只在中斷期間才流動，DTO 溢價幾乎不會發生。

PrivateLink vs 公開端點——隱藏費用比較

當一個 AWS 帳號向另一個 AWS 帳號暴露服務時（例如，SaaS 廠商向客戶提供 API），有兩種傳輸選擇，其費用結構對成本最佳化網路而言差異顯著。

公開端點路徑

消費者呼叫提供者的公開 DNS 名稱。封包離開消費者的 VPC，通過 NAT Gateway（或有公開 IP 的執行個體通過 IGW），穿越公開網際網路（或同 Region 同網路的 AWS 服務走 AWS 骨幹網路），抵達提供者的公開 ALB 或 API Gateway。消費者端的費用：每 GB NAT Gateway 處理費 + 潛在的 DTO 至網際網路；不過，同 Region 使用公開 DNS 的 AWS 對 AWS 流量不計為 DTO，但仍會產生 NAT 處理費。提供者端的費用：提供者的 ALB 或 API Gateway 將回應傳回消費者時產生的 DTO（回應酬載）。

PrivateLink 路徑

提供者在 NLB 上發布一個 VPC Endpoint Service。消費者建立指向提供者服務的 VPC Interface Endpoint。流量完全在 AWS 私有網路上流動，絕不觸碰 NAT 或公開網際網路。消費者端的費用：每個端點每個可用區的每小時費用 + per-GB 資料處理費（PrivateLink 費率）。提供者端的費用：Endpoint Service 每小時費用（小額）+ 前端的 NLB。

PrivateLink 在成本最佳化網路中勝出的情況

• 消費者端節省每 GB 的 NAT Gateway 處理費。
• 提供者端節省傳回消費者的 DTO——透過 PrivateLink 的回應以 PrivateLink 費率計費，而非 DTO 費率，在規模下便宜得多。
• 對於穩定或高流量的消費者對提供者流量，計入兩端後 PrivateLink 明確更便宜。

公開端點在成本最佳化網路中勝出的情況

• 來自許多消費者的偶發低流量呼叫，其中每 AZ 的 PrivateLink 每小時費用超過少量的 NAT 處理費。
• 必須同時服務非 AWS 客戶的對外暴露服務（此時 PrivateLink 本就不適用）。

減少跨可用區流量的模式

由於跨可用區流量來回各計費且容易在不知不覺中累積，成本最佳化網路包含刻意的模式來在不犧牲韌性的前提下將其最小化。

模式一——在服務層內進行同 AZ 釘選

將緊密耦合的服務（例如，一個應用程式程序和它的快取）部署為各 AZ 一組，而不是跨 AZ 的網狀架構。AZ-a 的應用程式與 AZ-a 的快取溝通，AZ-b 的應用程式與 AZ-b 的快取溝通。若某個 AZ 故障，另一個 AZ 的應用程式加快取繼續服務——韌性在 AZ 層面而非服務層面得以保留。跨可用區費用幾乎降為零，只有在容錯移轉時才會發生。

模式二——拓撲感知負載平衡

ALB 支援區域感知路由，負載平衡器在每個 AZ 的節點優先選擇同 AZ 的目標，才向其他 AZ 溢出。EKS 和 ECS 支援類似的拓撲提示。啟用同 AZ 偏好可保留所有 AZ 的容量，但將常見情況路由到本地，大幅降低跨可用區費用。

模式三——Aurora 和 RDS 讀取端點配置

Aurora 的叢集讀取端點會跨可用區分散。若你的應用程式連接池跨三個可用區，每個應用程式執行個體可能連到不同 AZ 的讀取副本，產生跨可用區的查詢流量。使用各 AZ 的讀取副本執行個體和各 AZ 的自訂端點，讓每個應用程式連接池從本地 AZ 讀取。RDS 讀取副本也適用相同模式。

模式四——S3 Gateway Endpoints 完全消除跨 AZ 問題

連到 S3 的 Gateway Endpoint 讓 S3 流量直接從執行個體路由到 VPC 內的 Gateway Endpoint，同時繞過 NAT 和跨可用區考量。對於以 S3 為主要資料來源的工作負載，Gateway Endpoints 是節省跨可用區和 NAT 費用的最大單一手段。

Route 53 與 DNS 費用最佳化

Route 53 在成本最佳化網路中鮮少是最大的費用項目，但在大型部署中有幾項小費用會累積起來：

• Hosted zone 費用：前 25 個 zone 約 $0.50/月每個 hosted zone。
• 查詢費用：依查詢類型（標準、延遲基礎、地理位置）收取每百萬查詢費用。
• Health checks：每個 health check 每月收費，HTTPS 或字串比對選項另收額外費用。
• Alias 記錄指向 AWS 資源免費——凡目標是 AWS 資源，都應使用 alias 而非 CNAME。

在規模下（每秒數十萬查詢的工作負載），將不必要的延遲基礎或加權策略換成簡單路由，並在可能的地方合併 hosted zone，可產生可量測的節省。更重要的是，Route 53 Resolver 對外端點和 DNS Firewall 都是額外收費的功能——只在必要時使用，而非預設啟用。

流量控管作為費用控制手段

API Gateway 使用計畫、AWS WAF 速率限制規則和 CloudFront 速率限制行為通常不被視為成本最佳化網路工具，但它們在這個角色中非常強大。透過限制每個客戶端的請求數，你同時限制了相關的下游費用：更少的 Lambda 呼叫、更少的 DynamoDB 讀取、更少的來源抓取。對於可能遭受爬取或濫用的成本最佳化網路，在邊緣（流量到達來源之前）配置 WAF 速率限制規則，能將潛在的帳單衝擊風險轉化為可控支出。

Bandwidth 配置——正確調整 Direct Connect 規格

Direct Connect 連接埠有固定大小（專用：1 Gbps、10 Gbps、100 Gbps；Hosted Connection：從 50 Mbps 到 10 Gbps）。成本最佳化網路依尖峰承諾 bandwidth 加上成長空間來調整連接埠規格，而非最大理論吞吐量。為平均只有 2 Gbps 的工作負載過度佈建 100 Gbps 連接埠是在浪費錢。不足佈建則導致封包遺失和重傳，產生另一種費用痛點。

整合所有要素——成本最佳化網路檢查清單

正式環境的成本最佳化網路審查應驗證：

1. 每個 VPC 都已為 S3 和 DynamoDB 部署 VPC Gateway Endpoints。
2. 高流量服務（KMS、Secrets Manager、ECR、SSM、CloudWatch Logs）已在 NAT 流量足以證明其必要性的情況下部署 VPC Interface Endpoints。
3. 正式環境每 AZ 部署 NAT Gateway；只有在流量真正很低時才共用。
4. 每個面向公開網際網路的 S3 儲存桶和 ALB 前方都配置 CloudFront，並搭配 Origin Access Control。
5. CloudFront Price Class 與受眾地理分布一致。
6. 快取未命中代價高昂的來源啟用 Origin Shield。
7. Transit Gateway 只在 VPC 數 ≥ 4 個或需要轉遞路由時使用；否則使用 VPC Peering。
8. Direct Connect 只在每月流量和延遲需求足以證明連接埠費用合理時使用；否則使用 Site-to-Site VPN。
9. 在 AWS 上高流量的跨帳號服務消費使用 PrivateLink。
10. 透過同 AZ 釘選和拓撲感知路由減少跨可用區流量。

並排比較：成本最佳化網路速查表

成本最佳化網路常見考試陷阱

1. Gateway Endpoint 與 Interface Endpoint 混淆——Gateway（免費）= 僅限 S3、DynamoDB；其他所有服務都是 Interface（收費）。
2. Transit Gateway「永遠更便宜」——錯；2-3 個 VPC 時，VPC Peering 更便宜。
3. 跨可用區流量免費——錯；來回各計費。
4. 跨 AZ 共用 NAT Gateway 可省錢——通常是錯的；跨可用區費用會抵消節省。
5. Direct Connect DTO 免費——錯；Direct Connect 提供折扣 DTO，而非免費 DTO。
6. CloudFront 只是效能工具——錯；它也是 DTO 費用工具，且有每月 1 TB 的永久 Free Tier。
7. VPN 和 Direct Connect 永遠是替代關係——在實務中，它們是互補的（VPN 作為 Direct Connect 的備援）。
8. Elastic IP 永遠免費——錯；未附加的 EIP 按每小時收費。
9. PrivateLink 永遠比公開端點便宜——錯，流量極低時並非如此。
10. inbound 資料免費，所以流入永遠免費——對網際網路到 AWS 成立；但跨可用區的「流入」在接收端的可用區仍然計費。

成本最佳化網路 vs 高效能網路——邊界在哪裡

SAA-C03 將網路分散在兩個有時會使用相同服務的任務說明中。**Task 3.4（高效能網路架構）**關心延遲、吞吐量和效能目標的拓撲適配性——CloudFront 作為 CDN、Global Accelerator 作為任播、Direct Connect 追求 bandwidth、Transit Gateway 追求拓撲。**Task 4.4（成本最佳化網路架構）**關心相同封包路徑的費用——CloudFront 作為 DTO 節省工具、Gateway Endpoints 作為 NAT 繞道、VPC Peering 作為小規模的免費網狀架構、Direct Connect 追求更便宜的 per-GB DTO。這些服務相互重疊；但考察框架不同。考試當天，讀懂情境的主要目標句：若說「最低成本」，你在成本最佳化網路的範疇；若說「最低延遲」或「最高吞吐量」，你在高效能網路的範疇；若兩者都說，優先選擇在滿足效能限制的同時費用最低的答案。

FAQ——成本最佳化網路熱門問題

Q1：如何降低大量存取 S3 的 VPC 的 NAT Gateway 費用？

為 VPC 新增 S3 的 VPC Gateway Endpoint，並將其關聯到每個私有子網路的路由表。S3 流量就會完全繞過 NAT Gateway，消除這些位元組的 NAT 處理費。Gateway Endpoints 是免費的——沒有每小時費用，也沒有 per-GB 費用——因此這永遠是淨正向的改動。若 VPC 也存取 DynamoDB，同樣加入 DynamoDB Gateway Endpoint。對於同時以可觀流量消費 ECR、KMS 或 Secrets Manager 等服務的工作負載，評估 Interface Endpoints 是否比其所能取代的 NAT Gateway 處理費更划算。

Q2：VPC Peering 何時比 Transit Gateway 便宜？何時情況反轉？

對於成本最佳化網路，當你的 VPC 數量較少（通常 2-3 個）、Peering 配對穩定、且不需要轉遞路由或集中檢查時，VPC Peering 更便宜。Peering 沒有附件費，也沒有超出標準跨可用區或跨 Region 費率的 per-GB 資料處理費。當你達到約四個或更多 VPC、需要轉遞路由，或想要集中 egress／檢查時，Transit Gateway 就變得更便宜，因為維護 N×(N−1)/2 Peering 網狀架構的運維費用，加上 Hub-and-Spoke 拓撲帶來的能力提升，超過了 Transit Gateway 的每附件每小時費和 per-GB 資料處理費。

Q3：CloudFront 真的比直接從 S3 提供服務更便宜嗎？

對於面向公開網際網路的內容，在幾乎所有情況下答案都是肯定的。CloudFront 的每 GB DTO 費率對等效目的地而言低於 S3 的區域性 DTO 費率，S3 到 CloudFront 的流量不計為 S3 的 DTO，而且 CloudFront 含有每月 1 TB 的永久 Free Tier。此外，快取命中完全消除快取物件的 S3 請求費用。對於只在同一 VPC 或 AWS 帳號內部提供服務的私有工作負載，CloudFront 沒有幫助——但對於可從公開網際網路存取的任何內容，在 S3 前面配置帶有 Origin Access Control 的 CloudFront，是成本最佳化網路的預設做法。

Q4：將本地端資料中心連接到 AWS 的成本最佳化方式是什麼？

這取決於每月的流量大小。對於每月對外流量低於約 1-2 TB 的情況，Site-to-Site VPN 在總費用上勝出——每小時費用低，VPN 流量以網際網路 DTO 費率計費，在低流量時這完全可以接受。對於每月超過約 5-10 TB，Direct Connect 勝出，因為其折扣 per-GB DTO 費率（通常比網際網路 DTO 便宜 60-80%）可在幾 TB 內抵消連接埠每小時費用。在這兩個閾值之間，請針對你的 Region 和目的地進行計算。許多企業採用 Direct Connect 主線加 VPN 備援——正常流量享有 Direct Connect 的低 per-GB 費用，中斷時有 VPN 的低成本待命。

Q5：如何在不破壞高可用性的情況下降低跨可用區 data transfer 費用？

使用拓撲感知路由模式：將緊密耦合的服務（應用程式加快取、應用程式加資料庫讀取副本）部署為各 AZ 一組，並以區域感知路由配置負載平衡器，優先選擇同 AZ 的目標。對於 Aurora 和 RDS 讀取副本叢集，在每個可用區部署讀取副本執行個體並使用各 AZ 端點，讓每個應用程式連接池在本地 AZ 讀取。對於 S3，Gateway Endpoints 完全繞過跨可用區問題。原則是：保留跨 AZ 的容量以應對故障，但讓常見情況路由到本地，讓跨可用區費用只在真正發生容錯移轉時才累積。

Q6：何時應為跨帳號 AWS 服務選擇 PrivateLink 而非公開端點？

當消費者端的 NAT Gateway 處理費加上提供者端的 DTO 費——兩者在使用 PrivateLink 後都會消失——超過 PrivateLink 的每 AZ 每小時費和 per-GB 費時，就選 PrivateLink。對於穩定或高流量的情況，損益平衡點很快就會到來。對於來自許多消費者的低流量消費，或服務必須同時對非 AWS 客戶開放（此時 PrivateLink 本就不適用）的情況，公開端點仍是成本最佳化網路的選擇。一個實用的判斷原則：若你正要為了存取某個特定的 AWS 託管服務而佈建 NAT Gateway，那 PrivateLink 幾乎肯定更便宜。

Q7：在每個 AZ 各部署一個 NAT Gateway，真的比共用一個省錢嗎？

通常是的，一旦你把跨可用區費用納入計算。在一個 3-AZ VPC 中，共用 NAT Gateway 可節省約三分之二的每小時 NAT Gateway 費用，但它對其他兩個 AZ 的私有子網路流往共用 NAT 的每個位元組收取跨可用區費用。這些跨可用區費用通常在月流量超過一個合理閾值後就超過節省的每小時費用，而且共用模式還為所有網際網路 egress 創造了單一可用區故障依賴。對於正式環境的成本最佳化網路設計，請每 AZ 部署 NAT Gateway；只在流量真正很低的非正式環境 VPC（每小時費用佔主導地位）才共用。

延伸閱讀

• AWS VPC 定價頁面（查詢各 Region 目前費率）
• AWS PrivateLink 定價頁面
• CloudFront 定價與 Price Classes 文件
• AWS Transit Gateway 定價頁面
• AWS Direct Connect 定價與連線類型
• AWS Well-Architected Framework — 費用最佳化支柱（網路章節）
• AWS 白皮書：Amazon Web Services 概覽 — 網路與內容傳遞
• AWS 白皮書：建置可擴展且安全的多 VPC AWS 網路基礎架構

掌握這些成本最佳化網路槓桿——data transfer 費用地圖、Gateway 與 Interface Endpoints、CloudFront 搭配 Price Classes 和 Origin Shield、規模下的 Transit Gateway vs VPC Peering、Direct Connect vs VPN 損益平衡、PrivateLink vs 公開端點，以及跨可用區減少模式——SAA-C03 Task 4.4 就會成為穩定得分的領域。考試上每一道成本最佳化網路題，歸根究底都是要你找出計費節點並移除它。持續做到這一點，你的架構在考試結束很久之後仍能控制在預算之內。祝你 SAA-C03 成本最佳化網路題目一切順利。