I'm working on a commercial website where video files are uploaded, usually 4-10mb each, and roughly 200mb worth each month in total. The videos are not made public, they are uploaded for review by a specific person.
At present, visitors upload video through a php script that stores the file in a directory on the webserver and notifies the admin with a link directly to the file where the admin can view/download.
Each couple of months a copy is taken of this directory and given to the admin, then the directory is cleared so the site doesn't use up too much space. This copy is then added to a backup on another server.
What would be a better flow? I'm thinking we could be uploading to a file storage service in the cloud instead of to the webserver itself. That would remove the first couple of steps and could even replace their backup as well...
Amazon's S3 Storage pricing looks like it'd be quite reasonable for your application. You'd be in the lowest usage tiers on all their categories:
Storage Pricing
Standard Storage Reduced Redundancy Storage
First 1 TB / month $0.140 per GB $0.093 per GB
Request Pricing
PUT, COPY, POST, or LIST Requests $0.01 per 1,000 requests
GET and all other Requests $0.01 per 10,000 requests
Data Transfer Pricing
Data Transfer OUT
First 1 GB / month $0.000 per GB
Up to 10 TB / month $0.120 per GB
"Reduced redundancy" is suggested to provide for four-nines (99.99%) availability -- which equates to roughly 53 minutes of down time each year. Pretty good. "Standard Storage" had enough nines in their pricing calculator tool tip that you can assume only catastrophic events would bring down your data. It'd be the option I would pick if I were going to eschew backups entirely and rely on Amazon for backups.
Assume after two years of operation and doubled-yearly growth: 1000 megabytes of uploads per month: 12 gigabytes of storage, that's less than $2 per month for storage at the end of two years. (It'll be cheaper before then.)
Your PUT requests will be so infrequent (40-120 per month) that you might
as well pretend they are $0 per month.
Your GET requests will be so infrequent (80-240 per month, assuming both
the uploader and designated viewer download the content once each) that
you might as well pretend they are free for ever. (Penny per 10,000? Wow.)
If you assume two gigabytes of data out each month (this is two-years out viewpoint of doubled-yearly growth -- 200 megs becomes 400, 800, and assume both video uploader and designated viewer download each video exactly once, that's 1600 megabytes), that'll be another $0.24 per month.
Assuming decent growth rates and looking two years into the future to see what accumulated storage looks like, it'll be roughly $2.25 per month for your data hosting costs.
But the S3 storage only makes sense if you're prepared to modify your existing tools to upload to S3 storage buckets. You might need to go to more effort for your designated viewer to "view" the content -- the easiest approach might in fact temporarily download the content out of the S3 bucket to your webserver to offer for re-download to your viewers -- or you might need to write a tool that can speak S3 to download the content directly to your viewer's desktop. (There are libraries for Python and Ruby, probably others too; the s3cmd tool might also be useful for quick and dirty tools.