Amazon ECS (Elastic Container Service) là dịch vụ quản lý container của AWS, cho phép bạn chạy ứng dụng Docker trên hạ tầng AWS mà không phải tự dựng toàn bộ hệ thống orchestration. ECS có hai launch type phổ biến:

• Fargate – serverless, không cần quản lý hạ tầng.

• EC2 – tự quản lý hạ tầng bằng các EC2 instance.

Trong bài này, chúng ta sẽ đi sâu vào ECS EC2 launch type: cách hoạt động, khi nào nên dùng, và từng bước triển khai.

1. ECS với EC2 launch type là gì?

Với EC2 launch type, bạn sẽ chạy các container trên chính các EC2 instance mà bạn quản lý. ECS chỉ đóng vai trò orchestrator (lên lịch, quản lý task, health check), còn tài nguyên compute (CPU/RAM) đến từ EC2.

🔑 Các thành phần chính:

• ECR (Elastic Container Registry): nơi lưu trữ image của bạn.

• ECS Cluster: tập hợp các tài nguyên compute (EC2 hoặc ASG) để ECS đặt container.

• ECS Agent: chạy trên mỗi EC2, giao tiếp với ECS control plane.

• Task Definition: định nghĩa container, tài nguyên, image, biến môi trường…

• Service: đảm bảo số lượng task luôn chạy theo mong muốn, tích hợp với load balancer.

2. Khi nào chọn ECS EC2 thay vì Fargate?

• Chi phí rẻ hơn nếu workload chạy liên tục: với Fargate, bạn trả tiền theo giây cho container, trong khi EC2 thì tính giờ (có thể rẻ hơn nếu sử dụng liên tục).

• Tận dụng Spot Instance: chạy workload không quá quan trọng với chi phí giảm tới 90%.

• Toàn quyền kiểm soát môi trường: bạn có thể SSH vào EC2, cài đặt thêm phần mềm, giám sát bằng agent tùy chỉnh.

• Ứng dụng cần kernel module hoặc driver đặc biệt (ví dụ GPU, low-level networking).

• Muốn gộp nhiều container nhỏ vào cùng một máy để tận dụng tối đa tài nguyên.

3. Chi phí khi dùng ECS EC2

Bạn không trả tiền cho ECS control plane, chỉ trả cho các dịch vụ đi kèm:

• EC2 instance (On-demand, Spot, Reserved Instance).

• EBS volumes gắn vào EC2.

• ECR (lưu trữ image, data transfer).

• ELB (ALB/NLB) nếu cần expose ra ngoài.

• CloudWatch Logs/Metrics nếu bạn bật logging/monitoring.

• Data transfer nếu có traffic ra internet hoặc cross-AZ.

4. Các bước triển khai ECS với EC2 launch type

Bước 1: Chuẩn bị ECR

• Build và push image Docker vào ECR:

  aws ecr create-repository --repository-name my-app
  docker build -t my-app .
  docker tag my-app:latest <account-id>.dkr.ecr.<region>.amazonaws.com/my-app:latest
  docker push <account-id>.dkr.ecr.<region>.amazonaws.com/my-app:latest​

Bước 2: Tạo ECS Cluster

• Chọn EC2 instances hoặc Networking only (nếu muốn gắn EC2 riêng).

• ECS sẽ yêu cầu bạn định nghĩa Auto Scaling Group (ASG) hoặc bạn tự tạo EC2 và cài ECS Agent.

👉 Nếu dùng ECS-Optimized AMI (Amazon Linux 2 hoặc Amazon Linux 2023 for ECS) thì Docker + ECS Agent đã được cài sẵn.
👉 Nếu dùng EC2 tự tạo, bạn phải config thêm:

echo "ECS_CLUSTER=my-cluster" | sudo tee -a /etc/ecs/ecs.config
sudo systemctl restart ecs

Bước 3: Tạo Task Definition

Ví dụ:

• CPU: 0.5 vCPU

• Memory: 512 MB

• Image: <account-id>.dkr.ecr.<region>.amazonaws.com/my-app:latest

• Network mode: awsvpc

• Log driver: awslogs

Lưu ý: ECS dùng thông tin CPU/RAM trong Task Definition để schedule container vào EC2 host phù hợp.

Bước 4: Tạo Service

• ECS Service đảm bảo số lượng task luôn chạy (ví dụ 2 task).

• Có thể gắn với ALB/NLB để expose HTTP/HTTPS.

• Có thể bật Auto Scaling cho service (tăng/giảm số task theo CPU/Mem).

Bước 5: Kiểm tra

• ECS Console → Cluster → Tasks.

• CloudWatch Logs để xem log container.

• ALB DNS hoặc EC2 IP để test ứng dụng.

5. Ví dụ: Triển khai Celery Beat và Celery Worker

• Celery Beat: rất nhẹ, chỉ cần 0.25 vCPU + 256 MB RAM.

• Celery Worker: nặng hơn, tuỳ workload, có thể cần 1 vCPU + 1–2 GB RAM cho mỗi worker.

• ECS cho phép bạn tách riêng Beat và Worker thành 2 task definition khác nhau, dễ scale worker mà không ảnh hưởng đến Beat.

6. Ưu nhược điểm của ECS EC2

✅ Ưu điểm

• Rẻ hơn Fargate nếu workload liên tục.

• Tận dụng Spot Instance.

• Kiểm soát cao, tuỳ biến OS, monitoring.

• Chạy được workload đặc thù (GPU, custom kernel).

❌ Nhược điểm

• Phải quản lý EC2 (patching, scaling, AMI update).

• Phức tạp hơn Fargate (capacity planning, scaling policy).

• Không “serverless”, bạn phải lo HA (Auto Scaling Group, Multi-AZ).

7. Kết luận

ECS EC2 launch type rất phù hợp khi:

• Bạn có workload chạy liên tục, dài hạn (giảm chi phí).

• Cần custom môi trường hoặc tận dụng Spot Instance.

• Muốn tối đa hiệu suất trên một EC2 (nhồi nhiều container).

Nếu bạn muốn nhanh – gọn – không quản lý hạ tầng thì Fargate vẫn là lựa chọn tốt.
Còn nếu bạn cần linh hoạt, tiết kiệm và kiểm soát thì ECS EC2 chính là lựa chọn sáng suốt. 🚀

Tại sao phải định nghĩa CPU và RAM cho Task ECS (EC2 type)?

Khi bạn chạy container trực tiếp trên EC2 instance, có thể bạn sẽ nghĩ rằng chỉ cần quan tâm đến cấu hình của EC2 (ví dụ: 2 vCPU, 4GB RAM). Tuy nhiên ECS vẫn bắt bạn định nghĩa Task size (CPU & Memory) khi tạo Task Definition.

Lý do chính là vì:

1. Quản lý tài nguyên container-level

   • ECS cần biết mỗi Task sẽ “ăn” bao nhiêu CPU/RAM để có thể sắp xếp (schedule) chúng lên EC2 instance phù hợp.

   • Nếu không khai báo, ECS không thể quyết định Task có vừa với tài nguyên còn trống của instance hay không.

2. Isolation (tách biệt tài nguyên)

   • Mỗi Task chạy dưới dạng container trong Docker.

   • Khi bạn set CPU = 512 (0.5 vCPU) và Memory = 1GB, ECS sẽ dùng cơ chế cgroup của Linux để giới hạn container đó, tránh việc một Task chiếm toàn bộ CPU/RAM của instance.

3. Scaling hợp lý

   • ECS scheduler sẽ tính toán tài nguyên còn lại trên từng EC2 instance.

   • Ví dụ: nếu EC2 có 2 vCPU, 4GB RAM

     • Task A = 1 vCPU, 2GB RAM

     • Task B = 1 vCPU, 2GB RAM
       → ECS sẽ biết rằng instance này chỉ chứa tối đa 2 Task kiểu đó, và khi quá tải thì sẽ yêu cầu Auto Scaling group bật thêm EC2 mới.

Cách chọn CPU & RAM chính xác cho Task

1. Hiểu workload của bạn

   • Ví dụ:

     • Celery Beat: rất nhẹ, chỉ cần lịch và trigger → có thể set 0.25 vCPU, 512MB RAM.

     • Celery Worker: nặng hơn (tùy job), thường cần từ 0.5–1 vCPU, 1–2GB RAM.

     • Django API: thường 1 vCPU, 1–2GB RAM là ổn cho web request trung bình.

2. Nguyên tắc 80/20

   • Đừng gán toàn bộ tài nguyên của EC2 cho một Task. Luôn để lại một phần nhỏ cho OS + ECS Agent + Docker Daemon (~10–15%).

3. Test & Monitor

   • Dùng CloudWatch metrics (CPUUtilization, MemoryUtilization) để theo dõi.

   • Nếu thấy Task thường xuyên xài ~80% CPU hoặc RAM → nâng cấp Task size.

   • Nếu thấy chỉ dùng <30% → có thể giảm xuống để tiết kiệm tài nguyên, tăng mật độ Task trên mỗi EC2.

👉 Ví dụ thực tế:

• Bạn có EC2 t3.medium (2 vCPU, 4GB RAM).

• Bạn muốn chạy:

  • 1 container Django API (1 vCPU, 2GB RAM)

  • 1 container Celery Worker (0.5 vCPU, 1GB RAM)

  • 1 container Celery Beat (0.25 vCPU, 512MB RAM)

• Tổng cộng ~1.75 vCPU + 3.5GB RAM → vẫn vừa vặn, còn dư cho ECS Agent.