In an AWS Lambda function, why do you create SDK clients and database connections outside the handler, and what kind of state must never be cached there?

## Two scopes, two lifetimes A Lambda module has two regions of code with very different lifetimes. **Initialization scope** — everything outside the handler — executes once, during the Init phase, when Lambda builds a new execution environment. **Handler scope** executes once per invocation. Because Lambda freezes rather than destroys the environment after a response, whatever initialization scope left in memory is still there when the next event arrives. ```python import boto3, os # Init scope: runs once per environment s3 = boto3.client("s3") BUCKET = os.environ["BUCKET"] def handler(event, context): # Invoke scope: runs once per request return s3.get_object(Bucket=BUCKET, Key=event["key"]) ``` That one property is the whole optimisation. Constructing an AWS SDK client is not free — it resolves configuration, sets up credential providers, and builds an HTTP connection pool. Doing it inside the handler repeats that on every request and, worse, throws away the warm TLS connections you already paid to establish. Hoisting it moves the cost into Init, where a warm environment pays it zero times. ## What genuinely belongs in Init scope - **SDK and HTTP clients**, so keep-alive connections are reused across invocations. - **Configuration** read from environment variables, and any parsing or validation of it. - **Secrets and parameters** fetched once from Secrets Manager or Parameter Store, so you make one API call per environment instead of one per request. Cache them with a TTL — an environment can live long enough to outlast a rotation. - **Expensive constants**: compiled regexes, loaded ML feature maps, schema objects, template compilations. ## What must never live there The hazard is that this memory is shared by every invocation that environment serves, and those invocations belong to *different callers*. Anything request-scoped stored globally leaks across request boundaries: ```javascript let currentUser; // BUG: survives into the next request export const handler = async (event) => { currentUser = event.user ?? currentUser; // stale value on the next invocation return fetchOrdersFor(currentUser); }; ``` Under low concurrency this passes every test — one environment, one request at a time, so the value looks right. In production, the second caller routed to that environment inherits the first caller's identity. This class of bug is severe (a cross-tenant data leak) and nearly invisible in local testing. The same applies to accumulators (an array you push results into and never clear grows until the environment OOMs), to mutable client state you reconfigure per request, and to files you write into `/tmp`, which is per-environment and also reused. A useful discipline: initialization scope is **immutable after Init**, except for caches whose contents are safe for any caller. ## Freeze, thaw, and unfinished work Freezing suspends the environment the moment your handler returns. Background work you started but did not await does not keep running — it is paused, and it may resume mid-way through some *later* invocation, producing baffling interleaving. In Node.js the historical trap is `context.callbackWaitsForEmptyEventLoop`, which defaults to `true`, so Lambda waits for the event loop to drain; setting it to `false` returns immediately and leaves pending work in limbo. Either way, the discipline is the same: await everything you care about before returning. ## Concurrency and the limits of caching There is no shared cache across environments. If 200 environments are live, an in-memory cache is populated 200 separate times and each copy can hold a different value. That makes global caching fine for slow-changing data (configuration, a signing key, a feature-flag snapshot) and wrong for anything requiring coherence. When invalidation matters, put the data in an external store and let each environment cache it briefly. Also note that because one environment handles one invocation at a time, code inside a single environment is not racing against a concurrent invocation in the same memory space. That is a genuine simplification — but it does not make globals safe, because the danger is *sequential* leakage between different callers, not simultaneous access. ## Connection pools A pooled database client in Init scope is right in spirit but has an AWS-specific catch: each environment holds its own pool, so peak connections scale with concurrency, not with request rate. A hundred environments with a pool of ten each is a thousand connections against a database sized for far fewer. Keep the per-environment pool size small — often one — and put a proxy in front when the backing database has a hard connection ceiling.