Media Cloud Costs: Render Bursts, Transcoding and Archives

Media workloads have a distinctive cost profile. Compute arrives in bursts: a render deadline, a batch of deliverables to transcode, a live event. Storage accumulates as raw footage and masters are retained. The two need opposite treatment: compute should drop to nothing between bursts, and storage should move down tiers as it ages, without tripping minimum-duration charges.

Burst compute: render and transcode

• Render farms. AWS Deadline Cloud orchestrates 3D rendering and visual effects across fleets of EC2 workers. For customer-managed fleets, Deadline Cloud publishes fleet-size recommendations you can feed into an EC2 Auto Scaling group; service-managed fleets need no scaling setup.
• Scratch disks do not survive a stop. If render nodes write to fast local disk, check what survives. On AWS, instance store data persists across a reboot but not across a stop, hibernate or terminate; every block is cryptographically erased. On Google Cloud, Local SSD data on a GPU instance is unrecoverable when the instance stops for host maintenance. Anything worth keeping must be copied to durable storage before a node is stopped, whether by you, a schedule, or the provider.
• Transcoding has two billing models. AWS Elemental MediaConvert on-demand queues bill by the features you use. Reserved queues bill for the whole queue’s capacity whether you use it or not, require a 12-month commitment, and do not scale automatically. A reserved queue only pays off if the pipeline keeps it busy.

Archive storage: minimum durations are the trap

Cold tiers are cheaper per GB but charge for a minimum period, so moving data too early costs money:

Retrieval fees apply to all of these tiers. Azure Archive blobs must be rehydrated before they can be read, which can take up to 15 hours. S3 Intelligent-Tiering avoids retrieval fees, moving objects not accessed for 30 consecutive days to Infrequent Access and 90 days to Archive Instant Access, for a per-object monitoring fee. Objects under 128 KB are not tiered.

Where ZopNight helps

ZopNight gives cost visibility, scheduling, recommendations and showback across AWS, GCP and Azure:

• Storage checks per bucket. Rules check S3 buckets still in Standard with a low access rate (RC-070), without Intelligent-Tiering (RC-071) or without a lifecycle policy (RC-072), GCS buckets in Standard with low access (RC-1233), and Azure storage accounts on the Hot tier with low access (RC-1325). Bucket size and object count are pulled from CloudWatch and Cloud Monitoring. Where a rule cannot price a saving from real data, it abstains instead of estimating.
• Lifecycle changes as a reviewed action. Setting a lifecycle policy is one of the remediation actions, run through the precondition, execute and validate steps.
• Compute that stops between deadlines. Render and encode VMs on EC2, GCE and Azure can follow a schedule, with overrides that keep a box on for a set window with a reason and an expiry when a deadline slips.
• Cost per project. Tag-based showback attributes cost by project or show tags, and accepted smart tags fill the gaps where tags are missing.

Read storage tiering for the decision logic, and see S3 in ZopNight for bucket coverage.