Leverage CloudFront CDN with any HTTPS origin content

CloudFront can be used as a whole site CDN, including as a front for applications which serve a mix of semi-static and 0 TTL dynamic content. This can be a nice solution for interactive legacy applications, for example, something like a message board.

Consider these benefits:

  • AWS hosted origins only – All edge to origin requests traverse the optimized AWS private backbone network.
  • Any origin – When you restrict access to your origin to only CloudFront, you are insulating your origin services from DDoS attacks. This can be accomplished by injecting a pre-shared secret into the request header at the edge and rejecting requests without this value.
  • Any origin – When a viewer requests expired cache content from an edge location, the edge will not just fetch the origin content, it will first perform an HTTP HEAD request to check for changes. Only if the content differs from the cached copy will an origin GET be performed.
  • Any origin – CloudFront respects the origins cache-control HTTP header value to specify cache lifetime for the object, or optionally override them at the edge.
  • Any origin – Lambda at the edge! One useful use case for this is as an API adapter in situations where you do not want to make changes on the origin service. So rather than have to setup and manage proxy servers to transform requests, you can do this via CloudFront.

WordPress example

Let’s consider an example, you have just setup a new single EC2 instance on AWS hosting WordPress and want to leverage CloudFront. You want your domain apex: wastedbandwidth.org, to point viewers to your CloudFront distribution, backed by your WordPress origin server. To simplify the steps, you used Amazon as your domain registrar though that’s not a requirement.

Obviously this is not an optimal configuration as it makes assumptions to be generic.

Create Route53 DNS records

  1. CNAME record pointing to your origin server: origin.wastedbandwidth.org
  2. A record (Alias) pointing to your CloudFront distribution: wastedbandwidth.org


Configuring the origin server

  1. Enable SSL/TLS on the server using Let’s encrypt provides
  2. Install certbot to automate the certificate provisioning and configuration,
  3. Configure WordPress within wp-admin setting the site to be https://wastedbandwidth.org

Optional – if you do not have mail services for your new domain you can configure email forwarding using SES. 

When you request a new certificate using AWS certificate manager, confirmation emails will be sent to multiple email addresses associated with that domain. If don’t have a mail service for your domain, you can quickly setup an email forwarder using SES to receive the mail, fire an SNS event to invoke lambda, and script a simple handler in Lambda to process/store/forward it.

Create a CloudFront Web Distribution


Distribution Configuration

  1. Specify the AWS managed certificate that for wastedbandwidth.org that you requested earlier

Origin Configuration

  1. Specify your origin server: origin.wastedbandwidth.org
  2. Origin Protocol: 
  3. Origin Protocol Policy: 
  4. HTTPS Port: 443

Default Cache Behavior Settings

  1. Path Pattern: Default (*)
  2. Viewer Protocol Policy:
  3. Allowed HTTP Methods:  
  4. Whitelist Headers: Origin
  5. Object Caching:
    1. Minimum TTL 0
    2. Maximum TTL 0
    3. Default TTL 0
  6. Forward Cookies: All
  7. Query String Forwarding and Caching: Forward All

restrict origin requests to cloudfront

With the above, users/bots/attackers could access your site via CloudFront or directly using the origin.domain.com. For added security and optimization, you can restrict access to your origin by configuring cloudFront to inject a pre-shared secret as a header value. You can add these custom injected header values into your origin configuration settings. Your origin can then reject all traffic without this header.

Worth sharing?