Sign in Get started

Python Serverless on AWS Lambda · Capstone Case Studies

Capstone: Serve a FastAPI Service on Lambda, or Not

Decide how to run an existing FastAPI service on AWS and plan the move with evidence.

Scenario

Example company: an internal platform team runs a FastAPI service (40 endpoints, PostgreSQL, Pydantic v2, SQLAlchemy) on two EC2 instances with gunicorn and uvicorn workers. Traffic: 5 requests per second on average, peaks of 150 requests per second for 20 minutes each morning, nearly zero at night. A few endpoints generate reports taking up to 90 seconds. The team wants less operations work and lower cost.

Requirements

  • p95 latency under 250 ms for normal endpoints; report endpoints may become asynchronous.
  • No change to the API contract for clients.
  • Zero-downtime migration with an easy rollback.

Constraints

  • PostgreSQL stays (RDS, 300 connections maximum).
  • The app imports pandas in a shared module used by every endpoint.
  • Two engineers, six weeks.

Deliverables

  1. A recommendation: Lambda (with Mangum or the Lambda Web Adapter), a container service (ECS Fargate or App Runner), or a hybrid, with the data you would use to decide.
  2. The code changes required (imports, connections, long requests, background tasks).
  3. A migration and rollback plan.
  4. Cost and performance expectations, and how you will verify them.

Hints

  • Spiky traffic with idle nights is a point in Lambda's favour; 90-second reports and a 300-connection limit are constraints to design around.
  • Cold starts depend heavily on what is imported at module level.

Draft each deliverable below before revealing the model answer and rubric.

Further reading: AWS Lambda Web Adapter · Amazon RDS Proxy

Deliverables

Make a recommendation and say how you would decide.

Model answer

  • Gather per-endpoint latency and duration distributions, requests per minute over a week, current EC2 and operations cost, and import-time profile (python -X importtime).
  • For this traffic shape (low average, short morning peak, idle nights) Lambda behind an HTTP API, using the Lambda Web Adapter (unchanged FastAPI app) is a strong option, with reports moved to asynchronous jobs. A container service is a valid alternative if the team prefers one long-running process model or if steady load grows.
  • Decide with a prototype measuring cold-start and warm latency, plus a cost model on real traffic.

Rubric

Strong answers tie the recommendation to measured traffic and latency, present the container option fairly, and treat reports separately.

List the code changes.

Model answer

  • Make pandas a lazy import inside report code only; check cold start with importtime.
  • Database: SQLAlchemy engine created at module level with a small pool (pool_size=1, pool_pre_ping=True) connecting through RDS Proxy; reserved concurrency so connections stay under 300.
  • Reports: POST /reports returns 202 with a job ID; a worker (SQS or Step Functions) writes the result to S3; GET /reports/{id} returns a presigned URL.
  • Replace FastAPI BackgroundTasks with queue messages; make startup work light and idempotent.

Rubric

Look for each long-lived-server assumption (heavy imports, pools, long requests, background tasks) being addressed concretely.

Plan the migration and rollback.

Model answer

  • Ship the code changes to the EC2 version first (lazy imports, async reports) and verify.
  • Deploy the Lambda version with its own stage; mirror or replay a sample of read traffic to compare responses and latency.
  • Shift traffic gradually with weighted DNS (or path routing), starting with read-only endpoints; keep EC2 running for instant rollback until metrics are stable for two weeks.

Rubric

Good plans change one thing at a time, compare with real traffic, and keep the old path warm for rollback.

Set cost and performance expectations.

Model answer

  • Expect warm p95 similar to EC2; cold starts affect the first requests of the morning peak, mitigated by smaller imports and, if needed, provisioned concurrency scheduled for the morning or SnapStart.
  • Cost: compute from measured requests and durations; with idle nights and a short peak, Lambda is likely cheaper than two always-on instances, but verify with the model.
  • Verify with dashboards comparing p95 per endpoint, error rates, cold-start share and monthly cost against the baseline.

Rubric

Look for explicit, measurable success criteria and an honest treatment of cold starts.

Open in the app to mark lessons complete, take notes and track your progress.