One media library: S3 access for processing and a drive for editors

Give each tool the interface it needs

Suite S3 Native lets people access supported object storage through a filesystem while files remain native objects for compatible S3 services. That creates a useful design for media teams: editors use a mounted drive, while an authorized processing service reads source objects through the bucket API.

Suite’s S3 Native overview describes these complementary access paths. File-based creative and processing tools can generally use the Suite drive without a dedicated integration, and can stream directly without pre-caching. A service using the object API needs S3 support; event triggers and mixed write paths are separate pipeline choices to validate. S3 Native requires at least 20 TB of active storage and assisted setup.

Draw the read paths first

Start with one approved source asset in supported storage. The editorial path is native object → Suite filesystem → creative application. The processing path is native object → authorized S3-compatible reader → processing job. Both point to the intended source, but use different interfaces and permissions.

Record the mapping between the object key and the editor’s file path. Object keys are not automatically desktop paths; AWS’s object-key documentation explains the object naming model. Validate the mapping through the actual supported Suite setup.

Define a processing job with a useful output

Choose one operation, such as generating a proxy, extracting authorized metadata or preparing a transcript with a selected tool. Record which source is consumed and which output the editor expects. The processing service may read a whole object even when the editor’s activity requests only part of the media.

The benefit to evaluate is less intermediate staging and a more connected library, not an assumption that every job transfers fewer bytes. Include compute, transfer, storage operations and output handling in the evaluation.

Keep permissions visible on both sides

Suite application permissions and bucket IAM are separate. Give the editor the necessary project access and the service only the objects and actions its task requires. An agent permitted to read the drive is not thereby authorized to obtain bucket credentials or disclose footage to an external service.

Use the permissions comparison to assign owners. Test an authorized read and an expected denied action in a controlled evaluation, without expanding permissions merely to bypass an unexplained error.

Agree on writes and completion

Reading the same source through two interfaces is only part of a production pipeline. Before writing directly to storage, confirm with Suite how new objects, overwrites, cached data and concurrent operations become visible through the filesystem. Do not assume immediate, conflict-free updates across interfaces.

Choose one owner per output and keep generated assets separate from originals. Define the observable completion signal and verify the editor can open the intended result. Event-driven automation is a separate integration to validate; do not assume a particular bucket event or processing service is included with Suite.

Prove one complete loop

For the pilot, an editor opens a selected source, the authorized processor generates a result, and the editor consumes that result. Record identity, access, completion, output correctness and preparation effort. Repeat once with a controlled failure such as a missing input so the recovery path is understandable.

Bring the provider, region, active capacity and proposed tools to the S3 Native discussion. Teams that want Suite-managed storage can begin with Managed; the customer-owned bucket architecture and its minimum should not be assumed to apply to that plan.