Lambda, containers & PaaS
Serverless, Fargate, ECS/EKS, Beanstalk.
EC2 is not the only compute option, and a good architect matches the workload to the right model. Serverless and container services often reduce operational burden and cost compared with managing instances directly.
Serverless with Lambda
AWS Lambda runs your code in response to events with no servers to manage — you upload a function, and AWS handles provisioning, scaling, and patching, charging only per invocation and duration. It is ideal for event-driven, short-lived work: processing files uploaded to S3, handling API requests behind API Gateway, reacting to queue messages, and glue between services. Because it scales automatically from zero to thousands of concurrent executions, it removes capacity planning for spiky workloads. It is not suited to long-running or always-on processes, or work needing more than its execution-time and memory limits — those belong on containers or EC2.
# WORKLOAD BEST FIT# event-driven, short, bursty → Lambda (serverless functions)# containerized, no server mgmt → ECS/EKS on Fargate (serverless containers)# containerized, need node ctrl → ECS/EKS on EC2# full OS control / legacy → EC2# simple web app, want PaaS → Elastic Beanstalk (managed EC2 + LB + ASG)
Containers and PaaS
For containerized applications, ECS (AWS-native orchestration) and EKS (managed Kubernetes) run your containers, and the Fargate launch type runs them serverlessly — no EC2 hosts to patch or scale. Choose Fargate to minimize operational overhead, or the EC2 launch type when you need node-level control or specific instance types. Elastic Beanstalk sits higher up: a platform-as-a-service that provisions and manages the EC2, load balancer, and auto-scaling for a web app from your code, good for teams wanting to deploy without designing the infrastructure. The architect’s skill is picking the least-operational option that meets the workload’s real requirements, since every layer you hand to AWS is one you do not have to run.