One More Accidental Complexity

Writing a simple template.yaml file for AWS SAM is easy, there are lots of “Hello World” level tutorials on the Internet. But if you try to do more complex things, you are alone with SAM Reference, Github page of SAM. Today, I had to deal with one more issue which was not very intuitive.

I was implementing a lambda function and had to give it permission to access a SNS Topic. Previously, I had given it permission to access a DynamoDB table and I just implemented the corresponding SNS permission like this:

Policies:
  - SNSPublishMessagePolicy:
      TopicName: !Ref TransactionTopic
  - DynamoDBCrudPolicy:
      TableName: !Ref TransactionTable

I have found the corresponding policy name, “SNSPublishMessagePolicy”, very similar to “DynamoDBCrudPolicy”. Instead of “TableName”, I had used “TopicName”. It is very intuitive, right? I was wrong. This template deploys and grants permission to publish an SNS Topic which doesn’t exist. Also, ARN of the topic is very very similar to actual ARN and you think that everything is correct. So if you check the permissions of Lambda, most probably you will not notice any problem.

The correct policy is like this:

Policies:
  - SNSPublishMessagePolicy:
      TopicName: !GetAtt TransactionTopic.TopicName
  - DynamoDBCrudPolicy:
      TableName: !Ref TransactionTable

For SNS topic, different then DynamoDB table, you need to use !GetAtt TransactionTopic.TopicName instead of !Ref TransactionTable.

It turns out, !Ref when used for a SNS topic, returns the ARN. But, !Ref when used for a DynamoDB table, the table name. The same function returns different attributes depending on the resource. If SAM had been designed to use ARN consistently, this mistake could have been completely eliminated. May be there is a technical reason, but it would be much easier if it was like the following:

Policies:
  - SNSPublishMessagePolicy:
      ARN: !Ref TransactionTopic
  - DynamoDBCrudPolicy:
      ARN: !Ref TransactionTable