Separate origins and different auth methods
With this scenario, 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. Each is hosted on a separate origin server. 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.https://system-software-patches.com
. A user targets this URL to request the PC version of the patch.
The full software installable is hosted on an Amazon AWS origin and requires secure, Standard TLS authentication. The patches are hosted on NetStorage and will be accessible via another Standard TLS authenticated edge hostname.
Phase 1: Create the property hostnames
We need a new Download Delivery property with two property hostnames. We want to employ Standard TLS security (HTTPS) access for both.
The steps that follow outline what you need to do to create the property hostnames for this scenario.
-
You need Standard TLS certificates set up for both domains. You can create two separate certificates or a single one for both. This can take a while to provision, so you should create the certs before you create the Download Delivery property. You need to include the domains as a certificate name (CN) or subject alternate name (SAN) in the certificate.
-
Create a new Download Delivery property in âAkamai Control Centerâ.
-
Set up a Standard TLS Property Hostname to Edge hostname association for
system-software-install.com
.
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 scenario. 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.
- Set up a second Standard TLS 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 https://system-software-patches
, we want to ensure that the 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.
-
In the Property Configuration Settings click Add Rule.
-
Ensure Blank Rule Template is selected (default) and click Insert Rule.
-
Click the gear icon in the New Rule and select Edit Name. Input the desired name. Set this to "Patches on NetStorage" for this scenario and press Enter.
-
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 software patches:
system-software-patches.com
.
Add behaviors to this rule
Add these behaviors to the new rule and configure them accordingly.
Add the Origin Server behavior
First we'll add this behavior to configure the origin server that's hosting the software patch.
-
Click Add Behavior.
-
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.
-
Add the Origin Characteristics behavior
Next, add this behavior to optimize delivery from your origin, based on its configuration.
-
Click Add Behavior.
-
Type origin in the Search available behaviors field to filter results, select Origin Characteristics, and click Insert Behavior. Set the options in this behavior as follows:
-
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
-
Add the HTTP/2 behavior
Now, we'll add this behavior to reduce latency and resource consumption when loading web properties for secure delivery via HTTPS.
-
Click Add Behavior.
-
Type http in the Search available behaviors field to filter results, select HTTP/2, and click Insert Behavior.
There are no options you need to set. Once the behavior is added, you're good to go.
Add the Content Characteristics behavior
Finally, we'll add this behavior to optimize delivery based on the type of content we're delivering.
-
Click Add Behavior.
-
Type content in the Search available behaviors field to filter results, select Content Characteristics, and click Insert Behavior. Set the options in this behavior as follows:
-
Origin Object Size. Each patch is roughly 20-50 MB in size, so set this to 10-100MB. This is what âAkamaiâ considers a "large file," so partial object caching is automatically applied to optimize delivery.
-
Popularity Distribution. We're not sure of the popularity, so 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.
-
Optimize for Foreground Download. Set this slider to Yes. It optimizes the delivery throughput and download times for the "large files" for this scenario.
-
Are you using Use Case-based Edge Mapping?
If you've applied use case-based edge mapping with the property hostname that's fielding requests for this rule, and set it to "BACKGROUND" (rather than "FOREGROUND" that's recommended here), that setting overrides a Yes setting here. Requests to that hostname will not be optimized for foreground downloads. You'll need to edit your hostname to set this to "FOREGROUND" if you want to follow this scenario.
Add the Client Characteristics behavior
Finally, you can optionally add this behavior to optimize delivery to specific clients.
-
Click Add Behavior.
-
Type client in the Search available behaviors field to filter results, select Client Characteristics, and click Insert Behavior. Set the options in this behavior as follows:
- Client Location. Set this to the geographic region that best represents the clients that will be accessing the software patch.
You'd only include this behavior if you want to use a different setting than what you've applied for the Client Characteristics behavior that's required in the Default Rule. The Default Rule applies to all requests, so you don't have to include this behavior if you're happy with what's set there.
Phase 3: Configure the Default Rule for the full installable
In this scenario, 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 then apply settings in other use case-based behaviors to optimize delivery from this origin.
Configure the Origin Server behavior
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.
Configure the Origin Characteristics behavior
Set these options as follows:
-
Origin Location. Set this to the geographic location that best matches the location of "Your Origin."
-
Authentication Method. For this scenario, we'd select Amazon AWS Signature Version 4.
You can find details on the remaining options for this behavior in Origin Characteristics and DD
Configure the Content Characteristics behavior
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. Since this is also a "large file," partial object caching is automatically applied to optimize delivery.
-
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. We'd set this to Software.
-
Optimize for Foreground Download. Set this slider to Yes. It will optimize the delivery throughput and download times for the "large files" for this scenario.
Are you using Use Case-based Edge Mapping?
If you've applied use case-based edge mapping in a property hostname who's requests are managed by the Default Rule, and set it to "BACKGROUND" (rather than "FOREGROUND" that's recommended here), that setting overrides a Yes setting here. Requests to that hostname will not be optimized for foreground downloads. You'll need to edit any hostname that uses the Default Rule's Content Characteristics behavior, and set this to "FOREGROUND" if you want to follow this scenario.
Updated over 2 years ago