Content deleted Content added
(3 intermediate revisions by the same user not shown) | |||
Line 11:
'''AWS Lambda''' is an [[event-driven programming|event-driven]], [[Serverless computing|serverless]] [[Function as a service|Function as a Service]] (FaaS) provided by [[Amazon.com|Amazon]] as a part of [[Amazon Web Services]]. It is designed to enable developers to run code without provisioning or managing servers. It executes code in response to [[Event (computing)|events]] and automatically manages the computing resources required by that code. It was introduced on November 13, 2014. <ref>{{Cite book |title=Serverless Development on AWS Building Enterprise-Scale Serverless Solutions |date=23 January 2024 |publisher=O'Reilly Media |isbn=9781098141899}}</ref>
== Specification ==
Each AWS Lambda instance runs within a lightweight, isolated environment powered by [[Firecracker (software)|Firecracker]] microVMs. These microVMs are initialized with a runtime environment based on [[Amazon Linux]] (Amazon Linux AMI or Amazon Linux 2), a custom Linux distribution developed by AWS. Firecracker provides hardware-virtualization-based isolation, aiming to achieve near-bare-metal performance with minimal overhead. AWS claims that, unlike traditional virtual machines, these microVMs launch in milliseconds, enabling rapid and secure function execution with a minimal memory footprint. The Amazon Linux AMI is specifically optimized for cloud-native and serverless workloads, aiming to provide a lightweight, secure, and performant runtime environment. <ref>{{Cite book |title=Accelerating Server-Side Development with Fastify: A comprehensive guide to API development for building a scalable backend for your web apps |isbn=9781800568747 |last1=Spigolon |first1=Manuel |last2=Sinik |first2=Maksim |last3=Collina |first3=Matteo |date=9 June 2023 |publisher=Packt Publishing }}</ref><ref>{{Cite web |title=Firecracker – Lightweight Virtualization for Serverless Computing |url=https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ }}</ref><ref>{{Cite web |title=Secure and fast microVMs for serverless computing |url=https://firecracker-microvm.github.io/ }}</ref>
{{As of|2025}}, AWS Lambda supports [[Node.js]], [[Python (programming language)|Python]], [[Java (programming language)|Java]], [[Go (programming language)|Go]], [[.NET]], [[Ruby (programming language)|Ruby]] and custom runtimes.<ref>{{Cite web |title=Lambda runtimes |url=https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html }}</ref>
== Cold Start Performance and Deployment Considerations ==
Rust and Go generally exhibit lower cold start times in AWS Lambda compared to Java and C# <ref>{{Cite web |date=2023-04-13 |title=Optimizing AWS Lambda extensions in C# and Rust {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/optimizing-aws-lambda-extensions-in-c-and-rust/ |access-date=2025-03-20 |website=aws.amazon.com |language=en-US}}</ref>because they compile to native static binaries, eliminating the need for a virtual machine (JVM or .NET CLR) and reducing runtime initialization overhead. Go has some minimal runtime initialization, including garbage collection and goroutine management, but its impact on cold start time is relatively low. Rust, which is fully ahead-of-time (AOT) compiled and does not require a runtime, often achieves the lowest cold start latency among supported languages. <ref name=":9">{{Cite book |last=Chapin |first=John |title=Programming AWS Lambda: build and deploy serverless applications with Java |last2=Roberts |first2=Mike |date=2020 |publisher=O'Reilly |isbn=978-1-4920-4102-3 |___location=Beijing Boston Farnham Sebastopol Tokyo}}</ref><ref name=":6" /><ref>{{Cite web |date=2021-04-26 |title=Operating Lambda: Performance optimization – Part 1 {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/ |access-date=2025-03-20 |website=aws.amazon.com |language=en-US}}</ref><ref>{{Cite web |title=Understanding the Lambda execution environment lifecycle - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |title=Define Lambda function handler in Rust - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/rust-handler.html#rust-best-practices |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |title=Define Lambda function handlers in Go - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html#go-best-practices |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref>
Java and C# run on managed runtime environments, introducing additional cold start latency due to runtime initialization and Just-In-Time (JIT) compilation. However, modern optimizations have mitigated some of these challenges. .NET 7 and .NET 8 support Ahead-of-Time (AOT) compilation, reducing cold start times by precompiling code. <ref>{{Cite web |title=Building .NET Lambda functions with Native AOT compilation in AWS SAM - AWS Serverless Application Model |url=https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/build-dotnet7.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |date=2024-02-22 |title=Introducing the .NET 8 runtime for AWS Lambda {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/introducing-the-net-8-runtime-for-aws-lambda/ |access-date=2025-03-20 |website=aws.amazon.com |language=en-US}}</ref> Additionally, AWS Lambda SnapStart for Java 11 and 17 pre-warms and snapshots execution state, significantly decreasing cold start overhead for Java-based functions. <ref>{{Cite web |date=2022-11-29 |title=Reducing Java cold starts on AWS Lambda functions with SnapStart {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/reducing-java-cold-starts-on-aws-lambda-functions-with-snapstart/ |access-date=2025-03-20 |website=aws.amazon.com |language=en-US}}</ref><ref>{{Cite web |title=Improving startup performance with Lambda SnapStart - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref> Despite these optimizations, Rust and Go typically maintain lower cold start times due to their minimal runtime dependencies. <ref name=":9" /><ref name=":6" />
In long-running workloads, JIT compilation in Java and .NET may improve execution speed through dynamic optimizations. However, this benefit is workload-dependent, and Rust’s AOT compilation often provides better performance consistency, particularly for CPU-bound tasks. <ref>{{Cite web |title=Compile .NET Lambda function code to a native runtime format - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/dotnet-native-aot.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref> For short-lived Lambda invocations, Rust and Go generally maintain more predictable performance, as JIT optimizations may not have sufficient time to take effect. <ref name=":6" /><ref>{{Cite web |title=Customize Java runtime startup behavior for Lambda functions - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/java-customization.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref>
Historically, Rust and Go required additional effort in deployment due to cross-compilation and static linking challenges. Rust, in particular, often necessitates MUSL-based static linking for AWS Lambda compatibility. However, advancements in deployment tooling, including AWS Serverless Application Model (AWS SAM), GitHub Actions, and Lambda container images, have simplified this process. Go benefits from native static linking support, making its deployment process comparatively straightforward. AWS Lambda's support for container images further reduces runtime compatibility concerns, enabling the use of custom runtimes and dependencies. <ref name=":9" /><ref name=":6" /><ref>{{Cite web |title=Building Lambda functions with Rust - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/lambda-rust.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |title=Building Rust Lambda functions with Cargo Lambda in AWS SAM - AWS Serverless Application Model |url=https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/building-rust.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |title=Generate a starter CI/CD pipeline with AWS SAM - AWS Serverless Application Model |url=https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-generating-example-ci-cd.html |access-date=2025-03-20 |website=docs.aws.amazon.com}}</ref><ref>{{Cite web |date=2022-01-24 |title=Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-to-arm-based-aws-graviton2-processors/ |access-date=2025-03-20 |website=aws.amazon.com |language=en-US}}</ref>
==Features==
=== Concurrency Models ===
Reserved Concurrency sets a maximum number of concurrent executions for a specific function and reserves that capacity from the account’s overall concurrency limit. However, it does not keep execution environments initialized or guarantee that any instances remain running when the function is idle.<ref>{{Cite web |title=Configuring reserved concurrency for a function - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html |access-date=2025-04-08 |website=docs.aws.amazon.com}}</ref>
Provisioned Concurrency, in contrast, maintains a specified number of pre-initialized execution environments, ensuring that the function does not experience cold starts and does not scale down to zero.<ref>{{Cite web |title=Configuring provisioned concurrency for a function - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html |access-date=2025-04-08 |website=docs.aws.amazon.com}}</ref>
=== Lambda Function URL ===
The Lambda Function URL gives Lambda a unique and permanent [[URL]] which can be accessed by [[authenticated]] and non-authenticated users alike.<ref name=":0">{{Cite web |title=Lambda function URLs - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html |access-date=2024-03-01 |website=docs.aws.amazon.com |archive-date=2024-03-01 |archive-url=https://web.archive.org/web/20240301105416/https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html |url-status=live }}</ref>
Line 32 ⟶ 46:
==Portability==
Migration from AWS Lambda to other AWS compute services, such as Amazon ECS, presents challenges due to tight integration with AWS Lambda's APIs, often referred to as service lock-in. <ref name=":7" /><ref name=":8" /> Tools like AWS Lambda Web Adapter offer a pathway for [[Software portability|portability]] by enabling developers to build web applications using familiar frameworks under a monolithic Lambda design pattern.<ref name=":7">{{Cite web |title=AWS Lambda Web Adapter |website=[[GitHub]] |url=https://github.com/awslabs/aws-lambda-web-adapter |url-status=live |archive-url=https://web.archive.org/web/20241128211006/https://github.com/awslabs/aws-lambda-web-adapter |archive-date=2024-11-28 |access-date=2024-11-29}}</ref><ref name=":8">{{Cite web |title=The Lambda monolith |url=https://docs.aws.amazon.com/lambda/latest/dg/monolith.html |url-status=live |archive-url=https://web.archive.org/web/20241126020340/https://docs.aws.amazon.com/lambda/latest/dg/monolith.html |archive-date=2024-11-26 |access-date=2024-11-29}}</ref> However, this approach introduces limitations, including coarser-grained alerting and access controls, potential cold start delays with large dependencies, and limited suitability for non-HTTP APIs. <ref name=":6" />
==Tools==
AWS Lambda Powertools is an open-source library developed by AWS that provides utilities for observability, tracing, and logging in AWS Lambda functions.<ref>{{Cite web |date=2020-06-22 |title=Simplifying serverless best practices with Lambda Powertools {{!}} AWS Open Source Blog |url=https://aws.amazon.com/blogs/opensource/simplifying-serverless-best-practices-with-lambda-powertools/ |access-date=2025-03-22 |website=aws.amazon.com |language=en-US}}</ref> It includes structured logging, metrics, and tracing tools for Python, Java, and TypeScript. As of March 2025, it also includes data masking support for Python. <ref>{{Cite web |title=Homepage - Powertools for AWS Lambda (Python) |url=https://docs.powertools.aws.dev/lambda/python/latest/ |access-date=2025-03-22 |website=docs.powertools.aws.dev}}</ref><ref>{{Cite web |title=Data Masking - Powertools for AWS Lambda (Python) |url=https://docs.powertools.aws.dev/lambda/python/latest/utilities/data_masking/ |access-date=2025-03-22 |website=docs.powertools.aws.dev}}</ref>
== Threading and Scalability in AWS Lambda ==
|