FastAPI + Mangum on AWS Lambda: SQLAlchemy connection pool lifecycle during container reuse

Context

A FastAPI application runs on AWS Lambda via the Mangum ASGI adapter with an async SQLAlchemy engine connected to Aurora Serverless v2. The engine is created at module level and its connection pool persists across warm Lambda invocations because Mangum reuses the same application instance.

Goal

Ensure the first request after an idle period (cold container reuse) succeeds without "MySQL server has gone away" errors, while keeping per-invocation latency and database connection overhead low for a low-traffic workload.

Constraints and uncertainty

SQLAlchemy's pool_pre_ping validates connections before checkout, yet Aurora's wait_timeout (default 300 seconds for Serverless v2) can expire idle pooled connections during Lambda's scale-to-zero pauses. Setting pool_recycle below the database timeout prevents stale checkouts but does not eliminate the validation round-trip on the first request after reuse. An alternative is creating a fresh engine with NullPool inside each handler invocation, which guarantees clean connections at the cost of a new TCP/SSL handshake per request. Background tasks scheduled after the response may be truncated when the container freezes, so they cannot reliably clean up or refresh pools.

Which pool configuration—module-level engine with tuned pool_recycle and pool_pre_ping, per-invocation NullPool engine, or offloading pooling to RDS Proxy—provides the most predictable latency and cost profile for sporadic traffic? How should the FastAPI lifespan shutdown hook be structured (or omitted) given that Lambda may terminate containers without invoking it? Does enabling provisioned concurrency meaningfully change the pool-staleness risk compared to pure on-demand scaling?