A typical story: You want to build on AWS API Gateway so that your applications have highly scalable and managed REST APIs. You need a front door for your users or other applications to interact with your application. You need to authenticate your API, so you go with the default “out of the box” option: AWS_IAM_._ Everything is quickly set up and the POC works fine. You are ready to onboard your first user/service. But wait…

AWS API Gateway is a super simple and intuitive managed service by AWS that can super charge your entire serverless ecosystem. It is the microservice front door. It has it all. REST, Websocket, authentication, validation, the works. However, always using the default authentication method for your api gateway methods/resources could possibly create more issues for your teams and applications than solutions. It might be simpler out of the box, but it can end up tightly coupling all of your microservices and increasing unnecessary toil for your entire environment. There must be a better way!

Whether your gamut of applications are same-account, cross-account, external to your company, etc., if you use the default way to secure your API’s on API Gateway each and every time, then you could be setting yourself up for an IAM nightmare. This is because in increasingly many scenarios IAM authentication requires cross-account role creation and management. This can reduce flexibility and cause extra toil the more complex your environment becomes. All too often the management becomes too overwhelming and teams can opt for less secure IAM policies and roles. This leads to greater and more frequent application coupling. To combat this potentially hazardous scenario, Lambda Authorizers come to the rescue.

#cloud #amazon-web-services #lambda #api-gateway #security #api