
一家出海SaaS 企業在遷移上AWS 三個月後,遭遇了嚴重的安全事故:由於RDS 資料庫實例被錯誤放置在公有子網,且安全群組規則過於寬鬆,導致資料庫連接埠暴露在公網,引發了一次資料外洩風險告警。
這個案例在出海企業上雲初期並不罕見。許多團隊急於完成遷移,對VPC 網路架構的理解停留在」能跑起來就行」的階段,結果為後續的安全和維運埋下隱患。
VPC(Virtual Private Cloud)是AWS 上所有資源的網路基礎。本文從核心概念到實戰配置,幫你把這個基礎打牢。
什麼是AWS VPC?
VPC 是你在AWS 雲端專屬的虛擬網路環境。你可以完全控制這個網路的IP 位址範圍、子網路劃分、路由規則和網路安全策略,就像在自己的資料中心裡管理網路一樣,但無需購買任何實體硬體。
每個AWS 帳戶在每個Region 會自動建立一個預設VPC,方便快速啟動資源。但對於生產環境,強烈建議創建自訂VPC,以獲得更精細的控制權。
VPC 的核心組成
| 組件 | 作用 |
|---|---|
| CIDR 區塊 | 定義VPC 的IP 位址範圍(如10.0.0.0/16) |
| 子網路(Subnet) | 將VPC 劃分為較小的網段,分佈在不同可用區 |
| 路由表(Route Table) | 控制子網路內流量的轉送規則 |
| 網際網路閘道(IGW) | 允許公有子網路與網際網路通信 |
| NAT 閘道 | 允許私有子網路存取互聯網,但阻止外部主動存取 |
| 安全群組(Security Group) | 實例層級的虛擬防火牆,控制入站/出站流量 |
| 網路ACL(NACL) | 子網路層級的防火牆,提供額外的存取控制層 |
子網規劃:公有子網路vs 私有子網
合理的子網路分割是VPC 架構設計的第一步,也是最關鍵的一步。
公有子網路(Public Subnet)
公有子網路是指路由表中包含指向網際網路閘道(IGW)路由的子網路。放置在公有子網路中的資源可以擁有公網IP,直接與網際網路通訊。
適合放入公有子網路的資源:
- 應用負載平衡器(ALB/ELB)
- NAT 閘道
- 堡壘機(Bastion Host)
- 需要直接面向網際網路的Web 伺服器(特殊場景)
私有子網路(Private Subnet)
私有子網路的路由表不包含直接通往IGW 的路由,資源無法從網路直接存取。私有子網路中的資源若需存取網際網路(如下載軟體包、呼叫外部API),需透過NAT 閘道中轉。
適合放入私有子網路的資源:
- 應用程式伺服器(EC2 實例)
- 資料庫(RDS、Aurora、ElastiCache)
- 內部API 服務
- 批次處理任務
標準三層架構示意
網際網路↓ [公有子網路] — 負載平衡器(ALB) ↓ [私有子網路] — 應用伺服器(EC2) ↓ [私有子網路] — 資料庫(RDS)
這種分層架構確保資料庫和應用程式伺服器永遠不會直接暴露在公網,大幅降低攻擊面。
多可用區(Multi-AZ)規劃
生產環境必須在至少兩個可用區(Availability Zone)部署子網路。 AWS 的可用區是獨立的實體資料中心,跨AZ 部署可在單一AZ 故障時保證服務連續性。
推薦的子網規劃(以ap-northeast-1 東京Region 為例):
| 子網路名稱 | CIDR | 可用區 | 類型 |
|---|---|---|---|
| public-subnet-1a | 10.0.1.0/24 | ap-northeast-1a | 公有 |
| public-subnet-1c | 10.0.2.0/24 | ap-northeast-1c | 公有 |
| private-app-1a | 10.0.11.0/24 | ap-northeast-1a | 私人 |
| private-app-1c | 10.0.12.0/24 | ap-northeast-1c | 私人 |
| private-db-1a | 10.0.21.0/24 | ap-northeast-1a | 私人 |
| private-db-1c | 10.0.22.0/24 | ap-northeast-1c | 私人 |
路由表配置
每個子網路必須關聯一張路由表。路由表決定了該子網路內的流量如何轉送。
公有子網路由表
公有子網路路由表需要包含兩條核心路由:
第一條是本地路由,目標為VPC 的CIDR 區塊(如10.0.0.0/16),目標為local,這條路由由AWS 自動添加,允許VPC 內部資源互相通訊。
第二條是網際網路路由,目標為0.0.0.0/0(所有流量),目標指向網際網路閘道(igw-xxxxxxxx),這條路由使公有子網路中的資源可以存取和被存取網際網路。
私有子網路由表
私有子網路路由表同樣有本地路由(自動建立),但不包含直接的IGW 路由。若私有子網路中的資源需要存取互聯網,則需增加一條0.0.0.0/0 指向NAT 閘道的路由。
重要提示:NAT 閘道本身必須部署在公有子網路中,並擁有彈性IP(EIP)。每個可用區應部署獨立的NAT 網關,避免單點故障。
安全群組配置最佳實踐
安全群組是AWS 中最常用的網路安全控製手段,它工作在實例級別,屬於有狀態防火牆(允許的入站流量,回程流量自動放行)。
最小權限原則
安全群組配置的核心原則是:只開放必要的端口,只允許必要的來源。
反例(危險配置):
| 類型 | 協定 | 連接埠 | 來源 |
|---|---|---|---|
| 入站 | TCP | 22 (SSH) | 0.0.0.0/0 |
| 入站 | TCP | 3306 (MySQL) | 0.0.0.0/0 |
| 入站 | All Traffic | All | 0.0.0.0/0 |
上述配置將SSH 和資料庫連接埠暴露給全球所有IP,極度危險。
正例(建議配置):
應用程式伺服器安全群組:
| 類型 | 協定 | 連接埠 | 來源 |
|---|---|---|---|
| 入站 | TCP | 80/443 | ALB 安全性群組ID |
| 入站 | TCP | 22 | 堡壘機安全群組ID |
| 出站 | All | All | 0.0.0.0/0 |
資料庫安全群組:
| 類型 | 協定 | 連接埠 | 來源 |
|---|---|---|---|
| 入站 | TCP | 3306 | 應用程式伺服器安全性群組ID |
| 出站 | All | All | 0.0.0.0/0 |
透過安全群組ID 相互引用,而不是使用IP 位址,可以確保即使EC2 實例IP 發生變化,安全規則仍然有效。
安全群組vs 網路ACL
| 特性 | 安全群組 | 網路ACL |
|---|---|---|
| 作用範圍 | 實例層級 | 子網路級別 |
| 狀態類型 | 有狀態 | 無狀態 |
| 規則類型 | 僅允許規則 | 允許+ 拒絕規則 |
| 規則順序 | 無序(取並集) | 有序(按編號匹配) |
| 適用場景 | 日常存取控制 | 額外安全層/緊急封鎖 |
對於大多數場景,安全群組已足夠。網路ACL 主要用於需要明確拒絕特定IP 段(如封鎖已知惡意IP)或增加額外合規審計層的場景。
VPC 對等連線與Transit Gateway
當企業業務規模擴大,需要在多個VPC 之間打通網路時(例如開發、測試、生產環境分屬不同VPC),有兩種主要方案:
VPC 對等連結(VPC Peering)
兩個VPC 之間建立一對一的私有網路連接,流量不經過互聯網,延遲低、成本低。
適合場景:VPC 數量較少(3個以內),需要簡單的點對點連線。
限制:VPC Peering 不支援傳遞性路由,即AB 對等、BC 對等,並不代表A 能存取C。
Transit Gateway
Transit Gateway 是AWS 提供的網路樞紐服務,可將多個VPC 和本地網路連接到同一個中心節點,以實現全互聯或受控互聯。
適合場景:VPC 數量較多(4個以上)、有混合雲(本地資料中心+雲端)需求、需要集中管理路由策略的企業。
常見VPC 配置錯誤與避坑指南
根據我們服務出海企業上雲的經驗,以下是最常見的VPC 配置錯誤:
錯誤一:資料庫放在公有子網
很多初學者為了方便連接,把RDS 放在公有子網並開放公網存取。正確做法是將RDS 始終放在私有子網,透過堡壘機或AWS Systems Manager Session Manager 進行維運存取。
錯誤二:生產環境使用預設VPC
預設VPC 的安全群組和路由配置過於寬鬆,且所有子網路都是公有子網路。生產環境必須使用自訂VPC。
錯誤三:NAT 網關只部署一個
如果只在一個可用區部署NAT 網關,當該AZ 發生故障時,所有私有子網路的出站流量都會中斷。高可用架構要求每個使用的可用區都有獨立的NAT 閘道。
錯誤四:忽略VPC 流日誌
VPC 流日誌(VPC Flow Logs)記錄所有進出VPC 的網路流量訊息,是安全審計和故障排查的重要工具。建議從搭建VPC 時開啟串流日誌,輸出到CloudWatch Logs 或S3。
總結:VPC 架構設計核心原則
一個健壯的AWS VPC 架構應遵循以下原則:
- 縱深防禦:公有子網路+ 私有應用子網路+ 私人資料庫子網,三層隔離
- 最小權限:安全群組只開放必要端口,來源精確到安全群組ID
- 高可用:跨至少兩個可用區部署,每個AZ 獨立NAT 網關
- 可觀測:開啟VPC 串流日誌,接入CloudWatch 監控警報
- 自訂優先:生產環境禁止使用預設VPC
VPC 是AWS 架構的基石,前期規劃好,後期省心省力。如果你正在規劃企業的AWS 上雲架構,或是現有VPC 配置有安全隱患,歡迎與我們聯繫,進行免費的雲端架構評估。
→ 申請免費AWS 架構評估:aws-oncloudai.com/contact
本文由aws-oncloudai.com 雲端架構團隊撰寫。我們專注為中國出海企業提供AWS 雲端服務諮詢、架構設計與成本優化服務。

