I would recommend at least 1 top level relay for all deployments.
As long as your root server is spec’d right, then I don’t think you actually “need” a relay with less than 3000 clients except for other benefits that a relay can help provide like WAN optimization and bringing UDP to systems behind a NAT.
That said, you might consider having a single relay as a “fake root” for security reasons. This allows all clients to talk to the single relay as if it is the root server without needing knowledge of what relays exist in order to find one. This also means that you can isolate your root server so that the only things that can talk to it are the “fake root” relay and BigFix Consoles / Web Reports / Web UI / Similar. If you do not do this then that means any client that can talk directly to your Root Server can also access the BigFix REST API and be able to use the BigFix Console directly, which is not a good idea for security reasons. The other reason to do this is you SHOULD NOT have your BigFix root server itself accessible directly over the internet. You need at least one relay to serve this function, which can be your “fake root” relay.
The other reason to have at least one top level relay is that relays are fairly easy to swap out without disrupting BigFix as a whole. I recommend that your top level relay(s) and/or root have large caches to prevent the breaking of prefetches if a download is removed from the internet. It is very easy to expand the storage of the relay or make a new relay with greater storage, copy over the cache from the previous relay, then swap them out in DNS.
A single top level relay will also allow BigFix clients to continue to download files and send reports when the BigFix server is offline during an upgrade.
The top level relay(s) can be configured to batch reports together into bigger chunks before being passed on to the root server which can help speed up the root server’s ability to ingest reports if it does not have storage with high enough random IOPS or a fast enough NIC.
What is fake root?
It just means having a top level relay with the DNS name of the Root Server as defined in the masthead file. The actual root server would be given a different DNS name. Everything downstream would think it is talking directly to the root server when in fact it is actually talking to the top level relay (fake root). The fake root / top level relay would have a manual relay assignment for the actual DNS name of the root server and/or an entry in it’s hosts file that points to the actual root server.
Because of this concept of fake root, and other considerations, it is not a bad idea for the hostname used in your BigFix masthead that points to your root server to be a CNAME DNS record that is something like bigfix.contoso.com while the actual DNS A record for the root server or fake root would be something like toplevelrelay.it.centraloffice.contoso.com or some other location. It could even be in Amazon EC2 or Microsoft Azure or anywhere else. It doesn’t matter, it just matters that the CNAME record that matches what is in the masthead points to the root or fake root and that you change the CNAME record if you move the root or fake root somewhere else with a different DNS A record.