What is the benefit of adding AWS Cloudfront on top of AWS Application LB?

Question

I have attended an AWS training, and they explained to us that a good practice is to have cache all dynamic content via Cloudfront, setting TTL to 0, even if you have an LB in front on the Load Balancer. So it could be like:

Route 53 -> CloudFront -> Application LB

I can not see any advantage of this architecture, instead of having directly (only for dynamic content):

Route 53 -> Application LB

I do not see the point since Cloudfront will send all traffic always to the LB, so you will have:

• Two HTTPS negotiation (client <-> Cloudfront, and Cloudfront <-> LB)
• No caching at all (it is dynamic content, it should not be cached, since that is the meaning of "dynamic")
• You will not have the client IP since your LB will see only the Cloudfront IP (I know this can be fixed, to have the client IP, but then you will have issues with the next bullet).
• As an extra work, you need to be able to update your LB security groups often, to match the CloudFront IPs (for this region), as I guess you want to get traffic only from your Cloudfront, and not directly from the LB public endpoint.

So, probably, I am missing something important about this Route 53 -> CloudFront -> Application LB architecture.

Any ideas?

Thanks!

Answer 1

Here are some of the benefits of having cloudfront on top of your ALB

• For a web application or other content that's served by an ALB in Elastic Load Balancing, CloudFront can cache objects and serve them directly to users (viewers), reducing the load on your ALB.

• CloudFront can also help to reduce latency and even absorb some distributed denial of service (DDoS) attacks. However, if users can bypass CloudFront and access your ALB directly, you don't get these benefits. But you can configure Amazon CloudFront and your Application Load Balancer to prevent users from directly accessing the Application Load Balancer (Doc).

• Outbound data transfer charges from AWS services to CloudFront is $0/GB. The cost coming out of CloudFront is typically half a cent less per GB than data transfer for the same tier and Region. What this means is that you can take advantage of the additional performance and security of CloudFront by putting it in front of your ALB, AWS Elastic Beanstalk, S3, and other AWS resources delivering HTTP(S) objects for next to no additional cost (Doc).

• The CloudFront global network, which consists of over 100 points of presence (POP), reduces the time to establish viewer-facing connections because the physical distance to the viewer is shortened. This reduces overall latency for serving both static and dynamic content (Doc).

• CloudFront maintains a pool of persistent connections to the origin, thus reducing the overhead of repeatedly establishing new connections to the origin. Over these connections, traffic between CloudFront and AWS origins are routed over a private backbone network for reliability and performance. This reduces overall latency for serving both static and dynamic content (Doc).

• You can use geo restriction, also known as geo blocking, to prevent users in specific geographic locations from accessing content that you're distributing through a CloudFront distribution (Doc).

In other words you can use the benefits of ClodFront to add new features to your source (ALB, Elastic Beanstalk, S3, EC2) but if you don't need these features it is better not to do this configuration in your architecture.

Answer 2

• Cloudfront enables you deliver content faster because Cloudfront Edge locations closer to the user requesting and are connected to the AWS Regions through the AWS network backbone.
• You can terminate SSL at cloudfront and make the load balancer listen at port 80
• Cloudfront allows to apply geo location restriction easily in 2 clicks.