Content deleted Content added
m Removed an unnecessary section |
|||
| (39 intermediate revisions by 9 users not shown) | |||
Line 1:
{{Short description|Serverless computing platform}}
{{Infobox software
| name = AWS Lambda
Line 10 ⟶ 9:
}}
'''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>{{
== 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" />
▲==Specification==
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>
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
AWS Lambda layer is a ZIP archive containing libraries, frameworks or custom code that can be added to AWS Lambda functions. <ref>{{Cite web |title=Managing Lambda dependencies with layers |url=https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html |url-status=live |access-date=2024-02-02 |archive-date=2024-02-04 |archive-url=https://web.archive.org/web/20240204142231/https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html }}</ref> As of December 2024, AWS Lambda layers have significant limitations: <ref name=":6">{{Cite book |last=Cui |first=Yan |title=Serverless Architectures on AWS: With examples using AWS Lambda |date=17 April 2017 |publisher=Simon and Schuster |isbn=9781638351146}}</ref><ref>{{Cite book |title=Data Engineering with AWS: Learn how to design and build cloud-based data transformation pipelines using AWS |isbn=9781800569041 |last1=Eagar |first1=Gareth |date=29 December 2021 |publisher=Packt Publishing }}</ref>
* No semantic versioning support.
▲== AWS Lambda Function URL ==
* Incompatibility with major security scanning tools.
▲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}}</ref> It was launched in April 6, 2022 by the AWS Lambda team.<ref>{{Cite web |title=Document history - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/lambda-releases.html |access-date=2024-03-01 |website=docs.aws.amazon.com}}</ref>
* Contribution to Lambda's 250MB size limit.
* Impeded local testing.
* No [[Tree shaking|tree-shaking]] optimizations.
==
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" />
==
== Threading and Scalability in AWS Lambda ==
As of March 2025, AWS Lambda supports limited vertical scaling by increasing the number of virtual central processing units (vCPUs) through memory allocation. However, it does not allow an increase in single-thread performance, as clock speed remains fixed. When a function is allocated only one vCPU, multiple threads share the same core, resulting in context switching rather than true parallel execution. As a result, multi-threading in single-vCPU environments is primarily beneficial for input/output (I/O)-bound workloads rather than computationally intensive tasks. <ref name=":1">{{Cite web |title=Configure Lambda function memory - AWS Lambda |url=https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html |access-date=2025-03-18 |website=docs.aws.amazon.com}}</ref><ref name=":2">{{Cite web |date=2024-08-28 |title=Efficiently processing batched data using parallelization in AWS Lambda {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/efficiently-processing-batched-data-using-parallelization-in-aws-lambda/ |access-date=2025-03-18 |website=aws.amazon.com |language=en-US}}</ref><ref name=":3">{{Cite web |date=2017-09-11 |title=Parallel Processing in Python with AWS Lambda {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/parallel-processing-in-python-with-aws-lambda/ |access-date=2025-03-18 |website=aws.amazon.com |language=en-US}}</ref><ref name=":4">{{Cite web |title=AWS Lambda now supports up to 10 GB of memory and 6 vCPU cores for Lambda Functions |url=https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-supports-10gb-memory-6-vcpu-cores-lambda-functions/ |access-date=2025-03-18 |website=Amazon Web Services, Inc. |language=en-US}}</ref><ref name=":5">{{Cite web |date=2021-02-08 |title=Operating Lambda: Application design – Scaling and concurrency: Part 2 {{!}} AWS Compute Blog |url=https://aws.amazon.com/blogs/compute/operating-lambda-application-design-scaling-and-concurrency-part-2/ |access-date=2025-03-18 |website=aws.amazon.com |language=en-US}}</ref>
Allocating additional memory in AWS Lambda enables multiple vCPUs, allowing for parallel execution. However, the clock speed per core remains unchanged, limiting individual thread performance. This configuration makes AWS Lambda suitable for workloads that scale horizontally or leverage parallelism but less optimal for applications that require high single-thread performance. <ref name=":1" /><ref name=":2" /><ref name=":3" /><ref name=":4" /><ref name=":5" />
▲== AWS Lambda Layers ==
== Security ==
In April 2022, researchers found cryptomining malware targeting AWS Lambda named "Denonia".<ref>{{Cite web |url=https://www.cadosecurity.com/blog/cado-discovers-denonia-the-first-malware-specifically-targeting-lambda |title=Cado Discovers Denonia: The First Malware Specifically Targeting Lambda |access-date=2024-11-04 |archive-date=2024-11-15 |archive-url=https://web.archive.org/web/20241115021350/https://www.cadosecurity.com/blog/cado-discovers-denonia-the-first-malware-specifically-targeting-lambda |url-status=live }}</ref><ref>{{Cite web |url=https://indianexpress.com/article/technology/crypto/cryptocurrency-mining-malware-used-to-target-aws-lambda-research-7859739/ |title=New cryptocurrency mining malware used to target AWS Lambda: Researchers | Technology News - the Indian Express |access-date=2024-11-04 |archive-date=2024-03-15 |archive-url=https://web.archive.org/web/20240315230202/https://indianexpress.com/article/technology/crypto/cryptocurrency-mining-malware-used-to-target-aws-lambda-research-7859739/ |url-status=live }}</ref><ref>{{Cite web |url=https://therecord.media/researcher-finds-cryptomining-malware-targeting-aws-lambda |title=Researcher finds cryptomining malware targeting AWS Lambda |access-date=2024-11-04 |archive-date=2024-04-05 |archive-url=https://web.archive.org/web/20240405092229/https://therecord.media/researcher-finds-cryptomining-malware-targeting-aws-lambda |url-status=live }}</ref>
==See also==
| |||