LearningTree · AWS · Compute
Compute Services —
Running Applications in the Cloud
EC2, Lambda, ECS, Elastic Beanstalk — four ways to run code in AWS, each trading control for convenience differently. This page maps the full compute landscape before you dive into each service.
01
Chapter One
What is Compute?
Compute services are the core of cloud computing — they let you run applications, process data, and execute workloads without managing physical servers.
Every application you build needs compute: a web server answering HTTP requests, a Lambda function processing an S3 upload, a container running a microservice. AWS provides multiple compute models so you pick exactly how much infrastructure you want to own vs. hand off to the platform.
What Does Compute Mean?
Compute = running code or applications. Whenever your application is doing work — serving a request, processing a file, executing a job — it is consuming compute.
Examples of Compute Workloads
- Web servers serving HTTP requests
- Backend APIs handling business logic
- Batch jobs processing files overnight
- Event-driven functions reacting to queue messages
- ML inference serving model predictions
What Changes Between Services
- How much control you have over OS and runtime
- How much management AWS takes off your hands
- How billing works (per-hour, per-request, per-second)
- How scaling happens (manual, scheduled, automatic)
From Fundamentals to Compute
All the fundamentals concepts you've learned feed directly into how compute services work:
Virtualization ↗
- EC2 instances are VMs created by the Nitro hypervisor on physical AWS hosts
- Every concept from the VM diagram applies directly here
Cloud Models ↗
- EC2 = IaaS (you manage OS and above)
- Lambda / Beanstalk = PaaS (you manage code only)
- The service model defines your security surface
Shared Responsibility ↗
- On EC2 you patch the OS — on Lambda you don't
- The compute model determines exactly where your responsibility begins
02
Chapter Two
Services & Spectrum
Core Compute Services
IaaS
Amazon EC2
Virtual machines with full control over OS, runtime, and configuration. You manage the guest OS upward; AWS owns the hypervisor.
Deep dive →
Containers
ECS & Fargate
Run Docker containers at scale. ECS manages orchestration; Fargate removes the need to manage EC2 instances entirely.
Deep dive →
Serverless
AWS Lambda
Function-as-a-service. Write code, deploy it, AWS runs it on demand. Zero server management, billing per 1ms execution time.
Deep dive →
PaaS
Elastic Beanstalk
Deploy your app code, Beanstalk provisions EC2, load balancers, Auto Scaling, and monitoring automatically.
Deep dive →
Other
EKS · App Runner · Batch
Kubernetes (EKS), simple deployments (App Runner), and job processing (Batch) — high-level architectural understanding.
Deep dive →
Compute Categories
| Category | Services | You Manage | Best For |
|---|---|---|---|
| Virtual Machines | EC2 | OS, runtime, patching, scaling | Full control, GPU, custom setups |
| Containers | ECS, Fargate, EKS | Container image, task config | Microservices, portable workloads |
| Serverless | Lambda | Function code only | Event-driven, short tasks, scale-to-zero |
| PaaS | Elastic Beanstalk, App Runner | Application code + config | Standard web apps, rapid deployment |
| Batch Processing | AWS Batch | Job definitions, queues | ETL, HPC, scientific computing |
The Compute Spectrum — Control vs Simplicity
Every compute service trades control for simplicity. More control = more responsibility. More abstraction = less to manage but less flexibility.
← More control / more responsibility Less management / more abstraction →
EC2
You own the OS
ECS
You own the container
Fargate
Container, no servers
Beanstalk
You own the app
Lambda
You own the function
Responsibility Shift Diagram
AWS Compute — What YOU manage vs what AWS manages per service
03
Chapter Three
Decision Guide
When to Use What
Use EC2 when…
- Full OS-level control needed
- GPU or bare-metal requirements
- Custom AMI / kernel tuning
- Long-running persistent workloads
- Steady-state cost optimization (RI/SP)
Use ECS / Fargate when…
- Docker-based microservices
- Long-running containers (always-on)
- More runtime control than Lambda
- Zero server management (Fargate)
- Independent scaling per service
Use Lambda when…
- Event-driven execution
- Short-lived functions (<15 min)
- Scale-to-zero matters
- Zero server management
- Spiky or unpredictable traffic
Use Beanstalk when…
- Standard web app (Node/Java/Python)
- Fastest path from code to production
- Don't want to configure infra
- Still need access to resources
- Prototypes, internal tools
Full Service Comparison
| Service | Type | Scaling | Startup | Max Runtime | Billing |
|---|---|---|---|---|---|
| EC2 | IaaS (VMs) | ASG (manual config) | 1–3 min | Unlimited | Per second |
| ECS (EC2) | Containers | Service Auto Scaling | 30–60s | Unlimited | EC2 cost |
| ECS (Fargate) | Serverless containers | Automatic | 30–60s | Unlimited | vCPU + memory/sec |
| Lambda | Serverless functions | Per-request (instant) | 100ms–3s | 15 min max | Per ms + requests |
| Beanstalk | PaaS | Built-in ASG | 2–5 min | Unlimited | Underlying resources |
| EKS | Managed K8s | K8s HPA/Karpenter | 30–60s | Unlimited | $72/mo + nodes |
| App Runner | Fully managed | Request-based auto | ~30s | Unlimited | vCPU + memory |
| Batch | Job scheduler | Queue-based auto | 1–3 min | Unlimited | Underlying compute |
04
Chapter Four
Architecture Patterns
Common Production Patterns
Most production architectures combine a traffic entry point, a compute service, and a data layer. Here are the three most common patterns:
Pattern 1: Serverless API
API Gateway → Lambda → DynamoDB
- Zero servers to manage
- Scale to zero (no idle cost)
- Best for: event-driven APIs, microservices
Pattern 2: Container Service
ALB → ECS Fargate → RDS
- Long-running, always-on
- Docker-based (portable)
- Best for: web apps, APIs, microservices
Pattern 3: Traditional Web App
ALB → EC2 (ASG) → RDS
- Full control over everything
- Custom OS and runtime
- Best for: legacy apps, GPU, full control
How Compute Fits in the Architecture
User Request
Browser · Mobile · API
→
Load Balancer
ALB / API Gateway
→
Compute
EC2 · Lambda · ECS
→
Storage / DB
S3 · RDS · DynamoDB
05
Chapter Five
Exam Insights
Exam Decision Hints
| If the question says… | Think… |
|---|---|
| "Least operational overhead" + containers | ECS + Fargate |
| "Event-driven" or "scale to zero" | Lambda |
| "Kubernetes" or "multi-cloud" | EKS |
| "GPU" or "custom AMI" | EC2 |
| "Deploy code quickly" + "standard web app" | Elastic Beanstalk |
| "Batch processing" or "ETL jobs" | AWS Batch |
| "Simplest container deploy" + "no infra" | App Runner |
| "15-minute timeout" as a constraint | Not Lambda — use ECS or EC2 |
| "No servers" + "containers" | Fargate |
| "Cost-optimize steady 24/7 workload" | EC2 with Reserved Instances |
Common Exam Traps
| Trap | Reality |
|---|---|
| "Lambda is always cheapest" | Only for spiky/infrequent workloads. Steady-state 24/7 = EC2 with RI is cheaper. |
| "Fargate supports GPU" | NO. GPU requires EC2 launch type (P/G instance families). |
| "Beanstalk is just EC2" | It's PaaS — EC2 + ALB + ASG + CloudWatch + CloudFormation, automated. |
| "ECS control plane costs money" | ECS control plane is free. EKS charges ~$72/month per cluster. |
| "Serverless means no servers" | Servers exist — AWS manages them. "Serverless" = you don't see or manage them. |
Summary
📋 Compute Services — Recap
- Compute = running code. Any active workload consumes compute.
- Core services: EC2 (IaaS), ECS/Fargate (containers), Lambda (serverless), Beanstalk (PaaS). Plus: EKS, App Runner, Batch.
- The spectrum trades control for simplicity — EC2 (max control) → Lambda (max abstraction).
- Start with the simplest service that meets your needs. Graduate to more complex only when required.
- Most architectures combine multiple models — Lambda for events, ECS for APIs, EC2 for legacy.
👉 Key Takeaway
Don't pick the "most powerful" compute service — pick the one that minimises management without sacrificing what your workload actually needs. Start simple, add complexity only when you hit a real limitation.