Adaptive Media Delivery (AMD) failover lets you switch from one origin to another, or send a specific HTTP status code to the requesting client if a failure occurs on your primary origin.

How it's implemented: the basics

You configure various recovery methods in a unique rule in your AMD property via Property Manager. Recovery methods consist of failing over to a backup origin or delivery of a specific response code to the requesting client. You also set up a policy of failure scenarios that trigger these recovery methods:

You can set a timeout. If a request to your primary origin exceeds a set amount of time, the request can be retried or you can use a recovery method (or both). This applies to connect and first-byte timeouts. Transaction timeouts don't apply.
You can specify HTTP status codes. If a request to your primary origin results in one of these status codes, the request can be retried or you can use a recovery method (or both).

In addition, you can apply settings to exclude a failed primary origin for a specific amount of time. After that time elapses, requests are routed back to the primary origin.

Before you begin with AMD Failover

There are some prerequisites and points to consider before implementing AMD failover.

How do I get AMD failover?

AMD failover is available to all AMD customers. AMD failover is built on top of Akamai's Mixed Mode Configuration functionality, which is also available to all AMD customers. For more details on it, see Use Mixed Mode with AMD.

Supported origin formats

The whole premise behind AMD failover is that it lets you failover from your primary origin to a backup in the event of a failure. The following origin formats are supported for use as a failover origin:

Custom ("Your Origin")
NetStorage
Media Services Live

Synchronize your content - IMPORTANT

To properly failover from one origin to another in the middle of a playback session, the content needs to be synchronized across your primary and backup origins.

Synchronized in this context means that segments can originate from either origin and not cause any decoding issues at the player. Otherwise, if Akamai switches from content "A" on the primary origin to content "B" on the backup, the player's decoder may have problems with the switch, and playback errors may occur.

In a live context with multiple encoders, these encoders must be synchronized using whatever method is required by the vendor. On-demand media cases are usually simpler because the content can be encoded once and pushed to multiple origins thus creating absolutely identical copies of the content.

For failover to work seamlessly, the content (segments) on primary and backup origins need to be binary-identical or time-aligned. This can be achieved in a number of ways:

You can use a single encoder to post the same segments to the two origins.
You can use a single encoder to post the segments to the primary origin. Then, you can archive these segments from the primary to the backup origin.
Ensure that the two encoders (and ingest servers) are time-aligned. They must use the same UTC time and you need to have them insert the same timestamp into the chunks.