Amazon ECS: Chạy container trên AWS — không cần Kubernetes

Hiểu ECS qua lăng kính thực tế: khi nào dùng, dùng thế nào, và tại sao nó vẫn là lựa chọn thông minh trong năm 2025

1. Tại sao lại cần ECS?

Bạn đã đóng gói ứng dụng vào Docker container. Giờ bạn muốn chạy nó trên cloud — nhưng không muốn tự quản lý máy chủ, cập nhật Docker daemon, hay lo về scaling.

Đây là lúc bạn cần một dịch vụ container orchestration .

Nhiều người nghĩ ngay đến Kubernetes (EKS). Nhưng nếu hệ thống của bạn chưa cần độ phức tạp đó, **Amazon ECS** — dịch vụ quản lý container “native” của AWS — có thể là lựa chọn **đơn giản, nhanh và đủ mạnh**.

ECS do AWS xây dựng, tích hợp sâu với IAM, VPC, ALB, CloudWatch… và **không tính phí cho control plane** — bạn chỉ trả tiền cho tài nguyên (EC2 hoặc Fargate).

2. Các khái niệm cốt lõi — hiểu để không bị lạc

2.1. Task và Task Definition

- Task Definition: Là “công thức” để chạy container — tương đương Dockerfile + docker-compose.yml nhưng ở mức AWS.
Trong đó bạn khai báo:
  • Ảnh container (ECR hoặc Docker Hub)
  • CPU/RAM
  • Biến môi trường, port, volume, IAM role…

- **Task**: Là **một lần chạy thực tế** của task definition. Ví dụ: bạn chạy 1 task → có 1 container đang chạy.

2.2. Service

Service đảm bảo **luôn có N task đang chạy**. Nếu task crash, service tự khởi động lại. Nếu bạn scale lên 5, service tạo thêm 4 task mới.

Service thường gắn với **Application Load Balancer (ALB)** để phân phối traffic.

2.3. Cluster

Cluster là **logic grouping** — nơi bạn gom các task/service lại. Cluster không phải là tài nguyên vật lý, mà là “vùng chứa”.

Một cluster có thể chạy trên:

• EC2 Launch Type: Bạn quản lý máy chủ (EC2), ECS chỉ điều phối container trên đó.
• Fargate Launch Type: AWS quản lý máy chủ — bạn chỉ quan tâm đến container. Trả tiền theo CPU/RAM tiêu thụ.

3. Mạng và luồng dữ liệu trong ECS

Khi dùng ECS trong VPC (bắt buộc trong production), bạn cần hiểu:

• Mỗi task có **IP riêng** trong subnet bạn chọn.
• Với **Fargate**, task luôn chạy trong **private subnet** — không có public IP.
• Để truy cập internet (pull image, gọi API), private subnet phải có **NAT Gateway**.
• Để client truy cập ứng dụng, bạn cần **ALB trong public subnet** → forward traffic vào task trong private subnet.

→ Đây là mô hình **bảo mật chuẩn**: container ẩn sau ALB, không tiếp xúc trực tiếp internet.

4. Bảo mật: IAM cho container

Một trong những lợi thế lớn của ECS so với Kubernetes: **tích hợp IAM ở mức task**.

Bạn có thể gán **IAM role trực tiếp cho task** — container trong task sẽ có quyền đó (qua AWS SDK).

Ví dụ: task cần ghi log vào S3 → gán role có quyền s3:PutObject → **không cần lưu access key trong container**.

→ Đây là best practice bảo mật, và ECS hỗ trợ “out of the box”.

5. Ví dụ thực tế: Deploy ứng dụng web với Fargate

Giả sử bạn có ứng dụng Node.js trong Docker image, muốn deploy trên AWS mà không quản lý server.

Bước 1: Tạo task definition (file JSON hoặc qua console):

{
  "family": "web-app-task",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::...:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::...:role/app-s3-role",
  "containerDefinitions": [{
    "name": "web",
    "image": "123456789.dkr.ecr.ap-southeast-1.amazonaws.com/my-app:latest",
    "portMappings": [{ "containerPort": 3000 }],
    "environment": [{ "name": "NODE_ENV", "value": "production" }]
  }]
}

Bước 2: Tạo cluster (chọn Fargate).

Bước 3: Tạo service → chọn cluster, task definition, số task = 2, gán ALB.

Bước 4: Truy cập URL của ALB → ứng dụng chạy!

Toàn bộ quá trình có thể tự động hóa bằng **Terraform hoặc AWS Copilot CLI**.

6. Khi nào nên dùng ECS?

ECS phù hợp nếu bạn:

• Muốn chạy container **nhanh, đơn giản**, không cần học Kubernetes.
• Đã dùng nhiều dịch vụ AWS (IAM, VPC, ALB) và muốn **tích hợp liền mạch**.
• Ưu tiên **bảo mật và compliance** (IAM per task, network isolation).
• Cần **serverless container** (Fargate) để tránh quản lý hạ tầng.

Không dùng ECS nếu bạn:

• Cần di chuyển workload giữa cloud (multi-cloud) → hãy dùng Kubernetes (EKS).
• Đã có đội ngũ thành thạo Kubernetes và cần tính năng nâng cao (custom controller, operator…).

7. Kết luận

Amazon ECS không “kém” Kubernetes — nó **khác**. Trong khi Kubernetes là công cụ mở, linh hoạt nhưng phức tạp, thì ECS là giải pháp **tập trung, tối ưu cho hệ sinh thái AWS**, và đặc biệt thân thiện với team nhỏ hoặc startup.

Năm 2025, với Fargate, integration sâu và chi phí minh bạch, ECS vẫn là lựa chọn **thông minh, thực dụng và an toàn** cho hàng triệu workload trên toàn cầu.

Đừng chạy theo xu hướng — hãy chọn công cụ phù hợp với **bài toán của bạn**.