混合連線維運 — BGP 限制、路由管理與 PrivateLink 存取

AWS Certified Advanced Networking — Specialty 考試 (ANS-C01) 網域 3 的任務 3.1「維護 AWS 和混合網路上的路由和連線」，是設計導向任務 1.5 的運作對應。任務 1.5 要求你架構具有 BGP 屬性操作的雙 Direct Connect 加 VPN 備援，而 3.1 則要求你保持該架構的健康 — 診斷 BGP 工作階段抖動 (Flapping)、在達到前綴限制時彙整路由、安排故障轉移測試、在 AWS 端維護時段生存、驗證 PrivateLink 端點健康狀況，以及在漂移後協調跨帳戶 RAM 共享資源。具備對路由限制、BGP 計時器、BFD 和標準維護程序的專業程度，是 ANS-C01 與其他 AWS 認證的分水嶺。

本主題深度涵蓋了考試要求的任務 3.1。我們將介紹主導 AWS 網路架構的路由限制 (Direct Connect 每個 VIF 接收 100 個前綴的上限、VGW 的 100 條路由限制、TGW 的 10,000 條路由限制)、在這些限制內保持運作的路由彙整策略、用於亞秒級故障轉移的 BFD 和 BGP 計時器調校、營運人員必須了解以避免意外停機的 AWS 託管維護時段 (針對 Direct Connect 和 VGW)、Direct Connect 故障轉移測試程序 (故意關閉 BGP、流量切換、恢復)、包含 DPD 和 NAT-T 的 VPN 隧道維護、PrivateLink 端點健康模式，以及跨帳戶資源共享維護程序。敘述內容基於考試常見的情境形式：「BGP 工作階段每 90 秒抖動一次 — 最可能的原因是什麼？」並提供三個看似合理但錯誤的選項和一個特定的正確診斷。

為什麼維護在 ANS-C01 網域 3.1 中佔有一席之地

任務 3.1 的知識點明確提到了「業界標準路由協定 (Direct Connect 上的 BGP)」、「限制與配額」、「私有與公有存取方法」以及「跨區域和區域內通訊模式」。技能點要求你管理混合連結上的路由協定、透過 PrivateLink 和對等連線維護私有存取、使用路由表引導流量並自動傳播，以及優化動態和靜態路由協定上的路由 (路由彙整、CIDR 重疊)。最後一個技能是 3.1 中考試產出最高的部分 — 幾乎每個 Specialty 考生都會遇到關於「Direct Connect 前綴限制超出」或「BGP 路由彙整」的問題。

考試框架是運作導向而非架構導向：網路在六個月前已正確建立，但現在出現了故障，你必須在不重新架構的情況下進行診斷和修復。這需要了解具體限制 (Direct Connect 每個 VIF 最多從內部部署接收 100 個前綴)、具體故障模式 (超出前綴限制時 BGP 工作階段中斷)、具體工具 (CloudWatch 上的 ConnectionState、客戶路由器上的 BGP show 命令、TGW Network Manager Route Analyzer) 以及具體修復程序 (彙整內部部署發佈、如果是硬性配額則透過 Support 申請提高、為變更安排維護時段)。

ANS-C01 還詳細測試了主動/被動 Direct Connect 加 VPN 備援模式 — 不是作為設計問題 (那是 1.5)，而是作為維護問題：「在計畫中的 Direct Connect 維護期間，如何確保流量流向 VPN 而不產生抖動？」。正確答案涉及 VPN BGP 工作階段上的 AS-PATH 前置 (Prepending)、BFD 計時以及透過 CloudWatch 指標驗證 BGP 工作階段狀態。該問題中潛伏著三個看似合理的干擾項。

白話文解釋 Hybrid Connectivity Maintenance — BGP Limits and Route Management

維護混合網路就像維護兩座城市之間的一座關鍵橋樑。橋樑有重量限制、車道限制、定期檢查和緊急程序 — 網路有前綴限制、路由限制、AWS 維護時段和 BGP 故障轉移程序。我們用三個類比來幫助內化。

類比 1：城市橋樑維護計畫

Direct Connect 連結是數據中心與 AWS 之間的一座專用橋樑。橋樑對每個方向的貨車數量都有重量限制 (BGP 前綴限制 — 每個 VIF 從內部部署到 AWS 最多 100 個)。如果你嘗試發送第 101 輛貨車，交通會完全停止 (BGP 工作階段中斷)，直到你減少數量。路由彙整是將貨物整合到更少、更大的貨車中 — 與其發佈 15 個 /24，不如發佈一個涵蓋相同範圍的 /20。BGP 是橋樑用來發佈哪些目的地可達的調度協定；BFD 是橋樑結構健康監測器，它能實現亞秒級偵測，報告故障的速度比 BGP 緩慢的 Keepalive 計時器快得多。

AWS 維護時段是城市預定的橋樑檢查時間 — AWS 會透過 Personal Health Dashboard 發佈即將進行的 Direct Connect 端點、VGW 和 Transit Gateway 維護；在這些時段，橋樑可能會關閉一條車道 (一個隧道關閉)。如果沒有冗餘 (第二座橋，即 Site-to-Site VPN 備援)，你將面臨檢查期間交通停止的風險。主動/被動故障轉移規則是：在正常運作期間，所有貨車都使用主橋 (Direct Connect)，但如果主橋關閉，貨車會自動重新路由到次要橋樑 (VPN)；路由發佈在次要路徑上使用 AS-PATH 前置，使其吸引力降低 — 調度員宣告「這條路線較長，僅在沒有其他路線時使用」。

類比 2：電網變電站

Direct Connect 連結是工廠與區域電力公司 (AWS) 之間的高壓輸電線路。線路具有額定容量 (BGP 前綴限制)，變電站具有路由表插槽 (VGW 或 TGW 路由表大小限制)。BGP 工作階段是電力線同步信號 — 兩端必須保持同步，否則線路會跳閘。BFD 是能在毫秒內做出反應的故障中斷器，而 BGP 則需要數秒。路由彙整是以更高的電壓傳輸，用更少的導體覆蓋相同的距離 — 將許多小的發佈結合成幾個大的發佈。AWS 維護時段是電力公司預定的變電站維護，透過 Personal Health Dashboard 提前宣佈；冗餘電力饋線 (雙 Direct Connect 或 DX + VPN) 可在維護期間保持工廠運作。主動/被動路由是電力公司的偏好饋線與備用饋線配置 — 主饋線處理正常負載，當主饋線斷開時，備用饋線在幾秒鐘內啟動。

類比 3：區域航空公司樞紐營運

Direct Connect 是你家鄉機場與 AWS 樞紐機場之間的專用商業航班位 (Slot)。該位置對每次航班宣佈的最大貨運目的地數量有限制 (BGP 前綴限制)。BGP 工作階段是與機場營運部門的航班時刻表同步。BFD 是快速天氣警告無線電 — 亞秒級故障偵測。路由彙整是將多個目的地標籤整合到一個貨櫃中 — 與其宣佈你的卡車遞送的每個單獨鄰里，不如宣佈整個大都會區。AWS 維護時段是跑道維護時間表，發佈在 AWS Personal Health Dashboard 上；維護期間的航班可能會改道至備用機場。VPN 備援是另一家承運商的包機備援航班 — 僅在主航班不可用時使用；AS-PATH 前置是增加了額外航點的飛行計畫，使該航線不如主商業航班受青睞。

AWS 網路路由限制 — 塑造架構的關鍵數字

ANS-C01 測試驅動混合網路設計的特定配額和限制。請記住這些數字。

Direct Connect BGP 前綴限制

• 每個私有 VIF 或 Transit VIF 最多從內部部署接收 100 個前綴。這是硬性配額 — 超出會導致 BGP 工作階段中斷，而不僅僅是抑制。
• 每個公有 VIF 最多接收 1000 個前綴 — 較高是因為公有 VIF 可以向 AWS 公有服務發佈內部部署網路。
• AWS 會將所有連接的 VPC CIDR 發佈到你的內部部署路由器 — 因此，如果你有 50 個 VPC 連接到一個 Direct Connect Gateway，AWS 會向你發佈 50 多個前綴。這通常沒問題，因為客戶路由器通常能處理數十萬個 BGP 前綴；限制是在往 AWS 的方向，而非往客戶的方向。

VGW 路由限制

• 從單個 VGW 傳播到 VPC 路由表的路由上限為 100 條。超出會導致多出的路由傳播靜默失敗 — 而非工作階段中斷。
• 單個 VGW 可以連接 20 個連線 (VPN + Direct Connect VIF)。

Transit Gateway 配額

• 每個 TGW 路由表 10,000 條路由 — 很慷慨，但在非常大的多區域部署中可能會超出。
• 預設每個 TGW 有 5 個 TGW 路由表 (可提高)。
• 預設每個 TGW 有 5,000 個連接 (Attachments) (可透過 AWS Support 提高到 50,000 個)。
• 透過 Transit VIF 使用 Direct Connect Gateway 時，每個 Direct Connect Gateway 可連接 20 個 VPC。

VPC 路由表限制

• 每個 VPC 路由表預設 50 條路由；可提高到 1,000 條 — 但路由超過 500 條後效能會開始下降。
• 每個 VPC 預設 5 個次要 CIDR 區塊；可提高。

為什麼這些數字對維護很重要

• 將新的 VPC 新增到帶有內部部署連線的 TGW 時，如果內部部署已經發佈了 99 個前綴，則可能會超過 Direct Connect 的 100 個前綴上限 — 新 VPC 的 CIDR 使計數超過限制，BGP 工作階段會中斷。
• 透過 BGP 傳播的新內部部署子網可能是導致工作階段中斷的第 101 個前綴。
• VGW 路由表傳播達到 100 條路由時，新路由會靜默丟棄 — 到達新內部部署網路的連線會失敗，且沒有明顯的「工作階段中斷」信號。

路由彙整策略

彙整 (也稱為超網或聚合) 是保持在路徑限制內的營運手段。

客戶端彙整

客戶路由器發佈一個較大的 CIDR，其中包含你希望可達的所有較小 CIDR。例如，與其發佈 10.0.0.0/24, 10.0.1.0/24, ..., 10.0.15.0/24 (16 個前綴)，不如發佈 10.0.0.0/20 (一個涵蓋相同範圍的前綴)。在 AWS 網路內部，返回任何屬於 /20 範圍內的 10.0.x.x 地址的流量都能在連結上正確路由。

權衡：僅當底層 CIDR 連續時，彙整才有效。非連續範圍 (如 10.0.0.0/24 和 10.5.0.0/24) 無法彙整到單個超網中，除非包含未分配的空間 (這會導致導向該未分配空間的流量進入黑洞)。對於非連續範圍，請將其彙整為涵蓋每個連續區塊的最小超網。

AWS 端發佈

AWS 不會自動彙整它向你的內部部署路由器發佈的 VPC CIDR。每個連接的 VPC CIDR 都按原樣發佈。如果你有 30 個 VPC，每個都有 /16 CIDR，你將從 AWS 接收 30 個 BGP 前綴。要減少數量，你需要設計具有連續 CIDR 的 VPC 以進行彙整 — 但 AWS 仍會單獨發佈每個 CIDR。實際含義：AWS 端發佈的前綴數量隨連接的 VPC 增加而增加。

允許的前綴過濾器 (Allowed Prefixes filter)

對於向 AWS 公有服務發佈內部部署網路的 公有 VIF，你需要指定「允許的前綴」過濾器 — AWS 僅會從你的內部部署 BGP 發佈中接受這些前綴。這可以防止意外劫持，並作為你發佈內容的健全性檢查。對於私有 VIF 和 Transit VIF，過濾器是隱含的 (AWS 接受最多 100 個前綴，不論內容，只要符合 RFC 1918 範圍即可)。

當彙整仍不足夠時

如果你確實需要從內部部署發佈超過 100 個前綴，選項包括：

• 在同一個連線上使用多個 VIF — 每個 VIF 都有自己的 100 個前綴預算。
• 使用多個 Direct Connect 連線 — 每個連線都有自己的 VIF。
• 重組內部部署編址，以實現更積極的彙整。
• 聯繫 AWS Support 申請提高配額 (很少獲得批准；通常 AWS 會建議先進行彙整)。

BGP 計時器調校與 BFD

BGP Keepalive 與 Hold 計時器

AWS Direct Connect 上的預設 BGP 計時器：Keepalive 30 秒，Hold Time 90 秒。這意味著 BGP 在實際失效後 60-90 秒才會偵測到工作階段故障 — 對於關鍵任務工作負載來說太慢了。將計時器減少到 Keepalive 10 / Hold 30 可以更快偵測到故障，但會增加兩端路由器的 CPU 負載，且並非所有設備都統一支援。

BFD — 亞秒級故障轉移

雙向轉發偵測 (BFD) 是一種專為亞秒級連結故障偵測而設計的輕量級協定。兩端路由器每 100-300 毫秒發送一次 BFD 封包；連續錯過 3-5 個封包則宣告連結失效。AWS Direct Connect 支援非同步 BFD，預設偵測時間約為 900 毫秒 (300ms × 3)，可調低至約 150 毫秒 (50ms × 3) 以實現極速故障轉移。

BFD 在每個 VIF 上透過在 AWS 和客戶路由器兩端設定 bfd_enabled = true 來啟用。AWS 將 BFD 與 BGP 工作階段結合使用 — 當 BFD 偵測到連結故障時，BGP 會立即中斷，流量會轉向備援路徑 (VPN, 第二個 DX)，而無需等待 BGP Hold Time。沒有 BFD，乾淨的 BGP 正常關閉至少需要 5-10 秒；非正常故障則需要 90 秒以上。

BGP MD5 身分驗證

AWS 支援在 BGP 工作階段上使用 MD5 密碼驗證，建議基於安全性開啟。兩端必須配置相同的密碼；密碼不匹配會阻止 BGP 工作階段建立。AWS BGP 目前不支援 SHA-1 或更強的身分驗證 — MD5 是唯一選項。

BGP 正常重啟 (Graceful Restart)

AWS Direct Connect 支援 BGP 正常重啟，如果任何一端路由器的 BGP 控制平面重啟 (例如在軟體升級期間)，BGP 工作階段可以在不丟失流量的情況下恢復。正常重啟預設啟用；它會設定一個「過時路由計時器」，以便在 BGP 重新建立時保留現有的轉發狀態。

AWS 託管維護時段

AWS 會對 Direct Connect 端點、虛擬私有閘道和 Transit Gateway 執行計畫性維護。營運人員必須了解通知管道、影響和冗餘要求，以渡過難關。

AWS Personal Health Dashboard

維護通知會出現在受影響帳戶的 AWS Personal Health Dashboard (現為 AWS Health 的一部分)。EventBridge 可以訂閱 AWS Health 事件，透過 SNS、Slack 或 PagerDuty 整合實現通知自動化。維護通常提前 7-14 天宣佈。

Direct Connect 端點維護

AWS 可能需要升級終止 Direct Connect VIF 的 AWS 端路由器。在維護時段內，該 VIF 的 BGP 工作階段會關閉，流量必須重新路由到備援路徑。AWS 建議：

• 在兩個不同的 AWS Direct Connect 地點建立兩個 Direct Connect 連線，以實現完全冗餘。
• 在同一個連線上建立兩個 VIF 並不是冗餘 — 兩者都終止在同一個 AWS 路由器上，並在該路由器維護期間同時失效。
• 使用 BGP 進行主動/被動故障轉移 — 主 VIF 處理所有流量；在主 VIF 維護期間，被動 VIF 透過 BGP 自動重新路由接管。

VGW 維護

VGW 是託管服務，由 AWS 處理維護。VGW 原生支援隧道彈性；在維護期間，一個隧道可能會短暫關閉。只要客戶閘道同時使用兩個隧道，流量就會在另一個隧道上繼續傳輸。

TGW 維護

TGW 的設計具有高度彈性 — 多可用區域部署意味著單個控制平面更新不會影響資料平面流量。客戶很少看到 TGW 維護的影響，除非正在修改特定的跨連接路由。

客戶維護程序

對於影響 BGP 工作階段的客戶端路由器或防火牆維護：

• 如果沒有冗餘，請安排在低流量時段進行。
• 透過內部變更管理宣佈，以便值班人員了解預期的 BGP 抖動。
• 在停機前使用 AS-PATH 前置或 BGP 正常關閉來排乾該路徑的流量。
• 提前驗證備援路徑 — 透過受控測試證明流量能在次要路徑上正確傳輸。

Direct Connect 故障轉移測試與驗證

從營運角度看，定期的故障轉移測試可驗證你的冗餘是否在真正需要時起作用。

計畫中的故障轉移測試程序

標準程序：(1) 通知利害關係人測試時段。(2) 準備回滾計畫 — 恢復主要的確切命令、預期時間。(3) 啟動故障轉移 — 在客戶路由器配置中手動關閉主 VIF 的 BGP (shutdown BGP 鄰居)，或暫時移除主路由的靜態路由。(4) 驗證 — 確認 CloudWatch 指標顯示流量正在次要路徑上傳輸；檢查應用程式指標在切換期間是否有任何錯誤；檢查間斷時間 (使用 BFD 應為亞秒級，不使用則為 5-30 秒)。(5) 恢復 — 重新啟動主要 BGP 工作階段；驗證流量返回主要路徑；確認沒有殘留的不對稱路由。(6) 記錄 — 故障轉移時間、任何非預期行為、後續行動。

故障轉移測試頻率

對於關鍵任務的混合連線，AWS 建議每季進行故障轉移測試。對於較低層級的工作負載，年度測試結合雲端配置稽核即可。在任何重大網路變更 (新的 VPC 連接到 TGW、宣佈新的內部部署子網、客戶路由器升級) 後，故障轉移測試也非常有用。

驗證指標

證明故障轉移成功的 CloudWatch 指標：

• ConnectionState — 測試期間主要為 0，次要為 1；恢復後兩者均為 1。
• ConnectionBpsEgress / ConnectionBpsIngress — 故障轉移期間主要路徑應下降，次要路徑應上升。
• 工作負載 ENI 處的 VPC Flow Logs — 應顯示流量持續存在，切換時僅有短暫間隔。
• 應用程式層級指標 — 測試期間的請求計數、錯誤率、p99 延遲。

用於主動/被動的 AS-PATH 前置

這是一種使流量在正常運作時偏好主要路徑，但在故障轉移期間使用次要路徑的機制。在次要 VPN 上，配置 BGP 在發佈內部部署前綴時多次前置其自身的 AS — route-map AS_PREPEND_OUT permit 10 配合 set as-path prepend 65000 65000 65000。AWS 看到次要路徑較長，會偏好主要路徑。當主要路徑失效時，次要路徑成為唯一路徑，流量隨之轉移。恢復主要路徑後，偏好會自動反轉。

Site-to-Site VPN 隧道維護

Site-to-Site VPN 隧道需要持續維護：監控隧道狀態、處理 DPD 逾時、處理位於 NAT 後方用戶端的 NAT-T 穿越以及重新金鑰。

DPD (Dead Peer Detection)

無回應對等端偵測 (DPD) 是用於偵測無回應對等端並拆除 IKE 關聯的 IPsec 機制。AWS 預設每 10 秒發送一次 DPD 探針；在 30 秒無回應 (連續錯過 3 個探針) 後，隧道被宣告失效並重新協商。在客戶閘道端，DPD 計時應匹配 — 大多數企業防火牆支援可配置的 DPD 間隔。

NAT-T (NAT 穿越)

如果客戶閘道位於 NAT 後方，IPsec ESP 流量 (協定 50) 無法穿越 NAT。NAT 穿越 (NAT-T) 將 ESP 封裝在 UDP/4500 中，允許 NAT 轉換。AWS Site-to-Site VPN 自動支援 NAT-T；客戶路由器必須配置為在 IKE 時間協商 NAT-T。偵測：如果客戶路由器位於 NAT 後方，會自動偵測並使用 NAT-T。

隧道重新金鑰 (Tunnel rekey)

預設情況下，AWS Site-to-Site VPN 隧道每 8 小時重新進行一次 IKE 第 1 階段金鑰協商，每 1 小時重新進行一次 IPsec 第 2 階段金鑰協商。重新金鑰對應用程式是透明的 — 流量在協商期間繼續傳輸。客戶閘道必須支援現代加密套件 (AES-256, SHA-2, DH group 14+)，以與目前的 AWS 預設值相容。

隧道端點更換

AWS 可能在計畫維護期間更換隧道端點 IP。客戶閘道必須配置兩個隧道端點 IP (每個連線有兩條隧道)，並同時使用兩者以實現高可用性。如果僅配置了一個，AWS 端的端點更換會中斷連線，直到客戶路由器更新為止。Personal Health Dashboard 會宣佈這些更換。

VPN 的 CloudWatch 指標

• TunnelState：up 為 1，down 為 0。對此設定警示以進行呼叫。
• TunnelDataIn, TunnelDataOut：驗證主動/主動共用或單隧道主導情況。
• TunnelIpAddress：隧道的 AWS 端端點 IP。

PrivateLink 端點維護

PrivateLink (介面和閘道端點) 有其自身的營運考量。

介面端點健康狀況

每個介面端點都在你的子網中佈建 ENI — 在啟用端點的每個可用區域 (AZ) 一個 ENI。ENI 由 AWS 管理，但在你的帳戶中可見。健康檢查考量：

• 端點狀態：pending, available, deleting, deleted, rejected, failed。透過 DescribeVpcEndpoints API 進行監控，並對非 available 狀態設定警示。
• 按可用區域劃分的可用性：每個 AZ 的端點 ENI 都是獨立的；AZ 層級的問題僅影響該 AZ 的端點。
• DNS 解析：啟用私有 DNS 後，端點會覆蓋公有 DNS。從 VPC 內部使用 dig <service-name> 驗證解析，確保響應指向 ENI 私有 IP，而非公有 IP。

端點安全性群組漂移

介面端點具有安全性群組；規則變更會隨時間漂移。定期稽核端點 SG，確保其僅允許來自預期用戶端子網的存取。AWS Config 規則可以標記具有過度寬鬆 SG 的端點。

端點策略 (Endpoint policies)

VPC 端點策略是附加到端點的 IAM 風格策略，限制哪些操作允許通過。更新端點策略需要謹慎的變更管理 — 過於嚴格的策略會拒絕通過端點的所有流量，導致用戶端應用程式故障。請先在非生產端點中測試策略變更。

跨帳戶端點共享維護

當服務提供者向取用者帳戶公開 PrivateLink 端點服務時，接受工作流程可能會漂移。新取用者帳戶請求連線；提供者手動接受 (除非啟用了自動接受)。當提供者擴展增加或移除端點服務後方的 NLB 目標時，取用者不會看到任何影響 (對端點透明)。當提供者移至新的 NLB 或端點服務 ID 時，取用者必須更新其端點配置 — 這是一個需要協調的破壞性變更。

Direct Connect SiteLink

Direct Connect SiteLink 是一項功能，允許兩個 Direct Connect 地點之間的流量穿越 AWS 骨幹網路，而無需先繞經 VPC。當組織有多個分支辦公室且每個都透過 Direct Connect 連接到 AWS 時，SiteLink 允許直接的分支對分支流量透過 AWS 內部連結而非網際網路傳輸。

SiteLink 在每個 VIF (私有或 Transit) 上啟用。定價：符合 SiteLink 條件的資料傳輸按不同於標準 Direct Connect 資料傳輸的費率計費。SiteLink 具有區域感知性：跨區域 SiteLink 使用區域間定價。

在維護方面，啟用了 SiteLink 的 VIF 遵循相同的 Direct Connect 維護規則 — AWS 端端點可能會受到計畫維護的影響，這需要在多個 Direct Connect 地點建立冗餘的啟用了 SiteLink 的 VIF。

常見陷阱回顧 — 網域 3.1

混合連線維護中考試最常寫的陷阱。

陷阱 1：AWS 在 BGP 發佈中彙整 VPC CIDR

錯誤。每個 VPC CIDR 都作為單獨的 BGP 前綴發佈。客戶端彙整是系統中唯一的彙整方式。

陷阱 2：Direct Connect 上的 100 個前綴限制是軟性上限

錯誤。它是硬性限制；超出會完全中斷 BGP 工作階段。

陷阱 3：在一個 Direct Connect 連線上建立兩個 VIF 提供冗餘

錯誤。同一個 AWS 路由器；同一個維護時段。在兩個地點建立兩個連線是最低要求。

陷阱 4：BFD 消除了 BGP 計時器調校的需求

錯誤。BFD 提供快速故障偵測；BGP 計時器仍主導工作階段 Keepalive 和正常重啟。兩者都應進行調校。

陷阱 5：VGW 支援超過 100 條傳播路由

錯誤。100 條路由是上限；超出後新的傳播路由會靜默丟棄且無警示。

陷阱 6：NAT-T 必須手動配置

錯誤。當客戶閘道進行協商時，AWS Site-to-Site VPN 會自動偵測 NAT 並透明地使用 NAT-T。

陷阱 7：VPN 隧道重新金鑰會導致流量丟失

錯誤。重新金鑰是透明的 — 流量在 IKE 第 1/2 階段協商期間繼續傳輸。

陷阱 8：AWS 託管的維護從不影響客戶流量

錯誤。Direct Connect 端點維護確實會影響單個連線上的單個 VIF。需要冗餘才能渡過。

陷阱 9：故障轉移測試對於冗餘設計是可選的

錯誤。未經測試的故障轉移路徑在真正需要時經常失敗。每季測試是 AWS 建議的頻率。

陷阱 10：AS-PATH 前置使路徑不可用

錯誤。AS-PATH 前置使路徑不如其他路徑受青睞，但仍然可用。當沒有更短的路徑時，流量會流向經過前置的路徑。

陷阱 11：PrivateLink 介面端點對維護免疫

錯誤。按 AZ 分配的 ENI 會單獨受到 AWS 維護的影響；端點提供者服務也可能有維護時段。

陷阱 12：SiteLink 取代了 VPC 對等連線或 TGW

錯誤。SiteLink 僅允許 Direct Connect 地點之間的流量在 AWS 骨幹網路上進行直接的內部部署對內部部署傳輸。它不取代 VPC 連線。

決策矩陣 — 每個 ANS-C01 目標的維護建構

常見問答 — 混合連線維護

Q1：我們 Direct Connect 上的 BGP 工作階段剛剛中斷 — 如何診斷我們是否達到了 100 個前綴限制？

診斷步驟：(1) 檢查 Direct Connect 連線上的 CloudWatch：ConnectionState 應顯示為 0；警示應該已經觸發。(2) 透過 SSH 連接到客戶端邊緣路由器並執行 show ip bgp summary (Cisco) 或等效命令。查看 BGP 工作階段狀態 — 如果顯示「Idle (PfxCt)」或「Idle (max-prefix)」，則客戶路由器報告它從 AWS 接收了太多前綴 (這種情況很少見，因為 AWS 很少發佈超過 100 個)。如果顯示工作階段逾時或 Hold-time 到期而無前綴計數，則問題在別處。(3) 檢查 AWS 端 BGP：在 Direct Connect 主控台中，VIF 將顯示為「Down」，並附帶「BGP_PEER_NEIGHBOUR_RECEIVED_TOO_MANY_PREFIXES」之類的原因。(4) 統計從內部部署發佈的前綴數量：在客戶路由器上執行 show ip bgp neighbors <aws-bgp-peer> advertised-routes | count。如果該計數 ≥ 100，則你已達到限制。(5) 彙整：辨識連續的 CIDR 範圍並將發佈結合成超網。重新建立 BGP 工作階段。(6) 記錄並提醒：新增一個監控「發佈前綴計數」的 CloudWatch 警示 — 這是一個你從客戶路由器透過 SNMP 發佈到 CloudWatch 的自訂指標 — 以在計數接近 90 時發出預警 (在達到 100 前)。

Q2：我配置了預設計時器且禁用了 BFD — 在 Direct Connect 停機期間，故障轉移需要多長時間？

使用預設計時器且沒有 BFD 時，故障偵測需要 60-90 秒。BGP Keepalive 計時器為 30 秒，Hold Time 為 90 秒 — 意味著 BGP 必須錯過 3 個 Keepalive 才能宣告工作階段失效。宣告工作階段失效後，BGP 必須收斂到備用路徑，這還需要額外的幾秒鐘 (對於 AS-PATH 前置的 VPN 備援，通常為 3-10 秒)。總恢復時間：65-100 秒。對於大多數生產工作負載來說，這是不可接受的。啟用 BFD 並使用預設的 300ms × 3 = 900ms 偵測，總恢復時間會下降到約 1-5 秒。如果使用 50ms × 3 = 150ms 的激進 BFD 計時，總恢復時間可接近亞秒級 — 這是關鍵任務混合連結的金本位標準。啟用 BFD 需要 AWS 和客戶路由器兩端的支援；大多數現代企業路由器 (Cisco, Juniper, Arista, Palo Alto) 都支援 BFD。請配置兩端、進行測試並透過故障轉移演練進行驗證。

Q3：我們需要向 AWS 發佈 150 個內部部署前綴 — 如何規避 100 個前綴限制？

三種可行的方法，按優先順序排列：(1) 客戶端路由彙整 — 這幾乎總是正確答案。辨識可合併為超網的連續 CIDR 範圍。例如，10.0.0.0-10.149.255.255 範圍內的 150 個單獨 /24 可以彙整為一個單個 /16 (10.0.0.0/16)，涵蓋所有範圍。權衡：彙整僅適用於連續範圍，且超網可能包含不應路由流量的未分配空間 (如果使用 VPC 路由表過濾，這是可以接受的)。(2) 在同一個 Direct Connect 連線上使用多個 VIF — 每個 VIF 都有自己的 100 個前綴預算。如果你的內部部署範圍自然分為兩組 (例如，生產 10.0.0.0/12，開發 172.16.0.0/12)，請為每組佈建一個私有 VIF。權衡：需要維護更多 BGP 工作階段；並非所有客戶路由器都能優雅地處理多 VIF。(3) 使用多個 Direct Connect 連線 — 每個連線都有自己的 VIF。這是最昂貴但最靈活的方法。當底層需求也包含冗餘時，這通常是正確答案。(4) 重組內部部署編址 — 如果前綴擴張是歷史累積的結果，長期的重新編址專案可以將許多小範圍合併為少數幾個可彙整的範圍。ANS-C01 期望將 (1) 作為首選，(2) 和 (3) 是升級方案。

Q4：我該如何針對 AWS 宣佈的 Direct Connect 正常維護時段進行架構設計？

架構方案：(1) 在兩個不同的 Direct Connect 地點建立兩個 Direct Connect 連線 — 當 AWS 對一個地點的路由器進行維護時，另一個地點繼續提供服務。(2) 具有 AS-PATH 前置的主動/被動 BGP 路由，使主要路徑在正常狀態下處理所有流量，而次要路徑僅在主要路徑維護期間接管。(3) 啟用 BFD 以實現亞秒級故障偵測。(4) 對兩個連線設定 CloudWatch ConnectionState 警示，並向值班人員發送 SNS 升級。 (5) 訂閱針對 Direct Connect 資源類型的 AWS Health 事件的 EventBridge 規則，在 AWS 宣佈維護時發送通知 — 通常提前 7-14 天。(6) 為每個維護場景建立記錄完備的運作手冊：正在維護哪個連線、預期的故障轉移行為、驗證步驟、升級路徑。(7) 每季進行故障轉移測試，以驗證維護當天的故障轉移是否真正起作用。有了這一套方案，AWS Direct Connect 維護就不再是大事 — 流量會自動切換，你也會在維護期間收到 CloudWatch 警示，維護完成後流量會切換回來。ANS-C01 期望將此作為「如何優雅處理 AWS 端 Direct Connect 維護」的標準答案。

Q5：BFD 具體起什麼作用，它與 BGP Keepalive 有何不同？

BFD (雙向轉發偵測) 是一種資料平面層級的快速故障偵測協定，設計得非常輕量，每 50-300 毫秒發送一次封包而不會產生顯著的 CPU 成本。BGP Keepalive 是控制平面層級的存活檢查，運行間隔慢得多 (預設 30 秒)，並使用 BGP TCP 工作階段本身。不對稱性：BFD 在毫秒內偵測到連結故障 (例如預設設定為 900ms)；BGP Keepalive 在 60-90 秒內偵測到 (連續錯過 3 個 Keepalive × 30s = 90s Hold Time)。BFD 封包是獨立於 BGP 發送的微小 UDP 資料報，因此如果 BGP 控制平面有響應但無法轉發流量 (例如 CPU 滿載)，BFD 會偵測到故障，但 BGP Keepalive 不會。AWS Direct Connect 支援非同步模式 (每端獨立發送) 的 BFD。BFD 故障會立即拆除 BGP 工作階段，然後 BGP 透過標準程序收斂到備用路徑。這兩種協定是互補的，而非冗餘 — 你應該同時運行兩者，而 BFD 是亞秒級與分鐘級故障轉移的分水嶺。

Q6：我該如何監控 PrivateLink 端點的生產環境健康狀況？

多個互補信號：(1) 按排程執行 DescribeVpcEndpoints API (每 5 分鐘一次 Lambda + EventBridge) — 查詢每個端點的狀態和每個 AZ 的 ENI 可用性。如果狀態 ≠ available 或缺少任何 AZ ENI，則發出警示。(2) 端點 ENI 上的 VPC Flow Logs — 透過 Athena 定期查詢，確認流量正在進出端點。流量突然下降可能預示著下游問題，甚至在 AWS 託管健康偵測到之前。(3) DNS 解析驗證 — 對於啟用了私有 DNS 的端點，定期從 VPC 內部使用 Lambda 檢查解析 AWS 服務主機名稱，並確認解析出的 IP 與端點 ENI IP 匹配。這裡的漂移可能預示著 DHCP 選項集或 Resolver 問題。(4) 應用程式層級健康指標 — 取用端應用程式應為其端點呼叫發佈自訂指標 (延遲、錯誤率、傳輸量)。端到端的成功是最終的驗證。(5) 端點策略驗證 — 定期使用 IAM Access Analyzer 審閱端點策略以偵測漂移。(6) 對於提供者端的自訂端點服務 — 監控底層 NLB 健康狀況、目標健康狀況和取用者連線的接受狀態。這些監控的集合提供了 PrivateLink 運作健康的全面覆蓋。

Q7：AS-PATH 前置 vs LOCAL_PREF vs MED — 在 AWS Direct Connect 上各控制什麼？

每個 BGP 屬性影響不同的路由決策。AS-PATH 前置影響從 AWS 到內部部署的對內流量 — 透過使路徑在 AS 跳數上顯得更長，AWS 會偏好較短的路徑，因此流量在對內到你的內部部署時會流向未經前置的 (主要) 路徑。在客戶路由器上為發向 AWS 的對外 BGP 發佈設定此項。LOCAL_PREF 影響從內部部署到 AWS 的對外流量 — 但 LOCAL_PREF 僅限於 iBGP (在同一個自治系統內)，因此 AWS 永遠看不到你的 LOCAL_PREF 設定；它僅影響你內部在多個 AWS BGP 對等端之間的路由決策 (這很少見，除非你有指向同一個 AWS 區域的多個 Direct Connect)。MED (多結束點鑒別器) 則更為微妙 — 當多個 BGP 路徑具有相同的 AS-PATH 長度時，它影響 AWS 如何選擇路徑，但僅當這些路徑來自同一個鄰居 AS (即你的 AS) 時才有效。對於具有從同一個內部部署 AS 到 AWS 的兩個連線的典型 Direct Connect 部署，MED 可以在它們之間微調偏好。考試標準模式：在次要 VPN 上進行 AS-PATH 前置，用於主動/被動 Direct Connect + VPN 故障轉移。MED 用於在兩個 Direct Connect 之間微調。LOCAL_PREF 很少對 AWS 可見。請記住這種不對稱性：AS-PATH 影響對內；LOCAL_PREF 影響對外；MED 是平局決勝因素。

Q8：Site-to-Site VPN 什麼時候是 Direct Connect 的正確備援，什麼時候第二個 Direct Connect 才是正確答案？

這取決於重要性和流量。Site-to-Site VPN 備援適用於：(a) 工作負載可以忍受 VPN 較低的頻寬 (通常每個 VPN 連線 1.25 Gbps，可透過 ECMP 彙整為更高)，(b) 第二個 Direct Connect 的成本不合理，(c) 恢復時間目標允許 VPN 在故障轉移期間稍高的延遲。常見模式：1 Gbps Direct Connect 配合 VPN 備援，用於非關鍵混合工作負載。第二個 Direct Connect 適用於：(a) 頻寬需求超過 VPN 彙整容量，(b) 工作負載有 VPN 無法滿足的嚴格延遲 SLA，(c) 監管要求即使在故障轉移期間也必須使用非網際網路傳輸，(d) 第二個連接埠的成本由工作負載價值支撐。常見模式：具有在不同 DX 地點的兩個 10 Gbps Direct Connect，外加 VPN 作為第三層故障轉移的第 1 級關鍵任務混合架構。對於 ANS-C01，提到「受監管產業」、「關鍵任務」或「一致的低延遲」的情境通常偏向雙 Direct Connect；提到「成本效益」或「小頻寬」的情境則偏向 DX + VPN。

Q9：當 VGW 路由傳播接近 100 條限制時，我該如何規劃？

多個選項：(1) 從 VGW 遷移到 Transit Gateway — TGW 支援每個路由表 10,000 條路由，限制大幅放寬。遷移涉及將 TGW 連接到所有相關 VPC、透過 Transit VIF + Direct Connect Gateway 連接 Direct Connect，以及更新 VPC 路由表以指向 TGW 而非 VGW。對於任何增長超過簡單單一 VPC 混合架構的組織，這都是正確的長期答案。(2) 客戶端路由彙整 — 減少來自內部部署的 BGP 發佈數量，使傳播到 VGW 的路由更少。技術與 Direct Connect 前綴限制彙整相同。(3) 使用靜態路由覆蓋傳播 — 如果某些路由是穩定的且不需要 BGP 傳播，請在 VPC 路由表中將其配置為靜態，僅依靠傳播處理動態路由。(4) 多個 VPC 各自擁有其 VGW — 將工作負載拆分為較小的 VPC，每個都有自己的 100 條路由 VGW；總容量會成倍增加。權衡：運作複雜度。ANS-C01 期望將 (1) 作為標準答案 — 在混合架構中，VGW 正在被 TGW 取代。新設計應始終使用 TGW。

Q10：有哪些「BGP 工作階段健康但流量不對稱或丟失」的營運信號？

症狀分類：(1) CloudWatch 顯示兩個 DX 連線的 ConnectionState=1，客戶路由器上 BGP 工作階段為 up — 連結沒問題。(2) 應用程式報告到某些內部部署目的地的連線間歇性逾時 — 開始調查。(3) 執行 TGW Route Analyzer 或 Reachability Analyzer，針對源到目的地配對進行檢查；驗證路徑是否正確且路由已傳播。(4) 檢查源 ENI 處的 VPC Flow Logs 是否有 REJECT 記錄 — 如果 SG/NACL 正在丟棄，你會看到它們。(5) 如果路徑中有 Network Firewall，請單獨檢查 NFW 日誌 — 那裡的丟棄不會出現在 Flow Logs 中。(6) 在客戶路由器上執行 show ip route <destination> 和 show ip bgp <destination> — 確認 AWS 正在發佈前綴且路由表包含該前綴。(7) 檢查不對稱路由 — 封包透過 DX-1 從 AWS 到內部部署，而回應透過 DX-2 返回 AWS，這會破壞有狀態防火牆；如果涉及檢測 VPC，請查看 TGW Appliance Mode。(8) 端到端驗證 MTU — PMTUD 黑洞會產生「小封包正常，大封包掛起」的症狀，即使 BGP 健康。診斷順序：連結狀態 → BGP 路由 → VPC 路由 → SG/NACL/NFW → 不對稱性 → MTU。ANS-C01 將此類問題定義為「間歇性連線失敗且無明顯 BGP 錯誤」 — 答案需要全面排查。

進階閱讀與相關操作模式

• AWS Direct Connect 使用者指南
• AWS Direct Connect 配額與限制
• Transit Gateway 配額
• Direct Connect 路由與 BGP
• 在 Direct Connect 上啟用 BFD
• VPN 的客戶閘道選項
• AWS Direct Connect SiteLink
• PrivateLink 支援的服務
• AWS ANS-C01 考試指南

了解混合連線維護後，ANS-C01 的下一個自然層級是：Direct Connect VIF 類型與 MACsec，用於跨連線加密的設計決策；BGP 屬性與路由操作，用於設計層級的流量工程工具；Transit Gateway 路由與連線，用於樞紐輻射式架構；以及具有最長前綴比對的 VPC 路由，用於決定任何 VPC 中封包出口決策的規則。

• Direct Connect — VIF 類型、LAG、MACsec — ANS-C01 學習筆記
• BGP 配置 — AS-Path、MED、社群、BFD — ANS-C01 學習筆記
• Transit Gateway — 路由表、連接與 Connect — ANS-C01 學習筆記
• VPC 路由 — 最長前綴比對、傳播、黑洞路由 — ANS-C01 學習筆記