Colin is right, there is no consideration of cluster - if the group (or user-role) is configured for a 50Mbps shaper, and there are 2 users, each on a separate controller, then each can have 50Mbps of throughput.
A shaper contract, whether applied to a role or a single user, allocates its buffer depth depending on the rate configured. The smaller the shape rate the smaller the buffer. There is no ordering or precedence applied per user, ergo if there is a single 50Mbps shaper applied to a role then all users on that controller in that role will have at it on a first come first served basis. It would not necessarily result in 50/50 splitting, e.g. if one client already had a heavy transfer running and the second client started up, it would have to fight to get through.
As such, group based shaping can be quite unfair, and is often detrimental to real time traffic as there is no fancy stuff done when deciding what packets to drop when the buffer is full.
Routers and dedicated packet shapers of course offer a wider selection of shaper algorithms that increase fairness, improve QOS and implement minimum guaranteed rate etc., but the controller unfortunately does not have such capabilities.
Final comment, please be aware of bug AOS-191579 which causes auth crashes on S-UAC when ap-group bandwidth contracts are configured. It's just recently fixed in 8.3.0.13 and 8.5.0.7, and any 8.6.0.x. If you're not on 8.6 or one of the fixed builds, you should probably move to role based in the interim.