By using AWS re:Post, you agree to the Terms of Use
/How to reduce cloudfront origin connection ssl time/

How to reduce cloudfront origin connection ssl time


We have an elasticbeanstalk application with alb speaking to an ec2 instance in Virginia. The application latency is in itself less than 100ms but the initial connection (dns + tcp + ssl) is taking 600ms and 300ms is for the ttfb(of which 100ms is due to the app).So overall its taking 900ms. The subsequent requests are taking 300ms.

To optimise and reduce the initial connection time, we used cloudfront in front of the alb without any caching as ours is dynamic content. So we used cloudfront just for ssl termination.That helped in reducing the initial connection time to 120ms.But now the ttfb increased to 800ms. My assumption is that cloudfront is setting up a new connection(ssl) to the origin server for every request and that is increasing the latency and is now worse than without having cloudfront.
So is using cloudfront for ssl termination and without any caching is not useful as its making the situation worse?

How can we reduce the cloudfront to origin connection times.I increased the keepalive time on cloudfront to 60s, but still its only helping for certain requests and some requests are still taking the regular time(with connection setup to origin) ? How can I measure whats happening between cloudfront and origin ?

Without ideally increasing the servers, how can I best achieve reduced latency in the above case.

  • I enabled the loadbalancer logs and was able to find the below

    Origin Latency from logs: 0.059

    https 2022-04-14T12:07:34.438950Z app/awseb-AWSEB-@#$$$$$$$/33c31cf831229bd5 0.001 0.059 0.000 200 200 1091 15561 "GET HTTP/1.1" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/awseb-AWSEB-CO4F476RJ4O0/e54f61d50c1c75c9 "Root=1-62580e86-1411f5a823d9bc5f7dc1df7e" "" "session-reused" 0 2022-04-14T12:07:34.378000Z "forward" "-" "-" "" "200" "-" "-"

    which means, the connection was reused from cloudfront.But still it took 800ms for TTFB.We are accessing the server in virgina from mumbai region.The round trip latency is around 200ms.Puzzled why is the cloudfront node in mumbai where our request went to, is taking 800ms even though it used the same connection to alb which responded in around 60ms.Not sure something is wrong.

  • Well, given that the TLS session was reused, the TCP connection was not reused (please double-check adresses/ports). This means that a TCP three-way handshake had to be performed, and given a 200 ms RTT (which seems low for VA to Mumbai), 800 ms TTFB would appear to be within expectations.

  • Also the first field is https, ideally I expected cloudfront to use http2 with origin

  • I enabled the keepalive on cloudfront.So due to that tls session is reused ? I assumed that helps in reusing the tcp connection as well. How can I check if the tcp connection is reused ? Even if the tcp handshake was happening again, the rtt is 200 ms, so for a 3 way handshake it should be 300ms = (200 + 100) right ? So is using cloudfront a good option in this case as we donno for how many of the given requests, the tcp or tls session is reused.

1 Answers

I can only provide a partial answer on how to measure what is happening between Cloudfront and origin.

If you enable access logging on the ALB, you will be able to determine TLS session reuse (value session-reused in the chosen_cert_arn field) and, by approximation, TCP connection reuse (HTTP keepalive) by matching up the client_ip, client_port, target_ip, target_port tuple.

answered a month ago
  • Sure.This helps a bit.

  • I added a comment to my question.Even the alb logs dont show high latency, not sure why cloudfront is taking that time.Even the same connection is used.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions