【Day 18】Azure SQL Database & Managed Instance：關聯式資料庫選型與遷徙指南 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆（本篇為知識點加強版）
今日任務：在原本 Day 18 的架構上，補進更多技術細節，並用「假設讀者是 13 歲」的白話比喻（下文標示 🧒 ELI13）幫每個硬知識點做一層翻譯，讓你不只記得選哪個服務，還能想像它實際上在做什麼。

🎯 前言與今日目標

Day 17 我們用 Storage Explorer、AzCopy、Data Box 與 Database Migration
Service 把資料送到雲端。資料抵達只是遷徙的中場：真正會決定上線風險的，
是「這個 SQL Server 應該落在哪一種管理邊界？」如果把需要跨資料庫查詢的
舊系統硬塞進單一資料庫，切換當天才發現語法不能執行；如果為了相容性直接
搬到 VM，又會把修補、備份與高可用性責任全部帶回團隊。

今天 Titan 科技的 Chief Cloud Architect 要拆開 Azure SQL 家族的三層
抽象：Azure SQL Database 以資料庫為管理單位、Azure SQL Managed
Instance 以執行個體為管理單位、SQL Server on Azure VMs 則把
作業系統控制權交回客戶。目標不是背「哪個比較新」，而是從相容性、維運
責任、成本與故障半徑，選出能安全遷徙的邊界。

本篇加強版會在每一個原本的章節裡「多挖一層」——加入計價模型、服務層級、
業務持續性機制、進階安全功能等原本沒展開的細節，並且每個硬知識點旁邊都
會有一個 🧒 ELI13 的生活化比喻，讓你先抓到「大概在幹嘛」，再回頭看
技術名詞就不會覺得空洞。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Azure SQL 家族三層架構與選型決策圖

┌──────────────────────────────────────────────────────────────────┐
│             Azure SQL 家族：控制權與相容性的取捨                 │
├──────────────────────┬──────────────────────┬────────────────────┤
│ Azure SQL Database    │ SQL Managed Instance │ SQL on Azure VM   │
│ 單一資料庫（PaaS）   │ 執行個體（PaaS）     │ 整台 OS（IaaS）    │
├──────────────────────┼──────────────────────┼────────────────────┤
│ 新應用、彈性擴展     │ 舊 SQL Server 搬遷   │ 需要 OS 完整控制   │
│ 平台管修補與備份     │ 跨 DB、SQL Agent     │ 客戶管修補與 HA    │
└──────────────────────┴──────────────────────┴────────────────────┘
                              ▼
                先問：相容性需求 > 維運控制 > 成本模型

💡 架構師重點筆記：越往右，控制權與相容性越高，客戶承擔的維運
也越多。Azure SQL Database 是「資料庫即服務」的最小管理單位；Managed
Instance 把多個資料庫與執行個體層功能一起託管；VM 則是把 SQL Server
放進 IaaS，平台只管理 VM 基礎設施，資料庫與 OS 的生命週期由客戶負責。

🧒 ELI13 總覽：三種資料庫，就像三種「住的方式」

在往下看技術細節之前，先用一個比喻把三層架構釘進腦袋：

• Azure SQL Database = 住飯店房間。 房間裡的床單、水電、消防警報都
  有飯店員工固定來處理，你只要負責自己放進房間的東西（資料表、資料
  本身）。你沒辦法要求飯店把兩間房打通變成一間（跨資料庫查詢受限）。
• SQL Managed Instance = 租一整層公寓。 大樓的電梯、外牆、消防系統
  還是物業（平台）在管，但你租的這一整層裡面有好幾個房間（多個資料庫）
  可以互通，你也可以請自己的管家固定時間來打掃（設定 SQL Agent 排程），
  自由度比住飯店高很多。
• SQL Server on Azure VM = 買一整棟透天厝。 想怎麼裝潢都可以，但屋頂
  漏水、抓漏、保全系統統統要自己找人來處理——雲端只負責把「土地跟房子的
  骨架」（VM 基礎設施）準備好給你。

記住這個比喻，後面看到「相容性、維運責任、故障半徑」這些詞，都可以套
回「飯店 / 公寓 / 透天厝」重新理解一次。

1. Why：為什麼要拆成三種資料庫邊界？

關聯式資料庫的需求不只一個維度。新應用通常希望快速建立資料庫、按需
擴縮、由平台處理修補與自動備份；既有 SQL Server 卻可能依賴 SQL Agent、
Database Mail、跨資料庫查詢、連結伺服器或執行個體層設定。若平台只提供
一種「全託管」模型，不是犧牲舊系統相容性，就是迫使新應用承擔不必要的
OS 維運。

⚠️ 關鍵判斷：Azure SQL Database 不是「把 SQL Server 伺服器端搬進
PaaS」；它是以資料庫為管理單位的受管服務。若團隊需要 SQL Server
的執行個體相容性、代理程式或 OS 級控制，才應提升到 Managed Instance
或 SQL Server on Azure VM，不要把三者混成同一個抽象層。

Azure SQL Database 因此把隔離與擴展焦點放在資料庫；它適合雲原生應用，
也可放在 Elastic Pool 中，讓多個資料庫共享一組資源。SQL Managed Instance
則提供較接近 SQL Server 執行個體的表面，讓多個資料庫、代理程式與傳統
應用依賴可以在 PaaS 邊界內遷移。SQL Server on Azure VMs 保留最大的
相容性與 OS 控制，代價是客戶重新承擔修補、備份、監控、授權與高可用設計。

即使決定用同一種服務（例如都選 Azure SQL Database），還有一層常被忽略
的選擇：要用哪一種計價模型？ 這會直接影響成本結構、能不能用既有
授權折抵，甚至能不能用某些進階功能（例如 Hyperscale）。這是原本 Day 18
沒展開的部分，以下補上。

1.5【延伸】兩種計價模型：DTU vs vCore

Azure SQL Database（也包含 Elastic Pool）有兩種完全不同的「算錢方式」：

DTU（Database Transaction Unit）購買模型：把 CPU、記憶體、讀寫 I/O
綁在一起變成一個綜合分數，分成 Basic、Standard、Premium 三個層級——
Premium 層級的範圍大約是 125 到 4000 DTU，是低延遲 I/O 的高效能層級，
儲存上限約 4 TB，並支援記憶體內 OLTP（In-Memory OLTP）。你不能單獨只
加購儲存或只加購運算，只能整包升級或降級。

vCore（虛擬核心）購買模型：把運算與儲存拆開來算，你自己選要幾顆
虛擬核心、選硬體世代（例如 Standard-series／Gen5；舊的 Fsv2 系列將於
2026 年 10 月 1 日退役，Gen4 已經退役無法再佈建），再另外決定要買多少
儲存空間。vCore 模型還有兩個 DTU 模型完全沒有的好處：可以用Azure
Hybrid Benefit（把你手上既有的 SQL Server 授權拿來抵免運算費），以及
只有 vCore 才能買**預留容量（Reserved Instance）**換長期折扣。

vCore 底下又分兩種計算層級：

• Provisioned（佈建）：固定佔用一份運算資源，不管有沒有在跑查詢都
  持續計費，單價相對較低。
• Serverless（無伺服器）：你只設定一個運算資源的浮動範圍，平台會
  依照負載自動調整；閒置一段時間後會自動暫停，暫停期間只計儲存費，
  有活動再自動喚醒。但要注意：Serverless 目前只提供給單一資料庫，
  Elastic Pool 跟 Managed Instance 都用不到；而且 Serverless 的單價
  （以秒計費時）通常比 Provisioned 貴一些，喚醒也有延遲，並不是「凡是
  Azure SQL Database 都能像這樣自動休眠」。

🧒 ELI13：DTU 就像去吃合菜餐廳的「套餐」——飯、湯、主菜全部綁好，
套餐等級越高份量越大，但你不能只多加飯不加湯。vCore 則像「自助餐」，
你可以自己決定要幾份蛋白質（核心數）、要拿多少飯（儲存空間），兩邊
分開算錢；如果你自己帶了餐具（既有的 SQL Server 授權），甚至還能靠
Hybrid Benefit 打折。Serverless 更像一種「隨叫隨到」的外送——沒人點餐
的時候廚房先熄火（自動暫停），只留冰箱的電費（儲存費用）在跑，有人
點餐再重新開火，但重新開火需要一點暖機時間（喚醒延遲）。

參見 vCore purchasing model。

1.6【延伸】vCore 底下的三種服務層級：General Purpose / Business Critical / Hyperscale

選了 vCore 之後，還要再選一個服務層級，這三種層級的差異主要在「儲存
架構」跟「內建的高可用能力」：

• General Purpose（一般用途）：運算與儲存架構分離，資料放在遠端
  儲存體上（類似網路掛載硬碟），適合大多數一般商業負載，是最平衡、
  也通常是預設起點的選項。
• Business Critical（業務關鍵）：儲存直接掛在運算節點的本地 SSD
  上，效能與延遲更好，並且內建一個可讀取的次要複本（readable
  secondary replica），同時支援記憶體內 OLTP；代價是單價比 General
  Purpose 貴上不少。
• Hyperscale（超大規模）：把儲存架構徹底解耦，資料庫大小理論上可以
  從幾 GB 一路長到 128 TB，且與運算大小無關；可以設定 0 到 4 個
  高可用複本，另外還能建立最多 30 個具名唯讀複本（named replica）
  來分流讀取負載；備份與還原是用儲存快照技術完成，動輒 TB 等級的資料庫
  也能在幾分鐘內完成備份或還原，而不是傳統的數小時甚至數天。但
  Hyperscale 目前只提供給 Azure SQL Database，並不提供給 SQL Managed
  Instance；另外自 2023 年 12 月起，新建立的 Hyperscale 資料庫也不再
  支援 Azure Hybrid Benefit（只有既有的 Hyperscale 單一資料庫可以繼續
  沿用到 2026 年 12 月為止）。

🧒 ELI13：

• General Purpose 像住一般公寓，家具（資料）放在樓下共用倉庫，要用
  的時候搬上來，速度普通但夠日常使用。
• Business Critical 像頂樓景觀套房，家具（SSD）直接放在你家裡，拿取
  超快，而且大樓還自動幫你多準備一間一模一樣、隨時能接手的備用房間
  （內建可讀取的次要複本）。
• Hyperscale 則像是你家倉庫外接到一個「怎麼塞都塞不滿」的巨型自助
  倉儲（最大 128 TB），還可以另外複製出多達 30 個「唯讀分身房間」，
  讓別人查資料的時候不會吵到正在寫東西的你；搬家（備份/還原）也像
  拍立可拍照一樣秒出結果，不用真的把家具一件件搬走。但這棟巨型倉儲
  目前只租給「單一房間」（Azure SQL Database），公寓大樓（Managed
  Instance）的房客暫時還租不到。

參見 Hyperscale service tier。

2. Risk：選錯服務的代價

相容性風險：Azure SQL Database 不是「把任意 SQL Server 資料庫檔案
上傳」的容器。跨資料庫查詢、SQL Agent 或執行個體級設定若不受支援，
可能在測試環境以外才爆出錯誤。遷移前要用 Data Migration Assistant
或相容性評估盤點語法、代理程式、CLR、連結伺服器與外部相依。

維運風險：為了「一定相容」而選 VM，會把每月修補、備份還原演練、
Always On 拓撲、監控告警與故障切換的主要設計與驗證責任帶回 Titan 團隊。
Azure 仍提供 SQL IaaS Agent、Azure Backup 與 Azure Monitor 等整合能力；
VM 的自由不是免費的自由，而是更多 Runbook、權限與值班責任。

成本迷思：Provisioned compute 的 Azure SQL Database 不能像 VM 一樣
執行 deallocate 就讓運算費歸零；資料庫仍有儲存、備份與其他資源成本。
Serverless tier 可依設定在閒置後自動暫停並降低計算消耗，但它有適用層級、
恢復延遲與最小容量等條件，不能把「自動暫停」泛化成所有 SQL Database
都能隨時停止計費。

【延伸】相容性風險其實有解方，只是要多花設計成本：如果 Titan 團隊
擔心「先盤點、再切換」這種一次性大搬家的風險太高，其實還有一種折衷路
線——SQL Managed Instance Link。它底層用的是 Always On 可用性群組
延伸出來的「分散式可用性群組」技術，可以把地端 SQL Server（2016 版以後）
的資料近乎即時（near real-time）地持續複寫到 Managed Instance，
在正式切換之前，就能拿 Managed Instance 那一份先做唯讀測試、驗證效能，
確認沒問題之後才真正把流量切過去，中斷時間可以壓縮到「切換那一瞬間」
而已。它甚至支援反向操作——從 Managed Instance 把資料複寫回 SQL Server
2022 以後的版本，拿來做地端備援或是「切回地端」（failback）的保險。
值得特別記住的一點：這是目前唯一能對 Business Critical 層級做到
真正線上（online）、低停機遷移的方法；其他遷移工具通常只能把 General
Purpose 層級做得比較順暢。

🧒 ELI13：傳統搬家是「打包全部家具、切斷舊家水電、上車、到新家
才卸貨插電」，中間一定會有一段時間家裡沒水沒電（停機）。Managed
Instance Link 比較像「先在新家把家具一模一樣複製擺好（近即時複寫），
天天更新、天天測試，等新家住起來完全沒問題了，才『咻』一聲把門牌
和郵件轉寄地址換過去」——真正斷線的時間只有「換門牌」那一秒，而不是
整個搬家過程。這個功能不是免費的魔法，它需要來源端符合特定 SQL
Server 版本與版別（例如 Enterprise 或 Developer 版），本質上是用
「多一層複寫架構的複雜度」去換「幾乎零停機」。

參見 Managed Instance link overview。

3. Blast Radius：管理單位決定故障半徑

在 Azure SQL Database 中，單一資料庫的設定與資源隔離能把錯誤限制在較小
範圍；但應用若錯誤地跨資料庫耦合，仍會擴散到多個資料庫。Managed Instance
把多個資料庫放進同一個執行個體，能提升傳統相容性，卻也代表實例級資源、
網路與維護事件可能影響同一實例內的多個資料庫。VM 的爆炸半徑更大：OS
補丁、磁碟故障、錯誤防火牆規則或 SQL Server 設定可能同時影響整台主機。

防禦性設計是把邊界顯式化：生產資料庫分離測試資料庫；Managed Instance
按工作負載分組；VM 用可用性區域、備份保管庫、監控與最小權限降低整機風險。
不要用「資料庫有備份」取代「誰能刪除備份、能否跨區還原、切換後如何驗證」
這些問題。

3.5【延伸】把故障半徑拉大來看：業務持續性方案怎麼選

「備份」處理的是資料遺失的風險；但如果連整個 Azure 區域都出事（機房
斷電、天災），你需要的是**業務持續性（Business Continuity）**方案，
關鍵在兩個指標：

• RPO（Recovery Point Objective，復原點目標）：允許最多遺失多少
  「時間」的資料。
• RTO（Recovery Time Objective，復原時間目標）：允許系統中斷多久
  才恢復服務。

Azure SQL Database 有兩種跨區保護機制，容易搞混：

• Active Geo-Replication（主動地理複寫）：非同步複寫到另一個
  Region 的可讀取次要複本，RPO 大約 5 秒（最多可能遺失最後 5 秒的
  交易），但需要你自己手動觸發容錯移轉，觸發後大約 30 秒左右完成
  角色互換；因為是手動的，也常被拿來做資料庫遷移或應用程式升級時的
  過渡方案，不是只能用在災難復原。它不支援 Managed Instance，只能
  用在單一資料庫。
• Auto-Failover Group（自動容錯移轉群組）：在 Active Geo-Replication
  的基礎上再包一層，提供穩定不變的讀寫／唯讀監聽端點（容錯移轉後
  應用程式的連線字串不用改），並且能自動偵測中斷並自動容錯移轉——
  預設會有一段緩衝寬限期（常見設定約 1 小時，可自行調整）才會真的觸發
  自動切換，避免只是短暫網路抖動就誤判整個區域掛掉。RPO 同樣約 5 秒。
  重要的是，Failover Group 同時支援 Azure SQL Database 與 SQL
  Managed Instance，MI 想做跨區備援就是靠這個機制，而不是 Active
  Geo-Replication。

🧒 ELI13：Active Geo-Replication 就像你自己偷偷把作業複印一份寄放
在外地朋友家，如果家裡真的失火了，要「打電話拜託朋友現在就把備份
拿出來交作業」——是手動的，而且最壞情況可能少了你失火前最後 5 秒鐘
寫的字，朋友接手大概 30 秒內能搞定。Auto-Failover Group 則是升級版，
它幫你裝了一個「自動感應器＋郵局轉寄服務」：真的斷線超過一段觀察期
（避免只是停電 5 分鐘又恢復就誤判），它會自動打給朋友接手，而且大家
寄信到你家的地址完全不用改，因為郵局會自動把信轉寄到現在誰是「正牌
本人」那邊——這就是「監聽端點不變」的意思。

跨雲對照（方向性，非一對一）：AWS RDS 的 Multi-AZ（同區同步備援、
自動容錯移轉）比較接近 Business Critical 內建的次要複本；跨區的
唯讀複本（Read Replica）手動升級為主要則接近 Active
Geo-Replication 的手動特性；而 Aurora Global Database 的受管理
容錯移轉能力，方向上比較接近 Auto-Failover Group 的自動化程度——但這些
都只是概念對照，實際的 RPO/RTO 數字、限制與定價模型並不相同，考試與
實務設計都要各自查證。

參見 Active geo-replication overview
與 Failover groups overview。

4. AWS ↔ Azure：從受控資料庫到 OS 控制權

這是抽象層的方向性映射，不是名稱替換。RDS Custom 目前限定支援
Oracle 與 SQL Server 引擎；它在 OS／資料庫環境客製化能力上高於 SQL
Managed Instance。若需求是完整主機 OS 控制，Azure 的對照應改看 SQL
Server on Azure VM。RDS 的 engine、parameter
group、subnet group 與 Azure SQL 的 logical server、managed instance
subnet、firewall 規則並不共用設定格式；計價維度也一樣——AWS 的 Reserved
Instance 與 Azure 的 Reserved Capacity（vCore）在折扣曲線、承諾期間與
可轉換性上都有各自的規則，不能直接套用彼此的試算表。AWS CDK/CloudFormation
或 Azure Bicep/ARM 能把資源宣告版本化，但 cdk synth 產生 CloudFormation
與 bicep build 產生 ARM JSON，最後仍由各自的控制平面驗證配額、網路與
服務限制；IaC 不會自動消除相容性測試。

5. 連線與防禦性架構：不要只換 CNAME

Azure SQL Database 通常透過 logical server 的 FQDN 連線；應用程式不應
硬編碼 IP，而應由受保護的連線字串與秘密管理流程取得端點。SQL Managed
Instance 使用專用網路整合與委派子網路；SQL Server on Azure VM 則要
自行設計 NSG、負載平衡、SQL 連接埠與作業系統防火牆。

三層服務都應把安全當成控制面與資料面的組合；其中 SQL Server on Azure VM
的 TDE 由 SQL Server 層設定與維運，不應直接套用 Azure SQL PaaS 的管理假設：

• 靜態資料：Azure SQL Database 與 Managed Instance 的 Transparent Data
  Encryption（TDE）提供
  儲存加密；若要求客戶管理金鑰，使用 Key Vault 與受限的金鑰生命週期。
• 身分：優先使用 Microsoft Entra ID 驗證、受控身分與最小 RBAC，
  不把 SQL 密碼寫進原始碼、Pipeline 變數或 VM 映像。
• 網路：SQL Database 可用 Private Endpoint；但建立 Private Endpoint
  不會自動封鎖公網路由，若目標是只允許私有入口，還要啟用
  Deny public network access，並搭配防火牆規則。Managed Instance 以委派
  子網路和私有連線為核心；VM 需要自行封鎖公網 RDP/SQL 連接埠並限制來源。
  參見 Azure SQL Private Link。
• 變更：以 Bicep/ARM 或 Terraform 管理可審查的設定，部署前執行
  What-If；AWS 對應 Change Sets。連線端點切換也要先做健康檢查與回復計畫。

5.5【延伸】進階威脅偵測與資料保護：Microsoft Defender for SQL 全家桶

TDE 跟 Private Endpoint 只解決了「資料靜態時有沒有加密」跟「網路能不能
被外面連到」，但還有兩類問題沒解決：有沒有人正在攻擊你、以及
就算有權限進來的人，能看到多少敏感資料。這就是下面這組功能的用途：

• Microsoft Defender for SQL：是一個套裝方案，裡面包含
  Vulnerability Assessment（弱點評估）——掃描設定錯誤、缺補丁、
  過度授權等問題並給出可執行的修補建議；以及 Advanced Threat
  Protection（進階威脅防護）——持續監控資料庫，偵測 SQL Injection
  攻擊嘗試、異常登入模式（例如短時間大量失敗登入、疑似暴力破解）、
  可疑的資料存取行為，並把警示整合進 Microsoft Defender for Cloud
  主控台。它同時涵蓋 Azure SQL Database、Managed Instance、Synapse
  Analytics、SQL Server on Azure VM，甚至透過 Azure Arc 涵蓋地端 SQL
  Server。
• Dynamic Data Masking（動態資料遮罩）：對信用卡卡號、電話號碼等
  欄位，在查詢結果顯示層面對低權限使用者做遮罩（例如只顯示卡號
  末四碼），但資料庫裡實際儲存的資料完全沒被改動。
• Row-Level Security（資料列層級安全性）：讓不同使用者查詢同一張
  表時，只能看到符合特定條件（例如自己負責的客戶）的資料列，其餘列
  會自動被過濾掉，不需要為每個角色另外複製一份表。
• Always Encrypted：一種用戶端加密機制，加密金鑰完全不會交給資料庫
  引擎或雲端維運人員，就算是資料庫管理員或雲端平台本身也看不到明文，
  只有持有正確金鑰的應用程式才解得開。
• Ledger（分類帳）：為資料表加上密碼學層級的「防竄改證明」，事後
  可以驗證歷史資料是否曾被偷偷竄改，概念類似區塊鏈的雜湊鏈。

🧒 ELI13：

• Microsoft Defender for SQL 就像幫房子裝一整組保全系統——先請一位
  管家檢查「窗戶鎖好了沒、密碼是不是太簡單」（弱點評估），再裝一台
  24 小時監視器，只要有人一直轉門把想硬闖（暴力破解登入）或想從窗戶
  縫塞奇怪的東西進來（SQL Injection），就馬上跳出警報通知你。
• Dynamic Data Masking 就像信用卡帳單上印出來的卡號只留後四碼、
  其他打星號——但銀行電腦裡真正存的卡號一個字都沒被改，只是「顯示
  給你看」的那一份被打了馬賽克。
• Row-Level Security 就像全公司共用同一份 Excel 客戶清單，但每個
  業務員打開來，畫面上就是只看得到自己負責的那幾列客戶，其他人的
  資料根本不會顯示出來，不用另外複製檔案給每個人。
• Always Encrypted 更狠一點：連保管員（資料庫管理員、雲端維運人員）
  都打不開的密碼鎖抽屜，只有拿到正確鑰匙的那個應用程式自己才解得開，
  等於「連房東都進不去房客的保險箱」。
• Ledger 就像在筆記本每一頁蓋一個防偽鋼印，事後如果有人偷改內容，
  鋼印圖案就會對不上，馬上被抓包，沒辦法神不知鬼不覺地竄改歷史紀錄。

參見 Microsoft Defender for SQL
與 Azure SQL security overview。

cxcxc-io 圖 10 / 圖 17：應用層到資料庫層的端點切換

cxcxc-io 的 AWS 架構觀點把 Route 53、CloudFront、ELB/ALB 與 EC2
應用層串到 RDS；多個 RDS 可透過 CNAME 做端點切換。以下是忠實保留
AWS 側分層、再加入 Azure 對照的精簡圖。Azure 的 Failover Group
listener 是服務提供的邏輯端點，不等於把 Route 53 或 RDS CNAME 原封不動
搬過來——這也呼應前面 3.5 節提到的重點：Auto-Failover Group 的價值正是
在容錯移轉後不需要應用程式重新指向新的 CNAME 或 IP。

┌──────────────────────────────────────────────────────────────────┐
│ AWS 側：圖 10 / 17 的端到端資料路徑（架構觀點）                  │
├──────────────────────────────────────────────────────────────────┤
│ Route 53 → CloudFront → ALB → EC2 / ECS                          │
│                              ├→ ElastiCache                      │
│                              └→ RDS CNAME → Primary DB           │
├──────────────────────────────────────────────────────────────────┤
│ Azure 對照（非一對一拓撲）：App Service / VM                     │
│                              └→ SQL DB / MI listener             │
│                                 → Failover Group 端點            │
└──────────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io/README.md 圖 10
與圖 17（AWS 側對照圖），已用 Azure SQL Database / Managed Instance
的端點與 Failover Group 概念調整；不可視為 Azure 原生拓撲的一對一複製。

📖 AZ-900 核心名詞解釋與速查（加強版：新增 5 個延伸考點）

1. Azure SQL Database

   • 定義：Microsoft Azure 的完全受控關聯式資料庫 PaaS，平台負責
     引擎基礎維運、備份與修補；資料庫是主要管理單位。
   • AWS 對照：Amazon RDS 的受控關聯式資料庫思維。
   • 考點：新應用與單一資料庫需求優先考慮；跨 DB 或執行個體功能要先做相容性檢查。

2. Azure SQL Managed Instance

   • 定義：受控 SQL Server 執行個體，提供較高的 SQL Server 相容性，
     可承載多個資料庫與部分執行個體層功能。
   • AWS 對照：RDS Custom 的「保留更多傳統相容性」方向性對照；
     RDS Custom 僅支援 Oracle 與 SQL Server，並非 SQL MI 的等價服務。
   • 考點：適合既有 SQL Server Lift-and-shift，但仍受支援功能與網路條件限制。

3. SQL Server on Azure VMs

   • 定義：在 Azure 虛擬機器上執行 SQL Server 的 IaaS 方案，客戶
     管理 OS、SQL Server 設定、修補、備份與高可用性。
   • AWS 對照：在 EC2 上自架 SQL Server。
   • 考點：需要 OS 層控制或特殊相容性時使用，不代表維運責任消失。

4. Elastic Pool（彈性集區）

   • 定義：讓多個 Azure SQL Database 共享一組計算資源的配置模型，
     適合各資料庫尖峰時間不同、但總體資源可共用的工作負載。
   • 考點：集區共享資源也共享容量邊界；單一資料庫失控可能擠壓其他資料庫。

5. Transparent Data Encryption (TDE，透明資料加密)

   • 定義：在儲存層對資料庫檔案、備份與交易記錄進行靜態資料加密，
     應用程式通常不需改變資料格式。
   • AWS 對照：RDS encryption at rest 的方向性概念。
   • 考點：TDE 保護靜態資料，不等於網路隔離、身分授權或秘密管理。

6. DTU vs vCore 購買模型

   • 定義：DTU 是把 CPU/記憶體/I/O 綁成一個綜合分數的固定套餐；
     vCore 讓運算與儲存分開計費，並提供 Provisioned／Serverless 兩種
     計算層級，也是唯一支援 Azure Hybrid Benefit 與 Reserved Capacity
     的模型。
   • 考點：想用既有授權折抵，或想用 Hyperscale／Serverless，都必須
     先選 vCore；DTU 沒有這些選項。

7. Hyperscale 服務層級

   • 定義：vCore 底下的服務層級之一，儲存架構完全解耦，單一資料庫
     最大可達 128 TB，支援快照式的秒級備份/還原，並可建立最多 30 個
     具名唯讀複本。
   • 考點：目前僅提供給 Azure SQL Database，不提供給 Managed
     Instance；2023 年 12 月後新建的 Hyperscale 資料庫不再支援 Azure
     Hybrid Benefit。

8. Auto-Failover Group（自動容錯移轉群組）

   • 定義：在 Active Geo-Replication 之上提供穩定監聽端點與自動
     容錯移轉能力的業務持續性機制，RPO 約 5 秒、預設約 1 小時的觀察
     寬限期後才會自動切換。
   • AWS 對照：方向上接近 Aurora Global Database 的受管理容錯移轉，
     但非等價服務。
   • 考點：同時支援 Azure SQL Database 與 Managed Instance；Active
     Geo-Replication 則只支援 Azure SQL Database 的單一資料庫。

9. SQL Managed Instance Link

   • 定義：以 Always On／分散式可用性群組技術，讓地端 SQL Server
     與 Managed Instance 之間近乎即時地持續複寫資料，用於低停機遷移或
     混合式讀取分流，也支援反向複寫回 SQL Server 2022 以後版本。
   • 考點：是目前唯一能對 Business Critical 層級做到真正線上遷移
     的方法。

10. Microsoft Defender for SQL

    • 定義：整合 Vulnerability Assessment（弱點評估）與 Advanced
      Threat Protection（進階威脅防護）的安全套件，涵蓋 Azure SQL
      Database、Managed Instance、Synapse 與 SQL Server on Azure VM。
    • 考點：偵測異常存取與 SQL Injection 等威脅，屬於「監控與偵測」
      層，不能取代 TDE（靜態加密）或 Private Endpoint（網路隔離）的
      角色，三者要一起設計。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的關聯神殿搬遷挑戰

Titan 科技要把地端訂單系統搬到 Azure。系統使用 SQL Server Agent
排程、跨資料庫查詢、Database Mail 與多個既有資料庫；CTO 的要求很明確：
「不要大改 code，但要有 PaaS 自動備份與修補，並且讓我們能用私有網路
連線。」Chief Cloud Architect 必須在週末切換前完成相容性盤點、網路設計、
備份還原演練與配額確認。

🧩 決策任務

• A：Azure SQL Database。它是最標準的 PaaS，因此所有 SQL Server
  應用都應直接搬進一個 database。
• B：SQL Managed Instance。以受控執行個體承接多資料庫與較高相容性，
  同時保留平台的修補、備份與高可用能力。
• C：SQL Server on Azure VM。雖然要自己管理 OS，但只要相容性最高，
  就能滿足 CTO 的 PaaS 維運要求。
• D：Cosmos DB。把關聯式資料改成 NoSQL，才能獲得最好的雲端擴展性。

🎯 解題拆解與解析

✅ 正解：B。 題幹的關鍵字是「SQL Agent、跨資料庫查詢、多個既有資料庫、
少改 code、仍要 PaaS」。Managed Instance 的管理單位接近傳統 SQL Server
執行個體，正好在相容性與託管維運之間取得平衡；但正式遷移仍須以 DMA、
支援矩陣與實際測試確認，不能把「高相容性」誤讀成無條件 100% 相容。

❌ A 的陷阱：Azure SQL Database 是 PaaS，但「PaaS」不是功能相容性的
保證。單一資料庫邊界可能無法承接執行個體級排程與跨資料庫依賴，直接選用
會把問題延後到整合測試或正式切換。

❌ C 的陷阱：VM 的確提供最大的 OS 與引擎控制權，但修補、備份、監控、
Always On、容量與故障切換都由 Titan 負責。它符合相容性優先的 IaaS，而
不符合 CTO 指定的 PaaS 維運邊界。

❌ D 的陷阱：Cosmos DB 是 NoSQL 平台，資料模型、查詢能力與一致性
選擇都不同；將成熟關聯式訂單系統強行改模，等同另開一個重寫專案，不是
這次要求的低風險 Lift-and-shift。

🧩【延伸任務】週末切換之後，CTO 的下一個問題

方案 B 拍板之後，CTO 接著問了一個更深的問題：「如果 Titan 所在的 Azure
區域整個掛掉（機房斷電、天災級別的中斷），我們的訂單資料庫要多快恢復？
最多可以接受掉多少資料？」

• A：什麼都不額外設定，出事再用每日備份還原（可能遺失接近一整天的
  資料，還原時間也可能是數小時起跳）。
• B：幫這個 Managed Instance 設定 Failover Group，在另一個
  Region 建立次要執行個體。
• C：幫這個 Managed Instance 設定 Active Geo-Replication，
  複寫到另一個 Region。
• D：乾脆放棄 Managed Instance，改用 SQL Server on Azure VM 自己
  跨區架設 Always On Availability Group。

✅ 正解：B。 這題的重點是「Managed Instance 沒有 Active
Geo-Replication 這個選項」——Active Geo-Replication 是設計給 Azure SQL
Database 的單一資料庫（logical server）使用的功能，Managed Instance 要
做跨區保護，機制是 Failover Group（MI 版本），一樣能提供自動容錯
移轉與穩定的監聽端點。

❌ C 的陷阱：這是最容易誤選的選項，因為「Active Geo-Replication」
聽起來很像通用的跨區複寫功能，但它實際上不支援 Managed Instance，選了
在建立階段就會失敗。

❌ A 的陷阱：每日備份還原不是業務持續性方案，RPO/RTO 都遠遠達不到
一般正式環境的要求，只適合當作最後一道防線，不能取代跨區保護機制。

❌ D 的陷阱：為了跨區備援放棄 Managed Instance 的 PaaS 維運優勢，
等於把原本 Day 18 一開始就想避免的「OS 級維運責任」又背了回來，是過度
工程化的選擇。

🧒 ELI13：這一題就像是「我住在公寓大樓（Managed Instance），
想在別的城市也留一份備用房間」——大樓物業（Azure）確實有提供「跨城市
備用房間」的服務，但那個服務的正式名稱叫「Failover Group」，而不是
「Active Geo-Replication」；後者其實是只租給「獨棟飯店房間」（Azure
SQL Database 的單一資料庫）的服務，公寓房客申請不到。

🎯 Part 3：AZ-900 精選高頻真題解析（加強版：新增 3 題）

本節題目全部改寫為 Titan 情境，不複製題庫原文。ExamTopics 是社群題型
參考，不是 Microsoft 官方題庫；本文不把未經現場讀取的票數當成技術證據，
每個答案均以 Microsoft Learn 的現行文件與下方摘錄交叉驗證。

📝 真題 1：PaaS 與 IaaS 的服務模型辨識（ExamTopics Q41 / Q319 考點改寫）

Titan 要建立新的交易 API，希望平台處理 SQL 引擎的修補、備份與基礎高可用；
另一個團隊需要管理 Windows Server 與 SQL Server 的自訂驅動。哪一組配對
最合理？

• A：兩者都使用 SQL Server on Azure VMs。
• B：前者使用 Azure SQL Database，後者使用 SQL Server on Azure VMs。
• C：前者使用 VM，後者使用 Azure SQL Database。
• D：兩者都使用 Cosmos DB。

答案：B。 關鍵字「平台處理引擎維運」指向 PaaS；「管理 OS 與自訂驅動」
指向 IaaS。A 讓新 API 承擔不必要的 OS 維運，C 顛倒抽象層，D 改變了
關聯式資料模型。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 41 與 Question 319（Azure SQL 服務模型與 PaaS vs IaaS 邊界高頻考點）；Microsoft Learn 將 Azure SQL Database 定義為「fully managed platform as a service (PaaS) database」，而 SQL Server on Azure VM 屬 IaaS。逐一排除 A、C、D 後，答案與官方服務邊界一致，參見
  Azure SQL Database overview
  與 SQL Server on Azure VMs。

📝 真題 2：Managed Instance 配額不足的處理方式（ExamTopics Q106 考點改寫）

Titan 在新訂用帳戶建立 SQL Managed Instance 時收到「目前區域的配額不足」
訊息。CTO 要求透過正式支援管道提高限制。應採取哪一項行動？

• A：刪除 Resource Group，重新建立同名資源。
• B：建立 Azure Support Request，申請檢視並提高相關配額。
• C：把 SQL Server 改成 Cosmos DB。
• D：在應用程式中重試部署直到成功。

答案：B。 配額是訂用帳戶與區域層級的服務限制，不是刪除資源或重試
就能消失的部署錯誤。Support Request 才是讓 Microsoft 檢視限制與需求的
正式管道；實務上仍要先檢查區域、目前用量與服務可用性。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 106（提高 Azure 訂用帳戶配額限制高頻題型）與 2020 年 gratisexam 題庫 Q85（SQL Managed Instance 資源上限申請）；官方限制文件說明訂用帳戶與服務有配額／限制；Support Request 是提交檢視與申請提高限制的正式流程。A、C、D 都不會改變訂用帳戶配額，因此答案與官方流程一致，參見
  Azure subscription and service limits
  與 Create an Azure support request。

📝 真題 3：運算停止與計費邊界（ExamTopics Q324 考點改寫）

測試環境使用 provisioned Azure SQL Database。工程師想仿照 VM 執行
deallocate，期待運算費立即停止；架構師應如何判斷？

• A：所有 Azure SQL Database 都能 deallocate，且所有費用歸零。
• B：Provisioned database 沒有 VM 式 deallocate；若符合條件可評估
  serverless auto-pause，但儲存與其他資源費用仍須檢查。
• C：只能把資料庫移到 Cosmos DB 才能停止計費。
• D：開啟 TDE 後資料庫會自動停止。

答案：B。 題幹把 VM 的生命週期命令誤套到 PaaS。Serverless compute
有自動暫停與喚醒模型，但不是任意資料庫的手動 deallocate，也不代表
儲存、備份、網路或其他項目都免費。成本設計要看服務層級與實際計費明細。

• 來源與驗證：改寫自 ExamTopics AZ-900 Topic 1 Question 324（Azure SQL 運算暫停/停止與計費邊界高頻考點）。Microsoft Learn 明確寫明 Serverless 是「for single databases」的 compute tier，會依秒計算並在閒置時自動暫停、只計儲存，不是 provisioned database 的 VM 式 deallocate。A、C、D 分別把條件、服務邊界或 TDE 功能混淆，參見
  Serverless compute tier
  與 Azure SQL pricing。

📝 真題 4：PaaS 遷移下的服務組合（2020 gratisexam 題庫 Q4/Q5 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q4 與 Q5 題型，屬歷史題庫層，已與 Microsoft Learn 交叉驗證；舊題庫中的服務名稱與能力若與現行文件衝突，以現行文件為準。

Titan 想把新 Web 應用的關聯式資料庫交給 Azure 維運，同時把舊 SQL Server
工作負載保留較高相容性。哪一組服務方向正確？

• A：新應用用 Azure SQL Database；舊系統評估 SQL Managed Instance。
• B：新應用與舊系統都用 SQL Server on Azure VMs，才能取得 PaaS。
• C：兩者都改用 Cosmos DB。
• D：新應用用 Storage Explorer；舊系統用 AzCopy。

答案：A。 Azure SQL Database 適合新應用的受控 PaaS 邊界；Managed
Instance 適合需要執行個體級相容性的遷移。VM 是 IaaS，不會因為 SQL
Server 已安裝就變成 PaaS；Storage Explorer 與 AzCopy 是儲存體資料平面
工具，不能取代關聯式資料庫服務。

• 來源與驗證：改寫自 2020 年 gratisexam AZ-900 題庫 Q4/Q5 題型；以現行 Azure SQL 服務邊界重新編寫，並經 Microsoft Learn：Azure SQL deployment options 交叉驗證。

📝 真題 5：透明資料加密的保護範圍（2020 gratisexam 題庫 Q78 改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q78 資料保護題型，屬歷史題庫層，已依 Microsoft Learn 現行文件重寫；不沿用可能過時的服務名稱或答案敘述。

Titan 要保護 Azure SQL Database 的資料檔案、備份與交易記錄，並詢問 TDE
是否同時負責網路隔離與登入授權。哪個判斷正確？

• A：TDE 保護靜態資料；網路隔離與登入授權仍要另行設計。
• B：TDE 會自動封鎖所有公網連線，因此不需要 Private Endpoint。
• C：TDE 會取代 Microsoft Entra ID 驗證與 RBAC。
• D：TDE 只加密應用程式送出的欄位，不處理資料庫檔案。

答案：A。 TDE 的責任是靜態資料加密；它不會自動建立網路邊界，也不會
取代身分驗證、授權或秘密管理。B、C 把不同控制面能力混為一談，D 則把
資料庫儲存層加密誤寫成欄位加密。

• 來源與驗證：改寫自 2020 年 gratisexam AZ-900 題庫 Q78 資料保護考點；本題只保留 TDE 的考點並以現行文件逐選項核對。參見
  Transparent data encryption
  與 Azure SQL security overview。

📝【新增】真題 6：計價模型與既有授權的搭配

Titan 手上有大量既有的 SQL Server Enterprise 授權尚未到期，也希望用長期
承諾換取運算折扣。架構師應該建議哪一種計價模型？

• A：DTU，因為設定介面比較簡單。
• B：vCore，因為只有 vCore 支援 Azure Hybrid Benefit 與 Reserved
  Capacity 折扣。
• C：兩種模型在授權折抵與長期折扣上完全一樣，選哪個都無所謂。
• D：改用 Hyperscale 的 DTU 版本，一次拿到兩種好處。

答案：B。 「既有授權折抵」對應 Azure Hybrid Benefit，「長期承諾換
折扣」對應 Reserved Capacity，這兩項都只在 vCore 購買模型下才存在。

❌ D 的陷阱：Hyperscale 是 vCore 底下的服務層級，並不存在「DTU 版本
的 Hyperscale」，這個選項混淆了兩個不同維度（購買模型 vs 服務層級）。

• 來源與驗證：本題為改編情境，核對現行文件對 vCore 模型福利的描述，
  參見 vCore purchasing model。

📝【新增】真題 7：Hyperscale 的服務邊界

Titan 有一個 90 TB 的歷史交易資料庫，想搬進 Managed Instance 並使用
Hyperscale 服務層級，藉此同時拿到「高相容性」與「巨量儲存」兩個好處。
這個計畫可行嗎？

• A：可行，Hyperscale 目前對所有 Azure SQL 系列服務一視同仁。
• B：不可行，Hyperscale 目前只提供給 Azure SQL Database，尚未提供
  給 SQL Managed Instance。
• C：可行，但必須先把購買模型切回 DTU 才能啟用。
• D：不可行，因為 Hyperscale 的儲存上限只有 4 TB，90 TB 根本放不下。

答案：B。 這是本篇反覆強調的重點：Managed Instance 目前無法使用
Hyperscale 服務層級，兩種「高相容性」與「巨量儲存」的優勢暫時無法同時
兼得，若堅持要用 Managed Instance，就必須另外設計儲存擴充或分庫策略。

❌ C 的陷阱：Hyperscale 只存在於 vCore 模型底下，跟 DTU 完全無關，
方向反了。

❌ D 的陷阱：4 TB 是 DTU 購買模型中 Premium 層級的儲存上限，跟
Hyperscale 最大 128 TB 的儲存能力是兩件事，這題故意把兩個數字互換來
考驗有沒有真的分清楚。

• 來源與驗證：核對 Hyperscale 現行文件，參見
  What is the Hyperscale service tier?。

📝【新增】真題 8：業務持續性方案的正確選擇

Titan 需要為正式環境的 Azure SQL Database 建立一個「跨區域、可以自動
容錯移轉、且容錯移轉後應用程式連線字串不需要更改」的方案。應該選擇
哪一項？

• A：Active Geo-Replication，因為它可以把資料複寫到另一個 Region。
• B：Auto-Failover Group，因為它提供穩定的監聽端點並支援自動容錯
  移轉。
• C：Transparent Data Encryption，因為它能保護資料安全性。
• D：Elastic Pool，因為它可以在多個資料庫之間分散流量。

答案：B。 題幹的兩個關鍵字「自動容錯移轉」與「連線字串不需要更改」
剛好對應 Auto-Failover Group 的兩大特性。

❌ A 的陷阱：Active Geo-Replication 雖然也能跨區複寫，但需要手動
觸發容錯移轉，而且沒有提供不變的監聽端點，應用程式在切換後可能需要
自行改接目標資料庫。

❌ C、D 的陷阱：TDE 屬於資料加密範疇，Elastic Pool 屬於資源共享與
成本最佳化範疇，兩者都與跨區業務持續性無關。

• 來源與驗證：核對現行文件對兩種機制差異的描述，參見
  Failover groups overview
  與 Active geo-replication overview。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

架構師收斂心法

先辨認「資料庫管理單位」再談產品：單一 DB 對應雲原生 PaaS；執行個體
對應傳統相容性；VM 對應 OS 控制。接著確認三個問題：是否需要跨 DB 或
Agent？是否能接受平台限制？團隊是否真的有能力維護 OS、備份與故障切換？
如果答案牽涉到「跨區域自動容錯移轉」，記得回頭檢查是要用
Active Geo-Replication（手動、僅限單一資料庫）還是 Auto-Failover
Group（自動、SQL DB 與 MI 都支援）——這是本篇加強版新增、也是最容易在
情境題裡被拿來混淆的一組概念。

┌──────────────────────────────────────────────────────────────────┐
│                 雙雲關聯式資料庫快速判斷矩陣                     │
├────────────────────┬──────────────────────┬──────────────────────┤
│ 新應用 / 單一 DB    │ 舊 SQL / 多 DB       │ OS / 引擎全控制     │
│ RDS / Azure SQL DB  │ RDS Custom / SQL MI* │ EC2 / Azure VM      │
├────────────────────┼──────────────────────┼──────────────────────┤
│ 先看 PaaS 生產力   │ 先看相容性與私網     │ 先看維運能力與 HA    │
└────────────────────┴──────────────────────┴──────────────────────┘

* RDS Custom 與 SQL Managed Instance 只是在遷移意圖與 SQL Server
相容性上作方向性比較；RDS Custom 的 OS 控制能力較高，不能視為 SQL MI
的等價服務。

經典情境一：跨資料庫交易與排程搬遷

情境題目（SAA-C03 考點改編）：Titan 的舊訂單系統在同一個 SQL Server
執行個體內跨資料庫交易，並以 SQL Agent 執行每日結算。團隊不想管理 OS，
但不能先重寫所有作業。AWS 與 Azure 各應優先評估哪個方向？

┌──────────────────────────────────────────────────────────────────┐
│ 需要跨 DB + SQL Agent？                                          │
│              ├─ 否 → RDS / Azure SQL Database                    │
│              └─ 是 → RDS Custom / SQL Managed Instance           │
│                         └─ 仍需 OS 特權 → EC2 / Azure VM         │
└──────────────────────────────────────────────────────────────────┘

解析：RDS Custom 與 SQL Managed Instance 是方向性對照，兩者都要逐項
核對引擎版本、功能支援與網路需求；若還需要自訂 OS 驅動、特殊代理程式或
完整 sysadmin 控制，才把邊界退回 EC2 或 Azure VM。關鍵不是「相容性最高」
四個字，而是把未支援功能列成遷移阻擋條件，先在非生產環境驗證交易、排程、
備份還原與故障切換——如果團隊擔心一次切換風險太高，前面 2. Risk 小節
提到的 Managed Instance Link 近即時複寫，正好可以在正式切換前先讓
新環境跑一段時間的唯讀驗證。

經典情境二：高併發與資料庫擴展模式

情境題目（CLF-C02 / SAA-C03 考點改編）：遊戲活動流量白天暴增、
夜間大幅下降，應用希望減少閒置計算；另一個 SaaS 產品有數百個小型
資料庫，尖峰時間彼此錯開。應如何比較 AWS 與 Azure？

┌──────────────────────────────────────────────────────────────────┐
│ 負載是否可預測？                                                 │
│   ├─ 波動且可接受喚醒延遲 → Aurora Serverless / SQL Serverless   │
│   └─ 多租戶尖峰錯開       → RDS DB instance / Azure Elastic Pool │
└──────────────────────────────────────────────────────────────────┘

解析：Serverless 是按需求調整計算的模式，不是所有資料庫都能零成本
休眠；Aurora Serverless v2 與 Azure SQL Database Serverless 是概念相近、
非產品等價，前者不應直接理解為可自動暫停至零 ACU。要把喚醒延遲、最小
容量、連線池與儲存費用納入測試——別忘了 Azure 這邊的 Serverless 目前
只能用在單一資料庫，Elastic Pool 與 Managed Instance 都不適用。
Elastic Pool 則讓多個 Azure SQL Database 分享資源（不適用於 SQL Managed
Instance），適合尖峰錯開，但要設定每庫上限，避免單一租戶搶光集區。若
工作負載長時間穩定，固定配置（Provisioned）可能更容易預測；不要只因為
「Serverless」名稱就假設一定更便宜。

雙雲考場口訣：

新應用單一 DB：RDS ↔ Azure SQL Database

舊系統執行個體相容：RDS Custom ↔ SQL Managed Instance

需要 OS 控制：EC2 SQL ↔ SQL Server on Azure VM

波動計算要看喚醒；多庫尖峰錯開才想 Elastic Pool

跨區自動切換找 Failover Group；手動切換才是 Active Geo-Replication

📐 Part 4：以戰代訓課程對照

⚠️ 課程空白日警語：Day 18 是課程對照表列出的空白日，且新考綱
已淡化資料庫服務的比重。本文以 Microsoft Learn 現行文件與 RPG 素材
補足選型與遷移理解，應把它當成架構判斷與跨雲對照，不要誤當成課程
已涵蓋的高權重單元。

🚀 今日總結與明日預告

🏆 今日重點速記（加強版：6 點）

1. Azure SQL Database 是單一資料庫 PaaS；SQL Managed Instance
   是較高相容性的執行個體 PaaS；SQL Server on Azure VMs 才是 OS
   與引擎都由客戶掌握的 IaaS——套用開頭的比喻，分別是飯店房間、租一整
   層公寓、買一整棟透天厝。
2. 選型先看跨 DB、SQL Agent、OS 控制與相容性，再看成本；Provisioned
   SQL Database 不能用 VM 式 deallocate，Serverless auto-pause 也只在
   單一資料庫、且有喚醒延遲等條件。
3. 計價模型要分開想：DTU 是綁定套餐，vCore 才能拆開算、才能用 Azure
   Hybrid Benefit 與 Reserved Capacity；vCore 底下的 General
   Purpose／Business Critical／Hyperscale 三個層級，決定的是儲存架構
   與內建高可用能力，其中 Hyperscale 目前不支援 Managed Instance。
4. 業務持續性不是只有「有備份」：Active Geo-Replication（手動、僅
   Azure SQL Database）與 Auto-Failover Group（自動、SQL DB 與 MI
   皆支援、監聽端點不變）是兩種不同層級的跨區保護，RPO 都約 5 秒，但
   RTO 與觸發方式完全不同。
5. 若擔心一次性遷移風險過高，SQL Managed Instance Link 可以先做近即時
   複寫、驗證無誤再切換，是目前唯一能對 Business Critical 層級做到真
   正線上遷移的方式。
6. TDE、Private Endpoint、Entra ID 與 Key Vault 要一起設計，再疊上
   Microsoft Defender for SQL（威脅偵測）、Dynamic Data
   Masking／Row-Level Security／Always Encrypted（資料層防護）與
   Ledger（防竄改證明），才是完整的縱深防禦；端點切換、配額申請、
   備份還原與故障演練，才是安全遷移的一部分。

🔮 明日預告：Day 19 Azure Cosmos DB

關聯式資料庫的邊界清楚後，Titan 下一個問題是：如果資料結構變動快速，
又要在全球多個 Region 低延遲讀寫，還要不要堅持 SQL？明天進入 Azure
Cosmos DB 全球分散式 NoSQL，對照 AWS DynamoDB 的資料模型、分割與一致性。