SaaS、PaaS 與 IaaS：你使用服務，也接下哪些責任

社區教室要讓學員在線上報名，廠商提出三份方案：訂閱現成報名工具、把客製程式放上平台，或租一台雲端主機。三份都能叫做雲端服務，後續工作卻差很多。選方案前，先確認教室想維護的是課程資料、程式，還是連主機系統都要管理。

本文以原創教室情境拆解 SaaS、PaaS 與 IaaS，依 2026 年 9 月 14 日查閱的 NIST、Microsoft 與 AWS 一手文件整理。沒有實際購買或部署服務，也不替特定廠商排名；文中的責任表是討論工具，正式分工仍須回到所選服務與合約。

先看自己拿到哪一層控制權

SaaS 是 Software as a Service，使用者直接使用供應商提供的應用程式。例如教室在現成報名工具內建立課程、管理學員和設定通知，不必自己安裝伺服器作業系統。能調整的功能範圍由服務決定，某個特殊候補規則未必能自由改寫。

PaaS 是 Platform as a Service，供應商提供執行應用程式的平台，使用者部署自己開發或取得的程式。本例若請工程師製作報名流程，便可將程式交給平台執行。平台處理的底層維護較多，但課程邏輯寫錯、套件有漏洞或程式設定不當，仍需要有人修正。

IaaS 是 Infrastructure as a Service，使用者取得運算、儲存和網路等基礎資源，可以控制虛擬主機的作業系統與安裝軟體。這讓特殊需求較有調整空間，也增加更新、監控和故障排除工作。供應商管理實體設備，不代表會替教室修好自行安裝的報名程式。

服務類型不等於一整家公司

NIST 用這三種類型描述服務提供到哪一層，另外還區分公有、私有等部署方式。它們回答的問題不同，因此不能把私有雲直接當成 IaaS，也不能認定有手機 App 就一定是某種服務。判斷時讀該項產品的實際功能，品牌名稱本身不足以決定分類。

同一套報名系統也可能混用：教室使用 SaaS 寄送通知，把客製網站放在 PaaS，另有 IaaS 主機處理舊系統。這時應分別畫出資料流向。若只在報價單寫「全雲端」，大家可能都以為另一方會處理通知串接失效或學員資料同步問題。

比較控制權時，可以直接問廠商：誰能安裝更新、誰能查看記錄、誰能修改程式，誰能停止服務？再問這些動作要透過介面、客服還是工程師完成。把答案寫成可執行的工作，比背熟三個縮寫更能找到符合教室人力的方案。

資料與帳號仍需要教室管理

Microsoft 的共用責任說明指出，不論服務類型，客戶仍需管理資料、身分及自己可控制的設定。以本例來說，供應商可以維護登入功能，卻不會自然知道哪位工讀生已離職、哪一班名單只該給授課老師，或某份匯出檔能否寄給外部合作人。

因此先分配管理者、行政人員與老師各自需要的操作。老師可能只需查看所授課程，不必能下載所有學員聯絡方式。以獨立帳號配合可用的多重要素驗證，並建立離職停權程序。即使採用 SaaS，這些設定與日常檢查仍不能只交給「雲端會處理」一句話。

另外區分服務方保存的資料與教室自己下載的檔案。匯出的名單若留在共用電腦、私人信箱或無限制分享的資料夾，風險已不只在雲端平台。可在工作表記下檔案用途、可讀人員及保存期限，讓報名工具之外的副本也有人負責整理。

更新、備份與恢復要逐項詢問

AWS 以 EC2 為例說明，IaaS 使用者要管理客體作業系統更新、安裝軟體及安全群組設定；較抽象化的服務則由供應商處理更多底層工作。這提醒我們，不能把某台虛擬主機的責任表直接套到每一種雲端產品，必須看當次選用的服務。

教室可以把維護工作拆成更新程式、套用平台設定、保留資料副本及恢復演練。逐一問清楚包含在月費裡嗎、由誰啟動、失敗如何通知，以及能恢復到什麼時間點。供應商有備援設備，與使用者能找回誤刪的一筆報名資料，是不同的查核項目。

安排一次小規模驗收：建立幾筆虛構報名資料，依官方提供的方式匯出，再確認檔案能開啟、欄位完整，並請負責人說明恢復程序。本例是建議的驗收方法，沒有宣稱已測試任何服務。真正要還原正式資料時，另訂操作窗口與確認程序，避免覆蓋較新的紀錄。

1. 列出報名、通知、儲存等服務，分辨各自的控制範圍。
2. 將帳號、資料、程式與系統維護分派給明確負責人。
3. 用虛構資料確認匯出、通知及恢復說明是否可操作。
4. 核對持續費用與退出方式，再決定是否導入正式資料。

比較費用時把人力放回來

三種類型不直接對應便宜、中等、昂貴。現成工具可能按使用者或功能收費，平台與基礎資源可能依用量計算，實際模式以方案為準。若只比較每月主機費，就可能漏掉工程師維護、監控、備份、額外儲存與資料傳出等成本，也漏掉行政人員的操作時間。

本例可用一個招生週期作為比較範圍：開課前匯入資料、招生時接收報名、截止後通知，再到課程結束匯出紀錄。每個階段填上需誰花多少時間，以及增加學員或檔案後哪些費用會變動。先取得同一工作量的估算，才有條件比較不同服務。

還要問清楚預算通知和用量限制的差別。收到提醒不一定會自動停止計費，關閉一個應用也不一定刪除所有持續收費的資源。採購時請供應商列出停止使用的程序及仍可能留存的項目，而不是自行假設登出帳號就已終止服務。

在導入前練習如何離開

退出服務先看能帶走什麼：課程、學員、付款紀錄、附件、操作歷程與權限設定是否都有匯出方式？能下載一份試算表，不代表可以完整重建報名流程。若程式部署在平台，也要確認原始碼、環境設定及資料庫能否移交，而不只取得前台網址。

接著確認匯出檔案的格式、關聯欄位及保留期限。例如學員和報名紀錄需要可對應的識別欄位，否則換到新工具後可能無法區分同名者。請承接人實際讀一份去識別化樣本，記錄缺少的欄位，再把移轉所需協助與費用列入委外範圍。

最後為每項關鍵工作填上主要與備援聯絡人。小教室可以合理選擇把更多技術工作交給服務商，但仍要保有帳號管理、資料使用及交接的掌握度。好的選擇是功能滿足需求，且每件持續工作都有人接手；不需要為了控制權而租下無人維護的主機。

把維護工作排入網站日常檢查

採購前整理網站預算與持續費用

• 教學
• 軟體與 App
• 架站與電商
• 網域、主機與前端