Diagram does help!
Controlling congestion downstream of the congestion point is difficult. Policing traffic like TCP, or shaping return ACKs, can get TCP flows to slow since they adapt their flow rate when they see lost packets. Other traffic types often don't slow. I.e. you can certainly police traffic as it ingresses (to you) on the Internet link or before passing it on to individual schools, which will certainly limit their received rate, but this might not slow or reduce inbound congestion on the Internet link. However, if you drop enough packets out of a video stream, the receipient of the stream might discontinue attempting to view it since the quality would be so bad (taking this bandwidth demand off your Internet link).
On most Cisco devices you could set an aggregate bandwidth for something like all received youtube traffic and/or set an aggregate on each school link; policing per flow, though, isn't as common. Some 6500s support it, i.e. microflow policing, don't know about other devices such as firewalls.
Since you note this is only a problem since the school links were upgraded to gig, I suspect the fact of the prior T1 links effectively did something similar to above (again, too many youtube requests would just degrade them so such requests, and their bandwidth demand, would be self limiting).
If this is correct, you can certainly try to either police or de-prioritize traffic, such as youtube traffic, and see how it works for you. You can also investigate what other QoS features your network devices support look especially for anything like per flow rate management.
