Cloud compute spans a wide spectrum: from long-running VMs (EC2, Azure VMs, GCP Compute Engine) with full OS control, to managed container platforms (ECS, Fargate, Azure Container Apps), to event-driven serverless functions (Lambda, Azure Functions, Cloud Run) that execute in sub-second billing increments. Choosing the right compute primitive is a core architectural decision that directly impacts cost, cold-start latency, operational overhead, and scaling behaviour.

Key Points

  • EC2 instance types follow a naming convention: family (m=general, c=compute, r=memory, g=GPU) + generation + size (e.g., m6i.4xlarge = 16 vCPU, 64 GB RAM).
  • AWS Fargate and Azure Container Apps eliminate node management; you specify vCPU + memory per task, not instance types — billing is per second of container uptime.
  • Lambda/Azure Functions/GCF have a maximum execution duration (Lambda: 15 min, Azure Functions Consumption: 10 min) making them unsuitable for long-running batch jobs.
  • ECS (Elastic Container Service) supports both EC2 launch type (customer manages nodes) and Fargate launch type (serverless) — same task definition, different pricing model.
  • Cold starts: JVM Lambda functions cold start in ~1–3 s; Go/Node.js/Python cold start in 100–500 ms; Lambda SnapStart (Java) reduces cold start to ~200 ms by snapshotting JVM state.
  • Spot/Preemptible/Spot VMs offer 60–90% cost reduction but can be reclaimed with 2-minute notice — appropriate for stateless, fault-tolerant batch workloads.
  • Azure App Service Plan shared pricing allows multiple apps on one underlying VM; isolate latency-sensitive services to dedicated plans.
  • Graviton3 (AWS ARM-based) instances offer ~40% better price-performance vs comparable x86 instances for most web and application workloads.

Real-World Example

Lyft runs its ride-matching service on ECS Fargate for consistent latency and easy horizontal scaling, while bulk notifications run on Lambda triggered by SQS for cost-efficient event-driven processing.