Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Likely the reason traffic shaping was mentioned because it's generally "nicer" in how it regulates bandwidth than a policer or rate-limiter, since it attempt to queue excess traffic rather than just dropping it.
The 3560 does supports "shaping" per egress queue. See the SRR shape feature in:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_50_se/configuration/guide/swqos.html
However this might not be suitable for you if you have more than customers than the 4 egress queues. (Ditto issue if you "shape" physical egress port, as mentioned by another poster.)
Otherwise, on your platform, you're limited to policing inbound traffic as described by Edison.
If you do utilize the policing method, you'll likly need to tune parameters as defaults often tend to impact TCP traffic enough that actual usage is much less than agreed upon bandwidth.
