Improving vProfile Performance with Amazon CloudFront

A practical walkthrough of placing Amazon CloudFront in front of the vProfile application to improve global delivery, reduce latency, and secure the public entry point with HTTPS.

After the vProfile application was fully deployed on Elastic Beanstalk, the next improvement was performance for users who are far away from the AWS Region hosting the application. This is where Amazon CloudFront becomes useful.

Instead of sending every request directly to the application load balancer from one central region, CloudFront introduces a global edge layer. It can cache eligible content closer to users and forward requests through AWS’s edge network to the origin.

Main idea: CloudFront improves delivery by placing a globally distributed layer in front of the application, which can reduce latency and offload repeated requests from the origin.

The Problem Before CloudFront

If the application is hosted in a single AWS Region, users near that region usually experience better response times than users in distant locations.

Users near the origin region -> Lower latency Users far from the origin -> Higher latency

That latency difference becomes more noticeable when users are distributed across different continents.

What CloudFront Does

Amazon CloudFront is AWS’s content delivery network. It uses a worldwide network of edge locations and routes viewers to the edge location with the lowest latency for them.

User -> Nearest CloudFront edge -> Origin when needed
If content is already cached at the edge, CloudFront can return it immediately. If not, it retrieves it from the origin and then serves it to the user.

Architecture Before and After

Before CloudFront

User -> Load Balancer -> Beanstalk EC2

After CloudFront

User -> CloudFront -> Load Balancer -> Beanstalk EC2

In this design, CloudFront sits in front of the load balancer and becomes the public-facing entry point for the application.

Choose the Correct Origin

For this setup, the correct CloudFront origin is the Application Load Balancer created for the Beanstalk environment, not the EC2 instances directly.

Origin = Application Load Balancer
Important: using the load balancer as the origin keeps traffic flowing through the intended application entry layer instead of bypassing Beanstalk’s load balancing design.

Create the CloudFront Distribution

The next step is to create a CloudFront distribution and point it to the load balancer origin. This adds the CDN layer in front of the running application.

  • Open CloudFront and create a new distribution
  • Select the Beanstalk load balancer as the origin
  • Review caching and protocol settings carefully

Viewer Protocol Policy

One of the key security-related settings is how CloudFront handles HTTP and HTTPS from viewers. For production traffic, redirecting HTTP to HTTPS is the cleaner choice.

Viewer protocol policy: Redirect HTTP to HTTPS

This makes sure users end up on a secure connection at the edge layer.

Allowed Methods and Caching

CloudFront can forward different sets of HTTP methods to the origin depending on the application needs. For dynamic web applications, this matters because not all traffic is simple static content.

Possible allowed methods: GET, HEAD GET, HEAD, OPTIONS GET, HEAD, OPTIONS, PUT, PATCH, POST, DELETE

If the application needs form submissions, APIs, or dynamic actions, the broader allowed-methods option may be required. But that does not mean every method is cached. CloudFront mainly caches responses for safe methods such as GET and HEAD.

HTTPS and Custom Domain Setup

To use a custom domain with CloudFront, the distribution must have an alternate domain name and a valid TLS certificate that covers that domain.

Alternate domain name: app.yourdomain.com

When using ACM with CloudFront, the certificate must be created or available in us-east-1. After attaching the certificate, the custom domain can be associated with the distribution.

CloudFront only supports ACM certificates for viewer connections when the certificate is in the US East (N. Virginia) region.

Update DNS to Point to CloudFront

Once the distribution is deployed and the custom domain is added, DNS needs to be updated so traffic goes to CloudFront instead of directly to the previous application endpoint.

Type: CNAME or alias Name: app Value: dxxxxx.cloudfront.net

The exact record type depends on the DNS provider and the domain setup, but the goal is the same: the custom domain should resolve to the CloudFront distribution.

Optional Security Layer with AWS WAF

CloudFront also works well with AWS WAF when the goal is to add request filtering and extra edge protection for web traffic.

  • Filter common web attack patterns
  • Apply rules at the edge before requests hit the origin
  • Add an extra control layer in front of the application

Final Architecture

User -> CloudFront -> Load Balancer -> Beanstalk EC2 -> RDS -> Memcached -> RabbitMQ

What I Learned

  • CloudFront improves delivery for geographically distributed users
  • The load balancer is the right origin for this Beanstalk setup
  • Viewer HTTPS policy is an important security decision
  • Custom domain and certificate setup must be handled carefully
  • CloudFront adds both performance and architectural polish

Conclusion

Adding CloudFront made the vProfile deployment feel more complete. Instead of exposing only a region-bound application endpoint, the project now uses a globally distributed front layer that improves delivery and gives more control over public traffic.

It also highlighted an important design lesson: performance is not just about bigger servers. Sometimes the better solution is to place content and traffic controls closer to users.

← Back to Blogs