Convince me to use API-Gateway and not call Lambda direct



What is the advantage of putting API-Gateway in front of my Lambda calls? Some AWS people are pushing me to do that but I can’t get a clear explanation of why I would want to do that. My Lambdas already have individual roles and policies that totally lock them down. We are serverless so no need for the gateway to talk to EC2 or any other external servers. The front ends (web/IOS/Android) use AWS_IAM security,

One argument is rate limiting control of API calls for DOS protection. Surely there are more advantages, can someone please explain?


Calling lambda’s directly is fine (and cheaper)

If you need to expose the lambda to a broader audience (web) then api gateway is it.

Some cool things about api gateway is custom authorizers, stage variables, and like you mentioned api rate limits.


Hi @jonsmirl

The fundamental thinking behind the lambda is event driven design. When ever an event triggered by the user only a small amount of code (Lambda function) will execute. AWS provides various events to trigger lambda execution API Gateway and CLI calls is 2 of those.

CLI calls are good if the lambda is not going to be distributed to to mass audience and used by a Team in closed environment. The reason for this is to execute lambda from CLI you need to create an IAM user and give him sufficient permissions, which will become very difficult if functionality of lambda needs to be exposed to large group. For larger reach API Gateway with Custom Authorizer is very good option.


My lambdas use AWS Cognito logins to get temp credentials. The role associated with the Cognito pool only allows execution of specific set of lambdas listed in the policy. Inside side each lambda the Cognito user ID that is passed in vai the environment is used to keep the users from messing with each other. This setup does not require external people to have a IAM user.

Flow is like this:
User authenticates via Google/Facebook/Cognito User pool.
Authentication provides a JWT token
Present the JWT token to the Cognito Federation pool
Receive temporary IAM credentials for the role associated with the Federation pool
Use those temp IAM credentials to call the lambda functions.
The policy in the role locks the functions down so that you can only execute them.
The Federation pool has also assigned the JWT user a Cognito ID.
That Cognito ID is provided inside the environment for the lambda function.
Now the lambda function can use it to keep the users separate.
You can’t mess with the Cognito ID since it has been encrypted into the temp credentials.


Your implementing is perfectly all right as you (or your team) are using all the lambdas in your code / application and not exposing them to any thirdpary / team for using in their code.

API Gateway is mainly for exposing the functionality to different team / users to used this their code and getting standard REST api signature for the calls

Only issue with your implementation is you do not have control over no of execution of lambda which may cost you unexpected money. I personally paid the price on similar implementation during development when one of my developer created an infinite condition in the code and ended up additional cost of several hundred $


I think this is totally dependent on your application, but one of the main reason for using an API over a direct invocation is adaptability to change. It is, in my opinion, not just for when you need to expose your services externally. What happens if 6 months from now your project lead or executives say they want you to use Docker containers (or worse, VMs) to run a particular service currently handled by a Lambda function? If you only have direct invocations, then you will find yourself having to cascade down all the callers and have them point to the new service–this may involve lots of code modifications.

Contrast that with having a pre-defined API which all your callers use. All you would have to do is modify the API to point to your new resource.

I think overall it’s just a matter of loose coupling between micro services–the same reason why you often want to use queues between them if you want more of a pull mechanism rather than push.


Definitely depends on your domain, but as someone who mostly works with APIs and mobile apps to consume them, I wouldn’t use Lambda directly.

Having an intermediary like API Gateway between your app and lambdas is pretty valuable in itself. It decouples your mobile clients from needing to know about all the lambdas, and from them changing.

You can’t force iOS and Android app updates, so whatever coupling you put out in the wile, needs to supported for quite a while. Even with automatic updates, this is at least months until there’s an insignificant number of people who haven’t updated (depending on your domain).

So as your backend evolves, do you just deploy new Lambdas and leave the old ones running for backwards compatibility?

If you change things with your AWS roles and IAM, does that break all existing apps in the wild?

I quite like having a standard HTTP interface so I can manage what’s exposed to apps better.


You still have to leave all of the old lambdas running with API gateway to support the different API versions in the gateway. API Gateway does not make that problem go away.


Yeah, it wont solve the API versioning problem, but it does decouple consumers from knowing anything more than endpoints and payload contracts.

I change my lambdas and internal structure more often than I change the external API contract, so I like the flexibility it gives me.


A new reason I’ve heard is because API Gateway some how deploys into Cloudfront. I believe the reasoning is that you can hide a multi-regional deployment behind Cloudfront and the app is then not aware it is multi-regional. With direct lambda calls the regions are visible. Is this something worth considering? We are a long ways away from needing multi-region support.

Related to this is the ability to use Clouldfront and API gateway together to get rid of the need for CORS.