views:

19

answers:

1

We host our images on Amazon S3, and serve them through Amazon Cloudfront. We'd like to reduce our bandwidth expenses. We believe that we have quite a bit of bandwidth theft, and want to start using signed URLs to prevent this. However, we have to balance this against the fact that each time we send out a new signed url, it invalidates the browser caches for the image.

Our current plan is to generate a signed url that is valid for two months, then cache it locally and serve it for a month, before generating a new signed URL. This will allow the browser to cache the images for longer. However, this also means that anyone can then leech bandwidth for an image for up to two months.

Is there any way to have the link expire sooner, but have the browser continue to cache that image? I know that the etag and If-Modified-Since for the image do not change when the url is resigned for a new timestamp, but the the browser no longer knows to send those values in the header, because as far as it is concerned, this is a new URL. Is there any way around this problem?

A: 

Have you measured how much of your bandwidth is being stolen? ie, check how many requests you get for your images that don't have a referrer field set to your own site.

For optimum caching, we recommend caching for 10 years, so 2 months sounds like a little short.

bluesmoon
We had tried logging, but didn't have any good way of going through the log files to quantitate how much bandwidth was being stolen. We are trying again, with s3stat.com. Looking at a log file at random generally shows some leeching--there are some chinese sites that hotlink our images. but it is hard to say how much it is costing us, vs how much it would cost us in bandwidth from reloads if we had to reduce cache times.
Karptonite