Serverless Application Modernization Playbook (2026): Strangler, Lambda, LMI, and Event Seams
Quick summary: For a .NET monolith (~220 endpoints, ~$28k/mo EC2), strangling 14 endpoints to Lambda cut p95 on those routes 1.4s → 210ms — an early LMI move on spiky traffic wasted ~$3.2k in idle capacity provider hours.
Key Takeaways
- NET monolith (~220 endpoints, ~$28k/mo EC2), strangling 14 endpoints to Lambda cut p95 on those routes 1
- 4s → 210ms — an early LMI move on spiky traffic wasted ~$3
- 2k in idle capacity provider hours
- Most modernization programs still start with standard Lambda and event seams, not a fleet of capacity providers
- This is the serverless modernization playbook
Table of Contents
Lambda Managed Instances (LMI) lets functions run on selected EC2 instance types with Lambda’s programming model — useful for steady, high-performance workloads that need specialized compute or EC2 pricing models (LMI launch coverage, ICYMI). Most modernization programs still start with standard Lambda and event seams, not a fleet of capacity providers.
This is the serverless modernization playbook. It is not general refactor/replatform/rearchitect, not scale-in-place before decomposition, not ECS Fargate zero-downtime migration, and not the LMI operations guide.
Artifacts: compute-path matrix, strangler checklist, architecture diagram (draw.io).
Benchmark silhouette (not a cited client) — .NET Framework monolith, ~220 endpoints, ~$28k/mo EC2+ALB, change lead time ~12 days. Strangled 14 high-churn endpoints to API Gateway + Lambda: those routes p95 1.4s → 210ms, deploy lead time same day. Premature LMI on a spiky reporting endpoint left capacity providers warm: ~$3.2k idle in a month — moved back to standard Lambda. Lesson: traffic shape picks compute, not fashion.
Strangler sequence
- Map top endpoints by RPS × change frequency
- Extract one capability behind API Gateway
- Anti-corruption layer to shared data — no casual dual-write
- Publish domain events to EventBridge
- Retire monolith path within 30 days of 100% traffic
Opinionated take: Prefer standard Lambda for the first three extracts. Introduce LMI only when metrics show steady concurrency and EC2 economics win — then read the LMI ops guide.
Compute path
Use compute-path-decision-matrix.md:
| Shape | Pick |
|---|---|
| Spiky, event-driven | Standard Lambda |
| Steady high RPS / special EC2 | LMI |
| Container service | ECS Fargate / Express Mode |
| Still meeting SLOs, data-bound | Scale in place first |
Reference flow
Monolith (remaining)
│
├── unchanged routes
│
└── strangled routes ──► API Gateway ──► Lambda or LMI
│
├── Aurora / DynamoDB (owned tables)
└── EventBridge ──► SQS consumersWhat broke — LMI on spiky traffic
What broke — Reporting extract moved to LMI in week 2 because “we might need Graviton4.” Traffic was weekday 9–11 only. Capacity provider hours stayed warm. Detection: Cost Explorer + capacity provider metrics. Fix: return to standard Lambda; revisit LMI when p95 concurrency stays high >12 hours/day for two weeks.
What to Do This Week
- Complete the strangler checklist Week 0 section.
- Pick one endpoint; ship behind a flag.
- Score Lambda vs LMI vs Fargate with the matrix — write the choice in the PR.
- If the monolith is still fine on SLOs, read scale-in-place before a rewrite program.
What This Post Doesn’t Cover
- Full ECS/EKS platform builds
- LMI capacity provider operations (dedicated post)
- Mainframe or packaged ERP exits
- GenAI/agent rewrites of business logic
Frequently asked questions
When should we NOT rewrite to serverless?
Lambda vs Lambda Managed Instances vs Fargate?
What could go wrong with strangler extracts?
How is this different from the general modernization refactor post?
How is this different from the LMI operations guide?
Should we extract everything to Step Functions?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
