AWS EKS vs ECS: Kiến trúc, Chi phí & Thực tế Sử dụng (2026)

TL;DR: EKS cung cấp cho bạn toàn bộ sức mạnh của Kubernetes, khả năng di động và hệ sinh thái CNCF. ECS mang lại sự đơn giản thuần túy của AWS với chi phí control plane bằng $0. Hãy chọn EKS nếu bạn cần GitOps, ArgoCD, Dapr, hoặc muốn không bị khóa chặt vào một cloud (multi-cloud). Chọn ECS nếu bạn muốn đưa sản phẩm ra thị trường nhanh nhất trên AWS với gánh nặng vận hành tối thiểu.

Tôi đã vận hành cả hai hệ thống này trên môi trường production. Tại Vigo Retail, tôi đã thiết kế kiến trúc nền tảng 21 microservices viết bằng Go trên EKS, xử lý đỉnh điểm 8.000 RPS và hơn 25 triệu request/tháng. Tôi cũng đã quản lý các cluster ECS cho những dự án nhỏ gọn thuần AWS. Bài viết này chính là tài liệu tôi ước mình có trước khi đưa ra những quyết định kiến trúc đó.

1. TL;DR — Bảng Quyết Định Nhanh

Answer-first: Nếu bạn cần hệ sinh thái CNCF (ArgoCD, Dapr, Helm, Istio), hãy chọn EKS. Nếu bạn cần con đường nhanh nhất để đưa sản phẩm lên AWS với gánh nặng vận hành (ops) thấp nhất, hãy chọn ECS.

2. ECS và EKS là gì? Kiến trúc Lõi

Answer-first: ECS là bộ điều phối container độc quyền của AWS — không dính líu gì tới Kubernetes. EKS là Kubernetes được quản lý bởi AWS — tương thích 100% với kubectl, Helm và toàn bộ hệ sinh thái CNCF.

2.1 Amazon ECS — Điều phối Container Thuần AWS

ECS ra mắt vào năm 2014 trước cả khi Kubernetes tồn tại. AWS thiết kế nó với định hướng cụ thể và sự đơn giản làm trọng tâm.

Các thành phần cốt lõi rất dễ hiểu:

• Task Definition — “công thức” của bạn: container images, CPU, memory, biến môi trường, IAM role, network mode.
• Service — chạy N bản sao của một Task, tích hợp với ALB, xử lý rolling updates.
• Cluster — ranh giới logic; map với một VPC + sức mạnh EC2/Fargate.

Không có phí control plane. AWS quản lý lớp điều phối này hoàn toàn. Bạn chỉ trả tiền cho những gì bạn chạy.

graph TD
    subgraph "Kiến trúc ECS"
        TD["Task Definition\n(images, CPU, memory, IAM role)"]
        SVC["ECS Service\n(số lượng mong muốn, auto-scaling)"]
        CLU["ECS Cluster\n(EC2 hoặc Fargate)"]
        ALB["Application Load Balancer"]
        CW["CloudWatch\n(metrics, logs)"]

        TD --> SVC
        SVC --> CLU
        ALB --> SVC
        SVC --> CW
    end

Giới hạn chết người mà nhiều người bỏ qua: ECS Task Definitions có giới hạn cứng là 10 container mỗi task. Nếu bạn sử dụng các pattern nặng về sidecar (app + Dapr + Envoy + log agent + metrics agent), bạn sẽ chạm ngưỡng này rất nhanh.

2.2 Amazon EKS — Kubernetes do AWS Quản Lý

EKS cung cấp cho bạn một control plane Kubernetes được quản lý hoàn toàn (API server, etcd, scheduler, controllers) — bạn tự quản lý các worker node (hoặc dùng Fargate/Auto Mode).

graph TD
    subgraph "Kiến trúc EKS"
        CP["EKS Control Plane\n(AWS quản lý: API server, etcd)\n$0.10/giờ = $73/tháng"]
        NG["Node Group\n(EC2 hoặc Fargate)"]
        POD["Pods\n(container của bạn)"]
        HELM["Helm / Kustomize"]
        ARGO["ArgoCD\n(GitOps controller)"]
        KARP["Karpenter\n(node autoscaler)"]
        ALB2["AWS Load Balancer Controller\n(ALB/NLB via annotations)"]

        CP --> NG
        NG --> POD
        ARGO --> CP
        HELM --> CP
        KARP --> NG
        ALB2 --> CP
    end

Mọi công cụ Kubernetes mà bạn từng nghe tới đều hoạt động ở đây: Helm, ArgoCD, Argo Rollouts, Dapr, Karpenter, KEDA, Istio, Linkerd, Prometheus, Grafana, OpenTelemetry Operator.

2.3 So Sánh Kiến Trúc: Control Plane, Data Plane

3. Bài Toán Chi Phí Thực Tế — Không Lý Thuyết Suông

Answer-first: ECS rẻ hơn ở tầng control plane — $0 so với $73/tháng của EKS. Nhưng nói “EKS đắt hơn” là một sự đơn giản hóa quá mức. Chi phí compute (tính toán) là như nhau; khoảng cách thực sự nằm ở phí control plane, nhân sự ops và chi phí hạ tầng ngầm.

3.1 Phí Control Plane: ECS $0 vs EKS $73/tháng

Đây là lợi thế tài chính rõ ràng duy nhất mà ECS có so với EKS ở tầng điều khiển:

Cái bẫy Extended Support: EKS Extended Support ($0.60/giờ) sẽ tự động kích hoạt khi bạn chạy một phiên bản Kubernetes đã quá 14 tháng kể từ ngày phát hành upstream. Điều này có hiệu lực từ tháng 4/2024. Các team lười nâng cấp K8s sẽ âm thầm chịu mức giá đắt gấp 6 lần. Với 3 cluster, con số này là $15,768/năm riêng tiền phí Control plane — chưa tính tới compute.

3.2 Phí Compute: EC2 vs Fargate

Cả ECS và EKS đều chạy trên phần cứng giống hệt nhau. Giá EC2 và Fargate là không đổi bất kể bạn dùng bộ điều phối nào:

Giá Fargate (US-East-1):

• vCPU: $0.04048/giờ mỗi vCPU
• Memory: $0.004445/giờ mỗi GB

Giới hạn của Fargate (Chỉ áp dụng với ECS): ECS Fargate ép bạn phải sử dụng các tổ hợp CPU/memory định sẵn (0.25, 0.5, 1, 2, 4, 8, 16, 32 vCPU — danh sách cố định). Bạn không thể yêu cầu 1.5 vCPU. Điều này buộc bạn phải over-provision (cấp phát thừa) lên bậc tiếp theo.

Các tùy chọn tối ưu chi phí (cả ECS và EKS):

• Compute Savings Plans: Tiết kiệm tới 66% cho EC2 và Fargate. (Lưu ý: Phí Control plane KHÔNG được cover).
• Spot Instances: ECS Spot thông qua capacity providers; EKS Spot thông qua Karpenter (chọn multi-pool thông minh).
• Graviton ARM: Giá cơ bản rẻ hơn ~20%, hiệu năng giá (price-performance) tốt hơn tới 40%. ECS: set cpuArchitecture: ARM64 trong Task Definition. EKS: Karpenter tự động chọn Graviton. Go biên dịch sang ARM mà không cần sửa code — GOARCH=arm64 GOOS=linux go build.
• Fargate Spot + Graviton: Tiết kiệm tới 76% chi phí so với giá on-demand x86.

3.3 Chi Phí Ngầm: NAT Gateway, ALB, Nhân Sự

Những chi phí này xuất hiện ở cả ECS và EKS, nhưng EKS có thể làm chúng phình to:

3.4 Ví dụ Chi Phí Thực Tế (10 Services, ap-southeast-1)

Đây là ước tính minh họa. Chi phí thực tế thay đổi theo traffic, region, và độ hiệu quả của workload.

4. Hiệu Năng & Khả năng Mở rộng (Scalability)

Answer-first: ECS và EKS có throughput và độ trễ raw là giống hệt nhau — cả hai đều dùng mạng VPC gốc qua ENI (không overlay). Sự khác biệt nằm ở tốc độ chúng scale ra và hiệu quả khi chúng sắp xếp workload (bin-packing).

4.1 Tốc độ Khởi động & Scale-Out

Đây là nơi EKS (kèm Karpenter) đánh bại ECS một cách thuyết phục cho các workload tăng vọt bất ngờ (bursty):

Tại sao điều này quan trọng ở mức 8.000 RPS: Tại Vigo Retail, traffic tăng vọt trong các đợt khuyến mãi đạt 8.000 RPS chỉ trong vài phút. Việc chờ 3 phút để có node mới sẽ dẫn trực tiếp đến hàng đợi request, độ trễ p99 tồi tệ, và rớt request (lỗi 5xx). Thời gian cấp phát 45 giây của Karpenter giúp chúng tôi giữ vững SLA trong mọi đợt burst.

Pod-level autoscaling (Quy mô ứng dụng):

KEDA là “siêu năng lực” của EKS cho background workers. Các consumer đọc SQS viết bằng Go có thể scale về 0 trong giờ thấp điểm và bật dậy khi hàng đợi đầy — mà không cần xây dựng các luồng metric CloudWatch phức tạp.

4.2 Networking: VPC CNI vs ECS awsvpc

Cả ECS (awsvpc mode) và EKS (VPC CNI) đều gán địa chỉ IP thực tế của VPC trực tiếp cho các container. Không NAT ảo, không overlay. Độ trễ tương đương với việc chạy thẳng trên EC2.

Lợi thế Prefix Delegation của EKS ở quy mô lớn: Nó cấp phát các block IPv4 /28 (16 IP) cho mỗi ENI. Điều này giảm đáng kể các cuộc gọi EC2 API trong quá trình scale-out pod — cực kỳ quan trọng đối với các cluster lớn đang scale thần tốc bằng Karpenter.

5. Thực Tiễn — Khi Nào Chọn ECS, Khi Nào Chọn EKS

Answer-first: Nếu bạn đang hỏi khi nào dùng EKS, khi nào dùng ECS — câu trả lời đơn giản hơn những bài so sánh lý thuyết. ECS là lựa chọn đúng đắn cho Startups và các hệ thống thuần AWS cần tốc độ ra mắt nhanh. EKS là lựa chọn đúng đắn cho các team cần GitOps, event-driven autoscaling, hoặc các công cụ hệ sinh thái CNCF.

5.1 Startup (Tốc độ & Đơn giản) → ECS Fargate

ECS Fargate là con đường nhanh nhất từ code lên production trên AWS.

ECS chiến thắng khi:

• Team của bạn không có kinh nghiệm Kubernetes.
• Bạn cần ship code trong vài ngày, thay vì vài tuần.
• Kiến trúc của bạn là các dịch vụ HTTP/gRPC tiêu chuẩn đứng sau ALB.
• Bạn hoàn toàn trung thành với hệ sinh thái AWS (CloudWatch, CodeDeploy, IAM).
• Bạn có từ 1–3 kỹ sư backend.

Timeline setup ECS Fargate thực tế:

1. Định nghĩa Task Definition (Terraform aws_ecs_task_definition) — 30 phút.
2. Tạo ECS Service với ALB target group — 20 phút.
3. Cấu hình Application Auto Scaling — 15 phút.
4. Tổng cộng: ~65 phút để lên production.

So sánh với EKS: Tạo cluster + cấu hình VPC CNI + ALB Controller (Helm) + Tối ưu CoreDNS + IRSA/Pod Identity + Karpenter NodePool + Cài đặt ArgoCD. Thực tế cần 4–8 giờ cho một cluster đủ chuẩn production.

5.2 Enterprise (Quy mô, Hệ sinh thái CNCF) → EKS

EKS là lựa chọn số một khi tổ chức của bạn cần sức mạnh của hệ sinh thái Kubernetes.

EKS chiến thắng khi:

• Bạn cần ArgoCD cho GitOps — ArgoCD chỉ dành cho Kubernetes. Nó không thể deploy lên ECS.
• Bạn chạy Dapr — trên ECS, Dapr yêu cầu tiêm (inject) sidecar thủ công trong từng Task Definition. Trên EKS, Dapr operator tự động làm việc này cho 21 service.
• Bạn cần KEDA để tự động scale theo sự kiện (event-driven) — ECS không có thứ tương đương.
• Bạn cần multi-tenancy ở quy mô lớn — EKS hỗ trợ cô lập qua Namespace + RBAC + NetworkPolicy; ECS không có khái niệm namespace.
• Bạn cần sự di động đa đám mây (multi-cloud).

Theo Khảo sát thường niên CNCF 2024, 93% tổ chức đang sử dụng, đánh giá hoặc thử nghiệm Kubernetes. 92% thị trường điều phối container đang chạy trên Kubernetes. Việc chọn ECS vào năm 2025 là một sự đánh đổi có chủ ý, sáng suốt — chứ không phải do thiếu nhận thức.

5.3 Go Microservices trên EKS — Trải Nghiệm Thực Tế

Tại Vigo Retail, tôi đã lãnh đạo kiến trúc cho một nền tảng 21 microservices viết bằng Go trên EKS tại ap-southeast-1. Hệ thống này xử lý backend thương mại điện tử cho các hoạt động tại Việt Nam của tập đoàn Hàn Quốc này, đạt đỉnh ở mức 8.000 RPS và hơn 25 triệu lượt request/tháng.

Stack sử dụng:

• 21 Go services (quản lý đơn hàng, kho, loyalty, thanh toán, thông báo…)
• EKS chạy trên EC2 (các node m6i + m6g Graviton2 — kiến trúc hỗn hợp)
• ArgoCD với pattern App-of-Apps
• Dapr cho pub/sub, state store, service invocation
• Karpenter để autoscaling node
• AWS Load Balancer Controller (ALB cho API ngoài, NLB cho gRPC nội bộ)
• ADOT + AWS X-Ray cho distributed tracing

Bài học 1 — Graviton Spot cho các Go service phi trạng thái Chúng tôi đã chạy toàn bộ Go services phi trạng thái (stateless) trên các instance Graviton Spot. Code thuần Go có thể compile thẳng ra ARM64 mà không cần đổi một dòng code nào:

# Build đa kiến trúc (multi-arch) — chạy tốt trên cả ECS và EKS
FROM --platform=$BUILDPLATFORM golang:1.23-alpine AS builder
ARG TARGETOS TARGETARCH
RUN GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app ./cmd/server

Kết quả: giảm ~35% chi phí compute cho các luồng tăng tải đột biến.

Bẫy scaling của IRSA: Công nghệ IRSA cũ yêu cầu một OIDC provider duy nhất cho mỗi EKS cluster. Các tài khoản AWS có giới hạn 100 OIDC provider. Các team chạy nhiều cluster sẽ đâm sầm vào bức tường này. EKS Pod Identity (EKS 1.24+) không phụ thuộc vào cluster — cùng một IAM role sẽ hoạt động trên tất cả các cluster mà không cần cập nhật trust policy.

10. Vendor Lock-in & Sự Di Động

Answer-first: ECS là một sản phẩm độc quyền của AWS không có đường lui sang cloud khác. Workload trên EKS sử dụng YAML manifests tiêu chuẩn của Kubernetes — dễ dàng mang sang GKE, AKS, hoặc bất kỳ cụm tự quản lý nào với rào cản tối thiểu.

EKS Hybrid Nodes (GA từ re:Invent tháng 12/2024): Control plane trên mây do AWS quản lý + worker nodes chạy on-prem. EKS Hybrid Nodes gateway (GA tháng 4/2026) tự động hóa định tuyến pod-to-pod giữa cloud và on-prem — loại bỏ việc cấu hình BGP/routing thủ công. Với các công ty có yêu cầu on-premises, đây giờ là giải pháp tốt nhất so với EKS Anywhere.

11. Khung Quyết Định Cuối Cùng

Answer-first: Hãy bắt đầu với các ràng buộc của bạn (chuyên môn của team, nhu cầu hệ sinh thái, ngân sách), chứ không phải bằng cách soi danh sách tính năng.

flowchart TD
    A["Bắt đầu dự án\ncontainer mới?"] --> B{"Cần ArgoCD,\nDapr, hoặc KEDA?"}
    B -- "Có" --> EKS1["→ EKS\n(cần hệ sinh thái CNCF)"]
    B -- "Không" --> C{"Team có chuyên\nmôn K8s không?"}
    C -- "Không" --> ECS1["→ ECS Fargate\n(nhanh nhất lên production)"]
    C -- "Có" --> D{"Cần Multi-cloud\nhoặc on-prem?"}
    D -- "Có" --> EKS2["→ EKS\n(cần khả năng di động)"]
    D -- "Không" --> E{"Quy mô team\ndự kiến sau 2 năm?"}
    E -- "1–5 kỹ sư" --> ECS2["→ ECS\n(ops overhead thấp)"]
    E -- "5+ hoặc platform team" --> EKS3["→ EKS + Auto Mode\n(đầu tư vào hệ sinh thái)"]

Câu Hỏi Thường Gặp (FAQ)

EKS có tốt hơn ECS không?

Không có cái nào tốt hơn một cách tuyệt đối. EKS mang lại cho bạn hệ sinh thái Kubernetes (ArgoCD, Dapr, KEDA, Helm) với cái giá là độ phức tạp vận hành cao hơn và phí $73/tháng mỗi cluster. ECS mang lại sự đơn giản thuần AWS với phí control plane bằng không. Hãy chọn dựa trên chuyên môn của team và những công cụ hệ sinh thái mà bạn thực sự cần — đừng chọn vì trend.

EKS Auto Mode thực sự làm được gì?

EKS Auto Mode (GA từ re:Invent 2024) tự động hóa cấp phát node thông qua managed Karpenter, vá lỗi OS bằng Bottlerocket, và quản lý các core add-ons (VPC CNI, Load Balancer Controller, EBS CSI). Bạn vẫn phải tự viết Kubernetes manifests và quản lý RBAC, namespace, cùng các application-level tools như ArgoCD và Dapr.

Sự khác nhau giữa ECS Fargate và EKS Fargate là gì?

Tầng compute hoàn toàn giống nhau: cùng mức giá Fargate ($0.04048/vCPU-giờ, $0.004445/GB-giờ tại US-East-1). Sự khác biệt nằm ở tầng điều phối (orchestration layer): ECS Fargate không tốn phí control plane và không dùng Kubernetes API. EKS Fargate tốn $73/tháng cho control plane nhưng đổi lại bạn có đầy đủ Kubernetes APIs, Helm, và toàn bộ tooling CNCF.

Chi phí thực sự của EKS là bao nhiêu?

Tối thiểu: $73/tháng (control plane) + compute. Nếu bạn chậm trễ trong việc nâng cấp phiên bản Kubernetes, phí Extended Support sẽ đá bạn một cú $438/tháng mỗi cluster (~gấp 6 lần). Với 3 cụm rơi vào Extended Support, bạn mất trắng $15,768/năm tiền phí quản lý — trước khi chạy bất kỳ một container nào. Extended Support đã có hiệu lực từ tháng 4/2024.

Có thể dùng ArgoCD với ECS không?

Không. ArgoCD là công cụ thuần Kubernetes — nó đồng bộ các resource Kubernetes với trạng thái trong Git. ECS không có resource K8s. Các team triển khai ECS theo phong cách GitOps thường sử dụng GitHub Actions + ecspresso hoặc AWS CodePipeline + CodeDeploy.

Startup nên chọn ECS hay EKS?

ECS Fargate cho 12–18 tháng đầu. Không tốn phí control plane, đưa sản phẩm lên production nhanh, gánh nặng vận hành tối thiểu. Khi bạn cần ArgoCD, Dapr, hoặc KEDA — hoặc khi bạn tuyển được một platform engineer — hãy đánh giá lại EKS. Migration từ ECS sang EKS không nhỏ (chuyển đổi Task Definition → K8s manifest, cấu trúc lại IAM, rebuild pipeline) nhưng hoàn toàn khả thi với chiến lược chuyển traffic theo giai đoạn qua ALB weighted target groups.

Mất bao lâu để migrate từ ECS sang EKS?

Cho một hệ thống 10 service: Hãy chuẩn bị 4–8 tuần-kỹ-sư. Các công việc chính: Chuyển đổi Task Definition sang K8s Deployment/Service manifests (không có tool tự động hóa), đổi IAM Task Roles sang EKS Pod Identity, ECS service discovery sang K8s Services + Ingress, CloudWatch sang Prometheus/ADOT, và rebuild pipeline CI/CD. AWS không cung cấp migration path tự động.

EKS Extended Support là gì và khi nào thì áp dụng?

EKS Extended Support tốn $0.60/giờ/cluster (~$438/tháng). Nó áp dụng khi cluster của bạn chạy phiên bản Kubernetes đã vượt qua cửa sổ hỗ trợ tiêu chuẩn 14 tháng. Điều này có hiệu lực từ tháng 4/2024. Các team chạy K8s phiên bản cũ phải trả gấp 6 lần phí thông thường — thường không hay biết cho đến khi nhận hóa đơn AWS.

Lời Kết

Việc lựa chọn giữa EKS và ECS suy cho cùng xoay quanh hai câu hỏi: Team của bạn cần công cụ hệ sinh thái nào? và Team của bạn có thể hấp thụ bao nhiêu sự phức tạp của Kubernetes?

Nếu bạn không cần ArgoCD, Dapr, KEDA, hay Kubernetes Network Policies — và bạn đã cam kết với hệ sinh thái AWS — ECS là lựa chọn thực dụng và trung thực. Nó không phải là lựa chọn “kém cỏi hơn”. Đây là một sự đánh đổi có chủ ý giúp giữ cho ops overhead ở mức tối thiểu và team của bạn tập trung vào phát triển sản phẩm.

Nếu bạn đang xây dựng một nền tảng cần GitOps, autoscaling theo sự kiện (event-driven), cách ly mạng ở cấp độ pod, hay khả năng di động đa đám mây (multi-cloud) — EKS là nền tảng phù hợp. EKS Auto Mode đã hạ thấp rào cản vận hành một cách đáng kể vào năm 2025. Nhưng chuyên môn về Kubernetes vẫn là tấm vé vào cửa bắt buộc.

Tại Vigo Retail, EKS là một quyết định đúng đắn. Hệ sinh thái CNCF — ArgoCD + Dapr + Karpenter — mang lại cho chúng tôi những khả năng mà ECS không thể sánh kịp. Nhưng tôi cũng từng chứng kiến các team chọn EKS chỉ vì “ai cũng dùng Kubernetes”, để rồi dành 3 tháng đánh vật với platform thay vì phát triển tính năng cho sản phẩm.

Hãy chọn công cụ phù hợp với team của bạn, đừng chọn theo trào lưu.

Lê Tuấn Anh là một Go Backend Architect với hơn 17 năm kinh nghiệm. Anh đã dẫn dắt kiến trúc EKS cho nền tảng 21 microservices viết bằng Go tại Vigo Retail, xử lý đỉnh tải 8.000 RPS. Anh cũng viết về GitOps ở Quy mô Lớn với ArgoCD, Kubernetes In-Place Pod Resizing, và Điều phối Dapr Workflow Saga.

Từ Tech Radar: Tech Radar ngày 13/05/2026 đã đưa ra tín hiệu về AgentOps gặp Kubernetes — sáng kiến của Signadot về việc chạy kiểm thử AI agent bên trong các sandbox Kubernetes trực tiếp. Với các team chọn EKS cụ thể để chạy agentic workloads, đây là tín hiệu gần đây nhất về hướng hội tụ K8s + AI trong môi trường vận hành thực tế.