AWS ECS Service：讓你的容器穩定持續運行的關鍵機制
更新日期： 2025 年 6 月 17 日
當你使用 AWS ECS（Elastic Container Service）成功啟動一個 Task，看見容器開始執行時，也許會有一種「大功告成」的錯覺。
但你會發現：
- Task 執行完就會結束（像定時任務、資料處理等）。
- 如果容器異常退出，不會自動重啟。
- 想要一直維持某個服務（像 API 或前端伺服器）在線上？那就得手動重新啟動 Task……
這時候，就需要一個「指揮家」來幫你穩定安排 Task 的運行狀態。
這個角色就是 ECS Service。
什麼是 ECS Service？—容器世界中的「導演」
在 AWS ECS 的架構中，Task 是一個實際執行容器的單位。
你可以把 Task 想成是一場演出中的「演員」，它穿著容器這套戲服，在舞台上演出某個角色，例如提供一個 API、處理使用者上傳的圖片、或是處理排程任務。
但如果你只是手動啟動一個 Task，這個 Task 就像一位演員自己登台，演完就下台。
若這位演員突然病倒（容器崩潰），整場戲就沒人演了。
這樣的運作方式無法保證應用程式穩定且持續提供服務。
這時候就需要「導演」來掌控全場，確保每個演員（Task）都就位、有人生病馬上補位、場上始終維持演出水準。這個導演就是——ECS Service。
ECS Service 的核心目的
ECS Service 是一種持續監控與管理 Task 的控制器，能自動確保你的容器服務「一直有在執行，而且數量正確」。
它不只是一次性地「啟動一個 Task」，而是：
- ✅ 維持固定數量的 Task 運行中（例如你設定要 3 個副本，就會永遠維持 3 個）
- ✅ 當 Task 當掉時，會自動重啟一個新的補上
- ✅ 可以設定 Auto Scaling，根據負載自動增加或減少 Task 數量
- ✅ 可以結合 Application Load Balancer，將使用者請求平均分派給這些 Task
這讓你的應用服務可以像雲一樣彈性伸縮，不會因為容器當掉或訪問量暴增而中斷。
生活化類比：戲劇演出 vs 容器服務
| 元素 | ECS 對應概念 | 說明 |
|---|---|---|
| 演員（Actor） | Task | 每個 Task 就是一個容器任務，執行應用邏輯 |
| 戲服（Costume） | Container | Task 內部穿的就是容器 Image，決定它演什麼戲 |
| 導演（Director） | ECS Service | 決定什麼時候該派人上場、場上維持幾個演員、是否需要替補或增援 |
| 演出舞台（Stage） | ECS Cluster | 容器任務實際執行的地方，可以是 EC2 或 Fargate |
| 觀眾（Audience） | 使用者請求 | 使用者透過 Load Balancer 對外連線，觀賞這場服務演出 |
這個類比幫助你理解：ECS Service 負責的是持續性、穩定性與擴展性，而不是單純一次性的啟動行為。
為什麼需要 ECS Service？
| 情境 | 沒有 ECS Service 的結果 | 使用 ECS Service 的好處 |
|---|---|---|
| 容器當掉 | 手動重新啟動，非常麻煩 | 自動重新啟動容器 |
| 多個容器提供服務 | 手動部署、難以同步 | 自動啟動多個 Task，整合 ALB |
| 流量忽然暴增 | 容器無法負荷請求 | 可搭配 Auto Scaling，自動增加 Task |
| 想讓服務 24 小時在線 | 無法保證穩定 | 持續監控、補足 Task 數量 |
🧠 一句話總結：
ECS Task 負責「演戲」，ECS Service 負責「讓戲不間斷」。
若你想讓你的應用服務真正進入生產環境，具備高度可用性與穩定性，ECS Service 是必備的角色。
ECS Service 的三大核心功能：讓你的服務 24 小時不間斷
ECS Service 的價值在於持續穩定地運行容器應用程式，就像一位貼心又可靠的自動化指揮官。
以下是它最重要的三個功能，也是讓你從「自己養容器」變成「讓 AWS 幫你養容器」的關鍵差異：
自動重啟 Task（Auto Recovery）— 系統故障時的自動補位機制
在沒有 Service 的情況下，如果一個 Task（容器）崩潰了，那你就只能自己手動重啟。
這在小規模測試還勉強可以接受，但在實務上是不可能容忍的風險。
有了 ECS Service，就像有一個「容器總管」時時在檢查場上有幾位演員還在線：
- 如果其中一個 Task 掛了（容器錯誤退出、節點失聯等），Service 馬上啟動一個新的 Task 補上。
- 這是透過「Desired Count（期望數量）」來控制的。
你告訴 Service：「我要 3 個 Task」，它就會永遠幫你維持這個數字。
📌 這項功能特別適合用在：
- API 伺服器
- 即時聊天室
- 線上服務的主程式
- 任何不能中斷的系統服務
自動擴展與縮減（Auto Scaling）— 流量高峰的救星，離峰時的省錢法寶
當你的服務開始面對不穩定的使用流量（例如白天使用者爆增、晚上安靜如雞），你不會希望始終維持一樣的容器數量，這樣要嘛撐不住，要嘛浪費資源。
ECS Service 支援 Auto Scaling 功能，能根據你設定的條件，自動增加或減少 Task 的數量。
📈 常見的自動擴縮觸發條件包括：
- CPU 使用率大於 70% 超過 1 分鐘 ➜ 增加 Task
- Memory 使用率小於 30% 持續 5 分鐘 ➜ 減少 Task
這些條件可以透過 CloudWatch 指標 來設定，甚至也能根據隊列長度、API 請求速率等自定義指標調整。
📌 Auto Scaling 能帶來：
- 在高峰時自動擴容，防止服務崩潰
- 在低谷時自動縮容，節省雲端支出
- 彈性部署，真正落實「按需計費」的雲端精神
整合 Load Balancer（對外提供穩定服務）— 讓使用者連得上，也連得快
當你有多個 Task 時，如何讓使用者「公平地」分流到這些容器呢？
這時候就要靠 Application Load Balancer（ALB）。
ECS Service 支援直接整合 ALB，達成以下效果：
- 每個 Task 被 ALB 註冊為一個 Target（目標實例）
- 當使用者發送請求，ALB 會根據健康狀態與流量規則，將請求分配到其中一個 Task
- 若某個 Task 不健康（例如不回應 HTTP 健康檢查），ALB 就不會分派請求給它
💡 實際應用場景：
| 應用類型 | 整合 ALB 帶來的好處 |
|---|---|
| Web 前端 | 用戶請求自動分流，提升回應速度 |
| RESTful API | 當其中一個 Task 爆炸時，ALB 自動避開故障容器 |
| 多容器架構 | 每個容器服務掛在不同的路由或端口，由 ALB 管控 |
圖解補充：ECS Service 如何串聯整個運作流程？
graph TB
User[👤 使用者請求<br/>HTTP] --> ALB[🔄 Application Load Balancer]
ALB --> Task1[📦 Task 1<br/>API 服務]
ALB --> Task2[📦 Task 2<br/>API 服務]
subgraph ECS["🎛️ ECS Service 控制"]
Health[❤️ 健康檢查]
Recovery[🔧 自動修復]
Scale[📊 Task 數量管理]
end
ECS -.管理.-> Task1
ECS -.管理.-> Task2
classDef userStyle fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef albStyle fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef taskStyle fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
classDef ecsStyle fill:#fff3e0,stroke:#f57c00,stroke-width:2px
class User userStyle
class ALB albStyle
class Task1,Task2 taskStyle
class ECS ecsStyle📍 圖解說明：
- ALB 是統一入口點（使用者不需要知道有幾個 Task）
- Task 是背後的實際運算單元
- ECS Service 保證 Task 數量與健康狀態，負責調度與維護
- 若 Task 失效，Service 重啟；若流量變動，Service 幫你擴縮容器
建立 ECS Service 的基本流程（Fargate 範例）
建立一個 ECS Service，等於是把你的應用服務「自動化長時間運行」起來，以下是使用 AWS CLI 的步驟拆解與說明：
步驟一：準備工作
在執行建立 Service 的指令之前，你需要先完成以下幾個前置條件：
建立 ECS Cluster
aws ecs create-cluster --cluster-name my-cluster建立 Task Definition
這會定義容器該怎麼執行（使用哪個映像檔、port、記憶體、CPU…）
aws ecs register-task-definition --cli-input-json file://task-definition.json設定 ALB 與 Target Group（若需要對外服務）
- ALB 是負責流量分發的入口
- Target Group 是 Task 的集合，ALB 把流量導向這裡
建立 VPC 子網路與安全群組
- 用於讓容器在 Fargate 模式下能夠正常連網
- 至少需要一個 Subnet 和一個 Security Group
步驟二：建立 ECS Service（CLI 語法說明）
aws ecs create-service \
--cluster my-cluster \ # 指定你的 ECS Cluster 名稱
--service-name my-api-service \ # 幫你的 Service 取一個名稱
--task-definition my-task-def:1 \ # 使用哪一個 Task Definition（含版本）
--desired-count 2 \ # 要維持幾個 Task 執行中
--launch-type FARGATE \ # 使用 Fargate 模式，不需管理 EC2
--network-configuration "awsvpcConfiguration={ # VPC 設定
subnets=[subnet-abc123], # 指定子網路 ID
securityGroups=[sg-abc123], # 指定安全群組 ID
assignPublicIp=ENABLED # 是否分配公開 IP（若要對外開放）
}" \
--load-balancers "targetGroupArn=arn:aws:..., # ALB 的 Target Group ARN
containerName=my-container, # 要連接的容器名稱（與 Task Definition 一致）
containerPort=80" # 要導流的容器內部 port📌 指令結果：這個 Service 建立好後，會在你指定的 Cluster 上，啟動 2 個 Task，並透過 ALB 對外提供服務。
若其中一個 Task 當掉，ECS 會自動補上。若使用者連進來，請求會透過 ALB 分發到健康的 Task。
🧠 小技巧：也可以用 capacity-provider-strategy 來指定混合使用 EC2 / Fargate
--capacity-provider-strategy capacityProvider=FARGATE,weight=1適合進階應用，例如你希望部分 Task 用 Fargate，部分跑在自管的 EC2 上。
小提醒：什麼時候該使用 ECS Service？
你不需要為所有的容器任務都建立 Service。以下是實務上常見場景判斷：
| 應用情境 | 建議 |
|---|---|
| 🗂️ 一次性任務（資料備份、檔案轉換、報表生成） | ❌ 不需要 ECS Service，只需要執行一次性的 Task 即可（如 run-task） |
| ⏰ 定時任務（每天凌晨 1 點執行、排程任務） | ❌ 不需要 ECS Service，建議使用 Scheduled Task（透過 CloudWatch Events / EventBridge） |
| 🌐 持續提供 API 的伺服器 | ✅ 非常適合 ECS Service，可持續監控與自動重啟 |
| 📊 長時間監控程式（如 IoT 資料收集） | ✅ 適合使用 ECS Service 確保不中斷 |
| 👥 多容器服務，須整合 ALB 對外供應流量 | ✅ 建議使用 Service + Load Balancer 架構 |
結語：Service 是 ECS 長期運營的基礎
如果說 Task 是短跑選手，Service 就是馬拉松選手的教練——負責監控狀況、調整策略、確保不中斷地跑下去。
對於需要穩定、可用性高、可自動擴縮的服務型應用，ECS Service 是你不可或缺的武器。