|
* Impeded local testing.
* No [[Tree shaking|tree-shaking]] optimizations.
== Lambda Destinations vs. Dead Letter Queues ==
AWS Lambda Destinations provide advanced error handling and routing capabilities compared to Dead Letter Queues (DLQs). While DLQs only capture failed asynchronous invocations for manual processing, Lambda Destinations support both synchronous and asynchronous invocations. Lambda Destinations allow routing to various targets, such as Amazon SQS, SNS, EventBridge, or another Lambda function, based on the outcome of the invocation (success or failure). Destinations also include the ability to capture detailed contextual information about the invocation, such as request and response payloads, aiding in more granular monitoring and troubleshooting. This feature facilitates more dynamic and automated error-handling workflows in serverless applications. <ref>{{Cite book |title=Programming AWS Lambda: Build and Deploy Serverless Applications with Java |publisher=O'Reilly Media |isbn=9781492041023}}</ref><ref name=":1">{{Cite book |last=Cui |first=Yan |title=Serverless Architectures on AWS |publisher=Manning |year=2020 |isbn=978-1617295423 |edition=2nd}}</ref>
==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. Tools like AWS Lambda Web Adapter offer a pathway for [[Software portability|portability]] by enabling developers to build web applications using familiar frameworks under the "Lambdalith" or monolithic Lambda design pattern. <ref>{{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>{{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.
Adopting architectural patterns such as [[Hexagonal architecture (software)|hexagonal architecture]] can mitigate these challenges by abstracting dependencies and facilitating compatibility across compute platforms. <ref name=":1" /> By separating the core business logic from infrastructure-specific code, this approach supports both HTTP and non-HTTP APIs, offering a more portable foundation for serverless workloads.
== Testing ==
Testing integrations between services is crucial, particularly for serverless applications like AWS Lambda, due to their distributed and fragmented architecture. Simulator tools like LocalStack can facilitate testing but may yield [[False positives and false negatives|false positives]] because they may diverge from actual AWS services. <ref>{{Cite book |last=Stojanovic |first=Slobodan |title=Serverless Applications with Node.js Using AWS Lambda and Claudia.js |publisher=Manning |isbn=9781638356172}}</ref>
To address this limitation, Yan Cui introduced "remocal testing," enabling local execution of application code while interacting with genuine AWS services. This approach allows real-time debugging and rapid code modifications without deployment. However, it necessitates provisioning and subsequent decommissioning of AWS resources, requiring meticulous planning. <ref name=":1" />
== Security ==
| 