Is there any plan to support snapstart ?

[jaeyoung0509]

AWS SnapStart is a powerful feature that significantly reduces cold start latency for Python function.
However the current AWS chalice framework may not provide a native way to enable SnapStart.

chalice deploy command and the .chalice/config.json file lack a specific option to configure this feature

I was wondering if there are any plans or a roadmap to natively support SnapStart within chalice?

[jonathan343]

Hey @jaeyoung0509, I'd love to get support for snapstart added.

The main blocker right now is that we don't have support for versioning or aliases which are called out as a limitation in the AWS Lambda docs:

Note You can use SnapStart only on published function versions and aliases that point to versions. You can't use SnapStart on a function's unpublished version ($LATEST).

I'll be looking into getting support for these to added to unblock this. In the meantime, if you have feedback on what the optimal experience here is, I'll be happy to consider it!

[rokclimb15]

@jonathan343 I'm glad to contribute support for versioning/aliases if it will help move this along

[jonathan343]

Hey @rokclimb15, I'm happy to review any related contribution for this. However, I do have something working locally for a simple Chalice config that lets customers define an alias for Chalice to use. The idea would be that on deployment, Chalice will auto-version your Lambda function and point your alias to the latest version.

The current idea is something like:

# In .chalice/config.json

{
  "stages": {
    "prod": { "auto_alias": "myalias" }
  }
}

The prototype is working, however, I want to flesh out the customer experience and see if there is anything else I should make configurable. If you have any feedback that would be great. I'll try to get something up by tomorrow which you can take a look at.

[rokclimb15]

@jonathan343 I think the MVP to provide support for SnapStart should auto-alias based on the stage name (prod, dev, etc) rather than requiring configuration. The alias should be fed to dependencies like API Gateway so the deployment is always stable. Later features might include rollback, deployment with traffic shifting, and version promotion like chalice promote dev prod.

[jonathan343]

Thanks for the feedback. I opened #2173 with an initial version of the Lambda versioning/alias support.

The PR keeps aliasing explicit for now through a new lambda_alias config option, and wires Chalice-managed integrations like API Gateway and event sources to the alias when configured. For example, a stage can opt into a stage-named alias with:

{
  "stages": {
    "prod": {
      "lambda_alias": "prod"
    }
  }
}

I’d be interested in your feedback on whether that shape works as the lower-level deployment primitive before layering SnapStart-specific behavior on top.

[jaeyoung0509]

@jonathan343 Sorry for the late reply, and thanks a lot for the update — this is great news!

I took a quick look at #2173 and the proposed lambda_alias shape makes sense to me as the lower-level primitive before adding SnapStart-specific behavior.

I also agree with keeping aliasing explicit for now. Auto-aliasing by stage name would be convenient, but since it changes the deployment target from the unqualified function to an alias/versioned function, making that opt-in feels safer for existing Chalice users.

For the SnapStart layer later, I think either of these UX options could work nicely:

{
  "stages": {
    "prod": {
      "lambda_alias": "prod",
      "snap_start": true
    }
  }
}

or a more AWS-shaped config:

{
  "stages": {
    "prod": {
      "lambda_alias": "prod",
      "snap_start": {
        "apply_on": "PublishedVersions"
      }
    }
  }
}

The boolean version is simpler, while the object version is closer to the underlying Lambda API and may leave more room for future options.

If snap_start is enabled without lambda_alias, I’d personally prefer a clear validation error explaining that SnapStart requires a published version or alias, rather than silently changing the deployment target.

I’ll take a closer look at the PR and leave any more detailed feedback there if I notice anything useful. Thanks again for working on this!