AWS國際帳號服務 AWS VPC內聯網專線搭建詳細指南

第一章：為什麼要在 VPC 建「內聯網專線」

很多團隊把上雲理解成「把伺服器搬到雲端」。但在企業場景裡，真正的核心往往是網路。你希望雲端不是一個孤島，而是像企業內部機房一樣，能被既有安全體系、資安策略與運維流程接管。這就引出了「內聯網專線」的需求：用可預期的網路品質與路由控制，將本地網段安全、穩定地延伸到 AWS VPC。

所謂內聯網專線，通常指的是企業內部網到 AWS 的私網連接方式。最典型的是 AWS Direct Connect（DX），它提供專用物理連接或承載通道，再透過 AWS 端的網路服務把流量引入你的 VPC。與之相比，僅用公網 VPN（IPsec）也能達成連通，但在延遲抖動、頻寬上限、成本可控性、長期穩定性上，專線往往更符合「關鍵業務」的期待。

本文以可落地的思路帶你搭建一套「能跑、好管、可擴」的方案。你不需要一開始就把所有進階能力都做完；你需要的是一個從設計到驗收的路徑。

第二章：先做需求釐清，避免後期返工

在動手建立連接之前，先回答四個問題。這些答案會直接決定你使用 DX 還是 VPN、用單一 VPC 還是 Transit Gateway、路由採用靜態還是 BGP、以及如何設計網段與安全邊界。

AWS國際帳號服務 2.1 連接範圍與對端

你的「內聯網」是跟哪裡打通？是單一資料中心？還是多地（例如總部與分公司）？如果未來會擴展到多個 VPC 或多個帳號，你就應該預先考慮中心化網路入口（例如 Transit Gateway）與治理方式。

2.2 網路品質指標

你需要穩定帶寬還是低延遲優先？是否有 SLA 要求？對於互動式應用（如交易系統、工控、語音）延遲與抖動會更敏感。對批次傳輸與資料同步，帶寬與成本可能更重要。

2.3 路由與地址規劃約束

最常見的坑是網段重疊：企業內網用 10.0.0.0/8，AWS VPC 也用同樣網段。只要你希望用路由把內部網真正「延伸」，重疊就會讓你陷入複雜的 NAT、轉換或額外設計。理想狀態是提前做地址盤點，確保跨域不重疊。

2.4 資安與合規

你是否有嚴格要求的防火牆策略？是否需要在邊界做檢測、日誌留存、或用特定的安全分層（例如在 VPC 內放置防火牆實例/設備）？如果你需要一條「所有私網流量都必經防火牆」的路徑，那就要在路由設計上預留。

第三章：整體架構選型（DX、TGW、單 VPC vs 多 VPC）

落地方案通常有幾種常見組合。選型的目的不是追求花哨，而是把維運成本降到可承受範圍。

3.1 最直觀：Direct Connect 到單一 VPC

當你只有一個主要 VPC，且未來短期內不太可能增加更多 VPC/帳號，DX 直接連到該 VPC（通常透過公有虛擬介面或在 VPC 端建立對應的網關路由）是最簡單的起步方式。優點是理解成本低；缺點是擴展性受限，後續若要接多 VPC，可能需要重構。

3.2 可擴展：Direct Connect + Transit Gateway

Transit Gateway（TGW）是一個跨 VPC 的中心轉送層。當你希望把多個 VPC、跨帳號網段或多區域連接納入同一套治理框架時，TGW 往往是更好的選擇。你可以在 TGW 端集中管理路由策略與連接關係，減少「每加一個 VPC 就要在邊界重畫一遍」的成本。

3.3 什麼情況要額外考慮集中防火牆

AWS國際帳號服務 如果你有強制要求所有內外網流量必經防火牆設備（物理/虛擬/第三方），你需要把路由設計成「回程走防火牆」。這通常意味著在 VPC 內部署防火牆子網，並使用自訂路由（例如路由表中的目標下一跳）或 TGW 路由方式，讓流量先到防火牆，再出站到目標網段。

AWS國際帳號服務 第四章：網段與子網設計——把可預測性留給未來

專線搭建成功與否，很多時候取決於「地址設計是否乾淨」。當網路越複雜、連接越多，越需要清晰的命名與一致的規則。

4.1 網段盤點與規劃原則

請列出：

• 企業本地網段（包含站點、伺服器區、辦公網、管理網等）
• AWS 既有 VPC 網段與預計新增網段
• 是否有重複風險（例如 10.0.0.0/8、192.168.0.0/16 等常見段）

AWS國際帳號服務 原則上，避免同一個 CIDR 在兩個域同時出現。如果已不可避免，需要提前討論轉換策略（但轉換會讓除錯與安全審計更複雜）。

4.2 子網切分：公網入口與內網承載分離

建議將子網按用途切分：

• 連接服務（如果你有需要）可放在特定子網
• 內網工作負載子網（應用/資料）獨立
• 防火牆/網路設備子網（若有集中出口）獨立
• 管理子網（SSH/RDP、跳板）與工作負載分離

這樣做能讓安全控制更精準，也能讓路由策略不被打散。

4.3 多可用區（AZ）與高可用

不只要連上，還要能承受故障。至少在 VPC 層面，應在不同 AZ 部署關鍵資源（例如 NAT、防火牆、關鍵服務）。在路由與安全組態上，確認 AZ 故障時流量仍有可用路徑。

第五章：建立 AWS VPC 基礎網路（你要先有一個穩的地基）

在開始做專線連接前，VPC 必須具備可靠的基本結構。這部分看似枯燥，但會直接影響後面的路由與安全效果。

5.1 建立 VPC、子網與路由表

建立 VPC 時，先決定是否啟用 IPv6（多數內聯網需求仍以 IPv4 為主）。然後建立至少兩個 AZ 的子網，並為每個子網配置路由表。

VPC 路由表中，你需要先把「到本地網段」與「到其他 VPC 或 TGW」的路由預留好。通常流程是：建立連接後再把路由條目填入；但在設計上，先確定哪些子網要走專線、哪些要走 NAT 或互聯。

5.2 安全群組與網路 ACL：用最小授權

安全群組（SG）建議採用以「服務」為核心的規則，而不是以「來源 IP」堆疊。網路 ACL（NACL）則適合做更底層的白名單控制，但它容易造成維運負擔。若你的團隊不擅長管理 NACL，優先把 SG 做乾淨，NACL 使用預設即可。

在內聯網專線場景下，你要確認：

• 本地網段到雲端服務的入站規則正確
• 回程流量不被阻擋
• 管理流量（跳板、管理端口）有單獨策略

第六章：Direct Connect 專線搭建步驟（核心操作）

下面以 DX 為主線描述。實際入口（控制台選項、資源命名）可能因帳號與地區略有差異，但概念一致。

AWS國際帳號服務 6.1 準備：建立 DX 連接與驗證資訊

你需要準備：

• 本地端路由器設備資訊（介面、BGP 設定、ASN 等）
• AWS 端 VLAN 與本地對應參數（通常在申請 DX 時由供應商與 AWS 協調）
• 與你的工單/交付文件對照的連線細節

在交付前就把「你到底要做靜態還是 BGP」想清楚。若你有多網段需要宣告，且希望路由收斂更可控，通常會選 BGP。

6.2 建立虛擬介面（VLAN）與連接端點

在 AWS 端建立 Virtual Interface（VIF），其目的就是把物理專線上的某段通道映射到你的 AWS 網路邏輯。

關鍵是把 VIF type 與目標網路服務對上。若你的架構採用 TGW，則通常 VIF 會接入 TGW 相關的介面邏輯；若你是單 VPC 方案，則接入到該 VPC 所需的邏輯路徑。

6.3 路由協議：BGP 設定與路由策略

對專線來說，BGP 的價值在於你能夠：

• 明確宣告本地可達網段（或相反）
• 控制哪些網段從 AWS 宣告出去
• 用 prefix list / route map 做過濾（避免誤宣告）

你需要在本地路由器與 AWS 端一致配置 ASN、MD5（如有）、以及鄰居 IP。收斂後，確認：

• 路由表中能看到對方宣告的 CIDR
• 沒有重疊路由導致循環
• 路由優先順序符合預期

6.4 連通性驗收：從控制面到資料面逐層驗證

不要只看「連線狀態綠燈」。你要驗證資料面。建議用分層方式：

• AWS國際帳號服務 先測路由可達：本地到 AWS 基礎網段
• 再測特定服務：例如跳板主機或應用端口
• 最後測應用層：資料庫連線、檔案傳輸、HTTP/HTTPS 等

資料面驗證要盡量使用同一批測試目的地址，避免因為測試目標變動導致排查困難。

第七章：路由與回程設計——讓流量走對、走回來

專線失敗最常見不是「連不起來」，而是「回程不通」。這往往出現在路由表與宣告策略沒有一致設計，或某些子網路由沒有被更新。

7.1 VPC 路由表：到本地網段的下一跳

在需要被專線承載的子網（通常是工作負載子網）路由表中，添加到本地 CIDR 的路由，下一跳指向你使用的網路入口（例如 TGW 或 DX 連接介面）。

同理，若你的目標是本地也能訪問雲端服務，你需要在本地側宣告雲端 CIDR，並確保本地路由器把回程交給專線。

7.2 TGW 路由：Attachment、Route Table 與政策

使用 TGW 時，還要確認：

• 每個 VPC attachment 是否正確關聯到對應 TGW route table
• 路由是否包含該目標 CIDR
• 是否存在不必要的 blackhole route

很多團隊在 TGW 上只改「一半」。例如雲端側路由表已經指向 TGW，但 TGW route table 沒有把本地 CIDR 映射到正確 attachment，導致流量卡在轉送層。

7.3 防火牆與 UDR（User Defined Route）：你想要的路徑必須被刻出來

如果你要經過防火牆，則需要：

• 在工作負載子網的路由表，把目的為本地/其他網段的流量下一跳指向防火牆
• 防火牆子網則再把流量轉送到 TGW 或專線入口
• 防火牆自身的安全規則要允許這些轉發

AWS國際帳號服務 否則你會遇到：路由到防火牆有了，但防火牆沒有允許回程或轉發，最終呈現為「連線建立但資料無法傳」。

第八章：DNS 與命名解析——讓使用者覺得它就是一張網

內聯網的體感來自兩件事：IP 可達與名稱可用。你可以先在網路層通了，但如果 DNS 解析混亂，使用者仍會覺得「不穩定、不完整」。

8.1 解析策略：Route 53 Resolver 或本地 DNS

常見做法有兩種：

• 讓本地 DNS 查詢雲端名稱（需在雲端配置可回應的 resolver 規則）
• 讓雲端 DNS 查詢本地名稱（需在 VPC 內配置 resolver 規則與轉發目標）

你應依照既有 DNS 的權責模型選擇方向。若企業已經有成熟的 AD/DNS，通常以企業為權威源更符合治理。

8.2 規則與轉發範圍：避免解析污染

建立 DNS 規則時，務必限制轉發範圍（例如只針對特定內網 zone），避免把公網名稱也轉到錯誤的後端造成延遲。

8.3 測試方法：不只 ping，還要測解析與端口

驗收時至少做：

• 名稱到 IP：nslookup/dig 測試
• IP 到服務：telnet 或連線測試
• 反向問題：若你有嚴格驗證（例如憑證/白名單），還要確認反向解析需求

第九章：安全控制與最小授權——把連通變成可審計

專線不是用來放寬安全，而是把連通性提升到更可控的層級。你需要在路由與防火牆策略之外，建立可審計能力。

9.1 安全分層建議

• 網路層：Security Group 做服務級規則
• AWS國際帳號服務 路由層：只允許必要的 CIDR 通往專線
• 裝置層：如使用防火牆，防火牆做應用層策略
• 管理層：把管理流量限制在管理子網與跳板

9.2 日誌與監控：至少要能追溯「何時、哪裡、誰」

至少要做到：

• VPC Flow Logs 開啟並能查詢到跨網段的流量
• DX/TGW 相關事件與告警有回饋到值班渠道
• 防火牆或安全設備具備可查詢的流量記錄

很多事故的關鍵不是「不知道發生」，而是「不知道是哪個環節先錯」。日誌能把時間線補齊。

第十章：高可用與故障處理——把單點風險降下來

專線專案的驗收不該只停在連通成功。你還要測「斷了會怎樣」。企業級網路最怕的是：平時沒問題，一故障就停擺。

10.1 雙專線與多路由器策略

AWS國際帳號服務 若供應商與成本允許，應使用雙物理連接，並在本地與 AWS 端建立冗餘路由。TGW 端的 attachment 與路由表也要確保能在主鏈路中斷後仍有替代路徑。

10.2 路由收斂測試：觀察時間與行為

故障測試要看兩件事：一是收斂要多久，二是收斂後是否出現錯誤路由（例如黑洞或回圈）。可以針對指定 CIDR 做連線觀測，記錄中斷與恢復時間。

10.3 回退方案：VPN 作為最後手段

很多團隊在專線旁邊保留 VPN 作為回退。這不是為了取代專線，而是為了在 DX 異常時確保關鍵服務仍可維持最低可用性。回退策略要在專案中提前定義：什麼條件觸發、誰負責、怎麼切換、切換後監控誰看。

第十一章：跨帳號與跨區域治理（讓它能長期擴張）

當你開始把專線帶進多個團隊或多個帳號後，治理會變成主要成本。你要避免「每個帳號各自一套，最後全都互相打架」。

11.1 TGW 跨帳號：權限與資源關聯

跨帳號通常需要清晰的權限授權與資源關聯流程。建議把網路資源的擁有權（ownership）與變更流程寫成規範：誰建立 TGW、誰管理 route table、誰申請 attachment、誰能改路由。

11.2 命名規則與文件：少做一次就會多錯一次

你應用可維護的方式保存資料：網段清單、路由表摘要、BGP prefix 宣告清單、每個服務對應的安全規則。當人員輪替或專案移交，你靠的不是記憶，而是這份資料。

第十二章：常見錯誤排查清單——把排查時間壓縮

下面是專線搭建與連通測試中最常見的問題與排查方向。你可以把它當作「驗收時的檢查表」。

12.1 只通一邊：本地能 ping 雲端，但雲端回不去

• 檢查本地是否有雲端 CIDR 的路由指向專線
• 檢查 TGW 或 VPC 路由表是否在目的 CIDR 上配置正確下一跳
• 檢查安全群組是否允許回程流量（入站狀態與端口範圍）

12.2 跟路由表像「對了」但連線仍失敗

• 安全規則與 NACL 可能阻擋特定端口
• 應用端只允許特定來源 IP，你實際來源卻變了（可能經過防火牆或 NAT）
• DNS 解析不一致，導致連到錯誤 IP

12.3 BGP 鄰居建立了，但沒有宣告路由

• prefix list/route map 過濾錯誤，或宣告未包含目標 CIDR
• ASN、MD5、鄰居 IP 配置不一致導致隱性問題
• 本地與 AWS 端的路由策略不一致（例如只接受某些前綴）

12.4 路由宣告後，流量突然變慢或抖動

• 可能出現路由回圈或錯誤路徑（回程走了非預期介面）
• 防火牆或檢測設備成為瓶頸，需要檢查吞吐與連線狀態
• 確認使用的應用端口與協議是否遭限速或深度檢測

第十三章：如何做驗收（讓你能交付而不是只「弄好」）

驗收不是看一張拓撲圖，而是把風險點轉成可驗證項。建議用「測試用例 + 觀測指標」完成交付。

13.1 功能性驗收

• AWS國際帳號服務 本地到雲端指定服務可用（至少包含資料庫、應用端口、管理端口）
• 雲端到本地指定服務可用
• DNS 解析正常（正向與必要的反向）

13.2 非功能性驗收

• 延遲與丟包在可接受範圍
• 在鏈路中斷時能恢復（測出收斂時間）
• 日誌可查（能定位到流量與來源）

13.3 文件化交付

交付文件至少包括：

• 網段清單與規劃說明
• 路由宣告清單（BGP prefix、route map 摘要）
• VPC 路由表與 TGW route table 對照
• 安全規則清單（服務級與管理級）
• 故障回退流程與聯絡人

結語：把專線當成一種「長期能力」而不是一次工程

AWS VPC 內聯網專線搭建的難點不只在「把線連上」，而在於你是否建立了清晰的地址規劃、可控的路由策略、可審計的安全控制，以及可演練的故障回退。當這些基礎都到位，你得到的不只是連通性，而是一套能隨業務擴張的網路能力。

如果你現在正準備動工，建議先回到本文的順序：需求釐清 → 網段設計 → VPC/TGW 基礎 → DX 建立與路由協議 → 路由與回程驗證 → DNS 與安全 → 高可用與故障演練 → 驗收與文件。照這個節奏，你會比「照著教學做」更少踩坑，也更容易把結果交付給未來的運維與擴容。