AWS deployment options have gotten complicated with all the service choices, pricing models, and architectural patterns flying around. As someone who has migrated dozens of applications to AWS and helped startups choose their infrastructure stack, I learned everything there is to know about when to use EC2, Elastic Beanstalk, ECS/Fargate, or Lambda. Today, I will share it all with you.
Lambda: Start Here for New Projects
If your application can be broken into request-response cycles under 15 minutes each, Lambda is probably your answer. You write functions, AWS runs them when triggered. No servers to manage, no capacity planning, no paying for idle time. It’s the closest thing to “just run my code” that exists.
Lambda works for API backends, webhook handlers, scheduled tasks, event processing (S3 uploads, DynamoDB changes), and lightweight data transformations. These are the bread and butter of modern serverless architectures.
Lambda doesn’t work for long-running processes, applications that need persistent connections (WebSockets require workarounds), anything that takes more than 15 minutes per invocation, or workloads that run constantly at high volume. Lambda’s per-request pricing eventually loses to always-on compute when you’re processing constant traffic.
Elastic Beanstalk: Traditional Apps, Less Work
Probably should have led with this section, honestly. Beanstalk is essentially managed EC2. You upload your code, tell it what language runtime you need, and it handles provisioning instances, load balancers, auto-scaling groups, and deployments. Under the hood, it’s the same EC2 instances you’d run yourself, just with less manual configuration.
Use Beanstalk when you have a traditional web application—Rails, Django, Spring, Node/Express—that expects to run on a server. You want something simpler than managing EC2 directly but need more control than Lambda provides. Your team knows how to deploy to servers but doesn’t want to become infrastructure experts.
Beanstalk downsides? The abstraction occasionally leaks. Debugging deployment failures sometimes requires understanding the underlying EC2 and CloudFormation mechanics. The platform versions like Amazon Linux 2 eventually deprecate, forcing migration work every few years.
ECS/Fargate: Containers Without Kubernetes
If you’ve containerized your application, ECS runs those containers. Fargate mode means you don’t manage the underlying EC2 instances—you just specify CPU and memory requirements, and AWS handles placement. EC2 launch type gives you more control and can be cheaper at scale if you’re willing to manage capacity.
Use ECS when your application is already containerized, you want consistent environments across development and production, you need to run multiple services with different scaling characteristics, or you’re not ready for Kubernetes complexity but want container orchestration.
ECS vs EKS? If you’re choosing between AWS container orchestrators, ECS is simpler and more tightly integrated with AWS services. EKS (managed Kubernetes) makes sense if you need Kubernetes specifically—for portability across clouds, because your team already knows it, or because you need its extensive ecosystem of tools.
Decision Framework
New API or event-driven project: Start with Lambda. You can always move to containers later if you hit limits. The operational simplicity is worth it.
Existing app that runs on a server: Beanstalk if you want minimal changes to your deployment process. ECS if you’re willing to containerize for better environment consistency.
Microservices architecture: ECS or EKS. The orchestration features are worth the complexity when you have many services to manage and coordinate.
Already containerized: ECS for simplicity and tight AWS integration. EKS if you need Kubernetes portability or ecosystem.
Very high, steady traffic: EC2 or ECS with reserved instances. Lambda’s per-request pricing loses to always-on compute for workloads that never idle.
That’s what makes cloud infrastructure endearing to us web developers—you can start simple and scale up as needs change. Most teams overthink this decision. Pick the simplest option that meets your requirements. You can migrate later if needed—the hard part is building the application that provides value, not choosing how to run it.
