EC2（Elastic Compute Cloud）可以先把它想成一台租來的雲端伺服器。要多少 CPU、多少記憶體，就選對應的規格；需要時開起來，不用了就關掉，不必先買硬體，也不用自己顧機房。這台伺服器叫做一個 instance（實例），開機用的映像檔叫 AMI（Amazon Machine Image），決定作業系統和預裝軟體。
開一台 instance 要做的決定裡，放哪個 subnet（Day 5）、掛哪個 Security Group（Day 6）、用哪個 IAM Role（Day 3）前面都講過了，這篇只處理兩個：規格怎麼選、錢怎麼付。
EC2 的機型代號長這樣：m5.large——前面的字母是「家族」，代表這台機器擅長什麼；數字是「世代」；後面 large 是「規格大小」（可以想成 T-shirt 尺寸，越大代表 CPU、記憶體給得越多）。
| 需求 | 實例類型 | 系列 | 適合情境 |
|---|---|---|---|
| CPU 跟記憶體需求差不多，沒有特別偏重 | General Purpose | M 系列 | Web Server、中小型資料庫 |
| 主要吃 CPU，記憶體需求不高 | Compute Optimized | C 系列 | 批次運算、遊戲伺服器、科學建模 |
| 需要大量記憶體 | Memory Optimized | R、X 系列 | 記憶體內資料庫、即時大數據分析 |
| 需要高速的本地磁碟讀寫 | Storage Optimized | I、D 系列 | NoSQL 資料庫、資料倉儲 |
| 需要 GPU 加速 | Accelerated Computing | P、G 系列 | 機器學習訓練、繪圖運算 |
先決定家族，再決定 size，這台機器的規格就定下來了。代號中間有時還會插別的字母，例如 c5n.xlarge 的 n 代表網路頻寬加強，r5a.2xlarge 的 a 代表用 AMD 處理器，m7g.large 的 g 代表 AWS 自己設計的 Graviton（ARM）處理器——這些是同一個家族裡的變體，不是新家族。Size 每往上一級，vCPU 和記憶體大致都翻倍：large 是 2 vCPU，xlarge 是 4，2xlarge 是 8，依此類推。
拆一個實際的代號：
m5.large
││ └── size：large，2 vCPU / 8 GiB
│└──── 世代：第 5 代
└────── 家族：m，General Purpose
c5n.xlarge
││└─── 變體：n，網路加強
│└──── 世代：第 5 代
└────── 家族：c，Compute Optimized；size xlarge，4 vCPU
機器開起來之後有幾個狀態，最重要的是分清楚 stop（停機） 和 terminate（終止）：
| Stop | Terminate | |
|---|---|---|
| 機器還在嗎 | 在，可以再 start | 不在了，回不來 |
| EBS root volume | 保留，資料還在 | 預設一起刪除（DeleteOnTermination = true，Day 10 再講） |
| Instance Store 上的資料 | 清掉 | 清掉 |
| Public IP | 釋放，再 start 會拿到新的（Elastic IP 例外） | 釋放 |
| Private IP | 保留 | 釋放 |
| 運算費用 | 停止計費，只付 EBS 儲存費 | 停止計費 |
停機的機器不收運算費，但掛在上面的 EBS 還是照容量計費。要真的省到零，就要 terminate。
順帶一提 Instance Store：有些機型附帶實體主機上的本機碟，速度快、不另外收費，但資料跟 instance 綁在一起——stop 或 terminate 就沒了。只適合暫存、快取這種掉了也沒關係的東西。
規格決定完，接下來是定價模式，同樣一台機器，付錢方式不同，帳單可以差好幾倍。把它想成一連串的問答：
還不知道會用多久，想隨時開、隨時關嗎？
└─ 是 → On-Demand（用多少算多少，剛開始測試、短期活動、用量不可預測）
確定同一類型的機器會長期使用、幾乎不關機嗎？
└─ 是 → Reserved Instances（承諾 1 或 3 年，換取比 On-Demand 低的價格，綁定機型）
這個工作可以承受隨時被中斷嗎？
└─ 是 → Spot Instance（用 AWS 閒置容量，價格最低，但可能被回收，只適合能重跑的工作）
用量穩定，但機型未來可能調整嗎？
└─ 是 → Savings Plans（承諾未來 1 或 3 年的每小時花費金額，不綁機型，折扣接近 Reserved Instance）
先看服務吃什麼資源決定機型家族，再看用量穩不穩定決定怎麼付錢。四種付法各自還有幾個要分清楚的細節：
按秒計費（Linux）、隨開隨關，沒有任何承諾，單價最高。所有其他付法都是拿「承諾」或「可中斷」去換這個價格的折扣。
承諾用 1 年或 3 年，換取最多約 70% 的折扣。要決定三件事：
| 要決定的 | 選項 | 差別 |
|---|---|---|
| 期限 | 1 年／3 年 | 越長越便宜 |
| 類型 | Standard／Convertible | Standard 折扣較高但綁死機型；Convertible 折扣少一點，但期間內可以換成別的機型家族 |
| 付款方式 | All Upfront／Partial Upfront／No Upfront | 預付越多越便宜 |
RI 買的不是一台特定機器，而是一個「折扣額度」：帳號裡只要有符合條件（機型、Region、作業系統）的 instance 在跑，帳單就自動套用折扣；那台機器停了，折扣額度就閒置在那裡照樣付錢。
跟 RI 一樣承諾 1 或 3 年，但承諾的是「每小時花多少美元」，不是哪一種機型：
| 類型 | 彈性 | 折扣 |
|---|---|---|
| Compute Savings Plans | 最彈性：跨機型家族、跨 Region、跨作業系統，連 Fargate 和 Lambda 都算 | 最多約 66% |
| EC2 Instance Savings Plans | 綁定一個機型家族和一個 Region，家族內的 size 可以換 | 最多約 72% |
同樣的折扣水準，Savings Plans 比 RI 好管理很多，現在 AWS 也比較推它。
用 AWS 當下閒置的容量，折扣最多可以到 90%，代價是 AWS 隨時可以收回——收回前給 2 分鐘的中斷通知。適合的工作只有一種：可以中斷、可以重跑的，例如批次運算、影片轉檔、CI 測試、能自動重新排程的大數據工作。不能中斷的（資料庫、線上服務）絕對不要放 Spot。
| 主題 | 說明 |
|---|---|
| T 系列（T2／T3） | 平常效能用不到滿，靠「CPU 積分」在需要時把效能衝高；積分用完，效能會被打回基準值。適合流量忽高忽低的小型應用，不適合長時間高負載 |
| Dedicated Host vs Dedicated Instance | 都是整台實體伺服器獨佔給你，差在 Dedicated Host 看得到、管得到底層主機（可以沿用既有按實體核心算的軟體授權），Dedicated Instance 只保證獨佔，底層主機資訊看不到 |
| Capacity Reservation | 只是「幫我在這個 AZ 留幾台 xx 機型的位子」，不打折但保證開得出來；可以跟 RI 或 Savings Plans 疊加使用 |
| Placement Group | 決定多台 instance 在實體機房裡怎麼擺：Cluster 擠在同一個機櫃區塊，網路延遲最低（HPC 用）；Spread 每台放不同硬體，一台壞不影響其他台（每個 AZ 最多 7 台）；Partition 分成幾組、組跟組不共用硬體（Hadoop、Kafka 這類分散式系統用） |
| Elastic IP | 固定的 public IPv4，機器 stop/start 也不會變；掛在運作中的 instance 上免費，閒置沒掛時要收費 |
| User data | 開機時自動跑一次的腳本（裝套件、拉設定檔），開一批一樣的機器時不用手動逐台設定 |
| 概念 | 說明 |
|---|---|
| EC2 instance | 租來的雲端伺服器，從 AMI 開機，兩個決定：規格、付法 |
| 機型代號 | 家族（擅長什麼）＋世代＋變體＋規格大小，例如 c5n.xlarge |
| Stop vs Terminate | Stop 保留 EBS、只付儲存費；Terminate 預設連 root volume 一起刪 |
| On-Demand | 用多少算多少，沒有任何承諾，單價最高 |
| Reserved Instances | 承諾 1 或 3 年換折扣，Standard 綁機型、Convertible 可換 |
| Savings Plans | 承諾每小時花費金額換折扣，Compute 最彈性、EC2 Instance 折扣較高 |
| Spot Instance | 折扣最高，但隨時可能被收回（提前 2 分鐘通知），只適合能重跑的工作 |
下一天 S3：物件儲存的分級與生命週期管理。
EC2 Reserved Instances 可以選擇的承諾期間是多久？
一家公司在 EC2 上運行電子商務網站。網站未來 3 年都需要固定 40 台實例維持基本流量，但促銷期間可能臨時增加最多 100 台。額外流量出現的時間與規模都無法準確預測，且所有實例都不能被中斷。團隊也可能在未來更換實例家族。
哪一種方案最符合成本效益？
一家公司在 EC2 上運行分散式 NoSQL 資料庫，資料會跨節點複寫。監控結果顯示 CPU 與記憶體仍有充足餘裕，但本機磁碟佇列持續增加，大量隨機讀寫的延遲也超出要求。公司希望在不修改應用程式的情況下降低延遲。
應優先採取哪一種做法？
一個風險分析系統在 EC2 上運行，運算時必須將約 1.5 TB 的工作資料保留在記憶體中。目前 CPU 使用率不到 50%，但系統經常因記憶體不足而使用 swap，造成回應時間增加。
哪一種做法最符合成本效益？
一家媒體公司要在 EC2 上處理大量影片轉檔工作。測試結果顯示 CPU 長時間接近滿載，但記憶體與磁碟不是瓶頸。每個工作彼此獨立、會定期儲存進度，即使實例中斷也能重新執行；每天只需要在 12 小時內完成全部工作。公司希望盡可能降低成本。
應選擇哪兩項方案？（選擇兩項）
Reserved Instances 的承諾期間固定為 1 年或 3 年，不能自行選擇中間的任意期間。這題屬於基本規則題，對應 Udemy 章節測驗常見的出題方式。
40 台基本用量長期穩定，適合用 Compute Savings Plans 的每小時費用承諾換取折扣；Compute Savings Plans 也能因應未來更換實例家族的需求。額外的 100 台只在無法預測的尖峰期間出現，因此使用 On-Demand 比依最高需求做長期承諾更合理。C 雖然更便宜，但 Spot 可能被中斷，不符合題目限制。
CPU 與記憶體都有餘裕，表示瓶頸不在運算或 RAM；磁碟佇列與隨機 I/O 延遲才是核心問題，因此應選 Storage Optimized。A 可能同時增加 CPU 與記憶體，卻不一定改善儲存效能，容易花更多錢但沒有解決真正的瓶頸。
問題來自記憶體不足，而不是 CPU 或磁碟本身。擴大 General Purpose Instance 雖然可能取得足夠記憶體，但也會一起購買題目不需要的 vCPU；Memory Optimized 提供更適合記憶體密集工作負載的資源比例，成本效益較高。D 只能讓 swap 稍快，沒有消除頻繁使用 swap 的根本原因。
CPU 長時間滿載，代表應選 Compute Optimized；工作可以保存進度、重新執行，又有彈性的完成期限，因此適合使用價格較低但可能中斷的 Spot。Reserved Instances 要為固定用量做長期承諾，不適合只因每天有短時間的最高需求就直接購買；On-Demand 可以執行這些工作，但不符合「盡可能降低成本」的要求。
iThome鐵人賽
看影片追技術