I've got an API already running. What does this buy me?
Caching? I can see some benefit there it's read heavy.
Auth and access control? Feels like that's part of my app code but maybe there's a benefit I'm missing
A lot of the other benefits also feel like it would be hard to cleanly separate them from my app code.
What's the elevator pitch and who's the target market?
Imagine this: You are BigCorp USA Inc. and have a bunch of internal SOAP-based web services that are 10 years old and cost a fortune to maintain.
You hear someone will pay you to use them, but SOAP sucks. So you could either go and change your APIs (and probably break a bunch of internal processes) OR you could use a gateway to sit in front of them and translate in bound / outbound requests. Now you can charge people for your APIs!
Scenario 2: If you're an indie dev/ startup but dont want to run EC2 infrastructure, Lambda + Gateway = Cloud service, without any heavy lifting, servers and cost effective. It's development lego. Kind of like Parse.
Scenario 3: You have an API for your app, now you wnat third party devs to use it.Your API is not set up for that kind of access (multi-user security, throttling, quotas, analytics etc.) - solution: shove a gateway in front of it.
How do you go about proxying REST style requests to a SOAP backend?
A harder case is when you have a "service" layer which also has a large collection of queries at various levels of abstraction.
These map poorly into resources, where you want a single level of abstraction per resource. And they map badly to legacy consumers, who've grown comfortable to having a collection of special knobs and dials perfectly shaped for their exact needs.
It does suck a bit, I've also sent Layer 7 into production which is just as bad as Axway. Typical Vendorware.
The AWS Gateway is pretty enticing. Solves lots of the API Gateway problem space very quickly and super cheap. We could run our production instance for about $2 a month I reckon, vs a 6 figure sum for the vendor tech.
[1]https://www.forrester.com/Sizing+The+Market+For+API+Manageme...
At a larger size, it may be more expensive than a roll your own, but for an independent idea that you just want to build something as a software/service and if successful be able to scale and handle extra load, it isn't a bad idea.
This is really the missing piece to Lambda in my mind... though being able to act as a bridge for legacy SOAP/WS-* services is pretty nice too. I've written a lot of pretty small node service that act as a bridge to SOAP based services the past few years... though most of those have been for internal use, and not sure how well that translates here.
Also API market is intended to grow to $660 million in US by 2020 and over a billion worldwide (http://blogs.forrester.com/michael_yamnitsky/15-06-07-the_ap...). So it's definetely not small.
It means you do not need to think about x instances that serve your API anymore. You just upload your Lambda function, wire some API path to it and pay per request. For smaller APIs this will be probably be negligible. Could be a gamechanger!
Rather than running an API server 24/7, you can write your API as a set of functions that cost you money only when they're actually invoked.
If you have a large cloud platform, an API gateway is priceless.
Especially if you have single sign on and therefore can use auth tokens for everything.
And because everything for them is already built on top of AWS.
In the API Gateway I work with allows you to do authentication within the gateway and then delegate responses to the back end API (which can still have its own security, if you really want it, but usually is just hidden on an internal network). It works pretty much the same for other things like rate limiting. It also gives you monitoring for each API, again cutting down on the things you have to add to every single API by encapsulating the function in the gateway.
Also, you can separate your internal API and your external APIs. Maybe you have to always support certain operations to the outside world, but internally you'd really like to change something. By having them separate, you can create a policy within the gateway to change how the internal calls are done without changing the interface as far as the outside world is concerned.
You can also do various types of conversion (e.g. REST->SOAP) or even more exotic things so that outside devs don't have to care just how weird your damned mainframe is or other aspects of your internal architecture that they shouldn't know about.
The target market is, effectively, anyone who wants to expose internal APIs to the outside world.
Source: I work on an API Gateway and this is how our product works.