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.