Internal vs. External Endpoint Performance

We’re hosting an API in an Aptible app that is currently used externally (and is exposed via an external endpoint). We are going to be creating a new app in the same stack that acts as an intermediate (interoperability) API layer and will be hitting the same API that is also available externally.

Is there a performance advantage to creating a separate internal endpoint for the internal app to use (due to proxies, DNS, etc.), or would it be equivalent to just have the internal app use the existing external endpoint?

The anatomy of an Endpoint is the same regardless of placement. There’s still an AWS Load Balancer and Endpoint proxy container that sit in front of your application container. The main difference is if the Load Balancer accepts traffic from the internet or the Stack’s VPC.

I can’t find any details from AWS but Internal Endpoints likely have a slightly lower round-trip time (RTT) for requests, i.e. more performant, since all communication remains in the same VPC whereas communication with External Endpoints has to traverse the internet. That being said since the External Endpoint is in the same AWS region as the resource accessing it and inter-region communication is fairly performant so if there’s probably not much of a difference if any.

For many use cases, an External Endpoint is sufficient. If you’d like to compare the performance of the two I recommend timing the same request to both an External and Internal Endpoint on the same Service. You’ll likely need to use a tool like curl from an Ephemeral SSH Session in order to access the Internal Endpoint. I found this article useful for using curl to time requests. Keep in mind that the additional Endpoint has a cost associated with it.

Thanks so much for the quick and thorough response, it was very helpful. I tested response times using the link you provided, and as expected the times were basically equivalent.