雲端的理念與責任分界

雲端運算是一種不持有IT資源、只在需要時按需租用、按實際使用量付費的使用形態。從提出需求到開始使用的時間很短，一旦歸還，計費也隨即停止。事先確定所需數量再採購設備、連電源與空調都由自家管理，都是地端部署（on-premises）的做法，由於必須提前確定數量，因而會發生過度佈建或容量不足的問題。簽約期間內無法變更數量的說法，與雲端「之後可自由增減」的前提正好相反。

按量計費（Pay-as-you-go）是無需預付款也無需長期承諾、按實際用量付費的原則。可以依實際需求而非預測來伸縮，藉此降低過度佈建的風險。以固定期限承諾使用量來換取較低單價的是承諾折扣（Save when you commit）；使用量越多單價越低的是用越多越便宜（Pay less by using more）；整合成按月固定收費、不會產生超額費用的是定額制（Flat rate），指的都是其他原則。

用越多越便宜（Pay less by using more）是指在 S3 與資料傳輸等場景採用階梯式收費體系，使用量越多，每GB的單價就越低的原則。以固定期限承諾使用量來降低單價的是承諾折扣（Save when you commit），Savings Plans 就屬於這一類。按實際用量逐次付費的是按量計費（Pay-as-you-go），整合成按月固定費用、不會產生超額費用的是定額制（Flat rate）。這4項原則目的各不相同，並非互斥，而是可以組合使用。

承諾折扣（Save when you commit）是指像 Savings Plans 那樣，以1年或3年的期間承諾特定的使用量水準，以換取運算或機器學習等服務的費用折扣的原則。將月費固定、不產生超額費用的是定額制（Flat rate），並不是遞延的機制。使用量越多單價越低的階梯式體系屬於用越多越便宜（Pay less by using more）。不需承諾、隨時可停用的性質屬於按量計費（Pay-as-you-go），與這項以承諾為前提的原則正好相反。

在2026年8月時點的官方考試指南一覽中，列在 Foundational 的是 AWS Certified Cloud Practitioner（CLF-C02）與 AWS Certified AI Practitioner（AIF-C01）這2項。Developer - Associate（DVA-C02）與 Data Engineer - Associate（DEA-C01）都屬於 Associate，Advanced Networking - Specialty（ANS-C01）屬於 Specialty。名稱結尾若帶有等級名稱可作為線索，但 Cloud Practitioner 與 AI Practitioner 的名稱沒有等級名稱，記住這2項就是 Foundational 即可。

CLF-C02 是 AWS Certified Cloud Practitioner 的考試代碼。CLF 代表 Cloud Practitioner，結尾的 C02 表示改版的世代。AWS Certified AI Practitioner 的代碼是 AIF-C01，AWS Certified Developer - Associate 是 DVA-C02，AWS Certified Data Engineer - Associate 是 DEA-C01。認證的名稱有時會改名，但考試代碼在改版之前不會變，因此教材是否為現行版，用代碼確認最可靠。

AWS Certified Solutions Architect - Professional 的考試代碼是 SAP-C02。SAA-C03 同樣是 Solutions Architect，但屬於 Associate 等級；SOA-C03 是 CloudOps Engineer - Associate；SCS-C03 是 Security - Specialty 的代碼。開頭3個字母相似容易混淆，只要記住 SAA 對應 Associate、SAP 對應 Professional 即可。

CLF-C02 的 Exam Guide 規定，Cloud Concepts 佔24%，Security and Compliance 佔30%，Cloud Technology and Services 佔34%，Billing, Pricing, and Support 佔12%。因此最大的是 Cloud Technology and Services，最小的是 Billing, Pricing, and Support。雖然這是入門認證，容易讓人以為概念類佔比最重，但實際上詢問服務知識的領域佔比最大，其次是安全性。學習時間的分配可以直接對照這個比例來安排。

SAA-C03 的 Exam Guide 規定，Design Secure Architectures 佔30%，Design Resilient Architectures 佔26%，Design High-Performing Architectures 佔24%，Design Cost-Optimized Architectures 佔20%。佔比最大的是安全架構的設計。這4個領域名稱可以對照 Well-Architected 的支柱來記，依序是安全性、可靠性、效能效率、成本最佳化，這樣比較容易記住。

維運系的 Associate 認證，名稱從 SysOps Administrator 改為 CloudOps Engineer，考試代碼也從 SOA-C02 改為 SOA-C03。舊代碼的最後應考日是2025年9月29日，新代碼則自2025年9月30日開始。Data Engineer - Associate 與 Machine Learning Engineer - Associate 並不是維運系的後繼，而是分別在資料與機器學習領域新設立的其他認證。DevOps Engineer - Professional 則是原本就存在的 Professional 等級認證，等級也不同。

AWS 官方將 AWS 一方的責任稱為「Security of the Cloud」，並定義為保護執行AWS雲端所提供之一切服務的基礎設施，也就是保護硬體、軟體、網路及設施。處理安裝在執行個體上的應用程式漏洞，是選擇 EC2 時使用者的責任。選擇資料加密選項與透過 IAM 賦予權限，則是不論選擇哪種服務都會留給使用者的工作，兩者都屬於「Security in the Cloud」的一方。

官方明確指出「客戶的責任取決於客戶所選擇的AWS雲端服務」。意思是依所選服務的不同，作為安全責任一部分、由使用者要進行的設定工作量也會不同。支援方案是決定技術支援的接受方式，並不會移動責任的分界。區域與可用區域是配置地點的問題，使用期間與使用金額則是計費的問題，都不是決定責任範圍寬窄的因素。

官方指出，在像 EC2 這樣需要自行設定的服務中，使用者要負責「客體作業系統的管理（含更新與安全修補）、安裝在執行個體上的應用程式軟體與公用程式、安全群組的設定」。因此，作業系統的修補套用屬於使用者的責任。在 EC2 中，AWS 所運作的範圍僅到實體基礎設施與虛擬化層為止，執行個體內的作業系統並不包含在內。支援方案是接受技術支援的合約，並不會移轉責任的歸屬。

對於抽象化、或稱受管理的服務，官方指出「AWS 運作基礎設施層、作業系統與平台，客戶則透過端點存取以儲存與取得資料」。留給使用者的是自身資料的管理（含加密選項）、資產的分類，以及透過 IAM 工具套用適當的權限。不論作業系統的更新或平台的運作，使用者都不需負責，但資料的分類與權限設定，不論哪種服務都不會脫離使用者的責任。

共同責任模式的分界並非固定，而是會隨著所選服務移動。像 EC2 這種由使用者管理客體作業系統的服務，修補套用是使用者的責任；但像 S3、DynamoDB 這種由 AWS 連作業系統與平台都負責運作的服務，就變成AWS的責任。因此「永遠是AWS」與「永遠是使用者」都不正確。區域是配置地點的選擇，並不會改變責任的分擔。掌握這一點後，即使遇到初次見到的服務，也只要思考它偏向 EC2 還是偏向 S3，就能推測出分界所在。

設施作為執行AWS雲端服務之基礎設施的一部分，被明確列在「Security of the Cloud」中，不論使用哪種服務都永遠是AWS的責任。使用者無法自行稽核或實地進入檢查這個範圍，而是透過AWS公開的第三方認證與稽核報告來確認。這屬於3種控制分類中的繼承控制（Inherited Controls），是使用者完全從AWS繼承而來的部分。會隨所選服務而移動的是作業系統或中介軟體層，而不是實體層。

官方明確指出，即使使用抽象化的服務，自身資料的管理（含加密選項）、資產的分類，以及透過 IAM 工具套用適當的權限，仍會留給使用者。不論選擇哪種服務都不會脫離，因此可作為思考分界時的固定點。實體伺服器的更換與骨幹網路的保護都屬於設施與硬體的範疇，永遠是AWS的一方。受管理服務的基礎作業系統由AWS運作，因此其修補套用並非使用者的工作。

官方定義繼承控制為使用者完全從AWS繼承而來的控制，實體、環境類的控制屬於此類。分別套用於基礎設施層與使用者層兩方的是共用控制（Shared Controls），完全由使用者負責、服務與可用區域安全性屬於此類的是客戶專屬控制（Customer Specific Controls）。繼承的方向是由AWS流向使用者的單向關係，並不是AWS沿用使用者設定的關係。

官方舉出的共用控制有3項：修補程式管理、組態管理、意識提升與訓練。共同的特徵是同樣的工作會同時在基礎設施層與使用者層進行，例如修補程式管理，AWS 套用於自己的基礎設施，使用者則套用於客體作業系統與應用程式，分別各自進行。門禁管理、電源備援、硬體的採購與報廢屬於實體、環境類的控制，是使用者從AWS繼承的一方。服務與可用區域的安全性則是客戶專屬控制的例子。

DynamoDB 是抽象化的服務，因此由AWS運作基礎設施層、作業系統與平台。在 EC2 中原本由使用者負責的客體作業系統修補套用，遷移後就變成AWS一方的工作。另一方面，資料的分類與加密選項的選擇，以及透過 IAM 賦予的權限，不論選擇哪種服務都留給使用者。實體設施的保護原本就一直是AWS的責任，遷移後也不會移轉給使用者。整理成「會移動的部分是作業系統或平台層，不會移動的部分是資料與權限」，就不容易混淆。

現行的支柱共6項：卓越營運、安全性、可靠性、效能效率、成本最佳化、永續性。永續性是2021年新增為第6項支柱的內容，若少了這項只列出5項，就代表是新增之前的舊資訊。互通性與可攜性都不是架構所列出的支柱名稱，官方一覽中並不存在這兩個詞。支柱數量寫錯的解說文，服務名稱或考試代碼也很可能是舊的，可作為判斷教材新舊的線索。

卓越營運著重於系統的執行與監控，以及流程與程序的持續改善，是這項支柱的重點。部署自動化、故障後透過檢討來更新程序、以小規模且頻繁的方式進行變更等都屬於此類。資訊與系統的保護是安全性的重點，資源配置的最佳化與資源類型的選擇是效能效率的重點，消除不必要支出、使資源合理化是成本最佳化的重點，指的都是其他支柱。

安全性著重於資訊與系統的保護，核心在於資料的完整性與存取控制。加密與依最小權限原則的存取控制正好符合這項重點。停用未使用資源並調整大小屬於成本最佳化，部署自動化與透過檢討更新程序屬於卓越營運，測量並降低對環境的影響則屬於永續性的關注重點。在共同責任模式中留給使用者一方的範圍，大部分都會落在這項安全性支柱裡處理。

可靠性著重於工作負載能否發揮預期功能，以及能從故障中多快恢復，是這項支柱的重點。分散配置於多個可用區域、自動恢復、備份與復原程序的驗證都屬於此類。這項支柱的特色不只在於不出故障，還包含出故障後能盡快恢復。資源配置的最佳化屬於效能效率，執行監控與程序改善屬於卓越營運，將環境影響降到最低則屬於永續性的重點。

效能效率著重於IT資源配置的最佳化，以及選擇符合工作負載需求的資源類型，是這項支柱的重點。為滿足要求而重新選擇資源類型的作為正好符合此重點。成本最佳化看起來是類似的作業，但目的在於消除支出上的浪費，而此情境的動機是要滿足延遲要求，重點並不相同。可靠性著重於抗故障能力，卓越營運著重於程序的改善，兩者都不是此處的主要重點。

成本最佳化著重於消除不必要的支出，使資源符合業務需求，是這項支柱的重點。停用未使用的資源、將過大的執行個體調整為合理大小、依情況選用不同的計費模式等判斷都屬於此類。目的不只是單純省錢，而是要問支出是否換得對應的價值，這一點是要點。資訊與系統的保護是安全性，發揮預期功能與復原是可靠性，將環境影響降到最低則是永續性的重點。

永續性著重於將雲端工作負載執行所造成的環境影響降到最低，是這項支柱的重點。它是2021年新增為第6項的最新支柱，有沒有這項支柱正是判斷教材新舊的分水嶺。資源配置的最佳化與資源類型的選擇屬於效能效率，執行監控與程序的持續改善屬於卓越營運，發揮預期功能與從故障中恢復屬於可靠性的重點，指的都是其他支柱。

遺漏的是永續性（Sustainability），這項支柱處理的是將雲端工作負載執行對環境的影響降到最低。由於是2021年才新增的第6項支柱，在此之前寫成的解說文仍停留在5項。卓越營運、效能效率、可靠性在新增之前就已存在，因此即使文章寫成5項，這3項仍會被列出。像支柱數量這種基本部分都寫錯的文章，其他敘述很可能也已過時，最好抱持這樣的判斷。

現行的支柱共6項：卓越營運、安全性、可靠性、效能效率、成本最佳化、永續性，互通性並不在此一覽之中。不同系統之間能否互相連接，在設計上固然是重要的關注點，但 Well-Architected 架構並未為此單獨設立支柱。成本最佳化、卓越營運、效能效率都是6項之中正規的支柱。若把架構中沒有的詞誤記成支柱，在刪去法作答時容易造成困惑。

消除不必要的支出、使資源符合業務需求，是成本最佳化的重點，並不是可靠性的重點。可靠性著重於工作負載能否發揮預期功能，以及能從故障中多快恢復，是這項支柱的重點。其餘3項都是依官方敘述的正確組合。支柱的名稱都很接近日常用語，若只憑字面印象去連結，很容易搞錯。建議連同表達重點的那一句話一起記住，就不容易在這類題型上出錯。

區域是AWS擁有多個可用區域的世界各地實體地點，帶有像 us-east-1 或 ap-northeast-1 這樣的名稱，選擇時要考量資料所在地與法規、與使用者的距離、以及費用。由1個以上獨立資料中心組成、用來隔離故障的單位指的是可用區域的說明。CloudFront 快取並發送內容的據點是邊緣節點，配置在電信業者網路內的則是 Wavelength Zones。

可用區域被定義為由1個以上獨立資料中心組成，每個資料中心都具備備援的電源、網路及連線，並收容於各自不同的設施中。它並不等同於1棟資料中心，重點在於它是一個集合體，且與其他區域位於不同的建築物。邊緣節點與來源伺服器之間的層是區域邊緣快取，能在使用者鄰近城市執行應用程式的則是 Local Zones 的說明，指的都是不同的機制。

官方指出，各區域由「至少3個獨立且實體隔離的可用區域」組成。由於區域總數與可用區域總數會持續增加，記住這些數字沒有太大意義，但1個區域最少要有幾個可用區域這項組成規則相當穩定，可以直接作為設計上的前提。「位於同一設施內」的說法，與「收容於各自不同設施」的定義相矛盾。可用區域並非由使用者申請增加，也不是每個區域只有1個。

邊緣節點是 CloudFront 用來發送內容的全球規模資料中心網路。請求會被路由到延遲最低的邊緣節點，並從該處發送。它並非用來提升可用性的備援單位，而是為了從離使用者較近的地方重新配送內容而設的快取據點，這一點是重點。隔離故障屬於可用區域的角色，劃分IP位址範圍屬於子網路，在電信業者設備內執行則是 Wavelength Zones 的角色。

請求會被路由到延遲最低的邊緣節點，若該處已有內容，就會立即發送。若沒有，則會從 S3 儲存貯體或HTTP伺服器等來源伺服器取得後發送，同時保留一份快取。因此第2次以後的請求就能直接從較近的據點回傳。沒有快取並不會變成錯誤，也不會讓使用者一直等待而被放著不管。轉發到可用區域是故障隔離的機制，與內容發送的流程是不同的事。

區域邊緣快取是位於邊緣節點與來源伺服器之間的快取層，作用是在邊緣找不到內容時，減少前往來源伺服器取得的次數。彙整可用區域的管理單位是區域，配置在電信業者網路內的區域是 Wavelength Zones，兩者都是不同的概念。使用者裝置端的快取並不是AWS的機制，而是瀏覽器或作業系統所具備的功能。

可用區域收容於各自不同的設施，是具備備援電源與網路的故障隔離單位。若將相同角色的資源分散配置在多個可用區域，即使其中一個區域整個停止，剩下的仍能繼續處理。這就是多AZ架構，是可用性設計的出發點。從最近據點發送內容是邊緣節點的角色，資料所在地是選擇區域時的考量因素，透過承諾使用量降低單價則是計費模式的話題，都不是分散可用區域的動機。

Local Zones 是能讓應用程式在離終端使用者或工作負載更近的AWS基礎設施上執行的機制，配置在離區域較遠的城市。它與邊緣節點同樣處理「較近之處」，但不同之處在於它是實際執行應用程式本身的場所，而不是用來發送內容的快取。區域內的故障隔離是可用區域，專用發送據點是邊緣節點，來源伺服器前方的中間快取則是區域邊緣快取。

Wavelength Zones 是配置在電信業者網路內的區域。它與 Local Zones 一樣，是用來在離使用者較近之處執行應用程式本身的機制，與作為內容發送快取據點的邊緣節點目的不同。配置在邊緣節點與來源伺服器之間的是區域邊緣快取，在區域中隔離故障的單位是可用區域，劃分 VPC 之IP位址範圍的則是子網路。

可用區域是收容於各自不同設施的故障隔離單位，因此要應對整個區域停止的情況，只能跨可用區域配置。由於各區域至少由3個彼此隔離的可用區域組成，同一區域內跨多個可用區域分散是可行的。若只在同一可用區域內增加台數，該區域一旦故障就會全部中斷，無法滿足需求。CloudFront 是加快發送速度的機制，若來源停止，動態處理仍會中斷。變更計費方案是費用的問題，與可用性無關。