Lambda, ECS Fargate, EKS và EC2: So sánh toàn diện để chọn đúng Compute Service trên AWS
Phong NguyễnChọn nhanh trong 60 giây
Trước khi đi sâu, nếu bạn đang bận và cần câu trả lời ngay:
- Traffic bursty (không đều, tăng đột biến) / event-driven, task ngắn < 15 phút → Lambda
- Web app / API đơn giản, deploy nhanh → App Runner
- Long-running containerized services, production-grade → ECS Fargate
- Cần Kubernetes native, multi-cloud, service mesh → EKS
- Full OS control, GPU, stateful / legacy app → EC2
- Batch job dài, không cần server thường trực → AWS Batch
Bài viết này sẽ giải thích tại sao đằng sau từng lựa chọn đó.
Bức tranh tổng quan – 6 Compute Options của AWS
AWS cho bạn 6 compute options chính. Nguyên tắc cốt lõi chỉ có một: càng nhiều control thì càng nhiều operational overhead.
| Service | Model | Bạn quản lý | AWS quản lý | Phù hợp nhất |
|---|---|---|---|---|
| EC2 | Virtual Machine | OS, runtime, app, scaling, patching | Physical hardware, hypervisor | Legacy apps, GPU, stateful workloads |
| ECS Fargate | Managed Containers | Container image, task definition, app | OS, container runtime, cluster | Long-running microservices, production APIs |
| EKS | Kubernetes Containers | K8s manifests, app, node groups | Control plane, OS (Fargate nodes) | Multi-cloud, Helm, service mesh, enterprise |
| App Runner | Fully Managed Containers | Container image hoặc source code | Everything except the app | Simple web apps & APIs, lowest overhead |
| Lambda | Serverless Functions | Function code only | Everything except the code | Event-driven, bursty, short-lived tasks |
| AWS Batch | Managed Batch Jobs | Container image, job logic | EC2/Fargate provisioning, scheduling | ML training, ETL, media encoding |
Analogy dễ nhớ
Một cách khác để hiểu sự khác biệt:
- EC2 = Nhân viên full-time: luôn on-clock và ăn lương đủ tháng, dù hôm nay idle không có việc gì làm
- ECS Fargate = Nhân viên hợp đồng có desk sẵn: always ready to work, nhưng toà nhà và infrastructure do AWS lo hết
- Lambda = Freelancer: gọi đến mới bắt đầu tính tiền, done việc tự disappear, không có request thì zero cost
- EKS = Quản lý chuỗi franchise: cực kỳ powerful và flexible, nhưng cần cả experienced ops team mới vận hành smooth được
- AWS Batch = Đội thợ chuyên cho big job: spin up khi có project lớn, xong việc tự terminate, không giữ lại tốn cost
AWS Lambda – Khi nào dùng và khi nào không
Lambda phù hợp khi
Lambda là lựa chọn tự nhiên cho những bài toán sau:
Event-driven workloads là điểm mạnh cốt lõi. Lambda được thiết kế để respond với S3 upload, SQS message, API Gateway request, DynamoDB stream, EventBridge schedule. Mọi trigger đều native.
Traffic bursty hoặc unpredictable. Lambda scale từ 0 đến hàng nghìn concurrent executions tự động. Bạn không trả tiền khi không có request nào.
Zero operational overhead. Không có instances để patch, không có capacity planning, không có health check ngoài IAM và function code của bạn.
Tasks short-lived và stateless. Mỗi invocation hoàn toàn độc lập. Lambda không share memory giữa các invocations.
Lambda KHÔNG phù hợp khi
Đây là những trường hợp Lambda thường bị dùng sai:
Task chạy > 15 phút. Hard limit. Không thể extend. Phải dùng ECS task hoặc AWS Batch.
APIs với strict p99 latency < 100ms. Cold start của Lambda dao động 100ms đến vài giây tùy runtime. Với Java hoặc .NET, con số này còn cao hơn. Provisioned Concurrency giải quyết được nhưng adds fixed cost và erodes Lambda's pricing advantage.
Duy trì cao mức độ đồng thời. Default 1,000 concurrent executions per account/region. Có thể raise, nhưng Lambda per-request billing trở nên đắt hơn containers khi concurrency cao liên tục.
Cần GPU. Lambda không expose GPU instances. Phải dùng EC2 hoặc AWS Batch với EC2 mode.
Cold Start – Hiểu để xử lý đúng
Cold start xảy ra khi function chưa được invoke gần đây. Lambda phải khởi động execution environment từ đầu:
- Download function code
- Initialize runtime (JVM với Java, Node.js runtime, v.v.)
- Load dependencies
- Execute your code Các cách giảm cold start:
- Minimize package size – ít dependencies = khởi động nhanh hơn
- Tăng memory allocation – CPU scale theo memory trong Lambda, init nhanh hơn
- Lambda SnapStart – dành cho Java, Python và .NET functions, reduce startup time đáng kể
- Provisioned Concurrency – pre-warm N instances, loại bỏ cold start nhưng có fixed hourly cost
- Lambda Managed Instances (ra mắt re:Invent 2025) – keeps instances warm cho steady workloads, kết hợp với Compute Savings Plans (1-year: ~17% off)
Note về Lambda Managed Instances: Đây là update lớn nhất của Lambda trong nhiều năm. Với 3-year Savings Plans, cost của Lambda Managed Instances giờ competitive với ECS Fargate – thay đổi hoàn toàn equation cho steady-state workloads.
ECS Fargate – Production Containers Không Cần Kubernetes
ECS Fargate là sweet spot giữa Lambda (quá hạn chế) và EKS (quá phức tạp). Bạn define container image và task definition, Fargate provisions và manages underlying infrastructure. Không cần manage EC2 instances.
Fargate phù hợp khi
Long-running services. Không bị limit 15 phút. Container chạy bao lâu cũng được – hours, days.
APIs với lưu lượng truy cập cao liên tục. Khi traffic đủ lớn (thường > 50–100M req/month), mức phí cố định của Fargate tốt hơn Lambda per-request billing.
Cần stateful in-memory data. Container có thể maintain session, cache data trong memory suốt thời gian nó chạy – không cần external storage cho mọi thứ.
Custom runtime hoặc dependencies. Bất kỳ language hoặc library nào chạy trong Docker container đều chạy được trên Fargate. Lambda chỉ support một số runtime nhất định.
Production microservices cần custom networking, VPC placement, task-level IAM, blue/green deployment.
Thông số kỹ thuật quan trọng
- CPU: 0.25 – 16 vCPU (independent với memory)
- Memory: 0.5 – 120 GiB (independent với CPU)
- Cold start: Cold start: 5 giây đến 2 phút tùy image size (image nhỏ < 200MB thường 5–15s, image lớn có thể 1–2 phút) – giảm bằng Seekable OCI/SOCI (kỹ thuật giúp Fargate không cần download toàn bộ container image trước khi chạy)
- Scaling: ECS scheduler launch up to 500 tasks/minute per service
- Pricing: Per vCPU-second và GB-second, bill ngay khi container running kể cả idle
Fargate vs Lambda – So sánh Performance
| Metric | AWS Fargate | AWS Lambda |
|---|---|---|
| Cold Start | 5s – 2 phút | 100ms – 10s |
| Max Execution Time | Không giới hạn | 15 phút |
| Max Memory | 120 GiB | 10 GiB |
| Max CPU | 16 vCPU | 6 vCPU (proportional) |
| State | Stateful possible (in-memory) | Stateless by design |
| Scaling Time | 1–2 phút cho new containers | Instant (cold start aside) |
| Concurrency Limit | Không giới hạn (cluster capacity) | 1,000 default (raiseable) |
| Cold Start Mitigation | SOCI lazy loading | Provisioned Concurrency, SnapStart |
EKS – Kubernetes Trên AWS: Mạnh Nhưng Đừng Chọn Quá Sớm
EKS là managed Kubernetes control plane. Bạn define workloads bằng K8s manifests và EKS schedules chúng trên nodes. EKS mang lại cluster-level features mà ECS không có – nhưng với độ phức tạp vận hành đáng kể.
Chọn EKS khi – và chỉ khi thực sự cần
Team có Kubernetes expertise thực sự. Không phải "đã đọc về K8s", mà là có người đã vận hành production K8s cluster, hiểu Helm, networking plugins, RBAC.
Multi-cloud portability là hard requirement. K8s manifests portable giữa AWS, GCP, Azure. ECS task definitions thì không.
Cần K8s-native features: Helm charts, custom admission controllers, DaemonSets, StatefulSets, Istio/Linkerd service mesh, GitOps với ArgoCD/FluxCD.
Large enterprise với nhiều teams, cần shared platform với RBAC phức tạp.
Tại sao không nên chọn EKS quá sớm
- Fixed cost $72/tháng cho control plane – expensive cho small workloads
- Setup mất hàng tuần: control plane, node groups, networking plugins, RBAC, security policies
- 5 services không cần EKS. ECS Fargate xử lý được hầu hết container workloads với fraction of complexity
- Kubernetes expertise khan hiếm và expensive – phải tính vào TCO
Nguyên tắc: Migrate lên EKS khi bạn có lý do cụ thể, không phải vì nó "sounds more production-ready" hoặc "more scalable".
EC2 – Full Control Cho Những Trường Hợp Đặc Biệt
EC2 là virtual machine đầy đủ. Bạn control mọi thứ từ OS đến kernel modules. Instance chạy liên tục và bạn trả tiền theo giờ, dù idle hay không.
EC2 là lựa chọn đúng khi
Cần GPU. Lambda và Fargate không expose GPU instances. ML training/inference với GPU (p4d, g5, p5 instances) phải dùng EC2 hoặc AWS Batch với EC2 mode.
Persistent long-lived connections. WebSocket servers, game servers, real-time communication apps giữ connection open hàng giờ. Lambda không thể hold connection giữa các invocations.
Legacy software. Ứng dụng chạy như một process liên tục, đọc/ghi file trực tiếp trên server, hoặc có cấu hình network phức tạp mà container không thể mô phỏng được.
Sustained high-throughput workloads. EC2 Reserved Instances hoặc Savings Plans rẻ hơn 30–60% so với on-demand. Với việc duy trì mức độ đồng thời cao, EC2 tốt hơn Lambda per-request billing rõ ràng.
Full OS-level control. Custom kernel modules, privileged processes, hardware features không available trong containers.
Trade-off phải chấp nhận
EC2 có highest operational overhead trong tất cả options: OS patching, security group configuration, scaling via Auto Scaling Groups, capacity planning. Bạn pay per hour dù traffic thấp hay không.
AWS Batch – Giải Pháp Đúng Cho Batch Workloads
AWS Batch được thiết kế riêng cho công việc tính toán riêng lẻ: jobs run to completion, cần nguồn lực tính toán đáng kể, và không cần persistent server giữa các runs.
Điểm khác biệt so với Lambda và EC2:
- Không có time limit – không có giới hạn như Lambda's 15-minute
- Automatic provisioning – Batch manages EC2 hoặc Fargate fleet, không pay khi không có jobs
- Job queuing và scheduling – các ưu tiên và sự phụ thuộc công việc được tích hợp sẵn
- Variable compute per job – mỗi job request CPU/memory khác nhau, Batch chọn đúng instance type
Use cases điển hình: ML training runs, large-scale ETL, media transcoding, scientific simulations, genomics processing.
Lambda-to-Batch migration: Nếu bạn đang dùng Lambda cho jobs mà keep hitting 15-minute timeout, migration lên Batch thường đơn giản vì Batch dùng cùng container image format.
Decision Matrix – Workload Nào Dùng Service Nào
Đây là bảng mapping workload thực tế sang service phù hợp nhất:
| Workload / Use Case | Service Phù Hợp | Lý do chính |
|---|---|---|
| Webhook handler (S3, GitHub, Stripe) | Lambda | Short-lived, event-driven, zero idle cost |
| REST API – traffic thấp/unpredictable | Lambda hoặc App Runner | Scale to zero; App Runner cho always-on simplicity |
| REST API – sustained high traffic | ECS Fargate hoặc EC2 | Lambda per-request cost đắt ở scale lớn |
| REST API – p99 latency < 100ms | ECS Fargate / App Runner | Lambda cold start tạo độ trễ không ổn định |
| Scheduled job < 15 phút | Lambda + EventBridge | Zero idle cost, scale to zero giữa các runs |
| Scheduled job > 15 phút | AWS Batch hoặc ECS task | Lambda timeout exceeded |
| Queue consumer (SQS/Kinesis) | Lambda hoặc ECS | Lambda cho short tasks; ECS cho long-running consumers |
| WebSocket / real-time connection | ECS Fargate hoặc EC2 | Lambda không hold connection giữa invocations |
| Image processing khi upload | Lambda + S3 trigger | S3 event → Lambda resizes → lưu về S3 |
| Video transcoding (> 15 phút) | AWS Batch hoặc ECS task | Lambda timeout quá ngắn |
| ML model training (GPU) | EC2 (GPU) hoặc AWS Batch | Lambda/Fargate không expose GPU |
| ML inference real-time | EC2 (GPU) hoặc ECS | Persistent server, consistent latency |
| Microservices platform (5–20 services) | ECS Fargate | Production-grade không cần K8s overhead |
| Microservices platform (large, multi-cloud) | EKS | K8s-native tooling, portable manifests |
| Batch data processing / ETL | AWS Batch | No time limit, automatic provisioning |
| Legacy monolith migration | EC2 | Long-running process, local filesystem, specific OS |
| Containerize monolith (first step) | ECS Fargate | Nhỏ hơn nhiều so với refactor sang serverless |
| IoT event ingestion | Lambda | Auto-scale với event volume, pay-per-event |
| Daily report / cron job | Lambda + EventBridge | Zero idle cost, no infra to maintain |
| Startup MVP / dự án mới | App Runner hoặc Lambda | Lowest setup, migrate lên ECS khi cần |
So Sánh Chi Phí Thực Tế
Breakdown 100M requests/month
Giả định: ~38 req/sec average, 200ms duration, 1GB memory:
| Compute Option | On-Demand | Với Savings Plans/Spot | Phù hợp nhất |
|---|---|---|---|
| Lambda Standard | ~$390–430 | N/A | Traffic thấp/sporadic |
| Lambda Managed Instances | ~$220–290 | ~$180–240 (3-yr SP) | Steady-state, latency-sensitive |
| ECS Fargate | ~$200–240 | ~$140–180 (Spot + SP) | Long-running, predictable load |
| EKS (Graviton) | ~$215–255 | ~$135–175 (Spot + SP) | Large-scale, ops expertise |
| EC2 Reserved | ~$120–160 | ~$100–140 | Sustained high-throughput |
Lưu ý: Kể từ tháng 8/2025, AWS tính thêm phí INIT phase (cold start). Dùng ARM64/Graviton2 để tiết kiệm thêm 20%.
Rule of thumb về cost
Lambda wins khi traffic thấp hoặc sporadic. Scale to zero = zero cost khi không dùng. Free tier 1M requests + 400K GB-seconds/tháng.
Containers/EC2 wins khi traffic cao liên tục. Khi lượng request cao và đều đặn suốt ngày, chi phí cố định của container sẽ rẻ hơn Lambda trả theo từng lượt gọi. Ngưỡng này thường rơi vào 50–100M request/tháng tùy workload.
Hidden costs phải tính vào TCO
Nhiều team chỉ nhìn compute cost mà bỏ qua:
- Engineer time: EKS cần dedicated DevOps engineer – tính giá engineer time vào TCO
- Lambda Provisioned Concurrency: loại bỏ cold start nhưng adds fixed hourly cost
- ALB: ~$25–35/tháng cho ECS/EKS (base + LCU charges)
- ECR storage + CloudWatch logs: nhỏ nhưng cộng lại đáng kể
- EKS control plane: fixed $72/tháng dù workload nhỏ
- Data transfer: outbound traffic tính fee với tất cả services
ECS vs EKS vs Lambda – Góc nhìn DevOps
| Feature | ECS Fargate | EKS | Lambda |
|---|---|---|---|
| Deployment Complexity | Thấp – AWS fully managed | Cao – K8s expertise required | Rất thấp – upload code và run |
| Scalability | Cao (ECS scheduler) | Cao (K8s HPA auto-scaling) | Automatic, event-driven |
| Cost Model | Pay per resource (có thể optimize) | Pay per cluster/node + $72/mo | Pay per execution (ms-level) |
| Management Overhead | Minimal | Moderate to High | None |
| Cold Start Risk | Không | Không | Có (mitigable) |
| Portability | AWS-only | Multi-cloud & on-prem (K8s) | Tied to AWS ecosystem |
| Customization | Medium | Rất cao (native Kubernetes) | Thấp – limited runtime config |
| CI/CD Integration | CodePipeline, Docker-native | Helm, GitOps, ArgoCD | SAM, Serverless Framework |
| Ideal Team Size | Small to Medium | Medium to Large | Any |
Framework Ra Quyết Định
6 câu hỏi để chọn đúng service
Trả lời 6 câu hỏi này theo thứ tự, dừng lại ở câu đầu tiên cho ra câu trả lời rõ ràng:
Câu hỏi 1: Workload có event-driven và hoàn thành trong < 15 phút không?
- YES → Lambda (Standard hoặc Managed Instances tùy traffic pattern)
- NO → tiếp tục câu 2
Câu hỏi 2: Traffic pattern như thế nào?
- Thỉnh thoảng / Có lúc tăng đột ngột (10x+ swings) → Lambda Standard
- Ổn định / Có thể dự đoán → Lambda Managed, ECS Fargate, hoặc EKS
Câu hỏi 3: Cần GPU, full OS, hoặc persistent local storage không?
- YES → EC2 (hoặc AWS Batch với EC2 mode cho batch GPU jobs)
- NO → tiếp tục câu 4
Câu hỏi 4: Cần Kubernetes-native tooling hoặc multi-cloud portability?
- YES → EKS
- NO → ECS Fargate (đơn giản hơn, chi phí thấp hơn)
Câu hỏi 5: Workload chạy > 15 phút và cần scheduling các job rời rạc?
- YES → AWS Batch
- NO → Lambda hoặc ECS task
Câu hỏi 6: Team có K8s expertise không? Có < 10 services không?
- < 10 services, no K8s expertise → ECS Fargate
- Large scale + K8s expertise → EKS
5 sai lầm phổ biến nhất
Sai lầm 1: Dùng Lambda cho mọi thứ bất kể fit hay không
Lambda là excellent default cho event-driven/short-lived, nhưng nhiều team apply nó cho APIs với strict p99 latency requirements, jobs > 15 phút, hoặc services với lượng request cao và duy trì liên tục. Kiểm tra hard limits và cost model trước khi commit.
Sai lầm 2: Default về EC2 vì quen thuộc
Teams từ traditional infrastructure thường reach for EC2 ngay cả khi Lambda hoặc App Runner đơn giản hơn, rẻ hơn, và lower-maintenance. EC2 chỉ là đúng choice cho specific reasons: full OS control, GPU hardware, persistent connections, legacy workloads.
Sai lầm 3: Chọn EKS quá sớm
EKS powerful nhưng introduces significant operational complexity. 5 services không cần Kubernetes. App Runner hoặc ECS Fargate xử lý được hầu hết container workloads. Migrate lên EKS khi có nhu cầu cụ thể và rõ ràng, không phải vì nó nghe có vẻ "production-ready" hơn.
Sai lầm 4: Ignore cold starts cho latency-sensitive APIs
Lambda cold starts: 100ms đến vài giây tùy runtime. Synchronous APIs với p99 < 100ms cần Provisioned Concurrency (adds cost) hoặc ECS/App Runner. Với Lambda Managed Instances, cold start được giải quyết cho steady workloads.
Sai lầm 5: Tự build job scheduler thay vì dùng AWS Batch
Teams thường try Lambda → hit 15-minute timeout → fallback về persistent EC2 → tự build job scheduler. AWS Batch giải quyết trực tiếp: job queuing, automatic provisioning, job dependencies – không có extra service cost ngoài underlying compute.
Hybrid Architectures – Kết Hợp Services
Phần lớn production systems dùng nhiều compute models. Thuần serverless hoặc thuần containers là hiếm. Câu hỏi đúng không phải "serverless hay containers?" mà là "compute model nào fit workload này?"
Pattern 1: API Gateway + Lambda + ECS Fargate
Pattern phổ biến nhất cho web applications:
- Lambda Managed Instances → High-traffic user-facing APIs (consistent latency, no cold start)
- Lambda Standard → Event handlers và async jobs (cost efficiency, scale to zero)
- ECS Fargate → Long-running processes và background workers
💡 Pattern này phù hợp với team đủ lớn (5+ engineers). Team nhỏ hơn nên chọn một platform chính – hoặc thuần Lambda hoặc thuần ECS – để giảm complexity vận hành.
Pattern 2: E-commerce / SaaS Platform
- Lambda → User authentication webhooks, order events, payment callbacks (short-lived, event-driven)
- ECS Fargate → Product catalog API, user sessions, core web app (always-on, consistent latency)
- ECS Fargate → Analytics API, recommendation service (long-running, containerized)
- AWS Batch + EC2 GPU → ML model training, batch recommendation generation (GPU, no idle cost)
- Lambda + S3 trigger → Image resizing khi upload
Pattern 3: Data Pipeline
- Lambda → Ingest events từ IoT/Kinesis (auto-scale với event volume)
- Lambda → Simple transformations, filtering
- AWS Batch → Heavy ETL, large dataset processing (no time limit, GPU EC2 khi cần)
- ECS Fargate → Serve processed data via API
Pattern 4: ML Platform
- AWS Batch + EC2 GPU → Model training (p4d, g5 instances – no idle GPU cost between runs)
- AWS Batch → Data preprocessing (large memory, no time limit)
- EC2 GPU hoặc ECS → Real-time inference (persistent, low latency, no cold start)
- Lambda hoặc AWS Batch → Batch inference tùy workload size
Real-world Case Study
Một e-learning startup cần handle millions of video interactions, real-time analytics, và scheduled notifications với cost efficiency:
| Component | Service | Lý do |
|---|---|---|
| Course completion emails, image uploads | Lambda | Functions chạy vài giây per event, scale to zero |
| User sessions, authentication microservices | ECS Fargate | Control over dependencies, no EC2 management |
| Analytics engine, ML components | AWS Batch + EC2 GPU | GPU thuộc EC2 node (p4d, g5), no idle cost giữa các runs |
| Real-time analytics API | ECS Fargate | Always-on, low latency serving |
Security & Compliance
Lambda
- IAM execution role per function – least privilege cho từng function
- Có thể attach vào customer-managed VPC (via AWS Hyperplane) để access VPC resources
- Stateless design: reduced attack surface
- Watch out: ENI limit (250/region soft) khi Lambda kết nối VPC; monitor nếu scale lớn
ECS Fargate
- Task-level IAM roles – fine-grained permissions per container
- Full VPC integration – security groups, NACLs, VPC peering
- Container-level isolation – tốt cho high-compliance applications
- Lý tưởng cho fintech, healthcare, government: granular network và container-level isolation
EKS
- Kubernetes RBAC – fine-grained access control at cluster, namespace, resource level
- Network policies – pod-to-pod communication control
- Pod security standards, admission controllers, OPA/Gatekeeper
- Full audit logging, compliance tooling integration
- Most complex security model nhưng most control
Optimization Tips Theo Từng Service
Lambda
- Minimize package size và dependencies – ít hơn = khởi động nhanh hơn
- Set memory phù hợp – memory tăng → CPU tăng proportionally; đôi khi tăng memory giảm total cost vì execution time giảm
- Provisioned Concurrency chỉ cho latency-critical paths – có fixed cost
- Lambda SnapStart (Java 11+, Python 3.12+, .NET 8+) – giảm startup time đáng kể
- Steady workloads: Lambda Managed Instances + Savings Plans = cost competitive với containers
ECS Fargate
- Right-size task definitions – review actual CPU/memory utilization trong CloudWatch; đừng over-provision
- Fargate Spot cho fault-tolerant workloads (batch processing, async jobs) – tiết kiệm đến 70%
- Seekable OCI (SOCI) – speed up container image loading, reduces cold start
- Compute Savings Plans apply to Fargate – commit based on baseline usage
EKS
- Graviton2/3 instances (t4g, m7g, c7g) – ~20% better price/performance vs x86
- EC2 Spot instances cho node groups với fault-tolerant workloads
- Karpenter cho intelligent node provisioning
- Cluster autoscaling – avoid over-provisioning nodes
Kết Luận
Không có một service nào là "tốt nhất" cho mọi trường hợp. Quyết định đúng luôn phụ thuộc vào workload characteristics, chuyên môn của team, traffic patterns, và long-term cost model.
Tóm tắt cuối:
- Lambda → Event-driven, < 15 min, stateless, bursty. Với Managed Instances: steady workloads không cold start.
- ECS Fargate → Long-running containers, production-grade, sweet spot giữa Lambda và EKS.
- EKS → Chỉ khi genuinely cần K8s: multi-cloud, Helm, service mesh, large enterprise.
- App Runner → Simplest container deployment cho web apps/APIs, starting point tốt.
- EC2 → Full control, GPU, persistent connections, legacy. Cheapest ở sustained scale lớn.
- AWS Batch → Discrete compute jobs, no time limit. Go-to khi Lambda timeout là barrier.
Và quan trọng nhất: hầu hết production systems dùng hybrid. Đừng ép mọi workload vào một service. Dùng đúng tool cho đúng việc.
Tài liệu tham khảo chính: AWS Documentation – Choosing an AWS Compute Service | AWS Fargate vs Lambda
Cập nhật tháng 5/2026 – Bao gồm Lambda Managed Instances (AWS re:Invent 2025)