You know you're supposed to use S3. Just do it.
January 22, 2018

You know you're supposed to use S3. Just do it.

Justin Schroeder | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Overall Satisfaction with Amazon S3 (Simple Storage Service)

We use S3 for everything imaginable, but particularly for storing larger assets like images, video, isos or data files. This allows us to purchase much smaller nodes in terms of attached SSDs. The cost of S3 for storage is almost a non-issue for anything in the sub-terabyte range, especially when compared to the price of larger EC2, Rackspace, or digital ocean instances.
  • Nearly every web framework now has integrations with the service as an easy plug-and-play storage solution.
  • General integration is so good there are tons of third-party tools like Transmit (for mac) you can mount S3 as a remote disk for easy access, and even Amazon's own web portal for using S3 has gotten quite good.
  • It's incredibly easy to offload all the expensive bandwidth operations for your typical website or app to S3, and, assuming your services are not yet HTTP2, you even get the benefits of sharding.
  • There is no true hierarchical filesystem in S3. So for example, if you have a file like /images/pizza/1.png, and you delete 1.png it deletes the entire directory structure. Now many tools will place an empty dummy file at /images/pizza to make it appear as if the structure is there – but if you do these operations via api it can be a bit of a gotchya.
  • The bucket namespace is global, so it can be really hard to get a sensible bucket name. Honestly no idea why they made that global.
  • While you can serve S3 content at your own subdomain, you have to have the proper bucket name to do so and this can get pretty cumbersome. Ideally, there would be a better way to mask S3 buckets at a DNS level.
  • S3 has a direct impact on ROI because it lowers your overall hosting budget. You will pay pennies on the dollar to host your larger files as S3 over your compute nodes. Especially when you consider all the additional backup storage, image storage, and uptime requirements of keeping files online where your compute nodes are.
  • If you ever want to have server clusters, where do you think you're going to store your static assets? Yep, S3. No brainer again – now you can scale.
  • I'll throw one more bone out here for this – you can literally distribute s3 files to a global CDN (CloudFront) with just a few clicks of a button. That kind of speed can have an immediate return on investment for international customers.
There are alternatives, Google Cloud Storage and Azure storage are the only real rivals, in my opinion, although most hosting vendors have their own flavor of an S3 like utility. However, most of those are actually just sub-vendors of S3. The most compelling case for using something else over Amazon is that S3 is a pretty significant point of failure in the general internet network as a whole. On the other hand, using Google Cloud Storage or Azure feels a little bit like using a windows phone in 2015 – you just knew it didn't have a great future.
Amazon Elastic Compute Cloud (EC2), Rackspace, Laravel PHP Framework
Anytime – and I do mean anytime – you have files of any size over, say, 50kb and they are static you should reach for S3 first. In 7 years of using the service, I have never once lost a file. There have been a total of maybe 30 minutes of downtime in 7 years, which was a DNS level issue. The speed is excellent, the availability is incredible, and there simply is no good competitor for the price.