You have implemented your solution with Remotion Lambda are are ready to launch your project into the world. Congrats! Before you go live, go through this checklist to make sure Lambda is running stable.
Optimizing for memory
Adding too much memory to your Lambda functions can make rendering more costly. Reducing the memory of your function by 25% will also decrease your cost by 25%! Redeploy your function multiple times and lower the memory size as much as possible until you feel you hit the sweet spot between low costs and confidence that your video will render reliably.
Maximum file size
Lambda is constrained to a maximum output file size of approximately half the disk space. Adjust the disk space parameter of Lambda to accomodate for the maximum video length that you would like to support. Test the file sizes of your outputs and make sure they don't run at risk of exceeding the limit. If your video is based on user input, prevent your users from rendering very long videos that would exceed the space available in Remotion Lambda.
Make sure your AWS user only has as many permissions as needed and store your credentials as environment variables. Review the Permissions page to see what the minimum amount of permissions is.
AWS burst limit
Familiarize yourself with the AWS burst limit. Essentially, you need to avoid a quick spike in video renders that will cause the burst limit to take effect. If you need to scale beyond the burst limit, consider scaling across multiple regions as the burst limit only applies for a certain region. Another strategy to consider is creating multiple sub-accounts in your AWS organization as the burst limit only affects a single account.
AWS payload limit
The maximum payload for invoking a Lambda function is 256KB. Ensure that in your application, the
inputProps payload does not exceed this amount and introduce validation and error handling if necessary.
Selecting the right concurrency
If you are using the
framesPerLambda option, make sure that for each video you render, the parameter is set in a way that it stays within the allowed bounds (no more than 200 lambda functions per render). See: Concurrency
Consider if it's possible for a user to invoke many video renders that will end up on your AWS bill, and implement a rate limiter to prevent a malicious actor from rendering many videos.
The default timeout for your Lambda function is 120 seconds which should be plenty, given that the video rendering is massively parallelized. But also here, measure and adjust the timeout for your needs and make sure it is high enough so that your video render will not fail.