Origin Characteristics and AMD

This behavior lets you set characteristics for your origin server to optimize access to it.



Origin Location

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

  • NetStorage. Set this to Unknown.
  • Your Own Origin. 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're not sure about your server location, select Unknown.

Authentication Method

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.
  • Interoperability Google Cloud Platform. Select this if you're authenticating with Google Cloud Storage (GCS) as your origin. Support is based on the GCS V4 signing process. Once selected, you can set these options:
    • Access ID. Enter the identifier of the access key used to authenticate requests to your GCS instance.
    • Secret. Enter the secret key value that is used to compute the signature.
  • Amazon Web Services. Select this if you're authenticating with Amazon Web Services (AWS) cloud provider as your origin. Support is based on the AWS signature version 4 signing process. Once selected, you can set these options:
    • Access Key ID. Enter the identifier of the access key used to authenticate requests to your AWS service.
    • Secret Access Key. Enter the secret key value that is used to compute the signature.
    • Region. Enter the AWS-specific region that houses your AWS instance.
    • Endpoint Service. Enter the code of your AWS service. This is the segment or part of the segment that precedes amazonaws.com or the region code in the AWS hostname. For example, s3 is the endpoint service for both https://<account-id>.s3-control.eu-north-1.amazonaws.com and https://s3.us-east-2.amazonaws.com hostnames. See Service endpoints and quotas in AWS.

Additional considerations for standard cloud provider-based origins

Pay attention to these points when using GCS or AWS:

  • You can check your authentication details in the file you saved when creating your access key. If you didn’t download the file, or if you lost it, you may need to delete the existing access key and add a new one. See Managing HMAC keys in GCS or Managing Access Keys (console) in AWS.
  • You may be eligible to streamline client authentication by using Cloud Access Manager. This service is currently in Beta. See Client access keys for cloud provider-based origins (below) for details.
  • Use a property with an akamaized hostname. This lets you either retrieve objects from the origin, or for read-only bucket operations. This is because we're currently limited to storing cloud provider access keys in clear text. This doesn't carry the level of protection you might expect for the transmission of personally identifiable information (PII).
  • Consider using two separate sets of cloud provider access keys. Dedicate one to GET operations and another 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 or SDKs offered by the associated cloud provider.
  • Regularly rotate the cloud provider access keys. This reduces the likelihood of unauthorized diversion of confidential information.
  • Only the "Authorization" header is supported (AWS, only). 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

Akamai automatically applies certain best practices settings when you configure various behaviors in the Default Rule. With the Origin Characteristics behavior, the following settings are automatically applied—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 lets AMD retrieve your cached content from another tier of Akamai edge servers that are closer to your origin server, rather than directly from your origin server. For cached content, the feature has significant advantages:
    • The demand for bandwidth at the Origin Server is reduced. This is often positive in itself and necessary to upscale applications.
    • The time it takes for the product to retrieve content is reduced. The 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 seconds
    • HTTP Response Timeout. Two 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. Use the Authentication Method options to apply these for your origin.

Client access keys for cloud provider-based origins Beta

If you're using a third party cloud provider for your origin—Interoperability Google Cloud Platform or Amazon Web Services—consider using Cloud Access Manager to streamline client authentication.

In a typical transaction, you need to include a signature in the request so that your cloud provider recognizes the client. The signature contains an access key supplied by your cloud provider. That key consists of a unique access identifier and a secret access key. You include both of these values when setting up your AMD property in Akamai Control Center. When receiving the request, a cloud provider calculates the signature and compares it to the one sent in the client request. If they match, the request is considered authentic. If they don’t match, the request is denied. While this standard method works, it has some drawbacks:
  • You need to set up the mechanism to inject the signature into a client request.
  • This requires that you proxy through your origin, which can delay the request.
  • The access identifier and secret access key are openly visible to anyone that can see your AMD property in Control Center.

Cloud Access Manager lets you privately create your access keys and protects them. You add them to your AMD property using a name you define, and the access identifier and secret key are hidden. Cloud Access Manager uses the Akamai Intelligent Platform to route origin requests directly to your cloud provider. Akamai edge servers inject access key authentication on the forward origin path for you. This can decrease cost, bandwidth requirements, and the number of hits to your origin during peak times.

Contact your account manager to see if you're eligible to participate in the beta program for this service.

How do I use Cloud Access Manager?

  1. Start by getting authentication details from your cloud provider.
  2. Use Cloud Access Manager to create an access key.
  3. Configure settings here in the Origin Characteristics behavior to sign requests with your access key:
    • Origin Location. Select the geographical location of your origin server to optimize access to it. If you aren't sure about your server location, you can leave it as Unknown.
    • Authentication Method. Select the third-party cloud provider that you use as your origin, either Amazon Web Services or Interoperability Google Cloud Storage.
    • Encrypted Storage. Set to Yes. This lets you refer to access keys you created that are securely stored in Cloud Access Manager. If you disable this option, the Origin Characteristics behavior stores the authentication details unencrypted.
    • Access Key. Select the access key that you want to use to sign requests to a cloud origin. This field lists only active access keys that you created in Cloud Access Manager, that match your property's authentication method selected in the Origin Characteristics behavior.
    • Region (Amazon Web Services, only). Enter the code of the AWS region that houses your AWS service.
    • Service Endpoint (Amazon Web Services, only). Enter the code of your AWS service. This is the segment or its part that precedes amazonaws.com or a region code in your the AWS service endpoint. For example, s3 is the service code for this service endpoint: https:// account-id.s3-control.eu-north-1.amazonaws.com. See AWS Service Endpoints and Service Endpoints and Quotas.

Best practices for Cloud Access Manager

Consider these points when authenticating via a third-party cloud provider.

  • 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.
  • 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.
  • You should regularly rotate the cloud provider Access Keys. This reduces the likelihood of unauthorized diversion of confidential information.
  • 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.

Need more information?

For complete details on Cloud Access Manager, see the Cloud Access Manager User Guide.

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 How to use Mixed Mode with 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.