Driver 01
Cold-start latency
Cold starts on latency-sensitive endpoints, especially with large packages or VPC networking.
Migration playbook: AWS Lambda → Cloud Run / ECS Fargate
AWS Lambda to containers on Cloud Run or Fargate
Move functions that have outgrown Lambda — long jobs, latency-sensitive APIs, complex local setups — into standard containers on Cloud Run or ECS Fargate.
Migration drivers
Why teams make this move
Driver 02
15-minute execution limit
Data processing, transcoding or AI jobs that can't finish within Lambda's 15-minute maximum.
Driver 03
Local development
Multi-function architectures that are hard to run locally without fragile mocks.
Execution sequence
How the migration runs
Each phase ends with a check you can verify — data parity, error rates, latency — and the rollback path is agreed before any traffic moves.
- 01Phase
Containers and HTTP entry points
Packaging functions as Docker containers running a lightweight HTTP server (for example Fastify or Axum).
- 02Phase
Cloud Run or ECS services
Deploying autoscaling services, with minimum instances to keep latency-sensitive endpoints warm.
- 03Phase
Event triggers and queues
Translating EventBridge and SQS triggers to Cloud Tasks, Pub/Sub or Kafka consumers.
- 04Phase
Traffic migration
Shifting API traffic to the new endpoints gradually, with the Lambda path kept as a fallback.
Risk prevention
Pitfalls that derail this migration
Risk 01
Too many minimum instances
Setting minimum instances high on low-traffic services, which adds idle cost.
Risk 02
Ignoring SIGTERM
Not handling SIGTERM, so in-flight requests are cut off when instances scale down.
Risk 03
Undersized memory
Allocating too little memory, which causes restarts under load.
Before and after
What we measure
We take a baseline before any change and report the same numbers after cutover, from your own tools. They are the evidence of whether the migration worked — not figures promised in advance.
- p95 latency
- Key endpoints, including the first request after idle
- Monthly cost
- Lambda bill vs container bill for the same traffic
- Longest job
- Runtime of the longest job, now free of the 15-minute limit
Questions
Frequently asked migration questions
Yes. With request-based billing you pay nothing while it is idle, and instances start on demand — the first request after idle pays a cold start unless you keep a minimum instance warm.
A Lambda execution environment handles one request at a time; a Cloud Run instance can handle many at once (up to 1,000, configurable), so I/O-bound services need far fewer instances.
Rehearse the cutover before the real one
Tell us about your data volume, traffic and timeline. An engineer will reply within one business day to set up a call about the migration plan and its rollback path.