- Newest
- Most votes
- Most comments
Using a VPC endpoint here isn't going to affect the latency in any noticeable way so I'd not recommend it unless you would like to use a private endpoint for other reasons (for example, reducing traffic through a NAT Gateway).
We don't provide any guidance as to the latency (shortest, longest, average) on API calls to AWS services. If you believe there is a problem the best suggestion I have is to raise a support case because the team can look at the Step Function as configured and determine if there are any problems with the service itself.
I'd also add that all AWS services are multi-tenant (in same way or another); and there will be variances in the time it takes to perform actions (API calls are a good example of this). We do our absolute best to ensure that all customers have "fair" access to the services and to reduce the effect of "noisy neighours" but it is inevitable in large-scale systems that the latency of some operations will vary sometimes.
You say "this (latency) is quite high and is a problem for us". What sort of latency do you require? And what is the Step Function doing? It might be the case that this isn't the best solution for the problem.
Relevant content
- Accepted Answerasked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 7 months ago
Thank you for the response. We need to ingest analytics data from many browsers and start an SFN execution for each event that is received. Currently that would add ~200ms response time to our API, which would make it slow. We also need to access DynamoDB, which is also slow (~150ms). The SFN workflow just does a bit of processing with Lambda functions. I was hoping for <100ms response times on average. I also tried testing with the AWS CLI but saw the same response times.
Curiously, running a DynamoDB query within AWS Console (which uses AWS JS SDK) is fast (30-40ms), but running the exact same query with AWS CLI gives a response time of ~150ms. The Step Functions API seems slow even in the AWS Console (inspecting my browser's network tab).
There are a lot of things that can add up to create latency. For example: When calling AWS services the underlying libraries have to set up a TCP connection (so there's a three-way handshake there) and then perform TLS negotiation (quite a few packets) and only then can the request be sent. You might consider writing the code such that it has those connections open all the time (this might be done by calling a "read" API when initialised) so that your other calls are then faster.
Yes, that is actually the conclusion I have come to as well. Because the AWS SDK is on a web server (event loop), a new TCP connection is created for each call. I will try to optimize this by keeping the HTTP connections alive after the first request by using an Envoy proxy or similar. Hopefully that will noticeably improve the time spent sending the API requests. Thanks a lot for the input, it is much appreciated!