Need help?

Our experts have had an average response time of 11.7 minutes in August 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

Set up Amazon CloudFront with WordPress site – How we do it

by | Mar 23, 2021

Wondering how to set up Amazon CloudFront with WordPress site? We can help you.

One of the easiest ways to improve the user experience is to accelerate one’s entire WordPress website by using CloudFront.

This will improve the site’s responsiveness by reducing the load on web servers. CloudFront can be configured to accelerate a website regardless of the website being hosted on AWS.

Here at Bobcares, we often handle requests from our customers to set up Amazon CloudFront with WordPress site as a part of our Server Management Services.

Today let’s see the Steps that our Support Techs follow for the setup.

Steps to Set up Amazon CloudFront with WordPress site

Before going into the steps we will see what is the importance of CloudFront on a WordPress site.

How does CloudFront help?

Amazon CloudFront improves the experience for users accessing websites in the following ways:

1.Firstly, Anycast DNS ensures that customers are routed to the nearest edge location.

2. Cached content, when available, is delivered to users from the edge location.

3.  When data needs to be fetched from our site, CloudFront optimizes network throughput by managing the transfers between Edge Locations and our website.

4. Finally, negotiating and offloading Transport Layer Security (TLS) at the CloudFront Edge and improving performance, reducing connection setup latency, and supporting back-end connection re-use.


Set up Amazon CloudFront with WordPress site

The simplified architecture above describes a common architecture for WordPress, with static content stored in AWS S3, and WordPress running on EC2, Lightsail, or another hosting facility.

Generally, WordPress stores everything locally on the webserver. However, there are several plugins that make it easy to move static content to S3 and one example is W3 Total Cache.

The main steps to configure CloudFront are:

1. Creating a distribution
2. Defining origin(s)
3. Configuring cache behaviors

Before creating a CloudFront distribution, we have to ensure that the site with www and non-www are resolving properly.

We can create a CloudFront Web distribution from the CloudFront console.

For this, we have to fill in the required details for the distribution.

The CloudFront console offers a drop-down listing the S3 buckets along with any Load Balancers configured in the AWS account to help avoid errors. We can simply type the DNS name or IP address if it not listed.


TLS/SSL certificates are made free by Amazon Certificate Manager. We can use this for use with CloudFront and AWS Elastic or Application Load Balancers.

Choose the SSL protocols that CloudFront may use when communicating with our WordPress site. This is relevant if we have configured the site to accept HTTPS traffic.

The Origin Protocol Policy determines how CloudFront communicates with Origin (WordPress server). We can choose to always have CloudFront use HTTP.

Timeouts & Ports

CloudFront allows users to configure the Origin response and Keep-alive timeouts.

If the site receives light traffic, it is good to increase the keep-alive timeout, possibly up to the maximum of 60 seconds.

This helps CloudFront to hold open TCP connections to Origin between requests for longer than the default behavior of closing connections if found idle for 5 seconds. As a result, it reduces the latency associated with re-establishing connections for subsequent users or page fetches.

Custom Headers

CloudFront has the ability to add user-specified headers to each request sent to the Origin, potentially overriding headers set by the viewer.

Default Cache Behavior Settings

The default settings are the “catch-all” behavior and must be appropriate for any request not handled by more specific rules.

We can configure CloudFront to redirect any HTTP requests to HTTPS. If we choose HTTPS Only, users may have to type the full https://url when they visit our site, unless they will always be following a link from another page to navigate there.


When the webserver is configured to host multiple sites the Host header determines the content that will be served.

It is better to set caching based on Whitelisted headers with both Host and Origin headers configured at a minimum.

Object Caching

WordPress, by default, does not set cache control headers such as Expires or max-age. We can install a plugin or configure ‘.htaccess’ files to set these headers. If we choose not to configure WordPress in this way, we can still have CloudFront cache content by choosing to customize under Object Caching.

When we configure Cache Control headers in WordPress we have to choose “User Origin Cache Headers”. The “Default TTL” setting tells CloudFront to cache objects for 300 seconds when the WordPress server does not configure caching headers.

We need to choose a lower default TTL if we want users to see comments soon after posting.


WordPress makes extensive use of cookies. We can forward cookies based on a whitelist.

Generally, the following cookies will be enough for most cases:


Query Strings

WordPress uses Query Strings to determine the content to return. With the “Compress Objects Automatically” option, CloudFront will compress certain files when the requesting viewer or browser includes the header: “Accept-Encoding: gzip”.

Distribution Settings

CloudFront configuration options that are relevant to a WordPress site is given below:


Certificate can be used with CloudFront in order to secure communications between users and the CloudFront edge location, in addition to securing the back-end traffic between CloudFront and the website.

Custom TLS/SSL Client Support

CloudFront offers two options for hosting TLS/SSL certificates. The default option is to serve only clients that support Server Name Indication (SNI).

SNI is an extension to the TLS protocol, supported by most modern browsers, that includes the domain name in the request header.

The alternative is to provide CloudFront dedicated IP addresses in each Edge location that hosts our distribution. In this case, a browser that does not support SNI will be able to negotiate a secure connection to the website.

Security Policy

CloudFront supports a variety of security policies that allow improving the security of web applications by enforcing, for example, TLS v1.2 and eliminate weak ciphers like RC4.

Default Root Object

This can be ignored for WordPress as the site will automatically be configured to serve index.php.


Depending on our requirements, we can choose to log HTTP requests handled by CloudFront, by an Elastic or Application Load Balancer, by WordPress server, or all of the above. The default is not to log all viewer requests.

Finally, we can add a comment, select “enabled” as the distribution state, and click create distribution.

Status: In Progress

Once we create the distribution, we will be redirected back to the CloudFront web console, where we can see our distribution listed with a status of “In Progress”. Next we can continue to specify Origins and Behaviors for the WordPress content.

Adding Origins & Behaviors

We need to select our Distribution and click the Distributions Settings button to edit the settings.

On the Origins tab, we should see one Origin, created during the initial setup.

Select Create Origin to add a source that CloudFront will request content from.

As WordPress is configured to store static content like images, CSS and JavaScript files in S3, add the S3 bucket as an Origin and configure appropriate Cache Behavior.

Next, from the Behaviors tab, we will create the configurations required.

Currently, we can see the Default(*) behavior only.

As the content is static, it should be very cacheable.

DNS Settings

In order to make the CloudFront configuration active for our domain, we have to update the DNS record, creating a CNAME or ALIAS pointing to CloudFront distribution’s DNS name.

However, before we make this change for all users, we can test the settings, overriding DNS for our own computer by editing the host’s file:

1. From a command line perform a DNS lookup on CloudFront distribution

dig 54 IN A 54 IN A

2. Pick any of the IP addresses returned and add to hosts file C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on a Mac or Linux system.

Append a line to the bottom of the file, it should look like this;

3. Now when we visit our site with our browser, the hosts file will overwrite DNS and we will be directed to CloudFront distribution for testing.

4. Finally, once the test seems to be successful, we can remove the entry from hosts file and in DNS create a CNAME pointing at our CloudFront Distribution DNS endpoint.

[Need Assistance? We are available 24*7]


To conclude we saw the steps that our support engineers follow to set up Amazon CloudFront with WordPress site.


Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.