Fastly FAQs

This guide describes Fastly's Request Collapsing feature, frequently used when creating advanced service configurations.

NOTE: This guide requires advanced knowledge of Varnish and the VCL language.

The basics

Request Collapsing causes simultaneous cache misses within a single Fastly datacenter to be "collapsed" into a single request to an origin server. While the single request is being processed by the origin, the other requests wait in a queue for it to complete. Two types of Request Collapsing exist:

Collapsing on a single cache server

Collapsing within the datacenter between cache servers

Each cache server will automatically queue duplicate requests for the same hash and only allow one request to origin. You can disable this behavior by setting req.hash_ignore_busy to true in vcl_recv.

Within a datacenter, not every cache stores every object. Only two servers in each datacenter will store an object: one as a primary and one as a backup. Only those two servers will fetch the object from origin.

How it works

In Fastly's version of Varnish, VCL subroutines often run on different caches during a request. For a particular request, both an edge node and a cluster node will exist (though a single cache can, in some cases, fulfill both of these roles). The edge node receives the HTTP request from the client and determines via a hash which server in the datacenter is the cluster node. If this cache determines it is the cluster node and has the object in cache, it fulfills both the edge node and the cluster node roles.

Certain VCL subroutines run on the edge node and some on the cluster node:

Edge Node: vcl_recv, vcl_deliver, vcl_log, vcl_error

Cluster Node: vcl_miss, vcl_hit, vcl_fetch, vcl_error

Determining if a cache is an edge or a cluster node

The fastly_info.is_cluster_edge VCL variable will be true if the cache currently running the VCL is the edge node and false if it is the cluster node.

Caveats

Keep in mind the following limitations when using the Request Collapsing feature:

Any req.http.* headers are not transferred from the cluster node back to the edge node. Remember this when writing advanced configurations that use headers to keep track of state. If you set a req.http.* header in any of the subroutines that run on the cluster node, expect that the change will not persist on the edge node.

A single, slow request to origin can sometimes cause a great many other requests for the same object to hang and fail. Because many requests for a single object are being collapsed down to one, they all succeed or fail based on the request that reaches the origin.

The Fastly Image Optimizer manipulates and transforms your images in real time and caches optimized versions of them. When an image is requested from your origin server, the Fastly Image Optimizer can perform one or more transformation tasks before serving and caching the optimized version. For example, you can resize, adjust quality, crop and trim, serve responsive images, and more.

cloud infrastructure security and compliance program

Getting started

To use the Fastly Image Optimizer, start by contacting sales to request access. Be sure to include the Service ID of the service for which image optimization should be enabled.

Setting up image optimization

Once we've enabled image optimization for your service, you can set up image optimization by following the steps in our guide to setting up image optimization. This is a four-step process:

Add a header.

Create a request condition.

Enable shielding.

Test an image.

Configuring basic image settings

The Fastly Image Optimizer supports a variety of image formats and applies specific settings to all images by default. Use the Fastly web interface to review and adjust the default settings as appropriate. See our instructions on reviewing and editing the default image settings for more information.

Using advanced image settings

To go beyond the basic image optimization and transformation settings in the Fastly web interface, you must change your existing image URLs by adding Fastly API query string parameters.

For example, if your image source existed at http://www.example.com/image.jpg, you would need to add ?<PARAMETER=VALUE> to the end of the URL to create the proper query string structure for Fastly to transform the image.

You can change existing URLs in your source by adding one or more Fastly URL API query string parameters directly to your sites HTML. You can also change them programmatically. For more information, see our section on changing image settings other than the defaults.

Using custom VCL with image optimization

If you're using custom VCL with the Fastly Image Optimizer, we recommend using the image optimization VCL boilerplate. This boilerplate is specially designed to work with image optimization. It also fixes several potential issues that can arise when using image optimization with our default VCL boilerplate.

Debugging

Running into problems? See our section on image optimization debugging for more information.

This article describes a product that may use third-party cloud infrastructure to process or store content or requests for content. For more information, see our .

Fastly's Real-Time Log Streaming feature can send log files to syslog-based logging software. Syslog is a widely used standard for message logging.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Adding syslog as a logging endpoint

Follow these instructions to add syslog as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Syslog Create endpoint button. The Create a Syslog endpoint page appears.

JSON feed

Fill out the Create a Syslog endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Syslog address field, type the domain name or IP address and port to which logs should be sent. Be sure this port can receive incoming TCP traffic from Fastly. See the firewall considerations section for more information.

In the Token field, optionally type a string prefix (line prefix) to send in front of each log line.

From the TLS menu, select No to disable encryption for the syslog endpoint, or Yes to enable it. When you select Yes, additional TLS fields appear.

In the TLS hostname field, optionally type the hostname used to verify the syslog server's certificate. This can be either the Common Name (CN) or Subject Alternate Name (SAN). This field only appears when you select Yes from the Use TLS menu.

In the TLS CA certificate field, optionally copy and paste the certification authority (CA) certificate used to verify that the origin server's certificate is valid. The certificate you upload must be in PEM format. Consider uploading the certificate if it's not signed by a well-known certification authority. This value is not required if your TLS certificate is signed by a well-known authority. This field only appears when you select Yes from the Use TLS menu.

In the TLS client certificate field, optionally copy and paste the TLS client certificate used to authenticate to the origin server. The TLS client certificate you upload must be in PEM format and must be accompanied by a client certificate. A TLS client certificate allows your server to authenticate that Fastly is performing the connection. This field only appears when you select Yes from the Use TLS menu.

In the TLS client key field, optionally copy and paste the TLS client key used to authenticate to the backend server. The TLS client key you upload must be in PEM format and must be accompanied by a TLS client certificate. A TLS client key allows your server to authenticate that Fastly is performing the connection. This field only appears when you select Yes from the Use TLS menu.

Click the Advanced options link of the Create a Syslog endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Syslog endpoint page as follows:

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on WAF logging for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Adding separators or static strings

To insert a separator or other arbitrary string into the syslog endpoint format:

Create a new header with the following fields:

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type any suitable header name (for example, http.X-Separator).

In the Source field, type any special character or string you want (for example, "|" ).

Reference the new header variable in the log format box for your specific provider (for example, req.http.X-Separator).

Syslog facility and severity

The syslog output includes the following facility and severity values:

1

2

facility: local0

severity: info

Firewall considerations

Syslog has limited security features. For this reason, it's best to create a firewall for your syslog server and only accept TCP traffic on your configured port from our address blocks. Our list of address blocks is dynamic, so we recommend programmatically obtaining the list from our whenever possible.

Fastly's Load Balancer allows you to create pools of origin servers that you dynamically manage using Fastly's Dynamic Servers feature to distribute and direct incoming requests. The benefits include:

support for any infrastructure deployments including any type of server instances and one or more datacenters, regions, or cloud providers

high availability of web applications when using health checks

compatibility with TLS termination, HTTP/2, and IPv6

server stickiness without requiring a cookie-based approach

implement any number of request routing rules/conditions to select a pool of origin servers

To set up Dynamic Servers, you attach a pool to a service, then add versionless origin servers that are stored separately from your VCL configuration. You can use the Fastly API to programmatically add, remove, and update pools and origin servers.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

How Dynamic Servers work

Like Edge Dictionaries and ACLs, Dynamic Servers have two major components: the pool and origin servers within it. Pools act as containers for origin servers that store the hostnames or IP addresses of servers to which incoming requests can be directed. Each pool is attached to a version of a service, but origin servers are versionless and any changes will become effective immediately.

When Dynamic Servers might be useful

Dynamic Servers might be useful for organizations that need to load balance requests among origin servers. They can be used to:

evaluate new server instance types and new software deployments.

independently scale individual microservices.

More specifically, they can be used as:

a Local Server Load Balancer (LSLB) where they are used to balance requests among origin servers within in a single region, such as AWS EC2 instances in the US East region, or within a single datacenter or on-premises location.

a Global Server Load Balancer (GSLB) where they are used to load balance requests among origin servers across any geographically distributed infrastructure deployments such as:

within multiple regions of an Infrastructure as a Service (IaaS) provider (e.g., AWS, GCP, Microsoft Azure).

between multiple IaaS providers (e.g., AWS, GCP, Microsoft Azure).

as part of hybrid infrastructure deployments that include a combination of on-premises origin servers or datacenters and IaaS providers.

Getting started

You'll need to follow these steps:

Create a pool in a working version of a service that's unlocked and not yet activated.

Add at least one origin server to the newly created pool, keeping in mind the limitations.

Activate the version of the service you associated with the pool.

Once the pool is created, properly associated, and filled with origin servers, it can be called in your service.

Limitations

Keep the following limitations in mind as you use Dynamic Servers:

Each Fastly service can be configured with up to five origin servers. Origin servers count as origins for the purposes of these limits. Contact [email protected] to enable more than five origin servers per service in your account.

Pools cannot be created with custom VCL. If you create a pool using the API, you can use the API to make changes to it and use custom VCL to interact with it.

Pools need at least one enabled server entry. Origin servers cannot be deleted when a pool only has one enabled entry left.

Origin server deletions are permanent. If you delete an origin server, it is permanently removed from all service versions and cannot be recovered.

When you delete a pool, you'll only delete it from the service version you're editing. Pools are tied to versions and can be cloned and reverted. When using pools, we want you to be able to do things like delete a pool from a current version of your service in order to roll back your configuration to a previous version using as few steps as possible.

Event logs don't exist for origin server changes. If you use the API to add, update, or remove an origin server, there will be no record of it. The only record of a change will exist when you compare service versions to view the point at which the pool was associated with the service version in the first place.

Fastly's Load Balancer allows you to create pools of origin servers that you dynamically manage using Fastly's Dynamic Servers feature to distribute and direct incoming requests. A pool is responsible for balancing requests among a group of origin servers. In addition to load balancing, pools can be configured to attempt retrying failed requests. Pools have a quorum setting that can be used to determine when the pool as a whole is considered up in order to prevent problems following an outage as origin servers come back up.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Creating a pool

To start using Dynamic Servers, you'll need to create an empty pool within a version of a service that's unlocked and not yet activated. Make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X POST https://api.fastly.com/service/<service_id>/version/<service_version>/pool -d 'name=<pool_name>&comment=<comment>'

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

{

"between_bytes_timeout": "10000",

"comment": "<comment>",

"connect_timeout": "1000",

"created_at": "2016-08-01T14:43:22+00:00",

"deleted_at": null,

"first_byte_timeout": "15000",

"healthcheck": null,

"id": "2IpWU5CGzPpbpGsABSDops",

"max_conn_default": "200",

"max_tls_version": null,

"min_tls_version": null,

"name": "<pool_name>",

"quorum": "75",

"request_condition": null,

"service_id": "<service_id>",

"shield": null,

"tls_ca_cert": null,

"tls_cert_hostname": null,

"tls_check_cert": 1,

"tls_ciphers": null,

"tls_client_cert": null,

"tls_client_key": null,

"tls_sni_hostname": null,

"type": "random",

"updated_at": "2016-08-01T14:43:22+00:00",

"use_tls": 0,

"version": "<service_version>"

}

Be sure to activate the new version of the service you associated with the pool after adding at least one origin server.

NOTE: Each Fastly service can be configured with up to five origin servers. Contact [email protected] to enable more than five origin servers per service in your account.

Viewing pools

To view a list of all pools attached to a particular version of a service, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" https://api.fastly.com/service/<service_id>/version/<service_version>/pool

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

[

{

"between_bytes_timeout": "10000",

"comment": "just my first pool",

"connect_timeout": "1000",

"created_at": "2016-08-01T14:43:22+00:00",

"deleted_at": null,

"first_byte_timeout": "15000",

"healthcheck": null,

"id": "2IpWU5CGzPpbpGsABSDops",

"max_conn_default": "200",

"max_tls_version": null,

"min_tls_version": null,

"name": "SP_Prod_Pool_1",

"quorum": "75",

"request_condition": null,

"service_id": "<service_id>",

"shield": null,

"tls_ca_cert": null,

"tls_cert_hostname": null,

"tls_check_cert": 1,

"tls_ciphers": null,

"tls_client_cert": null,

"tls_client_key": null,

"tls_sni_hostname": null,

"type": "random",

"updated_at": "2016-08-01T14:43:22+00:00",

"use_tls": 0,

"version": "<service_version>"

}

]

To see information related to a single pool (in this example, SP_Prod_Pool_1) attached to a particular version of a service, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" https://api.fastly.com/service/<service_id>/version/<service_version>/pool/<pool_name>

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

{

"between_bytes_timeout": "10000",

"comment": "just my first pool",

"connect_timeout": "1000",

"created_at": "2016-08-01T14:43:22+00:00",

"deleted_at": null,

"first_byte_timeout": "15000",

"healthcheck": null,

"id": "2IpWU5CGzPpbpGsABSDops",

"max_conn_default": "200",

"max_tls_version": null,

"min_tls_version": null,

"name": "SP_Prod_Pool_1",

"quorum": "75",

"request_condition": null,

"service_id": "<service_id>",

"shield": null,

"tls_ca_cert": null,

"tls_cert_hostname": null,

"tls_check_cert": 1,

"tls_ciphers": null,

"tls_client_cert": null,

"tls_client_key": null,

"tls_sni_hostname": null,

"type": "random",

"updated_at": "2016-08-01T14:43:22+00:00",

"use_tls": 0,

"version": "<service_version>"

}

Deleting a pool

Deleting a pool deletes the pool and all of its associated server entries. To delete a pool, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X DELETE https://api.fastly.com/service/<service_id>/version/<service_version>/pool/<pool_name>

The response will look like this:

1

2

3

{

"status":"ok"

}

Fastly's Load Balancer allows you to create pools of origin servers that you dynamically manage using Fastly's Dynamic Servers feature to distribute and direct incoming requests. An origin server is an address (IP address or hostname) of a server to which the Dynamic Servers feature can forward requests. Fastly can then select any one of the origin servers based on a selection policy defined for the pool.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Creating an origin server

To add an origin server to the pool, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X POST https://api.fastly.com/service/<service_id>/pool/<pool_id>/server -d 'address=<hostname_or_ip_address>'

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"id": "6kEuoknxiaDBCLiAjKqyXq",

"service_id": "<service_id>",

"pool_id": "<pool_id>",

"weight": "100",

"max_conn": "200",

"port": "80",

"address": "<hostname_or_ip_address>",

"comment": "",

"disabled": false,

"created_at": "2016-06-20T08:20:36+00:00",

"updated_at": "2016-06-20T08:20:36+00:00",

"deleted_at": null

}

NOTE: Each Fastly service can be configured with up to five origin servers. Contact [email protected] to enable more than five origin servers per service in your account.

Viewing origin servers

To see information related to a single origin server, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" https://api.fastly.com/service/<service_id>/pool/<pool_id>/server/<hostname_or_ip_address>

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"id": "6kEuoknxiaDBCLiAjKqyXq",

"service_id": "<service_id>",

"pool_id": "<pool_id>",

"weight": "100",

"max_conn": "200",

"port": "80",

"address": "<hostname_or_ip_address>",

"comment": "",

"disabled": false,

"created_at": "2016-06-20T08:20:36+00:00",

"updated_at": "2016-06-20T08:20:36+00:00",

"deleted_at": null

}

To view a list of all origin servers attached to a particular pool, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" https://api.fastly.com/service/<service_id>/pool/<pool_id>/servers

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

[

{

"id": "6kEuoknxiaDBCLiAjKqyXq",

"service_id": "<service_id>",

"pool_id": "<pool_id>",

"weight": "100",

"max_conn": "200",

"port": "80",

"address": "<hostname_or_ip_address>",

"comment": "",

"disabled": false,

"created_at": "2016-06-20T08:20:36+00:00",

"updated_at": "2016-06-20T08:20:36+00:00",

"deleted_at": null

}

]

Enabling and disabling origin servers

You can enable or disable an origin server to control whether or not traffic is sent to it. Disabling an origin server allows you to remove it from the pool temporarily.

Enabling an origin server

Origin servers are enabled by default. To enable an origin server that has been disabled, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X POST https://api.fastly.com/service/<service_id>/pool/<pool_id>/server -d 'address=<hostname_or_ip_address>&disabled=false'

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"id": "6kEuoknxiaDBCLiAjKqyXq",

"service_id": "<service_id>",

"pool_id": "<pool_id>",

"weight": "100",

"max_conn": "200",

"port": "80",

"address": "<hostname_or_ip_address>",

"comment": "",

"disabled": false,

"created_at": "2016-06-20T08:20:36+00:00",

"updated_at": "2016-06-20T08:20:36+00:00",

"deleted_at": null

}

Disabling an origin server

To disable an origin server, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X POST https://api.fastly.com/service/<service_id>/pool/<pool_id>/server -d 'address=<hostname_or_ip_address>&disabled=true'

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"id": "6kEuoknxiaDBCLiAjKqyXq",

"service_id": "<service_id>",

"pool_id": "<pool_id>",

"weight": "100",

"max_conn": "200",

"port": "80",

"address": "<hostname_or_ip_address>",

"comment": "",

"disabled": true,

"created_at": "2016-06-20T08:20:36+00:00",

"updated_at": "2016-06-20T08:20:36+00:00",

"deleted_at": null

}

Deleting an origin server

To permanently delete an origin server, make the following API call in a terminal application:

1

curl -vs -H "Fastly-Key: FASTLY_API_TOKEN" -X DELETE https://api.fastly.com/service/<service_id>/pool/<pool_id>/server/<server_id>

The response will look like this:

1

2

3

{

"status":"ok"

}

NOTE: Pools must have at least one origin server. The API won't allow you to delete the last origin server in the pool.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

To serve secure traffic from Fastly using HTTPS, a website or application needs to provide clients with a valid TLS certificate signed by a trusted certification authority. Fastly offers a number of ways to deploy TLS certificates across our edge network.

This guide describes how to replace the keys and certificates used to terminate TLS for domains that have already been configured within the Fastly system. If you generate your own keys and certificates and transfer them to Fastly to install, contact [email protected] to see if you qualify for this interface.

Prerequisites

To upload new private keys and replace TLS certificates using the web interface, you will need:

a Fastly user account assigned the role of superuser, or assigned a user role with added TLS management permission

a valid X.509 TLS certificate from a trusted certification authority (CA)

a matching 2048-bit RSA private key

Known Issues

The web interface does not accept 4096-bit keys. If you have such a key you must use Fastly's certificate uploading tool to upload your key.

When replacing a certificate, the SAN entries of the new certificate must either be an exact match or contain a superset of entries when compared with the existing certificate. All existing domains will be automatically enabled on the new certificate.

Accessing the HTTPS and network settings page

To access the HTTPS and network settings page, log in to your Fastly account, click the Configure link, and then click the HTTPS and network tab.

[email protected]

This brings you to the TLS certificates page, which lets you view your certificates and private keys, and allows you to upload new keys and replace your existing certificates.

Replacing a key and certificate

To upload the new key and replace the certificate used to terminate TLS for a domain, first you must generate a new key and certificate with your preferred certification authority. When regenerating a new certificate, you must specify the exact same list of SAN entries as the existing certificate. The TLS certificates page will provide you with information on all of your current certificates and the SAN entries of each of those certificates. If you need to modify the SAN entries for a particular certificate, or if you need to add a brand new certificate for a new set of domains, contact [email protected] for assistance.

In order to replace a TLS certificate you will first need to upload the matching private key that was used to generate the new certificate.

On the TLS certificates page there is a drag-and-drop area that you can use to drop your private key file. Alternatively you can browse your file system for the private key. This upload tool currently only accepts 2048-bit RSA keys. If you require longer key lengths, contact [email protected]. Valid private keys will automatically upload to Fastly upon being dropped on the page, or after being selected from the file picker.

Upon successfully uploading a private key, the TLS certificates page will display the key with the label, Orphan key. This refers to a private key that has no matching TLS certificate. If you have multiple private keys, you will be able to identify each by a unique upload date time. Private keys can only be deleted if they are in the orphan state.

Once you have uploaded the new private key, you will be able to replace the TLS certificate. Find the certificate in the list of certificates. In the example below we show a certificate that is nearing expiration. You will see the Replace icon at the top-right corner. Clicking this icon brings up a file-picker that can be used to select the new certificate. The certificate you select should be PEM-formatted and must contain all the same SAN entries as the current TLS certificate, either as an exact matchinig list, or as a superset. You can select either a file containing the full certificate chain or a file containing just the leaf certificate. The intermediate certificates will be automatically backfilled when just the leaf certificate is uploaded.

After selecting the new certificate, a success message will be displayed and the certificate information will be updated. When a certificate is replaced, it will be automatically deployed and all domains actively serving TLS traffic on the old certificate will be automatically transitioned to the updated certificate within a matter of minutes.

NOTE: If the new certificate is not being used to serve TLS traffic within 1 hour, contact for assistance.

There may be situations where Fastly identifies certificates that should be replaced. These certificates will be clearly marked.

The Fastly WAF dashboard allows you to monitor the Fastly WAF deployed within your Fastly service. If you've been assigned the role of engineer or superuser, you can use the information in the Fastly WAF dashboard to determine whether or not the WAF is active, see how many requests the WAF is currently processing, and review recent configuration changes.

The Fastly WAF dashboard consists of the following pages:

WAF summary

WAF audit log

All WAF services

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Accessing the Fastly WAF dashboard

To access the Fastly WAF dashboard, follow the steps below:

Log in to the Fastly web interface. The All services page appears.

Stats page

Find your Fastly service in the list, and then click the WAF link. The WAF summary page appears.

If you have hundreds of services, you might want to jump to the All WAF services page for an overview of all your WAFs.

NOTE: To access the Fastly WAF dashboard, you must sign up for a Fastly account and purchase the Fastly WAF. Contact our sales team to get started.

About the WAF summary page

The WAF summary page displays the status of your WAF. The top of the page provides links to the All WAF services page, WAF audit log page, and Fastly control panel.

The WAF status section indicates whether the WAF is currently active. To be considered active, the WAF must not be disabled and must have at least one rule status set in either logging or blocking mode. You can see the total number of active rules. This number includes OWASP rules set to "active" and strict match rules set to blocking or logging. The charts show the number of active and disabled OWASP rules, application-specific rules, and Fastly-created rules. Sample charts are shown below.

The Requests graph displays how many requests are served from cache and how many requests are processed by the WAF. Of the requests that are processed by the WAF, the WAF Process graph displays how many requests were blocked by the WAF, logged by the WAF and sent to the origin server, and were passed (not blocked or logged) and sent to the origin server.

You can exclude certain data from the graphs by clicking the hide link next to a data label. Clicking this link will hide that value in the graph's display.

TIP: The Fastly WAF only executes on traffic sent to the origin server.

About the WAF audit log page

The WAF audit log page displays all configuration changes made to your WAF. You can use this page to determine who made certain types of configuration changes to the WAF, and when the changes were made. The line items indicate when rules were set to log or block, when they were updated, and whether they were disabled.

Some line items include changes for multiple rules. Click Show rule IDs to see all of the changes.

TIP: You can use the Fastly WAF rule statuses API endpoint to view the state of an individual rule.

Some entries contain information about the WAF's OWASP properties. To learn more about the OWASP properties, refer to the OWASP properties section.

OWASP properties

You may see OWASP properties referenced on the WAF audit log page. The table below contains a list of all available properties and their descriptions. The properties shown here reflect changes made by altering the settings in the OWASP object.

OWASP property

Description

Allowed HTTP versions

HTTP versions that a client is allowed to use.

Allowed HTTP methods

HTTP methods that a client is allowed to use.

Allowed client content types

HTTP Content-Types that a client is allowed to use.

Maximum length for parameter names

Maximum length of any parameter names passed in the query string and request body.

Maximum length for parameter values

Maximum length of any parameter values passed in the query string and request body.

Combined file sizes

Total size of MIME bodies in the request.

Critical anomaly score

Configured critical anomaly score. Rules using the critical severity will increment scores using this value.

Validate UTF8 encoding

Validates the client request as UTF-8 prior to the execution of WAF rules.

Error anomaly score

Configured error anomaly score. Rules using the error severity will increment scores using this value.

High risk countries

Block clients from high risk countries based on their IP address.

HTTP violation threshold

Configured HTTP violation threshold. Action is taken when rules that trigger HTTP violations exceed the threshold.

Inbound anomaly threshold

Configured inbound anomaly threshold. Action is taken when the sum of the individual category scores exceed the threshold.

LFI threshold

Configured LFI threshold. Action is taken when rules that trigger Local File Inclusion (LFI) rules exceed the threshold.

Maximum file size (bytes)

Maximum size of any MIME body in the request.

Maximum argument count

Maximum number of parameters in the query string and request body.

Notice anomaly score

Configured notice anomaly score. Rules using the notice severity will increment scores using this value.

Paranoia level

The paranoia level setting can be set from 1 through 4 and determines the number of rules to include by default. Higher levels indicate higher levels of security but potentially a larger number of false positives.

PHP injection threshold

Configured PHP injection score threshold. Action is taken when rules that trigger PHP related violations exceed the threshold.

RCE threshold

Configured RCE injection score threshold. Action is taken when rules that trigger Remote Code Execution (RCE) violations exceed the threshold.

Restricted extensions

Control on restricted file extensions in the client request.

Restricted headers

Control on restricted HTTP headers in the client request.

RFI threshold

Configured RFI violation threshold. Action is taken when rules that trigger Remote File Inclusion (RFI) violations exceed the threshold.

Session fixation threshold

Configured Session Fixation violation threshold. Action is taken when rules that trigger Session Fixation violations exceed the threshold.

SQLi threshold

Configured SQLi threshold. Action is taken when rules that trigger SQL Injection (SQLi) violations exceed the threshold.

Total parameter length

Maximum length of all parameters passed in the query string and request body.

Warning anomaly score

Configured warning anomaly score. Rules using the warning severity will increment scores using this value.

XSS threshold

Configured XSS threshold. Action is taken when rules that trigger Cross-Site Scripting (XSS) violations exceed the threshold.

About the All WAF services page

You can use the All WAF services page to monitor all of the WAFs deployed within your services. This page shows which of your services have WAFs, which WAFs are enabled, how many rules are enabled and disabled per WAF, and which configuration sets the WAFs are using. If a configuration set is out of date, a message is displayed alerting you it's time to update to the latest rule set.

About the WAF stats

The WAF stats graph appears on the . For the selected service, this graph shows blocked traffic that was stopped by the WAF based on rules, logged traffic that triggered rules but was sent to the origin, and passed traffic that didn't trigger rules and was sent to the origin.

Fastly provides a number of WAF-specific logging variables to help you monitor and identify potentially malicious traffic. These variables provide specific details about the actions Fastly WAF performed on a request.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Setting up a logging endpoint

To begin monitoring requests for potential malicious activity, set up remote logging so you can log WAF variables. You can use an existing logging endpoint or add a new endpoint specially for Fastly WAF. You'll use the information provided in the logs to monitor WAF events.

OWASP rules

A single request can trigger multiple OWASP rules. By default, logging occurs in vcl_deliver or vcl_log. When logs are captured in vcl_deliver or vcl_log, it will show the last WAF rule triggered and the cumulative anomaly score.

waf_debug_log

The waf_debug_log subroutine allows logging of each OWASP rule triggered for a single request. You can use the web interface or the API to update the logging placement parameter to waf_debug.

Using the web interface

Follow these instructions to set a logging endpoint's placement parameter to waf_debug:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Logging link. The Logging endpoints page appears.

Click the name of a logging endpoint to edit it. The Edit this endpoint page appears.

Click the Advanced options link.

In the Placement section, select the waf_debug (waf_debug_log) setting.

OWASP category score variables

Click the Update button.

Click the Activate button to deploy your configuration changes.

Using the API

You can also update the logging placement parameter to waf_debug by running the following cURL command in a terminal application:

1

curl -X PUT -H 'Fastly-Key: FASTLY_API_TOKEN' -H 'Content-Type: application/json' 'https://api.fastly.com/service/<your Fastly service ID>/version/<version_id>/logging/<logging_integration>/<logging_name>' --data-binary '{"placement":"waf_debug"}'

waf_debug_log accepts the logging format via the UI only

waf_debug_log is called in vcl_miss and vcl_pass. The logging format can include request headers and WAF variables. Response headers will result in an error message.

<logging_integration> can be found listed in our remote logging API.

We recommended creating a request_id header to track a single request through multiple OWASP rules:

1

set req.http.x-request-id = digest.hash_sha256(now randomstr(64) req.http.host req.url req.http.Fastly-Client-IP server.identity);

Using WAF-specific variables

Fastly provides a number of WAF-specific logging variables to help you monitor and identify potentially malicious traffic. These variables provide specific details about the actions Fastly WAF performed on a request:

Whether or not Fastly WAF inspected a request. Fastly WAF only inspects traffic that is forwarded to your origin server (e.g., MISS or PASS requests for content that is not already cached).

Whether or not a rule matched the request. When Fastly WAF inspects a request, it checks to see if the request matches any of the rules in your rule set.

The severity of the rule that matched. If the request matches a rule, the log indicates the severity of the rule.

The action taken, if any. If the request matches a rule or OWASP threshold, the log indicates whether Fastly WAF simply logged the request or blocked it.

You can use the following variables to examine Fastly WAF log events.

Variable

Description

waf.executed

A response header indicating if WAF was executed or not. Appears as 1 (true) when executed or 0 (false) when not.

waf.blocked

Set to true when the request matches and the specific rule or OWASP threshold is configured to block. Will appear in log files as 1 (true) when blocked or 0 (false) when not.

waf.logged

Set to true when the request matches and the specific rule or OWASP threshold is configured to log. In active (blocking) mode, set to true when waf.blocked is also true. Will show up in the logs as 1 (true) or 0 (false).

waf.failures

A request exits the WAF rule set due to a failure to evaluate. Will show up in the logs as 1 (true) or 0 (false).

waf.logdata

Why (specifically) this rule matched. Includes the portion of the request that triggered the match, so it may look different depending on the rule.

waf.message

A message describing the generic condition this rule matched. For example, SLR: Arbitrary File Upload in Wordpress Gravity Forms plugin.

waf.rule_id

The rule ID for this rule.

waf.severity

The severity of the rule. 0 is the highest severity and 7 is the lowest severity. 99 indicates that severity is not applicable (e.g., the request did not match any rules).

waf.anomaly_score

Cumulative score returned if request triggers OWASP rules. See .

waf.passed

Indicates if the request doesn't match any rules in the WAF rule set. Will show up in the logs as 1 (true) or 0 (false). waf.passed is readable in vcl_deliver and vcl_log. It is not readable in waf_debug_log. The value is determined after the request has gone through the WAF rule set.

OWASP category score variables

As a request goes through the OWASP rules, it can trigger different rule IDs from different attack categories. OWASP category score variables track which categories were triggered and the scoring that contributed to the cumulative score. They can be used to get a sense of minimum, average, and maximum values for a specific attack category and set thresholds individually. When in active (block) mode, if a request exceeds the category threshold, it will be blocked.

waf.sql_injection_score

waf.rfi_score

waf.lfi_score

waf.rce_score

waf.php_injection_score

waf.session_fixation_score

waf.http_violation_score

waf.xss_score

Fastly provides rule set updates to the Fastly WAF in a prompt manner to help protect customers against attacks.

For OWASP and Trustwave rules changes we use the following process:

We regularly review the rule changes as they happen in both the OWASP Core Rule Set and the Trustwave Rule Set.

We translate the rules into Varnish Configuration Language (VCL) to run inside our cache nodes.

We test the rules in our platform to ensure they perform adequately. We try to maximize performance and rule efficacy while reducing false positives.

We correct bugs, if any are found.

We propagate the rule set changes to our platform worldwide.

Finally, we will provide customers with a notification and instructions on how to make rule updates.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Rule set maintenance

The following links provide information about the updates and changes to the provided rule sets:

ID

Version/Date

Type of Change

Affected Rule Sets

6wvihQHbaCG7NBPTfm20S9

v122019-08-29

The OWASP Core Rule Set (CRS) was updated with 19 new rules that mitigate SQL injection, Content-Type anomalies, client side code injection, PHP injection, and remote code execution. In addition, 95 rules were updated in the OWASP CRS to enhance their effectiveness or reduce incidents of false positives.

The following rules were removed from the OWASP CRS: 920130, 920280, 920290, 921100, 941200, 941310, 941350, and 944220. Rules 941310, 941350, and 941200 specifically were removed due to performance issues that may impact your WAF.

Fastly Rules 4112012 and 4112031 have been updated to reduce incidents of false positives. Fastly Rule 4112030 was removed due to excessive false positives.

The Trustwave rules have been updated with 197 new rules, of which 44 are for WordPress and 94 for Joomla. These rules include better protections for customers using these platforms to publish web content.

Trustwave rules 217055, 2066577, and 2100097 were removed.

Some Fastly and Trustwave rules have been renumbered. Renumbering is handled transparently so there should be no impact to your production WAF objects.

OWASP

Fastly Rules

Trustwave

1PD2HFpi6qwkAsePake7pw

v112019-03-25

Introduced new Fastly rule 4170010, which detects CVE-2019-6340 (Drupal 8 core Highly critical RCE)

Introduced new Fastly rule 4170020, which detects the Magento Magestore Store Locator extension vulnerability

Updated Fastly rule 4112031 to include additional user agents

Updated Fastly rules 4113001, 4120010, and 4120011 to show correct match data

Removed OWASP rules 905100 and 905110, which would never match

Updated OWASP rules 932100 and 932110 to avoid false positives for Windows and UNIX command injection

OWASP

Fastly Rules

3vnl3cwPda9Q3WYCDRuGW

v102018-09-05

Introduced new OWASP rule 932190, which mitigates RCE (OS File Access Attempt) on low paranoia level WAF

Introduced new OWASP rule 941110, which mitigates XSS using script tag vector

Introduced new OWASP rule 944100, which mitigates RCE via Java deserialization vulnerabilities (CVE-2017-9805, CVE-2017-10271)

Introduced new OWASP rule 944110, which mitigates RCE via Java process spawn vulnerability (CVE-2017-9805)

Introduced new OWASP rule 944120, which mitigates RCE via Java serialization (CVE-2015-5842)

Introduced new OWASP rule 944240, which mitigates RCE via Java serialization (CVE-2015-5842)

Introduced new OWASP rule 944130, which detects suspicious Java classes

Introduced new OWASP rule 944250, which detects RCE via Java method

Introduced new OWASP rule 944200, which detects magic bytes being used that signal Java serialization

Introduced new OWASP rule 944210, which detects magic bytes being Base64 encoded that signal Java serialization

Introduced new OWASP rule 944220, which detects vulnerable Java class in use

Introduced new OWASP rule 944300, which detects Base64 encoded string that matched suspicious keyword

Introduced new Fastly internal rule 4134010, which mitigates CVE-2018-11776 Apache Struts v2 vulnerability

Introduced new Fastly internal rule 4113010, which detects suspicious X-Rewrite-URL header

Introduced new Fastly internal rule 4113020, which detects suspicious X-Original-URL header

Introduced new Fastly internal rule 4113030, which detects ESI directives in request

Introduced new Fastly internal rule 4113050, which detects ESI directives in body

Removed Trustwave rule 2200000, IP blocklist

Removed Trustwave rule 2200002, TOR Exit Nodes blocklist

OWASP

Fastly Rules

Trustwave

67LUkBwzFzESzumlU2L0T8

v92018-08-01

Introduced new Fastly internal rule 4134010, which mitigates common XXE attacks

Introduced new Fastly internal rule 4112019, which mitigates CtrlFunc Botnet Attack

Introduced new Fastly internal rule 4113001, which mitigates suspicious X-Forwarded-Host headers

Introduced new Fastly internal rule 4113002, which mitigates X-Forwarded-Host and Host headers that do not match

Introduced new Fastly internal rule 4120010, which detects illegal characters found in the client X-Forwarded-Host header

Introduced new Fastly internal rule 4120011, which detects illegal characters found in the client X-Forwarded-For header

Updated OWASP rule 930130 to include additional restricted files

OWASP

Fastly Rules

552NEtnDyzucKd3vTjLgFC

v82018-05-11

Added logdata fields to OWASP rules 920230, 920260, 920270, 920271, 920272, 920273, 920274, 920360

Introduce new Fastly internal rule 4170001, which mitigates Drupal sa-core-2018-004 attack

Adjust threshold rule 1010090 message

OWASP

Fastly Rules

6LG4xleIDKWLblCJczGpi9

v72018-03-28

Introduce new Fastly internal rule 4170000, which mitigates Drupal sa-core-2018-002 attack

Updated Fastly internal 4112060 Wordpress PingBack rule

Updated Fastly internal rules that protect against DDoS bots (Rule IDs: 4112013 and 4112016)

Fastly Rules

1D0OPmXjm6ZMOe9rMGAeQj

v62018-01-25

Update Trustwave rules to latest available

Introduce new Fastly internal rules to protect against DDoS bots (Rule IDs: 4112010-4112018, 4112030, 4112031, and 4112060)

Introduce new Fastly internal rule 10041 (which complements existing rule 10040) to block any HTTP POST body greater than 2 kibibytes in size that uses chunked encoding

Trustwave

Fastly Rules

2YXlqZJQxMkWyAjM4kggR3

v52017-11-13

Global update to OWASP 3.0.2 CRS release

Update Trustwave rules to latest available

Introduce new Fastly internal rule 10040 to block any HTTP POST body greater than 2 kibibytes in size.

OWASP

Trustwave

Fastly Rules

2vyJNHO7fngQYJXU8UGUY6

v42017-10-06

Updates to rule 932140 to account for SAML false positives in Windows

Reintroduction of missing transforms on some OWASP rules

Introduction of Fastly internal rule to protect against CVE-2017-9805

OWASP

Fastly Rules

4Z09wgjp7do8NrOIzlckFS

v32017-08-14

Reintroduction of individual threshold variables: http_violation_score_threshold, lfi_score_threshold, php_injection_score_threshold, rce_score_threshold, rfi_score_threshold, session_fixation_score_threshold, sql_injection_score_threshold, xss_score_threshold

Removal of unused threshold variables: brute_force_counter_threshold, dos_counter_threshold, outbound_anomaly_score_threshold, trojan_score_threshold

Additional bug fixes in OWASP rule set

OWASP

Trustwave

39EE4tZnEM9Q8hxFJMHYU5

v22017-04-26

Global update to the OWASP CRS 3.0 rule set

New Fastly rule for the February 2017 Wordpress Code Injection

New Fastly rule for the March 2017 Apache Struts RCE exploit

Updated Trustwave content inspection rules

OWASP

Trustwave

Fastly Rules

RSS and JSON feeds

You can keep tabs on new rule sets by following our RSS and JSON feeds.

Updating to the newest rule set

Follow these instructions to update a WAF to use the newest rule set.

Reviewing the current rule set

Before updating your WAF to a new rule set, we recommend that you record the value of your WAF's currently active rule set. You can use this information to revert your WAF to its previous state.

Run the following cURL command in a terminal application to find the currently active rule set:

1

2

curl -s -H Fastly-Key:<your Fastly API token> -H Accept:application/vnd.api+json \

https://api.fastly.com/service/<your Fastly service ID>/version/<your service version number>/wafs/<your WAF ID>

TIP: You can use this API endpoint to find your WAF's ID.

The output from the cURL command is shown below. In the relationships object, notice that this WAF is using <ID of your active configuration set>. Remember the ID.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

{

"data": {

"attributes": {

"last_push": null,

"prefetch_condition": null,

"response": null,

"version": "1"

},

"id": "<your WAF ID>",

"relationships": {

"configuration_set": {

"data": {

"id": "<ID of your active configuration set>",

"type": "configuration_set"

}

}

},

"type": "waf"

}

}

Changing the rule set version

Follow these instructions to change the rule set version for a WAF:

Find the ID of the new rule set version you want to use in the rule set maintenance section.

On your computer, create a new file called updated_relationship.json.

Copy and paste the following JSON into the file, replacing <your rules ID> with the ID of the rule set version you want to use:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"data": {

"id": "<your WAF ID>",

"relationships": {

"configuration_set": {

"data": {

"id": "<your rules ID>",

"type": "configuration_set"

}

}

},

"type": "waf"

}

}

Save the changes to the updated_relationship.json file.

In the directory you saved the file, run the following cURL command in a terminal application to change the rule set version for a WAF:

1

2

3

curl -s -X PATCH -H Fastly-Key:<your Fastly API token> -H Accept:application/vnd.api+json \

-H Content-Type:application/vnd.api+json -d @updated_relationship.json \

https://api.fastly.com/service/<your Fastly service ID>/version/<your service version number>/wafs/<your WAF ID>

Changing the rule set version for a WAF can take some time. Run the following cURL command in a terminal application to monitor the status of the process:

1

2

curl -s -H Fastly-Key:<your Fastly API token> -H Accept:application/vnd.api+json \

https://api.fastly.com/service/<your Fastly service ID>/version/<your service version number>/wafs/<your WAF ID>

The process is complete when the output displays the ID of the new rule set version.

Updating to the latest rules

After you've verified that the rule set for the WAF has successfully been changed, follow these rules to update your WAF with the latest rules:

Run the following cURL command in a terminal application to update the rule set:

1

2

3

curl -s -X PATCH -H Fastly-Key:<your Fastly API token> -H Accept:application/vnd.api+json \

-H Content-Type:application/vnd.api+json -d '{"data":{"id":"<your WAF ID>","type":"ruleset"}}' \

https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/ruleset

The response will look like this:

1

2

3

4

5

6

7

8

9

10

11

{

"data": {

"id": "WAF_ID",

"type": "ruleset"

},

"links": {

"related": {

"href": "https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/update_statuses/<update status ID>"

}

}

}

Updating the WAF with the latest rules can take some time. Using the URL in the response in the previous step, run the following cURL command in a terminal application to monitor the status of the process:

1

2

curl -s -H Fastly-Key: FASTLY_API_TOKEN -H Accept:application/vnd.api+json \

https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/update_statuses/<update status ID>

The response for the waf_update_status will have a status of complete when the process is complete.

1

2

3

4

5

6

7

8

9

10

11

12

13

{

"data": {

"attributes": {

"completed_at": "2017-04-05 18:47:28 UTC",

"created_at": "2017-04-05 18:47:27 UTC",

"message": null,

"status": "complete",

"updated_at": "2017-04-05 18:47:28 UTC"

},

"id": "<update status ID>",

"type": "waf_update_status"

}

}

Reverting to a previous rule set version

If a WAF rule set update doesn't go as planned, you can revert to the previous rule set version. Using the previous rule set ID you recorded in the reviewing the current rule set section, follow the instructions in changing the rule set version and updating to the latest rules.

The Fastly WAF provides rules that detect and block potential attacks. The rules are collected into a policy and deployed within your Fastly service at the edge.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

Inspecting the Fastly WAF rule set

You can inspect your Fastly WAF rule set at any time. By making an API call, you can download all of the data associated with your Fastly WAF rules. To inspect your Fastly WAF rule set, run the following cURL command in a terminal application:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/ruleset | perl -pe 's/\\n/\n/g'

NOTE: The | perl -pe 's/\\n/\n/g' is optional and can assist with formatting.

Inspecting the VCL of a WAF rule

To inspect the VCL of a specific Fastly WAF rule, run the following cURL command in a terminal application:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' https://api.fastly.com/wafs/<your WAF ID> /rules/<rule_id>/vcl

See the API documentation for more information.

Blocking requests

When you start using Fastly WAF for the first time, all rules are set to log status to minimize false positives. We recommend you monitor the logs for a minimum of two weeks to make sure that the rules will not block legitimate requests to your web application. Requests will not be blocked until you switch one or more rules from log to block status.

Changing the status of rules

To change a rule from log status to disabled or block status, inspect your rule set or review your logs to find the waf.rule_id variable. Then, run the following cURL command in a terminal application for each rule:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' -X PATCH -d '{"data": {"id": "<your WAF ID>-<WAF rule ID>", "type": "rule_status", "attributes":{ "status": "block"}}}' -H 'Content-Type: application/vnd.api+json' https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/rules/<WAF rule ID>/rule_status

To change the status of a group of rules, use a filter-tag (e.g., application-WordPress, language-html, or OWASP) by running the following cURL command in a terminal application:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' -X POST -d '{"data": {"id": "<your WAF ID>", "type": "rule_status", "attributes": {"name": <tag>, "status": "block"}}}' -H 'Content-Type: application/vnd.api+json' https://api.fastly.com/service/<your Fastly service ID>/wafs/<your WAF ID>/rule_statuses

NOTE: When changing rule statuses for a group of rules using a filter-tag, the above API call will preserve the status of any disabled rules updated individually. If all rules under the filter-tag should be forced to have a log or block state, add the parameter force:true under attributes in the request body.

See the API documentation for more information. When you've finished setting rules to block status, you'll need to activate the changes.

NOTE: If you need to enable more than 1,000 rules, contact our customer support team at [email protected].

OWASP Configuration

OWASP blocking is dependent on the following:

All OWASP rules (excluding rules changed from log to disabled mode) set to block mode.

Threshold limits set for the cumulative score and attack categories.

If a request triggers OWASP rules, it returns attack category scores and a cumulative score. If any of the final scores exceed the threshold limit and the OWASP rules are in block mode, Fastly sends the custom error response to the user.

Viewing OWASP settings

To view your OWASP settings, run following cURL command in a terminal application:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' https://api.fastly.com/service/<service_id>/wafs/<your WAF ID>/owasp

The cumulative anomaly score is displayed in the inbound_anomaly_score_threshold field.

Changing OWASP settings

To change any OWASP settings object, run the following OWASP update command in a terminal application:

1

curl -X PATCH -v -H "Content-Type: application/vnd.api+json" -H "Accept: application/vnd.api+json" -H "Fastly-Key: FASTLY_API_TOKEN" https://api.fastly.com/service/<service_id>/wafs/<waf_id>/owasp -d '{"data": {"attributes":{"inbound_anomaly_score_threshold":"50"}, "id":"<owasp_id>", "type":"owasp"}}'

When you've finished modifying OWASP settings, you'll need to activate the changes.

Activating changes

After you modify the status of one or more rules, you must activate the changes by running the following cURL command in a terminal application:

1

curl -H 'Fastly-Key: FASTLY_API_TOKEN' -X PATCH -d '{"data": {"id": "<your WAF ID>", "type": "ruleset"}}' -H 'Content-Type: application/vnd.api+json' https://api.fastly.com/service/ID/wafs/ID/ruleset

See the API documentation for more information.

Rules are versionless. Any changes to the rules will become effective after you run the command shown above. You won't need to activate a new version of your service to have the changes take effect.

Fastly offers a Web Application Firewall (WAF) security product that allows you to detect malicious request traffic and log or log and block that traffic before it reaches your web application. The Fastly WAF provides rules that detect and block potential attacks. The rules are collected into a policy and deployed within your Fastly service at the edge. To get started, email our sales team for product information.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

How the Fastly WAF works

The Fastly WAF is designed to protect production web applications running over HTTP or HTTPS against known vulnerabilities and common attacks such as cross-site scripting (XSS) and SQL injection. The Fastly WAF can provide a layer of protection logically positioned at the client edge of your distributed application to detect and block malicious activity from exploiting vulnerabilities in web applications and APIs.

Fastly's assigned IP ranges

Like traditional network firewall appliances, Fastly WAF uses predetermined security rules to monitor and control incoming traffic to your web application. A network firewall works at the IP level and often blocks IP addresses from untrusted networks, preventing them from gaining access to a private network. Unlike firewalls at the network or transport layer level, the Fastly WAF works by analyzing web traffic primarily at the HTTP application layer. It reads all HTTP(S) headers and the post body of the HTTP(S) requests that it inspects and runs them through a rule set selected for your service environment.

Fastly provides a default WAF rule set to which you can add additional rule sets to help protect against application-specific attacks. Once the Fastly WAF is enabled for a version of your service, you can change the status of any individual rule to logging, blocking, or disabled mode. Rule changes are versionless and become effective immediately.

NOTE: The Fastly WAF only works when traffic is directed through it. Make sure that you've signed up for Fastly, created a service, and added a CNAME DNS record for your domain name to direct traffic to Fastly and through the Fastly WAF.

Enabling the Fastly WAF

Enabling Fastly WAF doesn't require modifications to your web application or origin servers. Contact our sales team to get started.

Refining the default WAF policy once it's enabled

Once you purchase the Fastly WAF, our customer support team will enable it with the default WAF policy for any service you've provided a service ID for. They will then work closely with you on additional configuration refinements, including:

setting up a logging endpoint,

selecting rule sets and a prefetch condition, and

optionally customizing the request responses.

You can then begin monitoring logs to determine which requests to your origin are legitimate and which you should consider blocking to protect your origin.

Setting up a logging endpoint

To begin monitoring requests for potential malicious activity, set up remote logging so you can log WAF variables. You can use an existing logging endpoint or add a new endpoint specially for Fastly WAF. You'll use the information provided in the logs to monitor WAF events.

Selecting rule sets

Fastly provides a default WAF rule set based on Trustwave ModSecurity Rules and the OWASP Top Ten. The default rule set is designed to help you monitor web application traffic for a wide range of common attacks.

Fastly adds a default prefetch condition (!req.backend.is_shield) for the WAF policy. This ensures that the Fastly WAF inspects traffic to the origin and accounts for whether or not a service has shielding configured.

You can modify the prefetch condition. For example, you could update the prefetch statement to run the WAF rule set on origin traffic and requests from IP addresses that aren't allowlisted:

1

curl -v -X PUT https://api.fastly.com/service/<your Fastly service ID>/version/<version_id>/condition/Waf_Prefetch -H "Fastly-Key: FASTLY_API_TOKEN" -H "Content-Type: application/json" -d '{"statement":"!req.backend.is_shield && !(client.ip ~ allowlist)"}' -H "Accept: application/json"

Fastly can add additional rule sets for specific applications or technologies (e.g., WordPress, Drupal, PHP, .Net). Keep in mind that adding additional rule sets can increase latency for requests being evaluated against the published WAF policy.

Once you've selected rule sets, Fastly will maintain rules sourced by Fastly to keep them current. However, you'll need to notify us if you modify the applications or technologies that are present at the origin.

Customizing the response

Fastly's customer support team creates a custom response and assigns an HTTP status code for all requests that Fastly WAF blocks. If you've configured Fastly WAF to block requests, that response will be served directly from the cache when a request matches a rule. If you would like to customize the response, use the web interface to change the following:

MIME Type: The content type of the response.

Response: The content served when delivering the response.

TIP: You can create a custom HTML error page that will be presented to users who are blocked by the Fastly WAF response object. For more information, see our guide on creating a custom WAF error page.

WARNING: Do not modify the Status or Description of the Fastly WAF response that customer support creates for you.

Monitoring the Fastly WAF

You can use the Fastly WAF dashboard to monitor the Fastly WAF deployed within your Fastly service.

Disabling Fastly WAF for your service

Contact our customer support team at [email protected] to disable the Fastly WAF for your service.

Limitations

All WAF products that exist today have several limitations:

False positives: Any WAF can mistake good traffic for bad. This is why we strongly recommend that you monitor your logs for a minimum of two weeks before blocking traffic. You don't want start blocking traffic with rules that are generating false positives.

DNS configuration: A WAF only works when traffic is directed through it. It cannot protect against malicious requests that are sent to domain names or IP addresses that are not specified in your WAF configuration.

Effective rule sets: A WAF is only as effective as its rule sets. You should add rule sets as necessary to protect your specific web application.

Custom application vulnerabilities: If attackers discover a vulnerability unique to your application or the technologies you use, and your WAF configuration does not have a rule to protect against exploits for that particular vulnerability, it will not be able to protect your application in that instance. Customer support can work with you to add additional rule sets to help protect against these types of attacks. If you need more protection than the rule sets provide, customer support can work with you to create custom VCL to help block malicious requests.

Inspection of HTTP and HTTPS traffic only: A WAF only inspects HTTP or HTTPS requests. It will not process any TCP, UDP, or ICMP requests.

LA limitations

The Fastly WAF is part of a limited availability release and it has the following limitations:

Inspecting the WAF rule set is challenging due to formatting issues with cURL.

Changes are managed via the API.

Security products note

IMPORTANT: To ensure your web application only receives traffic from your WAF-enabled Fastly service, we strongly recommend you configure TLS client authentication for that service and allowlist .

No security product, such as a WAF or DDoS mitigation product, including those security services offered by Fastly, will detect or prevent all possible attacks or threats. Subscribers should maintain appropriate security controls on all web applications and origins, and the use of Fastly's security products do not relieve subscribers of this obligation. Subscribers should test and validate the effectiveness of Fastly's security services to the extent possible prior to deploying these services in production, and continuously monitor their performance and adjust these services as appropriate to address changes in the Subscriber's web applications, origin services, and configurations of the other aspects of the Subscriber's Fastly services.

Fastly's Real-Time Log Streaming feature can send log files to Elasticsearch. Elasticsearch is a distributed, RESTful search and analytics engine.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

NOTE: This logging endpoint is disabled by default. To enable this endpoint for your account, contact [email protected] and request it.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Elasticsearch as a logging endpoint for Fastly services, ensure Elasticsearch is running on a remote server. Youll need to know the endpoint URL that includes a port to which logs should be sent (make sure it can receive traffic from Fastly) and also the name of the index to send logs to. For more information on setting up Elasticsearch, see the Elasticsearch setup documentation.

Adding Elasticsearch as a logging endpoint

Follow these instructions to add Elasticsearch as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Elasticsearch Create endpoint button. The Create an Elasticsearch endpoint page appears.

WAF logging

Fill out the Create an Elasticsearch endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, enter the data to send to Elasticsearch. See the example format section for details.

In the URL field, type the Elasticsearch endpoint URL that includes a port to which logs should be sent. Be sure this port can receive incoming TCP traffic from Fastly.

In the Index field, enter the name of the Elasticsearch index to send logs to. The index must follow the Elasticsearch index format rules. We support strftime interpolated variables inside braces prefixed with a pound symbol. For example, #{%F} will interpolate as YYYY-MM-DD with today's date.

In the Maximum logs field, optionally enter the maximum number of logs to append to a batch, if non-zero.

In the Maximum bytes field, optionally enter the maximum size of log batch.

In the BasicAuth user field, optionally enter your basic authentication username.

In the BasicAuth password field, optionally enter your basic authentication password.

In the TLS Hostname field, optionally type the hostname used to verify the server's certificate. This can be either the Common Name (CN) or Subject Alternate Name (SAN).

In the TLS CA certificate field, optionally copy and paste the certification authority (CA) certificate used to verify that the origin server's certificate is valid. The certificate you upload must be in PEM format. Consider uploading the certificate if it's not signed by a well-known certification authority. This value is not required if your TLS certificate is signed by a well-known authority.

In the TLS client certificate field, optionally copy and paste the TLS client certificate used to authenticate to the origin server. The TLS client certificate you upload must be in PEM format and must be accompanied by a client certificate. A TLS client certificate allows your server to authenticate that Fastly is performing the connection.

In the TLS client key field, optionally copy and paste the TLS client key used to authenticate to the backend server. The TLS client key you upload must be in PEM format and must be accompanied by a TLS client certificate. A TLS client key allows your server to authenticate that Fastly is performing the connection.

Click the Advanced options link of the Create an Elasticsearch endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Example format

Data sent to Elasticsearch must be serialized as a JSON object. Here's an example format string for sending data to Elasticsearch:

{

"timestamp":"%{begin:%Y-%m-%dT%H:%M:%S}t",

"time_elapsed":%{time.elapsed.usec}V,

"is_tls":%{if(req.is_ssl, "true", "false")}V,

"client_ip":"%{req.http.Fastly-Client-IP}V",

"geo_city":"%{client.geo.city}V",

"geo_country_code":"%{client.geo.country_code}V",

"request":"%{req.method}V",

"host":"%{req.http.Fastly-Orig-Host}V",

"url":"%{json.escape(req.url)}V",

"request_referer":"%{json.escape(req.http.Referer)}V",

"request_user_agent":"%{json.escape(req.http.User-Agent)}V",

"request_accept_language":"%{json.escape(req.http.Accept-Language)}V",

"request_accept_charset":"%{json.escape(req.http.Accept-Charset)}V",

"cache_status":"%{regsub(fastly_info.state, "^(HIT-(SYNTH)|(HITPASS|HIT|MISS|PASS|ERROR|PIPE)).*", "\\2\\3") }V"

}

Fastly's Real-Time Log Streaming feature can send log files to Apache Kafka. Kafka is an open-source, high-throughput, low-latency platform for handling real-time data feeds.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

NOTE: This logging endpoint is disabled by default. To enable this endpoint for your account, contact [email protected] and request it.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Apache Kafka as a logging endpoint for Fastly services, ensure Kafka is running on a remote server. Youll need to know the hostname or IP address of one or more servers (Brokers) and the category or feed name to which messages will be stored (Topic). For more information on setting up Kafka see the Apache Kafka Quickstart guide.

Adding Kafka as a logging endpoint

Follow these instructions to add Kafka as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Apache Kafka Create endpoint button. The Create an Apache Kafka endpoint page appears.

WAF logging

Fill out the Create an Apache Kafka endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Brokers field, type the hostname or IP address of one or more servers (Kafka brokers). Specify multiple servers using a comma-separated string.

In the Topic field, type the name of the topic to send logs to.

In the Write acknowledgement area, select the appropriate write acknowledgement a leader must receive before a write is considered successful.

In the Compression codec area, select the appropriate codec to use for compression of your logs.

From the TLS menu, select No to disable encryption for the Kafka endpoint, or Yes to enable it. When you select Yes, additional TLS fields appear.

In the TLS Hostname field, optionally type the hostname used to verify the server's certificate. This can be either the Common Name (CN) or Subject Alternate Name (SAN). If the hostname is not specified, the hostname of the first broker in the Brokers field will be used. This field only appears when you select Yes from the Use TLS menu.

In the TLS CA certificate field, optionally copy and paste the certification authority (CA) certificate used to verify that the origin server's certificate is valid. The certificate you upload must be in PEM format. Consider uploading the certificate if it's not signed by a well-known certification authority. This value is not required if your TLS certificate is signed by a well-known authority. This field only appears when you select Yes from the Use TLS menu.

In the TLS client certificate field, optionally copy and paste the TLS client certificate used to authenticate to the origin server. The TLS client certificate you upload must be in PEM format and must be accompanied by a client certificate. A TLS client certificate allows your server to authenticate that Fastly is performing the connection. This field only appears when you select Yes from the Use TLS menu.

In the TLS client key field, optionally copy and paste the TLS client key used to authenticate to the backend server. The TLS client key you upload must be in PEM format and must be accompanied by a TLS client certificate. A TLS client key allows your server to authenticate that Fastly is performing the connection. This field only appears when you select Yes from the Use TLS menu.

Click the Advanced options link of the Create an Apache Kafka endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly provides direct integration between PerimeterX Bot Defender and Fastly edge servers. By placing a snippet of JavaScript (or HTML5) on your site and custom VCL directly into your Fastly service configuration, this integration allows you to gather behavioral data and statistics that may help you do things like detect invalid traffic and mitigate automated web attacks.

IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.

How to get started

Integration with PerimeterX Bot Defender requires an account with PerimeterX. Once you have this account set up, contact your Fastly account manager or email [email protected] to begin the integration process with Fastly. We'll work with you to configure your service to include the required code to enforce bot mitigation policies.

This article describes an integration with a service provided by a third party. Please see our note on integrations.

This guide describes how to use Fastly TLS to enable HTTPS for a domain using a certificate managed by Fastly. Fastly-managed certificates use the ACME protocol to procure and renew TLS certificates from Lets Encrypt.

To serve secure traffic from Fastly using HTTPS, a website or application needs to provide clients with a valid TLS certificate signed by a trusted certification authority. TLS (Transport Level Security) and its predecessor SSL (Secure Sockets Layer) are the protocols that allow clients to form secure server connections so traffic can be served over HTTPS.

TIP: Our TLS subscriptions API allows you to manage Fastly TLS subscriptions programmatically.

Before you begin

To use Fastly TLS with Fastly-managed certificates, be sure you have the following prerequisites in place:

a paid Fastly user account (not a developers trial) assigned the role of superuser or assigned a user role with added TLS management permission

permission to modify the DNS records on the relevant domains that appear as SAN entries on the TLS certificate

the relevant domains added to a properly configured Fastly service

The Fastly TLS web interface is compatible with certificates that have been uploaded as part of the Customer-Provided TLS Certificate Hosting Service with the following limitations:

If you replace previously uploaded certificates, you can continue to use the Customer-Provided TLS Certificate Hosting Service with no changes to your bill.

Removing a previously uploaded certificate from the Customer-Provided TLS Certificate Hosting Service and uploading a new one using Fastly TLS will result in the new certificate being counted in your bill for Fastly TLS. The old certificate will continue to be billed per any contracted term for Customer-Provided TLS Certificate Hosting Service.

For information on migrating certificates from the Customer-Provided TLS Certificate Hosting Service to Fastly TLS, contact [email protected].

In addition to these prerequisites, be sure you understand the following limitations:

Fastly TLS comes with a 50 certificate limit. To discuss how to raise this products certificate limit, contact [email protected].

Fastly generates one certificate per domain.

Fastly managed certificates require clients to support TLS v1.2 and Server Name Indication (SNI) by default. To discuss how you can use settings other than these defaults, contact [email protected]. The ability to use custom settings may require you to use a dedicated Fastly IP address pool, which must be purchased separately.

Fastly TLS does not support the Triple DES (3des) cipher suite.

Setting up TLS for a domain

To set up TLS for an HTTPS domain, follow the steps below.

Log in to the Fastly web interface and click the Configure link.

Click the HTTPS and network tab. The TLS domains page appears, displaying any domains for which you have TLS either enabled or for which TLS can be enabled. If you've not yet started setting up TLS on any of your domains, this page appears empty.

Click the Add HTTPS to your domains button. The Enter domain window appears.

deleting a TLS domain

If you have your own TLS certificates and private keys, click the I want to bring my own certificate and private key link, and follow the guide to uploading and deploying your own certificates instead of this one.

In the Domain name field, enter an apex domain (e.g., example.com), a subdomain (e.g., www.example.com or api.example.com), or a wildcard domain (e.g., *.example.com).

Optionally, if you have access to multiple Fastly IP addresses or have multiple Fastly CNAME records created with different networking or TLS configurations, then from the TLS configuration menu, select which TLS configuration to apply. This option defines both the IPs that the certificate will be deployed to and the associated TLS settings that will be applied.

Click the Add domain button. The TLS domains page appears with a series of cards displayed, each listing a single domain, including the domain you just added along with any other domains and their current TLS and certificate statuses.

Verifying domain ownership

To begin serving HTTPS traffic, Fastly needs to verify that you control any domainyou'veadded to the web interface. Fastly offers two options to verify apex domains and subdomains: the ACME DNS challenge type and the ACME HTTP challenge type. Each requires you to make specific DNS changes. Wildcard domains require the DNS challenge type.

IMPORTANT: Fastly may modify the behavior of your services and DNS to complete ACME challenges for domain verification.

Using the ACME DNS challenge to verify domain ownership

The default method for verifying you control a domain being added to a Fastly managed TLS certificate uses the ACME DNS challenge type. Its suitable for all kinds of domains (apex, subdomains, and wildcards). It will only point the _acme-challenge subdomain at Fastly, allowing you to set up TLS first, before pointing production traffic at Fastly.

To use this verification method, create a CNAME record with a unique target for your domain. The formats for the record and target appear in the Whats next notification above your domains name in the list of TLS domains.

The steps to create the CNAME record will vary depending on your DNS provider's control panel interfaces. Refer to your DNS provider's documentation for exact instructions on how to do this. Your CNAME record must use the format _acme-challenge.DOMAIN_NAME (e.g., _acme-challenge.www.example.com) and must be pointed to a unique target for your domain (e.g., domain_token.fastly-validations.com). Onceyou'vepointed your DNS records at Fastly, we encourage you to keep the _acme-challenge subdomain CNAME in place to avoid interruptions in service.

Using the ACME HTTP challenge to verify domain ownership

An alternative method for verifying you control a domain uses the ACME HTTP challenge. This method is only suitable for apex domains and subdomains (wildcard domains can only be verified using the DNS challenge). It will point production traffic immediately at Fastly.

WARNING: The ACME HTTP challenge domain verification method can potentially point all end-user traffic to Fastly beforeyou'vecompleted TLS setup. This means that your end users may get an insecure warning in their browser related to your website or be totally unable to access your domain. To avoid this, ensure you have a properly configured Fastly service and have disabled any forced TLS redirection before you use this verification method.

To use this verification method, click the Alternative domain verification method(s) link in the Whats next notification above your domains name in the list of TLS domains. A verification options window appears:

Choose the verification alternative that suits your needs:

for a subdomain, create a CNAME record that points directly to the Fastly hostname

for an apex domain, create A records for the domain with the noted IP addresses

In both cases, once set up, production traffic will immediately begin flowing through Fastly.

What happens next

It should take no more than an hour for the TLS enablement process to progress through all of the TLS statuses shown below:

TLS Status

Description

Checking domain DNS recordsStep 1 of 3

Domain validation is in progress. Fastly is checking domain DNS records to verify that you control the domain being added to a certificate. To advance to the next enablement state, you must verify control by updating your domains DNS records to complete one of the ACME challenge types.

Certificate requested. Waiting for response from CAStep 2 of 3

Domain validation has been confirmed. Fastly believes the DNS records correctly point at Fastly and a certificate has been requested from the Certification Authority.

TLS enabled (certificate being deployed globally)

The Certification Authority has issued a TLS certificate. Newly issued certificates can take between 20 minutes to an hour to fully deploy across Fastlys global network.

Troubleshooting

If more than an hour has passed and TLS enablement appears to be stalled in one of the stages of adding a domain, there is likely an issue.

Domains stuck in the Checking domain DNS records state

If the domain is stuck in the Checking domain DNS records state, it is likely that you have not configured your DNS records correctly in order to verify domain ownership. You can check the DNS records yourself using a dig command in a command line application as follows:

ACME challenge type

Command to type

HTTP

dig www.example.com +short

DNS

dig _acme-challenge.www.example.com +short

Be sure to replace example.com with hostname you used when you configured your DNS records.

If you have correctly configured your DNS records, the result from this command will include one of the CNAME or A Records required for verification as defined in the Verifying domain ownership instructions.

If you recently added or modified DNS records, you may need to wait up to 72 hours for your DNS changes to propagate across the internet. If youdon'tsee these addresses within that time period, you may have misconfigured your DNS records.

If you are still having issues, there may be a CAA record on your domain that is blocking the certification authority from issuing certificates. This Certification Authority Authorization (CAA) record is used to specify which Certification Authorities (CAs) are allowed to issue certificates for a domain. If a CAA record exists, you may need to remove this record in order to use a managed Fastly TLS certificate.

Domains stuck in the Certificate requested state

If the domain is stuck in the Waiting for a response from CA state, this is likely a temporary issue with the Certification Authority. Be sure to allow up to an hour in this state before contacting [email protected] for assistance. If this is a new certificate request, you can also try deleting the domain and starting again.

TLS enabled but certificate not deployed everywhere

If the domain displays the TLS enabled state but the certificate doesnt appear to be available everywhere, the certificate is likely still in the process of being deployed throughout the Fastly network. It can take anywhere from 20 minutes to an hour for certificates to fully deploy. Be sure to allow up to an hour in this state before contacting [email protected] for assistance.

Pointing DNS to serve HTTPS traffic

To serve secure traffic via HTTPS once the certificate is deployed, follow these steps.

Ensure that the domains you've added via the TLS domains interface have been added to a properly configured Fastly service.

Configure your DNS records to point traffic at the newly created certificates IP addresses. All DNS details (CNAME, A records, and optionally AAAA records) can be found by clicking More details to view the TLS configuration associated with the domain. If you used the HTTP challenge method to verify domain ownership, youre already pointing traffic at the certificate.

If you have custom network maps or multiple, dedicated IPs, your domains and certificates can be set to use one or more TLS configurations. For more information, refer to the details on managing DNS and TLS configurations.

WARNING: If you point your DNS away from Fastly after the initial setup, we will be unable to terminate TLS on your behalf and we will also be unable to renew your certificate, which will expire after 90 days.

Disabling TLS and deleting a TLS domain

Once a domain has TLS enabled, you have the option to disable TLS via the Disable TLS link listed on the TLS domains page. Once disabled, Fastly will no longer serve TLS traffic on the selected domain. Fastly will attempt to renew a certificate for a disabled domain. To prevent this renewal process, you must delete the domain after you disable it. Fastly will not renew certificates for deleted domains.

Certificate management and renewals

Lets Encrypt issues certificates that are valid for 90 days. Fastly will attempt to re-verify your domain and renew your certificate after 60 days. However, if DNS records no longer point at Fastly, or if a CAA record blocks Let's Encrypt, the certificate will lapse at the end of the 90-day period.

Thirty days before it is due to expire, Fastly will automatically email all account users with TLS management permissions, notifying them of the upcoming expiration. If the renewal continues to fail, Fastly will continue to email users on the account on a schedule up until the expiry date.

If you have the correct DNS records for verifying domain ownership, and there is no blocking CAA record, but you are still receiving renewal failure emails, contact [email protected].

Migrating domains from shared certificates to Fastly-managed certificates

To migrate a domain on Fastlys shared certificates over to the Fastly TLS product, start by following the Setting up TLS for a domain instructions. Be sure to use the ACME DNS challenge using the _acme-challenge subdomain for verification, to keep production traffic pointing at the shared certificate.

Once your domain enters the TLS enabled state, wait at least 10 minutes and then verify that the certificate is globally deployed before changing over your DNS records to point away from the active shared certificate. You can do this using the following command in a command line application:

1

openssl s_client -connect TLS.CONFIG.CNAME.RECORD:443 -servername your.domain.com | openssl x509 -noout -text | grep 'Subject: CN'

If the result includes your TLS hostname, this means that Fastly has successfully generated and deployed a managed certificate to our network, and it is safe to update your DNS records with your DNS provider.

If you are currently using a shared certificate with a wildcard or subdomain, your CNAME record will likely end in shared.global.fastly.net. For apex domains, you will likely be using four A records. Provided the certificate is present on our network, you can now use the DNS records outlined in the Pointing DNS to serve HTTPS traffic instructions to point your domain to your new certificate, and away from the shared certificate.

After changing the DNS records for the domain with your DNS provider, check to see if the changes have propagated to a local DNS resolver by using the following command:

1

dig your.domain.com +short

TIP: Depending on your time to live (TTL) settings, you may need to allow up to 72 hours for DNS records to propagate across the internet.

As soon as your DNS information has been updated worldwide, visit your domain in a browser and check to see which certificate is served. Once you confirm that the new certificate is being served across clients, follow the instructions for to remove the domain from the shared certificate.

This guide describes how to use the Fastly TLS product to upload and deploy your own TLS certificates and private keys using the Fastly web interface.

To serve secure traffic from Fastly using HTTPS, a website or application needs to provide clients with a valid TLS certificate signed by a trusted Certification Authority (CA). TLS (Transport Level Security) and its predecessor SSL (Secure Sockets Layer) are the protocols that allow clients to form secure server connections so traffic can be served over HTTPS.

TIP: Fastly offers an API for uploading and managing your keys and certificates used to enable TLS for your domains on Fastly.

Before you begin

To use Fastly TLS with certificates and keys that you upload and deploy via the web interface, be sure you have the following prerequisites in place:

a paid Fastly user account (not a developers trial) assigned the role of superuser or assigned a user role with added TLS management permission

a valid X.509 TLS certificate from a trusted CA and a matching 2048-bit RSA private key

permission to modify the DNS records on the relevant domains that appear as Subject Alternative Name (SAN) entries on the TLS certificate

the relevant domains added to a properly configured Fastly service

The Fastly TLS web interface is compatible with certificates that have been uploaded as part of the Customer-Provided TLS Certificate Hosting Service with the following limitations:

If you replace previously uploaded certificates, you can continue to use the Customer-Provided TLS Certificate Hosting Service with no changes to your bill.

Removing a previously uploaded certificate from the Customer-Provided TLS Certificate Hosting Service and uploading a new one using Fastly TLS will result in the new certificate being counted in your bill for Fastly TLS. The old certificate will continue to be billed per any contracted term for Customer-Provided TLS Certificate Hosting Service.

For information on migrating certificates from the Customer-Provided TLS Certificate Hosting Service to Fastly TLS, contact [email protected].

In addition to these prerequisites, be sure you understand the following limitations:

Fastly TLS comes with a 50 certificate limit. To discuss how to raise this products certificate limit, contact [email protected].

Uploaded certificates require clients to support TLS v1.2 and Server Name Indication (SNI) by default. To discuss how you can use settings other than these defaults, contact [email protected]. The ability to use custom settings may require you to use a dedicated Fastly IP address pool, which must be purchased separately.

Fastly TLS does not support the Triple DES (3des) cipher suite.

If you're a DigiCert customer, be aware that upon making certificate changes, DigiCert will revoke your original certificate 72 hours after re-issuance. Be sure you upload your new certificate and switch all hostnames as soon as possible.

Uploading a private key and certificate

To upload a TLS certificate and the relevant private key (used to initially generate the certificate) follow the steps below.

IMPORTANT: The key file upload tool currently only accepts 2048-bit RSA keys. If you require longer key lengths, contact [email protected].

Log in to the Fastly web interface and click the Configure link.

Click the HTTPS and network tab. The TLS domains page appears, displaying any domains for which you have TLS either enabled or for which TLS can be enabled. If you've not yet started setting up TLS on any of your domains, this page appears empty.

Click the Add HTTPS to your domains button. The Enter domain window appears.

Click the I want to bring my own certificate and private key link. The TLS certificates tab appears displaying the secure upload controls.

[email protected]

Drag and drop your private key file into the drag and drop area to upload your private key file. Alternately, click the Browse for key file link to navigate to the file on your system using the file picker.

The private key appears below the upload controls and displays the Unmatched key label prominently on the left.

TIP: Unmatched keys are private keys that have no matching TLS certificate. If you have multiple private keys, you can identify each by the unique SHA1 hash. Private keys can only be deleted if they are in the unmatched state.

Upload a TLS certificate using the same drag-and-drop area or file picker you used to upload your private key. A success message appears.

Enabling TLS on a domain

Once a valid certificate and private key have been uploaded, all domains that appear as SAN entries will be listed on the TLS domains page with a status of TLS ready. To serve HTTPS traffic using your certificate, follow the steps below to enable TLS for the domain and point the DNS records to the certificate's location.

Click the TLS domains tab. The list of all domains that appear as SAN entries appear. Domains in a disabled state will have the status of TLS ready.

Click the Enable TLS button to the right of the appropriate domain. Fastly deploys your TLS certificate to the entire Fastly edge network. It may take up to an hour for your certificate to become available throughout the world.

Click More details to view the TLS configuration associated with the domain. Details about your domains TLS configuration appear.

Use the DNS details displayed in this section to configure your DNS records so that a TLS connection can be established using your certificate.

For TLS on an apex domain (e.g., example.com), you'll need to create a series of A records with your DNS provider.

For subdomains and wildcard domains (e.g, www.example.com or *.example.com), you'll need to create a relevant CNAME record.

IMPORTANT: It can take up to 48 hours for new DNS records to propagate across the internet.

Applying a TLS configuration to a domain

TLS configurations are a collection of TLS settings that include the supported versions of TLS and HTTP, along with networking and handshaking options that clients will use. For accounts with more than one TLS configuration, the default configuration has a label in the right corner of the card.

TIP: TLS configuration names are editable by clicking the pencil icon next to the name.

To override the default TLS configuration applied to a domain or to migrate a domain to use a different configuration follow these steps.

Click the TLS domains tab.

Click the More details link on the appropriate domain card.

From the Add TLS configuration menu at the bottom of the card, select the new configuration from the available options.

Once the configuration is selected, the TLS configurations listed are applied to the domain. Each TLS configuration is active and available at their respective IP addresses and DNS records.

Use the DNS details under the desired TLS configuration to update your DNS records.

Confirm the new DNS records have propagated across the internet (this can take up to 48 hours), then delete the old TLS configuration by clicking the trash can icon.

NOTE: For HTTP/1.1, be sure to enable TLS for each of your domains in the web application. If you upload a certificate with multiple SANs, each domain must be explicitly enabled if you want to secure these domains on Fastly.

Exceptions may apply in the case of HTTP/2 if your browser coalesces secure connections and has previously received a TLS certificate from an earlier handshake. In this case, some browsers may reuse an existing secure connection to Fastly if its certificate has a matching SAN entry.

Replacing a certificate

The TLS certificates page warns you when a certificate is nearing its expiration date.

There may be situations where Fastly identifies certificates that should be replaced. These certificates will be clearly marked.

Fastly allows you replace a certificate with a new one at any time.

Replacing certificates when there are no removed domains

To replace a TLS certificate with one that contains all the domains as the original (either as a superset or a matching list) follow these steps.

Generate a new certificate with your preferred Certification Authority.

If a new key was generated with the new certificate, upload it.

Find the certificate youre replacing on the TLS certificates tab in the web interface.

Click the certificate replacement icon in the upper right corner of the certificates card.

Using the file picker that appears, find the new certificate youre replacing the old one with. The certificate you select should be PEM-formatted and the SAN entries of this new certificate must contain all entries in the current certificate (i.e., it must either have an exact matching list or contain a superset).

Wait for the certificate update process to complete. A success message appears indicating the certificate has been successfully updated.

All domains actively serving TLS traffic on the old certificate will be automatically transitioned to the updated certificate within a matter of minutes. Any new domains will need to be manually enabled by following the steps for enabling TLS on a domain.

Replacing certificates when there have been changes to domains

If you want to update one of your certificates that requires removing domains, you will need to procure a new certificate with the updated list of SAN entries. Follow the steps to upload this certificate as a new certificate.

Upload the new certificate.

Click the TLS domains tab and find the previously existing domains that have already been enabled on the certificate youre replacing.

Click More details on the domain card to see the active TLS configurations.

From the Certificate being used menu, select a new certificate. A confirmation message appears.

Click the Use this certificate button on the confirmation message.

Manually activate any new domains that have been added to the updated certificate by following the steps for enabling TLS on a domain. Certificates for newly activated domains can take between 20 minutes to an hour to fully deploy across Fastlys global network. If the new certificate is not being used to serve TLS traffic within 1 hour, contact for assistance.

TIP: Certificate display names are editable by clicking the pencil icon next to the name.

Disabling TLS and deleting certificates and private keys

Once a domain has TLS enabled, you have the option to disable TLS via the Disable TLS link listed on the TLS domains page. Once disabled, Fastly will no longer serve TLS traffic on the selected domain.

To delete a certificate from the TLS certificates page, be sure to disable TLS for all domains on that specific certificate. You will also need to delete all certificates before you can delete a matching private key.

Certificate expirations

Thirty days before any certificate is due to expire, the web interface will display warnings on certificates soon to expire. Fastly will also begin to periodically send automated expiration notification emails to all users on the account with the TLS management permission. If the certificate is not replaced or removed, Fastly will continue to email users on the account until the certificate expires. Once expired, Fastly will no longer send automatic notifications.

This guide describes how to enable QUIC and HTTP/3 on your Fastly services.

IMPORTANT: This feature is part of a beta release. For more information, see our product and feature lifecycle descriptions.

About QUIC and HTTP/3

QUIC is a new web transport protocol that, when used with the Hypertext Transfer Protocol (HTTP) to deliver web content, will be officially designated as HTTP/3. Both QUIC and HTTP/3 are in the process of becoming IETF standards. Although the IETF standards are not yet ratified and may still undergo minor changes, Fastly has implemented QUIC and HTTP/3 support of end user connections for the purposes of limited customer beta testing.

Prerequisites

To use QUIC and HTTP/3 on Fastlys edge cloud services, you will need:

a Fastly user account assigned the role of superuser

relevant domains you will be using to test HTTP/3 added to a properly configured Fastly service

access privileges to modify DNS records for the domains you will be using

a client with the ability to generate QUIC and HTTP/3 end user requests to your Fastly services that is compliant with the latest IETF drafts

Moving your domains to QUIC-enabled Fastly IP addresses

Fastly currently restricts which end user requests will be allowed to connect to our edge cloud services using HTTP/3 to a subset of Fastlys IP addresses.

Onceyou'veidentified the domain names to be used for beta testing HTTP/3 and then added them in the Fastly services youll use for testing, email [email protected] and request that the domains be hosted on HTTP/3-enabled Fastly IP addresses. Be sure to list the exact domain names in the support ticket as they appear in the Fastly service configurations.

When the support request is completed, Fastly support will provide you with a hostname to use when updating the CNAME record for your domains with your DNS provider. Once you update your DNS providers CNAME records with the hostname provided by Fastly, end user requests to the domains will start connecting to Fastly on the HTTP/3-enabled IP addresses.

Configuring your Fastly service to offer HTTP/3

Once your domains begin using the HTTP/3-enabled Fastly IP addresses, you must configure the Fastly service you will be using for HTTP/3 testing to offer the new protocols to end user clients. The HTTP/3 protocol is offered via the alt-svc header in the HTTP responses to end user client connection requests. Because the actual value used in this header may change as both the QUIC and HTTP/3 protocols become finalized standards, Fastly has created a function that will automatically fill in the appropriate alt-svc header values for you.

To add the alt-svc header with the correct value for HTTP/3 traffic, configure your Fastly test service by following the instructions in our guide to Adding or modifying headers on HTTP requests and responses using the following values:

In the Name field, enter a descriptive name that will help you recognize this header addition rule.

From the Type menu, select Response and from the Action menu select Set.

In the Destination field, enter http.Alt-Svc.

In the Source field, enter h3_alt_svc().

Leave the Ignore if set menu set to the default value, No.

Leave the Priority field set to the default value.

Serving HTTP/3 traffic

Onceyou've configured your services appropriately, requests made to the domains on those services should be capable of supporting QUIC and HTTP/3 if they are being made from a client that supports these protocols.

The QUIC and HTTP/3 protocols provide optional upgraded connections to clients, which means that even HTTP/3-capable clients will initially connect on the standard TCP port 443 using HTTP/1.1 or HTTP/2 with TLS for security. HTTP/3-capable clients making their initial connections will see the HTTP/3 offer in the alt-svc response header from Fastly and then attempt the same requests by setting up QUIC connections and using HTTP/3.

If the QUIC connections and HTTP/3 requests are successful, the clients will continue using them for all subsequent requests and connections for those domains. Should problems occur with the QUIC connections or HTTP/3 requests, clients are expected to automatically fall back to a standard HTTP/1.1 or HTTP/2 connection over TCP. You should verify that your chosen test client implements this fallback if this is a priority for you.

Monitoring your HTTP/3 traffic

You can monitor HTTP/3 requests using Fastlys Real-Time Log Streaming feature. In addition to the existing connection-related logging variables, Fastly provides the following new HTTP/3-related VCL variables:

Variable

Description

%{if(fastly_info.is_h3, "true", "false")}V

Whether or not this was an HTTP/3 request.

%{if(fastly_info.h3.is_push, "true", "false")}V

Whether or not this was an HTTP/3 push request.

Disabling QUIC and HTTP/3

You can temporarily disable QUIC and HTTP/3 support on the service by either activating a previous version of the service configuration that does not include the alt-svc header or by creating a new service configuration version and deleting the alt-svc header before activation.

To permanently disable the QUIC capability of a service or a domain, revert your DNS records to the previous (non-QUIC) CNAME records.

Troubleshooting

Fastly contributes to an open source H2O client that can provide detailed logs of its interaction with Fastlys QUIC and HTTP/3 beta services. Fastly recommends beta participants use this client to provide logs to Fastly when requested to facilitate troubleshooting. Check out the client from its source repository following these steps:

Clone https://github.com/h2o/h2o.

Check out the kazuho/quic branch.

Compile it by entering the following command in any terminal application:

cmake . && make -j $(nprocs).

You should now have a binary file named h2o-httpclient.

Make a request with the client and have it generate logs of the request by typing the following command in any terminal application:

./h2o-httpclient -3 -E quic.log <URL OF REQUEST>

Microsoft Azure Blob Storage public and private containers can be used as origins with Fastly.

TIP: With properly configured services in place, shared Fastly and Microsoft customers will benefit from Fastlys integration with Azures ExpressRoute Direct Local, which results in Fastly including your outbound data transfer costs from Azure in your standard Fastly pricing. See our guide to outbound data transfers from Azure for more details.

Using Azure Blob Storage as an origin

To make your Azure Blob Storage stores available through Fastly, follow the steps below.

Creating a new service

Follow the instructions for creating a new service. You'll add specific details about your origin when you fill out the Create a new service fields:

In the Name field, type any descriptive name for your service.

In the Domain field, type the hostname you want to use as the URL (e.g., cdn.example.com).

In the Address field, type <storage account name>.blob.core.windows.net.

In the Transport Layer Security (TLS) area, leave the Enable TLS? default set to Yes to secure the connection between Fastly and your origin.

In the Transport Layer Security (TLS) area, type <storage account name>.blob.core.windows.net in the Certificate hostname field.

Setting the default host and correct path

Once the new service is created, set the default host to azure and then add your container path to the URL by following the steps below:

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Settings link. The Settings page appears.

Click the Override host switch. The Override host header field appears.

our note on integrations

Type the hostname of your Azure Blob Storage account. For example, <storage account name>.blob.core.windows.net.

Click the Save button. The new override host header appears in the Override host section.

Click the Content link. The Content page appears.

Click the Create header button. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type Modify URL.

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type url.

In the Source field, type "/<your container name>" req.url.

From the Ignore if set menu, select No.

In the Priority field, type 10.

Click the Create button. The new Modify URL header appears on the Content page.

Click the Activate button to deploy your configuration changes.

Testing your results

By default, we create DNS mapping called yourdomain.global.prod.fastly.net. In the example above, it would be cdn.example.com.global.prod.fastly.net. Create a DNS alias for the domain name you specified (e.g., CNAME cdn.example.com to global-nossl.fastly.net).

Fastly will cache any content without an explicit Cache-Control header for 1 hour. You can verify whether you are sending any cache headers using cURL. For example:

1

2

3

4

5

6

7

$ curl -I opscode-full-stack.blob.core.windows.net

HTTP/1.1 200 OK

Date: Fri, 04 May 2018 21:23:07 GMT

Content-Type: application/xml

Transfer-Encoding: chunked

Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0

In this example, no cache control headers are set so the default TTL will be applied.

Using an Azure Blob Storage private container

To use an Azure Blob Storage private container with Fastly, follow the instructions below.

Before you begin

Be sure you've already made your Azure Blob Storage containers available to Fastly by pointing to the right container and setting your origin to port 443. This needs to be done before authenticating.

To complete the setup, you'll also need your Azure Storage Account shared key and storage account name to construct the Azure Blob Storage Authorization header, which takes the following form:

1

Authorization: SharedKey `_Account name_`:`_Signature_`

Finally, you'll also need to know your Blob Storage container name.

Setting up Fastly to use an Azure Blob Storage private container with a Shared Key

WARNING: Your account's Shared Key does not have detailed access control. Anyone with access to your Shared Key can read and write to your container. Consider using a Shared Access Signature (SAS) instead.

To access an Azure Blob Storage private container with Fastly using a Shared Key, read Microsoft's " Authorize with Shared Key " page. Then, create two headers : a Date header (for use with the authorization Signature) and an Authorization header.

Create a Date header

Create the Date header using the steps below.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Create header button. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type Date.

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type http.Date.

In the Source field, type now.

From the Ignore if set menu, select No.

In the Priority field, type 10.

Click the Create button. A new Date header appears on the Content page. You will use this later within the Signature of the Authorization header.

Create an Authorization header

Next, create the Authorization header with the specifications listed below.

Click the Create header button again to create another new header. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type Azure Authorization.

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type http.Authorization.

From the Ignore if set menu, select No.

In the Priority field, type 20.

In the Source field, type the header authorization information using the following format:

1

"SharedKey <Storage Account name>:" digest.hmac_sha256_base64(digest.base64_decode("<Azure Storage Account shared key>"), if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/<Storage Account name>" req.url.path)

replacing <Storage Account name> and <Azure Storage Account shared key> with the information you gathered before you began. For example:

1

"SharedKey test123:" digest.hmac_sha256_base64(digest.base64_decode("UDJXUFN1NjhCZmw4OWo3MnZUK2JYWVpCN1NqbE93aFQ0d2hxdDI3"), if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/test123" req.url.path)

We provide a detailed look at the Source field parameters below.

Click the Create button. The new Authorization header appears on the Content page.

Click the Activate button to deploy your configuration changes.

A detailed look at the Source field

So what's going on in the Source field of the Authorization header? Here's the basic format:

SharedKey<storage account name><Signature Function><key><message>

It tells us the following:

Element

Description

SharedKey

A constant placed before the storage account name. It's always SharedKey.

storage account name

The name of your Azure Storage Account. We used test123 in this example.

signature function

The algorithm used to validate the key and message of the signature. We used digest.hmac_sha256_base64(<key>, <message>) in this example.

key

The Azure Storage Account shared key from your Azure Storage developer's account. We used UDJXUFN1NjhCZmw4OWo3MnZUK2JYWVpCN1NqbE93aFQ0d2hxdDI3 in this example. It must be Base64 decoded.

message

The UTF-8 encoding of the StringToSign. See the table below for a break down of each portion of the message.

The message that's part of the Source field in the Authorization header takes on this basic format:

<HTTP-verb></n><Content-MD5>/n<Content-Type></n><Date></n><CanonicalizedAmzHeader></n><CanonicalizedResource>

It tells us the following:

Element

Description

HTTP-verb

The REST verb. We use req.method in this example. We rewrite HEAD to GET because Varnish does this internally before sending requests to origin.

\n

A newline indicator constant. It's always \n.

Content-MD5

The content-md5 header value, used as a message integrity check. It's often left blank. We use LF (line feed) in this example.

Content-Type

The content-type header value, used to specify the MIME-type. It's often left blank. We use LFin this example.

Date

The date and time stamp. We use req.http.Date (which we created first as a separate header in the steps above).

CanonicalizedHeaders

The x-ms headers, which customize your Azure Blob Storage implementation. It's often left blank. We use LF in this example.

CanonicalizedResource

Your Storage Account Name. We use "/test123" in this example.

Setting up Fastly to use an Azure Blob Storage private container with a Shared Access Signature (SAS)

To access an Azure Blob Storage private container with Fastly using a Service Shared Access Signature (SAS), read Microsoft's " Delegating Access with a Shared Access Signature " page. Then, obtain the SAS and sign the access URL.

TIP: Using a Service Shared Access Signature gives you more detailed control over:

The interval during which the SAS is valid, including the start time and the expiry time.

The permissions granted by the SAS. For example, a SAS for a blob might grant read and write permissions to that blob, but not delete permissions.

An optional IP address or range of IP addresses from which Azure Storage will accept the SAS. For example, you might specify a range of IP addresses belonging to your organization.

The protocol over which Azure Storage will accept the SAS. You can use this optional parameter to restrict access to clients using HTTPS.

Obtaining the Shared Access Signature

Obtain the SAS using the steps below.

In the Azure portal, navigate to your storage account

Under settings navigate to Shared access signature. The Shared access signature controls appear.

From the Allowed services controls, select Blob.

From the Allowed resource types controls, select Object.

From the Allowed permissions controls, select Read.

Leave the Start time set to the current date and time.

Set the End time as far in the future as you are comfortable (see note below).

Ensure the Allowed protocols remain set to HTTPS only.

Click the Generate SAS and connection string button. The generated information appears.

Copy and save the contents of the SAS token field. It will look something like:

1

?sv=2017-11-09&ss=b&srt=o&sp=r&se=2019-10-22T15:41:23Z&st=2018-10-22T07:41:23Z&spr=https&sig=decafbaddeadbeef

We provide a detailed look at the Shared Access Signature parameters below.

Signing the URL

Next, sign the access URL by creating an authorization header following the steps below.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Create header button. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type a meaningful name such as Set Azure private SAS Authorization URL.

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type url.

In the Source field, type req.url.path "<SAS TOKEN>" replacing "<SAS TOKEN>" with the token you obtained from the Azure Portal.

From the Ignore if set menu, select No.

In the Priority field, type 10.

Click the Create button. A new header appears on the Content page.

Click the Activate button to deploy your configuration changes.

A detailed look at the Shared Access Signature parameters

Microsoft's " Constructing a Service SAS " page provides more details on shared access signatures and how they are constructed.

Element

Description

sv

The signedversion field. This is required and should be whatever the Azure portal provided.

ss

The signedservice field. This is required and should be b for "blob storage."

srt

The signedresourcetype field. This is required and should be o for "object."

sp

The signedpermissions field. This is required and should be r for "read only."

st

The signedstart field. This is optional and specifies, in a UTC format compatible with ISO 8601, the time at which the shared access signature becomes valid. If omitted, the start time for this call is assumed to be the time when the storage service receives the request.

se

The signedexpiry field. This is required and specifies, in a UTC format compatible with ISO 8601, the time at which the shared access signature becomes invalid.

spr

The signedprotocol field. This is optional and specifies which HTTP protocol (http or https) the container should use for access. We recommend https.

sig

The signature field. This is required and should be whatever the Azure portal provided.

WARNING: Always keep track of the se expiry date. After it has passed, Fastly will not be able to access your private container.

TCP connection settings for improved performance

By default, Fastly keeps established TCP connections opened to your origin to improve performance. Azures default behavior, however, closes idle connections. Specifically, the Azure Load Balancers default behavior silently drops flows when the default idle timeout of a flow reaches four minutes. To ensure successful integration, we suggest tuning Azure in two ways:

increase the Azure Load Balancers TCP idle timeout setting

configure Azure to send a bidirectional TCP Reset (RST packet) on idle timeout

This article describes an integration with a service provided by a third party. Please see .

Application Programming Interfaces (APIs) allow you to retrieve data from a variety of web services. Fastly makes it possible for you to cache your API so you can accelerate the performance of your service-oriented architecture. It optimizes your API's performance by efficiently handling traffic bursts and reducing latency.

An example

Let's look at an example to learn how API caching works. Imagine we're an online magazine with articles on which users can make comments. Each article can have many comments, and each comment is authored by exactly one user.

connecting to origins

We'll design a RESTful API specification and use it to manipulate and retrieve comments:

GET /comment - Returns a list of all comments

GET /comment/:id - Returns a comment with the given ID

POST /comment - Creates a new comment

PUT /comment/:id - Updates a comment with the given ID

DELETE /comment/:id - Deletes a comment with the given ID

The create, read, update, and delete (CRUD) methods ensure the API can perform its basic operations, but they don't expose the relational aspect of the data. To do so, you would add a couple of relational endpoints:

GET /articles/:article_id/comments - Get a list of comments for a given article

GET /user/:user_id/comments - Get all comments for a given user

Endpoints like these allow programmers to get the information they need to do things like render the HTML page for an article, or display comments on a user's profile page. While there are many other possible endpoints we could construct, this set should suffice for the purposes of this guide. Let's assume that the API has been programmed to use an Object-Relational Mapper (ORM), such as ActiveRecord, when interacting with the database.

Determining which API endpoints to cache

Start by identifying the URLs you want to cache. We recommend splitting the specification endpoints into two groups.

The first group, called "accessors," retrieves or accesses the comment data. These are the endpoints you want to cache using Fastly. Using the example, four endpoints match this description:

GET /comment

GET /comment/:id

GET /article/:article_id/comments

GET /user/:user_id/comments

The second group, called "mutators," changes or mutates the comment data. These endpoints are always dynamic, and are therefore uncacheable. Using the example, three endpoints match this description:

POST /comment

PUT /comment/:id

DELETE /comment/:id

You should see a pattern emerging. Because the example API is RESTful, we can use a simple rule to identify the accessor and mutator endpoints: GET endpoints can be cached, but PUT, POST, and DELETE endpoints cannot.

Once you've gathered this information, you're ready to program the API to configure PURGE requests.

Configuring PURGE requests

Don't be tempted to point at the PUT, POST, and DELETE endpoints as the place where data is modified. In most modern APIs, these endpoints represent an interface to the actual model code responsible for handling the database modifications.

In the example, we assumed that we'd be using an ORM to perform the actual database work. Most ORMs allow programmers to set special "callbacks" on models that will fire when certain actions have been performed (e.g., before or after validation, or after creating a new record).

For purging, we are interested in whether a model has saved information to the database whether it's a new record, an update to an existing record, or the deleting of a record. At this point, we'd add a callback that tells the API to send a PURGE request to Fastly for each of the cacheable endpoints.

For an ActiveRecord comments model, you could do something like this:

1

2

3

4

5

6

7

8

9

10

11

12

require 'fastly'

class Comment < ActiveRecord::Base

fastly = Fastly.new(api_key: 'FASTLY_API_TOKEN')

after_save do

fastly.purge "/comment"

fastly.purge "/comment/#{self.id}"

fastly.purge "/article/#{self.article_id}/comments"

fastly.purge "/user/#{self.user_id}/comments"

end

end

Keep two things in mind when creating the callback:

The purge code should be triggered after the information has been saved to the database, otherwise a race condition could be created where Fastly fetches the data from the origin server before the data has been saved to the database. This would cache the old data instead of the new data.

These URLs are being purged because they have content that changes when a comment is changed.

With the model code in place, the API is now ready to be cached.

Setting up Fastly

The final step to enabling API caching involves setting up Fastly. You'll need to:

Create a new service

Add the domain for the API

Add the origin server that powers the API

In addition, you can optionally create rules that tell Fastly how to work with the specific elements that are exclusive to your API.

NOTE: By default, Fastly will not cache PUT, POST, and DELETE requests. For more information, see our guide on default caching behavior of HTTP methods.

Creating a new service

Follow the instructions for creating a new service. You'll add specific details about your API server when you fill out the Create a new service fields:

In the Name field, type a name for this service that helps you identify it's related to caching your API information (e.g., My API Service).

In the Domain field, type the domain name associated with your API (e.g., api.example.com).

In the Address field, type the IP address or hostname of your API server.

Adding the domain

Follow these instructions to add the API's domain name to your Fastly service:

On the Configure page, click the Configuration button and then select Clone active. The Domains page appears.

Click the Create domain button. The Create a domain page appears.

Fill out the Create a domain fields as follows:

In the Domain Name field, type the domain name for the API.

In the Comment field, type an optional comment that describes your domain.

Click Create. Your API's domain name appears in the list of domains.

Adding the origin server

Follow the instructions for . You'll add specific details about your API server when you fill out the Create a host fields:

In the Name field, type a name for the origin server that helps you identify it's related to caching your API information.

In the Address field, type the IP address (or hostname) of the API server.

We recommend enabling CORS ( Cross-Origin Resource Sharing ) when using Amazon S3 as your backend server. To enable CORS, set up a custom HTTP header for your service by following the steps below.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Create header button. The Create a header page appears.

purge them

Fill out the Create a header fields as follows:

In the Name field, type a descriptive name for the new header (e.g., CORS S3 Allow). This name is displayed in the Fastly web interface.

From the Type menu, select Cache, and from the Action menu, select Set.

In the Destination field, type http.Access-Control-Allow-Origin.

In the Source field, type "*".

Leave the Ignore if set menu and the Priority field set to their default values.

Click the Create button. The new header appears on the Content page.

Click the Activate button to deploy your configuration changes.

IMPORTANT: Objects already cached won't have this header applied until you .

Test it out

Running the command curl -I example.tld/path/to/resource should include similar information to the following in your header:

1

2

3

Access-Control-Allow-Origin: http://example.tld

Access-Control-Allow-Methods: GET

Access-Control-Expose-Headers: Content-Length, Connection, Date...

Fastly's gzip feature dynamically fetches content from origin, compresses it, and then caches it. There are two ways to enable gzip:

Enable the default gzip policy to compress content in files with the following extensions: css js html eot ico otf ttf json svg.

Set up an advanced gzip policy to customize the content and conditions for compression.

WARNING: This feature doesn't work with our ESI feature. If you enable gzipping, Fastly will stop processing ESI language elements.

Enabling gzip

To dynamically gzip cacheable content based on file extension or content-type, follow the steps below to enable the default gzip policy:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Default gzip policy switch to enable gzip.

Click the Activate button to deploy your configuration changes.

Setting up an advanced gzip policy

To customize the content thats compressed and the conditions under which this compression occurs, follow the steps below:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Set up advanced gzip button. The Create a gzip page appears.

Click the Override these defaults link. Additional gzip fields appear.

modify our normalization algorithm

Fill out the Create a gzip fields as follows:

In the Name field, type an arbitrary name for your new gzip rule.

In the Extensions field, type the file extension for each file type to be dynamically gzipped, separated by spaces. Only type the three- or four-letter string representing the file extension.

In the Content Types field, type the content-type for each type of content you wish to have dynamically gzipped, separated by spaces. Do not use regular expressions.

Click the Create button. The new gzip policy appears.

Click the Activate button to deploy your configuration changes.

Automatic normalization

Because gzip is one of the most common reasons to vary output based on a request header, Fastly will normalize the value of Accept-Encoding on incoming requests. The modified header will be set to a single encoding type, or none, and will reflect the best compression scheme supported by the browser. This includes removing Accept-Encoding values in requests from browsers that advertise support for gzip but whose implementation is broken, such as IE6.

Specifically, we run the following steps on inbound requests:

If the User-Agent matches a pattern for browsers that have problems with compressed responses, remove the Accept-Encoding header

Else if the Accept-Encoding header includes the string "gzip", set the entire value to the string "gzip"

Else if the Accept-Encoding header includes the string "deflate", set the entire value to the string "deflate"

Else remove the Accept-Encoding header

Where this normalization process has changed the header value, the original value is made available in the custom header Fastly-Orig-Accept-Encoding.

If a user agent advertises support for brotli, currently we will normalize this to gzip because we do not support brotli encoding at the edge. However, if you are doing brotli encoding at your origin server, you may want to .

The sun never sets on the Fastly empire, but how can you take full advantage? Simply set your CNAME record to nonssl.global.fastly.net for non TLS traffic. You'll now have access to all of our worldwide POPs as they come online. We don't restrict POP access. Instead, you control it.

How to check if your CNAME is set to nonssl.global.fastly.net

Run the following command in your terminal:

1

$ dig www.example.com +short

Your output should appear similar to the following:

1

2

nonssl.global.fastly.net.

151.101.117.57

If you don't see nonssl.global.fastly.net. in your output, then your CNAME isn't properly set. We link to instructions for setting your CNAME for a number of popular providers.

Instead of using the above command in your terminal, you can also use various online DNS checking tools, such as the OpenDNS Cache Check.

Limiting POP use to North America and the European Union

You can route your traffic through Fastly's North American and European Union POPs only. If you're not using TLS, simply set your CNAME record to nossl.us-eu.fastly.net. instead of nonssl.global.fastly.net.. If you're using TLS, see our guide on CNAME records to find the appropriate entry.

The HTTP Strict Transport Security (HSTS) security enhancement specification provides a way to force modern browsers to communicate only via the Transport Layer Security (TLS) protocol. Once enabled, HSTS will force the browser to redirect (typically with a status code 307) to the HTTPS URL.

NOTE: HSTS only takes effect after a site has been visited on a trusted HTTPS connection. It doesn't replace the need to have redirects from your HTTP site.

Prerequisites

These instructions assume that you've set up TLS service with Fastly.

Forcing TLS and enabling HSTS

To force TLS and enable HSTS, follow these steps.

NOTE: Services activated using a previous version of the Force TLS controls may temporarily display an additional, older testing duration. Once you select the recommended new testing duration, this older option will disappear.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Settings link. The Settings page appears.

Click the Force TLS and enable HSTS switch to force TLS and enable HSTS for the service.

Chromium Projects description

The request setting for forcing TLS and the header for enabling HSTS will automatically be created for you.

Click the Activate button to deploy your configuration changes.

WARNING: You may experience problems if you enable this setting along with the override host setting. Instead of enabling the override host setting, create a new request setting and specify the override host in the advanced options.

Manually enabling HSTS

If you'd like configure additional HSTS options, you'll need to manually enable HSTS by adding a new header as follows.

NOTE: If you followed the instructions in the previous section, click the Force TLS and enable HSTS switch to remove the request setting and header that were automatically created.

Follow the instructions in forcing a TLS redirect to force unencrypted requests over to TLS.

Click the Content link. The Content page appears.

Click the Create header button to create a new header. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type a human-readable name, such as HSTS. This name is displayed in the Fastly web interface.

From the Type menu, select Response, and from the Action menu select Set.

In the Destination field, type http.Strict-Transport-Security.

In the Source field, type "max-age=<max age in seconds>". For example, "max-age=31536000". As described below, max-age is required and two additional HSTS options can be specified.

Leave the Ignore if set menu and the Priority field set to their defaults (or set them as appropriate for your service).

Click the Create button.

Click the Activate button to deploy your configuration changes.

HSTS options

If you manually configured the HSTS header, you can specify additional HSTS options.

HSTS requires the max-age directive be set in order to function properly. It specifies how long in seconds to remember that the current domain should only be contacted over HTTPS. The example shown above sets max-age to one year (31536000 seconds = 1 year). You may want to experiment using a smaller value than what is shown.

Two additional options can be specified with the HSTS response header:

includeSubdomains - This token applies HSTS to all of your site's subdomains. Before you include it, be certain none of your subdomains require functionality on HTTP in a browser. Ensure your TLS certificate is a wildcard or has coverage for all subdomain possibilities.

IMPORTANT: All subdomains will be unreachable on HTTP by browsers that have seen the HSTS header once includeSubdomains is enabled.

preload - This token allows you to submit your domain for inclusion in a preloaded HSTS list that is built into several major browsers. Although the token is not part of the HSTS specification, including it in the header is a prerequisite for submitting to this preloaded list.

WARNING: Don't request browser preload inclusion unless you're sure that you can support HTTPS for the long term. Inclusion in the HSTS Preload List cannot be undone easily. See https://hstspreload.org/ for submission instructions and more information.

Combining all of these options together in the Source field would look like this:

"Strict-Transport-Security: max-age=<max age in seconds>; includeSubDomains; preload"

To disable HSTS for whatever reason, simply set the max-age to 0 on an HTTPS connection.

The HSTS Preload List is managed by a third party, not by Fastly. See https://hstspreload.org/ for more information.

Additional reading

RFC 6797, which describes the HSTS specification

the Wikipedia description of HSTS, including the currently known limitations and a browser support list

the OWASP.org explanation of HSTS, including descriptions of the threats it addresses

the of HSTS and preloading HSTS sites

Token validation allows you to create URLs that expire. Tokens are generated within your web application and appended to URLs in a query string. Requests are authenticated at Fastly's edge instead of your origin server. When Fastly receives a request for the URL, the token is validated before serving the content. After a configurable period of time, the token expires.

Adding custom VCL

To enable token validation, you'll need to create a Varnish configuration named vcl_recv and add the following example code to it.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

# only do this once per request

if (req.restarts == 0) {

declare local var.token STRING;

declare local var.token_expiration STRING;

declare local var.token_signature STRING;

# extract the token

set var.token = subfield(req.url.qs, "token", "&");

# make sure there is a token

if (var.token == "") {

error 403;

}

# make sure there is a valid expiration and signature

if (var.token !~ "^(\d{10,11})_([a-f0-9]{40})$") {

error 403;

}

# extract token expiration and signature

set var.token_expiration = re.group.1;

set var.token_signature = re.group.2;

# make sure the signature is valid

if (!digest.secure_is_equal(var.token_signature, regsub(digest.hmac_sha1(digest.base64_decode("YOUR%SECRET%KEY%IN%BASE64%HERE"), req.url.path + var.token_expiration), "^0x", ""))) {

error 403;

}

# make sure the expiration time has not elapsed

if (time.is_after(now, std.integer2time(std.atoi(var.token_expiration)))) {

error 410;

}

}

IMPORTANT: Be sure to generate your own key for use with this VCL (the example key shown here will intentionally cause an error). Due to limitations in VCL, the binary form of the key should not contain NUL (0x00) bytes. In Linux, use the command while (b=$(openssl rand -base64 32) ; echo $b; echo $b | base64 -d | hd | grep " 00 " > /dev/null); do :; done | tail -1. In macOS, use the command while (b=$(openssl rand -base64 32) ; echo $b; echo $b | base64 -D | hexdump | grep " 00 " > /dev/null); do :; done | tail -1.

The custom VCL code above checks for two things:

It verifies the signature supplied matches the signature of the token

It ensures the current time is less than the expiration time specified in the token

If the signature is invalid, Varnish returns a 403 response. If the signature is valid but the expiration time has elapsed, Varnish returns a 410 response. The different response codes are helpful for debugging.

The token information

A token is expected in the ?token= GET parameter. Tokens take the format [expiration]_[signature] and look like this:

1

1441307151_4492f25946a2e8e1414a8bb53dab8a6ba1cf4615

The full request URL with the token looks like this:

1

http://www.example.com/foo/bar.html?token=1441307151_4492f25946a2e8e1414a8bb53dab8a6ba1cf4615

The signature validation

The key found in digest.hmac_sha1 can be any string. The one in this example was generated with the command openssl rand -base64 32. The example key YOUR%SECRET%KEY%IN%BASE64%HERE will intentionally cause an error if you use it. You must replace it with your own randomly generated secret key.

WARNING: Anyone who learns your key can bypass your token validation, so it's critical that you keep it secret.

Configuring your application

You'll need to write custom code in your application to generate tokens and authenticate with Varnish. We provide examples in our token functions repository on GitHub. Review the examples in the repository to learn how to generate custom tokens within your application.

Testing

To test your configuration, append a token generated by your application to a URL in a query string. For example:

http://www.example.com/foo/bar.html?token=1441307151_4492f25946a2e8e1414a8bb53dab8a6ba1cf4615

If the token is valid, you will receive a normal response. If it is invalid, you will receive a 403 response.

Troubleshooting NUL bytes

You should verify that your secret key is devoid of NUL bytes. If the Base64-decoded string contains a NUL byte (0x00), then that byte and any bytes following it will not be included in the response. See Base64 decoding for more information.

Excluding the token query string from the cache key

If all tokens are dynamic and different, you may want to exclude the token query string from the cache key to avoid potentially affecting the cache hit ratio. To do this, you'll need to add the following code in custom VCL in addition to the example code above :

1

2

/* strip out the token querystring so Fastly does not vary the cache. */

set req.url = querystring.filter(req.url, "token");

For supported logging endpoints, Fastly allows you to encrypt your log files before they are written to disk. The files are encrypted using OpenPGP (Pretty Good Privacy).

IMPORTANT: Be sure to take into account security, privacy, and compliance requirements when making configuration and endpoint decisions for the data you intend to include in streamed logs.

Generating a PGP key pair

To use this feature, you'll need to use a PGP implementation (such as GPG ) to generate a public and private PGP key pair. Typically, this involves running the following command in a terminal application on your personal computer:

gpg --gen-key

Follow the instructions shown in your terminal application. Enter your email address and set a passphrase when prompted. Remember the values you enter.

WARNING: Keep your private key safe! If you lose it, your encrypted log files will be permanently unreadable.

Exporting the PGP public key

After you generate the PGP key pair, you'll need to export your public key. Typically, this involves running the following command in a terminal application on your personal computer:

gpg --armor --export <your email>

The output will be in PEM (Privacy-Enhanced Mail) format and will look similar to the following:

1

2

3

4

5

6

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGiBFciSsYRBAC9aHsraEzLmzfuQLx+BZmGTCOQFsPGpiPaEKrulRbrcBvtt3Bl

zajFP9iVzSm3+Zyqge/1AtHllSnPHTqG2EoBCsWtXL/JnZcPjx8c5r8G5IuBGrh8

snP3KTJ64zCS7PUvrWy5RWcJ6Rs+6wiJ7zPOtU5wMEPuMbflh/soy50zrwCg74XN

[...REDACTED...]

-----END PGP PUBLIC KEY BLOCK-----

Enabling log encryption

To enable PGP encryption for a logging endpoint that supports it, copy and paste your public PGP key into the PGP public key field in the Fastly web interface when creating or editing a supported logging endpoint.

Decrypting log files

To read an encrypted log file, you'll need to download and decrypt it. Typically, this involves running the following command in a terminal application on your personal computer:

gpg --decrypt <encrypted log file>

Enter your passphrase to decrypt the log file.

Using CloudFlare for DNS and other CDNs can cause CloudFlare to show an Error 1000 indicating that your DNS points to prohibited IP addresses. This occurs when the hostnames are CNAMEed to Fastly and an origin server is configured as a fully qualified domain name (FQDN) within Fastly:

To solve this error, direct Fastly to use the IP address as the host for any backend origin servers. This removes the need to resolve the hostname for traffic to the servers:

You can also change this by modifying the VCL configuration files directly. For example, this VCL:

1

2

3

4

5

backend F_Hosting_server_Example_Backend {

...

.port = "80";

.host = "exampleserver.exampledomain.tld";

}

would become:

1

2

3

4

5

backend F_Hosting_server_Example_Backend {

...

.port = "80";

.host = "12.34.56.78";

}

To get started using Fastly, sign up for an account and then create your first service. Once you've created your service you can explore various configurations as much as you need before going live. Fastly won't start serving your traffic until you specifically set the CNAME DNS record for your domain.

Sign up at Fastly.com

Before you do anything else, you must sign up for a Fastly account.

Click on any Sign Up button on the Fastly.com website or simply point a browser to the signup form.

When the signup form appears, fill in all the fields with your contact information. All the fields are required.

Diagnostics

NOTE: You'll be able to change your password and email address any time after signup. Without a valid email we can't send you account verification details during account setup. Without a valid telephone number, we can't assist you with specific kinds of account lockout issues.

Click the Sign up for Fastly button. The confirmation screen will appear with instructions on what to do next and you'll be sent an e-mail that contains a verification link.

Check your inbox and find the confirmation email we sent you.

Click the verification link (we need to make sure you're not a spam robot and verify your email). The verification link will immediately take you to your empty home page.

Experiment with your first service

Onceyou'vesigned up at Fastly.com, well guide you through the process of creating your first service. When you receive your account verification email from us, well log you into the application automatically. All youll need to do to start creating your first service is click the Get Started button.

Use our configuration page with your first service to experiment with and test initial configurations safely, without impacting any traffic to your origin (trafficwon'tflow there until you update your DNS records ). When youre ready, well guide you through the process of creating a domain and a host, setting up your TLS, and finally activating your first service.

Test your configuration experiments

As you experiment with service configurations, you can test their success before you start serving traffic through Fastly. Simply open http://www.example.com.global.prod.fastly.net in a new browser window, replacing www.example.com with your own website's domain name. Your website should appear, though it may take up to 60 seconds for new configuration settings to take effect.

You can continue to explore various configuration settings for as long as you like, testing things repeatedly as you go.

Start serving traffic through Fastly

Once youre ready, all you need to do to complete your service setup and start serving traffic through Fastly is set your domain's CNAME DNS record to point to Fastly. For more information, see the instructions in our Adding CNAME records guide.

Next steps

Consider exploring these areas next:

Working with services

Log streaming

Health Checks

To communicate with your origin servers, you can add and edit a host.

Adding a host

To add a host, follow the steps below:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Origins link. The Origins page appears.

Click the Create a host button. The Hosts field appears.

Mozilla SSL Configuration Generator

Fill out the Hosts field by typing the hostname or IP address of your origin server. Entering a hostname automatically enables Transport Layer Security (TLS) and assigns port 443. Entering an IP address disables TLS and assigns port 80.

Click Add to add your host.

Editing a host

After you've created your host, you can edit the host's details by following the steps below:

In the Hosts area, click the pencil icon next to the host you want to edit. The Edit this host page appears.

Fill out the Edit this host fields as follows:

In the Name field, type the name of your server (for example, My Origin Server). This name is displayed in the Fastly web interface.

In the Address field, type the IP address (or hostname) of your origin server.

See Understanding the difference between certificate hostname and SNI hostname values for more information about hostnames.

Fill out the Transport Layer Security (TLS) area as follows:

Leave the Enable TLS? default set to Yes if you want to enable TLS to secure the connection between Fastly and your origin. To enable TLS, a valid SSL certificate must be installed on your origin server and port 443 (or the specified port) must be open in the firewall. You can select No if you do not want to use TLS.

Leave the Verify certificate? default set to Yes if you want to verify the authenticity of the TLS certificate. Selecting No means the certificate will not be verified.

WARNING: Not verifying the certificate has serious security implications, including vulnerability to man-in-the-middle attack. Consider uploading a CA certificate instead of disabling certificate validation.

In the Certificate hostname field, type the hostname associated with your TLS certificate. This value is matched against the certificate common name (CN) or a subject alternate name (SAN) depending on the certificate you were issued.

If you are specifying an SNI hostname, see the section below.

If you are specifying a TLS CA certificate, see the section below.

Fill out the remaining Create a host fields as follows:

From the Shielding menu, optionally select a POP to enable the shielding feature. For more information, see our guide on shielding.

From the Health check menu, optionally select a health check for this origin server. For more information, see our guide on working with health checks.

From the Auto load balance menu, optionally select Yes to enable load balancing for this origin server. For more information, see our guide on load balancing.

If you enabled load balancing, type a weight in the Weight field.

Click the Advanced options link and decide which of the optional fields to change, if any:

In the Maximum connections field, optionally type the maximum number of connections for your backend. The default limit is 200 connections per cach node to protect your origins from being overloaded.

In the Error threshold field, optionally type the number of errors allowed before an origin is considered down.

In the Connection timeout field, optionally type how long, in milliseconds, to wait for a connection timeout. The default is 1000 milliseconds.

In the First byte timeout field, optionally type how long, in milliseconds, to wait for a first byte timeout. The default is 15000 milliseconds.

In the Between bytes timeout field, optionally type how long, in milliseconds, to wait between bytes. The default is 10000 milliseconds.

In the Override host field, optionally type the hostname of your override host header based on the origin youre using. The value in this field will take precedence over anything you've set using the override host quick configuration. Keep in mind the following:

If you're using Amazon S3 as your origin, type <yourbucket>.s3.amazonaws.com.

If you're using Google Cloud Storage as your origin, type <your bucket name>.storage.googleapis.com.

NOTE: To override the incoming host header on your origin using your Fastly service, refer to the Specifying the override host guide.

Click the Update button.

Click the Activate button to deploy your configuration changes.

And that's all you need to do. Everything else is optional, but just in case you'd like to set them, we've included the information below.

Setting the TLS hostname

Normally we check the server certificate against the hostname portion of the address for your origin entered in the Create a host window. Checking the certificate is done by using the value of the Certificate Hostname field in your origin TLS settings. To have Fastly verify the certificate using a different hostname, specify it via the SNI Hostname field under Advanced options.

This information also gets sent to the server in the TLS handshake. If you are using Server Name Indication (SNI) to put multiple certificates on your origin, specifying it in the SNI Hostname field will select which one is used.

Understanding the difference between certificate hostname and SNI hostname values

The following explains the difference between a certificate and SNI hostname value:

The certificate hostname (ssl_cert_hostname). This hostname validates the certificate at origin. This value should match the certificate common name (CN) or an available subject alternate name (SAN). It displays as ssl_cert_hostname in VCL. This doesn't affect the SNI certification. You can set this value in Certificate hostname field of the TLS options page.

The SNI hostname (ssl_sni_hostname). This hostname determines which certificate should be used for the TLS handshake. SNI is generally only required when your origin is using shared hosting, such as Amazon S3, or when you use multiple certificates at your origin. SNI allows the origin server to know which certificate to use for the connection. This value displays as ssl_sni_hostname in VCL. This doesn't affect the certificate validation.

If you don't enter an actual value in your certificate hostname, the .host value is used by default to verify the certificate. The .host value is the actual IP address or virtual hostname you enter in the Address field on the Host area of the Origins page. This value is matched against the certificate common name (CN) or a subject alternate name (SAN).

The table below shows you what happens when you set the Certificate and SNI hostname values in the TLS settings:

If Certificate hostname contains

and SNI hostname contains

then the Certificate Validation value will be

and the SNI value will be

www.example.com

nothing

www.example.com

nothing

nothing

www.example.org

the .host value from the Address field

www.example.org

www.example.com

www.example.org

www.example.com

www.example.org

nothing

nothing

the .host value from the Address field

nothing

About the ssl_hostname value (deprecated). The ssl_hostname value has been deprecated and replaced with ssl_cert_hostname and ssl_sni_hostname. Use these two values instead.

IMPORTANT: If you use an IP address for your .host value (i.e., by not entering a value in your certificate hostname), this will generate an error where the certificate hostname specified in your service's origin TLS settings doesn't match either the Common Name (CN) or available Subject Alternate Names (SANs).

Using a wildcard certificate

If you're using a wildcard certificate, you can use any name that matches the wildcard certificate. The table below shows a variety of possible combinations of certificate and SNI hostnames that could be used with a wildcard certificate for *.example.com:

Certificate hostname

SNI hostname

www.example.com

*.example.com

live.example.com

live.example.com

*.example.com

*.example.com

If you set the certificate hostname to *.example.com, Fastly will treat it as a literal. When using that as the certificate hostname, *.example.com is the only option for the SNI hostname.

Specifying a TLS CA certificate

If you're using a certificate that is either self-signed or signed by a certification authority (CA) not commonly recognized by major browsers (and unlikely to be in the Ubuntu bundle that we use), you can provide the certificate in PEM format via the TLS CA certificate field. The PEM format looks like this:

Specifying a TLS client certificate and key

To ensure TLS connections to your origin come from Fastly and aren't random, anonymous requests, set your origin to verify the client using a client certificate. Simply paste the certificate and private key in PEM form into the appropriate text boxes on the TLS options page.

IMPORTANT: The private key must not be encrypted with a passphrase.

Then configure your backend to require client certificates and verify them against the CA cert they were signed with. Here are some ways of doing that:

Apache

Nginx

IIS

Specifying acceptable TLS protocol versions

If your origin server is configured with support for modern TLS protocol versions, you can customize the TLS protocols Fastly will use to connect to it by setting a Minimum TLS Version and Maximum TLS Version under Advanced options. We recommend setting both to the most up-to-date TLS protocol, currently 1.2, if your origin can support it.

Use the openssl command to verify your origin supports a given TLS protocol version. For example:

openssl s_client -connect origin.example.com:443 -tls1_2

Replace -tls1_2 with tls1_1 and tls1_0 to test other protocol versions. Fastly does not support SSLv2 or SSLv3.

IMPORTANT: In line with security best practices, Fastly recommends enabling servers with version 1.2 of the TLS protocol by default. For backend connections from our edge nodes to customer origins, Fastly supports TLS 1.2, 1.1, and 1.0 depending on the versions of the protocol in use on the origin server. Fastly will continue to support TLS 1.0 based on the ServerHello message as described in RFC 5246 if the server selects TLS 1.0 as the highest supported version.

Specifying acceptable TLS cipher suites

Fastly supports configuring the OpenSSL cipher suites used when connecting to your origin server. This allows you to turn specific cipher suites on or off based on security properties and origin server support. The Ciphersuites setting under Advanced options accepts an OpenSSL formatted cipher list. We recommend using the strongest cipher suite your origin will support as detailed by the .

Use the openssl command to verify your origin supports a given cipher suite. For example:

openssl s_client -connect origin.example.com:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256

Replace -cipher ECDHE-RSA-AES128-GCM-SHA256 with the cipher suite to test.

Some customers have assets stored on multiple origin servers and want to route various requests to specific, different servers based on criteria they supply (e.g., asset type, file directory, host header). Fastly offers customers the ability to set conditions on their origins, which simply adds an if statement block to your VCL.

Basic setup: Create conditions for each origin

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Origins link. The Origins page appears.

Click the Attach a condition link to the right of the name of an origin server. The Create a new request condition window appears.

created your origin

Fill out the Create a new request condition fields as follows:

In the Name field, type a human-readable name for the condition.

In the Apply if field, type the conditions that you want to apply to your origin server. For example, for hosts, you could type req.http.host ~ "www.example.com". Or, for content-type / URL, you could type req.url ~ ".(jpg|png|gif)($|\?)".

Click the Save and apply to button. The new condition appears on the Origins page.

Click the Activate button to deploy your configuration changes.

Backup setup: Create a header

What if you have a condition already assigned to your origin? Although you can group request conditions on the origin with an 'and' or 'or' clause, there can only ever be one condition rule attached to that origin. If you want to separate your request conditions instead of grouping them, you can use header rules to route assets to different origins instead.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Content link. The Content page appears.

Click the Create header button. The Create a header page appears.

Fill out the Create a header fields as follows:

In the Name field, type Image Backend (or any meaningful, preferred name).

From the Type menu, select Request, and from the Action menu, select Set.

In the Destination field, type backend.

In the Source field, type Image_Backend. (This should match the name of your global origin server. You can see the exact name if you look at your VCL. Click on the VCL button at the top of the page.)

From the Ignore if set menu, select No.

In the Priority field, type 10.

Click the Create button. The new header appears on the Content page.

On the Content page, click the Attach a condition link next to the header you just created. The Create a new request condition window appears.

Fill out the Create a new request condition fields as follows:

In the Name field, type Redirect Images (or any meaningful, preferred name).

In the Apply if field, type req.url ~ "\.(jpg|png|gif)($|\?)".

Click the Save and apply to button. The condition appears on the Content page.

Click the Activate button to deploy your configuration changes.

TIP: Our about guide provides more information about working with conditions.

Use VCL Snippets to specify an origin

You can also use VCL Snippets to specify an origin. Once you've, you can conditionally route traffic to it.

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the VCL Snippets link. The VCL Snippets page appears.

Click Create Snippet. The Create a VCL snippet page appears.

In the Name field, type an appropriate name (e.g., Send Images to Images Backend).

From the Type controls, select within subroutine.

From the Select subroutine menu, select recv (vcl_recv).

In the VCL field, add the following condition:

1

2

3

if (req.url.ext ~ "(jpg|png|gif)") {

set req.backend = Image_Backend;

}

Click Create to create the snippet.

Click the Activate button to deploy your configuration changes.

If you want to rewrite the host header being sent to your origin regardless of the host used in the initial request, specify an override host. Use this if you have multiple domains tied to a service and want them all served by the same origin, if the domain your origin is expecting is different than one specified in your Fastly service, or if the host header being sent to your origin is different from the host used in the initial request. You most likely won't need to use this feature.

You can override the host header being sent to your origin by specifying the domain name of your override host on the Settings page for a specific service or by specifying a host on the Origins page for a specific host.

Here are some examples of when to use an override host:

When using backends such as Amazon S3, Google Cloud Storage, or Heroku, you want to ensure you use the proper host header so these providers know how to route requests directly to your content. Each provider uses the host header to associate requests with your account's storage location. For example, if you set up your origin using Amazon S3, you send the name of your S3 bucket as your host header. Amazon is set up so that it only accepts host headers that have the same name as the bucket hosting your content. A request to your-domain.com must be re-written to <your-bucket>.s3.amazonaws.com, or else the request is denied.

You have a service that contains three sites: www.abc.com, www.myexample.com, and www.mysite.com and you have one origin. You can have the same origin respond to each domain by overriding the host header to one accepted by your origin, for example, origin.example.com. The result will be that a request to www.abc.com, www.myexample.com, or www.mysite.com returns content from origin.example.com.

Overriding a host at the host level

You can add an override a host at the host level. Onceyou've added a host, follow the steps below:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Origins link. The Origins page appears.

In the Hosts area, click the pencil icon next to the host you want to edit. The Edit this host page appears.

Towards the bottom of the Edit this host page, click the Advanced options link.

In the Override host field, type the hostname of your override host header based on the origin youre using. The value in this field will take precedence over anything you've set using the override host quick configuration. Keep in mind the following:

If you're using Amazon S3 as your origin, type <yourbucket>.s3.amazonaws.com.

If you're using Google Cloud Storage as your origin, type <your bucket name>.storage.googleapis.com.

Click the Update button.

Click the Activate button to deploy your configuration changes.

Overriding a host globally

NOTE: Use the global override if you only have one backend. If you do use the global override, be sure to read all the caveats below.

You can globally override a host if your service has multiple domains to serve but they are all same assets (e.g., assets1.example.com and assets2.example.com) and you want to normalize them (e.g., assets.example.com). To globally override a host, follow the steps below:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Settings link. The Settings page appears.

Click the Override host switch. The Override host header field appears.

Shielding

In the Override host header field, type the hostname of your override host based on the origin you are using:

If you are using Amazon S3 as your origin, type <yourbucket>.s3.amazonaws.com.

If you are using Google Cloud Storage as your origin, type <your bucket name>.storage.googleapis.com.

Click the Save button. The new override host header appears in the Override host section.

Click the Activate button to deploy your configuration changes.

Caveats about using the global override host

There are situations when you may not want to use an override host:

Forcing TLS and enabling HSTS. You may experience problems if you enable this setting along with the force TLS and enable HSTS setting. Instead of enabling this setting, create a new request setting and specify the override host in the advanced options.

Using multiple origins. When you specify a host override, you're specifying what hostname is actually sent to your origin. If you have a service with two different origins and each origin requires a different hostname, specifying a host override for all requests results in one origin not returning valid responses. If you specify a default hostname that matches only one of the origins, then no content is returned from the other origin requests.

NOTE: If you want to serve content from multiple backends, you should conditionally route to them. Refer to Routing assets to different origins for more information.

Shielding is enabled. If you enable a host override along with shielding and the specified override host doesn't match to a domain within the service, the shield won't route the request properly and an error of 500 is expected. Refer to for more information.

Varnish allows you to use access control lists (ACLs), a feature that enables fast matching of a client's IP address against a list of defined IP addresses. An ACL looks like this:

1

2

3

4

5

6

# Who is allowed access ...

acl local {

"localhost";

"192.0.2.0"/24; /* and everyone on the local network */

! "192.0.2.1"/32; /* except for the dial-in router */

}

Defining an ACL

Using ACLs requires you to create and add custom VCL to Fastly's boilerplate VCL. To define an ACL in your Fastly configuration:

Read about how to mix and match custom VCL with Fastly VCL.

Create a custom VCL file with your ACL definitions included in the appropriate location. Use the example shown below as a guide. You can reference the ACL in your configuration (vcl_recv) using a match operation that can be located above or below #FASTLY recv. The placement only matters for the order of operations within Varnish's execution of your configuration.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

# If you are using the "include" keyword

include "myACL1.vcl";

# And/or if you are using an actual ACL block

acl local {

"localhost";

"192.0.2.0"/24; /* and everyone on the local network */

! "192.0.2.1"/32; /* except for the dial-in router */

}

sub vcl_recv {

# block any requests to Admin pages not from local IPs

if (req.url ~ "^/admin" && req.http.Fastly-Client-IP !~ local) {

error 403 "Forbidden";

}

}

Upload the file in the Varnish Configuration area of your service.

We understand the need for our customers to validate the security of their service behind Fastly.

IMPORTANT: Penetration tests that interfere with or disrupt the integrity or performance of Fastly services violate our acceptable use policy. You must respond immediately to any communication from Fastly regarding your test to help ensure your testing does not adversely affect other customers or the Fastly network.

To perform security testing of your Fastly service configurations, create a Customer Support ticket by contacting Fastly via email at [email protected] at least two (2) business days before you begin any security testing. In your ticket, include these details:

the IDs of the services that will be tested

the source IP address of the test

the date of the test

the start and end time of the test, including the time zone

the contact information for the individual or third party performing the test, including a phone number and e-mail address

whether or not the security test is likely to lead to significantly increased traffic volume

The following requirements apply to any security testing you perform:

Only test Fastly services you own or are authorized by the owner to test. You may not perform tests against other customers without explicit permission or against Fastly-owned resources.

Do not begin testing until after Fastly has responded affirmatively to your ticket and authorized your request.

Update the ticket if either the scope or timeframe of your testing changes.

If you discover vulnerabilities in the Fastly platform during your test, update the ticket with your findings as soon as possible so we can address them.

Fastly maintains programs for security and technology compliance. To perform an independent audit of these programs, contact [email protected] to discuss purchase of Assurance Services.

TIP: We welcome security professionals researching potential vulnerabilities in our network under our guidelines for reporting a security issue.

Fastly's Real-Time Log Streaming feature can send log files to Amazon Simple Storage Service (Amazon S3). Amazon S3 is a static file storage service used by developers and IT teams. You can also use the instructions in this guide to configure log streaming to another S3-compatible service.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Amazon S3 as a logging endpoint for Fastly services, we recommend creating an Identity and Access Management (IAM) user in Amazon S3 specifically for Fastly. Grant the user ListBucket, GetObject, and PutObject permissions for the directory in which you want to store logs. For more information, see Amazon's Getting Your Access Key ID and Secret Access Key page.

Adding Amazon S3 as a logging endpoint

After you've registered for an Amazon S3 account and created an IAM user in Amazon S3, follow these instructions to add Amazon S3 as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Amazon Web Services S3 Create endpoint button. The Create an Amazon S3 endpoint page appears.

format strings

Fill out the Create an Amazon S3 endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Bucket name field, type the name of the Amazon S3 bucket in which to store the logs.

In the Access key field, type the access key associated with the Amazon S3 bucket. See Amazon's documentation on security credentials for more information.

In the Secret key field, type the secret key associated with the Amazon S3 bucket. See Amazon's documentation on security credentials for more information.

NOTE: Password management software may mistakenly treat the Secret Key field as a password field because of the way your web browser works. As such, that software may try to auto-fill this field with your Fastly account password. If this happens to you, the AWS integration with Fastly services won't work and you will need to enter Secret Key manually instead.

In the Period field, optionally type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a new S3 endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create an Amazon S3 endpoint page as follows:

In the Path field, optionally type the path within the bucket to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the bucket's root path. Our guide on changing where log files are written provides more information.

In the Domain field, optionally type the domain of the Amazon S3 endpoint. If your Amazon S3 bucket was not created in the US Standard region, you must set the domain to match the appropriate endpoint URL. Use the table in the S3 section of the Regions and Endpoints Amazon S3 documentation page. If you want to use an S3-compatible storage system (such as Dreamhost's DreamObjects ), set the domain to match the domain name for that service (for example, in the case of DreamObjects, the domain name would be objects.dreamhost.com).

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on WAF logging for more information about waf_debug_log.

In the Gzip level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

From the Redundancy level menu, select a setting. This value defaults to Standard. Amazon's Using Reduced Redundancy Storage Guide provides more information on using reduced redundancy storage.

From the ACL menu, optionally select an access control header. See Amazon's Access Control List (ACL) Specific Request Headers for more information.

In the Server side encryption area, optionally select an encryption method to protect files that Fastly writes to your Amazon S3 bucket. Valid values are None, AES-256, and AWS Key Management Service. If you select AWS Key Management Service, you'll have to provide an AWS KMS Key ID. See Amazon's guide on protecting data using server-side encryption for more information.

Our discussion of also provides more information.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

NOTE: Although Fastly continuously streams logs into Amazon S3, the Amazon S3 website and API do not make files available for access until after their upload is complete.

Fastly's Real-Time Log Streaming feature can send log files to Microsoft Azure Blob Storage (Blob Storage). Blob Storage is a static file storage service used to control arbitrarily large amounts of unstructured data and serve them to users over HTTP and HTTPS.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Blob Storage as a logging endpoint for Fastly services, create an Azure storage account in the Azure portal. For help creating the account, see Microsoft's account creation documentation.

We recommend creating a Shared Access Signature (SAS) user specifically for Fastly. For more information, see Microsoft's shared access signatures (SAS) documentation, paying specific attention to the Account SAS URI example.

Here is an example of a SAS token that provides write permissions to a blob:

sv=2018-04-05&st=2018-04-29T22%3A18%3A26Z&sr=b&se=2020-04-30T02%3A23%3A26Z&sp=w&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

The table breaks down each part of the token to understand how it contributes to the SAS:

Element

Example

Description

sv

sv=2018-04-05

Storage services version.

sr

sr=b

Store resources for which this token has access. We require blob (b).

st

st=2018-04-29T22%3A18%3A26Z

The start time of the token, specified in UTC.

se

se=2020-04-30T02%3A23%3A26Z

The expiry time of the token, specified in UTC. Ensure you update your token before it expires or the logging functionality will not work.

sp

sp=w

The permissions granted by the SAS token. We require write (w).

sig

sig=Z%2FRHIX5Xcg0Mq2...

The signature to authorize access to the blob.

Adding Blob Storage as a logging endpoint

After you've registered for an Azure account and created a SAS token, follow these instructions to add Blob Storage as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Azure Blob Storage Create endpoint button. The Create a Microsoft Azure Blob Storage endpoint page appears.

changing log line formats

Fill out the Create a Microsoft Azure Blob Storage endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Storage account name field, type the unique Azure namespace in which your data objects will be stored.

In the Container field, type the name of the Blob Storage container to store logs in. See Microsoft's Blob storage page for more information.

In the SAS token field, type the token associated with the container.

TIP: Ensure you update your token before it expires otherwise the logging functionality will not work.

In the Period field, optionally type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

Click the Advanced options link of the Create a Microsoft Azure Blob Storage endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Microsoft Azure Blob Storage endpoint page as follows:

In the Path field, optionally type the path within the container to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the container's root path. Our guide on changing where log files are written provides more information.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on WAF logging for more information about waf_debug_log.

In the Gzip level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

NOTE: Although Fastly continuously streams logs into Azure Blob Storage, the storage portal and API do not make files available for access until after their upload is complete.

Ingesting data for Azure Data Explorer

Azure Data Explorer is a data exploration service for log and telemetry data. To ingest your data correctly, Data Explorer requires your logs to be formatted as comma-separated values (CSVs). When creating your logging endpoint:

Set the Log format to a CSV string ( %H,%{time.start.sec}V,%{regsub(req.http.User-Agent, {"""}, {""""})}V).

Specify blank when you Select a log line format in the Advanced options.

Our guide on provides more information.

Fastly's Real-Time Log Streaming feature can send log file to Cloud Files. Operated by Rackspace, Cloud Files is a file storage service used by developers and IT teams.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

If you don't already have a Rackspace Cloud account, you'll need to register for one. Follow the instructions on Rackspace's website.

Creating a Cloud Files user and container

Start by creating a Cloud Files user with restricted permissions via Rackspace's cloud control panel.

Log in to Rackspace's cloud control panel.

From the user account menu, select User Management.

Click Create User and fill in all appropriate details.

In the Product Access section, set User Role to Custom.

Review the Product Access list. For all items in the Product column, set Role to No Access except the Files item.

Set the Files item Role to Admin. This will allow you to create the files to store the logs in, but not access any other services.

Next, find the API key for your Cloud Files account. You'll use this later to authenticate using the Cloud Files API.

From the user account menu, select Account Settings.

Show the API key in the Login details and make a note of it.

Now that you've created the Cloud Files user and found the API key, you can set up a Cloud Files container.

From the Storage menu, select Files.

Click Create Container.

Assign the container a meaningful name like Fastly logs - my service.

Choose a region to keep the files in and make sure the container is private.

Click Create Container.

Adding a Cloud Files logging endpoint

Once you have created the Cloud Files user and container, follow these instructions to add Cloud Files as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Rackspace Cloud Files Create endpoint button. The Create a Cloud Files endpoint page appears.

WAF logging

Fill out the Create a Cloud Files endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Bucket name field, type the name of the Cloud Files container in which to store the logs.

In the User field, type the username of the Cloud Files user you created above.

In the Access key field, type the API key of your Cloud Files account.

In the Period field, type an interval (in seconds) to manage how frequently in seconds to rotate your log files. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a Cloud Files endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Cloud Files endpoint page as follows:

In the Path field, optionally type the path within the container to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the container's root path. Our guide on changing where log files are written provides more information.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

From the Region menu, select the region to stream logs to.

In the Gzip level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can be configured to send logs in a format readable by Datadog. Datadog is a cloud-based monitoring and analytics solution that allows you to see inside applications within your stack and aggregate the results.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Datadog as a logging endpoint for Fastly services, you will need to:

Register for a Datadog account. You can sign up for a Datadog account on their site. A free plan exists that has some restrictions or you can upgrade for more features. Where you register your Datadog setup, either in the United States (US) or the European Union (EU), will affect which commands you use during logging endpoint setup at Fastly.

Get your Datadog API key from your settings page on Datadog. In the Datadog interface, navigate to " Integrations -> APIs " where you'll be able to create or retrieve an API key.

logging pipelines

This example displays the key decafbaddeadbeef. Your API key will be different. Make a note of this key somewhere.

Adding Datadog as a logging endpoint

After you've created a Datadog account and noted your Datadog API key, follow the steps below to add Datadog as a logging endpoint for Fastly services.

Review the information in our Setting Up Remote Log Streaming guide.

Click the Datadog (via Syslog) Create endpoint button. The Create a Syslog endpoint page appears.

Fill out the Create a Syslog endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, set the format to be the Datadog API key you noted earlier, followed by a space and then your log string in JSON format. Be sure to add the JSON as a single line to ensure proper parsing. We've described the use of this format below with additional suggestions.

In the Syslog address field, enter the appropriate information in the domain and port fields according to where your Datadog account is registered. Enter either intake.logs.datadoghq.com (for the US) or tcp-intake.logs.datadoghq.eu (for the EU) in the domain field before the colon, and then enter either 10516 (for the US) or 443 (for the EU) in the port field after the colon.

Leave the Token field blank.

From the TLS menu, select Yes to enable encryption for the syslog endpoint. The TLS Hostname and TLS CA Certificate fields will both appear.

In the TLS Hostname field, enter the appropriate information according to where your Datadog account is registered. Enter either intake.logs.datadoghq.com (for the US) or tcp-intake.logs.datadoghq.eu (for the EU). This is the hostname Fastly will use to verify the syslog server's certificate.

Leave the TLS CA certificate field blank.

Click the Advanced options link of the Create a Syslog endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Syslog endpoint page as follows:

In the Select a log line format area, select blank. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on WAF logging for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Logs should begin appearing in your Datadog account a few seconds after you've created the endpoint and deployed your service changes. These logs can then be accessed via the Datadog Log Explorer on your Datadog account.

Using the JSON logging format

Datadog automatically parses log files created in JSON format, making this format the easiest way to get data into Datadog because no customized logging rules are required. In addition, Datadog recognizes several reserved fields, such as service and date.

NOTE: The JSON in this example is formatted for ease of reading. For proper parsing, it must be added as a single line in the Log format field, removing all line breaks and indentation whitespace first.

For example, in the JSON below we've set service to the ID of the Fastly service that sent the log but you could also use a human-readable name or you could group all logs under a common name such as fastly.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

{

"ddsource": "fastly",

"service": "%{req.service_id}V",

"date": "%{begin:%Y-%m-%dT%H:%M:%S%Z}t",

"time_start": "%{begin:%Y-%m-%dT%H:%M:%S%Z}t",

"time_end": "%{end:%Y-%m-%dT%H:%M:%S%Z}t",

"http": {

"request_time_ms": %D,

"method": "%m",

"url": "%{json.escape(req.url)}V",

"useragent": "%{User-Agent}i",

"referer": "%{Referer}i",

"protocol": "%H",

"request_x_forwarded_for": "%{X-Forwarded-For}i",

"status_code": "%s"

},

"network": {

"client": {

"ip": "%h",

"name": "%{client.as.name}V",

"number": "%{client.as.number}V",

"connection_speed": "%{client.geo.conn_speed}V"

},

"destination": {

"ip": "%A"

},

"geoip": {

"geo_city": "%{client.geo.city.utf8}V",

"geo_country_code": "%{client.geo.country_code}V",

"geo_continent_code": "%{client.geo.continent_code}V",

"geo_region": "%{client.geo.region}V"

},

"bytes_written": %B,

"bytes_read": %{req.body_bytes_read}V

},

"host": "%{Fastly-Orig-Host}i",

"origin_host": "%v",

"is_ipv6": %{if(req.is_ipv6, "true", "false")}V,

"is_tls": %{if(req.is_ssl, "true", "false")}V,

"tls_client_protocol": "%{json.escape(tls.client.protocol)}V",

"tls_client_servername": "%{json.escape(tls.client.servername)}V",

"tls_client_cipher": "%{json.escape(tls.client.cipher)}V",

"tls_client_cipher_sha": "%{json.escape(tls.client.ciphers_sha)}V",

"tls_client_tlsexts_sha": "%{json.escape(tls.client.tlsexts_sha)}V",

"is_h2": %{if(fastly_info.is_h2, "true", "false")}V,

"is_h2_push": %{if(fastly_info.h2.is_push, "true", "false")}V,

"h2_stream_id": "%{fastly_info.h2.stream_id}V",

"request_accept_content": "%{Accept}i",

"request_accept_language": "%{Accept-Language}i",

"request_accept_encoding": "%{Accept-Encoding}i",

"request_accept_charset": "%{Accept-Charset}i",

"request_connection": "%{Connection}i",

"request_dnt": "%{DNT}i",

"request_forwarded": "%{Forwarded}i",

"request_via": "%{Via}i",

"request_cache_control": "%{Cache-Control}i",

"request_x_requested_with": "%{X-Requested-With}i",

"request_x_att_device_id": "%{X-ATT-Device-Id}i",

"content_type": "%{Content-Type}o",

"is_cacheable": %{if(fastly_info.state~"^(HIT|MISS)$", "true","false")}V,

"response_age": "%{Age}o",

"response_cache_control": "%{Cache-Control}o",

"response_expires": "%{Expires}o",

"response_last_modified": "%{Last-Modified}o",

"response_tsv": "%{TSV}o",

"server_datacenter": "%{server.datacenter}V",

"req_header_size": %{req.header_bytes_read}V,

"resp_header_size": %{resp.header_bytes_written}V,

"socket_cwnd": %{client.socket.cwnd}V,

"socket_nexthop": "%{client.socket.nexthop}V",

"socket_tcpi_rcv_mss": %{client.socket.tcpi_rcv_mss}V,

"socket_tcpi_snd_mss": %{client.socket.tcpi_snd_mss}V,

"socket_tcpi_rtt": %{client.socket.tcpi_rtt}V,

"socket_tcpi_rttvar": %{client.socket.tcpi_rttvar}V,

"socket_tcpi_rcv_rtt": %{client.socket.tcpi_rcv_rtt}V,

"socket_tcpi_rcv_space": %{client.socket.tcpi_rcv_space}V,

"socket_tcpi_last_data_sent": %{client.socket.tcpi_last_data_sent}V,

"socket_tcpi_total_retrans": %{client.socket.tcpi_total_retrans}V,

"socket_tcpi_delta_retrans": %{client.socket.tcpi_delta_retrans}V,

"socket_ploss": %{client.socket.ploss}V

}

Using logging formats other than JSON

The log format you specify doesn't have to be JSON. If you use other formats however, you'll need to parse the log manually instead. When selecting a format other than JSON, choose the format that best suits your needs (such as Apache Common Log Format) and then use Datadog's Grok Parser to extract the fields you want.

Fastly's guide to logging formats provides more information about using custom log formats with streaming logs. We also provide additional request and response variables for use with logging beyond the standard logging directives. Our guide to useful logging variables describes these in more detail.

When you use a logging format other than JSON, consider using Datadog's feature, which allows you to create a filtered subset of incoming logs. For example, you could use the User-Agent Parser to identify details like web browser, operating system, and device type and model, or the URL Parser to identify details like protocol, domain, and query string. Simply add these parsers to a Datadog pipeline and adjust the mapping as necessary.

Fastly's Real-Time Log Streaming feature can send log files to DigitalOcean Spaces. DigitalOcean Spaces is an Amazon S3-compatible static file storage service used by developers and IT teams.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding DigitalOcean Spaces as a logging endpoint for Fastly services, you'll need to create a DigitalOcean account if you don't already have one. Then you'll need to create a space with private access permissions on DigitalOcean's website, generate a secret key and an access key, and make a note of the endpoint.

Adding DigitalOcean Spaces as a logging endpoint

After you've created a DigitalOcean Space, follow these instructions to add DigitalOcean Spaces as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Spaces by DigitalOcean Create endpoint button. The Create a DigitalOcean endpoint page appears.

WAF logging

Fill out the Create a DigitalOcean endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Bucket name field, type the name of the DigitalOcean Space in which to store the logs.

In the Access key field, type the access key associated with the DigitalOcean Space. See the DigitalOcean Spaces Authentication Guide for more information.

In the Secret key field, type the secret key associated with the DigitalOcean Space.

In the Period field, optionally type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a DigitalOcean endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a DigitalOcean endpoint page as follows:

In the Path field, optionally type the path within the container to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the container's root path. Our guide on changing where log files are written provides more information.

In the Domain field, type the region-specific endpoint for your domain. In most cases, this should be nyc3.digitaloceanspaces.com. If the DigitalOcean Space was not created in the nyc3 region, refer to DigitalOcean's documentation to find the correct domain.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

In the Gzip level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to BigQuery, Google's managed enterprise data warehouse.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding BigQuery as a logging endpoint for Fastly services, you will need to:

Register for a Google Cloud Platform (GCP) account.

Create a service account on Google's website.

Obtain the private_key and client_email from the JSON file associated with the service account.

Enable the BigQuery API.

Create a BigQuery dataset.

Add a BigQuery table.

Creating a service account

BigQuery uses service accounts for third-party application authentication. To create a new service account, see Google's guide on generating service account credentials. When you create the service account, set the key type to JSON.

Obtaining the private key and client email

After you create the service account, download the JSON file to your computer. This file contains the credentials for your BigQuery service account. Open the file and make a note of the private_key and client_email.

Enabling the BigQuery API

To send your Fastly logs to your BigQuery table, you'll need to enable the BigQuery API in the Google Cloud Platform API Manager.

Creating the BigQuery dataset

After you've enabled the BigQuery API, follow these instructions to create a BigQuery dataset:

Log in to BigQuery.

Click the arrow next to your account name on the sidebar and select Create new dataset.

WAF logging

The Create Dataset window appears.

In the Dataset ID field, enter a name for the dataset (e.g., fastly_bigquery).

Click the OK button.

Adding a BigQuery table

After you've created the BigQuery dataset, you'll need to add a BigQuery table. There are four ways of creating the schema for the table:

Edit the schema using the BigQuery web interface.

Edit the schema using the text field in the BigQuery web interface.

Use an existing table.

Set the table to automatically detect the schema.

NOTE: Setting the table to automatically detect the schema may give unpredictable results.

Follow these instructions to add a BigQuery table:

On the BigQuery website, click the arrow next to the dataset name on the sidebar and select Create new table.

The Create Table page appears.

In the Source Data section, select Create empty table.

In the Table name field, enter a name for the table (e.g., logs).

In the Schema section of the BigQuery website, use the interface to add fields and complete the schema. See the example schema section for details.

Create the Create Table button.

Adding BigQuery as a logging endpoint

Follow these instructions to add BigQuery as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Google BigQuery Create endpoint button. The Create a BigQuery endpoint page appears.

Fill out the Create a BigQuery endpoint fields as follows:

In the Name field, enter a human-readable name for the endpoint.

In the Log format field, enter the data to send to BigQuery. See the example format section for details.

In the Email field, enter the client_email address associated with the BigQuery service account.

In the Secret key field, enter the value of the private_key associated with your BigQuery service account.

In the Project ID field, enter the ID of your Google Cloud Platform project.

In the Dataset field, enter the name of your BigQuery dataset.

In the Table field, enter the name of your BigQuery table.

In the Template field, optionally enter an strftime compatible string to use as the template suffix for your table.

Click the Advanced options link of the Create a BigQuery endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click Create to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Example format

Data sent to BigQuery must be serialized as a JSON object, and every field in the JSON object must map to a string in your table's schema. The JSON can have nested data in it (e.g. the value of a key in your object can be another object). Here's an example format string for sending data to BigQuery:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

{

"timestamp":"%{begin:%Y-%m-%dT%H:%M:%S}t",

"time_elapsed":%{time.elapsed.usec}V,

"is_tls":%{if(req.is_ssl, "true", "false")}V,

"client_ip":"%{req.http.Fastly-Client-IP}V",

"geo_city":"%{client.geo.city}V",

"geo_country_code":"%{client.geo.country_code}V",

"request":"%{req.method}V",

"host":"%{req.http.Fastly-Orig-Host}V",

"url":"%{json.escape(req.url)}V",

"request_referer":"%{json.escape(req.http.Referer)}V",

"request_user_agent":"%{json.escape(req.http.User-Agent)}V",

"request_accept_language":"%{json.escape(req.http.Accept-Language)}V",

"request_accept_charset":"%{json.escape(req.http.Accept-Charset)}V",

"cache_status":"%{regsub(fastly_info.state, "^(HIT-(SYNTH)|(HITPASS|HIT|MISS|PASS|ERROR|PIPE)).*", "\\2\\3") }V"

}

Example schema

The BigQuery schema for the example format shown above would look something like this:

1

timestamp:TIMESTAMP,time_elapsed:FLOAT,is_tls:BOOLEAN,client_ip:STRING,geo_city:STRING,geo_country_code:STRING,request:STRING,host:STRING,url:STRING,request_referer:STRING,request_user_agent:STRING,request_accept_language:STRING,request_accept_charset:STRING,cache_status:STRING

Fastly's Real-Time Log Streaming feature can send log files to password-protected and anonymous FTP servers.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Adding FTP as a logging endpoint

Follow these instructions to add FTP as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the FTP Create endpoint button. The Create a File Transfer Protocol (FTP) endpoint page appears.

WAF logging

Fill out the Create a File Transfer Protocol (FTP) endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Address field, type the hostname or IP address of the FTP server. In the port field, type the port number you're using for FTP (the default is 21).

In the Path field, optionally type the path to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the root path. Our guide on changing where log files are written provides more information.

In the User field, type the username used to authenticate to the FTP server. For anonymous access, use the username anonymous.

In the Password field, type the password used to authenticate to the FTP server. For anonymous access, use an email address as the password.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Period field, type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a File Transfer Protocol (FTP) endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a File Transfer Protocol (FTP) endpoint page as follows:

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

In the Gzip Level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to Google Cloud Storage (GCS). GCS is an online file storage service used for storing and accessing data on Google's infrastructure. One advantage of using GCS is that you can use Google BigQuery to analyze the log files.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding GCS as a logging endpoint for Fastly services, you will need to:

Register for a GCS account.

Create a bucket and service account on Google's website.

Obtain the private_key and client_email from the JSON file associated with the service account.

Enable the Google Cloud Storage JSON API.

Creating a GCS bucket

You can create a new GCS bucket to hold the logs, or you can use an existing bucket. Be sure to note the name of the bucket as you will need it later. To learn how to create a GCS bucket, see Google's guide on creating a bucket.

Creating a service account

GCS uses service accounts for third-party application authentication. You will need to create a new service account on Google's website with the role of Storage Object Creator and make sure you've added it as a member of the GCS bucket you created. To learn how to create a service account, see Google's guide on generating a service account credential. When you create the service account, be sure to set the Key Type to JSON.

Obtaining the private key and client email

After you create the service account, a JSON file will be downloaded to your computer. This file contains the credentials for the GCS service account you just created. Open the file with a text editor and make a note of the private_key and client_email.

Enabling the Google Cloud Storage JSON API

To ensure the Fastly logs are sent to your GCS bucket, you need to enable the Google Cloud Storage JSON API. For more information, see Google's instructions for activating the API.

Adding GCS as a logging endpoint

Follow these instructions to add GCS as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Google Cloud Services Create endpoint button. The Create a Google Cloud Storage (GCS) endpoint page appears.

WAF logging

Fill out the Create a Google Cloud Storage (GCS) endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Email field, type the client_email address listed in the JSON file associated with the service account you created on Google's website.

In the Bucket name field, type the name of the GCS bucket in which to store the logs.

In the Secret key field, type the private_key value listed in the JSON file associated with the service account you created on Google's website. We strip out the JSON newline escape characters for you so don't worry about removing them.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Period field, optionally type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a Google Cloud Storage (GCS) endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Google Cloud Storage (GCS) endpoint page as follows:

In the Path field, optionally type the path within the bucket to store the files. Specify a directory by ending the path with a trailing slash (/). Leaving this field empty saves the files in the bucket's root path. Our guide on changing where log files are written provides more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

In the Gzip Level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click Create to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send logs in JSON format to Honeycomb. Honeycomb is a tool that allows developers to explore the operations of complex systems, microservices, and databases.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding Honeycomb as a logging endpoint for Fastly services, you'll need to perform the following steps:

Sign up for a Honeycomb account if you don't already have one.

Obtain the Write Key for your team on the Honeycomb Account page.

Choose a Dataset name. If you plan to collect data from multiple environments (like production, development, staging), Honeycomb recommends creating a Dataset for each environment and naming your Datasets accordingly (e.g., prod.queries, dev.queries, and staging.queries). If a Dataset doesn't exist, Honeycomb will create one automatically.

Adding Honeycomb as a logging endpoint

Review the information in our Setting Up Remote Log Streaming guide.

Click the Honeycomb Create endpoint button. The Create a Honeycomb endpoint page appears.

WAF logging

Fill out the Create a Honeycomb endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, enter the data to send to Honeycomb. See the example format section for details.

In the Write Key field, type the write key for your Honeycomb team. This is available on the Honeycomb Account page.

In the Dataset field, type the name of the Honeycomb Dataset (e.g., myDataset).

Click the Advanced options link of the Create a Honeycomb endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Example format

Data sent to Honeycomb must be serialized as a JSON object. Here's an example format string for sending data to Honeycomb:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

{

"time":"%{begin:%Y-%m-%dT%H:%M:%SZ}t",

"data": {

"service_id":"%{req.service_id}V",

"time_elapsed":%D,

"request":"%m",

"host":"%{Fastly-Orig-Host}i",

"url":"%{cstr_escape(req.url)}V",

"protocol":"%H",

"is_ipv6":%{if(req.is_ipv6, "true", "false")}V,

"is_tls":%{if(req.is_ssl, "true", "false")}V,

"is_h2":%{if(fastly_info.is_h2, "true", "false")}V,

"client_ip":"%h",

"geo_city":"%{client.geo.city.utf8}V",

"geo_country_code":"%{client.geo.country_code}V",

"server_datacenter":"%{server.datacenter}V",

"request_referer":"%{Referer}i",

"request_user_agent":"%{User-Agent}i",

"request_accept_content":"%{Accept}i",

"request_accept_language":"%{Accept-Language}i",

"request_accept_charset":"%{Accept-Charset}i",

"cache_status":"%{regsub(fastly_info.state, "^(HIT-(SYNTH)|(HITPASS|HIT|MISS|PASS|ERROR|PIPE)).*", "\\2\\3") }V",

"status":"%s",

"content_type":"%{Content-Type}o",

"req_header_size":%{req.header_bytes_read}V,

"req_body_size":%{req.body_bytes_read}V,

"resp_header_size":%{resp.header_bytes_written}V,

"resp_body_size":%{resp.body_bytes_written}V,

}

}

Fastly's Real-Time Log Streaming feature can send log files to Log Shuttle. Log Shuttle is an open source application designed to provide simpler encrypted and authenticated log delivery.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Adding Log Shuttle as a logging endpoint

Follow these instructions to add Log Shuttle as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Log Shuttle Create endpoint button. The Create a Log Shuttle endpoint page appears.

WAF logging

Fill out the Create a Log Shuttle endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default.

In the Token field, type the data authentication token. This is required for some endpoints like Heroku's Log Integration.

In the URL field, type the URL to which log data will be sent (e.g., https://logs.example.com/).

Click the Advanced options link of the Create a Log Shuttle endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can be configured to send logs in a format that is readable by LogDNA. LogDNA is a cloud-based log management system that aggregates system and application logs into a single location.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before adding LogDNA as a logging endpoint for Fastly services, you'll need to perform the following steps:

Sign up for a LogDNA account if you don't already have one. You can sign up for a free (but restricted plan) or upgrade a LogDNA plan to include more features.

Set up a new LogDNA syslog source via the LogDNA web application by following their account-tailored log source instructions. Be sure to make note of the port number displayed at the end of the syslog URL when you complete set up. This is the port number you'll enter when setting up LogDNA as a logging endpoint for Fastly.

Fetch the LogDNA root CA certificate and save it for use during endpoint setup.

Adding LogDNA as a logging endpoint

Review the information in our Setting Up Remote Log Streaming guide.

Click the LogDNA (via Syslog ) Create endpoint button. The Create a Syslog endpoint page appears.

WAF logging

Fill out the Create a Syslog endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Syslog address field, type syslog-a.logdna.com in the domain field before the colon, and in the port field after the colon type the LogDNA port number you noted during your LogDNA account setup.

From the TLS menu, select Yes to enable encryption for the syslog endpoint. The TLS Hostname and TLS CA Certificate fields will both appear.

In the TLS Hostname field, type syslog-a.logdna.com. This is the hostname Fastly will use to verify the syslog server's certificate.

In the TLS CA certificate field, copy and paste the contents of the LogDNA root Certificate file you fetched.

Click the Advanced options link of the Create a Syslog endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Syslog endpoint page as follows:

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Logs should begin appearing in your LogDNA account a few seconds after you've created the endpoint and deployed your service.

Fastly's Real-Time Log Streaming feature can send log files to Logentries. Logentries is a real-time log management and analytics system that you can use to monitor your Fastly logs.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

One-click Logentries account setup

Fastly has partnered with Logentries to offer you a method for automatically creating a Logentries account and configuring a logging endpoint. By using the Logentries one-click integration, you can create a 30 day trial Logentries account with unlimited data. After 30 days, if you don't upgrade to one of the Logentries premium plans, your account will be capped at 5GB per month.

Follow these instructions to create a Logentries logging endpoint and configure the logging endpoint:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Logging link. The Logging endpoints page appears. If you have an existing logging endpoint, click the Create endpoint button.

Fastly Community Pack

In the Logentries One-click setup box, click the Create Account button. The Logentries log is automatically created.

Click the Activate button to deploy your configuration changes.

Accessing your Logentries account

If you created a Logentries account using the one-click integration, you must access your Logentries account from the Fastly web application. Follow these instructions to log in to Logentries:

Log in to the Fastly web interface and click the Configure link.

From the service menu, select the appropriate service.

Click the Edit configuration button and then select Clone active. The Domains page appears.

Click the Logging link. The Logging endpoints page appears.

Click the Logentries log view link to access your Logentries account dashboard.

Manually adding Logentries as a logging endpoint

If you already have a Logentries account, or if you'd prefer to sign up for a Logentries account on the Logentries website, you can manually add Logentries as a logging endpoint in the Fastly web interface.

Prerequisites

Register for a Logentries account.

Create a new log in the Logentries application by following the instructions on the Logentries website

During new log creation, select Manual Configuration and Token TCP.

Make a note of the token provided in the Logentries configuration panel. We recommend you use this token when you create the Logentries logging endpoint for Fastly services.

Creating the logging endpoint in the web interface

After you've created a new log in Logentries and found the token, follow these instructions to add Logentries as a logging endpoint for Fastly services:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Logentries by Rapid7 Create endpoint button. The Create a Logentries endpoint page appears.

Fill out the Create a Logentries endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. Our discussion of format strings also provides more information.

In the Token field, type the token provided in the Logentries configuration panel. Though you can use the provided secret port number, there are additional options to consider when deciding on token settings.

Click the Advanced options link of the Create a Logentries endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create a Logentries endpoint page as follows:

In the Port field, type 20000. Though we recommend this specific setting when adding your endpoint, there are additional options to consider when deciding on the port and TLS settings.

From the TLS menu, optionally select Yes.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on WAF logging for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Additional selections for tokens, ports, and TLS

Using your token. You can add a Logentries endpoint by using your secret account token. To use your token, set your port to 10000. However, we strongly recommend sending your logs via TLS. To do this, set TLS to Yes and the port number to 20000. See the Logentries guide Token TCP for more information.

Using your port number. You can add a Logentries endpoint by using your secret Logentries port number (e.g., 56789). However, we strongly recommend sending your logs via TLS. To do this, set TLS to Yes and add 10000 to your secret port number (e.g., 66789). See the Logentries guide Plain TCP/UDP for more information.

Next steps

Logentries maintains the that leverages custom VCL to provide advanced User-Agent statistics, regional statistics, error tracking, and more.

As part of our Real-Time Log Streaming feature, if you use our Heroku add-on, you can send log files directly to Heroku's Logplex system. Logplex is Heroku's distributed syslog router that collates and distributes log entries from a variety of sources into a single channel.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

Before continuing, you will need the token from your Heroku Logplex account. If you don't have a Heroku Logplex account, now is the time to set one up by signing up for Heroku.

Once enabled, your Fastly logs will be available in exactly the same way as your regular app and hosted service logs. You can view them using the Heroku command line log viewer or send them to a logging add-on.

Adding Heroku Logplex as a logging endpoint

Follow these instructions to add Heroku Logplex as a logging endpoint for Fastly services:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Heroku Logplex Create endpoint button. The Create a Heroku Logplex endpoint page appears.

WAF logging

Fill out the Create a Heroku Logplex endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. Our discussion of format strings also provides more information.

In the Token field, type your Heroku Logplex token.

In the URL field, type https://1.us.logplex.io/logs unless otherwise instructed by our support staff.

Click the Advanced options link of the Create a Heroku Logplex endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to Loggly. Loggly is an agent-less log collection and management tool.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

If you don't already have a Loggly account, you'll need to register for one. Follow the signup instructions on the Loggly website.

Follow the steps below to find your Loggly customer token:

Navigate to the Customer Tokens area in the Source Setup on your Loggly dashboard.

WAF logging

Make note of your Loggly customer token. Loggly uses this to associate data you send them with your account.

Adding Loggly as a logging endpoint

After you've created a Loggly account and obtained your customer token, follow these instructions to add Loggly as a logging endpoint for Fastly services:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Loggly Create endpoint button. The Create a Loggly endpoint page appears.

Fill out the Create a Loggly endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. Our discussion of format strings provides more information.

In the Token field, type your Loggly customer token.

Click the Advanced options link of the Create a Loggly endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to OpenStack. OpenStack is an open-source platform for cloud-computing that many companies deploy as an infrastructure-as-a-service.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Adding OpenStack as a logging endpoint

Follow these instructions to add OpenStack as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the OpenStack Create endpoint button. The Create an OpenStack endpoint page appears.

WAF logging

Fill out the Create an OpenStack endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written provides more information.

In the Auth URL field, type the URL used for OpenStack authentication (e.g., https://auth.api.rackspacecloud.com/v1.0).

In the Bucket name field, type the name of the OpenStack bucket in which to store the logs.

In the User field, type your OpenStack username.

In the Access Key field, type your OpenStack access key.

In the Period field, type an interval (in seconds) to control how frequently to rotate your log files. This value defaults to 3600 seconds.

Click the Advanced options link of the Create a new OpenStack endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create an OpenStack endpoint page as follows:

In the Path field, optionally type the path within the bucket to store the files. The path ends with a trailing slash. If this field is left empty, the files will be saved in the bucket's root path. Our guide on changing where log files are written provides more information.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You will only be able to read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. See our guide on log encryption for more information.

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

In the Gzip Level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to Scalyr. Scalyr pulls all your server logs and metrics into a centralized, searchable system in real time.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Prerequisites

If you don't already have a Scalyr account, you'll need to register for one. Follow the signup instructions on the Scalyr website.

Once you've signed up, navigate to the API Keys area in the Settings on your Scalyr dashboard and make note of your Scalyr Write Token. Scaylr uses this to associate data you send them with your account. You'll need this token when you set up your endpoint with Fastly.

If you're adding the Scalyr endpoint via the command line, instead of the web interface, you should also have your Fastly API token and the service ID and version number of the Fastly service for which you'll be enabling Scalyr logging.

Adding Scalyr as a logging endpoint

Follow these instructions to add Scalyr as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the Scalyr Create endpoint button. The Create a Scalyr endpoint page appears.

WAF logging

Fill out the Create a Scalyr endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default. See our guidance on format strings for more information.

In the Token field, type the Scalyr Write Token provided in the Scalyr dashboard.

Click the Advanced options link of the Create a Scalyr endpoint page. The Advanced options appear.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.

Fastly's Real-Time Log Streaming feature can send log files to SFTP, a secure file transfer subsystem for the Secure Shell (SSH) protocol. Our SFTP endpoint supports both password-based authentication and SSH public-key authentication, with SSH public-key authentication being preferred. To learn more about SSH public-key authentication, or to learn how to generate public and private key pairs, see this guide.

NOTE: Fastly does not provide direct support for third-party services. See Fastly's Terms of Service for more information.

Adding SFTP as a logging endpoint

Follow these instructions to add SFTP as a logging endpoint:

Review the information in our Setting Up Remote Log Streaming guide.

Click the SFTP Create endpoint button. The Create an SSH File Transfer Protocol (SFTP) endpoint page appears.

WAF logging

Fill out the Create an SSH File Transfer Protocol (SFTP) endpoint fields as follows:

In the Name field, type a human-readable name for the endpoint.

In the Log format field, optionally type an Apache-style string or VCL variables to use for log formatting. The Apache Common Log format string appears in this field by default.

In the Timestamp format field, optionally type a timestamp format for log files. The default is an strftime compatible string. Our guide on changing where log files are written](https://support.fastly.com/hc/en-us/articles/360035071352-Changing-where-log-files-are-written) provides more information.

In the Address field, type the hostname or IP address of the SFTP server. In the port field after the colon, type the port number you're using for SFTP (the default is 22).

In the Path field, type the path to use for storing log files. Leaving the default / in this field means the files will be saved in the root path. We describe this variable in more detail in our guide on changing where log files are written.

TIP: If you save logs on the SFTP server, make sure the directory already exists.

In the User field, type the username used to authenticate to the SFTP server.

In the Known hosts field, type a host key for each host you can connect to over SFTP. Each host key you enter must be on its own line. Known hosts entries should match whats stored in your known_hosts file located in your home directory (or the local account settings if you're working with a Mac or Windows operating system). A known hosts entry looks like this:

1.2.3.4 ecdsa-sha2-nistp256 aBc123xYz

where the 1.2.3.4 is the SFTP IP address, ecdsa-sha2-nistp256 is your host key algorithm, and aBc123xYz is your public key.

In the Secret key field, type the SSH secret key used to connect to the server. If both Secret key and Password are entered, the Secret key will be used in preference.

In the Password field, type the password used to authenticate to the SFTP server. If both Password and Secret key are entered, the Secret key will be used in preference.

In the Period field, type an interval (in seconds) to control how frequently your log files are rotated. This value defaults to 3600 seconds.

Click the Advanced options link of the Create an SSH File Transfer Protocol (SFTP) endpoint page and decide which of the optional fields to change, if any.

Fill out the Advanced options of the Create an SSH File Transfer Protocol (SFTP) endpoint as follows:

In the Select a log line format area, select the log line format for your log messages. Our guide on changing log line formats provides more information.

In the PGP public key field, optionally type a PGP public key that Fastly will use to encrypt your log files before writing them to disk. You only can read the contents by decrypting them with your private key. The PGP key should be in PEM (Privacy-Enhanced Mail) format. Our guide on log encryption provides more information.

In the Placement area, select where the logging call should be placed in the generated VCL. Valid values are Format Version Default, None, and waf_debug (waf_debug_log). Selecting None creates a logging object that can only be used in custom VCL. See our guide on for more information about waf_debug_log.

In the Gzip level field, optionally type the level of gzip compression you want applied to the log files. You can specify any whole number from 1 (fastest and least compressed) to 9 (slowest and most compressed). This value defaults to 0 (no compression).

Click the Create button to create the new logging endpoint.

Click the Activate button to deploy your configuration changes.