CH 14 高頻必考

成本優化與架構良好框架

Cost ExplorerBudgetsSavings Plans 管理Compute OptimizerTrusted AdvisorWell-Architected 六大支柱

這是 SAA 第四大考試領域（成本優化架構，佔 20%）的主場。前面各章學了「用哪個服務」，這章補上「怎麼用得最省」與「怎麼看懂帳單」：先掌握成本可視化與控管工具（Cost Explorer 看趨勢、Budgets 設預算告警、Cost & Usage Report 明細、Cost Allocation Tags 分攤），再看省錢手段（Savings Plans / RI 的購買與管理、Compute Optimizer 給的機型建議、S3 Intelligent-Tiering 自動分層）。最後用 AWS Well-Architected 六大支柱這套官方框架收尾—— 它是所有情境題「哪個方案最好」背後的判斷邏輯。

SAA 很愛考「我想看/控管費用，該用哪個工具」。這四個名字很像但職責完全不同：

Cost Explorer（成本瀏覽器）：用圖表看過去與預測未來的花費趨勢，可依服務/帳號/標籤切分，還能給 Savings Plans / RI 的購買建議。回答「錢花去哪了、未來大概花多少」。
AWS Budgets（預算）：設定預算門檻並在超支（或預測會超支）時發告警（Email / SNS）。回答「花超過我設的上限就通知我」。可針對成本、用量、RI/SP 使用率設預算。
Cost and Usage Report（CUR，成本與使用報告）：最細的帳單明細，每小時、每資源層級，輸出到 S3 可用 Athena / QuickSight / Redshift 分析。回答「我要最原始、最完整的逐項帳單資料做深度分析」。
Cost Allocation Tags（成本分攤標籤）：幫資源打標籤（如 Team=A、Project=X），再依標籤把費用分攤到不同團隊/專案。回答「這筆錢該算在哪個部門頭上」。

⭐ 一句話對應：看趨勢 → Cost Explorer；設上限告警 → Budgets；要最細明細做分析 → CUR；依團隊/專案分攤 → Cost Allocation Tags。

🚨 陷阱：「當花費超過 $X 時通知我」→ 是 Budgets，不是 Cost Explorer（Cost Explorer 只給你看，不會主動告警）。

只要工作負載是「長期穩定運行」，就該用承諾折扣把 On-Demand 價砍下來。兩大類：

Savings Plans（SP，節省方案）：承諾「每小時花多少錢」（如每小時 $10），用 1 或 3 年，換取折扣。
・Compute Savings Plans：最彈性——涵蓋 EC2、Fargate、Lambda，跨區域、跨機型、跨 OS 都算數，最多省 ~66%。
・EC2 Instance Savings Plans：綁定特定區域 + 機型家族，彈性較低但最多省 ~72%。
Reserved Instances（RI，預留執行個體）：承諾用「特定規格的 EC2」1 或 3 年。
・Standard RI：省最多（~72%），但不能換機型家族。
・Convertible RI：可以換機型家族 / OS / 租用類型，較彈性但省得少（~54%）。

⭐ 選擇心法：想要最大彈性（連 Lambda/Fargate 都想涵蓋）→ Compute Savings Plans；用量固定在特定機型、要省到極致 → EC2 Instance SP 或 Standard RI；規格可能會變 → Convertible RI。

💡 三種付款方式省錢幅度：All Upfront（全額預付）> Partial Upfront（部分預付）> No Upfront（不預付）。預付越多、折扣越大。

🚨 陷阱：Savings Plans / RI 是「帳務層面的折扣承諾」，不是預留實體容量（要保證容量得用 On-Demand Capacity Reservation）；也不適合可中斷的工作——那種用 Spot。

省錢的第一步是「找出被浪費的資源」。這幾個工具幫你揪出來：

AWS Compute Optimizer：用機器學習分析 CloudWatch 歷史指標，給「機型調整（right-sizing）」建議——這台 EC2 是不是開太大了？該降到哪個規格？涵蓋 EC2、Auto Scaling Group、EBS、Lambda。回答「我的資源規格開得剛好嗎」。
AWS Trusted Advisor：像一位顧問，從五大面向幫你的帳號做健檢——成本優化、效能、安全、容錯（可靠性）、服務限額。成本類會找出「閒置的 EC2、沒掛載的 EBS、利用率低的 RI」。（完整檢查項目需 Business/Enterprise 支援方案。）
CloudWatch Billing Alarm（帳單告警）：對「預估帳單金額」這個指標設 CloudWatch 告警，超過門檻就通知。（較舊做法，現在多用 Budgets，但考試兩者都可能出現。）

⭐ 對應：要「機型開太大」的調整建議 → Compute Optimizer；要帳號全面健檢（含閒置資源）→ Trusted Advisor；單純帳單超額通知 → Budgets / Billing Alarm。

除了買折扣，架構設計本身就能省很多錢。這些是情境題常見的「怎麼降成本」答案：

S3 生命週期 + Intelligent-Tiering：用生命週期規則把舊資料自動移到更冷的類別（IA → Glacier → Deep Archive）；存取模式不確定時用 Intelligent-Tiering 讓 AWS 自動搬，省下人工判斷。
用 Graviton（ARM 架構）：AWS 自研 CPU，同效能下比 x86 機型性價比高最多約 40%。應用能相容就換。
EBS gp3 取代 gp2：gp3 每 GB 便宜約 20%，且效能（IOPS/吞吐）可獨立調整。
VPC Gateway Endpoint 省 NAT 費：大量存取 S3/DynamoDB 時，走 Gateway Endpoint（免費）而不是繞 NAT Gateway（按小時 + 每 GB 處理費），可省可觀流量費。
資料傳輸費原則：同一 AZ 內走私有 IP 免費；跨 AZ、跨 Region、對外 Internet 傳出都要收費（傳入通常免費）。把常互通的資源放同一 AZ、用 CloudFront 快取降低對 origin 的傳出，都能省。
關掉閒置資源：非生產環境（測試機）排程在下班時間停機；釋放沒用的 Elastic IP（未附掛的 EIP 要收費）。

⭐ 高頻口訣：不確定存取頻率的 S3 → Intelligent-Tiering；大量 S3 存取省流量 → Gateway Endpoint；想無痛降 EC2 單價 → Graviton / gp3；跨 AZ 流量會收費，能同 AZ 就同 AZ。

Well-Architected Framework 是 AWS 官方的架構評估框架，也是所有情境題「哪個方案最好」背後的判斷邏輯。原本五支柱，2021 年加入永續性成為六支柱：

① 卓越營運 Operational Excellence：自動化、監控、持續改善流程（IaC、CI/CD、可觀測性）。
② 安全性 Security：最小權限、縱深防禦、資料加密、可追溯（IAM、KMS、CloudTrail）。
③ 可靠性 Reliability：從故障中自動恢復、水平擴展、消除單點（Multi-AZ、Auto Scaling、DR）。
④ 效能效率 Performance Efficiency：用對的資源、隨需調整（選對機型、Serverless、快取、全球部署）。
⑤ 成本優化 Cost Optimization：消除浪費、用對計價模式（本章主題：Savings Plans、right-sizing、生命週期）。
⑥ 永續性 Sustainability：降低環境衝擊（提高使用率、選低碳區域、用託管服務）。

⭐ 記憶法（前五支柱）：營運、安全、可靠、效能、成本——再加上後來的永續。考試若問「這個改動改善了哪個支柱」，對照上面的關鍵字即可。

💡 常配套出現的工具：Well-Architected Tool（在 Console 裡對你的工作負載做問卷式評估，指出風險）。

EC2 計價模式省錢對照

模式	承諾	省錢幅度	彈性	適用
On-Demand	無	基準價	最高	短期 / 不可預測 / 開發測試
Compute Savings Plans	每小時花費 1/3 年	~66%	高（跨區/機型/含 Fargate、Lambda）	穩定用量但機型可能變
EC2 Instance SP / Standard RI	特定機型 1/3 年	~72%	低（綁機型家族）	用量固定在特定機型
Convertible RI	1/3 年、可換規格	~54%	中（可換家族/OS）	長期但規格會變
Spot	無	最多 ~90%	隨時被收回	可中斷的批次 / CI / 算圖

成本管理工具速查

工具	用途	回答什麼問題
Cost Explorer	視覺化過去/預測花費趨勢	錢花去哪了？未來大概多少？
AWS Budgets	設預算門檻 + 超支告警	超過上限就通知我
Cost & Usage Report	最細帳單明細輸出到 S3	要逐項原始資料做深度分析
Cost Allocation Tags	依標籤分攤費用	這筆錢算哪個團隊/專案？
Compute Optimizer	ML 給 right-sizing 建議	我的機型開太大了嗎？
Trusted Advisor	五大面向帳號健檢	有沒有閒置資源 / 風險？

Well-Architected 六大支柱

支柱	核心問題	代表做法 / 服務
卓越營運	能否自動化與持續改善？	IaC、CI/CD、CloudWatch
安全性	權限最小化、資料加密？	IAM、KMS、CloudTrail
可靠性	能否從故障自動恢復？	Multi-AZ、Auto Scaling、DR
效能效率	用對資源、隨需調整？	選對機型、快取、Serverless
成本優化	有沒有浪費、計價對嗎？	Savings Plans、right-sizing
永續性	能否降低環境衝擊？	提高使用率、選低碳區域

練習題點選選項查看解析

0 / 24

01 / 24

財務團隊希望「當本月 AWS 花費超過 $5000 時自動收到 Email 通知」。最適合的做法是？

A 每天用 Cost Explorer 檢視花費趨勢圖

B 設定 AWS Budgets 預算並綁定告警通知

C 把 Cost and Usage Report 輸出到 S3

D 在 Trusted Advisor 啟用成本檢查項目

解析

AWS Budgets 專門用來設定預算門檻並在超支（或預測會超支）時主動告警（Email/SNS），完全符合「超過 $5000 就通知」。Cost Explorer 只能被動檢視趨勢、不會主動通知；CUR 是原始明細資料；Trusted Advisor 是帳號健檢，不做金額門檻告警。

02 / 24

一家公司想分析過去 6 個月各服務的花費趨勢，並預測未來 3 個月的支出，以便規劃預算。最合適的工具是？

A AWS Budgets

B Cost Explorer

C AWS Config

D CloudWatch Logs

解析

Cost Explorer 提供視覺化的歷史花費分析（可依服務、帳號、標籤切分）並能預測未來支出，正是規劃預算前「看清楚錢花在哪、未來大概多少」的工具。Budgets 用於設門檻告警；Config 追蹤資源設定變更；CloudWatch Logs 是日誌。

03 / 24

公司有一批 24 小時穩定運行的 EC2，未來一年機型可能會依需求在不同家族間調整。想要在保有彈性的前提下省下最多成本，應選？

A 用 Standard RI 鎖定機型

B 用 Compute Savings Plans

C 用 Spot Instances 競標

D 維持 On-Demand 計費模式

解析

Compute Savings Plans 承諾每小時花費，折扣可自動套用到任何區域、任何機型家族、甚至 Fargate 與 Lambda——機型改變也不影響折扣，最適合「穩定運行但規格會變」的情境。Standard RI 綁死機型家族不能換；Spot 會被中斷不適合穩定服務；On-Demand 沒有折扣。

04 / 24

一個工作負載固定使用 m5 家族、且確定一年內不會更換機型，公司希望把單價壓到最低。最省的選擇是？

A Compute Savings Plans

B Convertible Reserved Instances

C EC2 Instance SP 或 Standard RI

D On-Demand 搭配 Auto Scaling

解析

當機型確定不變、追求最大折扣時，EC2 Instance Savings Plans 或 Standard RI（綁定特定區域/機型家族）可省到約 72%，高於彈性較大的 Compute Savings Plans（~66%）與 Convertible RI（~54%）。犧牲彈性換取最低單價。

05 / 24

關於 Reserved Instances，公司預期未來可能需要把 EC2 從 Intel 機型換成 AMD 或更換作業系統。應選擇哪種 RI？

A 選 Standard RI，鎖定固定機型

B 選 Convertible RI，可更換機型

C 選 Spot RI，價格隨市場浮動

D 選 On-Demand RI，無需承諾

解析

Convertible RI 允許在承諾期內更換機型家族、作業系統、租用類型，適合「長期使用但規格可能變動」的情境，代價是折扣（~54%）低於 Standard RI（~72%）。Standard RI 不能更換機型家族；Spot RI / On-Demand RI 並非真實產品名稱。

06 / 24

一個每晚執行 3 小時的批次資料處理任務，可以容忍中途被中斷後重跑。要把運算成本壓到最低，應使用？

A Reserved Instances

B On-Demand Instances

C Spot Instances

D Dedicated Hosts

解析

Spot Instances 利用 AWS 閒置容量，最多可省約 90%，但可能被回收——批次、可中斷重跑的任務正是它的最佳場景。RI 適合長期穩定運行且不會中斷的工作；On-Demand 沒折扣；Dedicated Hosts 最貴，用於授權合規需求。

07 / 24

維運團隊想知道「有哪些 EC2 開得比實際需要還大，可以縮小規格省錢」。最直接提供這類建議的服務是？

A AWS Trusted Advisor 帳號健檢

B AWS Compute Optimizer 建議

C Amazon CloudWatch 監控指標

D AWS Config 設定紀錄追蹤

解析

Compute Optimizer 用機器學習分析 CloudWatch 歷史指標，針對 EC2、Auto Scaling Group、EBS、Lambda 給出具體的 right-sizing（機型調整）建議，直接回答「開太大該縮到哪個規格」。Trusted Advisor 也有成本檢查但偏帳號健檢；CloudWatch 給原始指標但不給機型建議；Config 追蹤設定變更。

08 / 24

一家企業想對整個 AWS 帳號做全面健檢，找出閒置的 EC2、未掛載的 EBS、以及利用率過低的 RI。最適合的服務是？

A Compute Optimizer 機型建議

B Cost Explorer 花費趨勢圖

C Trusted Advisor 帳號健檢

D AWS Budgets 預算告警

解析

Trusted Advisor 從成本優化、效能、安全、容錯、服務限額五大面向做帳號健檢，其成本類檢查會直接列出閒置 EC2、未掛載 EBS、低使用率 RI 等浪費（完整檢查需 Business/Enterprise 支援方案）。Compute Optimizer 專注 right-sizing 建議；Cost Explorer 看趨勢；Budgets 做告警。

09 / 24

一家公司有多個部門共用一個 AWS 帳號，財務希望把每個部門用掉的雲端費用分開統計、各自分攤。最適合的機制是？

A 各部門建立獨立使用者分帳

B 用標籤機制依部門分攤費用

C 各部門分別設定預算門檻

D 用日誌追蹤各部門操作

解析

Cost Allocation Tags 讓你為資源打上如 Department=Sales 的標籤，啟用後帳單即可依標籤把費用分攤到各部門，正是成本分攤的標準做法。IAM 使用者管的是權限不是費用歸屬；Budgets 是告警；CloudTrail 記錄 API 操作。

10 / 24

一個資料分析團隊需要最細緻的逐項帳單資料（每小時、每資源），並用 Athena 做自訂查詢分析。應使用？

A 將 Cost Explorer 資料匯出成 CSV

B 查看 AWS Budgets 產出的報告

C 將 Cost and Usage Report 輸出到 S3

D 匯出 Trusted Advisor 的檢查結果

解析

Cost and Usage Report（CUR）提供最細緻、最完整的帳單明細（每小時/每資源層級），可輸出到 S3 再用 Athena、QuickSight 或 Redshift 做深度自訂分析。Cost Explorer 的匯出較彙總、粒度不夠細；Budgets、Trusted Advisor 都不是明細資料來源。

11 / 24

一個應用大量從私有子網路的 EC2 存取 S3，目前流量繞經 NAT Gateway，資料處理費用很高。如何降低成本？

A 升級為更大規格的 NAT Gateway

B 建立 Gateway Endpoint 走內網

C 把 EC2 搬遷到公有子網路

D 改用自行維護的 NAT Instance

解析

S3/DynamoDB 的 VPC Gateway Endpoint 讓私有子網路直接透過 AWS 內網存取，完全繞過 NAT Gateway，而且 Gateway Endpoint 本身免費——省下 NAT 的每 GB 處理費與流量費。放大 NAT、移到公有子網或改 NAT Instance 都不能有效降低這筆處理費，且後者犧牲安全性。

12 / 24

一個 S3 bucket 存放大量日誌，前 30 天常存取、之後幾乎不看但需保留 1 年供稽核。最省成本又免人工管理的做法是？

A 全部物件維持在 S3 Standard

B 設生命週期規則自動轉冷儲存

C 每天人工搬移舊檔到 Glacier

D 改把日誌存放到 EBS 磁碟

解析

S3 生命週期規則能自動依物件年齡把資料轉到更便宜的類別（例如 30 天 → Standard-IA，更久 → Glacier），完全自動、免人工，兼顧存取需求與成本。全放 Standard 太貴；手動搬移不切實際；EBS 是區塊儲存、不適合這種物件歸檔且更貴。

13 / 24

一個 S3 bucket 的資料存取模式難以預測（有時熱、有時冷），團隊不想花心力設計生命週期規則。最適合的儲存類別是？

A S3 Standard 標準儲存類別

B S3 One Zone-IA 單區類別

C S3 Intelligent-Tiering 智慧分層

D Glacier Deep Archive 深度封存

解析

S3 Intelligent-Tiering 會自動監控物件存取頻率並在各分層間搬移（熱資料放常用層、冷資料自動降到低頻/歸檔層），無需人工設定生命週期，正好解決「存取模式不確定又不想手動管理」。其餘類別都需要你自己判斷存取頻率才不會踩到取回費或可用性問題。

14 / 24

一個運算密集的應用跑在 x86 的 EC2 上，程式可重新編譯為 ARM。想在維持效能的前提下降低成本，最有效的做法是？

A 改採用 Graviton（ARM）架構機型

B 增加更多台 On-Demand 執行個體

C 換成規格更大一級的 x86 機型

D 把應用程式改寫成單執行緒版本

解析

AWS Graviton 是 AWS 自研的 ARM 處理器，在許多工作負載上比同級 x86 機型有最多約 40% 更佳的性價比。應用能相容 ARM 時，換 Graviton 機型是無痛降低單價的高效手段。增加或放大 x86 機型只會增加花費。

15 / 24

公司透過 AWS Organizations 管理多個帳號。使用合併帳單（Consolidated Billing）的成本優勢是什麼？

A 各帳號仍各自享有獨立的折扣門檻

B 用量合併計算，更容易共享 RI/SP 折扣

C 自動把資源搬遷到費用最低的區域

D 組織下所有帳號可免費使用服務

解析

Consolidated Billing 會把組織下所有帳號的用量合併計算，因此更容易跨過 S3、資料傳輸等服務的分級量價門檻拿到更低單價，且未用滿的 RI/Savings Plans 折扣可以在帳號間共享，提高整體使用率。它不會自動搬資源，也不是免費使用服務。

16 / 24

開發團隊的測試環境 EC2 只有上班時間（週一至五 9-18 點）需要運行。降低成本最直接的做法是？

A 購買測試環境的預留執行個體

B 排程在下班時段自動停機執行

C 把執行個體調整為更小規格

D 改用 Spot Instances 來執行

解析

非生產環境只在特定時段使用時，用排程自動在下班時間停機（停止的 EC2 不收運算費，只收 EBS 儲存費）是最直接有效的省錢方式，可省下約 70% 的運算時數。RI/Convertible 適合 24 小時穩定運行；縮小機型省得有限；Spot 適合可中斷的批次而非固定開發環境。

17 / 24

現有一批使用 EBS gp2 磁碟的 EC2，想在不犧牲效能的前提下降低儲存成本。建議的做法是？

A 改用 io2 高效能磁碟類型

B 遷移到 EBS gp3 磁碟類型

C 改用 EBS 磁性磁碟類型

D 把資料全部搬到 S3 儲存

解析

EBS gp3 每 GB 比 gp2 便宜約 20%，而且 IOPS 與吞吐量可以獨立於容量設定，通常能在同等或更好效能下降低成本，是 gp2 的直接升級選項。io2 更貴（用於高 IOPS 需求）；Magnetic 是舊世代；S3 是物件儲存，不能當作 EC2 的區塊磁碟直接替換。

18 / 24

一個全球網站的靜態內容存在 S3，來自世界各地的重複請求造成大量 S3 資料傳出費用。如何同時降低成本並提升效能？

A 把儲存後端換成 EFS 檔案系統

B 在前面加上 CloudFront 做快取

C 為每個地區各建獨立的儲存桶

D 改為啟用 S3 資料傳輸加速功能

解析

CloudFront 在全球邊緣節點快取靜態內容，使用者就近取得，大幅減少回到 S3 origin 的請求與資料傳出量（從 CloudFront 到 origin 的傳輸也較便宜），同時降低延遲——成本與效能雙贏。多建 bucket 增加管理與複製成本；Transfer Acceleration 是加速上傳、非降低分發成本。

19 / 24

架構師把單一大型 EC2 上的服務改成 Lambda，只在有請求時才執行、閒置時不計費。這主要改善了 Well-Architected 的哪個支柱？

A 安全性支柱

B 成本與效能支柱

C 永續性支柱

D 卓越營運支柱

解析

從「常駐的大型 EC2」改為「按實際請求計費的 Lambda」，消除了閒置時的浪費，主要體現成本優化支柱（同時也涉及效能效率——用對的資源、隨需調整）。這說明 Well-Architected 各支柱常互相關聯，但此改動最直接的訴求是省下閒置成本。

20 / 24

團隊想在 AWS Console 裡對某個工作負載做結構化評估，回答一系列問題後得到「有哪些架構風險、可以怎麼改善」的報告。應使用？

A 用 Trusted Advisor 做帳號健檢

B 用 Well-Architected 做結構評估

C 用 Compute Optimizer 給機型建議

D 用 Config 追蹤設定變更紀錄

解析

AWS Well-Architected Tool 讓你針對特定工作負載，依六大支柱做問卷式評估，系統會指出高/中風險項目並給改善建議，正是「結構化評估架構風險」的官方工具。Trusted Advisor 是帳號層級健檢；Compute Optimizer 專注機型建議；Config 追蹤設定合規。

21 / 24

兩個頻繁互相傳輸大量資料的 EC2，目前分別部署在同一 Region 的不同 AZ，跨 AZ 流量費用可觀。在可用性可接受的前提下，如何降低此流量成本？

A 搬到同一 AZ，改用私有 IP 溝通

B 在兩台之間額外加裝 NAT Gateway

C 把架構改為跨 Region 部署

D 為每台各自加裝 Elastic IP

解析

同一 AZ 內透過私有 IP 的資料傳輸是免費的，而跨 AZ（同 Region）雙向都要收費。若這兩台服務關聯緊密、可接受同 AZ 的可用性取捨，放到同一 AZ 用私有 IP 溝通可直接消除跨 AZ 流量費。加 NAT、跨 Region、加 EIP 都只會增加成本。

22 / 24

一家公司想確保「未來若某服務用量暴增導致費用異常，能及早發現」。除了設定固定金額預算，Budgets 還能怎麼幫忙？

A 自動關閉造成超支的資源

B 設定預測型預算提前告警

C 依用量自動購買 RI

D 自動封鎖 IAM 使用者權限

解析

AWS Budgets 除了對「實際花費」告警，還能對「預測花費」告警——當它預測本月將超出預算時就提前通知，讓你在真正超支前就介入，適合抓異常暴增。Budgets 本身只負責告警，不會自動關資源、買 RI 或改權限（那些要另接自動化，如 SNS + Lambda）。

23 / 24

專案結束後，工程師把測試用的 EC2 都終止了，但下個月帳單仍出現一筆與 IP 相關的小額費用。最可能的來源是？

A 沒有釋放的 Elastic IP

B 同一 AZ 內的私有 IP 流量

C Security Group 的保留費

D 終止後的 EC2 仍在計費

解析

Elastic IP 沒有附掛在運行中的 EC2 上時會收費，EC2 終止後若沒有釋放 EIP，就會一直計費。終止的 EC2 不再收運算費；同一 AZ 內走私有 IP 的流量免費；Security Group 本身不收費。

24 / 24

架構師把原本單一 AZ 的 RDS 改成 Multi-AZ，並讓 Web 層的 Auto Scaling Group 跨三個 AZ 部署，目的是某個 AZ 故障時服務能自動恢復。這主要改善了 Well-Architected 的哪個支柱？

A 成本優化

B 可靠性

C 永續性

D 效能效率

解析

「從故障中自動恢復、消除單點」是可靠性（Reliability）支柱的核心，Multi-AZ 與跨 AZ 的 Auto Scaling 正是典型做法。這個改動反而會增加成本；效能效率談的是用對資源、隨需調整；永續性關注的是降低環境衝擊。

點擊卡片翻面查看答案，共 8 張。

QUESTION

Cost Explorer / Budgets / CUR / Cost Allocation Tags 各做什麼？

點擊翻面

ANSWER

Cost Explorer → 看趨勢與預測
Budgets → 設門檻 + 超支告警
CUR → 最細帳單明細（輸出 S3 做分析）
Cost Allocation Tags → 依標籤分攤費用

點擊翻回

QUESTION

Compute Savings Plans vs EC2 Instance SP / Standard RI 怎麼選？

點擊翻面

ANSWER

要最大彈性（跨機型、含 Fargate/Lambda）→ Compute Savings Plans（~66%）
機型固定、要省到極致 → EC2 Instance SP / Standard RI（~72%）
規格會變 → Convertible RI（~54%）

點擊翻回

QUESTION

Compute Optimizer vs Trusted Advisor 差別？

點擊翻面

ANSWER

Compute Optimizer → ML 給 right-sizing 機型調整建議
Trusted Advisor → 五大面向帳號健檢（成本/效能/安全/容錯/限額），找閒置資源

點擊翻回

QUESTION

大量從 VPC 存取 S3，怎麼省流量費？

點擊翻面

ANSWER

建 S3 的 VPC Gateway Endpoint 走內網、繞過 NAT Gateway。Gateway Endpoint 免費，省下 NAT 的每 GB 處理費。

點擊翻回

QUESTION

AWS 資料傳輸費的基本原則？

點擊翻面

ANSWER

同 AZ 私有 IP → 免費
跨 AZ / 跨 Region / 對外 Internet 傳出 → 收費（傳入通常免費）
能同 AZ 就同 AZ；用 CloudFront 降低回源傳出

點擊翻回

QUESTION

存取模式不確定的 S3 資料，選哪個類別最省心？

點擊翻面

ANSWER

S3 Intelligent-Tiering：自動在各分層間搬移，無需人工設生命週期，避免猜錯存取頻率。

點擊翻回

QUESTION

Well-Architected 六大支柱是哪些？

點擊翻面

ANSWER

① 卓越營運 ② 安全性 ③ 可靠性 ④ 效能效率 ⑤ 成本優化 ⑥ 永續性（2021 新增）

點擊翻回

QUESTION

測試環境只有上班時間要用，怎麼省最多？

點擊翻面

ANSWER

用排程（Instance Scheduler / Lambda+EventBridge）在下班時間自動停機。停止的 EC2 不收運算費，可省約 70% 時數。

點擊翻回

成本優化與架構良好框架

練習題 點選選項查看解析

練習題點選選項查看解析