S3

Use Amazon S3 storage or not?

• Posted by Rob (#1) on April 18, 2008 15:11 CEST

Capsi is not in jeopardy of requiring more bandwidth and storage than planend for with its current hosting solution. It is however the goal that one day it will require more resources - and I'd like to plan ahead.

Capsi's current host, EngineHosting, is probably the best entry-level hosting provider when it comes to knowledge, support and reliability. They on quality of service, where budget hosts tend to oversell resulting in questionable availability and horribly incompetent support. Not EngineHosting - they know what they're doing.

The downside? EngineHosting offers limited disk space and data traffic. So I have the feeling that splitting dynamic content from static content would be a good decision in the long run. So let's do some math, assuming bandwidth is a greater resource risk than storage. What would the next 5GB of traffic (average filesize 50k, so that's 100,000 requests) cost? And what's the next upgrade step?

Let's take a look at the options:

• Upgrade to a higher hosting level iof EngineHosting. This would give Capsi 15GB more data traffic for $10 extra, plus 600MB of extra storage. That's $0.66/GB traffic. The next upgrade step would beanother $20 a month extra, for 25GB more traffic: $0.80/GB.
• Amazon S3. Marketed as content storage and definitely not delivery, but possibly a good starting point for smaller enterprises who can't yet commit to one of the big CDN's (content delivery networks). 600MB storage generating 5GB data traffic in 100,000 requests? Monthly cost: $1.25, or $0.25/GB. And how much resources would $30 extra buy as opposed to the 50GB in total for EngineHosting? More than 10GB of storage and more than 100GB of traffic (2 million requests).

Don't be surprised if Capsi's static content will soon be hosted on S3..

Additional benefits:

• Fewer static images in the htdocs directory, making it easier to find the actual dynamic pages residing there.
• User uploads go directly to the S3 bucket - no more need for PHP to have write permissions into an upload directory within htdocs.
• No need to manually ignore the user upload directory when uploading a new code base to the production server. No need to synchronise user content towards the development environment either - and in which case it is desired, the S3Fox Firefox add-on will make it a trivial task.
• Even though S3 is not a true and proper CDN, the separation of static content will make it easier to migrate towards one in the future.
• Seperate error logs for code problems and missing content. Seperate access logs for actual visitor activity and content delivery.

Yup, I'm going to give it a go with a couple of static images. And if I'm happy with the performance, reliability, ease-of-use and costs.. I will definitely port the user content uploads towards S3. Another added benefit, albeit specific to Capsi: this would be a great opportunity to obfuscate content names more, providing better privacy for users using Capsi's access levels.

Last but not least: Neil will probably complain how Amazon is naughty for its one-click shopping patent, but to be honest I don't think life will be much fun if you're going to avoid every single bit of evil..

• PermaLink: Use Amazon S3 storage or not? (2 comments)
• Tags: Capsi, content, hosting, EngineHosting, Amazon, S3, CDN, data traffic
• Post comment