Serverless projects sometimes need changes
So now that we have our first deployment operational, we should reflect a bit on this new environment. First, remember that when there is no web traffic, your project is not doing any work and you will not be charged by Amazon.
When your deployment is very busy, then AWS Lambda manages instances for you, scaling up as traffic increases and then scaling down when traffic decreases. The best part about this?
Your dev and QA environments hardly cost anything, but your production environment can scale up to handle lots of traffic.
From the AWS Docs about Lambda Scaling:
The first time you invoke your function, AWS Lambda creates an instance of the function and runs its handler method to process the event. When the function returns a response, it stays active and waits to process additional events. If you invoke the function again while the first event is being processed, Lambda initializes another instance, and the function processes the two events concurrently. As more events come in, Lambda routes them to available instances and creates new instances as needed. When the number of requests decreases, Lambda stops unused instances to free up scaling capacity for other functions.
At some level of traffic, it may no longer be cost-effective to keep using AWS Lambda, and it may become cheaper to use EC2 or another service. Your business may vary, but I would say it would take a fairly large amount of traffic to cross this threshold. While the prices may be slightly outdated, this blog post provides cost breakdown for a low traffic site.
AWS Lambda charges by a chunk of requests and also by the duration of execution time - measured in milliseconds! So we want our Django app to finish quickly.
Using Django in AWS Lambda makes a lot of sense since most web requests are not long-lived and finish quickly. Think about it, users browsing the web get upset if a page takes more than 2 seconds to load.
Each AWS Lambda invocation has a time limit on how long it can run. It's configurable from between 30 seconds and 900 seconds (15 minutes). By default, the Zappa utility sets the max execution time to 30 seconds and after that limit, the function is terminated. For most web requests, this is completely fine - who would wait 30 seconds for a page to load? Also, the AWS API Gateway has a 30-second timeout; so for all web requests, 30 seconds is the effective maximum.
However, there are some circumstances where you need your AWS Lambda invocation to exceed 30 seconds. For example, you could be running a management command or doing some backend processing. If you'd like to modify the execution timeout, use the
timeout_seconds setting in