RTMS reduces meeting capture infrastructure costs by up to 7.5x

One of the most visible differences between Zoom Realtime Media Streams (RTMS) and Meeting SDK bots is that RTMS doesn't require a participant bot to join the meeting. When you build applications that scale, you quickly see how RTMS also consumes significantly fewer compute resources.

We ran a controlled benchmark comparing RTMS against traditional meeting bots across both the Meeting SDKs on Linux and web. We placed RTMS and Meeting SDK bots in identical hour-long group meetings and measured their CPU and RAM consumption throughout the session.

The results were striking.

On average:

  • RTMS used 86% less CPU than Meeting SDK Web bots
  • RTMS used 72% less CPU than Meeting SDK Linux bots
  • RTMS used 71% less RAM than Meeting SDK Web bots
  • RTMS used 18% less RAM than Meeting SDK Linux bots

The reduction in resource usage translates directly into lower infrastructure costs and higher media density per machine.

Chart showing RTMS CPU and RAM savings compared to Meeting SDK bots

While resource consumption will vary based on meeting size and media activity, the relative differences between RTMS and Meeting SDK bots were consistent across our test runs.

Measured resource profile

CPU usage per meeting

Average vCPU consumption:

ImplementationAverage vCPU
RTMS0.28
Meeting SDK Linux0.98
Meeting SDK Web2.01

Peak observed vCPU:

ImplementationPeak vCPU
RTMS0.316
Meeting SDK Linux1.081
Meeting SDK Web2.224

For media processing workloads, CPU is often the primary infrastructure cost. When media pipelines become CPU constrained, media quality can degrade, resulting in dropped frames, audio artifacts, or synchronization issues.

RTMS's lower CPU footprint means a given machine can support more sessions and higher quality media capture.

RAM usage per meeting

Maximum observed memory consumption:

ImplementationMax RAM
RTMS296 MB
Meeting SDK Linux365 MB
Meeting SDK Web1047 MB

Memory utilization is equally important when running media capture workloads in containerized environments. If a Kubernetes pod exceeds its memory limit, the process may be terminated entirely.

A lower and more predictable memory profile allows operators to provision smaller instances while maintaining a comfortable safety margin.

Estimated AWS infrastructure costs

To estimate real-world impact, let's assume these workloads are deployed on AWS Fargate (Linux/x86) in us-east-1.

Using current Fargate pricing of approximately $0.04048 per vCPU-hour and $0.004446 per GB-hour, and sizing each deployment with sufficient headroom based on the benchmark results, the estimated hourly infrastructure costs are:

ImplementationCPU RequestRAM RequestCost per Hour
RTMS0.25 vCPU450 MB$0.012
Meeting SDK Linux1 vCPU550 MB$0.042
Meeting SDK Web2 vCPU1600 MB$0.090

Under these assumptions, RTMS delivers:

  • 7.5x lower infrastructure cost than Meeting SDK Web bots
  • 3.5x lower infrastructure cost than Meeting SDK Linux bots

For teams processing thousands of meetings per month, these differences can have a meaningful impact on cloud spend.

Why is there such a big difference?

The answer comes down primarily to video processing.

The Zoom Meeting SDK was designed to help developers build custom Zoom clients used by humans. As a result, Meeting SDK bots behave much like traditional meeting participants. They receive video streams, decode them into raw video frames, manage rendering pipelines, and then re-encode the media to generate a final asset.

Each of those steps consumes CPU.

RTMS takes a different approach.

Because RTMS is connected directly to Zoom's media pipeline, it does not need to behave like a rendered meeting client. Instead of decoding video into raw frames and then re-encoding it for storage, RTMS can work directly with stream-friendly media formats and collect the encoded media as it is delivered.

By eliminating unnecessary decode and encode steps, RTMS dramatically reduces the amount of processing required to generate assets for playback or processing.

The result is lower CPU utilization, lower memory consumption, and lower infrastructure costs.

TL;DR

RTMS changes the economics of meeting capture infrastructure.

By providing direct access to Zoom media streams without requiring a meeting bot, RTMS not only simplifies the user experience, but also significantly reduces the compute resources required to operate at scale.

If you're building recording, transcription, analytics, or other media-processing workloads on Zoom, those efficiency gains can translate directly into lower cloud costs and higher system capacity.

Try RTMS yourself

RTMS is Zoom's real-time media streaming platform for developers who need direct access to meeting media. To learn more about RTMS and start building, explore the RTMS documentation.

Attendee, an open-source API and deployment platform, was used to collect the benchmark data presented in this post.

If you're looking for a fast way to get started, create a free account on Attendee's cloud instance, or read our related blog post to learn how Attendee simplifies deploying and scaling RTMS workloads.