💽 EBS 是什麼

EBS（Elastic Block Store）是掛在 EC2 上的虛擬硬碟，一種區塊儲存（block storage）——資料被切成一塊一塊的區塊存取，作業系統看到它就跟看到一顆實體硬碟一樣，可以格式化、切分割區、裝檔案系統。

跟 EC2 本身「開機/關機」不一樣，EBS volume 的生命週期是獨立的：instance 停機，volume 還在；重新開機，資料還是原封不動的樣子。但 volume 有兩個限制：一次只能掛到一台 instance 上（Multi-Attach 是例外，後面補），而且這台 instance 必須跟 volume 在同一個 AZ。

一台 instance 上通常有兩種 volume：root volume（作業系統那顆，開機時從 AMI 建出來）和資料 volume（另外掛上去存資料的）。兩種都是 EBS，差在 terminate 時的預設行為不一樣，後面補充會講。

🧱 Volume 類型

先介紹兩個衡量硬碟效能的單位，後面每一種類型都是用這兩個數字在比：

• IOPS（I/O operations per second）：每秒能處理幾次讀寫。資料庫這種「一次讀一小塊、但一秒讀幾千次」的工作看這個
• 吞吐量（throughput，MB/s）：每秒能搬多少資料量。影片轉檔、log 分析這種「一次讀一大段、連續讀」的工作看這個

分兩條路線想：gp3／io2 是 SSD，吃的是 IOPS；st1／sc1 是 HDD，吃的是吞吐量，也因此 st1／sc1 不適合資料庫這種隨機、小區塊、高頻率的存取模式。還有一個現在幾乎不用選的 gp2：舊一代的 General Purpose SSD，IOPS 跟容量綁在一起（每 GB 3 IOPS），要效能就得買大容量；gp3 把效能和容量拆開來各自買，同樣效能通常比 gp2 便宜兩成左右，新開的 volume 直接選 gp3 就好。

大小和類型可以事後改

Volume 建好之後可以直接放大容量、改類型（例如 gp2 換 gp3）、調 IOPS，不用停機、不用拆下來——這叫 Elastic Volumes。但只能放大不能縮小，要縮只能建一顆小的、把資料搬過去。

📸 Snapshot：備份怎麼運作

Volume 的備份叫 Snapshot，存在 S3（但不會出現在你自己的 bucket 清單裡，是 AWS 內部管理的）。Snapshot 是增量式的：第一份是完整資料的全量複製，之後每一份只存「相對於上一份有變動的區塊」。刪掉中間某一份也不會讓其他 snapshot 壞掉——AWS 會自動保留其他 snapshot 還需要用到的區塊。用 snapshot 還原時，會建立一顆新的 volume，不是原地覆蓋。

Day 1  snapshot-1：完整複製 500 GB          → 存 500 GB
Day 2  snapshot-2：只有 3 GB 的區塊有變      → 多存 3 GB
Day 3  snapshot-3：只有 2 GB 的區塊有變      → 多存 2 GB
                                            三份合計 505 GB，不是 1,500 GB
刪掉 snapshot-2 → snapshot-3 還原得出完整的 volume，AWS 會把它需要的區塊留著

Snapshot 能做的事不只還原：

📌 補充

除了類型和備份，EBS 還有三個獨立的行為：Multi-Attach、DeleteOnTermination 的預設值、加密狀態的傳遞規則。

Multi-Attach：一顆 volume 同時掛給好幾台機器

一般情況（沒開 Multi-Attach）
  volume-1 ──掛──▶ EC2-A        一顆 volume 只能掛一台機器

Multi-Attach（限 io1／io2，且必須同一個 AZ）
             ┌──▶ EC2-A
  volume-1 ──┼──▶ EC2-B         最多同時掛 16 台，都在同一個 AZ
             └──▶ EC2-C

三台機器可以同時對同一顆 volume 讀寫，但 EBS 只負責讓它們都連得上，不會幫忙判斷「誰先寫、誰的資料算數」——資料一致性要靠上層搭配叢集感知（cluster-aware）的軟體自己處理，例如叢集資料庫或叢集檔案系統。

其他兩個設定

✅ 小結

這天的核心：先看資料庫吃 IOPS 還是大檔案吃吞吐量，決定 volume 類型；備份靠 Snapshot，增量存、可以跨 AZ／跨 Region、還能做成 AMI。

下一天進 EFS：跟 EBS 一樣是掛給 EC2 用的儲存，但換成多台機器要同時讀寫同一份資料時怎麼辦。

🧠 AI 出題

問題 1

某公司在 ap-northeast-1a 執行一台 EC2 instance，掛載一顆 500 GB 的 gp3 EBS volume 存放應用程式資料。由於容量規劃調整，工程師需要把這台 instance 連同它的資料，搬到同一個 Region 的 ap-northeast-1c，且不能遺失 volume 中現有的資料。

解決方案架構師應該怎麼做？

• A. 直接把現有的 EBS volume 從 instance 卸載，再掛載到 ap-northeast-1c 的另一台 instance 上

• B. 為現有的 volume 建立一份 snapshot，再用這份 snapshot 在 ap-northeast-1c 建立一顆新的 volume，掛載到該 AZ 的 instance 上

• C. 在 ap-northeast-1c 啟動一台新 instance，設定與原本相同的 EBS 加密金鑰，讓兩台 instance 共用同一顆 volume

• D. 對 volume 執行 Elastic Volumes 操作，直接把它的可用區域從 ap-northeast-1a 改成 ap-northeast-1c

問題 2

某公司在 EC2 上執行大量歷史交易資料的批次分析工作，每次工作會用循序方式讀取幾百 GB 到數 TB 的檔案，對單次讀寫的隨機延遲沒有要求，但需要穩定的高吞吐量；資料存取頻率高、幾乎每天都要跑，公司希望在滿足吞吐量需求的前提下把儲存成本壓到最低。

哪一種 EBS volume 類型最符合這個需求？

• A. io2（Provisioned IOPS SSD）

• B. sc1（Cold HDD）

• C. st1（Throughput Optimized HDD）

• D. gp3（General Purpose SSD）

問題 3

某公司在 EC2 上運行一個正式環境的 MySQL 資料庫，掛載一顆 500 GB、3,000 IOPS 的 gp3 volume。監控顯示目前的 IOPS 已經不夠，資料庫寫入延遲持續上升，需要把 IOPS 提升到 6,000。這是對外服務的正式環境資料庫，不能接受停機。

解決方案架構師應該建議哪一個做法，才能在不中斷服務的前提下完成調整？

• A. 對這顆 gp3 volume 執行 Elastic Volumes 操作，直接把 IOPS 從 3,000 調整為 6,000，volume 全程保持連接、不需要卸載或停用

• B. 為這顆 volume 建立一份 snapshot，用該 snapshot 建立一顆 IOPS 6,000 的新 volume，停止 instance、卸載舊 volume、掛上新 volume 後再啟動 instance

• C. 先把 instance 停機，再將 volume 類型從 gp3 改為 io2 並指定 6,000 IOPS，設定完成後重新啟動 instance

• D. 在同一台 instance 上另外掛載一顆 IOPS 6,000 的新 gp3 volume，把資料庫的資料目錄搬移到新 volume 上，並修改資料庫設定指向新路徑

問題 4

某公司有數十台 EC2 instance，各自掛載著重要的資料 volume，過去仰賴工程師手動不定期拍 snapshot 做備份，曾發生忘記備份導致資料遺失的事故。公司要求對所有資料 volume 每天自動拍一次 snapshot，並且只保留最近 7 天，不需要工程師手動介入。

解決方案架構師應該建議哪一個做法，才能用最低的維運負擔滿足這個需求？

• A. 使用 Amazon Data Lifecycle Manager（DLM）建立排程政策，依標籤選取這些 volume，設定每天自動建立 snapshot 並保留 7 天，到期自動清除

• B. 撰寫一個 cron job 排程在每台 instance 上，每天呼叫 AWS CLI 對本機掛載的 volume 執行 create-snapshot，並自行寫腳本刪除超過 7 天的 snapshot

• C. 為每個 volume 開啟 EBS 加密，並依賴加密機制的版本歷史自動保留 7 天內的資料狀態

• D. 改用 AWS Backup 的手動備份功能，由值班工程師每天登入主控台為每一顆 volume 各自建立一次 snapshot

問題 5

某位工程師要淘汰一台已經不需要的測試用 EC2 instance，執行 terminate 前確認過這台 instance 除了 root volume 外，還額外掛載了一顆存放測試資料的 data volume。Instance terminate 完成後，工程師發現 root volume 已經被自動刪除，但那顆額外掛載的 data volume 卻還留在帳號裡繼續計費，讓他有點意外。

這個結果最可能的原因是什麼？

• A. 這是異常行為，正常情況下 instance terminate 時，root volume 與所有額外掛載的資料 volume 都會一起被刪除，需要回報 AWS 支援

• B. 這是 EBS 的預設行為，root volume 的 DeleteOnTermination 屬性預設為 true 會跟著刪除，額外掛載的資料 volume 預設為 false 會被保留下來

• C. 這是因為那顆資料 volume 當時正在被另一個 snapshot 讀取，AWS 為了避免資料遺失而暫時鎖住無法刪除

• D. 這是因為資料 volume 的類型是 io2，io2 類型的 volume 在 instance terminate 時一律不會被刪除，而 gp3 類型才會被刪除

💡 解答

1. B

EBS volume 是 AZ 層級的資源，無法直接掛到別的 AZ，但 snapshot 是 Region 層級的，能拿去任何一個 AZ 建立新 volume；這是文章提到「跨 AZ 搬 volume」的標準做法，不會遺失資料。

A 是常見誤解：volume 本身出不了原本的 AZ，卸載後也無法掛到另一個 AZ 的 instance。C 同樣是誤解：EBS volume 一次只能掛給一台 instance（Multi-Attach 除外，而且 Multi-Attach 也要求同一個 AZ），兩台不同 AZ 的 instance 不可能共用同一顆 volume。D 把 Elastic Volumes 的功能用錯地方：它只能線上調整容量、類型與 IOPS，不能改變 volume 所在的 AZ。

2. C

st1 是針對大型、循序讀寫的吞吐量密集工作設計的 HDD 類型，單價比 SSD 類的 gp3、io2 低，剛好對應題目「循序讀取、對隨機延遲沒要求、但要穩定高吞吐量」的描述，也符合每天高頻存取（不是冷資料）的使用型態。

A 的 io2 主打低延遲、高 IOPS，是給隨機小區塊、高頻率存取的關鍵資料庫用的，拿來處理純循序大區塊的吞吐量工作是不必要的高成本。B 的 sc1 雖然更便宜，但吞吐量與 IOPS 都是四種類型裡最低的，適合幾乎不存取的冷資料，不符合「幾乎每天都要跑」的高頻使用情境。D 的 gp3 是 IOPS 導向的效能基準，雖然也能處理吞吐量工作，但不是針對這種情境設計，對純吞吐量密集的大量循序讀寫來說，選 st1 的成本效益更好。

3. A

Elastic Volumes 可以在 volume 保持掛載、instance 持續運作的狀態下，直接調整容量、類型或 IOPS，不需要停機或卸載，剛好對應「不能接受停機」的限制。

B 雖然能達到目的，但要停止 instance、卸載舊 volume、掛上新 volume，整個過程服務會中斷，違反不能停機的要求。C 同樣要求先停機才能換類型，而且這個調整本來就不需要換成 io2——gp3 本身就支援到遠高於 6,000 的 IOPS 範圍，用 Elastic Volumes 直接把既有 gp3 的 IOPS 調高即可達到目標，不必連類型都換。D 需要在正式環境資料庫上手動搬遷資料目錄、修改設定路徑，操作風險高，維運負擔也遠高於直接調整既有 volume 的 IOPS。

4. A

Data Lifecycle Manager 可以依標籤自動選取一批 volume，設定排程規則（例如每天一次、保留 7 天），到期的 snapshot 會自動清除，整個流程不需要工程師手動介入，也不用自己寫腳本或排程。

B 技術上能達成同樣的排程效果，但要在每台 instance 上維護 cron job 和自訂的清理腳本，維運負擔遠高於原生服務。C 是誤解：EBS 加密只負責靜態與傳輸加密，沒有版本歷史或保留天數這種備份功能。D 的「值班工程師每天手動做」直接違反題目「不需要工程師手動介入」的要求，也是造成最初備份事故的同一種做法。

5. B

EBS 的 DeleteOnTermination 屬性，root volume 預設是 true，instance terminate 時會跟著被刪除；額外掛載的資料 volume 預設是 false，會被保留下來繼續計費，這個方向剛好跟直覺相反，是文章特別提醒容易搞混的地方。

A 是錯的：並非所有 volume 都會一起被刪除，兩種 volume 的預設行為本來就不同。C 是憑空捏造的理由，snapshot 讀取不會鎖住來源 volume 讓它無法刪除。D 也是誤解：volume 是否在 terminate 時被刪除，是由 DeleteOnTermination 這個屬性決定，跟 volume 類型是 gp3 還是 io2 無關。