The Place of Deployment Choices
The Place of Deployment Choices — From VMs to Functions
The single phrase "deploy on AWS" hides choices that span very different abstraction levels. From managing one EC2 box directly all the way to function-level hosting like Lambda. Including other clouds and PaaS, the picture grows wider.
1. AWS's compute abstraction ladder
| Service | Abstraction | Notes |
|---|---|---|
| EC2 | VM | Manage down to the OS. Most freedom, most responsibility. |
| Lightsail | Fixed-price VM | Bundle of small VPS. |
| Elastic Beanstalk (2011) | Platform | Code zip → auto EC2 + ELB + ASG. An older PaaS. |
| ECS (2014) | Container orchestrator | On EC2 or Fargate. |
| Fargate (2017) | Serverless containers | No EC2 management; billed per container. |
| EKS (2018) | Managed Kubernetes | Managed control plane; workers on EC2/Fargate. |
| App Runner (2021) | PaaS | Container/source → auto build, deploy, scale. |
| Lambda (2014) | Functions | Event-driven execution. Short tasks. |
Where to host the same code is a tradeoff between operational control and cognitive load.
2. EC2 — Most freedom, most responsibility
OS patching, runtime install, log rotation, security updates — all on the user. Maximum freedom. The burden is heavy without enough operations staff.
3. Beanstalk — Managed EC2 bundle
Upload source/Docker images and EC2 + ELB + ASG are configured automatically. It feels like a leftover from the early 2010s but is still operating. With App Runner and ECS appearing, its share has shrunk somewhat.
4. ECS · Fargate
A managed service for running containers. Two launch modes.
- EC2 mode — Place containers on a self-managed EC2 cluster. Pay for instances; ECS itself is free.
- Fargate mode — Infrastructure is invisible. Bills per container vCPU and memory.
A common comparison: Fargate reduces infrastructure management at the cost of higher unit prices than EC2. Spiky traffic or limited operations staff favor Fargate; stable large workloads can favor EC2 mode for cost.
5. EKS — Managed Kubernetes
AWS manages the control plane; worker nodes run on EC2 or Fargate. The learning and operations burden of k8s itself stays with the user. Strengths are multi-cloud portability and ecosystem.
6. App Runner — Container PaaS
Point at a container image (or source repo) and it builds, deploys, scales, and terminates HTTPS automatically. It feels like ECS/Fargate + ALB rolled into one abstraction. A natural fit for small web apps and APIs.
7. Lambda — Per-function
Executes per request or event. Zero cost when there are no calls. Constraints include cold starts (first-call latency), execution time limits (max 15 minutes), and response size limits. Pairs with API Gateway · ALB · EventBridge · SQS.
8. PaaS in other clouds
| Service | Notes |
|---|---|
| Heroku (2007, acquired by Salesforce 2010) | Classic PaaS. git push heroku main. Free tier ended (2022). |
| Vercel (2015) | Frontend / full-stack (especially Next.js). Global edge + functions. |
| Railway (2020) | Modern PaaS. Spiritual successor to Heroku. |
| Render (2018) | Managed static, web services, DB. |
| Fly.io (2017) | Multi-region container deployment. Edge-near workloads. |
| Cloudflare Workers (2017) | Edge functions. V8 isolate runtime. |
| Google Cloud Run (2019) | GCP's container serverless. |
| Azure Container Apps (2022) | KEDA-based. |
The shared appeal of PaaS is the ability to delegate a large share of operational decisions. Limits are cost, portability, and fine-grained control — at some point vendor lock-in becomes a burden.
9. Tradeoffs with single-VPS
| Provider | Notes |
|---|---|
| Hetzner Cloud | Europe-based low-cost VPS. Strong price/performance. |
| DigitalOcean | Simple UI · managed DB · App Platform. |
| Linode (Akamai) | Traditional VPS. |
| OVHcloud | Large Europe-based VPS provider. |
| Vultr | VPS in many regions. |
For low traffic, fixed-cost preference, and minimal operational cognitive load, a single VPS + docker compose is often reasonable. AWS's strength is feature breadth and scaling ceiling, not simplicity or price.
10. Workload → abstraction mapping (examples)
| Workload | Natural place |
|---|---|
| Static site | S3 + CloudFront · Vercel · Cloudflare Pages · Netlify |
| Small API | App Runner · Lambda + API Gateway · Fly.io |
| One or two containers | App Runner · ECS Fargate · Single VPS + Compose |
| Complex microservices | ECS Fargate · EKS · Nomad |
| Events and batch jobs | Lambda · ECS scheduled tasks · Step Functions |
| Large infrastructure, multi-team | EKS · self-hosted Kubernetes |
In general, higher abstraction means lower operational load and higher unit price. The unit-price order EC2 < ECS EC2 < Fargate < App Runner < Lambda is typical, but call patterns and always-on factors can flip it.
11. Common pitfalls
Lambda cold starts — Pronounced for Java or Node functions with large dependencies. Provisioned Concurrency, ARM (Graviton) functions, and dependency dieting are alternatives.
Egress cost accumulation — External traffic GBs add up everywhere. CDN, caching, and compression make a big difference.
EKS operational load — Even managed, nodes, networks, and add-ons require care. Rarely a recommended first choice for small teams.
PaaS lock-in — An easy start becomes a large migration cost later. Verify whether build, runtime, env vars, and secrets stay within a standard container model.
Mixing many abstractions — When a system contains EC2, ECS, Lambda, and App Runner together, the operational model fragments. Cost tracking and observability scatter as well.
Closing thoughts
Deployment choices are influenced more by team operational model than by code shape. Small teams stay safe by starting at the simplest tier and stepping up when needed. Larger abstractions like EKS only when staff capacity supports the operational burden.
Next
- flyio
- iam
AWS Compute services · App Runner · Lambda · Cloud Run · Fly.io · Heroku · Hetzner Cloud for reference.