I recently had a similar problem - I needed to serve dynamically resized images via CloudFront (with the images being stored in S3). Images are resized on-demand - if they exist they are served directly from S3. If not, they are resized and stored in S3, then the next request will serve them directly from S3.
It works rather well, although it is quite susceptible to the thundering herd problem - putting it behind a reverse proxy that supports collapsed forwards would probably help here.
I've put the WSGI app I used for this on github - hopefully someone finds it useful! https://github.com/mikery/s3cacher
Nice post... thanks.
I was thinking to use Cloudfront to lower the latency (not costs) for dynamic resources, because in Italy there isn't an ec2 datacenter, but there is an edge location for Cloudfront.
No 1005 ms was not a cache miss it was a request to the origin server. Latency was 799 ms.
I assume CloudFront will contribute some latency, however in our case (we are using Heroku) our servers were already on Amazon platform, therefore CloudFront --> our server latency should be significantly lower. So CloudFront cache miss latency for the enduser will be not significantly higher than origin server latency for the enduser.