Skip to main content

AWS Solutions Library

Guidance for Media Provenance with C2PA on AWS

Establishing digital content authenticity

Go to sample code

Overview

This Guidance demonstrates how to run the Coalition for Content Provenance and Authenticity (C2PA) standard for tracking provenance with media workloads on AWS. C2PA allows you to create digitally signed manifests that accompany digital assets to document their provenance in a secure, tamper-evident format. This Guidance automates this process by using the C2PA open-source command-line tool wrapped within a Docker container. An AWS CloudFormation template then creates an application using both AWS Fargate and AWS Lambda to accept each digital asset along with input arguments and produce a C2PA sidecar file to document each asset's origin.

How it works

AWS Fargate

This architecture diagram shows how you can generate a C2PA manifest sidecar file for a media workload in your AWS account using AWS Fargate. This also works with AWS Lambda, as shown on the next tab.

Download the architecture diagram
Architecture diagram illustrating an AWS Cloud solution for C2PA media provenance using AWS Fargate, Amazon S3, Certificate Authority, AWS Secrets Manager, and associated cloud components, including digital asset management and JSON assertions.

AWS Lambda

This architecture diagram shows how you can generate a C2PA manifest sidecar file for a media workload in your AWS account using AWS Lambda.

Download the architecture diagram
Architecture diagram illustrating a media provenance workflow using C2PA standards on AWS. Components include AWS Lambda, Secrets Manager, S3, a certificate authority, MAM system, and JSON assertions. The diagram shows the flow of digital assets, certificate creation, and manifest generation in the AWS Cloud.

Deploy with confidence

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

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 Cloud Development Kit (AWS CDK), which enables you to manage infrastructure as code, lets your developers automatically deploy, update, or delete this Guidance for different environments. Additionally, it enables a scalable and structured approach to managing infrastructure. As a result, you can reduce potential manual operational error risk on the console and easily deploy the solution to other parts of your business.

Read the Operational Excellence whitepaper

IAM roles protect the API that is exposed by Lambda function URLs, so only users with the right permissions can call endpoints. Additionally, users must access the API exposed by Fargate by using an internal Application Load Balancer that is only available to callers within your VPC. You can incorporate Amazon Virtual Private Cloud (Amazon VPC) advanced security features to configure specific access rules. Finally, Secrets Manager securely stores digital certificates and the private keys that are used to sign C2PA manifests, and it also provides auditing and monitoring tools.

Read the Security whitepaper

Lambda generates C2PA manifests in a serverless environment that is designed to be highly available and reliable. For example, it automatically scales functions to maintain availability, retries processes in the event of failure, and can be configured to run in multiple Availability Zones (AZs) to provide resilience.

Amazon Elastic Container Service (Amazon ECS), used with Fargate, is an alternative architecture to generate C2PA manifests. This architecture uses a fully managed service to deploy and manage containerized applications, and it supports reliability through health checks and automatic healing to handle unexpected system errors. For example, Fargate continuously monitors and replaces any failed or unhealthy containers and scales based on workload to maintain application reliability and responsiveness. Additionally, if you configure Fargate to run in multiple AZs, Application Load Balancer will automatically route requests to healthy containers, making request handling more resilient.

Read the Reliability whitepaper

Lambda supports function URLs, simplifying the architecture by exposing a REST API without an API gateway. These functions scale automatically based on demand, so your DevOps teams do not have to provision and manage Amazon Elastic Compute Cloud (Amazon EC2) instances or plan and manage Amazon EC2 Auto Scaling groups. Additionally, Fargate simplifies containerized application deployment by launching tasks in a serverless environment without the need to provision and maintain Amazon EC2 instances. You can also size Fargate tasks to match workload characteristics and configure it to automatically scale the number of running tasks up or down to maximize the use of computing resources.

Read the Performance Efficiency whitepaper

Lambda only bills for the time it is processing data and scales based on demand so that you are not billed for idle computational resources. Additionally, you can configure Fargate to use the right CPU and memory sizes to balance performance against cost.

Read the Cost Optimization whitepaper

Lambda only uses the computational energy required for your workload. Fargate is a managed service, so instead of implementing your own container infrastructure, you can rely on AWS for the high utilization and sustainability optimization of the deployed hardware.

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.