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

Recommended configuration

Use one module-level async SQLAlchemy engine with pool_pre_ping=True and pool_recycle set below your Aurora wait_timeout. Do not create a new NullPool engine inside each handler for sporadic traffic, and do not rely on FastAPI lifespan shutdown to dispose the pool. Provisioned concurrency reduces cold starts but does not remove the need for pre_ping and recycle.

Likely explanation

After an idle pause longer than wait_timeout, Aurora may close a pooled connection. The next warm Lambda invocation checks out that dead connection unless SQLAlchemy validates it first. pool_pre_ping catches the stale connection with one validation query; pool_recycle only shrinks the stale window and cannot prevent a death between recycle and checkout.

Confirmed facts and assumptions

• Confirmed: Lambda execution environments may be reused across invocations, so module-level objects persist during warm invocations.
• Confirmed: Lambda container termination can skip FastAPI lifespan shutdown; do not depend on it for pool disposal.
• Confirmed: SQLAlchemy pool_pre_ping validates a connection before checkout; pool_recycle disposes connections older than the configured seconds.
• Assumption: Aurora Serverless v2 wait_timeout defaults to 300 seconds. Verify this in your DB parameter group before choosing pool_recycle.
• Assumption: Mangum reuses the same FastAPI application instance across warm invocations; behavior can vary by adapter version.

Steps for this case

1. Create the engine at module level, outside the handler and outside lifespan:

from sqlalchemy.ext.asyncio import create_async_engine, async_sessionmaker

engine = create_async_engine(
    DATABASE_URL,
    pool_pre_ping=True,
    pool_recycle=240,  # set below your Aurora wait_timeout; 240 is an example only
    pool_size=5,
    max_overflow=10,
)

session_factory = async_sessionmaker(engine, expire_on_commit=False)

1. Use a FastAPI dependency that yields a session and closes it in finally. Do not call await engine.dispose() per request or in shutdown.
2. Confirm wait_timeout in the Aurora parameter group. If it is not 300 seconds, set pool_recycle at least 20–60 seconds below it.
3. Log the first request after an idle window longer than wait_timeout. Watch for MySQL server has gone away and elevated checkout latency from pre_ping.

Provisioned concurrency and RDS Proxy

Provisioned concurrency keeps environments initialized and shortens idle gaps, which lowers the chance that a pooled connection sits idle past wait_timeout. It does not eliminate staleness if idle periods still exceed the timeout, so keep pool_pre_ping and pool_recycle. Enable it only if the hourly idle cost is justified by fewer cold starts.

RDS Proxy can mask stale connections and smooth connection spikes, but it adds a proxy hop and separate cost. For low-traffic sporadic workloads, a tuned module-level pool is usually cheaper and simpler.

Missing diagnostic detail

What is wait_timeout in your Aurora DB parameter group? The exact pool_recycle value depends on it; do not use 240 or 280 without confirming the server timeout.

Verification

• Compare first-request latency and error rate after idle periods longer than wait_timeout against the warm-request baseline.
• If you test per-invocation NullPool, measure new-connection rate and TCP/SSL handshake time in CloudWatch Logs or X-Ray; expect higher latency than the tuned pool.
• Do not treat lifespan shutdown logs as proof of cleanup; Lambda can terminate the container without invoking shutdown.