Frequently asked questions about Lambda
In many cases, separating functionality into different functions can provide better performance and also make an application more maintainable and scalable. However, Lambda “monoliths” may be a useful stepping stone in migrating an existing application.
How much functionality should a single Lambda function contain?
The function should perform a single task in the flow of data across AWS services in your microservice. However, if the functional task is too small, this may incur additional latency in the application and overhead in managing large numbers of functions. The exact scope of a function is determined by the use case.
Can Lambda-based applications work in multiple Regions?
Yes, many serverless services provide replication and support for multiple Regions, including DynamoDB and Amazon S3.
Lambda functions can be deployed in multiple Regions as part of a deployment pipeline, and API Gateway can be configured
to support this configuration. See this
example architecture
Can Lambda functions run on a timed schedule?
Yes, you can use scheduled expressions for rules in EventBridge to trigger a Lambda function. This format uses cron syntax and can be set with a one-minute granularity. See this tutorial for an example.
How can a Lambda function retain state between invocations?
In many cases, a DynamoDB table is an ideal way to retain since it provides low-latency data access and can scale
with the Lambda service. You can also store data in
Amazon EFS for Lambda
What types of workloads are suited to event-driven architectures?
Event-driven architectures communicate across different systems using networks, which introduce variable latency. For workloads that require very low latency, such as real-time trading systems, this design may not be the best choice. However, for highly scalable and available workloads, or those with unpredictable traffic patterns, event-driven architectures can provide an effective way to meet these demands.
Why does the Lambda service have a 15-minute limit for functions?
Lambda functions exist to process events and most events are processed very quickly – typically, under 1 second for the majority of production invocations. The duration of a function is determined by the time taken to process one event. While there are some compute-intensive workloads that can take several minutes, very few require 15 minutes to complete.
If you find that you need a longer duration, ensure that your function code is processing single events, performing single tasks, and using the best practices outlined in this document. In many cases, functions can be redesigned to process single events and reduce the amount of time needed to process.
Why is a function with reserved concurrency not scaling to meet incoming traffic?
Reserved concurrency for a Lambda function also acts as a maximum capacity value. Raising the soft limit on total concurrency does not affect this behavior. If you need a function with reserved concurrency to process more traffic, you can update the reserved concurrency value, which increases the maximum throughput of your function.
Why is a function with provisioned concurrency still experiencing cold starts?
You can measure cold starts as Lambda scales up by adding X-Ray monitoring to your function. A function using provisioned concurrency does not exhibit cold start behavior since the execution environment is prepared ahead of invocation. However, provisioned concurrency must be applied to a specific version or alias of a function, not the $LATEST version. In cases where you continue to see cold start behavior, ensure that you are invoking the version of alias with provisioned concurrency configured.
What is the best runtime to use for my Lambda function?
Lambda is agnostic to your choice of runtime. For simple functions, interpreted languages like Python and Node.js offer the fastest performance. For functions with more complex computation, compiled languages like Java are often slower to initialize but run quickly in the Lambda handler. Choice of runtime is also influenced by developer preference and language familiarity.
How do I make sure that the SDK version doesn’t change?
The embedded SDKs may change without notice as AWS releases new services and features. You can lock a version of the SDK by creating a Lambda layer with the specific version needed. The function then always uses the version in the layer, even if the version embedded in the service changes.
How can I test that a Lambda-based application can scale to meet the expected traffic?
To ensure that your application scales as expected, use load testing in your development process to simulate the expected level of traffic.
Which workloads are suitable for provisioned concurrency?
Provisioned concurrency is designed to make functions available with double-digit millisecond response times. Generally, interactive workloads benefit the most from the feature. Those are applications with users initiating requests, such as web and mobile applications, and are the most sensitive to latency. Asynchronous workloads, such as data processing pipelines, are often less latency sensitive and so do not usually need provisioned concurrency.
Why is my Lambda function not logging any output?
If a Lambda function is not logging to CloudWatch, first ensure that the function is being invoked by the caller. Check the logs of the calling service and any CloudWatch metrics that indicate an event has triggered the function. Next, check the CloudWatch Logs for the function. All Lambda functions log three lines, even if there is no other explicit logging in the custom code of the function:
If there is no logging appearing in CloudWatch despite the function being invoked, check the permissions of the function. The IAM role must include logging permissions, or the function cannot write logs to the service. You can attach the AWSLambdaBasicExecutionRole policy to your function's execution role to grant these permissions.
