# What is AWS Elemental MediaTailor?
<a name="what-is"></a>

AWS Elemental MediaTailor is a scalable ad insertion and channel assembly service that runs in the AWS Cloud. With MediaTailor, you can serve targeted ad content to viewers and create linear streams while maintaining broadcast quality in over-the-top (OTT) video applications. MediaTailor ad insertion supports Apple HTTP Live Streaming (HLS) and MPEG Dynamic Adaptive Streaming over HTTP (DASH) for video on demand (VOD) and live workflows.

AWS Elemental MediaTailor ad insertion offers important advances over traditional ad-tracking systems: ads are better monetized, more consistent in video quality and resolution, and easier to manage across multi-platform environments. MediaTailor simplifies your ad workflow by allowing all IP-connected devices to render ads in the same way as they render other content. The service also offers advanced tracking of ad views, which further increases the monetization of content.

AWS Elemental MediaTailor channel assembly is a manifest-only service that allows you to create linear streaming channels using your existing video on demand (VOD) content. MediaTailor never touches your content segments, which are served directly from your origin server. Instead, MediaTailor fetches the manifests from your origin, and uses them to assemble a live sliding manifest window that references the underlying content segments.

 MediaTailor channel assembly makes it easy to monetize your channel by inserting ad breaks into your stream without having to condition it with SCTE-35 markers. You can use channel assembly with MediaTailor ad insertion, or another server-side ad insertion service. 

## Origin server requirements
<a name="what-is-origin-requirements"></a>

AWS Elemental MediaTailor has specific requirements for origin server communication:
+ **Supported ports** - MediaTailor only accepts origins using standard HTTP and HTTPS ports:
  + Port 80 for HTTP connections
  + Port 443 for HTTPS connections

  MediaTailor does not support custom ports for origin server communication.
+ **Protocol requirements** - For secure communication, MediaTailor requires HTTPS for certain origin types and authentication scenarios. For more information, see [Integrating a content source for MediaTailor ad insertion](integrating-origin.md).

# MediaTailor concepts
<a name="what-is-terms"></a>

 Here's an overview of the concepts that are used throughout the *AWS Elemental MediaTailor User Guide*.

# HLS playlist types
<a name="hls-playlist-types"></a>

HTTP Live Streaming (HLS) uses two primary types of playlists: multivariant playlists and media playlists. Understanding the difference between these playlist types is essential for configuring and troubleshooting MediaTailor workflows.

Multivariant playlist  
A multivariant playlist is the top-level index file in an HLS streaming workflow that lists all available renditions of the content. It contains references to media playlists but does not contain any media segments itself. The multivariant playlist allows players to select the most appropriate rendition based on network conditions, device capabilities, or user preferences.  
This playlist type is also known by several other names in various contexts:  
+ Master playlist (deprecated term)
+ Master manifest (common industry term)
+ Primary playlist
+ Main playlist
+ Index file
+ Master M3U8
In MediaTailor workflows, the multivariant playlist is the entry point for playback requests and is where ad personalization begins.  

**Example Multivariant playlist example**  

```
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=2665726,AVERAGE-BANDWIDTH=2526299,RESOLUTION=960x540,CODECS="avc1.640029,mp4a.40.2",SUBTITLES="subtitles"
index_1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4786126,AVERAGE-BANDWIDTH=4547599,RESOLUTION=1280x720,CODECS="avc1.640029,mp4a.40.2",SUBTITLES="subtitles"
index_2.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=8171787,AVERAGE-BANDWIDTH=7768157,RESOLUTION=1920x1080,CODECS="avc1.640029,mp4a.40.2",SUBTITLES="subtitles"
index_3.m3u8
```

Media playlist  
A media playlist contains the actual media segment information for a specific rendition (quality level) of the content. It includes timing information, segment URLs, and other metadata required for playback of a single rendition. Each media playlist represents a different combination of resolution, bitrate, and other characteristics.  
This playlist type is also known by several other names:  
+ Variant playlist
+ Child manifest (common industry term)
+ Chunklist
+ Media M3U8
+ Rendition playlist
In MediaTailor workflows, media playlists are personalized to include both content segments and ad segments in the proper sequence.  

**Example Media playlist example**  

```
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:123456
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXTINF:6.0,
segment123456.ts
#EXTINF:6.0,
segment123457.ts
#EXT-X-DISCONTINUITY
#EXTINF:5.0,
ad-segment1.ts
#EXTINF:5.0,
ad-segment2.ts
#EXT-X-DISCONTINUITY
#EXTINF:6.0,
segment123458.ts
```

**Note**  
Both multivariant and media playlists are text-based files that use the `.m3u8` extension. The terminology for these files varies across different documentation and contexts, but the fundamental roles remain the same in the HLS streaming architecture.

When configuring MediaTailor, you typically provide the URL to the multivariant playlist in your content origin. MediaTailor then handles the personalization of both the multivariant playlist and the media playlists to insert ads according to your configuration.

For more information about HLS playlist specifications, see the [HTTP Live Streaming RFC](https://datatracker.ietf.org/doc/html/rfc8216).

# DASH manifest types
<a name="dash-manifest-types"></a>

Dynamic Adaptive Streaming over HTTP (DASH) uses a Media Presentation Description (MPD) manifest to deliver streaming content. Understanding the structure and components of DASH manifests is essential for configuring and troubleshooting MediaTailor workflows.

MPD (Media Presentation Description)  
The MPD is the primary manifest file in DASH streaming that describes the structure and availability of media content. It contains information about periods, adaptation sets, representations, and segments that make up the streaming content.  
This manifest type is also known by several other names in various contexts:  
+ DASH manifest
+ DASH MPD
+ Master manifest (when comparing to HLS)
+ Presentation manifest
In MediaTailor workflows, the MPD is the entry point for playback requests and is where ad personalization begins.  

**Example MPD manifest example**  

```
<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" minBufferTime="PT5.000S" maxSegmentDuration="PT2.005S" availabilityStartTime="2020-01-01T00:00:00Z" publishTime="2020-01-01T12:30:00Z" minimumUpdatePeriod="PT2.000S" timeShiftBufferDepth="PT5M">
  <Period id="1" start="PT0.000S">
    <AdaptationSet id="1" contentType="video" segmentAlignment="true" bitstreamSwitching="true" frameRate="30000/1001" maxWidth="1920" maxHeight="1080" par="16:9">
      <Representation id="1" mimeType="video/mp4" codecs="avc1.640028" width="1920" height="1080" bandwidth="5000000">
        <SegmentTemplate timescale="90000" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startNumber="1" duration="180000"/>
      </Representation>
      <Representation id="2" mimeType="video/mp4" codecs="avc1.4d401f" width="1280" height="720" bandwidth="2800000">
        <SegmentTemplate timescale="90000" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startNumber="1" duration="180000"/>
      </Representation>
      <Representation id="3" mimeType="video/mp4" codecs="avc1.4d401e" width="640" height="360" bandwidth="1100000">
        <SegmentTemplate timescale="90000" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startNumber="1" duration="180000"/>
      </Representation>
    </AdaptationSet>
    <AdaptationSet id="2" contentType="audio" segmentAlignment="true" lang="eng">
      <Representation id="4" mimeType="audio/mp4" codecs="mp4a.40.2" audioSamplingRate="48000" bandwidth="128000">
        <SegmentTemplate timescale="48000" initialization="init-stream$RepresentationID$.m4s" media="chunk-stream$RepresentationID$-$Number%05d$.m4s" startNumber="1" duration="96000"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>
```

Period  
A Period is a temporal section of a DASH presentation. Each Period contains one or more adaptation sets and represents a span of media time. In ad insertion workflows, separate Periods are typically used to delineate between content and ads.  
This component is also known by several other names:  
+ Content segment
+ Timeline section
+ Program segment
In MediaTailor workflows, Periods are used to separate main content from ad content, with each ad typically represented by its own Period.  

**Example Period example**  

```
<Period id="ad-period-1" start="PT30.000S" duration="PT15.000S">
  <AdaptationSet id="1" contentType="video" segmentAlignment="true" bitstreamSwitching="true" frameRate="30000/1001" maxWidth="1920" maxHeight="1080" par="16:9">
    <Representation id="1" mimeType="video/mp4" codecs="avc1.640028" width="1920" height="1080" bandwidth="5000000">
      <SegmentTemplate timescale="90000" initialization="ad1/init-stream$RepresentationID$.m4s" media="ad1/chunk-stream$RepresentationID$-$Number%05d$.m4s" startNumber="1" duration="180000"/>
    </Representation>
  </AdaptationSet>
</Period>
```

AdaptationSet  
An AdaptationSet groups a set of interchangeable encoded versions of one or several media content components. For example, one AdaptationSet might contain multiple video quality levels, while another might contain multiple audio language options.  
This component is also known as:  
+ Media component group
+ Stream set
+ Track group
In MediaTailor workflows, AdaptationSets are preserved during ad insertion to maintain consistent media types between content and ads.

Representation  
A Representation is a specific encoded version of the media content within an AdaptationSet. Each Representation typically differs in bitrate, resolution, or other encoding parameters, allowing clients to select the most appropriate version based on network conditions and device capabilities.  
This component is also known as:  
+ Rendition (similar to HLS)
+ Quality level
+ Bitrate variant
+ Stream variant
In MediaTailor workflows, Representations in ad Periods are matched as closely as possible to the Representations in content Periods to ensure a smooth viewing experience.

Segment  
A Segment is a unit of media data that can be referenced individually by a URL. Segments contain the actual media content (video, audio, etc.) and are referenced within the MPD. There are two main types of segments in DASH:  
+ **Initialization Segment**: Contains initialization information for a Representation, such as codec parameters and timing information.
+ **Media Segment**: Contains the actual media data for a specific time range within a Representation.
In MediaTailor workflows, segment URLs are often modified to point to the appropriate content or ad media files.

**Note**  
DASH manifests are XML-based files that typically use the `.mpd` extension. The terminology for these files and their components may vary across different documentation and contexts, but the fundamental structure remains the same in the DASH streaming architecture.

When configuring MediaTailor, you provide the URL to the MPD manifest in your content origin. MediaTailor then handles the personalization of the manifest, typically by inserting additional Periods for ads according to your configuration.

For more information about DASH manifest specifications, see the [DASH Industry Forum Implementation Guidelines](https://dashif.org/docs/DASH-IF-IOP-v4.3.pdf).

# Advanced DASH manifest concepts
<a name="dash-manifest-advanced-concepts"></a>

When working with DASH manifests in MediaTailor, understanding the following advanced concepts can help you configure and troubleshoot your streaming workflows more effectively:

Period start time calculation  
In DASH manifests, Period start times are calculated based on the MPD's `availabilityStartTime` attribute and the Period's `start` attribute. For live streams, the start time is relative to the availability start time, while for VOD content, it's typically relative to the beginning of the presentation.  
When MediaTailor inserts ad Periods, it carefully calculates the start times to ensure seamless transitions between content and ads. This calculation takes into account:  
+ The original Period's start time
+ The duration of preceding ad Periods
+ Any time offset specified in the ad decision server response

Preroll timing calculations  
Preroll ads in DASH manifests require special handling because they appear before the main content begins. MediaTailor inserts preroll ads as separate Periods at the beginning of the manifest with appropriate start times and durations.  
For preroll ads, MediaTailor:  
+ Creates a new Period for each preroll ad
+ Sets the first preroll Period's start time to 0
+ Adjusts the start time of the main content Period to account for the total duration of all preroll ads

Live-to-VOD transitions  
DASH manifests can transition from live to VOD (Video on Demand) format when a live stream ends. This transition involves changing the MPD's `type` attribute from `dynamic` to `static` and adjusting other attributes like `timeShiftBufferDepth` and `minimumUpdatePeriod`.  
When MediaTailor processes manifests during live-to-VOD transitions, it ensures that:  
+ Ad markers are preserved in the VOD manifest
+ Period start times are adjusted to maintain proper timing
+ The manifest remains compatible with VOD playback clients

DRM handling  
Digital Rights Management (DRM) information in DASH manifests is typically included in the `ContentProtection` elements within AdaptationSets or Representations. MediaTailor preserves these elements during ad insertion to ensure that content protection remains intact.  
When processing DRM-protected content, MediaTailor:  
+ Maintains all ContentProtection elements from the original manifest
+ Ensures that ad content uses compatible DRM schemes if applicable
+ Preserves any DRM-related attributes and elements throughout the manifest

SCC flags  
Supplemental Content Control (SCC) flags in DASH manifests provide additional information about content characteristics and playback requirements. These flags are typically included as attributes or elements within the MPD structure.  
Common SCC flags that MediaTailor processes include:  
+ Content rating information
+ Accessibility features (closed captions, audio descriptions)
+ Content advisory notices
+ Playback restrictions
MediaTailor preserves these flags during manifest processing to ensure that all content metadata is maintained in the personalized manifest.

Understanding these advanced concepts helps you configure MediaTailor for optimal performance and troubleshoot any issues that may arise in your DASH streaming workflows.

## Ad insertion concepts
<a name="what-is-ssai-terms"></a>

Here's an overview of the concepts that are related to ad insertion.

**Ad avail**  
A specific unit of advertising time within an ad break that can be sold to advertisers. An ad break may contain multiple ad avails. When MediaTailor receives a VAST response from an ad decision server, it fills these avails with personalized ads.

**Ad break**  
The time period during programming when commercials are shown. Ad breaks can occur before content (pre-roll), during content (mid-roll), or after content (post-roll). MediaTailor identifies ad breaks in manifests through markers like SCTE-35.

**Ad decision server (ADS)**  
A server that provides advertising spot specifications based on criteria including current advertising campaigns and viewer preferences. 

**Configuration**  
An object in MediaTailor that you interact with. The configuration holds location information about the origin server and the ad decision server (ADS). The configuration also holds endpoints that provide access points in and out of MediaTailor.

**Dynamic transcoding**  
A process that matches the ad quality and format to the primary video content when content is requested. Dynamic transcoding reduces storage requirements and ensures that playback seamlessly transitions between the ad and video content.

**Manifest manipulation**  
The process of rewriting manifests from the origin server so that the manifests reference the appropriate ad and content fragments. Ads are determined by the VAST response from the ad decision server (ADS). As playback progresses, MediaTailor performs ad insertion or ad replacement into the content stream.

**VAST and VMAP**  
Video Ad Serving Template (VAST) and Video Multiple Ad Playlist (VMAP) are XML responses that the ad decision server sends to ad requests from MediaTailor. The responses dictate what ads MediaTailor inserts in the manifest. VMAP also includes timing for ad breaks and the ad avails within them. For more information about the logic behind MediaTailor ad insertion, see [Understanding AWS Elemental MediaTailor ad insertion behavior](ad-behavior.md). For more information about how MediaTailor works with VAST, see [MediaTailor ad server integration requirements](vast.md).

## Channel assembly concepts
<a name="what-is-ca-terms"></a>

Here's an overview of the concepts that are related to channel assembly.

**Channels**  
A channel assembles your source manifests into a linear stream. Each channel has one or more outputs that contain playback URLs accessed by players. The channel outputs correspond to the package configuration settings you create for your VOD sources. A channel contains a schedule, which determines when VOD sources will play in the channel's stream.

**Package configuration**  
A packager configuration is a representation of your VOD source that contains specific packaged format characteristics. You associate your package configurations with channel outputs to create playback streams for your VOD source's packaged formats, such as HTTP Live Streaming (HLS).

**Schedule**  
Each channel is made up of programs that are arranged into the channel's schedule. The schedule determines what time the programs will play in the channel's linear stream.

**Source locations**  
A source location represents the origin server where your assets are stored. It can be Amazon S3, an HTTP server, a Content Delivery Network (CDN), or a packaging infrastructure such as MediaPackage.

**VOD sources**  
A VOD source represents a single piece of content, such as a movie or an episode of a TV show. You associate VOD sources with programs to add them to your channel's linear stream.

**Audience**  
An audience defines a viewer cohort which can optionally have alternate content. You can define audiences on standard linear channels.

# How MediaTailor ad insertion works
<a name="what-is-flow"></a>

AWS Elemental MediaTailor interacts between your content delivery network (CDN), origin server, and ad decision server (ADS) to stitch personalized ads into ad breaks within live and video on demand content. 

Here's an overview of how MediaTailor ad insertion works:

![\[MediaTailor receives content requests, retrieves content from origin server and ads from ADS, then returns personalized manifest.\]](http://docs.aws.amazon.com/mediatailor/latest/ug/images/MediaTailorSSAI_Overview.png)


1. A player or CDN such as Amazon CloudFront sends a request to MediaTailor for HLS or DASH content. The request contains parameters from the player with information about the viewer, which is used for ad personalization.

1. MediaTailor sends a request to the ADS that contains the viewer information. The ADS chooses ads based on the viewer information and current ad campaigns. It returns the URLs to the ad creatives in a VAST or VMAP response to MediaTailor. 

   If you pre-conditioned the ads, the URLs point to the pre-transcoded ads. For information about ad stitching with pre-transcoded ads, see [Preconditioned ads](precondition-ads.md).

1. MediaTailor manipulates the manifest to include the ad URLs returned from the ADS, transcoded to match the encoding characteristics of the origin content. If you're using preconditioned ads, it's your responsibility to ensure that the ad matches the template manifest.

   If an ad hasn't yet been transcoded to match the content, MediaTailor will skip inserting it and use MediaConvert to prepare the ad so that it's ready for the next request.

1. MediaTailor returns the fully personalized manifest to the requesting CDN or player.

The ADS tracks the ads viewed based on viewing milestones such as start of ad, middle of ad, and end of ad. As playback progresses, the player or MediaTailor sends ad tracking beacons to the ADS ad tracking URL, to record how much of an ad has been viewed. In the session initialization with MediaTailor, the player indicates whether it or MediaTailor is to send these beacons for the session.

For information about how to get started with ad insertion, see [Getting started with MediaTailor](getting-started.md).

# AWS Elemental MediaTailor ad insertion event flow
<a name="mediatailor-event-flow"></a>

AWS Elemental MediaTailor processes manifest personalization for server-side ad insertion through a predictable sequence of events. Understanding this event flow helps you comprehend how MediaTailor transforms ad opportunities into personalized viewing experiences and provides a foundation for troubleshooting when issues occur.

Each ad insertion opportunity follows a chronological sequence of events that MediaTailor logs for visibility and monitoring. These events represent key milestones in the manifest personalization process, from detecting an ad opportunity to delivering tracking information.

## Standard event sequence
<a name="standard-event-sequence"></a>

When MediaTailor successfully processes an ad insertion opportunity, the following sequence of events typically occurs:

1. **Ad opportunity detection** - MediaTailor detects an ad marker (such as SCTE-35) in the content manifest, indicating an ad personalization opportunity is available.

1. **Ad decision server request** - MediaTailor sends a request to the configured ad decision server (ADS) to retrieve advertisements for the detected opportunity, including viewer parameters and ad break duration.

1. **Ad response processing** - MediaTailor receives a response from the ADS containing ad creative information, tracking URLs, and metadata about the advertisements to be included. For more information about VAST, VMAP, and VPAID response formats, see [Ad server integration requirements](vast.md).

1. **Manifest personalization** - MediaTailor successfully processes the ad response, transcodes the advertisements if necessary, and generates a personalized manifest that includes relative URLs for both the ad segments and origin content. MediaTailor then sends the personalized manifest to the playback device.

1. **Tracking beacon activation** - A tracking beacon is fired to report ad events (such as impressions, quartiles, and completion) back to the ad server or other measurement systems. In server-side reporting mode (default), MediaTailor fires the beacon based on player segment requests. In client-side reporting mode, the playback device fires the beacon using URLs provided in the personalized manifest.

**Typical timing:** This entire sequence usually completes within 2-5 seconds, depending on ad decision server response time and ad creative processing requirements.

## Common event variations
<a name="common-event-variations"></a>

Not all ad insertion attempts follow the standard successful sequence. MediaTailor handles various scenarios that can alter the event flow:

### Empty ad response scenario
<a name="empty-ad-response"></a>

When the ad decision server returns no advertisements:

1. Ad opportunity detection occurs normally

1. Ad decision server request is sent successfully

1. ADS returns an empty response with zero ads

1. No ads are included in the personalized manifest for this opportunity

This is a normal scenario that can occur due to ad inventory availability, targeting criteria, or business rules configured in the ad decision server. In this case, the underlying content will be displayed unless the stream is a live or live-to-VOD stream and slate has been configured. For more information, see [MediaTailor slate ad insertion](slate-management.md).

### Error scenarios
<a name="error-scenarios"></a>

When technical issues prevent successful ad insertion, the event flow might be interrupted at various points:
+ **Ad decision server timeout** - The request to the ADS exceeds the configured timeout threshold, preventing ad retrieval.
+ **Communication errors** - Network or connectivity issues prevent MediaTailor from reaching the ad decision server.
+ **Response parsing errors** - The ADS returns a response that MediaTailor cannot parse due to invalid VAST format or structure.

In error scenarios, MediaTailor typically continues with content playback without ads, ensuring uninterrupted viewer experience. For live or live-to-VOD streams with slate configured, slate content might be displayed instead. For more information, see [MediaTailor slate ad insertion](slate-management.md).

### VAST redirect scenarios
<a name="redirect-scenarios"></a>

When the initial VAST response contains a redirect to another ad server:

1. Ad opportunity detection and initial ADS request occur normally

1. Initial response contains a redirect instruction

1. MediaTailor follows the redirect to retrieve the final ad response

1. Manifest personalization proceeds with the final ad content

1. Tracking beacon activation occurs normally

VAST redirects are common in programmatic advertising and allow for ad server chaining and real-time decisioning. MediaTailor allows up to 7 wrapper redirects and unlimited HTTP redirects during the ad retrieval process.

## Event timing overview
<a name="event-timing-overview"></a>

Understanding the timing characteristics of MediaTailor event flows helps set appropriate expectations for ad insertion performance:
+ **Ad opportunity detection** - Occurs when MediaTailor receives a `GetManifest` request from the player and encounters the ad markers in the content manifest.
+ **Ad decision server interaction** - Typically takes 100-500 milliseconds, depending on ADS response time and network conditions.
+ **Manifest personalization** - Usually completes within 50-200 milliseconds after receiving the ADS response.
+ **Tracking beacon timing** - Varies by reporting mode. For server-side beacons, timing is based on segment requests from the client player; client-side beacons fire based on player implementation.

**Performance considerations:** The total time from ad opportunity detection to manifest delivery should typically remain under 5 seconds to maintain optimal viewer experience. Individual components complete in milliseconds as described above. However, the 5-second threshold accounts for potential timeout values, retry attempts, and network variability that can occur during the complete ad insertion workflow. Longer delays might indicate ADS performance issues or network connectivity problems.

## Using event flow knowledge
<a name="event-flow-next-steps"></a>

Understanding MediaTailor event flow provides the foundation for:
+ **Implementation planning** - Knowing the event sequence helps in designing player integration and ad server configuration.
+ **Performance optimization** - Understanding timing expectations enables identification of bottlenecks and optimization opportunities.
+ **Troubleshooting preparation** - Familiarity with normal event flows makes it easier to identify when something goes wrong.

For detailed troubleshooting guidance using event flow analysis, see [Troubleshooting](troubleshooting.md). For technical details about event logging and monitoring, see [Viewing logs](monitoring-through-logs.md).

## Related services
<a name="related-services"></a>
+ **Amazon CloudFront** is a global content delivery network (CDN) service that securely delivers data and videos to your viewers. Use CloudFront to deliver content with the best possible performance. For more information about CloudFront, see the [Amazon CloudFront website](https://aws.amazon.com/cloudfront/).
+ **AWS Elemental MediaPackage** is a just-in-time packaging and origination service that customizes live video assets for distribution in a format that is compatible with the device that makes the request. Use AWS Elemental MediaPackage as an origin server to prepare content and add ad markers before sending streams to MediaTailor. For more information about how MediaTailor works with origin servers, see [How MediaTailor ad insertion works](what-is-flow.md).
+ **AWS Identity and Access Management (IAM)** is a web service that helps you securely control access to AWS resources for your users. Use IAM to control who can use your AWS resources (authentication) and what resources they can use in which ways (authorization). For more information, see [Setting up AWS Elemental MediaTailor](setting-up.md).

## Accessing MediaTailor
<a name="accessing-emt"></a>

You can access MediaTailor using the service's console.

Access your AWS account by providing credentials that verify that you have permissions to use the services. 

To log in to the MediaTailor console, use the following link: **https://console.aws.amazon.com/mediatailor/home**.

## Pricing for MediaTailor
<a name="pricing"></a>

As with other AWS products, there are no contracts or minimum commitments for using MediaTailor. You are charged based on your use of the service. For more information, see [MediaTailor pricing](https://aws.amazon.com/mediatailor/pricing/).

## Regions for MediaTailor
<a name="regions-endpoints"></a>

To reduce data latency in your applications, MediaTailor offers regional endpoints to make your requests. To view the list of Regions in which MediaTailor is available, see [Regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).