- Newest
- Most votes
- Most comments
You can create scheduled events in EventBridge: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html
Note that it won't necessarily trigger at the 0 second of each minute.
I would actually recommend that you don't invoke all your active Lambdas every time, but add jitter to the invocations to spread the load. Have multiple events that invoke on different minutes spread across time so that you are not sending traffic spikes of the highest magnitude. This concept is part of this article in the Amazon Builders' Library: https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
It is an anti-pattern to have this kind of scheduled event. It requires you to have DynamoDB capacity to handle all the traffic at the same time, which likely exceeds you actual need for capacity, causing greater expense, as well as wasteful of resources.
You can also look at Lambda Extensions to perform actions before Lambda Invoke and also do cleanup or other activities after the Lambda invokes.
References : https://aws.amazon.com/blogs/compute/caching-data-and-configuration-settings-with-aws-lambda-extensions/ https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/ https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/
Can you please be more specific on which specific extension you would use? I can't identify one that would serve the purpose.
Thanks.
It appears he is recommending the cache-extension-demo extension in the blog. This also would not improve a write use case. Is your use case predominately write or read?
Both reads and writes. For reads, I don't want to make usage of any cache as I require strong consistent reads.
What you are asking is not easy to do and it is not recommended. First, there is no option to just invoke all instances. This means that you will need to create the code yourself to find out how many instances are there, and then invoke a specific path in the code that sleeps for some time * the number of instances. The thing is that if some of the instances are currently handling a request, new instances will be created, which is not what you want.
DynamoDB uses an HTTP API to interact with the service and not a persistent open connection like MySQL for example. Saying that, you can configure the DynamoDB SDK to keep the underlying TCP connection open using keep alive, e.g., in Python: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html. You should perform some dummy DynamoDB operation in your initialization code (outside the Lambda handler) and the connection will remain open. Configure the function with Provisioned Concurrency and it will be ready before you have any traffic.
I have both warming code in constructor and also provisioned concurrency configured but the first request after lambda instances have been initialize takes 500ms in establishing a connection with DynamoDb. Even if I don't close the connection at the client side, connections get closed at the server side.
Relevant content
- Accepted Answerasked 2 years ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated a year ago
- Why can't I view the EventBridge trigger in my Lambda function that my CloudFormation stack created?AWS OFFICIALUpdated 22 days ago
- AWS OFFICIALUpdated 7 months ago
Even if I schedule more EventBridge's rules than number of Lambda instances to run each minute, there is no guarantee that all instances of a Lambda will process at least one request.
You could open the connection in the initialization code, but it will still timeout and close when not used. Is your use case infrequent access with low latency response time?
I'm already warming up the lambda during initialization. Yes, infrequent access with low latency response time is my use case.