I mean, if your application is suffering due to cold starts, you can just use the old-school EventBridge ping option and it costs 0 This isn't nearly as effective as there's no real way to make EventBridge keep 100 or 1000 or more environments warm. If you have a very low traffic application maybe this method still makes sense, but for anything else PC is going to be more reliable

The proper way to scale AWS Lambda provisioned concurrency is by using Application Auto Scaling.

At the time of writing, you cannot do so through the AWS console, but you can use AWS CLI by passing the --schedule flag as follows:

aws application-autoscaling register-scalable-target \
  --service-namespace lambda \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --resource-id function:my-function:BLUE \
  --min-capacity 0 \
  --max-capacity 100

If you want to scale up only during peak hours, you can run the following:

aws application-autoscaling put-scheduled-action --service-namespace lambda \
  --scalable-dimension lambda:function:ProvisionedConcurrency \
  --resource-id function:CreateOrder:prod \
  --scheduled-action-name scale-out \
  --schedule "cron(45 11 * * ? *)" \
  --scalable-target-action MinCapacity=250

More details from the official AWS blog post.

The presence of spillover invocations in your scenario indicates that your provisioned concurrency (PC) is not sufficient to handle the current load. While the PC utilization is only at 28.5%, it's important to note that this metric represents the ratio of the provisioned concurrent executions being used to the total provisioned concurrency. It doesn't necessarily reflect the actual demand or the number of concurrent invocations at any given moment. In your case, the load test shows that you had a peak of 189 concurrent executions, but your provisioned concurrency was set to 500. This means that during the test, there were instances where the available provisioned concurrency was fully utilized, resulting in spillover invocations. These spillover invocations occur when the provisioned concurrency is exhausted, and additional requests cannot be immediately served by existing instances. Cold starts can still happen with provisioned concurrency, but their occurrence is minimized compared to using on-demand concurrency. When a cold start occurs, it means that the lambda function needs to initialize a new execution environment to handle the incoming request. With provisioned concurrency, you can pre-warm a certain number of instances to minimize the impact of cold starts, but if the demand exceeds the provisioned concurrency, spillover invocations may experience cold starts. To address the spillover invocations and potential cold starts, you have a few options: Increase Provisioned Concurrency: If the load test consistently exceeds the provisioned concurrency, consider increasing the provisioned concurrency limit to better accommodate the peak demand and minimize spillover invocations. Adjust Auto Scaling Parameters: Review your auto scaling configuration and ensure that the min and max capacity are set appropriately. If the current settings are not effectively scaling to meet the demand, you may need to fine-tune these parameters to better align with your application's requirements. Monitor and Analyze Load Patterns: Understand the patterns and fluctuations in your application's load. Analyze the metrics over time to identify peak usage periods and adjust your provisioned concurrency and auto scaling settings accordingly. By optimizing the provisioned concurrency and auto scaling parameters based on your application's load patterns, you can better utilize provisioned concurrency and minimize spillover invocations and potential cold starts.