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 from 1.4s to 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 from 1.4s to 210ms
- An early LMI move on spiky traffic wasted ~$3.2k in idle capacity provider hours
- Lambda Managed Instances (LMI) lets functions run on selected EC2 instance types with Lambda’s programming model
- It suits 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

Table of Contents
Lambda Managed Instances (LMI) lets functions run on selected EC2 instance types with Lambda’s programming model. It suits 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 does not cover general refactor/replatform/rearchitect, scale-in-place before decomposition, ECS Fargate zero-downtime migration, or the LMI operations guide.
Artifacts: compute-path matrix, strangler checklist, architecture diagram (draw.io).
Strangler sequence
- Map top endpoints by RPS × change frequency
- Extract one capability behind API Gateway
- Anti-corruption layer to shared data, with 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 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 and 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.




