Origin Characteristics

This behavior lets you specify details pertaining to the Origin Server, in order to apply related optimizations to your AMD property.



Origin Location

Select the appropriate location of the origin server, based on its Origin Type:

  • NetStorage. Leave as Unknown.
  • Your Own Origin: You can select the geographical location of your origin server to optimize access to it. (Do this to implement what we consider "Use Case-based" provisioning for this behavior.) If you are not sure about your server location, you can leave it as “Unknown.”
Important: If NetStorage is your selected Origin Server, Origin Location must be set to Unknown.

Authentication Method

Use this drop-down to select the appropriate authentication method for use:

  • Akamai Origins - Auto, Others - None: This is the default and applies to you if your Origin Server doesn't have any external authentication requirements, or if you're using NetStorage as your origin.
  • Akamai Signature Authentication: Select this if your AMD property has been set up to use our shared certificate hostname for secure (HTTPS) delivery to your custom origin.
  • Akamai Media Services Live: Select this if you're using this AMD property in association with the Media Services Live product to deliver live streaming media. This is covered in the Live Streaming with MSL 4.x and AMD - Getting Started Guide.
  • Google Cloud Platform: Select this if you are authenticating with this third-party cloud provider as your origin. Once selected, the following options are revealed:
    • Google Access Key ID: This is required. Input the ID of the access key used to compute the signature.
    • Google Secret Access Key: This is required. Input the secret key used to compute the signature.
    • Google Bucket Name: If applicable, input the bucket name for your Google Cloud Platform service. You must input the appropriate value if the bucket name is not included in the Forward Host Header. (This header is specified in the Origin Server Behavior.) If you've included the bucket name in this header, naming it here is optional.
  • Amazon AWS Signature Version 4: Select this if you are authenticating with this third-party cloud provider as your origin. Once selected, the following options are revealed:
    • AWS Access Key ID: This is required. Input the ID of the access key used to compute the signature.
    • AWS Secret Access Key: This is required. Input the secret key used to compute the signature.
    • AWS Region: This is required. Input the AWS v4-specific region that houses your AWS service.
    • AWS Hostname: This is required. Enter your unique AWS hostname. Do not include http:// or https://.
    • AWS Endpoint Service: If applicable, input your AWS endpoint service. This is the segment of the AWS hostname that precedes amazon.com.
Important: These points apply if you are authenticating via a third-party cloud provider (either Google or AWS v4):
  • Google and AWS v4: You should only use a property "akamaized" hostname with third-party cloud authentication to either retrieve objects from the origin, or for read-only bucket operations. This is because we are currently limited to storing cloud provider Access Keys in clear text. This does not carry the level of protection you might expect for the transmission of personally identifiable information (PII).
  • Google and AWS v4: We recommend that you use two separate sets of cloud provider Access Keys, with one dedicated to GET operations and another intended for POST, PUT or DELETE operations. For all GET operations, set them up to use a property via Property Manager; for POST, PUT and DELETE operations, you should use the APIs/SDKs offered by the associated cloud provider.
  • Google and AWS v4: You should regularly rotate the cloud provider Access Keys. This reduces the likelihood of unauthorized diversion of confidential information.
  • AWS v4, only: Currently, only the "Authorization" header is supported. If you're using query string parameters with this authentication, each query parameter in the incoming Client request must be sorted alphabetically, and URL encoded.

Best Practices settings applied by default

We automatically apply various "Best Practices" settings to coincide with Origin Characteristics in your AMD property. (You don't need to manually define these via individual behaviors, because we preset them for optimal access and delivery.)

Feature Setting applied
Origin Offload
  • 1-Tier Tiered Distribution is applied 1: This allows AMD to retrieve your cached content from another mid tier of servers that are closer to your origin server, rather than directly from your origin server. For cached content, the feature has significant advantages:
    • Reduction in demand for bandwidth at the Origin Server, which is often positive in itself and necessary to upscale applications.
    • Improved performance from the reduced time it takes for the product to retrieve content. (Tiered Distribution parent servers are generally located close to the product servers that use them.)
  • Hostname-based content sharding is incorporated in the Tiered Distribution layer.
  • Multiple requests for the same object are queued to a single primary request. If an error response is delivered to the primary request, it is delivered to all queued requests.
Origin Failure
  • Origin Unresponsiveness: The following are automatically set as best practices values for this scenario:
    • Connection Timeout: Five (5) seconds
    • HTTP Response Timeout: Two (2) minutes
    • Retry logic: Retry once, and serve an error to the requesting client after retry failure.
  • Origin Server Error: The following are automatically set as best practices values for this scenario:
    • Retry logic: Retry once, and serve an error to the requesting client after retry failure.
  • Object Content Error: An error is served to the requesting client.
Origin Authentication
  • NetStorage as your origin: Akamai Signature Header Verification Authentication is applied by default.
  • All other origin types: Origin Authentication is not default applied.

Tiered Distribution is preset as a “Best Practice”

This allows AMD to retrieve your cached content from another mid tier of servers that are closer to your origin server, rather than directly from your origin server. For cached content, the feature has significant advantages:

  • Reduction in demand for bandwidth at the Origin Server, which is often positive in itself and necessary to upscale applications.
  • Improved performance from the reduced time it takes for the product to retrieve content. (Tiered Distribution parent servers are generally located close to the product servers that use them.)
Note: This is enabled automatically as a “Best Practice” (and optimized by the Origin Characteristics Mandatory Behavior—a warning message is revealed by default here). If you need to disable Tiered Distribution, you can add Tiered Distribution as an Optional Behavior and set Enable to Off.

Origin Characteristics and Mixed Mode Configuration

This is a "use case-based" behavior that's automatically included in the Default Rule and used to optimize delivery. You need to apply settings for this behavior in the Default Rule. However, with Mixed mode Configuration for AMD (MMC), you can also include it in another rule and apply different match criteria to have separate requests use different origin characteristics optimizations. For more details, see Mixed Mode Configuration for AMD.

1 If you need to disable Tiered Distribution, you can add Tiered Distribution as an Optional Behavior and set Enable to Off. This will override the automatic best practices application.