Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is it really cheaper to host images and scripts via S3 than with an EC2 instance running nginx/varnish/etc. ?

It seems to me (but i'm just getting started with AWS) that the request costs will be the major factor if you don't use sprites or other optimizations... or am i missing something ?

share|improve this question

closed as off topic by Mark Henderson Jan 12 '12 at 5:46

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Shopping Questions are Off-Topic on any of the Stack Exchange sites. See Q and A is hard, lets go Shopping and the FAQ for more details. –  Mark Henderson Jan 12 '12 at 5:46

5 Answers 5

up vote 2 down vote accepted

You are kinda attempting to compare apples and oranges here. Amazon's EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service) services serve two totally different purposes. S3 is meant for redundant storage and is not a "server" per se. Yes, if you had a webserver hosted else where you could use S3 as a form of CDN using S3 along with Cloudfront, but the primary purpose is storage. EC2 on the other hand is a VPS (virtual private server) that would be able to run daemons like nginx, varnish, apache, etc. S3 by itself can not do this for you.

If you create your own AMI (Amazon Machine Image) for an EC2 then you would store them within S3 and you would pay the storage fees associated with that. An EC2 instance can be run without any use of S3 at all. However, as mentioned EC2 instances do not store data past shutdown when the instance is no longer running. In order to have data retained between startups & shutdowns you either have to store it on S3 or use an EBS (Elastic Block Store) that can persist the data for you.

There are different pricing tiers on the bandwidth inbound, outbound and within a given region as well as the storage capacity, I/O requests, etc. This gets complicated and there are several calculators out there to help you figure it out. I've written my own spreadsheet with formulas that I import my usage history CSV downloads to help estimate future usage costs. I've been managing several server instances for a client within EC2 now for over 9 months now. I've found the easiest cost to calculate is instance runtime as it is a simple hourly rate per instance. After that EBS volume and S3 storage capacities are easy to calculate but the I/O requests and bandwidth can be surprising at times.

My S3 storage costs are usually quite trivial (usually < $2/month) and I store several AMIs and some documents that the application servers access, along with the initial start-up of the instances. My instances use a Puppet server maintained on a VPS outside Amazon that also serves as my monitoring and jumpbox server. Running about 7 instances on average I've found my I/O requests to be between 5-8 million and cost < $1/month on average. The last 6 months I've averaged about 10GB in EBS volumes and that only costs a little over $1/month. I use EBS volumes for my static content along with my MySQL database files and binary logs. Data transfer inbound has ran between 20-24GB and averages ~ $2.25/month while outbound ran between 241-326GB and averaged ~ $42/month. My regional bandwidth between instances ran between 130MB-535GB as not all of my instances are in the same availability zones and averaged ~ $2.45/month. All that said, as I stated the hourly rate being the easiest to calculate we run upwards of $1700/month for the EC2 instances themselves. We're currently looking to move to reserved instances vs. on-demand instances and should drop that to around $600/month after the upfront cost ($6-9K) of getting the reserved instance.

share|improve this answer

With S3 you're paying for transfer and storage. With EC2 you're also paying for time that the instances are running. Either way, you're paying for transfer and storage, so it should be cheaper in all cases to just use S3 for file hosting. EC2 should always be more expensive because you're paying for the time the instance is running in addition to storage and transfer. Amazon has a pricing calculator that you can use to play with the numbers based on your own use case and estimated transfer and storage required.

share|improve this answer

Hosting static files on S3 is cheaper than paying for any dedicated server to host that content. It also relieves you of a few headaches like http server config opimization, disk space management and general server issues.

It also give you an easy option of leveraging Amazon's CDN (CloudFront) in case you want to further enhance download performance for your site visitors.

share|improve this answer

You need to factor in the amount of traffic that will be pulling hte s3 data to the webserver. ec2 you pay by the hour but you get 160GB of local storage, s3 you pay for storage and bandwidth.

In general I'd say that for a webserver the ec2 instance will either be cheaper or equal to s3. But take a look at the pricing calculator to verify

share|improve this answer
2  
It's worth pointing out that the 160GB of local storage is temporary. If you shut down the instance, the data is gone forever. –  tylerl Jun 7 '10 at 21:58
    
Including if the server goes down and is unable to be rebooted –  Rob Olmos Nov 5 '10 at 7:19

Since S3 is essentially providing a distributed network filesystem, try looking at using EC2 nodes to build that.

MongoDB/GridFS would be a compelling comparison.

S3 supposedly has read/write timeouts from time to time and building your own cache layer might also help.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.