Skip to content
R&D

AWS Compute — Service Map

From the AWS Compute overview slide (Developing Serverless video) + Ebot Q&A corrections.

The four compute services

Section titled “The four compute services”
Service Mental model Correction
EC2 VPS with AWS-integrated tools ✓ — AMIs, elastic IPs, security groups, EBS, IAM roles, CloudWatch, tagging built in
ECS NOT Cloud Run — it’s a container orchestrator (Kubernetes-lite) Cloud Run = serverless (scale-to-zero). ECS manages clusters + task placement. AWS’s Cloud Run equivalent = App Runner or Fargate
EC2 Auto Scaling HORIZONTAL, not vertical Adds/removes whole EC2 instances (2→10 servers). Vertical = resize the SAME instance (manual, not auto)
Lambda Function-as-a-Service ✓ — code runs on events, no server, pay per invocation, 15 min max

Horizontal vs vertical scaling

Section titled “Horizontal vs vertical scaling”
Horizontal (Auto Scaling):   add/remove whole machines
  ┌─[instance]─┐
  ├─[instance]─┤  ← 2 → 10 servers
  └─[instance]─┘


Vertical (manual resize):   upgrade the SAME machine
  ┌─[t3.micro → t3.large]─┐
  • Auto Scaling = launch template + min/max desired capacity + policies (CPU, mem, queue depth, schedule) + health checks
  • Vertical scaling on AWS = manual instance type change (stop → resize → start)

Containers comparison

Section titled “Containers comparison”
ECS Cloud Run App Runner Fargate
Type Orchestrator Serverless containers Serverless containers Serverless container runtime
Scale-to-zero No Yes (native) Yes No (runs on ECS/EKS)
Cluster mgmt You define, AWS schedules AWS managed AWS managed AWS managed
Billing Per EC2 node / Fargate task Per request Per request Per task vCPU/GB

Video source

Section titled “Video source”

Meeting Recording - Webinar - Developing Serverless Solutions and Event-Driven Architectures.mp4 (compute slide)

Compute stack summary (one-liner mental model)

Section titled “Compute stack summary (one-liner mental model)”
EC2   = VPS (raw VM, most control + ops)
ECS   = container orchestrator with AWS tooling
EKS   = container orchestrator with Kubernetes tooling
Both  = run on EC2 nodes OR Fargate (per-workload choice)
Fargate = Firecracker microVMs — same isolation tech as Lambda
        = accepts ANY container (no handler needed)
Lambda  = Firecracker microVMs too
        = accepts ONLY handler-shaped functions (function API)
  • Firecracker microVM = shared isolation engine
    • Lambda = snapshot-boot scooter (fast spawn ~125ms, short-lived, dies after response)
    • Fargate = cold-boot car (30-60s start, long-lived, runs until stopped)
  • Fargate is NOT Lambda under the hood — same tech family, different lifecycle optimization
  • Fargate limitations: no SSH/daemons, no GPU, no custom CNI, no DaemonSets (EKS)
  • Container services (Cloud Run/ECS/EKS/Fargate/App Runner) run your app as-is — just listen on a port
  • Lambda containers still need the handler — function-shaped only
  • AWS App Runner = closest to GCP Cloud Run (deploy any container → URL → autoscale)
Section titled “Related”
  • [[aws/index]]
  • [[aws/lambda-usage/index]]
  • [[aws/ccp-study-checklist/index]]