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.
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
- CNAME record pointing to your origin server: origin.wastedbandwidth.org
- A record (Alias) pointing to your CloudFront distribution: wastedbandwidth.org
Configuring the origin server
- Enable SSL/TLS on the server using Let’s encrypt provides
- Let’s encrypt provides SSL/TLS certificates for free:
- Install certbot to automate the certificate provisioning and configuration,
- Update the AWS security group associated with your EC2 instance, open port 443
- following the steps here for your stack: https://certbot.eff.org/
- 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
- Specify the AWS managed certificate that for wastedbandwidth.org that you requested earlier
- Specify your origin server: origin.wastedbandwidth.org
- Origin Protocol:
- Origin Protocol Policy:
- HTTPS Port: 443
Default Cache Behavior Settings
- Path Pattern: Default (*)
Viewer Protocol Policy:
- Allowed HTTP Methods:
Whitelist Headers: Origin
- Object Caching:
- Minimum TTL 0
- Maximum TTL 0
- Default TTL 0
- Forward Cookies: All
- 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.