Imagine running a large EC2 instance around the clock—even though your application only springs to life a couple of times a day. The instance is always on, the meter is always running, and yet the workload itself rarely needs more than a few minutes of actual compute time.
This is a common pattern we see in AWS exam scenarios and in real-world architectures: steady costs for workloads that are anything but steady.
In this post, we’ll break down why keeping an EC2 instance always on leads to wasted spend, and how moving to an event-driven model with AWS Lambda transforms both your architecture and your bill.
You’ll learn
The cost traps of idle EC2 capacity
Why Lambda is tailor-made for sporadic, short-lived workloads
How to spot exam keywords like “runs only a few times a day” or “reduce costs the MOST” that signal serverless is the right answer
Use Case: An EC2 Application Running Only a Few Times a Day
A company runs an application on a large general-purpose EC2 instance that’s part of an Auto Scaling group.
After reviewing Amazon CloudWatch metrics, the team discovers:
The application runs randomly only a couple of times per day
Each execution lasts no more than 10 minutes
It uses 4 GB of memory
The EC2 instance is running 24/7 even when idle
The goal: Reduce costs while still meeting workload requirements.
The Problem with Always-On EC2
Running a large EC2 instance continuously means:
Paying for compute capacity 24 hours a day
Wasting resources when the app is idle most of the time
Over-provisioning for peak performance that’s only needed briefly
This is a classic case of paying for unused capacity.
The Lambda Solution
Action: Refactor the application to run as an AWS Lambda function.
Why it works
Event-driven execution – Lambda runs code only when triggered
No idle cost – You pay only for compute time used, measured in milliseconds
Scales automatically – Can handle sporadic workloads without manual intervention
Managed service – No servers to manage or patch
For this scenario
Each run fits well within Lambda’s 15-minute max runtime
The memory requirement (4 GB) is within Lambda’s configurable limits (up to 10 GB)
The unpredictable execution pattern is ideal for pay-per-use pricing
Cost Impact
Switching from an always-on EC2 to Lambda can cut costs drastically when:
The application is idle most of the day
Execution times are short
Workload triggers are intermittent or unpredictable
Instead of paying for unused hours, you’re billed only for the few minutes the app actually runs.
AWS Certification Exam Insights
When you see these keywords on the exam, Lambda is usually the right answer:
“Runs only a few times a day” → think event-driven architecture
“Max runtime less than 15 minutes” → Lambda is an option
“Reduce costs the MOST” → move from always-on compute to serverless/pay-per-use
Exam Tip: Lambda often appears as the cost-optimized choice for bursty or sporadic workloads that fit within its execution limits.
Cheat Sheet: EC2 vs Lambda for Infrequent Workloads
Factor | EC2 (Always-On) | AWS Lambda (Serverless) |
|---|---|---|
Billing | Pay per hour/second while running | Pay per execution (ms) and memory used |
Scaling | Manual or Auto Scaling group | Automatic scaling per event |
Management | Manage OS, patches, scaling | Fully managed by AWS |
Best For | Steady, predictable workloads | Bursty, unpredictable workloads |
Idle Cost | Yes – still billed when idle | None – no cost when idle |
Execution Limit | No hard limit | 15 minutes per invocation |
Takeaway
If your workload runs only a few minutes per day, keeping EC2 running 24/7 is like leaving your car engine on in the driveway just in case you need to drive.
Lambda lets you pay only when you drive.
For both AWS exam prep and real-world architecture, remember: sporadic workloads = serverless savings.