The shared runtime identifier is the whole design [2]. A function you create this week on the preview identifier keeps that identifier through general availability; there is no template edit, no redeploy, no pipeline run at graduation [2]. That removes the tax that normally follows a preview, where you rewrite a runtime string across every stack and re-run every test suite to change nothing. It also removes the audit trail. Nothing in the function configuration changes at graduation, so there is no field to grep to answer "which of my functions are running a pre-release interpreter right now" [1].
Meanwhile the artifact under the handler moves. AWS applies upstream updates to the preview runtimes on the same schedule as any other supported runtime [6], and says breaking changes may occur during the preview because the language has not reached stable release and the Lambda team is still adding features and tuning performance [4]. The announcement channel for those changes is the per-language GitHub feedback issue [5]. That functions as a subscription rather than a control. The managed runtime identifier cannot be pinned, since it doubles as the GA identifier; only the ECR tag offers that option.
That asymmetry is worth reading twice. The base container images publish with tags starting 26-preview for Node.js and 3.15-preview for Python [7], so the container path carries an explicit preview marker in the artifact string while the managed path carries none [2]. If your compliance story depends on being able to see pre-release code in an inventory, the image tag is currently the only string that says so out loud.
On performance, AWS is refreshingly plain: at launch these are a straightforward version bump with no Lambda-specific enhancements beyond what the language version itself provides [8]. So whatever the upstream release notes promise belongs to upstream, and it transfers to your bill only if your functions actually spend their time on the thing upstream improved. No Lambda-side speedup is claimed, and not claiming one is the correct engineering answer for a runtime that is a version bump.
The parity claim is the part that makes this usable rather than a toy. AWS says every Lambda feature supported on current GA runtimes works on the previews, naming Lambda Managed Instances and durable functions [9], and the previews are live in all commercial Regions, GovCloud (US) and China Regions [3]. There is no staged rollout to blame if something behaves differently in one Region.
Context for my read: the compatibility bugs that hurt me on a language upgrade are almost never in the interpreter. They are in observability agents, native modules, and IaC providers that have not been rebuilt yet, which is exactly the constituency AWS says the preview window exists to serve [13]. So I would take this, in a non-production account, wired to a canary and to the GitHub issue, and I would keep it off any customer request path until GA. "Breaking changes may occur" [4] is a statement about my next deploy as much as about AWS's.
Worth noting what AWS admits it is buying with this. Historically it validated runtimes with internal testing and pre-release benchmarking, and some issues surfaced only after GA, when the scope to fix them had already narrowed because production workloads were on it [12]. This track trades a narrow blast radius for a wider one, on purpose, and calls itself an experiment [11].</body_markdown> </invoke>
