My team just spun up CerbosPDP in AWS in a minor variation of this lambda: https://github.com/cerbos/cerbos-aws-lambda We are observing what seem like fairly long startup/performance times for the lambda that seem related to the CerbosPDP binary. We are loading a few simple policies from an S3 bucket that derive role(s) from the principal and then resolve access to a single resource (kind) based on those roles. Can anyone comment on similar experiences or what optimization(s) we might further consider.

Memory               Cold Start Init (ms)      Warm Start Duration (ms)
128                  7353                      2921
256                  2585                      205
512                  1967                      88

Hi @Anne-Leslie Dean Cerbos doesn’t need that much memory, but “Lambda allocates CPU power in proportion to the amount of memory configured”, and also: “Memory is the principal lever for controlling the performance of a function. The default setting, 128 MB, is the lowest possible setting. We recommend that you only use 128 MB for simple Lambda functions, such as those that transform and route events to other AWS services.” It is also believed that allocated memory impacts the network bandwidth available to Lambda. 512MB corresponds to 0.3 vCPU, which I guess is rounded to 0.5 vCPU. That explains the lower start-up time for the 512MB Lambda, as Cerbos requires some compute power to download and compile policies. To eliminate the impact of network latency, can you try embedding policies in the Cerbos lambda and using disk storage for Cerbos? Additionally, I assume the S3 bucket is located in the same region as the Cerbos Lambda. If not, the network latency might be higher.

@Dennis (Cerbos) thanks that is consistent with what I expected per the cold start. I was just hoping there might be some secret-sauce to increase the warm start performance at 128 -- the policies should already be compiled at that point, correct?

If the policies haven’t changed or updatePollInterval is zero, which is a default value, then yes, policies shouldn’t be recompiled. 128MB is plenty of memory for Cerbos PDP, but in Lambda, that translates to a tiny fraction of vCPU (<0.1 vCPU). Even if Cerbos doesn’t need to recompile policies, it still requires CPU power to evaluate them. Cerbos and Go runtime run a few background threads that also consume CPU power. Overall, Cerbos PDP doesn’t fit the description of a simple Lambda function as outlined in the AWS documentation quoted above. We will update our documentation to recommend allocating at the very least 512MB for AWS Lambda running Cerbos PDP.

Thanks -- we were using lambda as the "first experiment" to see how CerbosPDP would behave -- and seeing the example repo made us assume that it would be reasonably performant -- however it does appear realistically, that CerbosPDP needs to be deployed as long running (ECS or EKS) process. I appreciate your confirming that the behavior we are observing is consistent with what you would expect.