The Moment Everything Clicked
Three years ago, I was leading a migration project for a Fortune 500 financial services company. We had a legacy monolith that required 47 EC2 instances running 24/7 to handle peak loads that occurred for about 2 hours per day. The rest of the time? Those servers sat mostly idle, burning through budget.
That's when I started seriously exploring AWS Lambda. Not because it was trendy, but because the economics made no sense any other way.
What I Got Wrong Initially
My first mistake was treating Lambda as just "smaller servers." I lifted code directly from our monolith, wrapped it in handlers, and deployed. The results were... disappointing. Cold starts made our APIs sluggish. Costs actually went up because I hadn't understood the pricing model.
The breakthrough came when I stopped thinking about servers entirely and started thinking about events and reactions. What triggers this code? What's the smallest unit of work? How do these pieces communicate?
The Mental Model That Works
Serverless architecture isn't about technology—it's about decomposition. Here's how I now approach any new project:
First, map the events. Every system responds to something: an HTTP request, a file upload, a database change, a scheduled time. List them all.
Second, define the reactions. For each event, what's the minimum work needed? Not "what does the current system do" but "what actually needs to happen."
Third, identify the state. Where does data need to persist? DynamoDB for low-latency access, S3 for objects, RDS if you truly need relational queries (but question this assumption).
When Serverless Is the Wrong Choice
I've also learned when to say no. Long-running processes that exceed 15 minutes. Workloads with consistent, predictable high traffic (EC2 Reserved Instances are cheaper). Applications requiring persistent connections like WebSockets at scale. GPU-intensive ML inference.
The key is matching the architecture to the workload pattern, not forcing everything into one paradigm.
The Results That Matter
For that financial services client, the final serverless architecture handled the same peak load with zero provisioned compute. Monthly costs dropped 73%. But more importantly, deployment velocity increased 10x because teams could ship individual functions without coordinating monolith releases.
That's the real win: not just efficiency, but agility.
Practical Starting Points
If you're exploring serverless, start with these low-risk opportunities:
Event-driven background jobs like image processing, report generation, or data transformation. API endpoints with variable traffic patterns. Scheduled tasks replacing cron jobs on EC2. Fan-out processing for batch operations.
Build confidence with these patterns before attempting to serverless your core business logic.