Skip to main content

Overview

This Guidance demonstrates new tools for media workflows in cloud environments as part of the Cloud-Native Agile Production (CNAP) program. This initiative builds upon the Time Addressable Media Store (TAMS) API specification, originally developed by the British Broadcasting Corporation's Research & Development team. The aim of the CNAP program is to drive industry adoption of TAMS as a cloud-native, open, and interoperable framework for fast-turnaround media workflows in the creation of News, Sports, and Entertainment content. TAMS stores media as discrete chunks in object storage, accessible through an open-source API. This approach eliminates common challenges found in traditional cloud-based media workflows. By using timing and identity as primary identifiers, TAMS enables content-centric workflows that reduce duplicate content and scale effectively, unlike traditional file-based systems.

How it works

TAMS concept overview

This architecture diagram shows the concept about how a Time Addressable Media Store (TAMS) sits at the core of a fast-turnaround workflow for processing live or near-live video and audio content.

Diagram illustrating a media asset management workflow, showing inputs like live video feeds and video files processed through TAMS Store with features like machine learning analysis, content clipping, and editing, leading to outputs such as streaming, playback, and file export.

TAMS data structure

This architecture diagram shows the high-level data structure represented in the TAMS API specification. This diagram establishes the connection between the content that a user would be aware of and the actual media essence, which is stored in multiple formats and segments on the object storage system.

Flowchart illustrating the breakdown of "Source Content" into "Source Video," "Source Audio," and "Source Data," with examples of flows like 1080p video, AAC audio, and JSON transcript.

AWS open source TAMS API

This architecture diagram shows the components and data flows within the AWS open source implementation of the TAMS API.

Diagram of an AWS architecture showing user authentication with Amazon Cognito, API Gateway, Lambda functions, data storage in Amazon Neptune and DynamoDB, event handling with EventBridge, optional webhooks, and a delete process using SQS, Lambda, and S3.

AWS open source TAMS tools

This architecture diagram demonstrates how the multiple components of the AWS TAMS Tools repository can be used alongside the core AWS open source TAMS implementation.

Diagram of a video processing workflow using AWS services, including live and file video ingestion, storage in Amazon S3, media processing with AWS Lambda and SQS, and delivery via HLS endpoints.

Deploy with confidence

Everything you need to launch this Guidance in your account is right here

We'll walk you through it

Dive deep into the implementation guide for additional customization options and service configurations to tailor to your specific needs.

Open guide

Let's make it happen

Ready to deploy? Review the sample code on GitHub for detailed deployment instructions to deploy as-is or customize to fit your needs. 

Go to sample code

Well-Architected Pillars

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

The AWS open source implementation of the TAMS API uses AWS X-Ray to trace requests through the serverless infrastructure, including API Gateway, Lambda, and DynamoDB. The X-Ray service aids developers and support teams in tracking and analyzing requests as they flow through the various components of the AWS open-source implementation of the TAMS API.

In addition, all logs and metrics are collected within Amazon CloudWatch to facilitate monitoring and analysis. The metrics collected within CloudWatch support the creation of dashboards and the configuration of alarms.

Read the Operational Excellence whitepaper

The TAMS API uses Amazon S3 pre-signed URLs to provide consumers with time-limited access to only the required segments, helping ensure that access control is managed centrally by the API, regardless of the consumer's location, whether within AWS or on-premises.

The AWS open-source implementation of the TAMS specification uses Amazon Cognito by default for authentication, providing OAuth2-based access control on the API, in addition to the ability to federate with other authentication providers. The current API implementation supports coarse-grained, role-based permissions across the various CRUD operations, with the team actively working on extending this to incorporate attribute-based access control (ABAC) in the near future.

Read the Security whitepaper

The AWS open-source implementation of the TAMS API exclusively uses AWS Regional-level services, including Amazon S3, API Gateway, Lambda, and DynamoDB. This design approach eliminates the need for AWS customers to manage Availability Zone-level resilience. Additionally, all the services employed will automatically scale and recover from any underlying issues.

Read the Reliability whitepaper

In the AWS open-source implementation of the TAMS, the database technologies have been carefully selected to provide optimal performance for the diverse access patterns. The sources and flows require complex linking and filtering capabilities, for which Neptune, a graph database, has been chosen as the appropriate solution. For the segments, the access patterns are more straightforward, but speed and performance are critical to handle the ingestion of new segments as they arrive. As a result, DynamoDB has been utilized to deliver the required performance characteristics.

Read the Performance Efficiency whitepaper

The TAMS-based approach eliminates the need for high-performance file storage alongside the object storage, as it maintains a single copy of the media on lower-cost object storage. The API facilitates the reuse of media segments across different content, thereby deduplicating the media at the storage level and resulting in savings in both storage space and cost.

The AWS open-source implementation of the TAMS is built around serverless components that scale and incur costs based on usage. Given that most media workloads exhibit peaky demand patterns, this design approach reduces costs to just the persistence layer (Amazon S3, DynamoDB, Neptune) when the system is not actively in use.

Read the Cost Optimization whitepaper

The TAMS approach to live media workflows is inherently more optimized and, consequently, more sustainable than traditional methods. At the storage level, there is no longer a requirement for high-performance file systems alongside Amazon S3 object storage, and the storage can be deduplicated, resulting in reduced space requirements.

The use of serverless technologies helps ensure that during periods of low usage, the resources are automatically scaled back, thereby reducing the environmental impact. In contrast, traditional on-premises broadcast solutions would typically remain operational 24/7, regardless of usage patterns.

The edit-by-reference model employed in the TAMS has the potential to reduce the need for rendering on edit workstations, thereby saving compute time and potentially allowing the use of smaller compute instances.

Read the Sustainability whitepaper

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.