For the purposes of this guide, we are going to assume that you want to serve the standard
sp.js from CloudFront. To accomplish this, you will need the following:
- An account with Amazon Web Services
- S3 and CloudFront enabled within your AWS account
gzip and rename the file
sp.jsto a random 8 character string to reduce the chance of AdBlockers preventing the script from loading e.g.
gzipthe file to reduce the file size and reduce associated cloud storage and egress costs.
From a terminal / command prompt window, navigate to where you have downloaded the file and run:
gzip -c sp.js > gh7rnghq.js
N.B. on Windows you may need to download the gzip binaries
We will continue referring to the file as
sp.js throughout this guide, however where
sp.js is mentioned we are referring to your renamed and gzipped file.
Navigate to S3 within AWS and then create a new bucket within your Amazon S3 account to store
|Bucket Name||For example, |
|AWS Region||For example, |
|Block Public Access settings for this bucket||Deselect: Block all public access|
You can leave all other settings as their defaults.
Click Create Bucket.
- Navigate to your new bucket by clicking on your Buckets name
If you downloaded Version 3.0.0 then create a folder called
- Navigate into your new folder, click Upload, click Add Files and browse to your file
- Your file should now be present in the Files and folders section
- Click on Additoinal upload options to drop down to extra settings
- In the Access control list (ACL) pane, you must select Read within the Objects column on Everyone (public access) row. You may need to confirm you understand the effects of this change within the UI.
- Before uploading, we must now we will configure the required metadata for a gzipped file and the cache control for Cloudfront.
First we will set the
- Scroll down to the Metadata section within the Addtional upload options.
- Click Add Metadata
- Add Type: System defined, Key: Content-Encoding, Value: gzip
Now we will add the
- Click Add Metadata
- Add Type: System defined, Key: Cache-Control, Value: max-age=315360000
- Click Edit metadata
This sets your items to expire in 10 years, that is 10x365x24x60x60 = 315,360,000.
We recommend that you set the
Cache-Control max-age property on the file. This property determines both how long Cloudfront caches
sp.js in its edge locations, and crucially, how long individual browsers cache
sp.js before repinging Cloudfront for a fresh copy. By setting a long expiration date, you can reduce the number of browser requests for
sp.js, which can significantly decrease your Cloudfront costs.
The only disadvantage of a long expiration is that you need to find a way to force end users to fetch a fresh copy of
sp.js when you upgrade to a newer version. However as you have created a versioned folder, this is easily managed by saving your new version to a new folder in your S3 bucket, and updating your Snowplow tags to point to the new version.
Your metadata should now look something like this:
Create your CloudFront distribution
- Click Create Distribution and then Get Started
- Use the table below to set all the required options
|Origin Domain Name||[Bucket Name].s3.amazonaws.com |
|Other options||Leave as default|
Click Create Distribution and then you should see AWS beginning to create the distribution.
Note down your CloudFront distribution’s Domain Name – e.g.
You will need this later when you integrate Snowplow into your website.
Before testing, take a 10 minute coffee break (that’s how long CloudFront takes to synchronize).
If you have any problems, then double-check your CloudFront distribution’s URL, and check the permissions on your
sp.js file: it must have Read permissions for Everyone.