Cloud-Based 3D Rendering: When Render Farms Beat On-Prem

Cloud rendering is one of the places where the hyperscaler marketing and the reality sit uncomfortably far apart. The pitch is simple: burst to hundreds of GPU nodes, finish your animation in hours instead of weeks, pay only for what you use. The reality is that the economics depend heavily on how often you render, how big your scenes are, and whether your team is already set up to move assets around.

We have helped studios and design shops build both sides — on-prem render farms and cloud-burst pipelines — and the answer is almost never one or the other. It is almost always a hybrid, and the shape of the hybrid is what matters.

1. Do the Utilization Math Before You Do Anything Else

The first question is how many hours per week your render infrastructure is actually busy. On-prem render hardware is cheapest when it runs near 100 percent utilization. Cloud render is cheapest when hardware sits idle most of the time.

A realistic on-prem node with an RTX 4090 or an L40S costs $5,000 to $8,000 to build, another $500 to $1,500 a year to power and cool, and depreciates over three years. Call it $3,000 per year all-in for a single node. The same node on-demand in the cloud is roughly $1.50 to $3.50 per hour, so 1,000 rendering hours in a year hits the breakeven point.

If your team renders two hours a day, five days a week, you are at 520 hours. Cloud wins. If you render nights and weekends on every node, you are at 5,000+ hours. On-prem wins by a factor of 3 to 5. Most shops we see are somewhere in the middle, and the right answer is a base of on-prem nodes for predictable load plus cloud burst for crunches and deadlines.

2. Pick the Right GPU Class

Not every render job needs the biggest GPU. Arnold, V-Ray, and Redshift each have different memory and compute profiles, and the cost-per-frame curves are not the same across GPU tiers.

For most animation and product visualization work, an L4 or L40S on the cloud side is the right price point. A100 and H100 are optimized for ML workloads and overbuy on memory for most render jobs. The one exception is very large scenes that exceed 24 GB of VRAM — those need either the A100 (40 or 80 GB) or need to be refactored with texture streaming.

Cloud GPU availability has been tight for two years. If you need H100s for inference and rendering both, you may be waiting in a queue. For rendering specifically we have had much better luck with L40S and A10 availability on AWS and GCP.

The specialty providers

Lambda, CoreWeave, RunPod, and Paperclip are worth knowing about. They tend to undercut hyperscaler GPU pricing by 30 to 50 percent, availability is usually better, and the tradeoff is a thinner surrounding service catalog. For a pipeline that is just "move assets in, run the render, move the frames out," specialty providers are almost always the better economics. For a pipeline that wants deep integration with IAM, VPC peering, and managed storage, stick with a hyperscaler.

3. Asset Transfer Is the Hidden Killer

The single most underestimated cost in cloud rendering is moving the scene files. A 50 GB scene with texture dependencies uploaded to the cloud, rendered, and downloaded again is not free. Uploads are usually free, downloads from the cloud cost money, and the time to transfer can exceed the time to render.

Strategies that actually work:

• Keep the asset library in cloud storage permanently. Don't re-upload for every job. Mount the bucket or sync incrementally.
• Render in the same region as the storage. Egress within a region is free or cheap. Egress between regions is not.
• Transfer only deltas. rclone, rsync, or git-lfs for large binary assets.
• Compress aggressively. Most scene files compress 2 to 5x.
• Bring back only what you need. If the client only wants the finished frames, don't download the intermediate AOVs.

4. Render Manager and Queue Software

Whatever you use on-prem — Deadline, Tractor, OpenCue, AfanasyCGru — should also drive your cloud burst. A pipeline that can submit the same job to a local node or a cloud node without the artist thinking about it is the difference between "cloud is usable" and "cloud is painful."

AWS Thinkbox Deadline works on-prem and in AWS natively. OpenCue has cloud plugins. Tractor can manage mixed fleets with some configuration. Pick one, commit to it, and make sure the job definitions are portable between environments.

The worst pattern is a pipeline where artists have to know whether a job is going to on-prem or the cloud and package assets differently for each. That friction kills adoption and you end up paying for cloud capacity nobody uses.

5. Licensing Surprises

Render engines are licensed. The license server is usually on-prem, tied to a dongle or a MAC address, and nobody has thought about how cloud nodes will check out licenses. You end up with three options:

• Extend the on-prem license server via VPN to cloud nodes. Works fine as long as the VPN stays up.
• Move the license server into the cloud itself. Works if the vendor allows it.
• Use cloud-native licensing where the render engine supports it. Redshift, Arnold, and V-Ray all have some flavor of cloud licensing now, but the terms vary.

Read the license before you burst. More than one customer has discovered mid-crunch that their license does not allow cloud rendering at all, or only allows it with a specific provider, or requires an upgrade.

6. Cost Controls That Actually Fire

Cloud rendering bills can balloon overnight. The horror story is an artist submitting a job with the wrong sample count, spinning up 200 nodes, and running for 14 hours before anybody notices. The next morning's bill is $12,000 for a 30-second clip.

Controls we put in place every time:

• Hard spending cap at the account or project level. AWS Budgets, Azure Cost Management, or GCP Billing alerts with automated actions.
• Job-level resource limits in the render manager — max nodes per job, max wall clock time, max hourly cost estimate before approval.
• Approval workflow for large jobs. Anything over some threshold (say, 50 nodes or $500 estimated) requires a supervisor click.
• Idle shutdown. Nodes that have been idle for more than 15 minutes shut themselves down automatically.
• Daily cost review by the producer or studio manager, not just the IT team. The people who care about the budget have to see it.

The Hybrid That Actually Works

For a typical production house with steady work plus occasional crunches, the stack we would recommend:

• Base on-prem farm: 8 to 20 GPU nodes sized to handle 60 to 70 percent of average load. This is your cheap capacity.
• Cloud burst: 50 to 500 nodes on a specialty provider or hyperscaler, enabled by the render manager, used only for crunches.
• Asset library: in cloud object storage, with a caching proxy on-prem for fast local reads.
• License server: in the cloud, reachable by both on-prem and cloud nodes via private networking.
• Spending controls: daily budget alerts, per-job resource limits, approval workflow above a threshold.

This setup lets the on-prem side run at high utilization (where it is cheapest) while the cloud absorbs the spikes (where it is justified). The combined total cost is usually 30 to 50 percent lower than all-cloud and 20 to 40 percent lower than all-on-prem, with better deadline reliability than either extreme. Rendering is a mixed workload. Treat it like one.