AWS Managed Services 筆記

AMS = AWS 專家代管你的雲端維運,讓你少救火、多專注業務。

一、AWS Managed Services 是什麼?

AWS Managed Services,簡稱 AMS,是 AWS 提供的代管維運服務。 它不是 RDS、Lambda 這類單一受管服務,而是由 AWS 專家團隊協助企業管理與操作 AWS 環境。

AMS 會協助處理基礎架構與應用程式的日常維運, 包含安全、可靠性、可用性、監控、修補、備份與變更管理。

二、AWS 專家重點說明

AWS Managed Services AMS Team Monitoring Patch Management Backup Automation
  • AMS 是代管營運服務:不是單一 AWS 產品,而是 AWS 專家團隊協助維運。
  • 降低維運負擔:例行工作可以交給 AMS 協助處理。
  • 提升安全與可靠性:導入 AWS 最佳實務與標準化流程。
  • 支援 24/7 營運:全年無休協助維持雲端環境穩定。
  • 重視自動化:透過自動化降低人工操作與錯誤。
  • 需要聯絡 AWS:AMS 不是 Console 直接點選啟用,通常需要透過 AWS Sales 導入。

三、AWS 服務與功能整理

類別 AWS 服務 / 功能 用途 白話說明
代管維運 AWS Managed Services / AMS 管理與操作 AWS 基礎架構 AWS 專家幫你顧雲端環境
專家支援 AMS Team 提供 AWS 專業維運服務 不是工具,是 AWS 專家團隊
基礎架構管理 Infrastructure Operations 管理雲端基礎架構 幫你管主機、網路、平台運作
應用支援 Application Support 協助應用程式維運 不只看底層,也協助應用相關支援
安全維運 Security Management 管理安全控制與風險 幫你維持安全基準
可靠性管理 Reliability Management 確保系統穩定運作 降低服務中斷風險
可用性管理 Availability Management 提升服務可用性 讓系統更穩、更少停機
變更管理 Change Requests 管理變更流程 不讓變更亂做,降低人為錯誤
監控 Monitoring 持續觀察系統狀態 幫你看系統有沒有異常
修補管理 Patch Management 管理系統修補與更新 幫主機與系統打 Patch
備份服務 Backup Services 管理備份與還原 確保資料出事時能救回
自動化 Automation 自動執行例行維運 減少人工操作與錯誤
合規管理 Compliance Support 協助維持合規要求 讓流程與設定更符合公司規範

四、生活化比喻

AWS Managed Services 可以想成大樓物業管理公司。

  • 你的 AWS 環境:就像你擁有的一棟大樓。
  • AMS Team:就像專業物業管理公司。
  • Monitoring:24 小時監控大樓設備。
  • Patch Management:定期保養與修繕設備。
  • Security Management:保全、門禁與安全巡檢。
  • Backup Services:重要文件與資料備份。
  • Change Requests:裝修或變更要走正式流程。

你還是大樓的主人,但日常維運交給專業團隊處理, 讓你可以專心經營公司本身。

五、整體概念流程圖

企業使用 AWS
        │
        ▼
[面臨維運挑戰]
需要監控
需要安全管理
需要 Patch
需要備份
需要變更控管
需要 24/7 支援
        │
        ▼
[AWS Managed Services / AMS]
AWS 專家團隊介入協助管理
        │
        ▼
[建立營運基準]
導入標準流程
導入最佳實務
建立安全與維運基線
        │
        ▼
[日常維運管理]
Monitoring
Patch Management
Change Requests
Security Management
Backup Services
        │
        ▼
[降低營運負擔]
減少人工操作
降低人為錯誤
降低維運風險
提升可用性與可靠性
        │
        ▼
[企業專注業務]
內部團隊不用一直救火
可以專注在應用、產品、創新與業務價值
  

六、常見誤解與正確觀念

常見誤解 正確觀念
AWS Managed Services 就是 RDS、Lambda 這類受管服務 AMS 是 AWS 專家團隊提供的代管維運服務,不是單一雲端產品
AMS 可以直接在 Console 啟用 AMS 通常需要聯絡 AWS Sales 進行導入
使用 AMS 後企業什麼都不用管 AMS 協助維運,但企業仍要負責業務需求、應用邏輯與決策
AMS 只是監控服務 AMS 包含監控、變更、修補、安全、備份與營運管理
AMS 只適合小公司 大型企業也常用 AMS 來標準化雲端營運與降低風險
AMS 等於 AWS Support AWS Support 是技術支援方案,AMS 是更偏代管營運的服務
AMS 會取代公司 IT 團隊 AMS 是協助公司 IT 團隊降低維運負擔,不是完全取代
AMS 只是人工代操 AMS 很重視自動化,會用流程與工具降低人工作業
AMS 只跟安全有關 安全只是其中一部分,還包含可靠性、可用性、備份、變更與維運
只有上雲初期才需要 AMS 上雲後的長期維運、合規與標準化管理也可能需要 AMS

七、總結

AWS Managed Services 是 AWS 提供的代管維運服務。 它透過 AWS 專家團隊與自動化流程,協助企業管理監控、修補、安全、備份與變更, 降低營運負擔與風險,讓企業更專注在業務與創新。

AWS Knowledge Center 筆記

AWS Knowledge Center = AWS 常見問題與疑難排解知識庫。

一、AWS Knowledge Center 是什麼?

AWS Knowledge Center 是 AWS re:Post 入口網站中的知識庫區域。 它提供 AWS 常見問題、常見請求、疑難排解與最佳實務文章。

它的重點是把常見問題整理成「問題描述」與「解決方法」, 讓使用者可以快速找到標準排查方向。

二、AWS 專家重點說明

Knowledge Center AWS re:Post FAQ Troubleshooting Best Practices
  • Knowledge Center:查 AWS 常見問題與標準解法。
  • re:Post:AWS 技術問答社群平台。
  • Featured Questions:精選常見問題。
  • Tags:依服務或主題快速篩選文章。
  • Resolution:文章中的解決步驟。

三、AWS 服務與功能整理

類別 AWS 服務 / 功能 用途 白話說明
知識庫 AWS Knowledge Center 查找 AWS 常見問題與解決方法 AWS 官方整理好的 FAQ / 疑難排解文章
問答入口 AWS re:Post AWS 技術問答社群平台 AWS 版的技術問答網站
精選問題 Featured Questions 顯示常見或重要問題 AWS 幫你挑出常被問的問題
問題文章 Knowledge Center Article 提供問題與解決方法 一篇文章解釋一個常見問題怎麼處理
服務分類 Service Categories 依 AWS 服務分類文章 例如 S3、EC2、RDS、Lambda
標籤篩選 Tags 用標籤篩選內容 依服務或主題快速找文章
搜尋功能 Search 搜尋問題或關鍵字 直接輸入錯誤訊息或服務名稱查找
排序功能 Sort 依熱門、新建立等方式排序 快速找最新或最多人看的內容
疑難排解 Troubleshooting 協助解決 AWS 問題 遇到錯誤時照文章步驟排查
最佳實務 Best Practices 提供建議做法 告訴你比較好的設定方式

四、生活化比喻

AWS Knowledge Center 可以想成家電官方維修知識庫。

  • Knowledge Center:官方常見問題與維修手冊。
  • Featured Questions:最多人遇到的熱門問題。
  • Search:輸入錯誤訊息或問題關鍵字。
  • Tags:依家電類型或問題類型篩選。
  • Resolution:一步一步的解決方法。

re:Post 像社群討論區,Knowledge Center 則像官方整理好的常見維修手冊。

五、整體概念流程圖

你在 AWS 遇到問題
        │
        ▼
[先判斷問題類型]
常見錯誤 / 設定問題 / 疑難排解 / 最佳實務
        │
        ▼
[進入 AWS re:Post]
找到 Knowledge Center 區域
        │
        ▼
[搜尋或篩選內容]
輸入關鍵字
依 AWS Service 篩選
依 Tags 篩選
依熱門或最新排序
        │
        ▼
[找到 Knowledge Center Article]
查看問題描述
查看 Resolution
查看詳細步驟
        │
        ▼
[依照文章排查]
檢查設定
檢查權限
檢查服務狀態
檢查常見錯誤
        │
        ▼
[問題解決或縮小範圍]
如果仍無法解決
再到 re:Post 提問或使用 AWS Support
  

六、常見誤解與正確觀念

常見誤解 正確觀念
Knowledge Center 是一個獨立 AWS 服務 它是 re:Post 裡的一個知識庫區域
Knowledge Center 是拿來開資源的 它是查問題與解法,不是建立 AWS 資源
Knowledge Center 跟 re:Post 完全一樣 re:Post 是問答社群,Knowledge Center 是整理好的常見問題文章
Knowledge Center 只能查入門問題 它也有很多疑難排解與最佳實務內容
遇到所有問題都直接開 AWS Support 常見問題可以先查 Knowledge Center,節省排查時間
Knowledge Center 可以取代 AWS Support 緊急、正式系統、帳號特殊問題仍應使用 AWS Support
文章裡的解法一定適用所有環境 仍要依自己的架構、權限、Region、服務設定確認
只適合開發人員使用 DBA、架構師、DevOps、維運人員都可以使用
搜尋只能用服務名稱 也可以用錯誤訊息、關鍵字、Tag 搜尋
它只是文件網站 它更偏向「問題 → 解法」的疑難排解知識庫

七、總結

AWS Knowledge Center 是 AWS re:Post 中的常見問題與疑難排解知識庫。 它適合用來查 AWS 常見錯誤、服務設定問題、最佳實務與解決步驟。 一般問題可以先查 Knowledge Center,社群討論可以用 re:Post,正式緊急問題則應使用 AWS Support。

AWS IQ 與 AWS re:Post 筆記

AWS IQ = 找專家做事;AWS re:Post = 問社群找答案。

一、AWS IQ 是什麼?

AWS IQ 是一個專家媒合平台,用來快速找到 AWS 認證專家, 協助你完成 AWS 專案。

它有點像 AWS 版的自由工作者平台,但專注在 AWS 專案。 你可以提交需求、比較專家、管理合約、安全協作,並透過 AWS 帳單付款。

二、AWS re:Post 是什麼?

AWS re:Post 是 AWS 管理的技術問答社群平台。 你可以在上面查問題、問問題、回答問題、看最佳實務,也可以加入不同主題群組。

它適合一般技術討論與知識查詢,但不適合緊急問題或涉及公司敏感資訊的問題。

三、AWS 專家重點說明

AWS IQ AWS re:Post AWS Support Expert Milestone Integrated Billing
  • AWS IQ:適合需要專家實際幫你做專案。
  • AWS re:Post:適合一般 AWS 技術問答與知識查詢。
  • AWS Support:適合正式系統、緊急問題與時效性高的支援需求。
  • Milestone:專案分階段驗收,完成一段再付款一段。
  • Integrated Billing:AWS IQ 費用可以整合到 AWS 帳單。

四、AWS 服務與功能整理

類別 AWS 服務 / 功能 用途 白話說明
專家媒合 AWS IQ 找 AWS 認證專家協助專案 AWS 版的專家自由工作平台
專案需求 Submit Request 提交 AWS 專案需求 告訴專家你需要解決什麼問題
專家篩選 Expert Selection 根據費率、經驗、時程選專家 像挑顧問或接案工程師
安全協作 Secure Collaboration 安全地與專家合作 不用亂給帳密,透過安全方式授權
合約管理 Contract Management 管理合作條件與工作範圍 把交付內容與費用講清楚
階段付款 Milestones 依工作階段確認與付款 做完一段、驗收一段、付款一段
帳單整合 Integrated Billing 費用整合到 AWS 帳單 不需要另外處理第三方付款
技術問答 AWS re:Post AWS 技術問答社群 AWS 版 Stack Overflow
社群回答 Community Answers 社群成員回答問題 讓其他 AWS 使用者幫你解答
專家審查 Expert-reviewed Answers 專家審查技術回答 提高答案可信度
聲譽系統 Reputation 透過回答問題累積聲譽 回答越多、越有價值,聲譽越高
正式支援 AWS Support 處理緊急與正式支援需求 正式系統出問題要找它

五、生活化比喻

AWS IQ 可以想成找專業水電師傅到你家施工。

  • Submit Request:描述你家要修什麼。
  • Expert Responses:不同師傅回覆報價與經驗。
  • Expert Selection:你挑一位合適的師傅。
  • Secure Collaboration:讓師傅安全進屋施工,不是把鑰匙亂丟給他。
  • Milestone:每完成一段工程,你驗收後再付款。

AWS re:Post 則像社區問答佈告欄。 一般問題可以問鄰居與專家,但如果水管爆裂,就應該直接找正式維修服務。

六、整體概念流程圖

你需要 AWS 協助
        │
        ▼
[先判斷需求類型]
        │
        ├── 一般技術問題 / 想查解法
        │          │
        │          ▼
        │   [AWS re:Post]
        │   提問、查詢答案、看最佳實務、參考社群回覆
        │
        ├── 需要專家幫忙完成專案
        │          │
        │          ▼
        │   [AWS IQ]
        │   提交需求 → 收到專家回覆 → 挑選專家
        │          │
        │          ▼
        │   安全協作 → 完成 Milestone → 整合 AWS 帳單付款
        │
        └── 正式系統緊急問題 / 時效性高
                   │
                   ▼
            [AWS Support]
            依支援方案取得正式技術支援
  

七、常見誤解與正確觀念

常見誤解 正確觀念
AWS IQ 是 AWS 官方工程師服務 AWS IQ 是媒合第三方 AWS 專家的平台
AWS IQ 是免費問答平台 AWS IQ 是付費專家協作平台
AWS IQ 只能問問題 AWS IQ 主要用來找專家完成實際專案工作
找 AWS IQ 專家就要直接給帳密 應透過安全方式授權,不應直接分享帳密
re:Post 是付費顧問服務 re:Post 是 AWS 技術問答社群
re:Post 適合處理緊急正式問題 緊急或正式系統問題應使用 AWS Support
re:Post 可以放公司敏感資訊 不應在公開社群放專有資訊、帳號細節或敏感資料
re:Post 跟 AWS Support 一樣 re:Post 是社群問答,AWS Support 是正式支援
re:Post 的答案都一定正確 答案可被審查與接受,但仍要依文件與實際環境驗證
AWS IQ 和 APN 一樣 AWS IQ 偏專案型專家媒合,APN 是 AWS 合作夥伴網路

八、總結

AWS IQ 適合找 AWS 專家協助完成專案,AWS re:Post 適合查詢與討論一般技術問題。 如果是正式系統緊急事件或需要時效性的支援,應該使用 AWS Support。

AWS Ecosystem 筆記

AWS Ecosystem = 學習、支援、購買、訓練、顧問、合作夥伴的一整套 AWS 周邊資源。

一、AWS Ecosystem 是什麼?

AWS 生態系不只是 AWS 雲端服務本身,還包含學習資源、文件、解決方案、 技術支援、Marketplace、訓練課程、專業服務與合作夥伴網路。

這些資源可以幫助企業更快學會 AWS、更快建置架構、更快取得支援, 也能更快找到成熟的解決方案。

二、AWS 生態系核心重點

AWS Blog Whitepapers Solutions Library Support Plans Marketplace Training APN
  • AWS Blog:看新功能與實作案例。
  • Community Forums:與其他 AWS 使用者交流。
  • Whitepapers and Guides:深入學習架構、安全、成本與治理。
  • Solutions Library:找到 AWS 驗證過的參考架構。
  • Support Plans:依需求取得不同層級的 AWS 技術支援。
  • AWS Marketplace:購買第三方軟體、AMI、SaaS、Container 與模板。
  • AWS Training:透過線上、課堂或企業內訓學習 AWS。
  • AWS Partner Network:尋找 AWS 認可的技術、顧問與訓練合作夥伴。

三、AWS 服務與資源整理

類別 AWS 服務 / 資源 用途 白話說明
學習資源 AWS Blog 了解新功能與實作案例 看 AWS 最新消息與實戰文章
社群交流 AWS Community Forums 與其他 AWS 使用者交流 遇到問題可以看別人怎麼處理
深度文件 AWS Whitepapers and Guides 深入學習特定主題 像 AWS 的專題教科書
解決方案 AWS Solutions Library 找 AWS 驗證過的架構方案 想做某種系統,可以先找現成藍圖
自動部署 CloudFormation 透過模板部署架構 Solutions Library 常可直接用它建立資源
技術支援 Developer Support 基礎技術支援 適合開發與測試階段的支援需求
技術支援 Business Support 24/7 技術支援 適合正式系統在 AWS 上運作的企業
技術支援 Enterprise Support 專屬 TAM 與高階支援 適合大型企業與關鍵系統
軟體市集 AWS Marketplace 購買第三方軟體與方案 AWS 上的軟體商店
映像檔 Custom AMI 預先安裝好軟體的主機映像 不用自己從零安裝環境
架構模板 CloudFormation Templates 快速建立完整架構 別人包好的基礎架構模板
SaaS 採購 SaaS on Marketplace 購買 SaaS 服務 透過 AWS 帳單整合付款
容器方案 Containers on Marketplace 購買容器化軟體 可以直接部署容器應用
線上訓練 AWS Digital Training 線上學習 AWS 自學 AWS 課程
課堂訓練 AWS Classroom Training 實體或虛擬課程 有講師帶著學
企業訓練 Private Training 給企業內部的專屬訓練 公司內部客製化上課
教育合作 AWS Academy 協助學校教授 AWS 讓學生在學校就學雲端
專業服務 AWS Professional Services AWS 專家協助導入與轉型 AWS 官方顧問團隊
合作夥伴 AWS Partner Network / APN AWS 合作夥伴網路 找 AWS 認可的外部專家

四、生活化比喻

AWS 生態系可以想成一個大型購物中心加教育中心。

  • AWS Blog:購物中心公告欄,告訴你新服務與新活動。
  • Whitepapers and Guides:專業使用手冊,適合深入研究。
  • Community Forums:顧客討論區,大家分享問題與解法。
  • Solutions Library:展示樣品屋,可以先看成熟架構範例。
  • CloudFormation:施工圖與自動施工工具。
  • Support Plans:客服等級,不同需求有不同支援層級。
  • AWS Marketplace:軟體商店,可以買 AMI、SaaS、Container。
  • AWS Training:補習班與企業內訓。
  • AWS Academy:大學裡的雲端課程。
  • AWS Professional Services:AWS 官方顧問團隊。
  • AWS Partner Network:AWS 認可的外部廠商與顧問名單。

五、整體概念流程圖

使用 AWS 的過程
        │
        ▼
[學習與查資料]
AWS Blog
AWS Whitepapers and Guides
AWS Community Forums
        │
        ▼
[尋找現成架構]
AWS Solutions Library
找到 AWS 驗證過的解決方案
        │
        ▼
[快速部署]
CloudFormation
根據模板建立 AWS 架構
        │
        ▼
[需要技術支援]
Developer Support
Business Support
Enterprise Support
        │
        ▼
[需要購買軟體或方案]
AWS Marketplace
購買 AMI、SaaS、Container、CloudFormation Templates
        │
        ▼
[需要學習與培訓]
AWS Digital Training
Classroom Training
Private Training
AWS Academy
        │
        ▼
[需要專家協助]
AWS Professional Services
AWS Partner Network
        │
        ▼
[合作夥伴類型]
Technology Partners    → 硬體、連線、軟體
Consulting Partners    → 顧問、建置、導入
Training Partners      → AWS 訓練課程
Competency Program     → 特定領域能力認可
Navigate Program       → 夥伴能力培育
        │
        ▼
[最終目標]
更快學會 AWS
更快建置架構
更快取得支援
更快導入成熟解決方案
  

六、常見誤解與正確觀念

常見誤解 正確觀念
AWS 生態系只有 AWS 服務 還包含文件、訓練、支援、市集、顧問與合作夥伴
AWS Blog 只是新聞 AWS Blog 常有新功能、架構案例與實作說明
Whitepapers 只是理論文件 Whitepapers 很適合深入理解架構、安全、成本與治理
Solutions Library 只是參考資料 很多方案可以直接透過 CloudFormation 部署
Marketplace 只能買 AMI Marketplace 也有 SaaS、Container、CloudFormation Template 等
Marketplace 上的東西都是 AWS 自己做的 很多是第三方獨立軟體廠商提供
透過 Marketplace 買軟體很麻煩 優點是費用可以整合到 AWS 帳單
Developer Support 適合所有正式系統 正式營運系統通常需要更高階支援
Enterprise Support 只是回覆比較快 它還包含 TAM 與帳務 / 帳號最佳實務協助
AWS Training 只有線上課 AWS 也有實體、虛擬、企業內訓等形式
AWS Academy 是給企業用的 AWS Academy 主要協助教育機構教授 AWS
AWS Professional Services 等於 APN Professional Services 是 AWS 官方專家團隊,APN 是合作夥伴網路
Technology Partner 跟 Consulting Partner 一樣 Technology Partner 偏產品與技術方案,Consulting Partner 偏顧問與導入服務
Competency Program 是訓練課程 它是對合作夥伴特定領域能力的認可

七、總結

AWS Ecosystem 是 AWS 周邊完整生態圈。 它包含學習文件、社群、解決方案、技術支援、Marketplace、訓練、AWS 官方專業服務與合作夥伴網路。 善用這些資源,可以讓企業更快學習 AWS、更快導入成熟架構,也能在需要時取得合適的支援與外部協助。

AWS Right Sizing 筆記

Right Sizing = 用監控數據決定資源大小,不靠感覺開機器。

一、Right Sizing 是什麼?

Right Sizing 是根據工作負載的效能需求與容量需求, 選擇最合適的 Instance 類型與大小,並用盡可能低的成本滿足需求。

簡單說,就是不要開太大,也不要開太小,而是讓資源大小剛剛好。

二、AWS 專家重點說明

先小後大 看監控數據 避免浪費 定期檢查 遷移前評估 上雲後持續調整
  • 不要一開始就選最大:雲端可以調整規格,不需要一次開到頂。
  • 先從合理小規格開始:再依照實際數據放大或縮小。
  • 用 CloudWatch 看使用率:觀察 CPU、Network、Disk I/O 等指標。
  • 用 Cost Explorer 看成本:找出花錢但使用率低的資源。
  • 遷移前先做 Right Sizing:不要把地端過大的規格直接搬上雲。
  • 上雲後持續檢查:需求會改變,資源大小也要跟著調整。

三、AWS 服務與工具整理

類別 AWS 服務 / 工具 用途 白話說明
資源合適化 Right Sizing 選擇合適的 Instance 類型與大小 不開太大,也不開太小
運算資源 Amazon EC2 提供虛擬主機運算能力 最常需要 Right Sizing 的服務
效能監控 CloudWatch 監控 CPU、Network、Disk、指標 看機器到底有沒有被用到
成本分析 Cost Explorer 分析成本與使用趨勢 看哪些資源花錢但使用率低
架構建議 Trusted Advisor 提供成本、效能、安全建議 幫你找可能浪費的資源
自動擴展 Auto Scaling 根據需求自動增加或減少資源 不靠固定大機器硬撐流量
遷移評估 Migration Planning 上雲前評估資源需求 搬上雲前先看原本主機實際用量
持續優化 Monthly Review 定期檢查資源是否合適 每月檢查哪些該放大、哪些該縮小

四、生活化比喻

Right Sizing 可以想成買車或租車。

  • EC2 Instance:就像車子,有小車、休旅車、貨車、遊覽車。
  • 小型 Instance:像小轎車,便宜但載量有限。
  • 大型 Instance:像遊覽車,容量大但成本高。
  • CloudWatch:像車上的儀表板,顯示負載與使用狀況。
  • Cost Explorer:像每月油錢與租車費報表。
  • Trusted Advisor:像顧問,提醒你車子是不是租太大台。

如果每天只有一個人上下班,就不用租遊覽車。 但如果每天要載 30 個人,小轎車也不夠。

五、整體概念流程圖

系統準備部署或遷移到 AWS
        │
        ▼
[先評估工作負載需求]
CPU / Memory / Network / Disk I/O / 使用者流量
        │
        ▼
[選擇初始 Instance 規格]
不要直接選最大
先選合理、可調整的規格
        │
        ▼
[系統開始運行]
EC2 / RDS / 其他雲端資源開始提供服務
        │
        ▼
[收集監控數據]
CloudWatch
觀察 CPU、網路、磁碟、連線數、延遲
        │
        ▼
[分析成本與使用率]
Cost Explorer + Trusted Advisor
找出高成本、低使用率、閒置資源
        │
        ▼
[判斷是否調整]
使用率太低 → Downsize / 停用 / 合併
使用率太高 → Upsize / Auto Scaling / 架構調整
        │
        ▼
[執行 Right Sizing]
調整 Instance Type、Instance Size 或擴展策略
        │
        ▼
[定期檢查]
每月或每季重新檢查
因為流量、需求、架構都會改變
  

六、常見誤解與正確觀念

常見誤解 正確觀念
Instance 開越大越安全 開太大會浪費成本,應該依實際需求調整
Right Sizing 只是省錢 它同時影響成本、效能、容量與穩定性
上雲時直接照地端規格搬就好 地端規格不一定適合雲端,應該看實際使用率
只要遷移前做一次就好 上雲後需求會變,Right Sizing 要持續做
CPU 低就一定可以縮小 還要看 Memory、Disk I/O、Network、尖峰時間與業務需求
使用率高就一定要換大台 也可能要用 Auto Scaling、快取、資料庫調校或架構優化
Right Sizing 只看 EC2 EC2 最常見,但 RDS、EBS、Lambda、容器資源也要檢查
CloudWatch 只是監控故障 CloudWatch 也可以用來判斷資源是否過度配置
Cost Explorer 只能看帳單 Cost Explorer 可以幫助找出成本趨勢與浪費資源
Trusted Advisor 只是安全工具 Trusted Advisor 也能提供成本與資源最佳化建議
開小一點一定比較好 太小會造成效能問題,正確做法是剛剛好
Right Sizing 可以完全靠感覺 應該靠監控數據與成本資料判斷

七、總結

AWS Right Sizing 的重點不是選最便宜,也不是選最大台, 而是根據實際工作負載選擇剛剛好的資源。 遷移前要先評估,上雲後也要持續透過 CloudWatch、Cost Explorer、Trusted Advisor 檢查與調整。

AWS Cloud Adoption Framework筆記

AWS CAF = 從業務、人員、治理、平台、安全、營運六個角度,規劃企業怎麼成功上雲。

一、AWS CAF 是什麼?

AWS Cloud Adoption Framework,簡稱 AWS CAF,是 AWS 提供的雲端採用與數位轉型方法論。 它不是一個 AWS 服務,而是一套幫助企業規劃上雲、管理轉型、建立能力與落實雲端價值的框架。

CAF 的重點不是只把系統搬到 AWS,而是讓企業從技術、流程、組織與產品層面一起轉型。

二、CAF 六大視角

Business People Governance Platform Security Operations
  • Business:確保雲端投資能帶來業務成果。
  • People:建立雲端文化、能力、領導力與組織變革。
  • Governance:管理風險、財務、計畫與治理標準。
  • Platform:建立企業級、可擴展的雲端平台。
  • Security:保護資料、身份、應用與基礎架構。
  • Operations:確保雲端服務可以穩定維運與交付。

三、AWS CAF 概念整理

類別 AWS 服務 / 概念 用途 白話說明
雲端採用框架 AWS CAF 規劃企業雲端採用與數位轉型 企業上雲的總體方法論
業務視角 Business Perspective 讓雲端投資對齊業務成果 上雲不是為了技術,是為了創造商業價值
人員視角 People Perspective 建立雲端文化、能力與組織變革 技術要成功,人跟組織也要跟上
治理視角 Governance Perspective 管理風險、預算、計畫與合規 避免上雲變成各做各的
平台視角 Platform Perspective 建立企業級雲端平台 打好雲端基礎建設
安全視角 Security Perspective 保護資料、身份、應用與基礎架構 確保雲端環境安全可信
營運視角 Operations Perspective 確保雲端服務穩定交付 上雲後要能監控、維護、處理事件
轉型領域 Technology 遷移與現代化系統 把舊系統搬上雲,並逐步雲端化
轉型領域 Process 數位化、自動化、最佳化流程 讓流程不要再靠人工土法煉鋼
轉型領域 Organization 調整團隊與營運模式 團隊圍繞產品與價值流運作
轉型領域 Product 建立新產品、服務與收入模式 用雲端創造新的商業模式
轉型階段 Envision 找出轉型願景與機會 先想清楚為什麼要上雲
轉型階段 Align 找出能力落差並建立行動計畫 看目前缺什麼能力,要補什麼
轉型階段 Launch 啟動試點專案 先小範圍實作,驗證價值
轉型階段 Scale 擴大成功模式 把成功經驗推廣到更大範圍

四、生活化比喻

AWS CAF 可以想成公司搬新總部的轉型計畫。

  • Business:老闆確認搬遷是否能帶來業務價值。
  • People:HR 與主管確保員工會使用新工具、適應新文化。
  • Governance:公司制度,管理預算、風險、流程與標準。
  • Platform:新總部的水電、網路、會議室與辦公區。
  • Security:保全、門禁、監視器與敏感區域控管。
  • Operations:大樓維運團隊,負責巡檢、維修與日常營運。

四個階段可以這樣記:

先想清楚 → 對齊能力 → 小範圍試做 → 全公司推廣
Envision → Align → Launch → Scale
    

五、整體概念流程圖

企業想要上雲 / 數位轉型
        │
        ▼
[AWS CAF]
提供一套雲端採用與轉型方法論
        │
        ▼
[六大視角 Perspectives]
Business     → 雲端是否帶來業務價值
People       → 人員、文化、組織是否跟得上
Governance   → 風險、財務、計畫是否可控
Platform     → 雲端平台是否穩定可擴展
Security     → 資料、身份、系統是否安全
Operations   → 上雲後是否能穩定維運
        │
        ▼
[四大轉型領域 Domains]
Technology   → 系統、資料、平台現代化
Process      → 流程數位化、自動化、最佳化
Organization → 團隊與營運模式重整
Product      → 新產品、新服務、新收入模式
        │
        ▼
[四個轉型階段 Phases]
Envision → 找出願景與業務機會
Align    → 找出能力落差與行動計畫
Launch   → 啟動試點並交付初步價值
Scale    → 擴大成功模式並落地效益
        │
        ▼
[最終目標]
讓企業不只是把系統搬上 AWS
而是透過雲端真正完成數位轉型
  

六、常見誤解與正確觀念

常見誤解 正確觀念
AWS CAF 是一個 AWS 服務 CAF 是框架與方法論,不是可以啟用的服務
CAF 只跟技術團隊有關 CAF 也包含業務、人員、治理、組織與產品
上雲就是把主機搬到 AWS 真正的雲端採用包含流程、組織、治理與商業模式改變
People Perspective 只是教育訓練 People 還包含文化、領導力、組織設計與人力轉型
Governance 只是資安控管 Governance 包含風險、財務、計畫、資料治理與投資效益
Platform 只是在開 EC2 Platform 是建立企業級、可擴展、可治理的雲端平台
Security 只是在設 IAM Security 包含身份、威脅偵測、弱點管理、資料保護與事件回應
Operations 是系統上線後才需要 Operations 從設計階段就要考慮監控、事件、變更、容量與持續性
Envision 可以跳過 沒有願景與業務目標,上雲容易變成單純技術搬遷
Launch 就是全面上線 Launch 通常是試點專案,先驗證價值
Scale 只是把機器開更多 Scale 是把成功模式擴展到更多團隊、系統與業務範圍

七、總結

AWS CAF 是企業上雲與數位轉型的方法論。 它透過 Business、People、Governance、Platform、Security、Operations 六大視角, 幫助企業從技術、流程、組織與產品面向規劃轉型,並透過 Envision、Align、Launch、Scale 四個階段逐步落地。

AWS Customer Carbon Footprint Tool筆記

Customer Carbon Footprint Tool = 幫你看 AWS 使用量背後的碳排放影響。

一、Customer Carbon Footprint Tool 是什麼?

AWS Customer Carbon Footprint Tool 是用來追蹤、衡量、檢視與預測 AWS 使用量所產生碳排放的工具。

它可以協助企業了解 AWS 帳號的碳排放量、碳排放節省量、 各服務的碳排影響,以及一段時間內的碳排放趨勢。

二、核心重點

碳排放追蹤 服務別分析 地區別分析 趨勢觀察 永續目標
  • 看碳排放量:了解 AWS 使用量造成多少碳排放。
  • 看碳排放趨勢:觀察碳排放是變多、變少,還是持平。
  • 看服務影響:找出哪些 AWS 服務造成較多碳排放。
  • 看地區差異:不同地區能源結構不同,碳排影響也可能不同。
  • 支援永續目標:適合 ESG、永續報告與內部治理需求。

三、AWS 服務與功能整理

類別 AWS 服務 / 功能 用途 白話說明
碳排放追蹤 AWS Customer Carbon Footprint Tool 追蹤 AWS 使用造成的碳排放 看你的 AWS 使用量產生多少碳排
費用與帳務入口 AWS Billing and Cost Management 管理帳單、成本與相關工具 從這裡進入碳排放工具
碳排放摘要 Emission Summary 顯示指定期間的碳排放狀況 看整體碳排放總覽
期間篩選 Start Month / End Month 選擇要查看的月份區間 查某段時間的碳排變化
服務分析 Emissions by Service 依 AWS 服務查看碳排放 看哪些服務影響比較大
地理分析 Savings by Geography 依地區查看碳排放節省量 看不同地區的碳排差異
趨勢追蹤 Emissions Over Time 追蹤碳排放變化 看碳排是上升還是下降
永續目標追蹤 Path to 100% Renewable Energy 查看 AWS 使用再生能源進展 看 AWS 朝再生能源目標的進度
成本關聯分析 Cost Explorer 分析 AWS 成本與使用趨勢 可搭配成本資料一起看資源使用狀況

四、生活化比喻

AWS Customer Carbon Footprint Tool 可以想成公司的用電與碳排放報表。

  • Billing and Cost Management:財務部,告訴你 AWS 花了多少錢。
  • Customer Carbon Footprint Tool:永續報表,告訴你 AWS 使用造成多少碳排。
  • Emission Summary:本月總用電與碳排總覽。
  • Emissions by Service:看哪個部門或設備最耗能。
  • Savings by Geography:看不同辦公室地點的碳排差異。
  • Emissions Over Time:看每個月碳排放是上升還是下降。
  • Path to 100% Renewable Energy:看距離全面使用綠電還有多遠。

五、整體概念流程圖

AWS 使用資源
例如:EC2、S3、RDS、Lambda、資料傳輸
        │
        ▼
[產生雲端使用量]
不同服務、不同地區、不同月份產生不同使用量
        │
        ▼
[AWS Customer Carbon Footprint Tool]
統計 AWS 使用量背後的碳排放影響
        │
        ▼
[選擇查詢期間]
Start Month → End Month
查看指定期間的碳排放資料
        │
        ▼
[查看碳排放摘要]
Emission Summary
了解整體碳排放狀況
        │
        ▼
[依服務分析]
Emissions by Service
找出哪些 AWS 服務碳排影響較大
        │
        ▼
[依地區分析]
Savings by Geography
了解不同地區的碳排放節省效果
        │
        ▼
[查看趨勢]
Emissions Over Time
觀察碳排放是上升、下降或持平
        │
        ▼
[支援永續決策]
調整架構、減少閒置資源、使用更有效率服務
        │
        ▼
[追蹤永續目標]
Path to 100% Renewable Energy
觀察 AWS 朝再生能源目標的進展
  

六、常見誤解與正確觀念

常見誤解 正確觀念
Customer Carbon Footprint Tool 是成本分析工具 它主要分析碳排放,不是分析費用
AWS 成本低就代表碳排低 成本與碳排有關聯,但不是完全等同
只有大型企業才需要看碳排放 只要公司有 ESG、永續或內部治理需求,就可以使用
碳排放只跟 EC2 有關 儲存、資料庫、網路、區域選擇都可能影響碳排放
使用 AWS 就完全沒有碳排放 雲端仍會使用能源,只是 AWS 透過規模化與再生能源降低影響
只要看總碳排就夠了 還要看服務別、地區別與時間趨勢,才知道怎麼改善
碳排放工具會自動幫你優化架構 它提供可視化與分析,實際改善仍要靠架構調整
永續性只跟環保部門有關 架構師、DBA、DevOps、FinOps 都會影響資源使用效率
看碳排放只是做報告 它也能幫助團隊找出資源浪費與架構改善方向

七、總結

AWS Customer Carbon Footprint Tool 是用來查看 AWS 使用量背後碳排放影響的工具。 它可以依時間、服務與地區檢視碳排放資料,協助企業追蹤永續目標, 並讓架構設計不只看成本與效能,也能考量環境影響。

AWS Well-Architected Tool筆記

Well-Architected Tool = 把 AWS 六大支柱變成一份架構健檢報告。

一、AWS Well-Architected Tool 是什麼?

AWS Well-Architected Tool 是 AWS 提供的架構評估工具。 它可以幫你用 Well-Architected Framework 的六大支柱來檢查系統架構, 找出風險,並提供改善建議。

它的目的不是自動幫你改系統,而是幫團隊用一致的方法檢查架構是否健康。

二、核心概念

Workload Lens Review Risk Improvement Plan Milestone
  • Workload:你要檢查的系統或應用程式。
  • Lens:架構檢查角度或檢查模板。
  • Review:依照問題逐題回答,檢查目前架構狀態。
  • Risk:根據答案產生高風險、中風險等結果。
  • Improvement Plan:提供改善建議與文件連結。
  • Milestone:保存某個時間點的架構評估快照。

三、AWS 服務與功能整理

類別 AWS 服務 / 功能 用途 白話說明
架構評估 AWS Well-Architected Tool 檢查架構是否符合最佳實務 AWS 官方架構健檢工具
評估對象 Workload 定義要檢查的系統或應用程式 你要被檢查的那套系統
檢查角度 Lens 套用不同架構檢查模板 用不同角度看你的系統
標準檢查 Well-Architected Framework Lens 用六大支柱檢查架構 最基本、最通用的架構檢查表
特定架構檢查 Serverless Lens 檢查 Serverless 架構 專門檢查 Lambda、API Gateway 這類設計
SaaS 架構檢查 SaaS Lens 檢查 SaaS 系統架構 適合多租戶 SaaS 服務
自訂檢查 Custom Lens 建立自己的檢查規則 公司可以放自己的架構標準
風險評估 High Risk / Medium Risk 標示架構風險等級 告訴你哪裡最需要優先處理
改善建議 Improvement Plan 提供改善項目與文件連結 告訴你下一步可以怎麼改
架構快照 Milestone 儲存某個時間點的評估結果 像版本紀錄,可比較改善前後差異

四、生活化比喻

AWS Well-Architected Tool 可以想成建築物安全健檢。

  • Workload:要檢查的一棟大樓。
  • Lens:不同類型的大樓檢查表。
  • Review Questions:逐項檢查消防、門禁、水電、結構、成本。
  • High Risk:很嚴重的風險,應優先處理。
  • Medium Risk:需要改善,但優先順序較低。
  • Improvement Plan:改善清單,告訴你哪裡要補強。
  • Milestone:每次健檢報告的存檔。

五、整體概念流程圖

開始使用 AWS Well-Architected Tool
        │
        ▼
[定義 Workload]
填寫系統名稱、描述、負責人、環境、Region、Account
        │
        ▼
[選擇 Lens]
Well-Architected Framework Lens
Serverless Lens
SaaS Lens
Custom Lens
        │
        ▼
[開始 Review]
依照問題逐題回答
        │
        ▼
[檢查六大支柱]
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization
Sustainability
        │
        ▼
[產生風險結果]
High Risk
Medium Risk
No Risk / Improvement Items
        │
        ▼
[查看 Improvement Plan]
取得改善建議、文件連結、最佳實務方向
        │
        ▼
[建立 Milestone]
保存目前架構評估快照
        │
        ▼
[執行改善]
調整架構、權限、監控、備份、成本、效能
        │
        ▼
[再次 Review]
比較改善前後差異,持續優化架構
  

六、常見誤解與正確觀念

常見誤解 正確觀念
Well-Architected Tool 會自動修正架構 它主要是評估與建議,不會自動幫你改架構
只要跑一次就夠了 架構會變,應該定期 Review
這只是填問卷,沒有實際價值 它可以幫團隊系統化找出風險與改善方向
只有大型系統才需要使用 小系統也可以用,尤其是準備上線或擴展前
High Risk 代表系統一定會壞 High Risk 代表風險較高,應優先處理
Medium Risk 可以完全不管 Medium Risk 也需要排入改善計畫,只是優先順序較低
Lens 只有一種 除了標準 Lens,還有 Serverless、SaaS、自訂 Lens
Milestone 是備份工具 Milestone 是架構評估快照,不是系統備份
回覆越漂亮越好 應該如實回答,否則報告沒有參考價值
它可以取代架構師判斷 它是輔助工具,最終仍需要架構師與團隊判斷

七、總結

AWS Well-Architected Tool 是用來做架構健檢的工具。 它會依照六大支柱檢查 Workload,找出高風險與中風險項目, 並提供改善計畫與文件連結,幫助團隊持續優化 AWS 架構。

AWS Well-Architected:Sustainability Pillar

AWS 永續性 = 少閒置、少浪費、用新硬體、用受管服務、資料放對地方。

一、Sustainability 是什麼?

Sustainability 是 Well-Architected Framework 中的永續性支柱, 重點是降低雲端工作負載對環境造成的影響。

它不是只談環保,而是要求我們用更有效率的方式使用運算、儲存、網路與資料庫資源。

二、AWS 永續性設計重點

減少閒置 提高使用率 受管服務 儲存分層 就近讀取 持續改善
  • 資源用剛好:不要長期開著沒人在用的運算資源。
  • 使用更有效率硬體:例如 Graviton 系列,提升效能與能源效率。
  • 善用受管服務:共享底層基礎設施,提高整體資源使用率。
  • 冷資料放冷儲存:不常用資料不要放在高成本、高效能儲存層。
  • 資料生命週期自動化:用規則自動封存、搬移或刪除資料。
  • 讓使用者就近讀取:減少不必要的遠距傳輸與後端壓力。

三、AWS 服務整理

類別 AWS 服務 用途 白話說明
自動擴展 EC2 Auto Scaling 自動增加或減少 EC2 數量 有流量才加機器,沒流量就減少
Serverless 運算 AWS Lambda 按事件執行程式碼 沒有執行就不佔用運算資源
Serverless Container AWS Fargate 不管理 EC2 也能跑容器 只專注容器,不用養主機
使用分析 Cost Explorer 分析資源使用與成本 看哪些資源可能浪費
高效率處理器 Graviton 系列 提供更佳效能與能源效率 用更省資源的 CPU 跑工作
彈性運算 EC2 T 系列 適合低到中等、偶爾爆量的工作 平常省,偶爾需要時衝一下
閒置容量利用 Spot Instances 使用 AWS 閒置運算容量 把原本可能閒置的資源拿來用
低頻檔案儲存 EFS-IA 儲存低頻存取的 EFS 檔案 不常用的共享檔案放便宜層
長期封存 S3 Glacier 儲存長期歸檔資料 很少讀的資料不要放昂貴儲存
低成本磁碟 EBS Cold HDD 低成本、大容量磁碟 適合低頻、大量資料場景
生命週期管理 S3 Lifecycle Configuration 自動轉移或刪除 S3 物件 舊資料自動搬到便宜層
智慧分層 S3 Intelligent-Tiering 依存取模式自動調整儲存層 系統幫你判斷資料該放哪一層
快照生命週期 Amazon Data Lifecycle Manager 管理 EBS Snapshot 生命週期 自動建立、保留、刪除快照
讀取擴展 RDS Read Replicas 分散資料庫讀取流量 讀很多時,把查詢分散出去
全球資料庫 Aurora Global Database 跨區域資料庫架構 讓全球使用者更快讀取資料
全球 NoSQL DynamoDB Global Tables 多區域 NoSQL 資料表 讓不同地區都能低延遲存取
全球快取 CloudFront CDN 與邊緣快取 使用者從最近節點拿資料

四、生活化比喻

AWS 永續性可以想成經營一棟節能辦公大樓。

  • Auto Scaling:自動控制冷氣,人多開強,人少降低用電。
  • Lambda:感應式電燈,有人來才亮,沒人就不耗電。
  • Fargate:共用辦公室,只租需要的空間,不用自己蓋整棟樓。
  • Graviton:更省電的新型冷氣,做一樣的事但耗電更少。
  • Spot Instances:使用空著的會議室,避免閒置浪費。
  • Cost Explorer:電費分析表,找出哪裡最耗電。
  • S3 Glacier:地下倉庫,適合放很久才拿一次的文件。
  • S3 Lifecycle:自動整理倉庫,新資料放近,舊資料搬遠。
  • CloudFront:各地分店,客人不用每次都跑總公司拿資料。
  • RDS Read Replica:分店查詢櫃台,幫總店分擔查詢壓力。

五、整體概念流程圖

雲端工作負載開始運行
        │
        ▼
[了解資源使用狀況]
Cost Explorer + CloudWatch
先看哪些資源使用率低、成本高、可能浪費
        │
        ▼
[運算資源用剛好]
EC2 Auto Scaling + Lambda + Fargate
有需求才使用資源,沒有需求就縮小或不執行
        │
        ▼
[採用更有效率硬體]
Graviton 系列 + EC2 T 系列
用更高效能、更省資源的運算選項
        │
        ▼
[善用閒置容量]
Spot Instances
把 AWS 閒置容量拿來執行可中斷工作
        │
        ▼
[資料放到正確儲存層]
S3 Glacier + EFS-IA + EBS Cold HDD
熱資料放高效能層,冷資料放低成本低頻層
        │
        ▼
[資料生命週期自動化]
S3 Lifecycle + S3 Intelligent-Tiering + Data Lifecycle Manager
資料依存取頻率自動搬移、封存或刪除
        │
        ▼
[全球讀取最佳化]
CloudFront + RDS Read Replicas + Aurora Global Database + DynamoDB Global Tables
讓使用者就近讀取資料,減少延遲與不必要傳輸
        │
        ▼
[持續改善]
定期檢查使用率、成本、架構與新服務
讓系統更省資源、更有效率、更少浪費
  

六、常見誤解與正確觀念

常見誤解 正確觀念
永續性只是環保議題,跟架構無關 永續性跟資源使用率、架構效率、儲存分層與運算選型都有關
成本低就一定比較永續 成本低通常有幫助,但還要看是否減少資源浪費與不必要運算
EC2 開著不用也沒差 閒置 EC2 會浪費成本與運算資源,應該關閉或用 Auto Scaling
Serverless 只是省錢工具 Serverless 也能減少閒置資源,讓運算更符合實際需求
所有資料都放標準 S3 最簡單 不常用資料應該移到 Glacier 或低頻儲存層
S3 Lifecycle 只是成本工具 它也能減少高效能儲存資源浪費,符合永續設計
Spot Instances 只是為了便宜 Spot 也能利用閒置容量,避免資源浪費
受管服務只是比較方便 受管服務共享底層資源,通常能提高整體使用效率
CloudFront 只是加速網站 CloudFront 也能減少遠距傳輸與後端負載
Read Replica 只是提升效能 Read Replica 也能讓使用者就近讀取,減少延遲與跨區流量
永續性做一次就好 永續性需要持續檢查,因為流量、資料量、服務與硬體都會變

七、總結

AWS 永續性不是少用雲端,而是讓雲端資源用得更有效率。 重點是減少閒置、使用更有效率的運算、善用受管服務、做好儲存分層, 並讓使用者就近取得資料,降低不必要的資源消耗。

AWS Well-Architected:Cost Optimization Pillar

AWS 成本最佳化 = 看得見成本、用得剛剛好、選對計費模式、持續調整。

一、Cost Optimization 是什麼?

Cost Optimization 指的是在能夠穩定運行系統、交付商業價值的前提下, 用盡可能低且合理的成本達成目標。

它不是單純砍成本,而是避免浪費,並讓每一筆雲端費用都花得有價值。

二、AWS 成本最佳化設計重點

按需付費 成本可視化 避免浪費 選對計費模式 善用受管服務 持續優化
  • 採用用多少付多少:例如 Lambda 沒執行就不產生運算費用。
  • 衡量資源效率:透過 CloudWatch 找出閒置或過度佈建資源。
  • 分析成本來源:使用 Tags、Cost Explorer、Cost and Usage Report 追蹤花費。
  • 選對計費模式:短期用 On-Demand,長期用 Reserved Instances 或 Savings Plans。
  • 善用低成本資源:可中斷工作可考慮 Spot Instances。
  • 冷資料放便宜儲存:長期封存資料適合放 S3 Glacier。
  • 持續調整:AWS 新功能有時可以直接降低成本。

三、AWS 服務整理

類別 AWS 服務 用途 白話說明
成本預算 AWS Budgets 設定預算與告警 花費快超過預算時提醒你
成本分析 Cost Explorer 分析 AWS 花費趨勢 看錢花在哪個服務、哪個時間
成本明細 Cost and Usage Report 產生詳細用量與費用報表 最細的 AWS 帳單明細
成本標籤 Cost Allocation Tags 依系統、環境、部門分攤成本 幫每筆花費貼標籤,方便追蹤
架構建議 Trusted Advisor 提供成本、安全、效能建議 幫你找出閒置或浪費的資源
監控資源 CloudWatch 監控 CPU、流量、使用率 看資源是不是開太大或太小
自動調整 Auto Scaling 根據需求自動增減資源 人多加機器,人少減機器
Serverless AWS Lambda 按執行次數與時間計費 沒有執行就不用付運算費
長期折扣 Reserved Instances 長期使用資源的折扣方案 確定會長期用,就預約省錢
彈性折扣 Savings Plans 承諾固定用量換取折扣 比 Reserved Instances 更有彈性的省錢方式
低價運算 Spot Instances 使用閒置 EC2 容量 很便宜,但可能被中斷
資料歸檔 S3 Glacier 長期低成本保存資料 很少查的備份、歷史資料放這裡
資料庫成本 Amazon RDS 受管資料庫 不用自己管 DB 主機,但開著就會收費
NoSQL 成本模式 DynamoDB On-Demand 依實際請求量付費 流量不固定時比較彈性

四、生活化比喻

AWS 成本最佳化可以想成經營一間公司。

  • AWS Budgets:每月預算表,快超支時提醒你。
  • Cost Explorer:信用卡帳單分析,看錢花在哪裡。
  • Tags:每筆支出都標記部門與專案名稱。
  • CloudWatch:水電表,觀察資源是不是浪費。
  • Auto Scaling:彈性排班,客人多就多排人,客人少就少排人。
  • Lambda:臨時工,有工作才來,做完就走。
  • RDS:固定租辦公室,就算沒人用也要付租金。
  • Reserved Instances:長租辦公室,確定會用就簽長約拿折扣。
  • Spot Instances:便宜臨時場地,便宜但可能被收回。
  • S3 Glacier:便宜倉庫,適合放很久才會拿一次的資料。

五、整體概念流程圖

AWS 系統開始運作
        │
        ▼
[建立成本可視化]
Tags + Cost Explorer + Cost and Usage Report
知道錢花在哪裡、誰在花、哪個服務最貴
        │
        ▼
[設定預算與告警]
AWS Budgets
快超過預算時提前通知
        │
        ▼
[檢查資源使用率]
CloudWatch + Trusted Advisor
找出 CPU 過低、閒置資源、過度佈建
        │
        ▼
[調整運算模式]
EC2 / Auto Scaling / Lambda
固定流量用 EC2,變動流量用 Auto Scaling 或 Serverless
        │
        ▼
[選擇合適計費方式]
On-Demand / Reserved Instances / Savings Plans / Spot
短期用按需,長期用折扣,可中斷用 Spot
        │
        ▼
[調整儲存成本]
S3 / S3 Glacier
常用資料放 S3,冷資料與歸檔放 Glacier
        │
        ▼
[調整資料庫成本]
RDS / DynamoDB On-Demand
固定使用要控規格,不固定流量可考慮按需模式
        │
        ▼
[持續最佳化]
Trusted Advisor + Cost Report + AWS 新功能
定期檢查、調整架構、利用新功能降低成本
  

六、常見誤解與正確觀念

常見誤解 正確觀念
成本最佳化就是一直砍成本 成本最佳化是用合理成本交付商業價值,不是盲目省錢
AWS 一定比地端便宜 AWS 有彈性,但如果資源亂開、不關、不監控,一樣會很貴
Lambda 一定比較便宜 Lambda 適合事件驅動與不固定流量,高頻長時間執行不一定便宜
RDS 沒人用就不會收費 RDS 只要建立並運行,就會持續產生成本
EC2 開大一點比較保險 長期低使用率代表浪費,應根據實際需求調整規格
Spot Instances 可以用在所有系統 Spot 可能被中斷,適合批次、測試、可重跑工作
Reserved Instances 買了就一定省 如果買了沒用滿,反而會浪費錢
S3 Glacier 適合所有資料 Glacier 適合低頻存取,不適合常常讀取或需要立即取回的資料
不用 Tags 也能管成本 沒有 Tags,很難知道是哪個專案、環境、團隊造成費用
受管服務比較貴 單看服務費可能較高,但可降低維運、人力與故障處理成本
成本最佳化做一次就好 成本最佳化是持續工作,需求、流量、AWS 功能都會變

七、總結

AWS 成本最佳化不是把所有資源砍到最低,而是讓每一筆費用都能對應到實際價值。 重點是看得見成本、避免過度佈建、選對計費模式,並持續根據使用狀況調整。

AWS Well-Architected:Performance Efficiency Pillar

AWS 效能效率 = 選對服務、自動擴展、善用快取、持續監控、理解取捨。

一、Performance Efficiency 是什麼?

Performance Efficiency 指的是有效率地使用運算資源來滿足系統需求, 並且在需求改變、技術演進時,仍然維持良好的效能。

簡單說,就是讓系統在不同流量、不同資料量、不同使用情境下, 都能維持穩定且合適的效能。

二、AWS 效能效率設計重點

選對服務 Serverless 自動擴展 快取 全球加速 持續監控
  • 善用先進技術:AWS 持續推出新服務與新功能,可能大幅改善架構。
  • 快速全球部署:需要多區域部署時,應該靠自動化快速完成。
  • 使用 Serverless:不需要管理伺服器,服務可依需求自動擴展。
  • 頻繁實驗:現在跑得動,不代表未來流量變 10 倍還跑得動。
  • 理解服務特性:不同服務適合不同場景,選錯服務會影響效能與成本。
  • 理解效能取捨:快取、資料一致性、成本、即時性都要一起考量。

三、AWS 服務整理

類別 AWS 服務 用途 白話說明
自動擴展 Auto Scaling 根據需求自動增加或減少資源 流量變大自動加機器,流量變小自動減少
Serverless 運算 AWS Lambda 執行事件驅動程式碼 不用管主機,有事件來就執行
虛擬主機 Amazon EC2 提供可控的運算資源 需要自己管理主機,但彈性高
磁碟效能 Amazon EBS 提供 EC2 使用的磁碟 需要高 I/O 或穩定磁碟效能時使用
物件儲存 Amazon S3 儲存大量檔案與物件 圖片、備份、Log、靜態檔案常放這裡
關聯式資料庫 Amazon RDS 受管關聯式資料庫 AWS 幫你管 DB 主機、備份與維護
高效能資料庫 Amazon Aurora AWS 雲端原生關聯式資料庫 更偏雲端化與高擴展的資料庫選項
快取 ElastiCache Redis / Memcached 快取服務 熱門資料先放記憶體,加速查詢
CDN CloudFront 全球內容快取與加速 讓使用者從最近的節點拿資料
監控 CloudWatch Metrics 收集效能指標 看 CPU、延遲、錯誤率與容量壓力
告警 CloudWatch Alarms 指標異常時通知或觸發動作 超過門檻就提醒你
儀表板 CloudWatch Dashboards 視覺化監控畫面 把系統狀態集中看
基礎架構自動化 CloudFormation 用模板建立 AWS 資源 快速、一致地部署環境
大量資料搬移 AWS Snowball 用實體設備搬移大量資料 網路傳太慢時,用設備寄送資料

四、生活化比喻

Performance Efficiency 可以想成經營一間餐廳。

  • Auto Scaling:客人變多時,自動加開櫃台與廚師。
  • Lambda:臨時外包人員,有任務才出現,做完就離開。
  • EC2:固定員工,彈性高,但要自己管理。
  • EBS:廚房設備,設備效能會影響出餐速度。
  • S3:大型倉庫,適合放大量食材、包材與備品。
  • RDS:訂單資料庫,負責保存訂單、會員與庫存資料。
  • Aurora:升級版訂單系統,更適合高流量需求。
  • ElastiCache:熱門菜先備好,不用每次從頭煮。
  • CloudFront:各地取餐點,客人不用都跑回總店。
  • CloudWatch:餐廳監控看板,看排隊人數、出餐時間、錯誤訂單數。
  • Snowball:搬整個倉庫時,直接叫貨櫃車。

五、整體概念流程圖

系統需求產生
例如:使用者變多、資料變大、查詢變慢
        │
        ▼
[選擇合適運算方式]
EC2 / Auto Scaling / Lambda
決定要自己管主機,還是使用 Serverless
        │
        ▼
[選擇合適儲存方式]
EBS / S3
依照磁碟效能、物件儲存、資料量選擇
        │
        ▼
[選擇合適資料庫]
RDS / Aurora
依照關聯式資料、讀寫壓力、擴展需求選擇
        │
        ▼
[提升讀取效能]
ElastiCache / CloudFront
用快取降低後端壓力,加快使用者存取速度
        │
        ▼
[全球化部署]
CloudFront / Multi-Region / CloudFormation
讓服務可以更快部署到不同區域
        │
        ▼
[監控效能]
CloudWatch Metrics + Alarms + Dashboards
觀察 CPU、延遲、錯誤率、Throttling
        │
        ▼
[持續調整與實驗]
測試不同架構與服務組合
找出效能、成本、維運之間的最佳平衡
        │
        ▼
[做出取捨]
速度 vs 成本
即時性 vs 快取
自管彈性 vs Serverless 簡化
網路傳輸 vs Snowball 搬移
  

六、常見誤解與正確觀念

常見誤解 正確觀念
效能不好就把 EC2 開大 不一定要 Scale Up,很多時候應該水平擴展或換服務
Serverless 一定比 EC2 快 Serverless 是少管理、好擴展,不代表所有場景都最快
有 Auto Scaling 就不用監控 Auto Scaling 也需要 CloudWatch 指標與告警判斷是否有效
CloudFront 只是加速圖片 CloudFront 可加速靜態與部分動態內容,也能降低來源伺服器壓力
ElastiCache 一定適合所有系統 快取適合讀多寫少或熱門資料,但要處理資料過期與一致性問題
RDS 不夠快就一定換 Aurora 要先確認瓶頸是 CPU、I/O、SQL、Index 還是連線數
S3 可以取代所有儲存 S3 是物件儲存,不是傳統檔案系統或區塊磁碟
EBS 效能都一樣 不同磁碟類型適合不同 I/O 與延遲需求
Snowball 是即時資料傳輸工具 Snowball 適合大量資料搬移,不適合即時同步
CloudWatch 只看有沒有掛掉 CloudWatch 更重要的是看趨勢、瓶頸、延遲、錯誤率與容量壓力
效能效率就是追求最快 真正的效能效率是效能、成本、穩定性、維運複雜度之間的平衡

七、總結

AWS 效能效率不是把機器開到最大,而是根據工作負載選對服務, 搭配 Auto Scaling、Lambda、ElastiCache、CloudFront、CloudWatch 等工具, 在效能、成本、穩定性與維運複雜度之間取得最佳平衡。

AWS Well-Architected:Reliability Pillar筆記

AWS 可靠性 = 自動擴展、自動復原、可監控、可備份、可重建、可切換。

一、Reliability 是什麼?

Reliability 是指系統在遇到基礎架構故障、服務中斷、設定錯誤, 或暫時性網路問題時,仍然能恢復並持續運作。

簡單說,可靠性就是: 系統壞了要能救回來,流量變大要能撐住,環境出問題要能快速切換。

二、AWS 可靠性設計重點

自動復原 水平擴展 不要猜容量 監控告警 備份復原 故障切換
  • 測試復原程序:不要等出事才知道備份不能用。
  • 自動從失敗中恢復:能自動修復,就不要只靠人工救火。
  • 水平擴展:流量變大時,增加更多節點,而不是只依賴單一大主機。
  • 不要猜容量:使用 Auto Scaling 依照實際需求調整資源。
  • 變更自動化:透過 CloudFormation 管理架構,方便部署與回滾。
  • 準備故障切換:透過 Route 53 與多區域架構,讓服務可以切到可用環境。

三、AWS 服務整理

類別 AWS 服務 用途 白話說明
權限基礎 IAM 控制使用者、角色與權限 避免有人權限太大,把系統搞壞
網路基礎 Amazon VPC 建立雲端網路 AWS 裡自己的網路環境
資源限制 Service Quotas / Service Limits 管理 AWS 資源上限 避免資源用到上限後服務中斷
架構檢查 Trusted Advisor 檢查帳號與架構建議 幫你看哪裡可能有風險
自動擴展 Auto Scaling 依流量自動增加或減少資源 人變多就加機器,人變少就減機器
監控告警 CloudWatch 監控指標、日誌與告警 看 CPU、流量、錯誤率有沒有異常
操作追蹤 CloudTrail 記錄 API 操作 查誰改了什麼、刪了什麼
設定追蹤 AWS Config 追蹤資源設定變更 看設定有沒有被改壞
備份復原 AWS Backup 集中管理備份 幫重要資料做備份與還原
架構重建 CloudFormation 用範本建立 AWS 資源 環境壞掉時,可以照設計圖重建
備份儲存 Amazon S3 儲存備份、檔案、資料 穩定耐用的雲端儲存空間
長期封存 S3 Glacier 長期保存低頻資料 很少用到的備份資料放這裡
DNS 切換 Route 53 全球 DNS 與流量導向 系統壞掉時,把流量切到別的地方

四、生活化比喻

AWS 可靠性可以想成一間 24 小時營業的便利商店。

  • IAM:員工權限管理,店員不能隨便動金庫。
  • VPC:店面動線設計,客人、員工、倉庫分開管理。
  • Service Quotas:店內容量限制,倉庫與冰箱都有上限。
  • Auto Scaling:尖峰時段自動加派人手。
  • CloudWatch:監控螢幕,看客流量、設備與收銀狀況。
  • CloudTrail:操作紀錄,知道誰改了價格、誰開了金庫。
  • AWS Config:稽核表,檢查設備與設定是否符合規範。
  • S3 / Backup:倉庫備份,重要資料不能只放一份。
  • CloudFormation:店面設計圖,店壞了可以照圖重建。
  • Route 53:客服導流,A 店不能營業就導到 B 店。

五、整體概念流程圖

使用者流量進入系統
        │
        ▼
[DNS 與流量導向]
Route 53
把使用者導向可用的服務入口
        │
        ▼
[網路基礎]
VPC + Subnet + Route Table
建立穩定的雲端網路環境
        │
        ▼
[權限控管]
IAM
避免錯誤操作或過大權限造成系統風險
        │
        ▼
[應用程式運行]
EC2 / ALB / RDS / 其他服務
承載實際系統與資料
        │
        ▼
[自動擴展]
Auto Scaling
流量增加時自動加資源
        │
        ▼
[監控與追蹤]
CloudWatch + CloudTrail + AWS Config
監控效能、追蹤操作、檢查設定變更
        │
        ▼
[備份與復原]
AWS Backup + S3 + S3 Glacier
保留資料備份,必要時可以還原
        │
        ▼
[基礎架構重建]
CloudFormation
環境損壞時,快速重建整套架構
        │
        ▼
[故障切換]
Route 53 + Multi-AZ / Multi-Region
某個環境壞掉時,將流量切到可用環境
  

六、常見誤解與正確觀念

常見誤解 正確觀念
可靠性就是備份 備份只是其中一部分,還包含監控、自動擴展、故障復原與切換
系統規格開大一點就可靠 單機再大也可能故障,應該用水平擴展與多可用區設計
Auto Scaling 只是省錢工具 Auto Scaling 更重要的是讓系統在流量變化下仍可用
有備份就一定能復原 備份要定期測試還原,否則出事時可能無法使用
CloudWatch 只是看 CPU CloudWatch 還可以看日誌、錯誤率、延遲與告警
CloudTrail 跟 CloudWatch 一樣 CloudTrail 看操作紀錄,CloudWatch 看系統狀態與指標
AWS Config 是監控效能用的 AWS Config 是追蹤設定變更與合規狀態
Service Quotas 不重要 資源用到上限時,可能會造成擴展失敗或服務中斷
CloudFormation 只是部署工具 它也能在環境損壞時快速重建基礎架構
Route 53 只是 DNS Route 53 也可以做健康檢查、流量導向與故障切換

七、總結

AWS 可靠性不是單靠一台大主機,而是靠自動擴展、監控告警、備份復原、 基礎架構自動化與故障切換,讓系統在出問題時仍能繼續服務。

AWS Well-Architected:Security Pillar筆記

AWS 安全 = 管身分、看紀錄、守網路、護資料、能復原。

一、Security 是什麼?

Security 是 AWS Well-Architected Framework 的重要支柱。 它的目的不是單純「防止被駭」,而是在系統提供商業價值的同時, 保護資訊、系統與資產,並降低長期風險。

好的安全設計,可以避免資料外洩、帳號濫用、服務中斷與災難性損失。

二、AWS 安全設計重點

身分管理 最小權限 可追蹤性 分層防禦 資料加密 自動化回應
  • 建立強大的身分基礎:集中管理帳號與權限,避免權限過大。
  • 啟用可追蹤性:記錄誰做了什麼、什麼時候做、從哪裡做。
  • 套用分層防禦:從邊緣、網路、主機、系統到資料都要保護。
  • 自動化安全管理:安全不能只靠人工,應盡量用規則與事件自動處理。
  • 保護資料:資料傳輸中與儲存中都應加密。
  • 準備事件回應:假設問題會發生,提前設計偵測、通知與復原流程。

三、AWS 安全服務整理

類別 AWS 服務 用途 白話說明
身分與權限 IAM 管理使用者、角色、權限 決定誰可以做什麼事
身分與權限 MFA 多因素驗證 登入時多一道保護
身分與權限 STS 臨時憑證 給短時間有效的通行證
身分與權限 AWS Organizations 集中管理多個 AWS 帳號 公司多帳號時統一控管
偵測與稽核 CloudTrail 記錄 API 操作 查誰在 AWS 做了什麼
監控 CloudWatch 監控指標、日誌、告警 看系統有沒有異常
合規檢查 AWS Config 檢查資源設定 檢查設定有沒有被亂改
網路防護 VPC / Security Group / NACL 控制網路與流量 建立雲端網路邊界與防火牆規則
邊緣防護 CloudFront CDN 與入口保護 讓流量先經過 AWS 邊緣節點
DDoS 防護 AWS Shield 防禦 DDoS 攻擊 防止大量惡意流量打爆服務
Web 防護 AWS WAF Web Application Firewall 擋 SQL Injection、XSS 等 Web 攻擊
弱點檢查 Amazon Inspector 掃描弱點 幫 EC2、Container 做安全健檢
資料加密 AWS KMS 管理加密金鑰 集中管理加密用的鑰匙
資料保護 S3 / EBS / RDS Encryption 資料儲存加密 檔案、磁碟、資料庫都要加密
事件自動化 EventBridge 事件觸發自動處理 發生異常時自動通知或處理
復原 CloudFormation 重建基礎架構 照設計圖快速恢復環境

四、生活化比喻

AWS 安全可以想成一棟公司的大樓安全管理。

  • IAM:門禁系統,決定誰可以進哪個區域。
  • MFA:門禁卡之外,還要手機驗證碼。
  • CloudTrail:監視器紀錄,記下誰做了什麼事。
  • CloudWatch:監控中心,觀察系統是否異常。
  • AWS Config:稽核人員,檢查設定是否符合規範。
  • VPC:公司園區,裡面再分不同區域。
  • Security Group:每個房間門口的門禁規則。
  • WAF:櫃台保全,擋掉可疑訪客。
  • Shield:防暴門,抵擋大量攻擊流量。
  • KMS:鑰匙管理中心,負責保管加密鑰匙。
  • CloudFormation:大樓設計圖,出事時可以快速重建。

五、整體概念流程圖

使用者 / 系統請求
        │
        ▼
[邊緣防護]
CloudFront + Shield + WAF
先擋掉 DDoS、大量攻擊、Web 攻擊
        │
        ▼
[網路防護]
VPC + Subnet + NACL + Security Group
控制哪些流量可以進入哪些資源
        │
        ▼
[身分與權限]
IAM + MFA + STS + Organizations
確認誰可以登入、誰可以操作、權限有多大
        │
        ▼
[主機與應用安全]
Patch + Inspector + 最小權限
降低主機與應用程式弱點
        │
        ▼
[資料保護]
KMS + S3 Encryption + EBS Encryption + RDS Encryption + HTTPS
保護傳輸中與儲存中的資料
        │
        ▼
[監控與稽核]
CloudTrail + CloudWatch + AWS Config
記錄操作、監控異常、檢查設定
        │
        ▼
[事件回應]
EventBridge + SNS + Lambda + IAM + CloudFormation
通知、自動處理、限制帳號、重建環境
  

六、常見誤解與正確觀念

常見誤解 正確觀念
用了 AWS,安全就都是 AWS 負責 AWS 負責雲端底層,客戶要負責帳號、權限、資料、網路與應用設定
IAM 直接給 Administrator 比較方便 應採用最小權限,用多少給多少
有 Security Group 就夠安全 Security Group 只是其中一層,還需要 IAM、WAF、加密、監控與稽核
CloudTrail 跟 CloudWatch 一樣 CloudTrail 看操作紀錄,CloudWatch 看系統指標、日誌與告警
AWS Config 是效能監控工具 AWS Config 是檢查資源設定與合規狀態
WAF 可以防所有攻擊 WAF 主要防 Web 層攻擊,不能取代 IAM、VPC、加密與弱點管理
安全事件發生再處理就好 應事先設計事件回應流程、自動化通知與復原機制

七、總結

AWS 安全不是單一服務,而是一整套架構設計。 從身分、網路、資料、監控到事件回應,每一層都要有防護。

AWS Security and Compliance 總整理

AWS Security and Compliance 總整理 一、核心概念 AWS 安全與合規不是靠單一服務,而是透過多層防護來完成。 從外部流量防護、身分權限、資料加密、設定稽核、威脅偵測,到集中管理與事件調查, 每一個服務...