iamRoleStatement/Resource with pseudo-parametes/intrinsic functions ${AWS::Region} and ${AWS::AccountId} creates invalid Cloudformation template

This is a Bug Report

Description

Defining iamRoleStatements/Resource with pseudo-parameters/instrinsic functions ${AWS::Region} and ${AWS::AccountId} leads to invalid Cloudformation in cloudformation-template-update-stack.json See also http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html#cfn-pseudo-param-accountid

• What went wrong? Deploying attached serverless.yml causes AWS error: “An error occurred while provisioning your stack: IamRoleLambdaExecution - The policy failed legacy parsing.”

Reason is that some policies are created as

"Resource": [
   "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/iamParsingTest-dev-hello:*:*"
]

instead of:

"Resource": [
  {
    "Fn::Sub": "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/iamParsingTest-dev-hello:*:*"
  }
]

The error only occurred when a function and a resource were defined as well.

• What did you expect should have happened? Expected correct variable replacement and correct deployment

• What was the config you used? See files below

• What stacktrace or error message from your provider did you see? See above: “An error occurred while provisioning your stack: IamRoleLambdaExecution - The policy failed legacy parsing.”

Similar or dependent issues:

• #3824

Additional Data

serverless.yml (derived from https://github.com/serverless/serverless/pull/3111):

## Workaround attempt:
custom:
  acc: ${AWS::AccountId}

provider:
  name: aws
  runtime: nodejs6.10
  region: us-east-1
  # https://serverless.com/framework/docs/providers/aws/guide/variables/
  variableSyntax: "\\${{([ :a-zA-Z0-9._,\\-\\/\\(\\)]+?)}}"
  stage:  dev
  
  iamRoleStatements:
    - Effect: "Allow"
      Action: 
        - "dynamodb:GetRecords"
        - "dynamodb:GetShardIterator"
        - "dynamodb:DescribeStream"
        - "dynamodb:ListStreams"
      Resource:
        # Next line causes "IamRoleLambdaExecution - The policy failed legacy parsing."
        #- "arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/myTable/stream/*"
        ## Workaround does not work as ${AWS:AccountId} is not resolved, just passed on to CloudFormation without resolving it
        - "arn:aws:dynamodb:${{self:provider.region}}:${{self:custom.acc}}:table/myTable/stream/*"
        
# Note: error only occurs if function/resource is defined
functions:
  hello:
    handler: handler.hello
    events:
      - stream:
          type: dynamodb
          arn:
            Fn::GetAtt:
              - ResourcesDynamoDBStream
              - StreamArn
          batchSize: 1

resources:
  Resources:
    ResourcesDynamoDBStream:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ResourcesDynamoDBStream
        AttributeDefinitions:
          - AttributeName: id
            AttributeType: S
        KeySchema:
          - AttributeName: id
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        StreamSpecification:
          StreamViewType: NEW_AND_OLD_IMAGES

handler.js (auto-generated):

'use strict';
module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Go Serverless v1.0! Your function executed successfully!',
      input: event,
    }),
  };
  callback(null, response);
};

• Serverless Framework Version you’re using: 1 .17.0
• Operating System: Win10
• Stack Trace: none
• Provider Error messages: “An error occurred while provisioning your stack: IamRoleLambdaExecution - The policy failed legacy parsing.”

[amphibithen]

i experienced this today with iam policy as well when trying to reference ${AWS::Region} and ${AWS::AccountId} resulting in legacy parsing error during cloudformation load. work around was using !Join and !Ref, but that is a lot of extra that should not be needed i think…

[rickysahu]

As others suggested, we fixed it by moving arn:aws:logs:${self:provider.region}:#{AWS::AccountId}:log-group/abc/* to arn:aws:logs:${self:provider.region}:*:log-group/abc/*