If it's internal, you probably shouldn't be using the API Gateway. You can just call the underlying lambda directly through the SDK with invoke and save yourself the cost of the API Gateway, as well as be able to invoke it asynchronously should that be a better fit.
That said, it depends on your design/architecture as to whether that is appropriate or not. Sometimes you want that distinct separation. But if that's the case, you should also probably not even be thinking about that low latency case, because you should treat it as a service outside of your control, that may be (and probably should be) cross regionally available (so you might even be crossing the country, for all you know. This presumes the inclusion of latency based routing with a custom DNS, of course, but for a standalone, client facing service, that's what you should be doing anyway).
Obviously there may be a middle ground you want, but I'd say you probably either want to treat it as "your" API, and thus, you can be as pragmatic as you want when accessing it, or you want to treat it as a reusable, completely separate service, that you are a client of, in which case things like location can not be guaranteed, and thus latency is a reality.
>If it's internal, you probably shouldn't be using the API Gateway
It's common enough that when I asked Amazon about it, they already had enough requests that it's on the roadmap.
People use api gateways for all sorts of things like orchestration, tokenizing sensitive data, caching requests, etc, that should have the same interface whether used internally or externally. Sure, I could recreate all that functionality for internal use, but that's one of the supposed benefits of an API gateway...turn what was code into configuration. See products like Apigee, Kong, Tyk, etc.
Per your OP, how do you plan on caching requests without it hitting Cloudfront in some way? :P
But, I -did- mention there were caveats. Your correct in tha I should probably not have led with "You probably shouldn't", and -then- gotten more nuanced, though. While I agree that optimizing it to not leave the AWS network would be of benefit, if you reach the point you're calling it via the API Gateway internally, it's a separate service, and if it has -any- high availability requirements, or ever will, you should not be reliant on it not leaving the network (since even without going multi-region with distributed DNS, it may be handled by another AZ, introducing latency).
>Per your OP, how do you plan on caching requests without it hitting Cloudfront in some way?
Products that compete with Amazon's API gateway can do it, though you're right that their product cannot.
Edit: There are also AWS customers that use a different CDN...Akamai, Cloudflare, etc. Decoupling API gateway and Cloudfront would have benefit for them.
That said, it depends on your design/architecture as to whether that is appropriate or not. Sometimes you want that distinct separation. But if that's the case, you should also probably not even be thinking about that low latency case, because you should treat it as a service outside of your control, that may be (and probably should be) cross regionally available (so you might even be crossing the country, for all you know. This presumes the inclusion of latency based routing with a custom DNS, of course, but for a standalone, client facing service, that's what you should be doing anyway).
Obviously there may be a middle ground you want, but I'd say you probably either want to treat it as "your" API, and thus, you can be as pragmatic as you want when accessing it, or you want to treat it as a reusable, completely separate service, that you are a client of, in which case things like location can not be guaranteed, and thus latency is a reality.