# RTMS reduces meeting capture infrastructure costs by up to 7.5x One of the most visible differences between Zoom [Realtime Media Streams](/docs/rtms/) (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](/img/blog/jenbrissman/attendee/ram-cpu-savings.png) _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:** | **Implementation** | **Average vCPU** | | ------------------ | ---------------- | | RTMS | 0.28 | | Meeting SDK Linux | 0.98 | | Meeting SDK Web | 2.01 | **Peak observed vCPU:** | **Implementation** | **Peak vCPU** | | ------------------ | ------------- | | RTMS | 0.316 | | Meeting SDK Linux | 1.081 | | Meeting SDK Web | 2.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: | **Implementation** | **Max RAM** | | ------------------ | ----------- | | RTMS | 296 MB | | Meeting SDK Linux | 365 MB | | Meeting SDK Web | 1047 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: | **Implementation** | **CPU Request** | **RAM Request** | **Cost per Hour** | | ------------------ | --------------- | --------------- | ----------------- | | RTMS | 0.25 vCPU | 450 MB | $0.012 | | Meeting SDK Linux | 1 vCPU | 550 MB | $0.042 | | Meeting SDK Web | 2 vCPU | 1600 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](/docs/rtms/). [Attendee](https://attendee.dev/), 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](https://app.attendee.dev/accounts/signup/) on Attendee's cloud instance, or read our related [blog post](/blog/realtime-media-streams-attendee/) to learn how Attendee simplifies deploying and scaling RTMS workloads.