Separate origins and different auth methods

With this use case, we'll set up two separate property hostname to edge hostname associations ("property hostnames") to field requests to separate origins. We'll streamline delivery from each by using unique Origin Characteristics.

Overview

We'll be fielding requests to two property hostnames to deliver a full software installable and its associated patches. The Both are hosted on two separate origin servers. It assumes that these requests are originating from one of two URLs:

  • https://system-software-install.com. A user targets this URL to request the full installable of the software.
  • http://system-software-patches.com. A user targets this URL to request the PC version of the patch.

The full software installable is hosted on a Amazon AWS origin and requires secure, Standard TLS authentication. The patches are hosted on NetStorage and will be accessible via HTTP requests.

Phase 1: Create the property hostnames

We need a new DD property with two property hostnames. We want to employ Standard TLS security (HTTPS) access for the installable, and standard HTTP access for the patches.



The steps that follow outline what you need to do to create the property hostnames for this use case.

  1. You need a Standard TLS certificate set up for the system-software-install.com hostname. This can take awhile to provision, so you should create it before you create the DD property. You need to include the hostname as a certificate name (CN) or subject alternate name (SAN) in the certificate.
  2. Create a new DD property in Control Center.
  3. Set up a Standard TLS Property Hostname to Edge hostname association for "system-software-install.com."
    Note: If you have use case-based edge mapping enabled on your account, set the Download Mode to "FOREGROUND" (or leave it blank, if you don't see this option). This adds the appropriate use case-based edge mapping profile for this hostname, in this use case. It's important to note that what you set here takes precedence over what you set for the "Optimize for Foreground Download" option in the Content Characteristics behavior for requests from this hostname.
  4. Set up a custom HTTP property hostname to edge hostname association for "system-software-patches.com.

Phase 2: Add a new rule for the software patch requests

For download requests to http://system-software-patches, we want to ensure that patch software is served from the proper origin and optimized for delivery. So, we incorporate a separate rule to target requests for that URL, and to use specific Origin Characteristics and Content Characteristics behavior settings.

  1. In the Property Configuration Settings click Add Rule.
  2. Ensure Blank Rule Template is selected (default) and click Insert Rule.
  3. Click the gear icon in the New Rule and select Edit Name. Input a desired name (for example, "Patches on NetStorage") and press Enter.
  4. Click Add Match and set the fields as follows:
    • Hostname
    • is one of
    • Select Items. Click this field and input the property hostname for the lo-res images—"system-software-patches.com."
  5. Click Add Behavior.
  6. Type "origin" in the Search available behaviors field to filter results, select Origin Server, and click Insert Behavior. Set the options in this behavior as follows:
    • Origin Type: NetStorage
    • NetStorage Account: Click to select the NetStorage account associated with the storage group that houses the Linux patch software.
  7. Repeat steps 5-6, to add the Origin Characteristics and Content Characteristics behaviors.
    Behavior Options
    Origin Characteristics Set these options to optimize delivery of the patches that are stored in from NetStorage.
    • Origin Location. Set this to the geographic location that represents the NetStorage Account you set in the Origin Server behavior.
    • Authentication Method. Akamai Origins - Auto, Others - None
    Content Characteristics We know that the following apply for the Linuc patch content, so we set these options, accordingly:
    • Origin Object Size. Each patch is roughly 20-50 MB in size, so set this to "10-100MB."
      Note: Anything greater than 10 MB in size constitutes a "large file," so Akamai's Partial Object Caching feature is automatically applied when you select this size object. This is beneficial if all files are 10 MB in size or greater, but it can have a negative impact if your file sizes are below this value. See Do you need partial object caching? for more details.
    • Popularity Distribution: We're not sure of the popularity, so we set this to "Unknown."
    • Catalog Size. This is the overall size of the patch catalog. Multiple patches will be stored here, but the entire catalog is less than 1TB in size, so set this to "Medium."
    • Content Type. Set this to "Software Patch."
    Tip: Full details on these options, including recommendations on usage can be found in the Content Characteristics topic.
    Optimize for Foreground Download Set this slider to Yes. It optimizes the delivery throughput and download times for the "large files" for this use case.
    Note: If you've applied use case-based edge mapping with the associated property hostname, and set it to "BACKGROUND" (rather than "FOREGROUND" that was recommended), that setting overrides a "Yes" setting here. Requests to that hostname will not be optimized for foreground downloads.

Phase 3: Configure the Default Rule for hi-res image requests

In this use case, the majority of the requests will be coming for the actual software installable. So, we'll configure the Default Rule to handle these requests. We need to set the Origin Server as "Your Origin" to incorporate Amazon AWS as the origin, and apply Origin Characteristics optimization for it.

Access the Default Rule and set the use case-based behaviors.

Behavior Options
Origin Server For this scenario, we set this to "Your Origin."

Configure settings here for a Google Cloud Platform origin. This is covered in detail in the I selected "Your Origin" topic in the Property Manager help.

Origin Characteristics Set the these options:
  • Origin Location. Set this to the geographic location that best matches the location of "Your Origin."
  • Authentication Method. Akamai For this use case, we'd select "Amazon AWS Signature Version 4."
Tip: Full details on these options, including recommendations on usage can be found in the Origin Characteristics topic.
Content Characteristics We know that the following apply for the software installable, so we set these options, accordingly:
  • Origin Object Size. The installable is roughly 2 GB in size, so set this to "Greater than 100MB."
    Note: Anything greater than 10 MB in size constitutes a "large file," so Akamai's Partial Object Caching feature is automatically applied when you select this size object. This is beneficial if the installable file size will always be greater than 10 MB in size, but it can have a negative impact if it ever drops below this value. See Do you need partial object caching? for more details.
  • Popularity Distribution. This is the most popular content, but it doesn't specifically fall into either of the two use cases. So, set this to "Other."
  • Catalog Size. This is the overall size of the software installable catalog. For this example, there's only a single object and it's 2 GB in size. So, set this to "Medium."
  • Content Type. Set this to "Software."
  • Optimize for Foreground Download. Set this slider to Yes. It will optimizes the delivery throughput and download times for the "large files" for this use case.
    Note: If you've applied use case-based edge mapping with the associated property hostname, and set it to "BACKGROUND" (rather than "FOREGROUND" that was recommended), that setting overrides a "Yes" setting here. Requests to that hostname will not be optimized for foreground downloads.
Tip: Full details on these options, including recommendations on usage can be found in the Content Characteristics topic.
Client Characteristics For this use case, all requesting clients are in the Europe. So, set the Client Location option to "Europe."

Note that we didn't set up this behavior in the "Patches on NetStorage" rule. This is because all requests--for both the software installable and the patches--will originate in Europe. So, we set it here in the Default Rule so it applies to all requests.

What happens next?

First, you need to complete creation of the DD property, optionally test it, and finally promote it to production for use.

Once live in production, request logic for your content works as follows:

  • A request to "http://system-software-patches.com". Since this matches the "system-software-patches.com" property hostname set in the "Patches on NetStorage" rule, its Origin Server is used, and its versions of the Origin Characteristics and Content Characteristics behaviors are applied. However, the Default Rule applies to all requests. So, all of its additional behaviors are also applied—use case-based behaviors or not.
  • A request to "https://system-software-install.com". The "Patches on NetStorage" rule is checked first, but this request doesn't match its criteria. So, the request references the Default Rule, and its Origin Server is used, as well as what's been set in its instances of the Origin Characteristics and Content Characteristics behaviors.