Getting started
Basics
Domains & Origins
Performance

Configuration
Basics
Conditions
Dictionaries
Domains & Origins
Request settings
Cache settings
Headers
Responses
Performance
Purging
Custom VCL
Image optimization
Video

Security
Access Control Lists
Monitoring and testing
Securing communications
Security measures
TLS
Web Application Firewall

Integrations
Logging endpoints
Non-Fastly services

Diagnostics
Streaming logs
Debugging techniques
Common errors

Account info
Account management
Billing
User access and control

Reference

    Google Cloud Storage

      Last updated November 11, 2019

    Google Cloud Storage (GCS) can be used as an origin server with your Fastly services once you set up and configure your GCS account and link it to a Fastly service. It can also be configured to use private content. This speeds up your content delivery and reduces your origin's workload and response times with the dedicated links between Google and Fastly's POPs.

    Using GCS as an origin server

    To make your GCS data available through Fastly, follow the steps below.

    Setting up and configuring your GCS account

    1. Sign up for Google Cloud Storage.
    2. Create a bucket to store your origin's data. The Create a bucket window appears.

      Google Cloud Storage New Bucket window

    3. Use Google's Search Console to verify ownership of your domain name, if you have not already done so. See the instructions on Google's website.
    4. Fill out the Create a bucket fields as follows:
      • In the Name field, type your domain name (e.g., example.com or images.example.com) to create a domain-named bucket. Remember the name you type. You'll need it to connect your GCS bucket to your Fastly service.
      • In the Default storage class area, select Regional.
      • From the Regional location menu, select a location to store your content. Most customers select a region close to the interconnect location they specify for shielding.
    5. Click the Create button.

    You should now add files to your bucket and make them externally accessible by selecting the Public link checkbox next to each of the files.

    Adding your GCS bucket as an origin server

    To add your GCS bucket as an origin server, follow the instructions for connecting to origins. You'll add specific details about your origin server.

    1. In the Hosts field on the Origins page, enter the appropriate address for your host using the format <BUCKET>.storage.googleapis.com. For example, if your bucket name is test123, your override hostname would be test123.storage.googleapis.com.

    For the initial Edit this host fields:

    Interconnect locations

    Interconnect locations allow you to establish direct links with Google's network edge when you choose your shielding location. By selecting one of the locations listed below, you will be eligible to receive discounted pricing from Google CDN Interconnect for traffic traveling from Google Cloud Platform to Fastly's network. Most customers select the interconnect closest to their GCS bucket's region.

    Interconnects exist in the following locations within North America:

    Interconnects outside of North America exist in:

    Review our caveats of shielding and select an interconnect accordingly.

    Setting the Cache-Control header for your GCS bucket

    GCS performs its own caching, which may complicate efforts to purge cache. To avoid potential problems, we recommend using the gsutil command line utility to set the Cache-Control header for one or more files in your GCS bucket:

    1
    
    gsutil setmeta -h "Cache-Control: max-age=0, s-maxage=86400" gs://<bucket>/*.html
    

    Replace <bucket> in the example above with your GCS bucket's name. Note that max-age should instruct GCS to cache your content for zero seconds, and Fastly to cache your content for one day. See Google's setmeta docs for more information.

    Changing the default TTL for your GCS bucket

    If you want to change the default TTL for your GCS bucket, if at all, keep the following in mind:

    Using GCS with private objects

    To use Fastly with GCS private objects, be sure you've already made your GCS data available to Fastly by pointing to the right GCS bucket, then follow the steps below.

    Setting up interoperable access

    By default, GCS authenticates requests using OAuth2, which Fastly does not support. To access private objects on GCS, your project must have HMAC authentication enabled and interoperable storage access keys (an "Access Key" and "Secret" pair) created. Do this by following the steps below.

    1. Open the Google Cloud Platform console and select the appropriate project.
    2. Click Settings. The Settings appear with the Project Access controls highlighted.
    3. Click the Interoperability tab. The Interoperability API access controls appear.
    4. If you have not set up interoperability before, click Enable interoperability access.
    5. Click Make <PROJECT-ID> your default project for interoperable access. If that project already serves as the default project, that information appears instead.

      the interoperability tab

    6. Click Create a new key. An access key and secret code appear.

      the google cloud storage access key

    7. Save the access key and secret code that appear. You'll need these later when you're creating an authorization header.

    Setting up Fastly to use GCS private content

    To use GCS private content with Fastly, create two headers, a Date header (required Authorization Signature) and an Authorization header.

    Creating a Date header

    1. Log in to the Fastly web interface and click the Configure link.
    2. From the service menu, select the appropriate service.
    3. Click the Edit configuration button and then select Clone active. The Domains page appears.
    4. Click the Content link. The Content page appears.
    5. Click the Create header button. The Create a new header page appears.

      creating a date header via the new header page

    6. Fill out the Create a new 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.
    7. 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.

    Creating an Authorization header

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

      creating an authorization header via the header page

    2. Fill out the Create a header fields as follows:
      • In the Name field, type 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.
    3. In the Source field, type the header authorization information using the following format:

      1
      
        "AWS <access key>:" digest.hmac_sha1_base64("<GCS secret>", if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/<GCS bucket name>" req.url.path)
      

      replacing <access key>, <GCS secret>, and <GCS bucket name> with the information you gathered before you began. For example:

      1
      
        "AWS GOOGQORE5WOJJHLXH6OD:" digest.hmac_sha1_base64("oQb0hdmaxFOc5UmC6F833Cde0+ghRSgsr7CCnX62", if(req.method == "HEAD", "GET", req.method) LF LF LF req.http.Date LF "/test123" req.url.path)
      
    4. Click the Create button. A new Authorization header appears on the Content page.
    5. 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:

    AWS<access key><signature function><key><message>

    It tells us the following:

    Element Description
    AWS A constant placed before the access key. It's always AWS.
    access key The access key ID from your GCS developer's account. We used GOOGQORE5WOJJHLXH6OD in this example.
    signature function The algorithm used to validate the key and message of the signature. We used digest.hmac_sha1_base64(<key>, <message>) in this example.
    key The secret key ID from your GCS developer's account. We used oQb0hdmaxFOc5UmC6F833Cde0+ghRSgsr7CCnX62 in this example.
    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><CanonicalExtensionHeaders><\n><CanonicalizedResource>

    It tells us the following:

    Element Description
    HTTP-verb The REST verb. We use req.method in this example.
    \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).
    CanonicalExtensionHeaders The x-amz- or x-goog- headers, which customize your GCS implementation. It's often left blank. We use LF in this example.
    CanonicalizedResource Your GCS resource path name. We're concatenating GCS bucket name "/test123" with object path req.url.path in this example.
    This article describes an integration with a service provided by a third party. Please see our note on integrations.
    Back to Top