AWS企業帳號代開 AWS EC2執行個體無法啟動的常見原因分析

第一章：先搞清楚「不能啟動」到底是哪一種失敗

很多人遇到「EC2 執行個體無法啟動」會直接從重裝系統開始，但這通常浪費時間。真正的關鍵是：你要先判斷它卡在哪個階段。EC2 從你點下啟動到系統進入可用狀態，大致會經過「控制面啟動」、「狀態檢查」、「進入作業系統」幾段。不同階段對應的原因完全不同。

實務上，我會用一個很直覺的方式把問題切開：它是 壓根沒啟動成功，還是 啟動了但作業系統層失敗？

• 如果控制台顯示啟動失敗或立刻回到「停止」：多半是啟動參數、權限、容量、磁碟/映像、或 VPC/網路設定導致的早期失敗。
• 如果啟動成功但「狀態檢查」顯示不通過：通常是系統級問題，例如開機磁區、驅動、檔案系統、網路介面無法初始化等。
• AWS企業帳號代開 如果啟動成功且狀態檢查通過，但你就是連不上：那就進到安全組、NACL、路由、私網/公網、登入使用者/金鑰等「可連線」問題。

你會發現，把問題按階段定義好，後續排查就會快很多。下面我會把最常見的原因按類型整理，並給出可操作的檢查路徑。

第二章：狀態檢查是你的羅盤

在 AWS 主控台的執行個體頁面裡，查看「狀態檢查（Status checks）」非常重要。通常會出現兩種：系統狀態檢查（System status checks）與 執行個體狀態檢查（Instance status checks）。

2.1 系統狀態檢查不通過：偏向硬體或網路底層

AWS企業帳號代開 當系統狀態檢查不通過，問題多半不在你打包的 AMI，而在底層資源或連線路徑上。常見原因包括：

• 底層主機或虛擬化層出現異常（AWS 偵測到）。
• 網路不可用或路由問題導致無法與控制面通信。
• 啟用的網路介面/子網環境不符合要求。

這時候你可以先做兩件事：確認同一個子網是否也影響其他執行個體、以及查看是否近期有 VPC/NACL/路由表變更。

2.2 執行個體狀態檢查不通過：偏向 OS 或啟動流程

如果是執行個體狀態檢查不通過，往往與 OS 開機失敗、磁碟掛載失敗、服務沒起來、憑證/金鑰配置錯等相關。典型情況包括：

• 沒有足夠的磁碟空間導致開機過程中服務或檔案系統檢查失敗。
• 開機腳本依賴的環境不存在（例如依賴掛載的 EBS 但它並未正確附加或命名錯誤）。
• 網路初始化失敗（例如自動配置檔案不相容、網卡名稱變更）。

接下來就要看更具體的線索，例如：系統日誌、開機時的事件、以及控制台提供的診斷輸出。

AWS企業帳號代開 第三章：啟動前就失敗的常見原因

有些問題會在你按啟動後立即顯示異常。這類通常不是 OS 的問題，而是「執行個體還沒真正進入正常開機流程」。以下是最常見的幾個。

3.1 容量不足或配額限制（Capacity / Quota）

當你用特定實例型別、特定 AZ、或特定啟動模板去啟動時，很容易碰到容量不足。你可能會看到類似「容量不足」或「無法滿足容量需求」的訊息。

排查方式很簡單：

• 嘗試更換 AZ 或改用相同規格的替代型別。
• 檢查該區域的 vCPU/實例數量是否超過配額。
• 如果你使用 Spot，檢查中斷事件或中止原因。

許多人只盯著 OS，而忽略了「根本沒分配到資源」。這種錯誤代價很高，因為你會在錯的層級修復。

3.2 啟動模板/參數錯誤，導致無法附加或啟動

AWS企業帳號代開 如果你是使用 Launch Template 或自動化（例如用 EC2 Fleet/ASG）去啟動，最常見是參數在某次改動後不相容：

• 指定了不存在的安全群組、子網或快照 ID。
• 指定了錯誤的 KMS key（造成磁碟無法解密）。
• 指定了 AMI 但該 AMI 在該區域不存在或架構不匹配（例如 ARM vs x86）。

建議你回到啟動事件的參數，逐項比對「模板定義」與「你以為會用的資源」。尤其是快照與 KMS 這兩個，錯一個字就全盤失效。

3.3 AMI 架構或開機核心（Kernel/Bootloader）不相容

某些系統使用特定開機核心或自帶特定假設（例如特定虛擬化或特定驅動）。當 AMI 被改造過、或你把不同架構的鏡像拿去跑，就會出現「啟動卡住」或狀態檢查不通過。

• 確保 AMI 的平台（x86_64/arm64）與你選擇的實例型別相符。
• 如果你有自訂 kernel/ramdisk，檢查它是否與該 AMI 的系統相匹配。
• 若你從第三方來源拿鏡像，特別要注意「啟動需求」文件。

3.4 EBS 卷（磁碟）相關問題：快照、大小、加密與掛載

AWS企業帳號代開 EBS 不是每次都明顯，但它確實是「無法啟動」的大宗原因之一。

常見坑包括：

• 快照損壞或不完整：恢復後開機失敗。
• 卷大小與檔案系統假設不符：某些系統初始化在啟動時會檢查分區大小，大小不足會卡住。
• 加密卷使用錯 KMS key：附加或解密失敗，系統自然起不來。
• 裝置名稱不一致：你在 fstab 或 init scripts 中寫死 /dev/xvdf 之類，但實際開機後裝置可能變成別的名稱。

你可以優先檢查啟動事件與執行個體的「EBS 初始化」相關日誌。若你使用自動化附加資料卷，也要確認它是否在開機早期就需要掛載。

第四章：安全群組/NACL/VPC 網路問題（連得上與否常被誤判成啟動失敗）

很多團隊遇到「連不到」時，會以為 EC2 沒啟動。其實 EC2 可能早就啟動完成了，只是你沒有辦法進入。

區分方式也很簡單：如果執行個體狀態檢查通過，且系統本身正常運行，那問題通常在網路或登入層。

4.1 安全群組放行不足：尤其是 SSH/RDP 或應用端口

安全群組是最常見的阻擋點。典型情境：

• 只放行了 22/3389，但來源 IP 不在允許範圍內（公司網段變動、雲端防火牆變更）。
• 安全群組與網卡綁定錯了，導致你以為放行了卻其實沒綁上。
• 忘了啟用出站（通常默認允許出站，但自訂策略可能關掉）。

4.2 NACL 或路由表問題：狀態檢查可能通過，但連線仍失敗

NACL 是「無狀態」的，會比你想得更嚴格。即使安全群組放行，NACL 仍可能擋住 return traffic。

另外，路由表也是常見雷點：

• AWS企業帳號代開 公網子網沒有正確的 Internet Gateway 或路由。
• 私網子網沒有 NAT Gateway，導致你在系統中更新套件或拉取資源失敗（表面像「卡住」。）
• 跨 AZ 走錯路由，導致回包不可達。

如果你的系統啟動過程中需要連到外部服務（例如下載套件、連到 S3），那麼網路問題也會讓 OS 初始化失敗，進一步被你誤認為「EC2 沒啟動」。

第五章：登入失敗（金鑰、使用者、服務）常被誤當成啟動問題

有時候執行個體其實早就活著，只是你無法登入。這類問題往往表現在：狀態檢查通過，但 SSH 超時或憑證錯誤。

5.1 金鑰（Key pair）不匹配或用錯區域的金鑰

• 啟動時選錯 Key pair：你拿到的是另一組私鑰，當然連不上。
• 金鑰刪除後無法再拿去登入（雖然執行個體仍可能存在，但你缺少正確憑證）。

5.2 OS 使用者密鑰或 cloud-init 配置失敗

尤其是你使用自動化部署（cloud-init、System Manager、或映像自帶的初始化腳本），如果 cloud-init 失敗，可能直接造成：

• SSH service 沒開
• 使用者沒建立
• authorized_keys 沒寫入
• 主機名稱或網路設定導致沒有可用 IP

這時建議你在系統日誌中查 cloud-init 的錯誤，而不是盲目重建。

5.3 安全設定檔導致 SSH/防火牆擋掉

如果系統有自動化硬化策略（例如改用 firewalld、ufw、或硬編 SSH 規則），可能在啟動後立刻把你擋在門外。這類不是雲端安全群組問題，而是 OS 內部策略。

第六章：作業系統開機失敗的典型原因（真正會造成「狀態檢查不通過」）

當執行個體狀態檢查不通過，你應該把注意力放回作業系統本身。以下是最常遇到的情境。

6.1 磁碟空間不足或檔案系統檢查失敗

啟動階段如果需要寫入日誌、快取或臨時檔，磁碟空間不足很容易讓流程中斷。更糟的是，檔案系統若出現錯誤，可能在開機時進入修復流程，卻因為某些依賴缺失而失敗。

常見來源：

• 從舊系統做快照/映像搬移到較小的卷
• 磁碟策略改了但你沒調整分區
• 應用寫爆 root volume

6.2 fstab 或裝置識別碼錯誤，導致掛載卡住

很多系統把裝置寫死在 fstab 裡，例如 /dev/xvdf。只要裝置順序或命名變了，開機就可能卡在「掛載資料卷」。

更穩定的做法是用 UUID 或 label 來識別。不過重點是：當你看到開機卡住或狀態檢查不通過，檢查 fstab 常常能快速找到原因。

6.3 網路初始化失敗（例如網卡名稱變更、netplan 設定不相容）

近年來 Linux 發行版對網卡命名與設定方式變化較大。若你的映像或腳本假設特定網卡名稱（eth0、ens5 等），換到新環境可能失效。

• AWS企業帳號代開 網路服務無法啟動導致沒有 IP
• 路由配置缺失導致無法連外
• 開機時依賴網路（下載設定或取密鑰）而失敗

這類問題看似是網路，但根因可能是 OS 設定不相容。

6.4 驅動或核心模組缺失（尤其是自訂 AMI 或特殊映像）

如果你自建 AMI，可能在打包過程中不小心排除了必要模組或驅動。典型結果是：

• 網卡驅動不工作，無法建立網路
• EBS 或存儲相關驅動不工作，磁碟掛載失敗

這在跨架構或跨核心版本時更常見。

6.5 cloud-init/啟動腳本錯誤或權限不足

cloud-init 是常見的初始化框架。它的失敗可能不是立刻讓系統死掉，而是造成關鍵服務沒起來。你要留意腳本是否：

• 依賴某個檔案存在，但實際不存在
• 使用了錯誤權限，導致寫入失敗
• AWS企業帳號代開 命令引用了環境變數，但在該階段變數沒有被設置

當你看到服務層起不來，同時狀態檢查也不通過時，cloud-init 錯誤往往是第一嫌疑。

AWS企業帳號代開 第七章：KMS、IAM 角色與加密解密問題（沉默但致命）

很多人忽略權限與加密。當你的 EBS 或 AMI 使用 KMS 加密，而執行個體角色缺少必要權限，磁碟可能無法解密，最終導致開機失敗。

7.1 執行角色（Instance profile）沒有 KMS 權限

• 缺少 kms:Decrypt
• 對應的 Key policy 不允許該角色
• 同名但不同帳戶/不同區域的 KMS key 被指定

你可以先檢查啟動時是否有明確的加密相關錯誤訊息，再回頭查 IAM 與 Key policy。

7.2 使用了需要外部存取的模板，但沒有相應網路或憑證

如果啟動腳本或 cloud-init 需要存取 S3/SSM/Secrets Manager 取配置，卻因為網路或 IAM 問題而失敗，也會導致應用層起不來，進一步觸發你以為的「不能啟動」。

這時候排查要同時看：雲端權限、系統日誌、以及網路路徑是否可達。

第八章：事件性因素與「最近有做變更嗎？」

絕大多數可用問題不是憑空發生。EC2 開不來，往往和最近的變更有關。這裡我建議你在排查初期就問三個問題：

• 最近是否更新過啟動模板、AMI、快照、或 EBS 卷配置？
• 最近是否改過 VPC（路由表、NACL、安全群組）？
• 最近是否改過 IAM 角色或 KMS key policy？

很多時候，真正的原因在「那次部署」或「那次網路調整」，而不是在當前你新增的配置。

8.1 VPC/子網/路由表變更造成回包或初始化失敗

如果你最近調整了路由或安全策略，執行個體可能在某個階段無法連回控制面，表現為狀態檢查不通過或初始化卡住。

8.2 配額、策略或服務中斷造成的短期不可用

雖然不常見，但也會發生：你的帳號配額突然不足、或某服務限制改變、或 AWS 區域出現異常。這種情況通常會在你啟動當下反映出更明確的錯誤訊息。

當你遇到不尋常的錯誤碼或大批量執行個體同時失敗，別只查單一機器，應該把時間範圍拉到最近變更與事件。

第九章：一條實用的排查路徑（照著做通常能縮小範圍）

下面給你一個「不依賴猜測」的排查流程。你可以把它當作現場 SOP。

9.1 先看執行個體狀態與狀態檢查

• 狀態檢查通過：偏向連線/登入/應用服務層問題。
• 系統狀態檢查不通過：偏向底層資源或網路底層不可達。
• 執行個體狀態檢查不通過：偏向 OS 開機、磁碟掛載、初始化腳本。

9.2 再看啟動事件與錯誤訊息（不要跳過）

控制台通常會給你相對清楚的原因線索。尤其是容量不足、權限/解密、快照/磁碟掛載失敗，常常會出現可辨識的字眼。

9.3 核對啟動模板/參數與資源是否一致

• AMI ID 是否正確、是否跨區域。
• Key pair、啟動腳本、cloud-init 是否與預期一致。
• EBS 卷是否使用對的快照、對的 KMS key、對的大小與類型。

9.4 檢查網路路徑與安全策略

• 安全群組：入站/出站是否符合你要的服務端口。
• NACL：是否擋了回程。
• 路由表：公網/私網是否能走到該走的地方（尤其是要連外時）。

9.5 最後才是進到 OS 日誌與服務

當你確認不是雲端容量、不是權限、不是網路策略，那就去看系統日誌：cloud-init、掛載、檔案系統、網路服務、SSH/登入服務。

這樣你才能真正做到「定位原因」而不是「碰碰運氣」。

第十章：常見情境對照表（快速對號入座）

為了讓你更快判斷，我用幾個常見案例做對照。你可以用它快速縮小到幾類原因，再回到前面的排查路徑。

10.1 啟動就失敗，顯示容量不足

先處理容量/配額：換 AZ、替代實例型別、調整啟動策略或等候。

10.2 啟動失敗與 KMS/解密相關

檢查 EBS/AMI 的加密來源，以及執行角色與 Key policy 是否允許 kms:Decrypt。

10.3 啟動成功但狀態檢查不通過

優先查 OS 開機流程：磁碟掛載、檔案系統、cloud-init、網路初始化。

10.4 狀態檢查通過但連不上 SSH

以安全群組/NACL/路由與登入憑證為主：Key pair 是否正確、SSH port 是否放行、cloud-init 是否寫入 authorized_keys。

10.5 啟動後服務起不來、更新套件失敗

通常是私網子網沒有 NAT、路由缺失，或 IAM 權限不足導致外部存取失敗。

第十一章：怎麼避免下次再踩同樣的坑

修好一次還不夠，最重要是把問題變成流程。這裡提供一些經驗法則：

• 模板與鏡像版本要可追溯：啟動模板改動、AMI 更新、快照替換都要有版本管理，避免「昨天還能用今天就不行」卻找不到差異。
• 磁碟識別用 UUID：避免依賴 /dev/xvdf 這種可能變動的裝置命名。
• AWS企業帳號代開 加密權限預先檢查：使用 KMS 時，啟動前就核對角色與 Key policy。
• 把 cloud-init 失敗當成高優先級：日誌要保留，且部署流程要能回放錯誤。
• 網路環境要在測試中覆蓋：私網與公網、不同子網路由要做最小驗證，避免上線才發現不能連外。

當你能在部署前就排除高機率錯誤，後續遇到「無法啟動」時，你就會從容很多。

結語：不要急著重裝，先用階段判斷再逐層縮小

EC2 無法啟動的原因非常多，但它們不是亂的。只要你遵循「先看狀態檢查」→「再看啟動事件」→「核對參數與資源」→「檢查網路與權限」→「最後才進 OS 日誌」這條路，幾乎可以把排查時間壓到最短。

真正讓人痛苦的，通常不是問題本身，而是沒有一套可重複的判斷方式。希望你讀完這篇後，下次遇到同樣的情況，能少走幾步彎路，快速把根因抓出來。