Were you simply unable to configure django-compressor (or any other pre-existing django statics library) properly?
An even worse problem is that you won't be able to transition to using async dependency loading for your JavaScript since there's no way to get the filenames of each compressed bundle that you'll need to pass to whatever lib you're using.
These problems don't apply much when you're just prototyping something, but it turned out to be an awful hole we dug ourselves into when we ran into severe performance bottlenecks with Django's template rendering and serving all our JS on page load.
In this case the 2 hours I spent implementing my own solution means it works exactly how I want it to and going forward it will be way easier to maintain.
1. The config was overly complex and not flexible enough for our needs.
2. It added extra, and unnecessary deploy steps which slowed down our deployments.
3. Configuring GZIP on S3 and Cloudfront is prohibitively complex.
CloudFlare on the other hand, solves many of these problems for us.
http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support...
So unfortunately, cloudflare would be your only option.
Also, google's pagespeed service (in beta) is also an option. Also free, so that's good :D
EDIT: Okay, wrong again. Appears that cloudfront will serve dynamically gzipped content if your origin server responds with gzipped content to the Accept-Encoding header. So origin server = S3 is not a good idea, but origin through your own web server should work fine.