Bobcares

Accelerate drupal with CloudFront

by | Jan 17, 2023

Wondering how to accelerate drupal with CloudFront? Our Drupal Support team is here to lend a hand with your queries and issues.

How to accelerate drupal with CloudFront?

Today, let us see the steps followed by our Support techs to accelerate drupal with CloudFront.

1.The Path Module allows us to create URL aliases for our content.

By default, Drupal creates URL patterns like https://www.mydrupalwebsite.com/node/2.

When we consider adding a Content Distribution Network, URL aliases also allow us to define the paths within our website, optimising for the type of content they hold.

The Path module allows us to take the URL we just discussed, and alias it into something like https://www.mydrupalwebsite.com/images

2.Within Drupal 8 Administration you will find that “Aggregate CSS files” and “Aggregate JavaScript files” are enabled by default.

This helps reduce the bandwidth requirements between our Origin AWS infrastructure, and the CloudFront Edge nodes.

3.On the same page, you can see that Internal Drupal caching is disabled by default.

This controls the maximum time a page can cache by browsers and proxies, controlled through the value for max-age in Cache-Control headers.

Even if we define a value for this, we can override that setting through the controls offer in Amazon CloudFront, providing us a single interface to control these TTL values.

There is CDN Module, changes file URLs so that CSS, JavaScript, images, audio, and videos can cache within CloudFront more easily.

It also changes the URL when a file is changed by a user in Drupal.

To enable the module, go your Drupal Administration site, and click the Extend Tab.

From there, click the blue button for “+ install new module.”

I looked up the latest version supporting Drupal 8, and provided the URL to the .tar.gz file.

With the module installed, I scrolled down to the bottom of the Extend Tab and enabled both the CDN and CDN UI modules.

Now let’s head over to the AWS Management Console, and use the CloudFront console to create our CloudFront distribution.

Then, we will select Web as the Distribution type.

From there, you can see the following sections, which need to fill in.

Origin Domain Name :

CloudFront is integrated into many AWS services, so it knows about the AWS infrastructure deployed in my AWS account.

I simply scroll down through the list until I find the Application Load Balancer sitting in front of my Drupal EC2 instances.

Origin SSL Protocols:

I have chosen to remove support for TLS 1.

This is entirely your choice and based on the security or risk position you want to take for your own application.

Origin Protocol Policy:

I want to ensure all communications from CloudFront to my Origin occur over HTTPS.

I have enabled the HTTPS Only setting.

Origin Custom Headers :

In some application deployments, you will want to ensure all visitors reach your website using CloudFront.

You may want to stop people going around it, communicating directly with your Origin endpoint.

Using Origin Custom Headers, I can create a “Header Name” and “Value” and add them to my CloudFront distribution.

You can use any values you want, just make sure you take note of them.

With that done, I can then create an AWS WAF ACL to my Application Load Balancer, using a String Matching Condition, which looks for an exact match on the Header Name and Value I have just created.

Section Two: Default Cache Behavior Settings

Viewer Protocol Policy:

I want to ensure that all communications between CloudFront and the viewers of my website are encrypted using HTTPS.

So I change this setting to Redirect HTTP to HTTPS, this means visitors to my website are automatically redirect if they don’t specify a secure connection.

Allowed HTTP Methods:

As with WordPress, my Drupal website supports the use of Forms, so I want CloudFront to support the additional POST HTTP methods for form submissions.

Whitelist Headers:

I want to control how CloudFront caches content. Since Drupal supports multi-site configurations.

I have chosen to cache the Host header, along with the Origin header and the forwarded protocol headers.

Object Caching:

Earlier in this blog I referred to native caching capabilities in Drupal, which include the ability to declare the minimum TTL for objects served from my Drupal origin.

Here you can opt to either leverage the values coming from Drupal, in which case select Use Origin Cache Headers, or if you want to override these values, or control them within CloudFront.

Then select Customize and apply a Default TTL which you want to the default caching period your clients are given.

Forward Cookies:

I recommend that you enable the Whitelist feature and add in the cookies that you would like to be forwarded to your Origin.

Drupal supports a variety of cookie session controls, natively as well as through the Community Modules.

This is particular to your configuration so play with this setting.

Query String Forwarding and Caching:

Drupal makes use of query strings within the URL.

Therefore, I have set this parameter to forward all to my Origin.

If you can refine this down to a whitelist, based on your Drupal application configuration, then you will be able to improve your cache-hit ratio.

Try and ensure static content is presented through static paths, making use of the Path Module where appropriate.

Compress Objects Automatically:

If objects received by CloudFront from the Origin are not compressed, then I want CloudFront to do this for me.

Setting this flag to True means that where possible, CloudFront will compress these objects.

AWS WAF Web ACL:

I recommend that even if you don’t plan to use AWS WAF in the first place that at the very least you enable a blank WAF ACL for each of your CloudFront distributions.

The reason for this is that it takes far less time to add a rule to an empty web ACL than it takes to modify your CloudFront distribution globally to include a Web ACL in its distribution settings.

If you are ever under an attack, then time to respond will be important to you.

This design approach allows you to make effective changes as fast as possible.

Alternative Domain Names:

Here I have added the real Fully Qualified Domain Name(s) for my website, allowing this CloudFront distribution to respond to calls for my domain.

SSL Certificate:

CloudFront offers two options for hosting TLS/SSL certificates.

The default option is to serve only clients that support Server Name Indication (SNI).

With this default option CloudFront associates your certificate with an IP address that is not dedicated to your distribution.

Logging:

I have chosen to configure CloudFront to log all viewer requests for files in my distribution, including logging of the cookies within that session.

This is optional and should enable if you need to collect this data.

Data is stored in Amazon S3.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion

To sum up, our Support Engineers demonstrated how to accelerate drupal with CloudFront

PREVENT YOUR SERVER FROM CRASHING!

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.

GET STARTED

0 Comments

Submit a Comment

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

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

Privacy Preference Center

Necessary

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]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

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
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

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

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

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.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF