Amazon SAA-C03: 網路與連線 — 學習指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

屬於 AWS SAA-C03 — 完整學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

VPC 設計與 CIDR 規劃

每個 VPC 都始於一個 CIDR 區塊，而在建立時所做的選擇，會對後續的對等連接 (peering)、Transit Gateway 附件以及混合雲連線產生影響。主要的 CIDR 必須介於 /16 和 /28 之間，並從 RFC 1918 私有位址空間中選擇，且不得與您打算進行對等連接、透過 Transit Gateway 路由，或經由 Direct Connect 或 VPN 連線的任何網路重疊。CIDR 重疊是混合雲設計失敗最常見的單一原因，因為 AWS 無法在共享相同位址空間的兩個網路之間進行路由——Transit Gateway 會接受附件，但路由傳播 (propagation) 會失敗，或無聲地將流量黑洞化 (blackhole)。

當 VPC 的位址空間用盡時，您不需要重建它。最多可以附加四個次要的 IPv4 CIDR 區塊（預設總共可有五個，可透過增加配額從更廣泛的池中取得額外範圍）。次要區塊可以來自相同的 RFC 1918 範圍，或來自 100.64.0.0/10 的共享位址空間，這在 10.0.0.0/8 已耗盡或需要電信級 NAT (carrier-grade NAT) 空間時非常有用。次要 CIDR 讓您可以為擴展需求（例如 EKS pod 網路、新的應用層）切分出新的子網路，而無需對現有工作負載進行重新編號。

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

一個穩健的設計會為未來的增長保留一個 /17 或 /18 的空間，將子網路邊界與可用區域 (Availability Zone) 對齊（每個 AZ 的每一層使用一個 /20 是常見模式），並為介面端點 (interface endpoints)、NAT Gateway 和負載平衡器所消耗的 ENI 預留空間。

VPC 是一個區域性 (regional) 的建構，被分割成多個子網路，每個子網路都綁定到單一的 AZ。「公有」與「私有」的區別純粹是一個路由決策：公有子網路有一條指向 Internet Gateway 的路由 0.0.0.0/0 → igw-xxxx，而私有子網路要嘛沒有預設路由，要嘛將 0.0.0.0/0 指向一個 NAT 設備。公有子網路中的 Instance 也需要一個公有 IP 或 Elastic IP 才能接收傳入的連線；IGW 會在私有 IP 和公有 IP 之間執行 1:1 NAT。

NAT Gateway、NAT Instance 與 IPv6 Egress

對於私有子網路中僅限傳出的 IPv4 網際網路存取，NAT Gateway 是正確的基本元件。託管的 NAT Gateway 會自動擴展至 45–100 Gbps，支援對每個唯一目的地高達 55,000 個同時連線，由 AWS 負責修補，並在其所在的 AZ 內具有高可用性。NAT Gateway 的計費方式是按小時計費，並根據處理的 GB 數收費。

NAT Instance——也就是自行管理的、停用了來源/目的地檢查的 EC2——是一種舊式的作法。它們受限於單一 Instance 的吞吐量，必須透過腳本來實現容錯轉移，並且在持續負載下會成為瓶頸。它們僅適用於非典型需求，如自訂過濾，即便如此，通常使用 Gateway Load Balancer 應用裝置會是更好的選擇。

標準的高可用性模式是每個 AZ 一個 NAT Gateway，各自位於該 AZ 的公有子網路中，並為每個 AZ 設定一個獨立的私有路由表，其預設路由指向本地的 NAT Gateway：

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

部署一個跨 AZ 共享的單一 NAT Gateway 是一個陷阱，原因有二。首先，它是一個單點故障：一個 AZ 的中斷會導致所有私有子網路的傳出流量中斷。其次，來自其他 AZ 的 Instance 的每個封包都會跨越 AZ 邊界，除了 NAT Gateway 的處理費用外，還會產生跨 AZ 資料傳輸費用（目前單向為 $0.01/GB）。在處理數百 TB 傳出流量的工作負載上，這筆費用遠超過額外 NAT Gateway 的成本。第二個常見的錯誤配置是將 NAT Gateway 本身放置在私有子網路中——這樣它就沒有通往 IGW 的路徑，因而無法運作。

對於 IPv6，既不需要也不提供 NAT，因為每個 IPv6 位址都是全域可路由的。若要允許僅限傳出的 IPv6 流量，同時阻擋未經請求的傳入流量，請附加一個僅限傳出網際網路閘道 (egress-only internet gateway)，並將私有子網路的 ::/0 路由指向它。一般的 IGW 是雙向的，會將 Instance 暴露於外。

VPC 端點：閘道 (Gateway) vs. 介面 (Interface)

VPC 端點能將您的 VPC 與 AWS 服務之間的流量保留在 AWS 骨幹網路上，完全避開網際網路、NAT 閘道和網際網路閘道。這有兩種根本上不同的實作方式，混淆這兩者是最常見的架構錯誤之一。

閘道端點 (Gateway endpoints) 僅適用於 Amazon S3 和 DynamoDB。它們是一個路由表項目——一個前綴列表 (prefix list) (例如在 us-east-1 的 S3 是 pl-63a5400a)，其目標指向端點本身。它沒有 ENI、沒有 DNS 變更、沒有小時計費，也沒有安全群組 (存取權限由路由表加上端點政策 (endpoint policy) 控制)。因為它們是基於路由的，所以只對 VPC 內的資源有效——透過 Direct Connect 連接 S3 的地端網路無法使用它們。

介面端點 (Interface endpoints) (AWS PrivateLink) 是放置在您子網路中帶有私有 IP 的 ENI，按可用區 (AZ) 每小時收費，外加每 GB 的費用。它們適用於幾乎所有其他服務——SQS、KMS、Secrets Manager、ECR、STS、SSM、SNS 等數百種服務——以及發佈為端點服務 (endpoint services) 的第三方服務。介面端點支援私有 DNS (private DNS)，它會覆寫公有服務主機名稱，解析到端點的私有 IP，因此 SDK 和 CLI 無需修改程式碼。因為它們由 ENI 支援，所以安全群組適用。

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

成本邏輯很重要：任何離開私有子網路到公有 AWS 服務的流量，預設會通過 NAT 閘道，費用約為 $0.045/GB。對於一個每天推送 1 TB 資料到 S3 的容器化工作負載，NAT 閘道路徑和閘道端點路徑之間的差異，每月可達數千美元。當介面端點大規模取代 NAT 出口流量，或當合規性要求禁止網際網路路由時，它們就很有價值。

陷阱：將安全群組附加到閘道端點 (它們沒有 ENI)；假設閘道端點可以從地端連線 (事實上不行——請使用介面端點或混合模式 EC2 → S3 閘道端點 → 獨立的 DX 路徑)；在介面端點上停用私有 DNS，卻期望未經修改的 SDK 呼叫能正常運作 (它們會透過網際網路連到公有端點，完全違背了使用端點的初衷)；建立了閘道端點，卻忘了關聯私有子網路的路由表 (流量會默默地繼續走公有路徑)；試圖為沒有閘道端點的服務 (例如 KMS) 使用閘道端點——只有 S3 和 DynamoDB 適用。

VPC 互連：對等連接 (Peering) vs. 傳輸閘道 (Transit Gateway)

VPC 對等連接 (VPC peering) 是兩個 VPC 之間一對一、非傳遞性 (non-transitive) 的第三層 (Layer 3) 連線，可在相同或不同帳戶、相同或不同區域中進行。流量走 AWS 骨幹網路，沒有頻寬瓶頸，也沒有小時計費——您只需支付跨可用區 (cross-AZ) 或跨區域 (inter-Region) 的資料傳輸費用。有兩個特性限制了對等連接：(1) 它是 非傳遞性的 (non-transitive)——如果 A 與 B 對等連接，B 與 C 對等連接，A 無法透過 B 連到 C；以及 (2) CIDR 範圍不得重疊。以全網狀 (full-mesh) 拓撲連接 N 個 VPC 需要 N(N-1)/2 個對等連接，且每個連接的雙向都需編輯路由表；以 30 個 VPC 為例，這就是 435 個對等連接。期望對等連接能擴展到數百個 VPC 是一個陷阱。

Transit Gateway (TGW) 是一個區域性的雲端路由器。每個 VPC、VPN 或 Direct Connect 閘道都是一個附件 (attachment)，而 TGW 路由表控制哪個附件可以連到哪個前綴。這將一個 O(n²) 的網狀拓撲轉換為 O(n) 的附件模式，並實現了軸輻式 (hub-and-spoke) 拓撲，其中一個安全 VPC 可託管防火牆來檢查所有 VPC 間的流量。TGW 支援傳遞性路由，原生終止 VPN 和 Direct Connect 閘道關聯，並且可以透過 Resource Access Manager 在 AWS Organizations 中共享，讓中央網路團隊控制路由，而工作負載帳戶則擁有自己的 VPC。TGW 會增加每小時每個附件的費用，以及大約每處理 1 GB 流量 $0.02 的費用。

對於跨區域 (inter-Region) 連線，TGW 對等連接 (TGW peering) 透過 AWS 全球骨幹網路連接不同區域的 TGW，流量經過加密——每個區域一個 TGW，以網狀或軸輻式設計進行對等連接。這避免了跨區域 VPC 對等連接會重新引入的 N 平方問題。

路由表的整潔度是這裡的隱形殺手。建立一個對等連接或 TGW 附件本身並不會有任何作用，直到在兩個 VPC 的子網路路由表中都明確新增指向 pcx- 或 tgw- 目標的 CIDR 路由，並且安全群組允許該流量。悄無聲息的連線失敗幾乎總是能追溯到遺失的路由，或是安全群組中參考了錯誤來源 CIDR 的隱性拒絕規則。

混合式連線：Site-to-Site VPN 與 Direct Connect 的比較

選擇 Site-to-Site VPN 或 Direct Connect，是在「部署速度快且內建加密」與「一致的低延遲、專用頻寬和可預測的吞吐量」之間的一種權衡。

Site-to-Site VPN 在客戶閘道 (地端路由器) 與 Virtual Private Gateway 或 Transit Gateway 之間建立兩條 IPsec 隧道。每個隧道的上限約為 1.25 Gbps。流量在網路層加密，與 TLS 結合使用時，可滿足網路層和會話層的加密要求。它通過公共網際網路，因此延遲和抖動是可變的，但它在幾分鐘內即可使用，每小時成本僅幾美分。當需要立即連線、頻寬需求不大，或作為備援路徑時，請使用它。

Direct Connect (DX) 提供一條從地端路由器到 AWS Direct Connect 位置的專用光纖連線 (1、10 或 100 Gbps)。它繞過公共網際網路，從而實現一致的延遲和更高的吞吐量。DX 的出口流量定價遠低於網際網路出口流量，這在每天傳輸數百 GB 資料時非常重要。佈建需要數週時間——包含交叉連接 (cross-connects)、授權書 (LOAs)、BGP 設定。

這裡有兩個主要的陷阱。首先，單獨使用 Direct Connect 並不會加密流量。私有線路不等於經過密碼學保護的通道。若要在 DX 上滿足加密要求，需在其上層疊加 Site-to-Site VPN，或在支援的專用連接埠上使用 MACsec 進行第二層加密。其次，一個原始的 DX 連線本身無法路由到多個 VPC。一個私有 VIF 連接到一個附加到單一 VPC 的 Virtual Private Gateway。要連接到多個 VPC——特別是跨帳戶和區域時——請使用 Direct Connect Gateway，透過 transit VIF 與 Transit Gateway 關聯，並將每個 VPC 附加到 TGW：

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

典型的生產模式是使用兩條 DX 連線，在兩個不同的 DX 位置終端於不同的客戶路由器，並以 Site-to-Site VPN 作為自動 BGP 故障轉移的備援——當 DX 正常運作時，透過 BGP AS-path prepending 或 MED 將流量導向 DX；如果 DX 故障，BGP 會撤銷 DX 路由，並由 VPN 接管。

負載平衡器：ALB、NLB 與 GWLB

ALB 是第 7 層，能理解 HTTP 語意——例如主機和路徑路由、WebSockets、重新導向、基於 cookie 的黏性會話。對於非 HTTP 的任何協定，它都不是合適的工具：例如 MQTT、原始 TCP、基於 UDP 的 syslog、SMTP。ALB 使用基於 DNS 的定址，其 IP 會隨時間變化；它無法被指派 Elastic IP。當用戶端需要將目的地 IP 加入白名單時，單獨使用 ALB 是不合適的——應改用帶有 EIP 的 NLB，或在 ALB 前端加上 Global Accelerator 的兩個靜態 anycast IP。「只要解析一次 ALB 的 DNS 並將 IP 固定在防火牆規則中」是一個陷阱：AWS 會在不另行通知的情況下更改這些 IP。

NLB 是第 4 層，可擴展至每秒數百萬個流量。它預設會保留真實的用戶端來源 IP (目標會看到真實的用戶端 IP)，支援為每個可用區指派一個靜態的 Elastic IP，並處理高吞吐量的 TCP/UDP 工作負載。過去，NLB 本身不支援安全群組——用戶端的 CIDR 必須直接在目標的安全群組中被允許。AWS 在 2023 年為 NLB 新增了可選的安全群組，但許多設計仍然假設是傳統的行為模式。

典型的公開對外模式是：

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

在後端將 ALB 的安全群組（而非 CIDR）作為來源，是最小權限的模式，並且會自動涵蓋來自 ALB ENI 的健康檢查流量。ALB 本身位於至少兩個可用區的公有子網路中（有路由到 IGW）；目標則位於私有子網路中。將面向網際網路的 ALB 放置在私有子網路中是一個典型的錯誤設定——目標註冊會成功，但用戶端無法連線到它。

Gateway Load Balancer (GWLB) 是專為透明地插入第三方虛擬應用裝置（如防火牆、IDS/IPS、DPI）而設計的。它在第 3 層運作，使用 GENEVE 封裝 (在 UDP 6081 上) 來轉發所有 IP 協定。流量透過 GWLB 端點 (GWLBe) 到達 GWLB——GWLBe 是一個位於子網路中的介面端點，並在路由表中顯示為一個目標：

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

該端點透過 PrivateLink 將封包轉發到 GWLB，GWLB 則使用流量黏性在應用裝置叢集中進行負載平衡，以確保一個流量的雙向都命中同一個應用裝置。在 hub-and-spoke 的檢查設計中，spoke VPC 會附加到一個 TGW，其路由表會強制東西向流量在到達目的地 VPC 之前，先通過檢查 VPC（包含 GWLB 和應用裝置）。入口流量檢查則使用邊緣路由表，將從 IGW 到 Web 層的流量先重新導向到 GWLBe：

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

對於集中式、跨帳戶的流量檢查，這是正確的解決方案——自己用 EC2、自訂路由表技巧和故障轉移腳本來土炮，只是在重新發明 GWLB 原生提供的功能。

為消費者對提供者服務設計的 PrivateLink

除了為 AWS 服務提供介面端點的動力外，PrivateLink 還能實現與第三方或其他 AWS 帳戶發布的服務之間的私有連線。提供者將其服務置於 NLB 之後，並建立一個 VPC endpoint service。消費者則在自己的 VPC 中建立針對該服務的介面端點。

關鍵的方向性規則是：連線總是從消費者端發起，朝向提供者端。 提供者無法主動發起連線到消費者的 VPC。流量絕不會接觸到網際網路，只有特定的目標服務可以連線（不像 peering 那樣可以連到整個提供者的 VPC），而且因為兩邊都只暴露端點 IP，所以不會出現 CIDR 重疊的問題。對於消費者 VPC 沒有 IGW、沒有 VPN、也沒有 Direct Connect 的 SaaS 或供應商資料庫存取模式，這就是標準的解決方案。VPC peering 會暴露整個 CIDR 範圍，且要求 IP 不重疊；TGW attachment 的路由範圍較廣；而透過網際網路的 public API 則不是私有的。

Global Accelerator 與 Route 53

AWS Global Accelerator 會指派兩個靜態的 anycast IPv4 位址，並從全球的 AWS 邊緣站點進行宣告。用戶端的流量會從最近的邊緣站點進入，並沿著 AWS 骨幹網路傳輸到最近的健康區域端點（ALB、NLB、EIP 或 EC2）。這同時解決了兩個問題：為 ALB 提供靜態 IP（彌補了白名單的不足），以及透過繞行公共網際網路，為全球分佈的使用者減少抖動/延遲。它能加速那些無法快取的 TCP/UDP 流量到達來源，適用於 CloudFront（其功能為快取內容）不適用的情境。

Route 53 解決的是不同的問題——DNS 層級的流量導向。Global Accelerator 影響的是資料層本身；Route 53 只影響 DNS 解析，解析完成後，TCP 連線會直接連到解析出的 IP 所在位置。這兩者經常結合使用：一個 Route 53 alias 指向一個 Global Accelerator，而這個 Global Accelerator 再將流量導向各區域的 ALB。

Route 53 路由政策：

延遲型和地理位置型常被混淆：延遲型是為了最小化使用者感受到的來回時間（RTT）；地理位置型則是為了強制執行資料落地，不論延遲如何。多區域的容錯移轉需要在主要資源上設定健康檢查。Alias records 是 AWS 特有的記錄類型，可以直接解析到 ALB、NLB、CloudFront、S3 網站和 API Gateway 端點，不收取查詢費用，而且——不像 CNAME——可以在 zone apex（裸域名）上使用。

Route 53 Resolver 透過 .2 位址（VPC CIDR 基礎位址 + 2）在 VPC 內部回應 DNS 查詢。對於混合式 DNS，inbound endpoints 讓地端解析器可以查詢 AWS 中的私有託管區域；outbound endpoints 搭配轉送規則，則讓 VPC 內的資源可以解析地端的名稱。若沒有這些設定，EC2 執行個體將無法解析 corp.internal，而地端伺服器也無法解析 db.prod.internal——這是一個很細微的故障，只有當應用程式開始進行跨環境查詢時才會浮現。介面端點需要啟用私有 DNS (Enable Private DNS)，SDK 的呼叫才會導向端點的 ENI；若未啟用，呼叫仍會透過網際網路連到公有端點，從而失去了使用介面端點的意義。

安全群組、NACL 與最小權限

安全群組是有狀態的 (stateful)——回傳的流量會被自動允許——並且作用在 ENI 層級。NACL 則是無狀態的 (stateless)，作用在子網路邊界。NACL 中的任何 TCP 規則都需要明確的傳入 和 傳出規則；因為用戶端會從臨時連接埠範圍中選擇一個來源埠，所以回傳方向的規則必須允許 1024–65535 的連接埠（Linux 預設使用 32768–60999；這個更寬的範圍涵蓋了 Windows 和其他堆疊）。忘記設定臨時埠的回傳規則，是造成連線完成 SYN 但在等待回應時卡住的典型原因。

為了在不同層級間實踐最小權限，安全群組規則應該參考其他安全群組 ID，而不是 CIDR。這樣可以配合 Auto Scaling 進行擴展，並避免使用脆弱的 IP 白名單：

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL 是一種粗略的爆炸半徑控制工具，不能取代安全群組。若為了「深度防禦」而收緊 NACL，卻沒有相應地修改安全群組，通常會導致向外發起的流量（例如透過 NAT 閘道進行的 yum/apt 更新）中斷，因為無狀態的回傳流量會被靜默丟棄。路由表最終決定了可達性：即使安全群組設定得很寬鬆，如果路由表中沒有到達目的地的條目，流量也無法傳遞；反之，閘道端點只有在 S3 前綴列表路由確實安裝在工作負載所在子網路的路由表中時才有效。

決策參考

← 資料傳輸與遷移 · 所有領域 · 內容交付、邊緣與效能最佳化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →