While preparing for the AWS SAP-C02, many candidates get confused by event-driven architecture patterns. In the real world, this is fundamentally a decision about idle compute cost vs. architectural complexity. Let’s drill into a simulated scenario.
The Scenario #
DataPulse Analytics, a financial modeling firm, operates a compliance data processing pipeline on AWS. Their current architecture uses a t3.medium EC2 instance running a Python script that:
- Executes every 10 minutes via cron
- Downloads CSV files from an S3 bucket (
s3://datapulse-compliance-inputs/) - Processes each file in approximately 5 minutes
- Maintains a DynamoDB table to track processed files and avoid reprocessing
After reviewing CloudWatch metrics, the infrastructure team discovered:
- CPU utilization averages 28% (60% during processing, 0% during idle periods)
- The instance is idle 40% of the time between processing cycles
- Monthly file volume is unpredictable (ranges from 200 to 2,000 files)
Leadership has mandated a redesign to achieve:
✅ High availability and elastic scalability
✅ Reduced operational overhead (fewer manual interventions)
✅ Cost optimization (eliminate idle resource waste)
Key Requirements #
Redesign the architecture to minimize Total Cost of Ownership (TCO) while ensuring event-driven responsiveness, high availability, and low operational burden.
The Options #
A) Migrate the Python script to an AWS Lambda function. Configure S3 Event Notifications to trigger the Lambda function automatically when new objects are uploaded.
B) Create an Amazon SQS queue and configure S3 to send event notifications to the queue. Deploy an EC2 Auto Scaling Group (minimum 1 instance) running the modified script to poll SQS and process messages.
C) Containerize the Python script using Docker and run it on the existing EC2 instance. Configure the container to poll the S3 bucket periodically for new objects.
D) Migrate the script to a container image and deploy it on Amazon ECS with AWS Fargate. Create a Lambda function that invokes the ECS RunTask API when files arrive, triggered by S3 Event Notifications.
Correct Answer #
Option A – AWS Lambda with S3 Event Notifications
Step-by-Step Winning Logic #
This solution achieves maximum cost efficiency by eliminating all idle compute costs while meeting every requirement:
🎯 Event-Driven Trigger: S3 Event Notifications invoke Lambda instantly when files arrive—no polling overhead, no wasted cycles.
💰 Pure Pay-Per-Use Model: You pay only for actual execution time (5 minutes per file). At 1,000 files/month:
- Lambda Cost: ~$8.50/month (5-min execution @ 1024MB memory)
- Eliminated EC2 Cost: ~$30/month (t3.medium On-Demand) + EBS volumes
⚡ Zero Operational Overhead:
- No EC2 patching, no OS management, no capacity planning
- AWS manages scaling automatically (up to 1,000 concurrent executions by default)
✅ High Availability by Default: Lambda runs across multiple AZs automatically—no ASG configuration needed.
📈 Elastic Scalability: Handles 200–2,000 files/month without code changes or capacity reservations.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
Why not Option B? (SQS + EC2 Auto Scaling) #
- ❌ Still incurs baseline EC2 costs (minimum 1 instance = ~$30/month + overhead)
- ❌ Higher operational complexity: Must manage ASG policies, CloudWatch alarms, instance lifecycle
- ❌ Slower scale-out: ASG takes 2–5 minutes to launch new instances during spikes
- ⚠️ Use case: Valid for workloads requiring persistent state or execution times > 15 minutes (Lambda’s max timeout)
Why not Option C? (Containerized Polling on EC2) #
- ❌ No cost improvement: Still runs 24/7 on a fixed-cost EC2 instance
- ❌ No high availability: Single instance = single point of failure
- ❌ Polling inefficiency: Continues to waste cycles checking for files that may not exist
- 🚫 Anti-pattern: Adds Docker complexity without solving the core problem
Why not Option D? (ECS Fargate + Lambda Trigger) #
- ❌ Over-engineered: Adds unnecessary complexity with two compute layers (Lambda + Fargate)
- ❌ Higher cost: Fargate charges per vCPU-hour (~$0.04048/vCPU-hour) + Lambda invocation costs
- ❌ Longer cold start: ECS task provisioning takes 30–60 seconds vs. Lambda’s 1–3 seconds
- ⚠️ Use case: Reserved for workloads requiring custom runtimes, GPU acceleration, or execution > 15 minutes
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
A[User Uploads File to S3] -->|S3 Event Notification| B[Amazon S3 Bucket]
B -->|Triggers| C[AWS Lambda Function]
C -->|Downloads| B
C -->|Processes CSV| D[Python Processing Logic]
D -->|Check Duplicate| E[DynamoDB Tracking Table]
E -->|Not Processed| D
D -->|Write Results| F[S3 Output Bucket]
C -->|Logs| G[CloudWatch Logs]
style C fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style B fill:#569A31,stroke:#232F3E,stroke-width:2px,color:#fff
style E fill:#4053D6,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: S3 Event Notifications trigger Lambda instantly upon file upload, eliminating polling overhead. DynamoDB ensures idempotent processing by tracking completed files.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) Lambda + S3 Events | Low | $8–$85 (scales with file count; 1K files ≈ $8.50) | ✅ Zero idle cost ✅ Auto-scaling ✅ No ops overhead |
⚠️ 15-min max execution ⚠️ Cold start latency (1–3s) |
| B) SQS + EC2 ASG | Medium-High | $150–$400 (1–4 instances @ $30/ea + SQS $0.40/1M requests) | ✅ Handles long tasks ✅ Persistent state |
❌ Baseline EC2 cost ❌ Complex scaling policies |
| C) Docker + EC2 Polling | Medium | $30–$50 (t3.medium + EBS) | ✅ Simple migration | ❌ No HA ❌ Still 40% idle ❌ No cost savings |
| D) Lambda + ECS Fargate | Very High | $120–$300 (Fargate tasks + Lambda invocations) | ✅ Custom runtime support | ❌ Over-engineered ❌ Slow cold start (30–60s) ❌ Higher cost than A |
FinOps Insight: Option A reduces monthly compute costs by 73–94% compared to the current EC2 baseline, with costs scaling linearly with actual workload (not time).
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the SAP-C02, when you see:
- “40% idle time” or “intermittent workload”
- “Cost-effective” + “High availability”
- “Reduce operational overhead”
→ Choose event-driven serverless (Lambda + S3/SQS/EventBridge) over persistent compute.
Real World #
In production environments, I’d also consider:
- Lambda Reserved Concurrency: If file spikes exceed 1,000 concurrent executions, reserve capacity to avoid throttling.
- Step Functions Integration: For complex multi-stage processing (e.g., file validation → transformation → quality checks), orchestrate Lambda functions via Step Functions.
- S3 Batch Operations: If dealing with backfills of 10,000+ existing files, use S3 Batch Operations to invoke Lambda at scale without overwhelming the function.
- Cost Anomaly Detection: Set up AWS Cost Anomaly Detection to alert if Lambda invocations suddenly spike (e.g., due to S3 versioning misconfiguration causing duplicate events).
Hybrid Consideration: For files requiring 10–30 minutes of processing, I’d use Lambda (up to 15 min) + SQS + Fargate Spot for overflow tasks, optimizing cost while avoiding Lambda’s timeout limit.