[proposal] Distribute the AWS Lambda Swift Runtime as a Lambda Layer

[sebsto]

Summary

Should we provide an AWS Lambda Layer to distribute the Swift runtime?

Background

AWS Lambda Layers allow for the distribution of dependencies and runtimes separately from the function code. This approach can simplify deployment, reduce package sizes, and improve maintainability.

Given the absence of ABI stability for Swift on Linux, each Swift version would require a separate binary layer. This introduces additional complexity but also offers potential benefits.

Benefits

Distributing the Swift runtime as a Lambda Layer would have the following advantages:

• Smaller Deployment Packages: Users would not need to bundle the Swift runtime with their function code, reducing package sizes and improving cold start performance.
• Simplified Deployment Process: Developers can reference the runtime layer directly, avoiding the need to manage runtime dependencies within their application package.
• Easier Updates: Updating the runtime version would require updating the layer reference rather than redeploying the entire function.
• Encourages Best Practices: Using a common runtime layer helps enforce consistency across Lambda functions within an organization.

Challenges & Considerations

This is a one-way door decision, meaning that once we commit to providing the Swift runtime as a Lambda Layer, we must maintain it reliably. Key challenges include:

• Multiple Versions: Each Swift version requires a separate binary layer due to the lack of ABI stability on Linux.
• Security & Trust: We must ensure the runtime layer is securely distributed, including:
  • Hosting it in a dedicated AWS Lambda account.
  • Signing and verifying the integrity of the layer to prevent supply chain attacks.
  • Adhering to AWS security best practices.
• Operational Overhead:
  • Managing multiple layers across different regions.
  • Providing clear documentation on how to use the layer.
  • Defining a deprecation policy for older versions.
• Telemetry & Monitoring:
  • Optionally, we could collect basic telemetry, similar to the Bref PHP Lambda framework ([reference](https://github.com/brefphp/bref/blob/55258b3c1cf9c763f1bf8ec7067d445b7bac63a4/docs/runtimes/runtimes-details.mdx#L118)).
  • Careful consideration must be given to privacy concerns and opt-in mechanisms.

Next Steps

• Gather feedback from the community on the need for a runtime layer.
• Define a strategy for building, hosting, and securing the runtime layers.
• Implement an initial proof of concept to validate feasibility.
• Define a release and maintenance strategy, including versioning policies.

Should we move forward with this approach? Feedback and discussion are welcome.