AWS SAM + Cloudformation macros, a patch made in heaven

Over the last few weeks I have been working with a very ambitious client – Solve, who is building a new murder mystery game. They are doing some really cool things technically, and are building an entirely serverless stack.

While working with Solve I have spent a lot of time with AWS SAM. That experience also helped inform my opinion about SAM, as I explained in this article. Where compared with the Serverless framework it’s lacking the customizability that the serverless framework offers through its plugin system.

With the Serverless framework, I can write plugins to tailor the framework’s built-in behaviours. This gets me out of jail whenever I disagree with the framework’s choices. However, I don’t have such a luxury with SAM.

Just today, I ran into a problem with SAM’s support for AWS_IAM authorizer in API Gateway. The built-in behaviour is such that, anytime I choose to use AWS_IAM as the authorizer it’ll default the InvokeRole to CALLER_CREDENTIALS. Even if I explicitly set InvokeRole to null.

This means the caller’s IAM role would be used to invoke the Lambda function. So, to call my IAM-protected endpoint, I need to sign the request with an IAM profile with the permissions to:

That completely breaks the abstraction layer! As a caller, I not only need to know the endpoint I wish to talk to, but also how it’s implemented under the hood. If the API maintainer renames the functions behind the endpoint, my code would suddenly break.

If this issue also impacts you, then keep an eye on this Github issue.

Since SAM doesn’t have a plugin system, I would have to wait for the SAM team to fix the problem.

Or, do I?

Since SAM is ultimately just CloudFormation with a magical macro called AWS::Serverless-2016–10–31. I can modify the CloudFormation template it transformed with my own macros.

In this case, we were able to get ourselves out of jail by writing a CloudFormation macro to:

  • look for AWS::ApiGateway::RestApi CloudFormation resources
  • iteratively remove any credentials fields from AWS_PROXY integrations

With this macro, we were able to unblock ourselves.

Admittedly, using CloudFormation macros is a rather heavy-handed approach to customize SAM’s behaviour! However, in the absence of a built-in mechanism for customizing SAM, it was the best bad idea we were able to come up with. Please let us know in the comments if you know of a simpler, more elegant solution!

p.s. Solve is looking for a backend engineer to join their team in Shoreditch, London. If you’re looking for an opportunity to work with serverless technologies and build games for millions of users, then you should consider applying!

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter


Hi, I’m Yan. I’m an AWS Serverless Hero and the author of Production-Ready Serverless.

I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.


Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.

Get Your Copy


Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.

You can also get 40% off the face price with the code ytcui.

Get Your Copy