系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★☆☆
核心考點：VNet 邏輯隔離、Subnet 跨可用區特性、CIDR 與 5 個保留 IP、Public IP / Private IP、Service Endpoint、Private Endpoint 與 Private DNS、VNet Peering（非傳遞式與 Gateway Transit）、Internet 進入 VM 的逐段封包請求路徑。
本文使用copilot +antigravity cli 3.6flash low +3.8 flash medium + market azure skill 完成。
Day 10 我們替 Titan 科技選好了 ACI 與 AKS：無伺服器容器輕騎兵能秒級啟動，Kubernetes 兵團則能大規模編排微服務。但如果沒有穩固的網路疆域與安全邊界，這些容器與虛擬機器不是在雲端內部互相失聯，就是把資料庫與內部管理介面直接暴露在公網掃描器前。今天我們要把雲端網路的基石徹底打牢：位址空間如何規劃、誰可以進入私有網路、PaaS 服務如何實現完全私有連線，以及跨 VNet 的流量究竟怎麼走。
對於具備 AWS 背景（CLF/SAA）的雲端工程師與架構師，今天最反直覺、也最容易在考場與實務上踩雷的核心觀念就是：Azure Subnet 不綁定 Availability Zone！
在 AWS 中，每一個 Subnet 都必須嚴格指定唯一的 Availability Zone（例如 us-east-1a）；但在 Azure 中，Subnet 是整個 Virtual Network（VNet）內部的邏輯 IP 分段，單一 Subnet 天生就涵蓋該 Region 內所有的 Availability Zones。如果在 Azure 看到 subnet-web，絕不能把它腦補成單一資料中心；要達成跨 AZ 高可用，必須在部署 VM 或 VMSS 時明確指定可用區（Zone 1、2、3），而不是靠建三個 Subnet 來自我安慰。
今日目標是建立一條符合 AWS Skill Builder 原廠培訓標準 的架構推理鏈：從 問題意識與架構風險剖析（Why/Risk/Blast Radius）、雙雲底層抽象演進機制 到 實體 Bicep/Terraform 程式碼解構，徹底掌握 AZ-900 網路核心考點！
Internet
|
v
Public DNS
|
v
Public IP / Application Gateway / Load Balancer
|
v
+------------------------------------------------------------------+
| Azure Region |
| |
| +------------------------------------------------------------+ |
| | VNet: 10.20.0.0/16 (Subnet does not bind an Availability | |
| | Zone) | |
| | | |
| | +------------------+ +------------------+ | |
| | | Web subnet | | API subnet | | |
| | | 10.20.1.0/24 | | 10.20.2.0/24 | | |
| | | NSG: inbound | | NSG: Web only | | |
| | | AKS / Web |--->| API workload | | |
| | +------------------+ +--------+---------+ | |
| | | | |
| | v | |
| | +------------------+ +------------------+ | |
| | | Data subnet |<---| Private Endpoint | | |
| | | 10.20.3.0/24 | | private IP | | |
| | | NSG: API only | | Private DNS | | |
| | +------------------+ +--------+---------+ | |
| | | Private Link | |
| | +--------+---------+ | |
| | | Azure SQL | | |
| | | Azure Storage | | |
| | +------------------+ | |
| | | |
| | Web/API subnets --(subnet association)--> NAT Gateway | |
| +------------------------------------------------------------+ |
| |
| VNet <==== VNet Peering (non-transitive) ====> Hub VNet |
+------------------------------------------------------------------+
讀圖方式：Internet 只到達公開入口；Web、API 與 Data 依信任邊界分在
不重疊的 Subnet，NSG 分別限制允許的來源。API 透過 Data subnet 的 Private
Endpoint 以私有 IP 連到 Azure SQL/Storage，Private DNS 負責把服務名稱解析
到該私有 IP。NAT Gateway 僅提供受控的出站連線；VNet Peering 是兩個 VNet
的直接私有連線，不會自動形成 Hub 的傳遞式路由。
┌──────────────────────┐ ┌──────────────────────┐
│ AWS: 網際網路入口 │ │ Azure: 網際網路入口 │
│ Internet Gateway │ │ Internet Endpoint │
└──────────────────────┘ └──────────────────────┘
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ 公有 IP / 彈性 IP │ │ 公用 IP 位址 │
│ Elastic IP (EIP) │ │ Public IP (PIP) │
└──────────────────────┘ └──────────────────────┘
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ 邊界與網卡防護 │ │ 網路安全性群組 │
│ NACL + SecGroup │ │ NSG (Subnet/NIC) │
└──────────────────────┘ └──────────────────────┘
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ 子網路（綁定單一AZ） │ │ 子網路（跨全Region） │
│ EC2 Instance │ │ Azure VM / VMSS │
└──────────────────────┘ └──────────────────────┘
💡 架構師重點筆記：兩側都能透過公有 IP 將 Internet 流量導入雲端工作負載，但 Azure 的 Subnet 屬於整個 VNet，並不代表單一 Availability Zone。在 Azure 中，同一子網路內的兩台 VM 可以分別放在 Zone 1 與 Zone 2；高可用性取決於運算資源部署時的可用區配置，而非網路子網路的切分。
┌─────────────────────────────────┬─────────────────────────────────┐
│ AWS VPC（Subnet 綁單一 AZ） │ Azure VNet（Subnet 跨全區） │
├─────────────────────────────────┼─────────────────────────────────┤
│ • Subnet 必須指定單一 AZ │ • Subnet 是邏輯分段，不綁 AZ │
│ • 跨 AZ 容錯需建多個 Subnet │ • 單一 Subnet 內 VM 可跨 AZ │
│ • 路由表需手動關聯 Subnet │ • 預設系統路由，全 VNet 互通 │
│ • 每個 Subnet 保留 5 個 IP │ • 每個 Subnet 保留 5 個 IP │
│ • Peering 無 Gateway Transit │ • Peering 支援 Gateway Transit │
└─────────────────────────────────┴─────────────────────────────────┘
💡 架構師重點筆記：雙雲在子網路底層有著根本的哲學差異。AWS 將 Subnet 視為實體機房（AZ）的容器，而 Azure 將 Subnet 視為純粹的邏輯定址與存取控制分段。
當外部使用者向 Titan 科技的系統發送 HTTP/HTTPS 請求時，封包在 Azure 網路底層經歷以下嚴格的逐段驗證路徑：
10.0.0.0/16。在子網路切分中，CIDR（無類別網域間路由）前綴長度決定可用 IP 數量。例如 /16 擁有 65,536 個位址，/24 擁有 256 個位址。
然而，Azure 在每一個 Subnet 中都會固定保留 5 個內部專用 IP，這與 AWS VPC 的保留機制完全一致，是架構師計算容量容量時不可踩的坑：
| 保留順序 | IP 位址範例 (10.20.1.0/24) |
Azure 保留用途 | AWS 對照保留用途 |
|---|---|---|---|
| 第 1 個 | 10.20.1.0 |
網路位址 (Network address) | 網路位址 (Network address) |
| 第 2 個 | 10.20.1.1 |
預設閘道 (Default Gateway) | VPC 路由器 / 預設閘道 |
| 第 3 個 | 10.20.1.2 |
Azure DNS 伺服器 | Amazon 提供的 DNS (Route 53 Resolver) |
| 第 4 個 | 10.20.1.3 |
Azure 內部預留 (未來用途) | AWS 未來用途預留 |
| 最後 1 個 | 10.20.1.255 |
網路廣播位址 (Network Broadcast) | 網路廣播位址（AWS 亦不支援廣播，保留） |
📌 原廠考點計算公式：一個
/24子網路的理論總數為 256，扣除 5 個保留 IP 後，實際可用主機 IP 僅有 251 個；若切出極小的/29（8 個 IP），扣除 5 個後僅剩 3 個可用 IP！規劃 AKS 節點集區或大量 Private Endpoint 時，必須預留充足空間。
對標 AWS Skill Builder 的範本剖析標準，我們透過 Side-by-Side 程式碼解構 Azure 宣告 VNet、Subnet 與 Private Endpoint 的核心語法：
// Azure Bicep: 定義 VNet 與多個子網路 (含 Private Endpoint 專用子網路)
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-09-01' = {
name: 'vnet-titan-prod'
location: 'eastus'
properties: {
addressSpace: {
addressPrefixes: [ '10.20.0.0/16' ] // 預留充足 CIDR 空間
}
subnets: [
{
name: 'snet-web'
properties: {
addressPrefix: '10.20.1.0/24'
}
}
{
name: 'snet-private-endpoints'
properties: {
addressPrefix: '10.20.2.0/24'
// 允許部署 Private Endpoint
privateEndpointNetworkPolicies: 'Disabled'
}
}
]
}
}
# AWS Terraform: 定義 VPC 與 Subnet (必須綁定 availability_zone)
resource "aws_vpc" "titan_vpc" {
cidr_block = "10.20.0.0/16"
enable_dns_hostnames = true
}
resource "aws_subnet" "web_subnet" {
vpc_id = aws_vpc.titan_vpc.id
cidr_block = "10.20.1.0/24"
availability_zone = "us-east-1a" # ⚠️ AWS 強制綁定特定可用區
}
在 Azure 存取 PaaS 服務（如 Azure Storage、Azure SQL Database）時，許多工程師常分不清 Service Endpoint 與 Private Endpoint 的本質差異：
| 評估維度 | Service Endpoint (服務端點) | Private Endpoint (私人端點 / Private Link) |
|---|---|---|
| 底層運作機制 | 讓 VNet 流量透過 Azure 內部骨幹直達 PaaS 服務，不經公開網際網路 | 在你的 Subnet 內直接建立一張虛擬網路卡 (NIC)，分配一個 Private IP |
| 端點 IP 位址 | PaaS 服務端點維持原有的 Public IP，無私有 IP | 完全轉移至 Subnet 內部的 私有 IP (Private IP) |
| 防火牆邊界 | 在 PaaS 服務防火牆上設定：「僅允許特定 VNet/Subnet 存取」 | 可在 PaaS 服務端完全關閉公網存取 (Deny Public Access) |
| DNS 解析需求 | 解析為公網 IP，無需修改 Private DNS | 必須搭配 Private DNS Zone（解析至 Subnet 私有 IP） |
| AWS 對應服務 | AWS VPC Gateway Endpoint（如 S3/DynamoDB） | AWS VPC Interface Endpoint（AWS PrivateLink） |
| 最佳適用場景 | 快速限制內部 VNet 來源，但預算有限的情境 | 最高合規標準、金融級完全私密網路、杜絕資料外洩 |
💡 防禦性設計關鍵：使用 Private Endpoint 時，PaaS 資源的公開網路存取即可切斷。但請注意：私有 IP 僅解決連線路徑，不等於通過身分驗證！呼叫 Storage 或 SQL 依然必須通過 Microsoft Entra ID 身分驗證或存取金鑰授權。
VNet Peering（虛擬網路對等互連）讓兩個不同的 VNet 透過 Microsoft 全球私有光纖骨幹網路 直接互通。封包傳輸延遲極低、頻寬高，且完全不經過公開網際網路。
Titan 科技正在將核心電商系統遷移至 Azure。微服務架構包含：公開前端 Web（由 AKS 與 VMSS 提供）、內部微服務 API，以及後端 Azure SQL Database 與 Blob Storage。
一位具備多年 AWS 經驗的資深架構師在白板上畫出了以下架構提案：
「為了符合金融級高可用標準，我們必須在 Azure 建立 3 個 Subnet，分別強制綁定 Zone 1、Zone 2 與 Zone 3；為了讓管理人員排查問題，把 Azure SQL 配置公用 IP 並由強密碼保護；最後，讓前端 VNet 與 API VNet 建立 Peering，再讓 API VNet 與地端資料庫建立 Peering，這樣前端就能直接存取地端資源。」
CTO 聽完後眉頭深鎖，轉向 Chief Cloud Architect（你）：「這份設計如果直接上線，會不會把我們帶進毀滅性的死胡同？請提出正確且合規的架構決策。」
10.20.0.0/16 統一 VNet，切分 Web、API 與 Private-Endpoint 三個不重疊子網路；VMSS 部署時跨 Zone 1/2/3 放置；後端 Azure SQL 與 Storage 部署 Private Endpoint 並停用公網存取；跨 VNet 互聯走 VNet Peering，若需中繼連線地端則配置明確路由或 Hub Gateway Transit。Subnet-Zone1、Subnet-Zone2），並宣稱 Subnet 是實體故障隔離容器。方案 A 展現了正統的 Azure 雲端架構實務：
本節精選 5 題核心真題（3 題 ExamTopics 高頻題 ＋ 2 題 gratisexam 歷史題庫題），全數改寫為 Titan 科技實戰情境，剔除已退役技術，並依照原廠思維鏈進行拆解。
Titan 科技正在規劃雲端網路架構，架構師需要向管理團隊說明：在 Azure 中建立 Virtual Network (VNet) 的最主要核心能力是什麼？
【關鍵字識別】：Virtual Network、主要能力 (Feature)。
【核心考點定位】：VNet 的本質是租戶在 Azure 雲端上的私有空間。
【陷阱識破】：封包檢驗（B）是 Azure Firewall 或 NVA 的功能；成本分析（A）是 Cost Management 的職責；異地備援（C）是 GRS/GZRS 儲存體或跨區域負載平衡的功能。
【逐一排除干擾項】：
【關聯官方最佳實踐】：VNet 透過專屬位址空間提供與其他租戶的「邏輯隔離（Isolation）」，並透過 Subnet 提供內部不同工作負載的「分段（Segmentation）」。正解為 D。
來源與驗證：改寫自 ExamTopics 社群高頻真題 Topic 1 Question 92（社群討論達成 100% 共識，真實 tally 票數高達 39 票全數投 D）；並經 Microsoft Learn：Azure Virtual Network 概觀 交叉驗證確認。
Titan 科技的安全合規官要求：必須防止部署在 Azure VNet 內的虛擬機器在存取 Azure Storage 帳戶時，將連線流量透過公開網際網路（Internet）路由。請問架構師應優先採用哪項功能？
prevent traffic from VNet to Storage via Internet（阻止流量經由網際網路）。Service Endpoint 可以把 Azure Storage 這類 PaaS 服務的連線，從 Azure VNet 直接延伸到 Azure 服務的骨幹網路（Azure backbone），而不是經由 Public Internet。
架構概念：
Azure VNet
┌─────────────────────┐
│ VM │
│ │
│ │ │
│ ▼ │
│ Service Endpoint │
└────────┬────────────┘
│ Azure Backbone
▼
Azure Storage
其他選項為什麼不對？
選項 判斷 原因
A. NSG ❌ 控制網路流量允許/拒絕，但不是用來建立 VNet → Storage 的私有 Azure 服務路徑
B. Public Endpoint ❌ 本身就是公用端點，與「避免 Internet」的要求相反
C. VPN Gateway ❌ 主要用於 VNet-to-VNet 或 On-premises ↔ Azure 的 VPN 連線，這裡不需要
D. Service Endpoint ✅ 讓 VNet 中的資源透過 Azure backbone 存取 Azure Storage
SAA 考試記法
看到：
VNet → Azure Storage / Azure SQL / Azure Key Vault，而且要求不要走 Internet
先想到：
Service Endpoint
但再進階一點要注意：
若題目強調「Private IP」或「完全私有連線」→ Private Endpoint
兩者很容易考混：
Service Endpoint
VNet ───── Azure Backbone ───── Azure Service
（服務仍有 Public Endpoint）
Private Endpoint
VNet ───── Private IP ───── Azure Service
（透過 Private Link）
所以這一題既然選項沒有 Private Endpoint，標準答案就是 D。
Titan 科技在同一個 Azure 區域建立了兩個虛擬網路：VNet-Production 與 VNet-Analytics。兩者需要進行大量資料交換，要求傳輸延遲極低、不經過公開網際網路，且不需部署 VPN 閘道硬體設備。請問應使用何種連線架構？
【關鍵字識別】：同區域兩 VNet 互通、不走網際網路、免 VPN 閘道。
【核心考點定位】：VNet Peering 的骨幹直連能力。
【陷阱識破】：ExpressRoute 是連接地端與雲端的專線，不是 VNet 對 VNet 的直接解法。
【逐一排除干擾項】：
【關聯官方最佳實踐】：VNet Peering 直接利用 Azure 高速實體光纖骨幹互聯，免閘道、免加密開銷，為 Azure 內部網路互通之首選。正解為 A。
來源與驗證：改寫自 ExamTopics AZ-900 高頻真題考點（討論串高達數十則驗證）；並經 Microsoft Learn：虛擬網路對等互連 交叉驗證確認。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q33 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，並已校正現行名詞。
Titan 科技計劃建立 Site-to-Site VPN，將地端機房的用戶端電腦連接至 Azure VNet 中的虛擬機器。在建立 Virtual Network Gateway（虛擬網路閘道）之前，必須在 Azure VNet 內預先建立哪一個專屬資源？
GatewaySubnet 的專用子網路VNet-Router 的虛擬機器【關鍵字識別】：Virtual Network Gateway、預先建立之資源。
【核心考點定位】：GatewaySubnet 的系統命名保留規則。
【陷阱識破】：許多工程師以為子網路名稱可以自訂（如 vpn-subnet），但 Azure 平台強制規定閘道必須且只能部署在名為 GatewaySubnet 的子網路中！
【逐一排除干擾項】：
【關聯官方最佳實踐】：Azure 要求部署 Virtual Network Gateway 時，子網路名稱必須為 GatewaySubnet，且建議前綴大小至少為 /27，以預留未來雙主動或維護升級 IP。正解為 A。
來源與驗證：改寫自 2020 gratisexam Q33；並經 Microsoft Learn：關於 VPN 閘道設定與 GatewaySubnet 交叉驗證確認。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（Q37 改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證，強調資源層級相依關係。
Titan 科技決定將所有網路與伺服器資源全面遷移至 Azure。在架構師能夠開始在 Azure 中建立第一個 Virtual Network (VNet) 或任何虛擬機器之前，組織必須在 Azure 中最先建立哪項實體？
【關鍵字識別】：最先建立 (Create first)、規劃之起點。
【核心考點定位】：Azure 資源階層結構（Day 1 核心觀念連動）。
【陷阱識破】：Management Group（D）是可選的管理容器，並非建立資源的強制前提。
【逐一排除干擾項】：
【關聯官方最佳實踐】：在 Azure 中，所有資源的部署與計費都必須錨定在 Azure Subscription（訂用帳戶） 之內。沒有 Subscription，就無法呼叫 ARM API 建立 VNet。正解為 A。
來源與驗證：改寫自 2020 gratisexam Q37；並經 Microsoft Learn：Azure 基本概念 - 訂用帳戶與資源群組 交叉驗證確認。
| 項目 | 內容 |
|---|---|
| 對應課程章節 | 第 2 章 ▸ Networking 請求路徑、VNet、Subnet、IP / Endpoint（p83–87） |
| 官方考綱領域 | Describe Azure Architecture & Services（占比 35–40%） |
| 課程涵蓋範圍 | Networking 請求路徑、VNet 與 Subnet、IP 位址，以及 Service/Private Endpoint 的基本定位 |
| 本文補充範圍 | Microsoft Learn 的 CIDR 實務規劃、5 個保留 IP 雙雲深度對照；Azure Subnet 跨全區不綁 AZ 與 AWS VPC 差異；Service Endpoint 與 Private Endpoint 的邊界、Private DNS 整合；VNet Peering 的非傳遞式限制與 Gateway Transit 架構演進 |
/24 實得 251 個可用位址。有了網路疆域與連線路徑，下一道防線是：誰有權利穿越每一道城門？
明天進入 Day 12：Network Security Group (NSG) & Application Security Group (ASG)。我們將深入拆解 Inbound/Outbound 規則優先序（100–4096）、平台預設拒絕收口機制、狀態式封包追蹤，以及如何利用 ASG 告別手動維護 IP 清單的維運噩夢！
iThome鐵人賽
看影片追技術