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:

• execute-api:Invoke against the API Gateway resource
• and lambda:InvokeFunction against the Lambda function sitting behind API Gateway

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!

Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.

You can contact me via Email, Twitter and LinkedIn.

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, design patterns and best practices.

Get your copy here.

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 here.

Originally published at https://theburningmonk.com on May 17, 2019.

AWS SAM + Cloudformation macros, a patch made in heaven was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.