You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* chore: point lambda_http at SnapStart-enabled runtime branch
* feat: add SnapStart hook-path environment variables
* test: merge SnapStart env-var tests to avoid parallel race
* refactor: extract build_client() and drop SnapStart pool special-case
* feat: add swappable restored_client with write-once OnceLock
* refactor: return BoxBody<Bytes, Error> from fetch_response
* feat: reject external requests to SnapStart hook paths with 403
* feat: add SnapStartHooks bridging restore lifecycle to inner app
* feat: register SnapStart resource in adapter run loop
* docs: document SnapStart hook environment variables
* docs(guide): add SnapStart feature page and env vars
* docs: add fastapi-snapstart-zip example
* docs: link fastapi-snapstart example from README
* docs: drop /lwa prefix from SnapStart example hook paths
* refactor: extract register_and_run helper to dedup run() arms
* feat: add 60s timeout to SnapStart inner-app hooks
* feat: re-run readiness check after SnapStart restore
* docs: add fastapi-snapstart (OCI) example
* refactor: move SnapStart hook env vars to SAM template in OCI example
* chore: point OCI example at 1.1.0 SnapStart-enabled adapter image
* chore: use public ECR adapter image in OCI SnapStart example
* docs: correct after-restore step ordering in OCI example README
* docs: correct after-restore step ordering in zip example README
* docs: fix incorrect AWS_LAMBDA_INITIALIZATION_TYPE claim in snapstart guide
* chore: use released lambda_http 1.3.0 with SnapStart support
Switch from the git-branch dependency to the published lambda_http/lambda_runtime
1.3.0 from crates.io, removing the release blocker. Also fix the integration test
body-reader helpers to accept the BoxBody response type, and resolve a clippy
ok().expect() lint.
* docs: add SnapStart to README features list
* fix: reseed RNG in after-restore hook so restored envs get unique ids
[Lambda SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html) snapshots an initialized execution environment and restores it on later cold starts, reducing startup latency. Because the adapter runs your web application as a separate process, the application does not have direct access to the SnapStart lifecycle. The adapter bridges this gap with two optional HTTP hooks.
4
+
5
+
## Hooks
6
+
7
+
| Variable | When the adapter calls it | Use it to |
|`AWS_LWA_SNAPSTART_BEFORE_CHECKPOINT_PATH`| Before the snapshot is taken | Drain or close resources that will not survive the snapshot |
10
+
|`AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH`| After restore, before serving traffic | Reconnect, refresh credentials, reseed randomness, regenerate unique identifiers |
11
+
12
+
Both hooks are opt-in and independent — each fires only when its variable is set.
13
+
14
+
## How it works
15
+
16
+
The adapter always registers for the SnapStart lifecycle; the Lambda runtime invokes the hooks only when your function runs under SnapStart. When it does, the adapter participates as follows:
17
+
18
+
1.**Before checkpoint** — if `AWS_LWA_SNAPSTART_BEFORE_CHECKPOINT_PATH` is set, the adapter sends an empty `POST` to that path on your application, then signals Lambda that it is ready for the snapshot.
19
+
2.**After restore** — Lambda restores the environment. The adapter first refreshes its own HTTP connection to your application (so it never reuses a connection captured in the snapshot); then, if `AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH` is set, sends an empty `POST` to that path; and finally re-runs the readiness check before admitting traffic.
20
+
21
+
Each hook is an empty `POST`, and your application must respond with a `2xx` status. A non-`2xx` response, a connection failure, or taking longer than 60 seconds to respond fails the SnapStart phase — initialization for the before-checkpoint hook, restore for the after-restore hook — rather than serving traffic against an improperly prepared application. The final readiness check runs on every restore (whether or not an after-restore path is configured); if your application does not report ready within 10 seconds of restore, the restore fails.
22
+
23
+
## Why you need the hooks
24
+
25
+
State captured in a snapshot is shared across every restored environment. Two classes of problem follow:
26
+
27
+
-**Stale connections.** Database connections, cached DNS, and keep-alive HTTP connections captured in the snapshot are dead by the time the environment is restored. Close them in the before-checkpoint hook and re-establish them in the after-restore hook.
28
+
-**Uniqueness and entropy.** Values seeded once at initialization — random number generators, UUID seeds, security tokens — become identical across every restored environment. Reseed them in the after-restore hook.
29
+
30
+
## Securing the hook paths
31
+
32
+
The hook paths are control-plane operations. External requests (via API Gateway or ALB) that target a configured hook path receive `403 Forbidden` and are never forwarded to your application. The guard matches the exact configured path, so choose paths your normal application traffic does not use (for example, `/snapstart/before` and `/snapstart/after`).
33
+
34
+
## Example
35
+
36
+
```python
37
+
from fastapi import FastAPI, Response
38
+
39
+
app = FastAPI()
40
+
pool =None# your database/connection pool
41
+
42
+
43
+
@app.post("/snapstart/before")
44
+
asyncdefbefore_checkpoint():
45
+
# Close resources that won't survive the snapshot.
46
+
if pool isnotNone:
47
+
await pool.close()
48
+
return Response(status_code=200)
49
+
50
+
51
+
@app.post("/snapstart/after")
52
+
asyncdefafter_restore():
53
+
# Re-establish resources and reseed anything that must be unique.
See the [fastapi-snapstart-zip example](https://github.com/aws/aws-lambda-web-adapter/tree/main/examples/fastapi-snapstart-zip) for a complete, deployable application.
0 commit comments