What is AWS Snowball and when is it the choice solution for large-scale data ingest to S3?
re:Invent always spawns some great moments where you go “Hmmmmm…,” whether it’s during the keynotes or the hundreds of presentations. But, this year, given the announcements about AWS Snowball, Kinesis Firehose, QuickInsight and Database Migration Services – those moments stretched into an ever-present buzz around the need that many companies have to move large amounts of data into the cloud for S3 and Glacier. Some are driven by the pure size of the data sets and digital content; others require real-time streaming. Obviously, given that Signiant lives and breaths accelerated file movement, the former really calls out to us.
AWS Snowball is an interesting HW appliance solution from AWS, something that you wouldn’t normally think would come from Amazon. It’s a unique approach – hardened JBODs (“just a bunch of disks” or a collection of hard drives) with a Kindle interface that customers literally fill up and mail to AWS. It has the capacity to physically move 48 TB of data for $200 over a week’s time. Like sneaker-net on steroids.
Snowball definitely is a sound solution if you’re moving bulk data periodically, but beware of potential operational, performance and efficiency costs.
It can be a compelling solution, IF you can maximize the efficiency of $$$/GB. That is, if you don’t max out the 48 TB, your overall cost efficiency drops. Additionally, there is still a challenge of operational efficiency as you need to set up the appliance, account for transfer times from your premise-based storage to the appliance, transfer the appliance via UPS and then upload the data to S3.
The frequency of your file transfers, the size of your files and where you want to distribute your digital content should influence your decision to go with a managed SaaS solution rather than do a bulk upload with Snowball.
The excellent presentation on Media Supply Chain co-delivered by FOX’s Chris Blandy, EVP of Technology Solutions and SDVI’s Simon Eldridge, Chief Products Officer is a perfect example of when Flight is the better choice. Fox Network Engineering and Operations supports the production of close to 4000 programs per year with about 330k playout hours per year over 3 managed production facilities. This dictates the need to ingest large content from many sources with numerous production control rooms, hundreds of graphics systems, edit bays, master control rooms, etc…
So Fox is consistently moving content into and out of the cloud (S3) and would benefit from the cost efficiency, flexibility and elasticity that that a fully managed service such as Flight delivers, including security and controls. In this case, Flight not only reduces costs and increases operational efficiency; it preserves the elasticity of the cloud for peak volumes (Flight automatically scales additional instances for you as a managed service). For Fox, it’s also in line with their Cloud-First strategy.
If I took one major theme away from re:Invent, the growing need to move large digital content and data sets into the cloud continues to be a challenge, and industry leaders like FOX and SDVI are leveraging cloud-first solutions to address this need.
In a world of SaaS, wouldn’t you rather utilize your existing network to efficiently and securely ingest any amount of data to S3 or Glacier whenever you need to? Without ever having to create a shipping label?