We started the compute layer on Day 13 with EC2, ELB, and Auto Scaling — where you launch and manage everything yourself. Today we move one level up the abstraction ladder: services where AWS takes over more of the operational burden. By the end of this post you'll know what each one does, how it differs from plain EC2, and when to actually reach for it.
AWS Elastic Beanstalk
Elastic Beanstalk is a Platform-as-a-Service (PaaS) offering built on top of EC2. You upload your application code and a bit of configuration; Beanstalk provisions the EC2 instances, load balancer, and Auto Scaling Group for you.
The IaaS/PaaS/SaaS framing from Day 13 explains why this exists: with EC2 you cook the meal yourself, with Beanstalk you eat at a restaurant — someone else runs the kitchen. In practice, that means you pick a platform (Tomcat for Java, .NET, Python, Docker, Go, and so on), upload your application, and Beanstalk launches and manages the EC2 instances behind the scenes, handing you back a URL.
One nuance worth calling out: in general, PaaS means you have zero control over the underlying servers. Beanstalk is a bit more generous than that — you still have full access to the EC2 instances it creates, you can SSH in and tweak things, Beanstalk just manages the lifecycle for you instead of you doing it manually.
Reach for Beanstalk when you want to ship an app fast without building out your own CI/CD-to-EC2 pipeline, but you're not ready to go fully serverless. It's a strong middle ground for small-to-mid teams. Where it gets awkward is long-term: because it abstracts the infrastructure, teams that eventually need fine-grained control — custom networking, non-standard scaling logic — often end up moving out of Beanstalk into raw EC2 with their own CI/CD later. Treat it as a fast on-ramp, not necessarily a forever-home for a growing production system.
Amazon Lightsail
Lightsail is a simplified virtual private server (VPS) service. You spin up an instance that comes pre-installed with common stacks — WordPress, GitLab, Node.js, Joomla, Drupal, Redmine, Nginx, cPanel, and more.
It doesn't support Auto Scaling, and it's built for small businesses and non-technical users who just want a working server without navigating EC2, VPC, security groups, and everything else that comes with raw EC2. Pricing is also flat and predictable, unlike EC2's more granular pay-as-you-go model.
Think of Lightsail as EC2 with the training wheels on. If a client just needs a WordPress blog or a small internal tool and will never need to scale past one or two servers, Lightsail is genuinely the right call — it's cheaper to reason about and harder to misconfigure. The moment scaling, high availability, or custom networking enters the conversation, that's the signal to migrate to EC2 + ELB + Auto Scaling instead.
AWS Lambda
Lambda is a serverless compute service. You write a function — a set of instructions — and Lambda runs it in response to a trigger, with no server to provision, patch, or manage. It supports Java, Python, Ruby, Node.js, and more, and you're charged for actual execution time and requests, not for idle capacity, since there's no persistent server sitting around.
A classic automation example: automatically stopping all EC2 instances at 11 PM and starting them again at 9 AM to save cost outside business hours — no cron job on a server needed, Lambda just runs on schedule.
A couple of details worth knowing beyond the basics. Cold starts happen on the first invocation after a period of inactivity, since AWS has to spin up the execution environment — worth factoring in if you're building latency-sensitive APIs. And Lambda functions can run for a maximum of 15 minutes per invocation — it's built for short, event-driven tasks, not long-running processes. Common real-world uses include resizing images on upload to S3, lightweight API backends (often paired with API Gateway), glue logic between AWS services, and scheduled housekeeping tasks like the EC2 start/stop example above.
Amazon EventBridge
EventBridge is a serverless event bus. It captures events happening across your AWS environment — and even from SaaS apps — and routes them to targets, most commonly Lambda functions, based on rules you define.
Tying it back to the Lambda example: you define a rule in EventBridge (say, "every day at 11 PM"). When that rule triggers, EventBridge invokes a target — a Lambda function written in Python, for instance — and that function executes its logic, in our case stopping EC2 instances.
It's easy to conflate EventBridge with SNS since both deal with "something happened, now do something." The distinction: SNS is primarily a pub/sub messaging service for pushing notifications to subscribers (email, SMS, other services), while EventBridge is built specifically around rules matching event patterns and routing them to targets — including third-party SaaS event sources, not just internal AWS activity. If you're building event-driven automation within AWS, EventBridge is usually the right tool; if you just need to fan out a notification, SNS is simpler.
Which one do you actually reach for?
| Service | Control Level | Best For |
|---|---|---|
| Elastic Beanstalk | Managed infra, full app control | Fast deployment without building your own pipeline |
| Lightsail | Minimal control, pre-built stacks | Small business sites, simple non-technical use cases |
| Lambda | No servers at all | Short, event-driven tasks and automation |
| EventBridge | No servers at all | Routing events to the right target based on rules |
Quick Recap Questions
- What's the key difference between EC2 and Elastic Beanstalk in terms of who manages the underlying servers?
- Why doesn't Lightsail support Auto Scaling, and what does that tell you about its target audience?
- In the EC2 stop/start automation example, what role does EventBridge play versus what role does Lambda play?
- What's the maximum execution time for a single Lambda invocation?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 15 | Networking Basics | VPC, Route 53 |
Top comments (0)