AWS帳號認證服務 AWS Batch 作業卡在 RUNNABLE 狀態無法調度：Compute Environment 配置排查

先看結論：RUNNABLE 不是壞掉，而是在等能接單的算力

AWS Batch 作業卡在 RUNNABLE，意思不是作業已經開始執行，也不是一定發生錯誤，而是系統已經接受這個作業，卻暫時找不到符合條件的 Compute Environment 來排程。很多人一看到這個狀態，就先懷疑程式、Docker 映像或日誌，其實真正的問題常常藏在資源配置。

簡單說，Batch 調度作業時會同時看幾件事：作業需要多少 vCPU、多少記憶體、是否需要 GPU、CPU 架構是 x86 還是 Arm、隊列綁定了哪些 Compute Environment、這些 CE 是否啟用、是否有可用的 EC2 容量、子網是否還有 IP、IAM 權限是否完整。只要其中一個條件不成立，作業就可能一直停在 RUNNABLE。

因此，排查這類問題的關鍵不是盲目重啟，而是先確認作業是否真的有資格被調度，再看 Compute Environment 能不能把它接住。只要順序對了，通常都能很快縮小範圍。

一、先分清楚：是作業限制太嚴，還是 CE 根本無法擴容

先看 job definition 的需求

很多 RUNNABLE 的根因，其實早就寫在 job definition 裡。比如作業要求 8 vCPU、32 GiB 記憶體，但你的 Compute Environment 只允許很小的實例規格，Batch 就算想排，也找不到符合條件的機器。又比如作業是 Arm 映像，CE 卻只提供 x86 實例，這種架構不匹配也會讓它卡住。

如果是多容器或多節點工作，還要看資源是否被單個節點上限限制。Batch 不是只看總量，而是看是否能在某一個容器實例上落地。很多人把 vCPU 和記憶體設得很大，結果 CE 的 instance type 根本沒有這麼高的規格，作業自然只能排隊。

再看 job queue 和 Compute Environment 的綁定順序

Job queue 可以綁多個 Compute Environment，但它們有順序，也有啟用狀態。你以為系統會自動挑一個可用的，其實不一定。如果排在前面的 CE 雖然存在，卻是 DISABLED、INVALID，或已經達到上限，Batch 就只能繼續往後找。若後面的 CE 又不符合作業需求，作業就會長時間停在 RUNNABLE。

因此，先確認 queue 是否 ENABLED，再看每個 CE 的狀態是不是 VALID。這一步非常重要，因為很多現場問題不是資源不夠，而是其中一個環節被人手動關掉了，或者修改配置後 CE 進入了異常狀態。

二、最常見的 8 個配置坑

1. vCPU、記憶體與實例規格對不上

這是最常見、也最容易被忽略的原因。作業需求 16 vCPU、64 GiB 記憶體，但 CE 只允許 t 系列或較小的 m 系列，Batch 就無法找到合適節點。尤其在使用固定實例類型時，問題更明顯。你以為開了很多台，實際上每台都裝不下這個作業。

解法很直接：要麼把作業需求調低，要麼擴大 Compute Environment 可用的 instance types，讓調度器有更多選擇。對大作業來說，單一小型實例種類通常不是好主意。

2. Max vCPUs 設太低，隊列再多也排不上去

Compute Environment 的 maxvCpus 是硬上限。當所有作業加起來需要的容量超過這個值，Batch 不會憑空變出更多實例。很多人為了控成本，把上限設得很保守，結果高峰期作業全部堆在 RUNNABLE。這不是調度器不努力，而是你事先把門關小了。

AWS帳號認證服務 如果是常態性批次任務，建議根據尖峰量預留一部分餘裕。若是偶發大批次，也要至少確保上限高於單次峰值，否則任務永遠排不完。

3. 子網沒有足夠的可用 IP

AWS帳號認證服務 AWS Batch 在 EC2 模式下，實例需要在子網裡取得私有 IP。當子網 IP 來源不足時，即使 EC2 配額還夠，Batch 也無法成功啟動新機器。這種情況在容器數量多、子網太小、或者長期沒有整理舊資源時特別常見。

一個常見誤區是只選了單一子網，甚至單一可用區。只要那個子網的可用 IP 用盡，整個 CE 就會卡住。比較穩妥的做法，是至少提供兩個以上子網，分散到不同可用區，讓調度器有更多落點。

4. 安全組、路由表、NACL 阻斷了實例正常啟動

安全組通常不會直接讓作業停在 RUNNABLE，但網路配置錯誤會讓實例無法正常完成啟動流程，最終表現成 CE 不可用或擴容失敗。若實例放在私有子網，卻沒有 NAT 或對外路由，鏡像拉取、服務註冊、元資料存取都可能出問題。這時候你看到的不是明顯報錯，而是一個一直沒被接住的作業隊列。

排查時，不要只看安全組，路由表、NACL、VPC 端點都要一起看。尤其是使用私有鏡像倉庫、私有子網、以及嚴格出站限制的環境，最容易忽略這一層。

5. IAM role 權限不足

Compute Environment 需要正確的 service role，EC2 實例也需要 instance role。少了必要權限，Batch 可能無法建立實例、掛載日誌、拉取映像，或向 ECS 註冊。對外看起來像是作業排隊，實際上是底層資源根本沒有成功啟動。

權限問題最麻煩的地方在於，它不一定在第一時間報得很明確。建議直接核對 Batch 相關角色是否完整，尤其是修改過預設角色、或跨帳號部署時，更要小心。

6. Instance type 太窄，沒有留下調度空間

有些團隊為了成本只允許少數幾種 instance type，結果 Batch 只能在非常狹窄的範圍裡找機器。當 Spot 容量波動、區域臨時供應不足，或某種規格恰好缺貨時，作業就會堆在 RUNNABLE。這在高峰期尤其明顯。

與其只放一兩種實例，不如按作業大小分層配置。例如小任務用通用型實例，大任務允許更大規格，甚至乾脆分成多個 job queue，避免不同需求互相卡住。

7. Spot 容量波動太大，策略又太保守

如果你用的是 Spot Compute Environment，RUNNABLE 更常見。因為 Spot 本來就受市場容量影響，若 instance type 過窄，或分配策略過於保守，Batch 會找不到足夠便宜又可用的容量。這不是故障，而是容量現實。

想降低卡單機率，就要把 instance type 範圍放寬，並選擇更適合 Spot 的策略。不要只盯著價格，也要看可獲得性。便宜但永遠起不來的容量，對批次作業沒有任何價值。

8. Fargate 和 EC2 模式搞混

有些作業定義寫的是 Fargate 需要的參數，但 CE 卻建在 EC2；或者相反，作業本身依賴 EC2 特有能力，卻放進 Fargate queue。這類模式不匹配，常常不會直接噴出很直白的錯，而是讓作業一直等不到合適的執行環境。

如果團隊同時使用兩種模式，最好把 queue 分開管理，不要混在一起。名稱看起來都叫 Batch，但底層調度邏輯完全不同。

三、真正有效的排查順序

第一步：看作業詳情，不要先動手改配置

先查作業狀態與原因，確認它是不是一直在等待資源。這一步最重要，因為它能告訴你問題是在作業層、隊列層，還是 CE 層。可以先用以下命令看基本資訊：

aws batch describe-jobs --jobs job-id

重點看狀態、statusReason，以及作業需要的資源。很多時候你會發現，作業本身的需求就已經超出了環境能提供的範圍。

第二步：確認 queue 是否正常綁定到 CE

AWS帳號認證服務 接著看 job queue 的配置，確認它是否仍然指向正確的 Compute Environment。曾經見過不少案例，是環境升級後切換了新 CE，但隊列還指向舊 CE，結果舊環境已經停用，作業當然永遠排不上。

aws batch describe-job-queues --job-queues queue-name

如果 queue 綁了多個 CE，順序也要一起看。很多排隊問題，其實只要把正確的 CE 放到前面，就能立刻改善。

第三步：檢查 Compute Environment 是否有擴容能力

AWS帳號認證服務 再來看 CE 本身，重點是狀態、desired vCPUs、minvCpus、maxvCpus、instance types、subnets、allocation strategy。這些配置裡，只要有一項卡死，Batch 就無法把作業往下送。

aws batch describe-compute-environments --compute-environments ce-name

如果 CE 顯示 INVALID，先不要急著改作業，應該先找出是哪個基礎配置出錯。常見的是子網刪掉了、角色失效了、實例類型不再可用、或 launch template 被改壞。

第四步：去看雲端監控和事件紀錄

如果 Batch 介面看不出來問題，下一步就看 CloudWatch、EC2 事件、Auto Scaling 活動紀錄。你會看到更接近底層的訊息，例如容量不足、啟動失敗、權限拒絕、子網無 IP、或區域供應不足。這些訊息往往比 Batch 的表面狀態更有用。

排查這類問題的關鍵，不是只看一個服務，而是把 job、queue、CE、EC2、VPC 串起來看。只看單點，很容易誤判。

四、把配置改對，RUNNABLE 才會真正消失

讓 CE 有足夠的調度彈性

AWS帳號認證服務 最穩妥的做法，是不要把 instance type 限得太死。對通用批次任務來說，應該給 Batch 一組能覆蓋多種規格的實例，而不是只給某一個固定型號。這樣一來，當某個規格暫時缺貨時，調度器還能退而求其次，找別的機器接單。

如果你的任務大小差異很大，最好直接拆成多個 queue。小任務和大任務不要混排，否則小作業會被大作業擠壓，大作業又因為找不到足夠大的實例而一直等待。

子網不要只留一條路

至少提供多個子網，並分佈在不同可用區。這不只是為了高可用，也是為了讓 Batch 在某個 AZ 壓力大時，還能換地方起機。當某個子網 IP 快滿、或某個區域臨時容量吃緊時，多子網配置會明顯提升排程成功率。

預留合理的 vCPU 上限

maxvCpus 不要只按日常量來設，而要考慮峰值。Batch 最怕的不是偶爾慢，而是峰值來時完全沒空間。如果你明明知道晚間會有大量作業，卻把上限壓得很低，那麼 RUNNABLE 只是早晚的事。

權限、網路、配額要一起看

很多團隊只檢查 Batch 配置，卻忽略 AWS 服務配額。當 EC2 vCPU quota、Spot 配額、Elastic Network Interface 限額不足時，Batch 也沒法繼續擴容。這時候不是改一個 job 就會好，而是整個底層配額要補齊。

如果團隊規模已經上來，建議把配額監控納入日常運維。等作業卡住了才去補配額，通常已經耽誤一輪批次窗口。

五、一個很典型的實戰案例

某團隊把大批次轉到 AWS Batch 後，發現作業經常卡在 RUNNABLE。表面看起來 queue 正常、CE 也已啟用，但工作就是不上機。最後排查發現，作業需要 12 vCPU 和 48 GiB 記憶體，而 CE 只允許較小的 instance family；同時子網只放了一個可用區，且該區的 IP 已經接近耗盡。兩個問題疊在一起，導致 Batch 找不到合適實例。

修正方式也很直接：把 CE 的 instance types 擴到更大的家族，增加第二個子網與可用區，並把 maxvCpus 提高到能覆蓋尖峰需求。調整後，作業很快恢復正常，不再長時間滯留 RUNNABLE。這個案例說明，Batch 問題常常不是單點故障，而是多個小配置一起把路堵死了。

六、最後給你一份排查清單

• 作業需求是否超出 CE 可提供的 vCPU、記憶體、GPU 或架構
• Job queue 是否指向正確的 Compute Environment，且 CE 為 ENABLED、VALID
• maxvCpus 是否過低，導致高峰期無法擴容
• 子網是否有足夠可用 IP，是否只綁了單一可用區
• 安全組、路由表、NACL 是否允許實例正常啟動與出站
• IAM service role 與 instance role 是否完整
• EC2 或 Spot 配額是否已用滿
• instance type 是否過窄，是否與作業架構或大小不匹配
• Fargate 與 EC2 模式是否混用錯誤

結語：RUNNABLE 卡住時，先懷疑環境，不要先怪程式

AWS Batch 的 RUNNABLE 狀態，本質上是一個訊號：作業已經排進來了，但目前沒有符合條件的地方可以執行。只要你把排查順序抓對，從 job definition、queue、CE、子網、配額一路往下看，大多數問題都能找到。真正耗時間的，不是修復，而是找對那個被忽略的配置點。

下次再遇到作業卡在 RUNNABLE，不妨先問自己三個問題：這個作業需要什麼？CE 真能提供嗎？底層資源真的還有空位嗎？這三個問題一旦回答清楚，調度問題通常就不再神祕。