Skip to content

Latest commit

 

History

History

Lambda

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Lambda notes

Jump to


Useful Libs and Tools


Best Practices Guides


Synchronous Invokes, Asynchronous Invokes, Poll-Based Invokes


MLTA, Debugging, Error Handling

Useful blog posts

How error should be handled for Asynchronous Invocations

  1. Lambda Destinations + X-Ray traces
    • With Destinations, you will be able to send asynchronous function execution results to a destination resource without writing code. For each execution status (i.e. Success and Failure), you can choose one destination from four options:
      • another Lambda function,
      • an SNS topic,
      • an SQS standard queue, or
      • EventBridge.
  2. Dead-letter queues

Code storage for uploaded Lambda functions (CodeStorageExceededException)

The Lambda service stores your function code in an internal S3 bucket that's private to your account. Each AWS account is allocated 75 GB of storage in each Region (and can be increased up to Terabytes). Code storage includes the total storage used by both Lambda functions and layers. If you reach the quota, you receive a CodeStorageExceededException when you attempt to deploy new functions.

See Lambda quotas.

To see the storage used

  1. From AWS Lambda console > Dashboard
  2. From AWS CLI:
    aws lambda list-versions-by-function --function-name myTestFunction
    aws lambda get-layer-version --layer-version --layer-name TestLayer --version-number 2
    
    This returns each published version of the function/layer together with the $LATEST version. The CodeSize attribute shows the total number of bytes used by code storage of this function/layer.

See Monitoring Lambda code storage.

To manage the storage used

It's best practice to manage the storage space available and clean up old versions of functions and remove unused code.

See Best practices for managing code storage.


Lambda Scaling and Throughput

Scaling quotas

There are two scaling quotas to consider with concurrency: account concurrency quota and burst concurrency quota.

  • The account concurrency is the maximum concurrency in a particular Region. This is shared across all functions in an account. The default Regional concurrency quota starts at 1,000, which you can increase with a service ticket.

  • The burst concurrency quota provides an initial burst of traffic for each function, between 500 and 3000 per minute, depending on the Region. After this initial burst, functions can scale by another 500 concurrent invocations per minute for all Regions. If you reach the maximum number of concurrent requests, further requests are throttled.

Provisioned Concurrency

The function initialization process can introduce latency for your applications. You can reduce this latency by configuring Provisioned Concurrency for a function version or alias. This prepares runtime environments in advance, running the function initialization process, so the function is ready to invoke when needed.

This is primarily useful for synchronous requests to ensure you have enough concurrency before an expected traffic spike. You can still burst above this using standard concurrency.

You can use Application Auto Scaling to adjust Provisioned Concurrency automatically based on Lambda's utilization metric.

Estimate concurrent requests

  • Each runtime environment processes a single request at a time. While a single runtime environment is processing a request, it cannot process other requests.
  • The number of runtime environments determines the concurrency. This is the sum of all concurrent requests for currently running functions at a particular point in time.
  • The number of transactions Lambda can process per second is the sum of all invokes for that period.
  • Reducing a function's invocation duration can increase the transactions per second that a function can process.

To estimate concurrent requests from the number of requests per unit of time (e.g. seconds) and their average duration, using the formula:

RequestsPerSecond x AvgDurationInSeconds = concurrent requests

For example, if a Lambda function takes an average 500 ms to run, at 100 requests per second, the number of concurrent requests is 50:

100 requests/second x 0.5 sec = 50 concurrent requests

See this blog post for more examples.

Throttling error and asynchronous/synchronous invocations

  • For synchronous invocations, Lambda returns a throttling error (429) to the caller, which must retry the request.
  • With asynchronous and event source mapping invokes, Lambda automatically retries the requests.

See also

Operational metrics

There are CloudWatch metrics available to monitor your account and function concurrency to ensure that your applications can scale as expected. Monitor function Invocations and Duration to understand throughput. Throttles show throttled invocations.

  • ConcurrentExecutions tracks the total number of runtime environments that are processing events. Ensure this doesn't reach your account concurrency to avoid account throttling. Use the metric for individual functions to see which are using account concurrency, and also ensure reserved concurrency is not too high. For example, a function may have a reserved concurrency of 2000, but is only using 10.
  • UnreservedConcurrentExecutions show the number of function invocations without reserved concurrency. This is your available account concurrency buffer.
  • Use ProvisionedConcurrencyUtilization to ensure you are not paying for Provisioned Concurrency that you are not using. The metric shows the percentage of allocated Provisioned Concurrency in use.
  • ProvisionedConcurrencySpilloverInvocations show function invocations using standard concurrency, above the configured Provisioned Concurrency value. This may show that you need to increase Provisioned Concurrency.

See Understanding AWS Lambda scaling and throughput.


Lambda Performance Optimisation

Some good reads:

See also Lambda - Performance optimization.


Lambda Cost Optimisation

Useful blog posts


Lambda Function URLs

The Lambda Function URLs feature was introduced in April 2022. A function URL is a dedicated HTTP(S) endpoint for the Lambda function (https://<url-id>.lambda-url.<region>.on.aws)

Lambda function URLs use resource-based policies for security and access control. When AuthType = None, resource-based policy that grants public access, any unauthenticated user with your function URL can invoke your function).

Recommendation:

  • Use SCP to deny following actions:
    • lambda:CreateFunctionUrlConfig
    • lambda:UpdateFunctionUrlConfig

Useful blog posts


Lambda Response Streaming


Lambda Container Images


Lambda Layers

  • Centralizing management of AWS Lambda layers across multiple AWS Accounts , AWS, 2023-09-19
    aws configservice select-aggregate-resource-config \
        --expression "SELECT accountId, awsRegion, configuration.functionName, configuration.version WHERE resourceType = 'AWS::Lambda::Function' AND configuration.layers.arn = 'YOUR_LAYER_ARN'" \
        --configuration-aggregator-name 'YOUR_AGGREGATOR_NAME' \
        --query "Results" \
        --output json | \
        jq -r '.[] | fromjson | [.accountId, .awsRegion, .configuration.functionName, .configuration.version] | @csv' > output.csv
    

Lambda Extensions


Design Patterns


Gotchas

Lambda Python Runtimes - Python 3.6/3.7 are Amazon Linux 1 and Python 3.8/3.9 are Amazon Linux 2

Python 3.6/3.7 are Amazon Linux 1 and Python 3.8/3.9 are Amazon Linux 2.

In general it should be fine to upgrade from Python 3.6 to 3.9. But there are cases you'll need to make some changes. For example: If you have code utilizing some sys call, e.g. curl - curl is not installed in Amazon Linux 2 by default.

AWS CLI not allowing valid JSON in payload parameter with lambda invoke

If you see error like Invalid base64:, it could be because since awscli 2, payloads need to be base64 encoded when invoking a Lambda function.

By default, the AWS CLI version 2 now passes all binary input and binary output parameters as base64-encoded strings. A parameter that requires binary input has its type specified as blob (binary large object) in the documentation.

You will need to pass in also --cli-binary-format raw-in-base64-out. For example:

aws lambda invoke --function-name testsms \
    --invocation-type Event \
    --cli-binary-format raw-in-base64-out \
    --payload '{"key": "test"}' response.json

See also

Cannot do ping from Lambda Function

See AWS Lambda FAQs

Lambda attempts to impose as few restrictions as possible on normal language and operating system activities, but there are a few activities that are disabled: Inbound network connections are blocked by AWS Lambda, and for outbound connections, only TCP/IP and UDP/IP sockets are supported, and ptrace (debugging) system calls are blocked. TCP port 25 traffic is also blocked as an anti-spam measure.

Non-async handlers and context.callbackWaitsForEmptyEventLoop = false

  • By default calling the callback() function in a NodeJS Lambda function does not end the function execution. It will continue running until the event loop is empty. A common issue with NodeJS Lambda functions continuing to run after callback is called occurs when you are holding on to open database connections.

I solved my problems with set to callbackWaitsForEmptyEventLoop = false.