For most DDoS attacks, on-premise RIOS filtering is the fastest and most cost-effective response. It mitigates automatically at line rate without adding latency or consuming rCloud capacity. Director is configured to let RIOS handle the majority of events, escalating to rCloud only when attack volume genuinely exceeds what your local capacity can absorb. This tiered approach means you are not burning rCloud capacity on attacks that RIOS could have handled, while still having the headroom to absorb the largest events your network will ever face.

rCloud plans have real limits depending on your tier — attack counts, bandwidth ceilings, and cost all factor into how you want to allocate cloud scrubbing capacity. If rCloud is a finite resource for you, it makes sense to ensure that capacity goes to the groups where availability matters most. Because Director pulls group and zone definitions directly from rWeb, you can configure your redirection policies at the group level. Lower-value groups or groups that are unlikely to face serious attacks can be excluded from rCloud escalation entirely, preserving your cloud capacity for the groups where downtime has real consequences.

Not all groups on your network behave the same way under attack. Some destinations, particularly those hosting high-profile services or operating in targeted industries, face large volumetric floods regularly. If those groups are consistently consuming local bandwidth before mitigation can fully respond, the answer is not to provision more hardware. The answer is to configure Director to redirect those specific groups to rCloud sooner, at a lower threshold than you would apply to the rest of your network. This frees up local capacity for other customers while ensuring the targeted group gets the scrubbing volume it needs.