Michael Bernstein sent me a discussion note at the S3 Forum on the new pricing infrastructure and how it penalizes for smaller files. From there, I found a more disquieting thread.
When asked the question, Are 404 and 403 errors charged under the new pricing plan? the answer was:
As our intent is to charge equitably for system resources used, we will be charging the owner of the bucket for 403s and 404s, since they consume system resources (as do all requests). Note that we will not be charging for requests which fail due to an Amazon S3 internal system error (all other requests will be billed).
(emph.mine)
In case you missed it, let me repeat this: we will be charging the owner of the bucket for 403s and 404s, since they consume system resources. What this means is that anyone can setup a simple script to post requests to my S3 account to non-existent files, and I'll be charged for each request. Even if I set the bucket to be private and requests return a 403, not authorized. A badly behaved bot, aggregator, or other application could do the same. The risk of maintaining my photos at the site has now become too great, and I'll have to plan on moving these by end of the month.
Then there is 304 requests: they're also being charged. HEAD and conditional/range GET requests will be billed at the GET request rate? Answer: Yes, that is correct.
As was mentioned in another thread, Amazon had no intention of S3 being used for web access. It had no intention of this being used by anyone outside of larger, corporate uses through the company's EC2 CPU enabled applications. Surprising considering how this was the way the system was packaged for sale. So much for Web 2.0 thinking. So much for Amazon being one of the 'cool kids'. Be interesting to chat with Jeff Bezos about this at the next O'Reilly conference.
"So, Jeff, how does it feel to be the Web 2.0 man who broke Web 1.0 functionality?"
If you're using S3 in a public facing capability, I suggest, strongly, you work on your exit from the system before June. If you're using the site for backup, make doubly sure that your site can't be accessed by the public. If you're using it for backup, you might want to consider doing the same, or hope no one figures out your private bucket names.
S3 is effectively dead as a web service.
I looked more closely at a site such as SmugMug, which uses S3. I'm not sure if the company is using EC2, but regardless, the site is serving images through it's own server, which then accesses S3. This means that the requests aren't direct to the S3 service.
If they can cache images, the company can probably limit GET requests. I imagine it might be able to work something out with Amazon not to be charged when any of their buckets is accessed anonymously, resulting in a 403, forbidden access.
I thought about putting something in for me locally, but it's not worth it. This means a request would have to go to my server, which then I'd have to programmatically process into a request to S3, cache the most recent photos, and then serve up the image. Talk about 'break the web'.
No, it's obvious that S3 was not intended for this type of service, and this is a move to chase those of us who 'corrupted' the service off. Though the costs seem low, it's the lack of control that's really becoming the issue.
As for bandwidth, bandwidth was never the issue for me as physical storage was.
