The final policy size is bigger than the limit

[amoghesturi]

I am using the following configuration and receiving error

custom:
  configFile: ${file(./config/${self:provider.stage}.yml)}
  stage: ${opt:stage, self:provider.stage}
  domains:
    production: ${self:custom.configFile.DOMAIN}
    development: ${self:custom.configFile.DOMAIN}
    qa: ${self:custom.configFile.DOMAIN}
  customDomain:
    domainName: ${self:custom.domains.${self:custom.stage}}
    basePath: dummyPath
    createRoute53Record: true
    endpointType: 'regional'
    stage: ${self:provider.stage}
  serverless-layers:
    - common:
        layersDeploymentBucket: 'platform-${self:provider.stage}-${self:provider.region}'
        dependenciesPath: ./package.json
        compatibleRuntimes: ["nodejs14.x"]
  region: ${self:custom.configFile.REGION, 'ap-south-1'}
  logSubscription:
    enabled: ${self:custom.configFile.LOG_AGGREGATION, true}
    destinationArn: ${self:custom.configFile.LOG_STREAM} // Pointing to 

provider:
  iam:
    role:
      managedPolicies:
        - arn:aws:iam::#{AWS::AccountId}:policy/platform_${self:provider.stage}
        - arn:aws:iam::aws:policy/AmazonAPIGatewayInvokeFullAccess
        - arn:aws:iam::aws:policy/AmazonAPIGatewayAdministrator
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AWSLambda_FullAccess
        - arn:aws:iam::aws:policy/AmazonSESFullAccess
  deploymentBucket:
    name: com.serverless.${self:provider.stage}.${self:provider.region}.deploys

We have more than 15 rest API functions deployed through this and we are receiving the following error

An error occurred: FunctionNameLogLambdaPermission - The final policy size (20798) is bigger than the limit (20480). (Service: AWSLambda; Status Code: 400; Error Code: PolicyLengthExceededException; Request ID: <>; Proxy: null).

[paolo-rechia]

Hi, we had a similar problem. We deployed dozens of stacks and then this error started showing up.

The reason why is that this plugin creates policies like the following:

{
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "function1-YYYYYY",
      "Effect": "Allow",
      "Principal": {
        "Service": "logs.eu-central-1.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-central-1:XXXXXXXX:function:function1",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:logs:eu-central-1:XXXXXXXX:log-group:/aws/lambda/function1:*"
        }
      }
    },
    {
      "Sid": "function2-ZZZZZZZ",
      "Effect": "Allow",
      "Principal": {
        "Service": "logs.eu-central-1.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:eu-central-1:XXXXXXXX:function:function2",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:logs:eu-central-1:XXXXXXXX:log-group:/aws/lambda/function2:*"
        }
      }
    }
  ]
}

As you can see, it's one statement generated per lambda function. This quickly fills up your log subscription policy size limit. To work around this, we rolled this policy in the log subscription lambda:

      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:logs:eu-central-1:XXXXXXXX:log-group:/aws/lambda/*:*"
         }
       }

And then disabled the auto generated permissions with the flag addLambdaPermission set to false

  logSubscription:
    enabled: true
    destinationArn: your-destination-arn
    addLambdaPermission: false

I hope this helps you.

[amoghesturi]

Thanks, @paolo-rechia . After quite a bit of debugging, I ended up doing the same exact thing you mentioned.

@dougmoscrop The current step requires manual steps. So, do you think it would be a good idea to implement the functionality to group multiple permissions with wildcard? It would have made the life of new adopters like me easier to get started without having to deal with policy size exceeding the limits.

[Nicoowr]

+1 for this feature request

It seems like addLambdaPermission: false does not work since IAM role policies are automatically generated even when it is set to false

[RichardBradley]

We had the same problem

It seems that this addLambdaPermission is granting Cloudwatch permission to write to the dest Lambda, for the specific log group in question, once per endpoint in your app.

That doesn't scale at all and errors if you have more than a handful of endpoints.

We are working around this by setting addLambdaPermission: false and granting Cloudwatch permissions outside of this plugin, like those above.

I don't think this setting should be on by default, as it's not production ready

(EDIT: I have updated my comment as I misunderstood what this was doing on first post)