AWS Security and Compliance 總整理

AWS Security and Compliance 總整理

一、核心概念

AWS 安全與合規不是靠單一服務，而是透過多層防護來完成。 從外部流量防護、身分權限、資料加密、設定稽核、威脅偵測，到集中管理與事件調查， 每一個服務都有不同的角色。

簡單記法：
Shield / WAF / Network Firewall 負責擋攻擊；
KMS / CloudHSM / ACM 負責加密與憑證；
GuardDuty / Inspector / Macie 負責找風險；
CloudTrail / Config 負責記錄與合規；
Security Hub / Detective 負責集中管理與調查。

二、AWS 服務整理表

AWS 服務	用途	白話說明
Shared Responsibility Model	定義 AWS 與使用者責任	AWS 管底層基礎設施，使用者管自己的設定、資料與權限。
AWS Shield	DDoS 防護	幫 AWS 資源抵擋大量流量攻擊。
AWS WAF	Web 防火牆	根據規則過濾 HTTP / HTTPS 請求。
AWS KMS	金鑰管理	用來建立與管理加密金鑰。
CloudHSM	硬體加密模組	你自己管理金鑰，AWS 管理底層硬體。
ACM	SSL / TLS 憑證管理	幫網站、ALB、CloudFront 等服務使用 HTTPS。
AWS Artifact	合規文件	可以下載 PCI、ISO、SOC 等合規報告。
GuardDuty	威脅偵測	分析 CloudTrail、VPC Flow Logs、DNS Logs 找可疑行為。
Inspector	弱點掃描	檢查 EC2、ECR Image、Lambda 是否有軟體漏洞。
Network Firewall	VPC 網路防火牆	保護 VPC 進出流量，抵擋網路層攻擊。
AWS Config	設定追蹤與合規檢查	記錄資源設定變更，也能檢查設定是否符合規範。
Macie	敏感資料偵測	找出 S3 裡面的個資與敏感資料。
CloudTrail	API 稽核	記錄誰在 AWS 帳號中做了什麼操作。
Security Hub	安全發現集中管理	把多個安全服務與多個帳號的告警集中管理。
Detective	事件根因分析	協助調查安全事件發生的原因。
IAM Access Analyzer	外部存取分析	找出哪些資源被分享到信任範圍之外。
Firewall Manager	集中管理安全規則	跨 AWS Organization 管理 WAF、Shield、Security Group 等規則。

三、生活化比喻

可以把 AWS 帳號想成一棟企業大樓。 Shield 是外面的防暴盾牌，WAF 是大門警衛，Network Firewall 是整棟大樓的網路管制站。 KMS 是鑰匙管理員，CloudHSM 是你自己掌控的高級保險箱。 CloudTrail 是監視器，Config 是資產盤點員，GuardDuty 是 AI 保全， Inspector 是安檢人員，Macie 是個資巡查員。 Security Hub 是中央保全控制室，Detective 則是負責追查原因的偵探。

四、整體流程圖

使用者 / 外部流量 │ ▼ [邊界防護] Shield + WAF + Network Firewall │ ▼ [身分與權限] IAM + IAM Access Analyzer + Root User 控制 │ ▼ [資料保護] KMS + CloudHSM + ACM │ ▼ [設定與合規] AWS Config + AWS Artifact │ ▼ [威脅與弱點偵測] GuardDuty + Inspector + Macie │ ▼ [稽核與記錄] CloudTrail │ ▼ [集中管理與調查] Security Hub + Detective + Firewall Manager

五、常見誤解

常見誤解	正確觀念
GuardDuty 是掃毒軟體	不是。GuardDuty 是分析 Log 與行為，找出可疑資安活動。
Inspector 跟 GuardDuty 一樣	不一樣。Inspector 找漏洞，GuardDuty 找可疑行為。
CloudTrail 是監控 CPU 的	不是。CloudTrail 是記錄 API 操作。
Macie 可以掃所有 AWS 資料	Macie 主要用來偵測 S3 裡的敏感資料。
Security Hub 會取代 GuardDuty	不會。Security Hub 是集中平台，GuardDuty 是安全發現來源之一。
Root user 可以日常使用	不建議。Root user 權限太大，應該只在必要時使用。

AWS成本管理工具比較

AWS Billing and Costing Tools 總整理

AWS 成本管理工具可以幫你做到：事前估算、事中追蹤、事後分析、即時告警、長期最佳化。

一、AWS 成本工具總覽

AWS 提供多種帳單與成本管理工具。每個工具解決的問題不同： 有些用來估算成本，有些用來追蹤帳單，有些用來分析趨勢， 有些用來偵測異常，有些則用來降低成本。

成本管理的重點不是只看帳單金額，而是要知道： 錢花在哪裡、誰造成成本、未來會不會變高、哪裡可以省錢。

簡單記法： 先估算，再追蹤，再分析，再告警，最後最佳化。

二、AWS 專家口語化說明

AWS 成本工具可以分成幾個層次。

• 估算還沒開資源前，用 Pricing Calculator 算大概費用。
• 總覽想快速看帳單，用 Billing Dashboard。
• 分類想知道哪個部門或專案花錢，用 Cost Allocation Tags。
• 明細要查最完整費用資料，用 Cost and Usage Report。
• 分析要看趨勢與預測，用 Cost Explorer。
• 告警要避免超支，用 Billing Alarms 或 AWS Budgets。
• 省錢要最佳化成本，用 Compute Optimizer 與 Savings Plans。
• 異常要抓突然暴增費用，用 Cost Anomaly Detection。
• 上限要避免服務打到限制，用 Service Quotas。

三、AWS 服務與用途表格

AWS 服務 / 工具	用途	白話說明
AWS Compute Optimizer	資源最佳化建議	分析資源是否開太大或太小，協助降低成本與改善效能。
AWS Pricing Calculator	預估成本	在正式建立 AWS 資源前，先試算大概要花多少錢。
Billing Dashboard	帳單總覽	快速查看本月成本、上月成本與預估成本。
Cost Allocation Tags	成本分類	用 Tag 區分部門、專案、環境，方便分攤成本。
Cost and Usage Report	詳細帳單報表	AWS 最完整的成本與使用量明細資料。
Cost Explorer	成本分析與預測	用圖表看成本趨勢，也可以預測未來成本。
Billing Alarms	帳單告警	實際帳單超過門檻時通知，Billing Metrics 位於 us-east-1。
AWS Budgets	預算控管	可追蹤成本、用量、Reserved Instances、Savings Plans 並發出告警。
Savings Plans	長期使用折扣	承諾每小時固定花費，換取比 On-Demand 更低的價格。
Cost Anomaly Detection	成本異常偵測	使用機器學習找出突然暴增或不正常的 AWS 花費。
Service Quotas	服務配額管理	監控 AWS 服務使用上限，接近限制時通知，也可申請提高配額。

四、生活化比喻

可以把 AWS 成本工具想成公司財務管理系統。

生活場景	AWS 對應
買設備前先請廠商報價	AWS Pricing Calculator
信用卡帳單首頁	Billing Dashboard
發票貼上部門與專案標籤	Cost Allocation Tags
完整交易明細	Cost and Usage Report
記帳 App 圖表	Cost Explorer
刷卡超額提醒	Billing Alarms
每月預算表	AWS Budgets
長期合約折扣	Savings Plans
設備健檢顧問	AWS Compute Optimizer
信用卡異常刷卡通知	Cost Anomaly Detection
公司資源申請上限表	Service Quotas

五、整體流程圖

AWS 成本管理工具總覽 │ ├─ 1. 使用前：先估算成本 │ └─ AWS Pricing Calculator │ ├─ 2. 使用中：查看帳單總覽 │ └─ Billing Dashboard │ ├─ 3. 使用中：分類成本 │ └─ Cost Allocation Tags │ ├─ 4. 使用中：查詳細明細 │ └─ Cost and Usage Report │ ├─ 5. 使用中：分析與預測 │ └─ Cost Explorer │ ├─ 6. 使用中：設定告警與預算 │ ├─ Billing Alarms │ └─ AWS Budgets │ ├─ 7. 成本最佳化 │ ├─ AWS Compute Optimizer │ └─ Savings Plans │ ├─ 8. 異常偵測 │ └─ Cost Anomaly Detection │ └─ 9. 配額管理 └─ Service Quotas

六、工具選擇速查表

你想解決的問題	建議工具
還沒使用 AWS，想先估算成本	AWS Pricing Calculator
想快速看目前帳單	Billing Dashboard
想知道哪個部門或專案花錢	Cost Allocation Tags
想查最完整成本明細	Cost and Usage Report
想看成本趨勢與未來預測	Cost Explorer
帳單超過門檻要通知	Billing Alarms
要設定正式預算與告警	AWS Budgets
想找出資源開太大造成浪費	AWS Compute Optimizer
長期穩定使用 AWS，想省錢	Savings Plans
想自動偵測異常花費	Cost Anomaly Detection
想知道服務是否快達到上限	Service Quotas

總結： AWS 成本管理不是單一工具可以完成。 Pricing Calculator 負責事前估算，Billing Dashboard 與 Cost Explorer 負責追蹤分析， Budgets 與 Alarms 負責提醒，Compute Optimizer、Savings Plans 與 Cost Anomaly Detection 負責最佳化與異常偵測。

AWS 帳號管理筆記

 AWS 帳號最佳實務就是讓帳號集中管理、權限受控、日誌可追、成本可分、資源可標準化。

一、AWS 帳號管理核心觀念

如果你要管理多個 AWS 帳號，建議使用 AWS Organizations。 它可以把多個帳號集中管理，並搭配 SCP 控制每個帳號可以做什麼、不能做什麼。

如果想更快速建立安全標準化的多帳號環境，可以使用 AWS Control Tower。 它建立在 AWS Organizations 之上，可以協助你建立符合安全最佳實務的帳號架構。

簡單記法： Organizations 管帳號，SCP 管限制，Control Tower 幫你快速建立標準化多帳號環境。

二、AWS 專家口語化說明

AWS 帳號管理不是只建立帳號而已，重點是後續能不能控管。

你要知道誰可以做什麼、資源屬於誰、費用算在哪個部門、設定有沒有被改過、 出問題時能不能查 API 紀錄，這些才是帳號治理的重點。

所以要搭配 IAM、Tags、CloudTrail、AWS Config、Trusted Advisor、CloudFormation、 Service Catalog 等工具，讓整個 AWS 環境可控、可查、可維護。

三、AWS 服務與用途表格

AWS 服務 / 概念	用途	白話說明
AWS Organizations	多帳號集中管理	把多個 AWS 帳號集中在同一個組織下管理。
SCP	限制帳號權限	控制某個帳號或 OU 最多可以做什麼、不能做什麼。
AWS Control Tower	快速建立多帳號環境	幫你用安全最佳實務建立 Landing Zone。
Tags	資源標籤	幫 EC2、RDS、S3 等資源加上分類資訊。
Cost Allocation Tags	成本分類標籤	依照部門、專案、環境追蹤 AWS 成本。
IAM	身分與權限管理	控制誰可以登入、可以操作哪些 AWS 資源。
MFA	多因素驗證	登入時多一層驗證，降低帳號被盜風險。
AWS Config	資源設定追蹤	記錄資源設定變化與合規狀態。
AWS CloudFormation	基礎設施自動化部署	用模板跨帳號、跨 Region 建立標準化資源。
AWS Trusted Advisor	帳號健康檢查	檢查成本、安全、效能、容錯、服務限制等問題。
Amazon S3	日誌保存	可集中保存服務日誌與存取日誌。
CloudWatch Logs	日誌集中管理	收集與查詢 AWS 服務或應用程式日誌。
AWS CloudTrail	API 呼叫紀錄	記錄誰在什麼時間對 AWS 做了什麼操作。
AWS Service Catalog	標準化資源自助入口	讓使用者建立管理員預先定義好的標準資源。

四、生活化比喻

可以把 AWS 多帳號管理想成管理一間大型公司。

生活場景	AWS 對應
總公司管理所有分公司	AWS Organizations
公司規章限制員工不能做危險行為	SCP
標準化開分公司流程	AWS Control Tower
資產貼上部門與負責人標籤	Tags / Cost Allocation Tags
門禁與身份權限控管	IAM / MFA / Least Privilege
監視器與門禁紀錄	AWS CloudTrail
資產變更紀錄	AWS Config
企業健檢顧問	AWS Trusted Advisor
核准採購清單	AWS Service Catalog

五、整體流程圖

AWS 帳號最佳實務 │ ├─ 1. 多帳號集中管理 │ ├─ AWS Organizations │ └─ SCP │ ├─ 2. 快速建立安全多帳號環境 │ └─ AWS Control Tower │ ├─ 3. 權限與身分安全 │ └─ IAM │ ├─ 啟用 MFA │ ├─ 最小權限 │ ├─ 密碼政策 │ └─ 密碼輪替 │ ├─ 4. 成本與資源管理 │ ├─ Tags │ └─ Cost Allocation Tags │ ├─ 5. 變更與合規追蹤 │ └─ AWS Config │ ├─ 6. 標準化部署 │ └─ AWS CloudFormation │ ├─ 7. 日誌與稽核 │ ├─ CloudTrail │ ├─ CloudWatch Logs │ └─ Amazon S3 / Logging Account │ ├─ 8. 帳號健康檢查 │ └─ AWS Trusted Advisor │ ├─ 9. 帳號被入侵時 │ ├─ 修改 Root Password │ ├─ 刪除或停用可疑 Passwords / Keys │ └─ 聯絡 AWS Support │ └─ 10. 使用者自助建立標準資源 └─ AWS Service Catalog

六、帳號被入侵時的處理

處理步驟	目的
修改 Root Password	防止攻擊者繼續使用最高權限帳號。
刪除或停用可疑 Passwords / Access Keys	避免被盜憑證繼續操作 AWS 資源。
檢查 CloudTrail	追查攻擊者做了哪些 API 操作。
聯絡 AWS Support	請 AWS 協助處理帳號安全事件。

總結： AWS 帳號管理的核心是集中治理、權限控管、日誌稽核、成本追蹤與標準化資源建立。 Organizations、Control Tower、IAM、CloudTrail、Config、Service Catalog 是帳號治理的重要組合。

AWS Support Plans 重點整理

AWS Support Plans 是依照系統重要性，選擇不同等級的 AWS 技術支援方案。

一、什麼是 AWS Support Plans？

AWS Support Plans 是 AWS 提供的支援方案。 不同方案會提供不同層級的技術支援、回應時間、Trusted Advisor 檢查項目與專屬服務。

剛建立 AWS 帳號時，預設是 Basic Support，這是免費方案。 如果系統開始進入開發、正式上線或支援核心業務，就可以依需求升級支援方案。

簡單記法： 系統越重要，支援方案就要越高階。

二、AWS 專家口語化說明

如果只是學習或測試，用 Basic Support 就夠。

如果是開發階段，需要用 Email 問 AWS 問題，可以用 Developer Support。

如果是正式系統上線，建議至少使用 Business Support，因為它提供 24/7 電話、Email、Chat 支援， 也可以使用 Trusted Advisor 完整檢查。

如果是公司重要系統或核心業務系統，就要考慮 Enterprise On-Ramp 或 Enterprise Support。

三、AWS Support Plans 比較表

支援方案	用途	白話說明
Basic Support	免費基本支援	適合學習、測試、個人帳號使用。
Developer Support	開發階段支援	可以用 Email 開 Case 詢問 AWS 問題。
Business Support	正式系統支援	適合 Production 系統，有 24/7 電話、Email、Chat 支援。
Enterprise On-Ramp Support	重要業務系統支援	適合 Production 或 Business-Critical 工作負載。
Enterprise Support	關鍵任務系統支援	適合 Mission-Critical 系統，有指定 TAM 與最快回應。

四、重要功能比較

功能 / 服務	用途	適用方案
AWS Health Dashboard	查看個人化 AWS 服務健康狀態	Basic 以上
Trusted Advisor Core Checks	基本 AWS 帳號健檢	Basic 以上
Trusted Advisor Full Checks	完整 AWS 帳號健檢	Business 以上
AWS Support API	程式化存取 Trusted Advisor 與支援資料	Business 以上
Cloud Support Engineers	24/7 技術支援	Business 以上
Technical Account Manager	技術客戶經理	Enterprise On-Ramp / Enterprise
Concierge Support Team	帳務與帳號最佳實務支援	Enterprise On-Ramp / Enterprise
AWS Incident Detection and Response	重大事件偵測與回應	Enterprise 可額外付費使用

五、回應時間比較

情境	Developer	Business	Enterprise On-Ramp	Enterprise
一般指引	24 個營業小時內	24 小時內	24 小時內	24 小時內
系統受影響	12 個營業小時內	12 小時內	12 小時內	12 小時內
正式系統受影響	不適用	少於 4 小時	少於 4 小時	少於 4 小時
正式系統停擺	不適用	少於 1 小時	少於 1 小時	少於 1 小時
業務關鍵系統停擺	不適用	不適用	少於 30 分鐘	少於 15 分鐘

六、生活化比喻

可以把 AWS Support Plans 想成汽車道路救援方案。

• Basic像免費說明書與官方網站，適合自己查資料。
• Developer像營業時間 Email 問維修廠，適合開發階段。
• Business像 24 小時道路救援，適合正式系統。
• Enterprise On-Ramp像公司車隊支援，有一組技術顧問協助。
• Enterprise像總裁專車等級支援，有指定顧問與最快回應。

七、整體流程圖

AWS Support Plans │ ├─ Basic Support │ ├─ 免費 │ ├─ 文件 / 白皮書 / 論壇 │ ├─ AWS Health Dashboard │ └─ Trusted Advisor 7 個核心檢查 │ ├─ Developer Support │ ├─ 包含 Basic │ ├─ 營業時間 Email 支援 │ ├─ 可開 Support Case │ ├─ 一般指引：24 個營業小時內 │ └─ 系統受影響：12 個營業小時內 │ ├─ Business Support │ ├─ 包含 Developer │ ├─ Trusted Advisor 完整檢查 │ ├─ AWS Support API │ ├─ 24/7 Phone / Email / Chat │ ├─ 正式系統受影響：少於 4 小時 │ └─ 正式系統停擺：少於 1 小時 │ ├─ Enterprise On-Ramp Support │ ├─ 包含 Business │ ├─ TAM Pool │ ├─ Concierge Support Team │ ├─ Operations Review │ ├─ Well-Architected Review │ └─ 業務關鍵系統停擺：少於 30 分鐘 │ └─ Enterprise Support ├─ 包含 Enterprise On-Ramp ├─ 指定 TAM ├─ Concierge Support Team ├─ AWS Incident Detection and Response └─ 業務關鍵系統停擺：少於 15 分鐘

八、選擇建議

使用情境	建議方案	原因
學習、測試、個人帳號	Basic Support	免費，基本文件與健康狀態資訊已足夠。
開發階段需要問 AWS 問題	Developer Support	可透過 Email 開 Case 詢問技術問題。
正式 Production 系統	Business Support	有 24/7 支援、完整 Trusted Advisor 檢查與較快回應。
重要業務系統	Enterprise On-Ramp Support	有 TAM Pool、營運檢查與更快的關鍵系統支援。
核心任務系統，停機影響重大	Enterprise Support	有指定 TAM，業務關鍵系統停擺回應時間最短。

總結： Basic 適合學習，Developer 適合開發，Business 適合正式系統， Enterprise On-Ramp 適合重要業務系統，Enterprise 適合關鍵任務系統。

AWS Trusted Advisor 重點整理

AWS Trusted Advisor 是 AWS 帳號的健康檢查工具，幫你找出成本、效能、安全、容錯與服務限制問題。

一、什麼是 AWS Trusted Advisor？

AWS Trusted Advisor 是 AWS 提供的帳號檢查服務。 你不需要安裝任何東西，它會直接檢查你的 AWS 帳號，並提供改善建議。

它會從多個面向檢查你的 AWS 環境，例如成本是否浪費、安全設定是否有風險、 架構是否有容錯能力，以及服務使用量是否快達到限制。

簡單記法： Trusted Advisor 就像 AWS 的健檢顧問，幫你指出帳號裡可能需要改善的地方。

二、AWS 專家口語化說明

Trusted Advisor 不是幫你自動修復問題，而是幫你發現問題。

例如它可能會提醒你：S3 Bucket 權限太開放、Security Group 開太大、 EBS Snapshot 被公開、RDS Snapshot 被公開，或是 Root Account 還在被使用。

如果你使用 Business 或 Enterprise Support Plan，就可以看到更完整的檢查項目， 也可以透過 AWS Support API 用程式化方式取得 Trusted Advisor 結果。

三、Trusted Advisor 六大檢查類別

類別	用途	白話說明
Cost Optimization	成本最佳化	找出可能浪費錢的資源。
Performance	效能檢查	檢查資源設定是否可能影響效能。
Security	安全檢查	檢查 S3、Security Group、Snapshot、Root Account 等安全風險。
Fault Tolerance	容錯能力	檢查架構是否具備備援與高可用能力。
Service Limits	服務限制	檢查 AWS 服務是否快達到使用上限。
Operational Excellence	營運最佳化	檢查操作與管理是否符合最佳實務。

四、AWS 服務與概念表格

AWS 服務 / 概念	用途	白話說明
AWS Trusted Advisor	AWS 帳號健康檢查	幫你檢查成本、效能、安全、容錯、服務限制與營運問題。
Core Checks	核心檢查	基本可用的 Trusted Advisor 檢查項目。
Full Set of Checks	完整檢查	需要 Business 或 Enterprise Support Plan 才能使用。
AWS Support Plan	AWS 支援方案	支援方案等級會影響可使用的 Trusted Advisor 檢查項目。
AWS Support API	程式化存取 Trusted Advisor	Business / Enterprise Support 可透過 API 讀取檢查結果。
S3 Bucket Permissions	S3 權限檢查	檢查 Bucket 是否有不安全的公開存取。
Security Group Ports	Security Group 檢查	檢查 Port 是否對外開放過大。
EBS Public Snapshot	EBS Snapshot 安全檢查	檢查 EBS Snapshot 是否被公開。
RDS Public Snapshot	RDS Snapshot 安全檢查	檢查 RDS Snapshot 是否被公開。
Root Account Usage	Root 帳號使用檢查	檢查是否仍使用 Root Account 操作 AWS。

五、生活化比喻

可以把 AWS Trusted Advisor 想成企業健檢顧問。

公司請顧問來檢查辦公室時，顧問會看電費是否浪費、門禁是否太鬆、 消防與備援設備是否正常、倉庫容量是否快滿。

Trusted Advisor 也是一樣，它會幫你檢查 AWS 帳號中可能需要改善的地方。

生活場景	AWS 對應
企業健檢顧問	AWS Trusted Advisor
電費浪費	Cost Optimization
門禁太鬆	Security
設備效能不好	Performance
沒有備援設備	Fault Tolerance
倉庫快滿	Service Limits
流程不標準	Operational Excellence

六、整體流程圖

AWS 帳號 │ ├─ EC2 ├─ S3 ├─ RDS ├─ EBS ├─ Security Groups ├─ IAM / Root Account └─ 其他 AWS 資源 │ ▼ AWS Trusted Advisor 自動檢查 │ ├─ Cost Optimization │ └─ 是否有浪費成本的資源 │ ├─ Performance │ └─ 是否有影響效能的設定 │ ├─ Security │ ├─ S3 Bucket 是否公開 │ ├─ Security Group 是否過度開放 │ ├─ EBS Snapshot 是否公開 │ ├─ RDS Snapshot 是否公開 │ └─ 是否使用 Root Account │ ├─ Fault Tolerance │ └─ 是否有足夠備援與高可用設計 │ ├─ Service Limits │ └─ 是否快達到 AWS 服務上限 │ └─ Operational Excellence └─ 操作是否符合最佳實務 │ ▼ 產生 Recommendations │ ├─ 正常項目 ├─ 需要調查項目 └─ 建議處理項目 │ ▼ 管理者檢查與改善 │ ├─ 修正安全設定 ├─ 優化成本 ├─ 調整效能 ├─ 補強備援 └─ 申請服務限制提升

總結： AWS Trusted Advisor 是 AWS 帳號的健康檢查工具。 它會從成本、效能、安全、容錯、服務限制與營運最佳化角度提供建議。 基本檢查可直接使用，完整檢查需要 Business 或 Enterprise Support Plan。

AWS Service Quotas 重點整理

AWS Service Quotas 是用來查看、監控與申請提高 AWS 服務使用上限的工具。

一、什麼是 AWS Service Quotas？

在 AWS 中，每個服務都有使用限制，這些限制稱為 Quotas，也就是服務配額。

例如 Lambda 同時執行數量、EC2 Instance 數量、VPC 數量、Elastic IP 數量， 都可能有預設上限。

如果你的資源使用量快達到上限，可能會導致新的資源無法建立， 或系統無法繼續擴展。

二、AWS 專家口語化說明

AWS Service Quotas 就像 AWS 帳號的資源上限管理表。

它可以讓你知道目前每個服務的上限是多少、現在用了多少， 以及是否快要碰到限制。

簡單記法： Service Quotas 幫你避免「資源開到一半，才發現不能再開」。

三、AWS 服務與概念表格

AWS 服務 / 概念	用途	白話說明
AWS Service Quotas	管理 AWS 服務配額	查看各服務目前上限、使用量，並可申請提高配額。
Quota	服務配額 / 使用上限	AWS 對每個服務設定的使用限制。
CloudWatch Alarms	配額告警	當使用量接近配額時發出通知。
AWS Lambda Concurrent Executions	Lambda 同時執行數量	Lambda 同時可以跑多少個執行個體。
Amazon EC2	虛擬主機	EC2 可建立數量也會受到配額限制。
Amazon VPC	虛擬網路	每個 Region 可建立的 VPC 數量有限。
Elastic IP	固定公網 IP	每個帳號每個 Region 可用數量有限。
Security Group	防火牆規則群組	Security Group 數量與規則數也有配額。
Quota Increase Request	配額提升申請	如果上限不夠，可以向 AWS 申請增加。

四、生活化比喻

可以把 AWS Service Quotas 想成公司資源申請上限表。

公司可能規定每個部門最多只能申請 10 台筆電、2 台印表機、5 間會議室。 這些就是資源配額。

如果某個部門快達到上限，系統就應該提醒管理員。 如果真的需要更多資源，可以申請提高上限； 如果是資源被亂用，就應該回收不必要的資源。

生活場景	AWS 對應
公司資源上限	AWS Service Quotas
最多可申請幾台筆電	某服務的 Quota
快達到上限時提醒	CloudWatch Alarm
申請更多設備	Request Quota Increase
回收不用的設備	關閉或刪除不必要 AWS 資源

五、整體流程圖

AWS 各服務都有使用上限 │ ├─ Lambda concurrent executions ├─ EC2 Instance 數量 ├─ VPC 數量 ├─ Elastic IP 數量 └─ Security Group 數量 │ ▼ AWS Service Quotas │ ├─ 查看目前服務配額 ├─ 查看目前使用狀況 └─ 判斷是否接近上限 │ ▼ 接近或達到配額 │ ├─ 建立 CloudWatch Alarm ├─ 發送通知給管理者 └─ 提醒可能影響資源建立或系統擴展 │ ▼ 管理者決策 │ ├─ 真的需要更多資源 │ └─ 申請 Quota Increase │ └─ 發現資源開太多 └─ 關閉或刪除不必要資源 │ ▼ 維持 AWS 帳號資源可控、可擴展

六、Service Quotas 的管理重點

管理重點	說明
不要等到打到上限才處理	正式系統要提前監控配額，避免擴展失敗。
搭配 CloudWatch Alarms	接近配額時主動通知管理者。
需要時申請提高配額	如果是正常業務成長，可以直接向 AWS 申請增加上限。
資源異常增加時要檢查	如果是測試資源或錯誤配置導致用量暴增，應先清理資源。

總結： AWS Service Quotas 的核心價值是提前掌握 AWS 服務上限。 它可以搭配 CloudWatch Alarms 通知你，也可以直接申請提高配額， 避免系統在擴展時突然受限。

AWS Cost Anomaly Detection 重點整理

AWS Cost Anomaly Detection 是用機器學習自動偵測 AWS 成本異常的服務。

一、什麼是 AWS Cost Anomaly Detection？

AWS Cost Anomaly Detection 是一個用來監控 AWS 成本與使用量的服務。 它會持續分析你的 AWS 花費，並使用 Machine Learning 偵測不尋常的成本變化。

它會學習你的歷史成本模式，判斷哪些花費是正常的，哪些看起來不正常。 例如成本突然暴增、某個服務花費突然上升，或某個帳號成本異常增加。

最大的特色是： 你不需要自己設定固定門檻，系統會根據歷史模式自動判斷異常。

二、AWS 專家口語化說明

Cost Anomaly Detection 就像 AWS 的成本異常警報器。

它不是單純判斷「超過 100 美元就通知」， 而是會先學習你平常的花費習慣，再自動判斷什麼情況不正常。

簡單記法： AWS Budgets 是你自己設定預算；Cost Anomaly Detection 是 AWS 自動幫你抓異常花費。

三、AWS 服務與概念表格

AWS 服務 / 概念	用途	白話說明
AWS Cost Anomaly Detection	偵測成本異常	自動發現 AWS 花費突然變高或不正常。
Machine Learning	分析成本模式	學習你的歷史花費，判斷什麼情況算異常。
Cost and Usage Data	成本與使用量資料	用來分析哪些服務、帳號或分類產生成本。
AWS Services	服務層級監控	可偵測 EC2、RDS、S3 等服務是否成本異常。
Member Accounts	帳號層級監控	在多帳號環境中，監控各成員帳號成本。
Cost Allocation Tags	成本分類標籤	可依專案、部門、環境等 Tag 偵測異常。
Cost Categories	成本分類群組	可依自訂成本分類分析異常。
Anomaly Detection Report	異常偵測報告	顯示發生什麼異常，以及可能原因。
Root Cause Analysis	根本原因分析	協助找出是哪個服務、帳號或分類造成成本異常。
Amazon SNS	通知服務	可用來發送成本異常通知。

四、通知方式

通知方式	用途	白話說明
Individual Alerts	個別異常通知	每次偵測到異常時，就發送通知。
Daily Summary	每日摘要	每天整理成本異常狀況。
Weekly Summary	每週摘要	每週整理成本異常狀況。
Amazon SNS	通知管道	透過 SNS 發送 Email 或其他通知。

五、生活化比喻

可以把 AWS Cost Anomaly Detection 想成信用卡異常消費偵測。

平常你的信用卡消費很固定，銀行系統會知道你的正常消費模式。 如果某天突然出現大額刷卡或不尋常交易，銀行就會提醒你確認。

AWS Cost Anomaly Detection 也是一樣。 它會學你的 AWS 成本模式，當某個服務、帳號、Tag 或成本分類突然變貴時，就會通知你。

生活場景	AWS 對應
信用卡日常消費	AWS 日常成本
銀行學習你的消費模式	Machine Learning 學習 AWS 成本模式
異常刷卡	AWS 成本異常
銀行通知你	SNS / Email 通知
查看是哪筆消費出問題	Root Cause Analysis
每日或每週消費摘要	Daily / Weekly Summary

六、整體流程圖

AWS 成本與使用量資料 │ ├─ AWS Services ├─ Member Accounts ├─ Cost Allocation Tags └─ Cost Categories │ ▼ AWS Cost Anomaly Detection │ ├─ 持續監控成本資料 ├─ 使用 Machine Learning ├─ 學習歷史成本模式 └─ 判斷目前花費是否異常 │ ▼ 偵測異常成本 │ ├─ 單次成本突然暴增 ├─ 成本持續上升 ├─ 某服務成本異常 ├─ 某帳號成本異常 └─ 某 Tag / Cost Category 成本異常 │ ▼ 產生異常報告 │ ├─ 顯示異常內容 ├─ 提供可能原因 └─ 協助 Root Cause Analysis │ ▼ 發送通知 │ ├─ Individual Alerts ├─ Daily Summary ├─ Weekly Summary └─ SNS Notification │ ▼ 管理者確認並處理成本問題

總結： AWS Cost Anomaly Detection 的重點是「不用自己猜門檻」。 它會根據歷史成本模式，自動偵測不正常的花費，並協助你快速找出原因。

AWS Billing Alarm 與 AWS Budgets 重點整理

Billing Alarm 是簡單帳單提醒，AWS Budgets 是完整預算控管工具。

一、Billing Alarm 是什麼？

Billing Alarm 是建立在 CloudWatch Billing Metric 上的帳單告警。 當 AWS 實際成本超過你設定的金額門檻時，就可以發送通知。

Billing Metric 儲存在 us-east-1， 但它彙整的是整個 AWS 帳號、所有 Region 的成本。

需要注意的是，Billing Metric 看的是 實際已產生成本， 不是預測成本。

簡單記法： Billing Alarm 就是「帳單超過某個金額就提醒我」。

二、AWS Budgets 是什麼？

AWS Budgets 是用來設定預算、追蹤成本與發送通知的工具。 它不只可以看實際成本，也可以看預測成本。

例如你設定每月預算 100 美元， AWS Budgets 可以在實際成本達到 80 美元時提醒你， 也可以在預測月底會超過 100 美元時提前通知你。

核心差異： Billing Alarm 看實際金額是否超標；AWS Budgets 可以看實際成本，也可以看預測成本。

三、AWS 服務與概念表格

AWS 服務 / 概念	用途	白話說明
CloudWatch Billing Metric	追蹤 AWS 實際帳單成本	帳單指標集中在 us-east-1，但彙整所有 Region 的成本。
Billing Alarm	帳單告警	實際費用超過門檻時發通知。
AWS Budgets	預算管理與告警	可以針對成本、用量、RI、Savings Plans 設定預算。
Cost Budget	成本預算	例如每月 AWS 成本不要超過 100 美元。
Usage Budget	用量預算	例如 EC2 使用時數不要超過某個數量。
Reservation Budget	Reserved Instances 預算	追蹤 RI 使用率與使用狀況。
Savings Plans Budget	Savings Plans 預算	追蹤 Savings Plans 是否被有效使用。
Amazon SNS	通知服務	Budget 或 Alarm 可以透過 SNS 發送通知。
AWS Lambda	自動化處理	Budget 通知可以觸發 Lambda 做後續處理。
Cost Explorer	成本分析	可以從 Budgets 進一步查看成本來源與趨勢。

四、Billing Alarm 與 AWS Budgets 比較

項目	Billing Alarm	AWS Budgets
主要用途	簡單帳單告警	完整預算控管
依據資料	實際成本	實際成本與預測成本
設定彈性	較簡單	可依服務、帳號、Tag、Region 等條件篩選
適合情境	費用超過固定金額時提醒	正式預算管理與提前預警
通知方式	Email / SNS	Email / SNS / Lambda 等

五、生活化比喻

可以把 Billing Alarm 和 AWS Budgets 想成信用卡提醒與家庭預算表。

• Billing Alarm像信用卡超額提醒，刷超過某個金額才通知。
• AWS Budgets像家庭預算表，不只看已花金額，也會預測月底會不會超支。
• Cost Budget像每月總生活費上限。
• Usage Budget像水電用量限制。
• Reservation Budget像健身房年約使用率，買了不用就浪費。
• Savings Plans Budget像電信長約使用率，要確認承諾有被有效使用。

六、AWS Budgets 可篩選條件

篩選條件	用途
Service	只看特定服務成本，例如 EC2、RDS、KMS。
Linked Account	在多帳號環境中，只看特定帳號成本。
Tag	依照專案、部門、環境追蹤成本。
Purchase Option	依照 On-Demand、Reserved、Savings Plans 等購買方式分析。
Instance Type	針對特定 EC2 規格追蹤成本或用量。
Region / AZ	針對特定區域或可用區追蹤成本。
API Operation	依照特定 API 操作分析成本。

七、整體流程圖

AWS 帳單監控與預算管理 │ ├─ 1. CloudWatch Billing Metric │ │ │ ├─ 儲存在 us-east-1 │ ├─ 彙整所有 Region 成本 │ └─ 顯示實際成本，不是預測成本 │ ├─ 2. Billing Alarm │ │ │ ├─ 建立在 Billing Metric 上 │ ├─ 設定金額門檻 │ ├─ 實際成本超過門檻 │ └─ 發送 Email / SNS 通知 │ └─ 3. AWS Budgets │ ├─ 可監控實際成本 ├─ 可監控預測成本 ├─ 可依條件篩選 │ ├─ Service │ ├─ Linked Account │ ├─ Tag │ ├─ Region │ ├─ AZ │ ├─ Instance Type │ └─ Purchase Option │ ├─ Budget 類型 │ ├─ Cost Budget │ ├─ Usage Budget │ ├─ Reservation Budget │ └─ Savings Plans Budget │ ├─ 設定告警條件 │ ├─ 實際成本達到 80% │ └─ 預測成本達到 80% │ ├─ 發送通知 │ ├─ Email │ ├─ SNS │ └─ Lambda │ └─ 可連到 Cost Explorer 深入分析

總結： Billing Alarm 適合簡單金額提醒；AWS Budgets 適合正式預算管理。 如果你想提前知道月底可能超支，就應該使用 AWS Budgets。

AWS Application Cost Profiler重點整理

AWS Application Cost Profiler 可以幫你看總覽、做分類、查明細、看趨勢與預測未來成本。

一、什麼是 AWS Application Cost Profiler？

AWS 提供多種工具來追蹤雲端成本。不同工具的用途不同： 有些用來看帳單總覽，有些用來分類成本，有些用來產生詳細報表， 有些則用來做視覺化分析與未來成本預測。

這些工具可以幫助你回答幾個重要問題： 錢花在哪裡？哪個服務最貴？哪個部門或專案造成成本？ 未來成本是否會繼續增加？

二、AWS 專家口語化說明

AWS 成本追蹤可以用四句話記：

• Billing Dashboard看總覽。
• Cost Allocation Tags做分類。
• Cost and Usage Report看明細。
• Cost Explorer看趨勢與預測。

簡單記法： 先看總金額，再用 Tag 分類，接著用報表查明細，最後用 Cost Explorer 看趨勢。

三、AWS 服務與工具表格整理

AWS 服務 / 工具	用途	白話說明
Billing Dashboard	查看帳單總覽	快速看本月花多少、上月花多少、預估會花多少。
Billing and Cost Management	成本管理入口	AWS 帳單、成本分析、預算、報表都從這裡進入。
Cost Allocation Tags	成本分類	用 Tag 把成本分到部門、專案、環境或 Owner。
AWS-generated Tags	AWS 自動產生標籤	例如 aws:createdBy，可幫助追蹤資源建立來源。
User-defined Tags	使用者自訂標籤	例如 Environment、Team、CostCenter、Application。
Resource Groups	資源群組	把相同 Tag 的資源集中起來管理。
Tag Editor	批次編輯 Tag	可以一次幫多個資源新增或修改標籤。
Cost and Usage Report	最詳細成本報表	提供最完整的 AWS 使用量與費用明細。
Data Exports	匯出成本資料	將成本與使用量資料匯出到 S3，可選 CSV 或 Parquet。
Amazon S3	儲存報表	成本報表可以輸出到 S3 保存與分析。
Amazon Athena	查詢成本報表	可用 SQL 查詢 S3 裡的成本資料。
Amazon Redshift	成本資料分析	適合把成本資料放入資料倉儲做分析。
Amazon QuickSight	視覺化儀表板	可以把成本資料做成圖表與報表。
Cost Explorer	成本視覺化分析	用圖表看成本趨勢、服務費用、未來預測。
Savings Plans Recommendations	節省成本建議	Cost Explorer 可提供 Savings Plans 建議。

四、生活化比喻

可以把 AWS 成本追蹤工具想成公司財務管理系統。

• Billing Dashboard像信用卡帳單首頁，快速看總花費。
• Cost Allocation Tags像發票分類標籤，標示是哪個部門或專案花的錢。
• Resource Groups像把同類物品放進同一個櫃子。
• Tag Editor像批次貼標籤機，可以一次修改很多資源。
• Cost and Usage Report像銀行完整交易明細。
• Cost Explorer像記帳 App，用圖表看花費趨勢。

五、各工具適用情境

你想知道的問題	適合工具	原因
這個月目前花多少？	Billing Dashboard	快速查看帳單總覽。
哪個部門或專案花最多？	Cost Allocation Tags	可依 Tag 分類成本。
我要查最詳細的費用明細	Cost and Usage Report	提供最完整、最細的成本與使用量資料。
我要用 SQL 查成本資料	Cost and Usage Report + Athena	報表匯出到 S3 後，可用 Athena 查詢。
我要做成本儀表板	QuickSight	可將成本資料視覺化。
我要看成本趨勢與未來預測	Cost Explorer	可用圖表分析成本，並預測未來最多 12 個月。

六、整體流程圖

AWS 成本追蹤流程 │ ├─ 1. 先看整體帳單 │ │ │ └─ Billing Dashboard │ ├─ 本月累計成本 │ ├─ 上月成本 │ ├─ 預估成本 │ └─ 依服務 / 帳號 / Region 查看成本 │ ├─ 2. 替資源加上分類標籤 │ │ │ └─ Cost Allocation Tags │ ├─ AWS-generated Tags │ └─ User-defined Tags │ ├─ Environment │ ├─ Team │ ├─ Owner │ ├─ Cost Center │ └─ Application │ ├─ 3. 用 Tag 管理資源 │ │ │ ├─ Tag Editor │ │ └─ 批次修改資源標籤 │ │ │ └─ Resource Groups │ └─ 將相同 Tag 的資源集中管理 │ ├─ 4. 匯出詳細成本報表 │ │ │ └─ Cost and Usage Report / Data Exports │ ├─ 匯出到 Amazon S3 │ ├─ 可選 CSV 或 Parquet │ ├─ 可用 Athena 查詢 │ ├─ 可用 Redshift 分析 │ └─ 可用 QuickSight 視覺化 │ └─ 5. 視覺化分析與預測 │ └─ Cost Explorer ├─ 查看成本趨勢 ├─ 分析各服務費用 ├─ 查看資源層級成本 ├─ 取得 Savings Plans 建議 └─ 預測未來最多 12 個月成本

總結： Billing Dashboard 看總覽，Cost Allocation Tags 做分類， Cost and Usage Report 查細節，Cost Explorer 看趨勢與預測。 這四個工具搭配使用，才能真正掌握 AWS 成本來源。

AWS Pricing Calculator 重點整理

AWS Pricing Calculator 是在正式建立 AWS 資源前，先幫你估算整體架構成本的工具。

一、什麼是 AWS Pricing Calculator？

AWS Pricing Calculator 是 AWS 提供的成本估算工具。 它可以讓你在真正建立雲端資源之前，先估算整個架構大概會花多少錢。

你可以選擇不同 AWS 服務，例如 EC2、EBS、Elastic Load Balancing 等， 並設定 Region、規格、數量、使用率與付款方式。

設定完成後，Pricing Calculator 會幫你產生預估成本， 例如每月費用或 12 個月總成本。

二、AWS 專家口語化說明

AWS Pricing Calculator 就像 AWS 的雲端報價單工具。

你還沒真的開 EC2、Load Balancer、EBS 之前， 可以先把架構放進去試算，看看一個月或一年大概要花多少錢。

簡單記法： 還沒開資源前，先用 Pricing Calculator 估價，避免開完才發現太貴。

三、常見估算項目

AWS 服務 / 概念	用途	白話說明
AWS Pricing Calculator	預估 AWS 成本	在真正建立資源前，先試算大概要花多少錢。
Amazon EC2	虛擬主機	可以估算 Instance 規格、數量、使用率與付款方式。
EC2 Instance Type	EC2 規格	例如 T4g.xlarge，代表 CPU、RAM 等主機大小。
Region	AWS 區域	不同 Region 價格可能不同，估算時要選對區域。
EC2 Instance Savings Plans	長期承諾折扣	承諾一段時間使用量，換取比 On-Demand 更低的價格。
Amazon EBS	EC2 磁碟儲存	可以估算每台 EC2 搭配多少 GB 儲存空間。
Elastic Load Balancing	負載平衡	可以估算 Load Balancer 的使用時間、流量與連線成本。
Application Load Balancer	第七層負載平衡器	常用於 Web 應用程式，依流量與使用量計費。
Estimate	成本估算結果	把各服務成本加總，形成整體架構預估費用。
Support Plan	AWS 支援方案	可以把支援方案成本一起納入估算。

四、EC2 估算範例

假設你要估算一組 EC2 工作負載，可以在 Pricing Calculator 中設定：

• Region選擇資源所在區域。
• OS選擇 Linux 或其他作業系統。
• Instance Type例如 T4g.xlarge。
• 數量例如 4 台 EC2。
• 使用率例如每月 80%。
• 付款方式例如 1 年 Savings Plans，不預付。
• EBS例如每台 EC2 搭配 200GB 儲存空間。

五、生活化比喻

可以把 AWS Pricing Calculator 想成裝潢報價單。

你還沒開始裝潢前，會先估算要幾間房、用什麼材料、要多少冷氣、要不要系統櫃。 AWS Pricing Calculator 也是一樣，先估算你的雲端架構大概要花多少錢。

生活場景	AWS 對應
裝潢前估價	AWS Pricing Calculator
房間數量	EC2 數量
房間大小	EC2 Instance Type
冷氣與設備	EBS、Load Balancer 等附加資源
使用多久	每月使用率
簽長約折扣	Savings Plans
最後報價單	Estimate 成本估算結果

六、整體流程圖

開始規劃 AWS 架構 │ ▼ 進入 AWS Pricing Calculator │ ▼ 建立新的 Estimate │ ▼ 選擇要估算的 AWS 服務 │ ├─ Amazon EC2 ├─ Elastic Load Balancing ├─ Amazon EBS └─ 其他 AWS 服務 │ ▼ 設定服務細節 │ ├─ Region ├─ 作業系統 ├─ Instance Type ├─ 數量 ├─ 使用率 ├─ 儲存容量 └─ 計價策略 │ ▼ 選擇付款方式 │ ├─ On-Demand ├─ Savings Plans ├─ Reserved └─ No Upfront / Partial Upfront / All Upfront │ ▼ 加入 Estimate │ ▼ 繼續加入其他服務 │ ├─ Load Balancer ├─ Storage ├─ Database └─ Support Plan │ ▼ 產生整體成本估算 │ ▼ 查看每月成本與 12 個月總成本 │ ▼ 用於預算規劃、架構比較、成本控制

總結： AWS Pricing Calculator 的重點是「先估算，再建置」。 它可以幫你在架構設計階段就掌握大概成本，避免資源建立後才發現費用超出預期。

AWS Billing and Costing Tools 重點整理

AWS 成本工具可以分成三類：使用前先估算、使用中追蹤分析、快超支時提醒。

一、什麼是 AWS Billing and Costing Tools？

AWS Billing and Costing Tools 是一組用來管理雲端費用的工具。 它可以幫助你在使用 AWS 前先估算成本，在使用中追蹤花費， 並在成本接近預算或超過門檻時發出提醒。

這些工具的目的不是只讓你看帳單，而是讓你更清楚知道： 錢花在哪裡、哪些服務最貴、哪個專案或部門產生成本，以及是否快要超支。

二、AWS 專家口語化說明

AWS 成本管理可以用三句話記：

• 使用前先用 AWS Pricing Calculator 估算成本。
• 使用中用 Billing Dashboard、Cost Explorer、Cost and Usage Report 追蹤與分析。
• 快超支用 Billing Alarms 和 AWS Budgets 提醒。

簡單記法： 先估算、再追蹤、最後設定提醒，這就是 AWS 成本管理的基本流程。

三、AWS 成本工具表格整理

AWS 服務 / 工具	用途	白話說明
AWS Pricing Calculator	預估成本	在使用 AWS 前，先試算大概要花多少錢。
Billing Dashboard	查看帳單總覽	看目前帳單、服務費用與付款狀態。
Cost Allocation Tags	成本分類	用 Tag 區分部門、專案、環境，方便看誰花了多少錢。
Cost and Usage Report	詳細成本報表	最完整的 AWS 使用量與費用明細，適合深入分析。
Cost Explorer	成本分析	用圖表看成本趨勢、服務花費與未來預測。
Billing Alarms	帳單告警	費用超過設定門檻時發出通知。
AWS Budgets	預算控管	設定每月預算，追蹤是否快超支。
Amazon CloudWatch	監控與告警基礎	Billing Alarms 會搭配 CloudWatch 進行告警。
Amazon SNS	通知服務	成本告警可以透過 SNS 發送 Email 或訊息。

四、三大類成本工具

分類	工具	用途
預估成本	AWS Pricing Calculator	使用 AWS 前，先估算可能費用。
追蹤成本	Billing Dashboard、Cost Allocation Tags、Cost and Usage Report、Cost Explorer	查看目前花費、分類成本、分析趨勢。
監控成本	Billing Alarms、AWS Budgets	設定金額門檻或預算，避免費用失控。

五、生活化比喻

可以把 AWS 成本工具想成家庭理財工具。

• Pricing Calculator像買東西前先估價。
• Billing Dashboard像信用卡帳單總覽。
• Cost Allocation Tags像把消費分成家用、交通、娛樂。
• Cost and Usage Report像完整交易明細。
• Cost Explorer像記帳 App，用圖表分析花費。
• Billing Alarms像刷卡超額提醒。
• AWS Budgets像每月生活費預算表。

六、整體流程圖

AWS 成本管理流程 │ ├─ 1. 使用前：預估成本 │ │ │ └─ AWS Pricing Calculator │ └─ 先估算 EC2、RDS、S3 等服務大概要多少錢 │ ├─ 2. 使用中：查看目前花費 │ │ │ └─ Billing Dashboard │ └─ 看目前帳單總覽與各服務費用 │ ├─ 3. 使用中：分類成本 │ │ │ └─ Cost Allocation Tags │ └─ 用 Tag 區分專案、部門、環境成本 │ ├─ 4. 使用中：產生詳細報表 │ │ │ └─ Cost and Usage Report │ └─ 提供最完整的使用量與費用明細 │ ├─ 5. 使用中：分析成本趨勢 │ │ │ └─ Cost Explorer │ ├─ 用圖表分析成本 │ ├─ 比較不同服務花費 │ └─ 預測未來成本 │ └─ 6. 使用中：監控與提醒 │ ├─ Billing Alarms │ └─ 超過金額門檻就通知 │ └─ AWS Budgets └─ 設定預算並追蹤是否超支

總結： AWS 成本管理不是等帳單出來才看，而是先估算、持續追蹤、定期分析，並設定預算與告警。

AWS Compute Optimizer 重點整理

AWS Compute Optimizer 是幫你檢查 AWS 資源有沒有開太大或開太小的成本與效能最佳化工具。

一、什麼是 AWS Compute Optimizer？

AWS Compute Optimizer 是一個用來降低成本、改善效能的 AWS 服務。 它會分析你的 AWS 資源使用狀況，然後建議你應該調大、調小，或維持目前設定。

它可以協助你找出哪些資源是 配置過高， 也就是規格開太大、浪費成本； 也可以找出哪些資源是 配置不足， 也就是規格太小、可能影響效能。

二、AWS 專家口語化說明

Compute Optimizer 就像 AWS 的資源健檢工具。

很多人在 AWS 上開 EC2、EBS、Lambda 時，常常會怕效能不夠，所以規格開太大。 但規格開太大就會浪費錢；規格開太小，又可能造成效能問題。

Compute Optimizer 會根據 CloudWatch Metrics 加上機器學習，幫你判斷目前資源配置是否合理。

簡單記法： Compute Optimizer 幫你把 AWS 資源調到剛剛好，不要浪費，也不要不夠用。

三、支援資源與用途

AWS 服務 / 概念	用途	白話說明
AWS Compute Optimizer	資源最佳化建議	分析 AWS 資源是否開太大或開太小。
Amazon EC2	虛擬主機	檢查 Instance Type 是否適合目前工作負載。
Auto Scaling Groups	自動調整 EC2 數量	分析整組 EC2 的容量與設定是否合理。
Amazon EBS	區塊儲存	檢查 Volume 類型、效能或容量是否合適。
AWS Lambda	Serverless 函數	分析 Lambda 記憶體與執行效能是否合理。
Amazon CloudWatch	監控指標來源	Compute Optimizer 會使用 CloudWatch Metrics 判斷資源使用率。
Machine Learning	智慧分析	用機器學習分析資源配置與使用趨勢。
Amazon S3	儲存最佳化報告	Compute Optimizer 的建議結果可以匯出到 S3。

四、常見分析結果

狀態	意思	白話說明
Over-provisioned	資源配置過高	規格開太大，實際用不到，會浪費成本。
Under-provisioned	資源配置不足	規格開太小，可能造成效能瓶頸。
Optimized	配置合理	目前資源大小與工作負載大致匹配。

五、生活化比喻

可以把 AWS Compute Optimizer 想成公司水電與設備健檢顧問。

如果小會議室裝了超大冷氣，雖然很涼，但很浪費電。 如果大會議室裝了太小的冷氣，就會不夠冷，大家都不舒服。

Compute Optimizer 就像顧問來幫你檢查： 哪些設備太大、哪些設備太小、哪些設備剛剛好。

生活場景	AWS 對應
冷氣太大，浪費電	EC2 規格開太大
冷氣太小，不夠冷	EC2 規格太小，效能不足
電表記錄用電量	CloudWatch Metrics
顧問分析使用狀況	AWS Compute Optimizer
建議更換適合設備	建議調整 EC2、EBS、Lambda
健檢報告存起來	匯出建議結果到 Amazon S3

六、整體流程圖

AWS 資源運作中 │ ├─ EC2 Instances ├─ Auto Scaling Groups ├─ EBS Volumes └─ Lambda Functions │ ▼ CloudWatch 收集使用指標 │ ├─ CPU 使用率 ├─ Memory 使用狀況 ├─ I/O 表現 ├─ Lambda 執行時間 └─ 資源使用趨勢 │ ▼ AWS Compute Optimizer 分析 │ ├─ 使用機器學習 ├─ 分析資源設定 └─ 判斷實際使用率 │ ▼ 產生最佳化建議 │ ├─ Over-provisioned：資源開太大 ├─ Under-provisioned：資源開太小 └─ Optimized：目前配置合理 │ ▼ 使用者依建議調整資源 │ ├─ 降低成本 ├─ 改善效能 └─ 提升資源使用效率 │ ▼ 建議報告可匯出到 Amazon S3

總結： AWS Compute Optimizer 的重點是利用 CloudWatch 指標與機器學習，幫你找出 AWS 資源是否配置過高或不足， 讓成本與效能取得更好的平衡。

AWS Savings Plans筆記

Savings Plans 是用「長期承諾每小時花費」來換取 AWS 運算成本折扣。

一、什麼是 AWS Savings Plans？

AWS Savings Plans 是一種節省 AWS 成本的方案。 它不像傳統 Reserved Instances 一樣，要綁定非常明確的 Instance Type。

Savings Plans 的核心概念是： 你承諾未來 1 年或 3 年，每小時會花費固定金額，AWS 就給你折扣。

例如你承諾未來 3 年，每小時至少花 10 美元在運算資源上， AWS 就會自動將符合條件的用量套用折扣。

二、AWS 專家口語化說明

Savings Plans 就像跟 AWS 簽長約。

你不是買一台固定機器，而是跟 AWS 說： 「我未來會穩定使用一定金額的運算資源，請給我折扣。」

如果你的系統長期運作，Savings Plans 通常會比 On-Demand 更省。 但如果你的用量很不穩定，就要小心不要承諾太多，避免浪費。

簡單判斷： 長期穩定用量可以考慮 Savings Plans；短期、臨時、不確定的用量先用 On-Demand。

三、Savings Plans 類型比較

類型	用途	白話說明
EC2 Instance Savings Plans	節省 EC2 成本	適合長期使用特定 Region、特定 Instance Family 的 EC2，折扣較高但限制較多。
Compute Savings Plans	節省多種運算服務成本	可套用 EC2、Fargate、Lambda，彈性最高。
Machine Learning Savings Plans	節省機器學習服務成本	常見於 Amazon SageMaker 長期使用情境。

四、相關 AWS 服務整理

AWS 服務 / 概念	用途	白話說明
AWS Savings Plans	節省運算成本	承諾每小時固定花費，換取比 On-Demand 更低的價格。
Amazon EC2	虛擬主機	EC2 Instance Savings Plans 與 Compute Savings Plans 都可套用。
AWS Fargate	無伺服器容器運算	Compute Savings Plans 可套用到 Fargate。
AWS Lambda	Serverless 函數	Compute Savings Plans 可套用到 Lambda。
Amazon SageMaker	機器學習平台	可使用 SageMaker Savings Plans 降低長期 ML 成本。
AWS Cost Explorer	成本分析與建議	可根據目前用量，建議適合的 Savings Plan。
On-Demand	隨用隨付	彈性最高，但價格通常較高。

五、付款方式

付款方式	說明	白話說明
All Upfront	全額預付	一開始付清，通常折扣最大。
Partial Upfront	部分預付	先付一部分，後續再分期或按月支付。
No Upfront	不預付	不用先付錢，但折扣通常較低。

六、生活化比喻

Savings Plans 可以想成電信門號長約。

• On-Demand像預付卡，用多少付多少，彈性高但單價較貴。
• Savings Plans像月租方案，承諾固定消費，換取折扣。
• EC2 Instance Savings Plans像指定品牌長約，折扣高但限制較多。
• Compute Savings Plans像全平台通用月租，EC2、Fargate、Lambda 都可能適用。
• SageMaker Savings Plans像專門給 AI 團隊的長約方案。

七、整體流程圖

AWS 運算成本 │ ├─ 不承諾 │ │ │ └─ On-Demand │ ├─ 用多少付多少 │ ├─ 彈性最高 │ └─ 單價通常較高 │ └─ 願意長期承諾 │ └─ Savings Plans │ ├─ 承諾每小時固定花費 ├─ 承諾 1 年或 3 年 ├─ 選擇付款方式 │ ├─ EC2 Instance Savings Plans │ ├─ 適用 EC2 │ ├─ 綁定 Region │ ├─ 綁定 Instance Family │ └─ 折扣較高 │ ├─ Compute Savings Plans │ ├─ 適用 EC2 │ ├─ 適用 Fargate │ ├─ 適用 Lambda │ └─ 彈性最高 │ └─ Machine Learning Savings Plans ├─ 適用 SageMaker └─ 適合長期 ML 工作負載

八、實務選擇建議

情境	建議選擇	原因
EC2 長期固定使用同一類型	EC2 Instance Savings Plans	折扣通常較高，適合穩定工作負載。
架構常在 EC2、Lambda、Fargate 之間變動	Compute Savings Plans	彈性最高，不容易因架構調整而浪費承諾。
長期使用 SageMaker	Machine Learning Savings Plans	適合長時間機器學習工作負載。
用量不穩定或只是短期測試	On-Demand	不用承諾，避免買太多造成浪費。

總結： Savings Plans 的重點不是買某一台機器，而是承諾每小時使用一定金額的 AWS 運算資源。 用量穩定時可以省錢，用量不穩時要小心承諾過高。

AWS Pricing 計費筆記

AWS 的費用不是只看服務名稱，而是看你用了什麼、用多久、用多大、資料傳到哪裡。

一、AWS 四種主要計價模式

計價模式	用途	白話說明
Pay as you go	用多少付多少	資源開多久、用多少，就付多少，不需要先買硬體。
Reserved	長期使用折扣	如果確定長期使用，可以用 1 年或 3 年承諾換折扣。
Volume Discount	用越多越便宜	像 S3 這類服務，使用量越大，可能有階梯式折扣。
Economies of Scale	AWS 規模經濟	AWS 規模變大後，可能把成本下降的好處回饋給客戶。

二、AWS Free Tier 免費額度

新建立的 AWS 帳號通常可以使用一定額度的免費資源或點數。 有些服務也提供 Always Free 的每月免費額度。

服務	免費額度概念	白話說明
Lambda	每月一定請求數與運算時間	適合練習事件驅動與 Serverless。
DynamoDB	每月一定儲存與請求額度	適合練習 NoSQL 與簡單應用。

免費額度不是無限免費，超過額度後仍可能收費，建議搭配 Billing Alarm 或 AWS Budgets。

三、EC2 計費重點

EC2 的費用會受到 Instance Type、CPU、RAM、Region、OS、使用時間與監控設定影響。

EC2 模式	用途	白話說明
On-Demand	彈性使用	隨開隨用，用多少付多少，適合不確定用量。
Reserved Instances	長期穩定工作負載	承諾 1 年或 3 年，換取較低價格。
Spot Instances	可中斷工作	很便宜，但 AWS 可能收回容量。
Dedicated Host	專屬實體主機	整台底層主機只給你用，常見於授權或合規需求。
Savings Plans	運算折扣	承諾一定用量，換取比 On-Demand 更低的價格。

四、Lambda、ECS、Fargate 計費

服務	計費方式	白話說明
AWS Lambda	呼叫次數 + 執行時間 + 記憶體大小	函數被呼叫才付費，適合事件驅動。
Amazon ECS EC2 Mode	主要付底層 EC2 費用	ECS 管容器，但 EC2 還是你要付錢。
AWS Fargate	依 Container 的 CPU 與 Memory 計費	不用管 EC2，直接為容器資源付費。

五、儲存服務計費

服務	成本來源	白話說明
Amazon S3	容量、物件數、請求、儲存類別、資料傳出	像倉庫，放越多、拿越多，成本越高。
S3 Glacier	低成本封存	適合冷資料，便宜但取回較慢。
Amazon EBS	Volume Type、配置容量、IOPS、Snapshot	像租固定大小硬碟，配置多少就付多少。
Amazon EFS	依實際使用容量	像共享資料夾，多台 EC2 可共同使用。

六、RDS 計費重點

RDS 的成本主要來自 DB 規格、儲存空間、I/O、備份、部署模式與資料傳輸。

項目	影響	白話說明
DB Engine	不同資料庫引擎價格不同	MySQL、PostgreSQL、Oracle、SQL Server 成本可能不同。
Instance Size	規格越大越貴	CPU、RAM 越高，成本越高。
Storage	依配置容量計費	資料庫底層儲存通常要付費。
Single-AZ / Multi-AZ	高可用會增加成本	Multi-AZ 比較可靠，但通常更貴。
Backup	備份可能有免費額度，也可能額外收費	備份越多、保留越久，要注意成本。

七、CloudFront 與網路成本

CloudFront 是全球 CDN，主要依照請求次數、資料傳出量與服務地區計費。

網路情境	成本觀念	白話說明
Data In	通常免費	資料進 AWS 通常成本較低。
Data Out	通常收費	資料從 AWS 傳出去要特別注意。
同 AZ Private IP	通常較省	EC2 之間盡量用 Private IP。
跨 AZ	可能收費	不同 AZ 溝通可能產生資料傳輸費。
跨 Region	通常收費	跨區域傳輸資料通常會增加成本。

八、生活化比喻

AWS 計費就像租辦公室、倉庫、物流與水電。

• EC2像租辦公室，坪數越大、租越久，費用越高。
• S3像倉庫，放越多東西、搬出越多，費用越高。
• EBS像固定大小的儲物櫃，租了 100GB 就付 100GB。
• RDS像請 AWS 幫你代管資料庫主機。
• CloudFront像各地分店，讓客戶從最近的地方取貨。
• Data Transfer像物流費，送出去通常比較容易產生成本。

九、整體流程圖

AWS 成本來源 │ ├─ Compute 運算 │ ├─ EC2：看規格、時間、OS、Region │ ├─ Lambda：看呼叫次數與執行時間 │ └─ Fargate：看 Container CPU / Memory │ ├─ Storage 儲存 │ ├─ S3：容量、請求、資料傳出 │ ├─ EBS：配置容量、IOPS、Snapshot │ └─ EFS：實際使用容量 │ ├─ Database 資料庫 │ └─ RDS：規格、儲存、I/O、備份、Multi-AZ │ ├─ CDN │ └─ CloudFront：請求數、傳出流量、地區 │ └─ Network 網路 ├─ Data In：通常免費 ├─ Data Out：通常收費 ├─ 跨 AZ：可能收費 └─ 跨 Region：通常收費

十、常見誤解與正確觀念

常見誤解	正確觀念
AWS 沒用就不會收錢	EBS、Snapshot、Elastic IP 等資源即使主機停掉，也可能繼續收費。
S3 上傳下載都免費	上傳通常免費，但資料傳出 AWS 可能收費。
Spot Instance 適合所有系統	Spot 可能被中斷，不適合重要且不能中斷的服務。
Multi-AZ 不會增加太多成本	Multi-AZ 提高可用性，但通常會增加底層資源成本。
Lambda 一定比 EC2 便宜	短時間事件型工作適合 Lambda，長時間高頻執行要重新比較。
Private IP 和 Public IP 沒差	EC2 之間能用 Private IP 就用 Private IP，通常更省也更快。

總結： AWS 成本管理的關鍵，不是只看單一服務價格，而是要同時看規格、使用時間、資料傳輸、儲存類型與高可用設計。

AWS Service Catalog筆記

AWS Service Catalog 筆記

一、說明

AWS 的選項很多，如果讓每個人自由建立資源， 很容易造成設定不一致、不符合公司標準，甚至產生成本與安全風險。

透過 AWS Service Catalog，管理員可以先定義好一組被核准的產品， 例如虛擬機器、資料庫、儲存空間等，然後讓使用者依照權限自行啟動。

這些產品背後通常是由 CloudFormation Template 建立， 當使用者選擇產品後，CloudFormation 會自動佈建相關 AWS 資源。

一句話： Service Catalog 讓使用者可以自助建立 AWS 資源，但資源內容仍然符合公司標準。

二、AWS 專家口語化說明

AWS Service Catalog 就像公司內部的 AWS 自助點餐系統。

管理員先把標準化的資源包裝好，例如標準 EC2、標準 RDS、標準 S3 Bucket。 使用者不用自己研究一堆設定，只要從清單選擇需要的項目。

背後由 CloudFormation 自動建立資源，而且資源會套用公司規定的設定、標籤與權限。

這樣可以避免使用者亂開資源，也能讓 IT 團隊更容易管理成本、安全與標準化。

三、服務與概念表格

AWS 服務 / 概念	用途	白話說明
AWS Service Catalog	建立自助式資源入口	讓使用者從公司核准的清單中選資源來建立
Product	可被使用者啟動的標準資源	像是一個已包裝好的 EC2、RDS 或 S3 建立方案
Portfolio	Product 的集合	像是一份菜單，裡面放多個可選產品
AWS CloudFormation	自動佈建 AWS 資源	使用者按下建立後，背後由它自動部署
Amazon EC2	建立虛擬機器	可被包成標準 VM 產品
Amazon RDS	建立資料庫	可被包成標準資料庫產品
Amazon S3	建立儲存空間	可被包成標準儲存產品
IAM 權限	控制誰可以使用哪些產品	不同部門或角色只能看到自己可用的項目
Tag 標籤	資源分類與成本追蹤	確保建立出來的資源都有公司規定的標籤

四、生活化比喻

可以把 AWS Service Catalog 想成公司內部的標準化點餐機。

如果每個員工都自己進廚房煮菜，可能會造成食材亂拿、成本難控、品質不一致。 所以公司提供一台點餐機，上面只有公司核准的餐點。

員工只要選擇餐點，後面的廚房就會按照標準流程製作。

生活場景	AWS 對應
點餐機	AWS Service Catalog
餐點	Product
菜單	Portfolio
廚房標準流程	CloudFormation
員工可點哪些餐	IAM 權限
餐點成本分類	Tag 標籤

五、文字流程圖

管理員 │ │ 1. 建立標準 CloudFormation Template ▼ Product │ │ 2. 把多個 Product 放在一起 ▼ Portfolio │ │ 3. 設定哪些使用者 / 部門可以使用 ▼ 權限控管 │ │ 4. 使用者登入 Service Catalog ▼ 自助式入口 │ │ 5. 使用者選擇可用的產品 ▼ 啟動 Product │ │ 6. 背後由 CloudFormation 自動部署 ▼ 建立 AWS 資源 │ │ 7. 套用標準設定、標籤與權限 ▼ 完成：標準化、可控管、可追蹤

六、常見誤解與正確觀念

常見誤解	正確觀念
Service Catalog 是拿來建立所有 AWS 資源的主要工具	它主要是提供標準化自助入口，背後通常靠 CloudFormation 建立資源
Service Catalog 會取代 CloudFormation	不會。它通常是把 CloudFormation Template 包裝成可選產品
使用者可以自由建立任何東西	不行。使用者只能看到自己有權限啟動的產品
Product 是一個 AWS 服務	Product 是 Service Catalog 裡的一個標準化項目
Portfolio 是單一資源	Portfolio 是一組 Product 的集合
Service Catalog 只是方便使用者	它也能強制標準化、控管權限、統一 Tag、降低錯誤
有了 Service Catalog 就不需要 IAM	還是需要 IAM 來控制誰可以看、誰可以啟動哪些產品

總結： AWS Service Catalog 的核心價值是「讓使用者自助，但資源建立仍然受控」。 它很適合用在企業內部標準化 EC2、RDS、S3 等資源建立流程。