Scaling BigBlueButton on AWS with Scalelite

A single BigBlueButton server can handle a surprising amount, right up until two classes start at the same time. BigBlueButton doesn't scale by making one machine bigger forever. It scales by running several servers with a load balancer in front, and that load balancer is Scalelite.

This guide walks through what that setup looks like on AWS: the pieces you need, what each one requires, how recordings and TURN fit in, and where clusters usually go wrong. It assumes you already know how to install a single node. If you don't, start with our BigBlueButton install on AWS EC2 guide. We don't sell BigBlueButton as a product, so this is a plain technical walk-through built from the official docs.

When One Server Is Enough

The official requirements describe one node as 8 CPU cores with good single-thread performance, 16 GB of memory with swap enabled, 250 Mbit/s of symmetrical bandwidth, and UDP ports 16384 to 32768 open. On AWS, the docs name c5a.2xlarge or larger.

The Scalelite README puts a server at that minimum spec at around 200 concurrent users, and our BigBlueButton vs Jitsi comparison uses the same planning figure. Treat it as a starting point, not a promise, and measure with your own sessions. Our guide to WebRTC load testing shows how.

Past that point you have two choices: a bigger instance, or more instances. A bigger instance has a ceiling and stays a single point of failure. That is exactly why the project built Scalelite.

The Scalelite Architecture

Scalelite is an open-source load balancer, licensed AGPL-3.0, that manages a pool of BigBlueButton servers and makes the whole pool look like one server. A front end such as Greenlight or Moodle sends ordinary BigBlueButton API requests to Scalelite, and Scalelite hands each new meeting to the least loaded server in the pool.

It checks every server regularly: is it reachable, is it ready for API requests, and what is its current load? The docs describe that load as the number of meetings on the server, not the number of people in them. Read that carefully, because a server running one 100-person class and a server running one 5-person meeting can look the same. The docs don't spell out how load is calculated beyond that, so check how your Scalelite version behaves before you rely on it, and leave headroom for big classes.

There is one tuning knob. When you add a server you can give it a load multiplier, and the rake task docs say a higher multiplier belongs on the weaker servers. It defaults to 1.

Sizing the Pieces on AWS

Scalelite needs more than servers. Its docs list the pieces and their minimum sizes, and AWS's own reference architecture for BigBlueButton shows which AWS services fill them:

Scalelite asks for Redis persistence, so confirm that your managed Redis option can provide it before you commit. I haven't priced this setup, because the bill depends on region, instance count and hours. Multiply your node count by the on-demand price on AWS's pricing page, add the supporting services, and compare the total with what one large instance would cost.

Notice how little of that list is the BigBlueButton servers. The pool gets the attention, but the database, Redis and storage are what keep it coherent. Give them the same care you give the nodes.

Shared Recordings with EFS

With one server, recordings live on that server's disk. With a pool, a participant could have been on any node, and the front end still has to show one list. Scalelite solves this by consolidating recordings from all nodes on a shared volume and indexing them in the database, so it can answer "list the recordings" quickly. AWS's reference build uses EFS for exactly this, and its write-up notes that recordings reach the front end independently of the node that recorded them.

In practice that means mounting the shared volume over NFS on every BigBlueButton server and on the Scalelite side, and letting Scalelite's recording importer pick up what the nodes hand over. Follow the Scalelite docs for the exact paths and services.

Two things to settle early. Decide your retention period before the first class, because the shared volume only ever grows. And budget for disk: the BigBlueButton docs ask for 500 GB free per server if you record, or 50 GB if you don't.

TURN Is Not Optional

Some of your users sit behind firewalls that block direct UDP media. They can see the page, they can log in, and they still can't hear or see anyone. A TURN server fixes that by relaying their media over a port the firewall allows. The Scalelite docs say to set up a TURN server and configure every BigBlueButton server to use it, and that bbb-install can automate the configuration.

TURN isn't heavy on CPU or memory, but it wants port 443 for itself, so nothing else web-facing should share that instance. Run it on its own machine, not on a BigBlueButton node, so a busy class can't starve it.

If you'd rather not build that part yourself, Meetrix has a pre-configured Coturn TURN server with SSL ready to go, and our Coturn installation guide covers the manual route. It's the one piece of this stack where we have a ready-made product.

Scaling Out and In

Adding a node means building a BigBlueButton server, pointing it at the shared TURN server, and registering it with Scalelite. Removing one needs more care, because stopping a node ends the meetings running on it. Scalelite's rake tasks include a cordon command: a cordoned server gets no new meetings, and its existing meetings run until they finish. Cordon first, wait for the meetings to end, then terminate.

Be careful with the word "auto". AWS's reference build uses an Auto Scaling group, but it states that it is not using metric-based scaling. An operator changes the desired, minimum and maximum capacity by hand. My reading is that a metric-based policy has no idea which nodes are mid-class, so it could scale in a server that is full of students. For a school with a predictable timetable, manual changes work well: raise capacity before the morning classes and lower it afterwards. If you want to automate, schedule by time before you try scaling on load. The same ideas apply to other WebRTC servers, as our Jitsi Meet auto scaling on AWS guide shows.

Whatever you choose, watch it. A pool you can't see into is a pool that fails during the first big class. Start with the metrics in monitoring WebRTC in production.

Common Mistakes

• Running a cluster for one class. You pay for a load balancer, a database, Redis and shared storage that a single server never needed.
• Starting with fewer than three nodes. The docs recommend at least three in the pool.
• Putting TURN on a BigBlueButton node. A busy class then competes with your relay.
• Skipping shared recordings. Without the shared volume, recordings are stranded on whichever node made them.
• Terminating a node mid-class. Cordon it and let the meetings finish first.
• Sizing for the average class. Plan for the biggest session on the busiest morning, not the mean.
• Assuming Scalelite counts people. Its load figure is meetings, so one huge class can fill a node that looks half empty.

Where I'd Start