Other Compute Services —
EKS · App Runner · Batch
High-level architectural understanding of three additional AWS compute services. Not deep-dives — just enough to know when and why to reach for each one.
⚡ Where These Fit
- Amazon EKS — Managed Kubernetes. Use when you need the Kubernetes ecosystem or multi-cloud portability.
- AWS App Runner — Simplest container deployment. Zero infrastructure. Deploy from source code or image.
- AWS Batch — Job-based compute for batch processing. Queues, scheduling, and automatic resource provisioning.
| Service | Abstraction | You Manage | Best For |
|---|---|---|---|
| EC2 | IaaS — raw VMs | Everything (OS, runtime, scaling) | Full control, custom setups |
| ECS | Managed containers | Task definitions, scaling rules | AWS-native container workloads |
| Fargate | Serverless containers | Task definitions only (no nodes) | Containers without server management |
| EKS | Managed Kubernetes | K8s manifests, node groups | K8s ecosystem, multi-cloud teams |
| Beanstalk | PaaS | Code + config only | Standard web apps, quick deploy |
| App Runner | Fully managed | Code or image only | Simple APIs, no-ops teams |
| Lambda | Serverless functions | Function code only | Event-driven, short tasks |
| Batch | Job scheduler | Job definitions, queues | ETL, HPC, batch processing |
Amazon EKS — Elastic Kubernetes Service
Amazon EKS is a managed Kubernetes service. AWS runs the Kubernetes control plane (API server, etcd, scheduler) — you focus on deploying your applications as Kubernetes workloads. EKS is the standard Kubernetes API, which means anything that works on Kubernetes works on EKS.
What is Kubernetes?
Open-source container orchestrator originally built by Google. The industry standard for running containers at scale across many machines. Huge ecosystem of tools, plugins, and community support.
Mental Model
Think of ECS as an AWS-custom kitchen — AWS-designed workflows, deeply integrated. EKS is a franchise kitchen — standard equipment (Kubernetes) that works the same in any cloud. Same recipes everywhere.
Pricing
Control plane: $0.10/hour (~$72/month) per cluster. Plus the cost of worker nodes (EC2 or Fargate). ECS control plane is free — this cost differential matters.
👉 EKS cost reality: The $72/month is per cluster. If you need separate clusters for dev/staging/prod, that's ~$216/month before any worker nodes. EKS on Fargate removes node management entirely — each pod runs in its own microVM. No EC2 costs, but higher per-pod price. Great for bursty workloads, not ideal for high-volume steady-state.
Control Plane (AWS Managed)
- API Server — accepts kubectl commands
- etcd — key-value store for cluster state
- Scheduler — places pods on nodes
- Controller Manager — watches desired vs actual state
- Runs across 3 AZs automatically
- You never SSH into or manage these components
Data Plane (You Manage)
- Worker Nodes — EC2 instances that run your pods
- Managed Node Groups — AWS provisions and manages EC2 for you
- Fargate Profiles — serverless pods, no nodes to manage
- Pods — smallest deployable unit (1+ containers)
- Services — stable networking for pods (load balancing)
- Deployments — declarative updates for pods
Use EKS When
- Your team already knows Kubernetes
- You need multi-cloud portability (same K8s manifests on GCP/Azure)
- You require the Kubernetes ecosystem (Helm, Istio, ArgoCD, Prometheus)
- Complex microservices with service mesh needs
- You're migrating existing K8s workloads to AWS
Don't Use EKS When
- Your team doesn't know Kubernetes — steep learning curve
- Simple container workloads — use ECS (free control plane, simpler)
- Single web app — use App Runner or Beanstalk
- Event-driven / short tasks — use Lambda
- Cost-sensitive small projects — $72/month control plane overhead
| Feature | ECS | EKS |
|---|---|---|
| Orchestrator | AWS-proprietary | Kubernetes (open-source standard) |
| Control plane cost | Free | ~$72/month per cluster |
| Learning curve | Medium (AWS concepts) | High (K8s concepts + AWS) |
| Portability | AWS only | Multi-cloud (K8s standard) |
| Ecosystem | AWS integrations | Vast K8s ecosystem (Helm, Istio, etc.) |
| Best for | AWS-native teams | K8s-experienced / multi-cloud teams |
EKS control plane → EC2/Fargate worker nodes → ALB Ingress for traffic · ECR for images · CloudWatch for observability · IAM for auth
Managed Kubernetes — portable, powerful, but complex.
- What: AWS runs the Kubernetes control plane. You run pods on EC2 nodes or Fargate.
- When: You need Kubernetes ecosystem, multi-cloud portability, or have existing K8s expertise.
- When NOT: Simple container apps (use ECS), simple web apps (use App Runner), event-driven (use Lambda).
- Cost: ~$72/month control plane + node costs. ECS control plane is free.
- Exam tip: Know EKS = managed K8s, supports EC2 + Fargate launch types, $0.10/hr cluster fee.
AWS App Runner
AWS App Runner is the simplest way to deploy a containerized web app or API on AWS. No VPC configuration, no load balancer setup, no auto scaling rules — you point App Runner at your source code (GitHub) or container image (ECR), and it handles literally everything else.
What It Does
Takes your code or container image, builds it, deploys it, load-balances it, auto-scales it, and gives you an HTTPS URL. From code to production in minutes.
Mental Model
Think of App Runner as Heroku on AWS. Push code → get a URL. You don't know (or care) about the underlying servers. It's the closest AWS gets to a "magic deploy button."
Pricing
Pay for vCPU + memory while your app is actively processing requests. Idle instances cost much less (only memory charged). No ELB cost, no EC2 cost. Simple, predictable.
Source Options
- Source Code — Connect a GitHub repo. App Runner builds with Buildpacks (Node.js, Python, Java).
- Container Image — Point to an ECR image. More control over the runtime.
- Auto Deploy — Push to main → automatic redeploy. CI/CD built in.
What App Runner Manages
- Build — Compiles code, creates container
- Deploy — Rolls out new version
- TLS/HTTPS — Free certificate, auto-renewed
- Load Balancing — Built-in, no config needed
- Auto Scaling — 1 → N instances based on requests
- Health Checks — Auto-replaces unhealthy instances
Use App Runner When
- You want the fastest path from code to URL
- Small to medium APIs and web apps
- Your team has zero DevOps capacity
- Prototypes, MVPs, internal tools
- You don't want to manage VPCs, ELBs, or ASGs
- Predictable, simple pricing is important
Don't Use App Runner When
- You need fine-grained network control (custom VPC rules, private subnets)
- Complex multi-service architectures — use ECS or EKS
- GPU workloads or specialized instance types
- Long-running background tasks — no worker environments
- You need WebSockets or gRPC (limited support)
- High-volume, cost-optimized production — ECS is cheaper at scale
| Feature | App Runner | ECS Fargate | Elastic Beanstalk | Lambda |
|---|---|---|---|---|
| Deploy from | Code or Image | Task Definition + Image | ZIP/WAR/Docker | Function code |
| Infrastructure | Zero config | VPC, ALB, IAM, SG | Automated but visible | None |
| Scaling | Automatic (request-based) | You configure ASG rules | Built-in ASG | Per-request |
| Networking | Public HTTPS (VPC optional) | Full VPC control | Full VPC control | VPC optional |
| Flexibility | Low (opinionated) | High | Medium | Medium |
| Best for | Simple APIs, no-ops teams | Production containers | Standard web apps | Event-driven |
Source (GitHub/ECR) → App Runner builds + deploys + scales → HTTPS URL. Optional: VPC Connector for private resource access (RDS, ElastiCache).
The simplest container deployment on AWS — from code to URL in minutes.
- What: Fully managed service — deploy from GitHub or ECR. No VPC, ELB, or ASG to configure.
- When: Simple APIs, MVPs, internal tools, teams with zero DevOps capacity.
- When NOT: Complex microservices (use ECS/EKS), GPU workloads, background workers, fine-grained networking.
- Cost model: Pay per vCPU-second + memory while actively processing. Idle instances charge memory only (no vCPU). Cannot scale to zero — minimum 1 instance always running.
- VPC access: Use a VPC Connector to reach private databases (RDS, ElastiCache). Note: ~1 min to provision, has ENI limits, cannot cross regions/accounts.
- Exam tip: Know App Runner = simplest container deploy, auto-scales, HTTPS included, optional VPC Connector.
AWS Batch
AWS Batch is a fully managed job processing service. You submit jobs (containerized workloads), Batch queues them, provisions the right amount of compute (EC2 or Fargate), runs the jobs, and shuts down when done. You never worry about cluster management, job scheduling, or resource provisioning.
What It Does
Runs batch processing workloads at any scale. You define jobs (Docker containers), submit them to queues, and Batch handles scheduling and compute provisioning automatically.
Mental Model
Think of Batch as a laundromat. You drop off bags of laundry (jobs). The laundromat has washing machines of different sizes (compute). It loads machines efficiently, runs everything, and notifies you when done.
Pricing
No charge for Batch itself. You pay only for the underlying compute (EC2 instances or Fargate tasks) used to run your jobs. Supports Spot Instances for up to 90% savings.
👉 Key distinction: AWS Batch is for batch processing — finite jobs that start, run, and finish. It is NOT for long-running services, real-time APIs, or web servers. Those belong to ECS, EKS, or App Runner.
Job Definition
- Docker image to run (from ECR or Docker Hub)
- vCPU + memory requirements
- Environment variables and mount points
- Retry strategy — how many times to retry on failure
- Like a "recipe" — what to run and how
Job Queue
- Where you submit jobs — they wait here until compute is available
- Multiple queues with priority (urgent vs background)
- Jobs are scheduled FIFO within priority
- Connected to one or more compute environments
Compute Environment
- The pool of compute that runs your jobs
- Managed — Batch provisions/terminates EC2 instances for you
- Unmanaged — You provide your own EC2 instances
- Supports Spot Instances for massive cost savings
- Supports Fargate for serverless job execution
- Auto-scales between minvCpus and maxvCpus
Job Lifecycle
- SUBMITTED → job enters the queue
- PENDING → waiting for compute capacity
- RUNNABLE → ready, waiting for a slot
- STARTING → container launching
- RUNNING → executing your workload
- SUCCEEDED / FAILED → done
Use Batch When
- ETL pipelines — transform large data sets
- Scientific computing / HPC — simulations, modeling
- Media processing — video transcoding, rendering
- Machine learning — training jobs, batch inference
- Financial modeling — risk calculations, backtests
- Any job that starts, runs, and completes
Don't Use Batch When
- Real-time APIs — use ECS, EKS, or App Runner
- Event-driven triggers with sub-second latency — use Lambda
- Long-running services — Batch jobs eventually end
- Simple cron jobs — use Lambda + EventBridge (cheaper, simpler)
- Jobs under 15 minutes with simple dependencies — Lambda is sufficient
| Feature | AWS Batch | Lambda | Step Functions |
|---|---|---|---|
| Best for | Long-running jobs (hours) | Short tasks (<15 min) | Orchestrating multiple steps |
| Max duration | Unlimited | 15 minutes | 1 year (state machine) |
| Compute | EC2 / Fargate (any size) | Lambda (10GB RAM max) | Invokes other services |
| GPU support | ✅ Yes | ❌ No | Via Batch/SageMaker |
| Spot support | ✅ Yes (huge savings) | N/A | N/A |
| Cost at idle | $0 (scales to zero) | $0 | $0 |
| Job dependencies | ✅ Built-in (job DAGs) | Manual or via Step Functions | ✅ Built-in (orchestration) |
Job Dependencies (DAGs)
Batch supports dependency chains — jobs wait for predecessors to finish before starting:
Job A (extract) → Job B (transform) → Job C (load)
Each job only starts after its parent completes successfully. Failed parents = dependent jobs cancelled.
Array Jobs (Parallel Processing)
Run the same container across many inputs in parallel — massive parallelization without managing separate submissions:
--array-properties size=100→ 100 parallel jobs- Each job gets
AWS_BATCH_JOB_ARRAY_INDEX(0–99) - Process 1M records in 100 parallel chunks
EventBridge triggers → Batch queues + schedules → EC2/Spot/Fargate runs containers → S3 for data · CloudWatch for logs · IAM for permissions
Managed job processing — submit, schedule, and run batch workloads at any scale.
- What: Job queue + scheduler + auto-provisioned compute (EC2/Spot/Fargate). Free service — pay for compute only.
- When: ETL pipelines, scientific computing, media processing, ML training, financial modeling.
- When NOT: Real-time APIs (use ECS), short event handlers (use Lambda), long-running services (use ECS/EKS).
- Spot support: Use Spot Instances for up to 90% cost savings on fault-tolerant batch jobs.
- Job dependencies: Built-in DAG support — Job B waits for Job A to finish before starting.
- Exam tip: Know Batch = managed job scheduling, supports Spot, scales to zero, NOT for real-time workloads.
Quick Selection Guide
| If you need... | Use... | Why |
|---|---|---|
| Full OS control, custom AMIs | EC2 | Maximum flexibility, any workload |
| AWS-native container orchestration | ECS | Simple, free control plane, deep AWS integration |
| Serverless containers (no nodes) | Fargate | Containers without any server management |
| Kubernetes ecosystem, multi-cloud | EKS | Standard K8s API, Helm/Istio/ArgoCD |
| Simplest deploy (code → URL) | App Runner | Zero infra config, auto HTTPS + scaling |
| PaaS with access to resources | Elastic Beanstalk | Deploy ZIP/WAR, retain access to EC2/ELB/ASG |
| Event-driven, short tasks (<15 min) | Lambda | Pay per request, zero servers, massive concurrency |
| Batch/ETL, long-running jobs, HPC | AWS Batch | Job queues, Spot Instances, scales to zero |
Three services, three different problems — know when to reach for each.
- EKS = Kubernetes on AWS. Portable, powerful, complex. Use when K8s ecosystem matters. $72/mo per cluster.
- App Runner = Heroku on AWS. Code → URL in minutes. Use for simple APIs, MVPs, no-ops teams. Min 1 instance always running.
- Batch = Job laundromat. Submit jobs, Batch handles everything. Use for ETL, HPC, ML training. Supports Spot for 90% savings.
- Rule of thumb: Start with the simplest option that meets your needs. You can always graduate to more complex services later.