Member-only story
Top things you should avoid when building with AWS Lambda
Don’t set Provisioned Concurrency == Reserved Concurrency
Reserved Concurrency (RC) is a configuration that places a max cap on concurrency available to the entire function family (all versions/alias). Provisioned Concurrency (PC) is set on a specific function version. If PC == RC, guess what happens?
You you can’t execute any other versions of the function INCLUDING any spillover that your PC allocation cannot handle. If you’re looking to cap your concurrency as a safety mechanism, just pick a buffer and add that to the RC value.
Don’t set maxed out Lambda configurations (Duration → 15 mins and Memory 10 GB)
In my experience dev teams use maxed out settings because they don’t understand Lambda billing/performance details or have not to optimized the function. In most cases its better to break up a large workload into small pieces that run in parallel. If you can’t shard up your workload then make sure you’re using the right memory for your workload.
Lambda Power Tuner is an excellent tool to help you choose the right memory.
Don’t set Batch Size == 1 when using a poll based event source
I’ve seen teams set Batch Sizes to 1 when configuring SQS or Kinesis as a Lambda event source. This results in a single message being delivered to a single invocation of Lambda. It’s incredibly inefficient and expensive. I understand it makes code easier because you only need to process 1 message at a time and not worry about errors, but AWS gives us the tools to do this properly.
Write your to code process multiple messages delivered to a single Lambda invoke. Then tell AWS which records failed. For example, SQS lets you report failed records all in one batch via the ReportBatchItemFailures feature. Kinesis has a similar feature.
Don’t configure CloudWatch Logs as an event source
You can create a CloudWatch Logs subscription that batches up logs and delivers them to Lambda via async invokes. You have no control over concurrency or speed. The logs are…
