Customer Private Cloud

By default, service jobs are processed in a shared (multi-tenant) pool of compute instances provided by Telestream. Service charges include both the software usage and the cost of the compute instances needed for each job.

Telestream manages shared instance pools at multiple public cloud providers and in most geographic regions.

Optionally, jobs can be processed in a private (single-tenant) pool of compute instances provided by the customer. In this case the service charges include only the software usage. Compute instance cost is charged directly to the customer's account with the cloud provider.

Each customer private cloud is created at a specific cloud provider and in a specific geographic region.

In either case Telestream automatically scales the size of the pool (up or down) based on the current number of jobs.

Operating in a private cloud requires setup within the customer's cloud provider account. This section has detailed instructions for the setup at each of the supported cloud providers.

Security Roles

In general a private cloud is created and managed using Identity and Access Management (IAM) roles created within the customer's cloud provider account.

Each role grants the Telestream provider account a specific set of permissions. The Telestream account assumes those roles to operate the private cloud on behalf of the customer.

This section provides command line examples and Terraform scripts the customer can use to create the IAM roles in their account.

Depending on the cloud provider and security considerations the customer will need to create one or more of the following IAM roles. Note that none of these roles require access to customer storage or media assets.

bootstrap

The bootstrap role is used to create a private cloud in the customer account. While this role requires the most extensive set of permissions the customer can disable or delete the role once the private cloud has been created.

Alternatively Telestream provides a Terraform script that the customer can use to create a private cloud in their account.

autoscaler

The autoscaler role is used to create and delete compute instances within the customer private cloud. Typically the customer will place restrictions on the number of instances that can be created using this role.

Telestream can configure the autoscaler to use different instances types (on-demand, reserved, or spot) and different instance sizes based on the customer requirements.

instance

This role is used by an instance within the private cloud to attach block storage. This role is only required for certain services and only when the block storage created by the autoscaler was insufficient for a specific job.

Firewall Rules

Instances created within the private cloud require outbound network connections to public IP addresses over HTTPS (port 443) an gRPC (port 8496). Inbound connections are not required and will be blocked by the firewall.

Outbound connections are required to:

Communicate with the Telestream Cloud job manager and report job status. Job managers are available in most high traffic cloud provider regions.
Pull containers from the Telestream Cloud Docker registry. The registry is cached at each of the supported cloud providers.
Read and write media files to object storage.

Object Storage

A job running in either a shared or private instance pool will generally need to read or write media assets located in cloud object storage. Instances access object storage using either an IAM role or signed URLs.

Storage Role

A storage IAM role is used by an instance to read or write media objects to a bucket associated with the customer account.

Signed URLs

A signed URL can be used to read a specific media object. A signed URL contains the permissions required to access the object within a specific period of time. There are several issues with signed URLs:

Both shared and private cloud pools limit the number of instances that can be running at the same time. If the pool reaches this limit jobs will be queued until a resource becomes available. It is possible for a signed URL to expire during this period.
A signed URL can only be used for single object (file) media formats. Some media formats (QuickTime Reference, IMF Packages, etc.) have a primary media object that refers to secondary media objects. A storage role with access to the entire bucket must be used for these formats.