AWS Snowcone
aws.amazon.com
aws.amazon.com
It seems like a way to sync local big data to AWS cloud storage for data that is too large to realistically transfer via the internet. So is this simply a sneakernet external harddrive because physically shipping an 8TB hard drive has better bandwidth than using the internet?
I would love it if someone could explain a couple of use cases for the Snow family of products to someone that has never had to handle 100 GB of data much less terabytes.
The use case for the other Snow products (Snowball, Snowmobile) are clearer, as they are for transferring petabytes of data to/from AWS without having to use slow internet connections. Snowcone could be used for this indeed, but at only 8 TB, the value proposition seems a lot less. Personally, I'd probably just suffer through having to spend a week doing a slow internet upload/download rather than paying for Snowcone.
Also, the articles talks multiple times about using Snowcone to upload the data for you, over your own internet connection. Why would I pay for Snowcone to do that when I could just upload directly to S3, without using Snowcone as the middle layer, and get the same speeds?
The compute aspect of it seems cool from a "im a tech enthusiast and this is cool" perspective, similar to how a Raspberry Pi is cool, but I don't see the real-world use case for hosting compute workloads on a rented Raspberry Pi. I would just buy a Raspberry Pi instead for cheaper.
What this does make me interested in is something like this, but purchaseable outright without renting, a la AWS Outposts but the size of the Snowcone. It would be cool to have a swarm of Raspberry Pi sized devices that I controlled entirely through the AWS console with AWS services, and it would open up some niche use cases like having a tiny server cluster in places where I otherwise wouldn't have infrastructure, like a remote research camp or rural community.
I knew AWS bandwidth costs were absurd, but it wasn't until seeing those numbers that it really hit me just how absurd they are.
“Someone else’s problem”
That’s what you’re paying for on any cloud provider. Any hardware problem isn’t your problem and it (should be) abstracted away.
So AWS made this.
Now they have an offering for you & everyone like you, that they can pitch to CxO execs, especially those who came from Snowmobile-using companies.
>Personally, I'd probably just suffer through having to spend a week doing a slow internet upload/download rather than paying for Snowcone.
Well, I think there's two things here.
1) A lot of businesses probably won't be willing to spend a week with reduced internet capacity to upload stuff. Things we as single users might be okay with might not always translate to being a good fit for a business overall.
2) My reading is that some of the use cases for this are areas where you are likely to have limited or no internet connectivity.
From https://aws.amazon.com/snowcone/
>AWS Snowcone is built for edge computing and data storage outside of a data center. It is designed to meet stringent standards for ruggedization, including free-fall shock, operational vibration, and more. When sealed, the device is both dust-tight and water-resistant, protected from water jets on all sides. Snowcone has a wide operating temperature range from freezing to desert-like conditions, and withstands even harsher temperatures in storage.
and:
>AWS Snowcone deploys virtually anywhere you need it. It features 2 CPUs, 4 GB of memory, 8 TB of usable storage, Wi-Fi or wired access, and USB-C power using a cord or optional battery. You can put it in a messenger bag, run it in an autonomous vehicle or an airplane, or even attach it to a drone.
So, ruggedization and the ability to run this totally off battery points me towards thinking about use cases where there's not existing infrastructure to take advantage of. I guess this supported by the 'run it in an autonomous vehicle or airplane' bit I'm quoting as well.
Perfect for us. We used to ship small amount of data in the scheme of things on external drives to Amazon for long term storage in Glacier. Worked great. That program was dropped and replaced by Snowball.
We tried Snowball and never could get it to work properly in our location. Amazon support couldn't get it to work, either. It was really overblown for what we wanted to, anyway.
Sending over the wire isn't an option for us.
This is a better solution for us as long as the networking issues are resolved and the pricing works out.
My guess is for situations where you don't have a decent internet connection. Like some remote research base way out in the middle of nowhere. The other major application I can think of is for transferring data to air-gapped networks. You could use Snowball for this also, but that would be overkill in a lot of cases. I think for air-gapped networks this is meant to fill in the niche between a USB drive and something like Snowball.
EDIT: expanding on that off the top of my head I can think of a couple other applications. If you're using long range drones with lots of sensors (think RQ-4 global hawk, but also weather monitoring and the like) you're generating way more data than you could stream over a satellite uplink. So you could put a snowcone (or maybe several) inside the drone and use them for storage of all that raw data. On landing you can remove the snowcone(s) and ship it off to Amazon and all that raw data is available on S3 the next day. There's a bunch of other defense-type applications. Embassies could transfer these in diplomatic pouches for top secret information. In fact, if you wanted to be particularly secure but wanted lower latency, you could use the snowball to transfer a bunch of random bytes to use as a one time pad, which the embassy or intelligence center could use on demand as it transfers data back.
I can certainly see where this makes more sense if you're below that average, though.
0: https://www.speedtest.net/global-index/united-states#fixed
But I really want that stat to be true. The world of American ISPs is sad and depressing.
The first google result for median says it was 60/5 two and a half years ago. If you can sustain 90% saturation that's 164 days. Over half a year at 80%.
Most or at least many households in the UK I think max out at my speeds (FTTC) which puts me at about 20Mbps upload. At 2.5 meg/second that's over 4 days per TB if I've done my maths right. 8TB is over a month.
I'm looking at a house where I'd have an upload speed about 1-2Mbps, so well over a month per TB uploaded.
> It would be cool to have a swarm of Raspberry Pi sized devices that I controlled entirely through the AWS console with AWS services,
You used to be able to manage things on opsworks outside of AWS if you installed a client. Maybe you still can do this kind of thing - possibly AWS Systems Manager for non-opsworks things? I get a bit lost in all the services these days and their restrictions.
You’re looking for Greengrass, which is hidden away in the IoT tooling AWS provide. It allows you to run Lambda functions and Docker containers on Raspberry Pi (and smaller) sized devices, controlled entirely through the AWS console.
For them Snowcone is perfect as it's much cheaper than Snowball and does the job of trickling data back home.
When we did it, we bought a drive, went to the colo, offloaded the files, and you have to do some stuff to kick off a job to let them know you're sending a drive and what kind and all that sort of thing. Then you mail it to them and they run an import into an bucket.
My guess with these drives is controlling the hardware makes the process significantly more efficient for them, and for the enterprise customers they're trying to move off colo and onto AWS.
The other big part is pricing. AWS charges $ 0.09 per GB for outbound transfer, so getting 8 TB of data out of AWS via the internet costs over $ 700. Doing it through Snowcone costs around $ 300 + shipping.
Reasonable use-case would be transferring video material or high resolution sensor data.
DO is great for small personal projects, but, I wouldn't run a fortune 500 company on it.
4TB on S3 Deep Archive: $3.96/mo to store, $360 to restore and download over the internet 4TB on B2: $20/mo to store, $40 to download 4TB on Digital Ocean: $80/mo to store, $30 to download
Yes, it feels almost extortionary to have to pay that much to get your data out of AWS. But depending how long you store data for, it can end up being the cheaper option: you're just gambling on how likely you are to actually need to download it.
Snowball/snowcone, US East
$0.03 per GB ~-> $300 per 10TB
If you're buying disks at scale that's almost the cost of the disk.
Network egress
$0.15 per GB
$0.08 per GB (>150TB/month)
It makes sense for the occassional transfer so you're not paying for expensive EBS storage for stuff you don't need cloud access to.
Regarding the size of the data. Well, yes. There are companies with petabytes of data. Banking is one example that comes to my mind when thinking about petabytes scale data.
Imagine Amazon was bidding on a big Department of Defense contract ($ in billion). DoD let's say wants to send drones / UAV's whatever to do big sensor passes out in far off areas / imagery, wideband radio etc). There is NO fast internet for the TB's generated. You pop this out of the drone, put it on the next resupply mail flight out, and ingest into Amazon cloud on far side for analytics.
Let's stay a store wants to collect 30 days of customer video related to all traffic in their 100 stores to do some sort of AI analysis on how folks use the stores. Again, some poorly paid store staff person can unplug this after a week and ship it off.
Let's say I generate data but instead of wanting to do a snowmobile every year, I want to do more granular moves. Again, I could do a weekly or whatever ship, and again from maybe a few locations.
I think especially in places with lower high speed internet penetration (africa, china etc) there is room for something "snackable" like this.
Let's say I distribute movies to movie theatres. Again, do a weekly ship in/out.
It's $60/job. Not bad. No data IN fees.
Sometimes, even when we're in the middle of a big city, there's still no secure or reliable internet connection at the location we've been given, so this might be good for those cases, too.
I'm not on the infrastructure side of things, so I can't say for sure. But I've already forwarded the page to our mobile IT team to make sure they've heard about it.
Edit:
They might also be good for television and movie production. In the early part of this century, rushes were sent from remote filming locations to the studios loaded onto iPods. With everything being 4K and higher now, this might be useful to move those rushes to a cloud location where they can be accessed by multiple people who need to see them in multiple cities.
More details here: https://blog.maxar.com/earth-intelligence/2017/digitalglobe-...
"A carrier pigeon with a cargo of microSD cards can transfer large amounts of data faster, and more cheaply, than just about any other method"
Link: https://spectrum.ieee.org/tech-talk/computing/networks/pigeo...
$0.00099 per GB per month * 100,000,000 GB = $99000
When I was using glacier, we treated it sort of like a write only storage, with the understanding that if we ever needed data out, we’d have to think long and hard about the data’s value, and probably would have gotten an AWS rep on the line to make sure we didn’t do anything stupid.
The cert is limited to *.wpengine.com
And the link 404s so.. that's a shame. Was interested in learning more about the platform.
You can learn more here: https://www.digitalglobe.com/products/gbdx
One of the distributor show me a 64 MB usb flashdisk that’s travelled every week with the delivery truck to get 4 MB of data from their branches (8 hours truck driving from the capital)
Went to Myanmar in 2017. The nation is just upgrading to 4G in 2016. But not every places have 4G coverage
2019 in eastern Indonesia (Seram island) you’re lucky if you can get a reliable 5 KB/s internet. It’s a remote area, but we still have a branch there :(
> Explore the new AWS Snowcone with Bill Vass and Jeff Barr (2:46)
[1] https://www.youtube.com/watch?v=8RNRssCiR_E&feature=emb_rel_...
The old method of customers sending in hard disks and AWS importing them turned out to be _incredibly_ high touch.
* Customers would put the wrong labels on the wrong drives. Given they were encrypted, and the label details were critical to matching the right disk with the right encryption key, that was a big issue.
* Imports would routinely fail due to all sorts of driver bugs both on the AWS side, and on the customer side. The number of fringe NTFS quirks was phenomenal, let alone all the wide range of other formats that had to be handled
* Encryption tooling still really isn't all that user friendly. Too many opportunities for mistakes.
* Drives would get damaged during shipping.
* Stuff would go missing in shipping.
It just didn't scale as a solution, and caused unending customer pain and frustration.
Snowball solves _all_ of that, by taking out of the equation almost anything about the process that customers could get wrong. It handles all of the encryption stuff, is extremely ruggedised, has basic tracking. The label is an e-ink display that automatically contains all the right information. It becomes a "just works" solution.
Now I'm really curious what filesystem Snowball wound up standardizing on, and how/if file metadata/ACLs/alternate data streams are maintained.
The software client for doing the transfer is some sort of command line JVM tool from my memory. You locally create S3 buckets on the snowball and copy from the local disks into the buckets.
Once the snowball is returned, the buckets appear in your online account.
Stuff going missing in shipping is solved by very low powered tracking chips in them. AWS knows where those devices are and could tell shipping firms if needs be.
The mining equipment runs greengrass right on the machine to do real time inference to help make mining more efficient as well as flag potential equipment failure to the operator.
So they would strap this device onto the equipment, it would collect data and do inference, and then they can swap it out for a new one and send the old one back so the data can be added to their data lake to update all of the AI models.
For our use case it was genome sequencing. Each individual genome was a terabyte or so depending on what types of data we sent. We can crank out a few hundred genomes per week at full production so when our collaborators need to receive their data they usually neither have the capacity in bandwidth or storage for cohort of thousands. So it gets shipped to AWS.
We've made improvements to get more direct connections to cloud services so we don't use them anymore but for awhile we were filling a snowball and shipping it every week or two. We also used the Google Transfer Appliance once or twice (480tb) to transfer projects all at once instead of piecemeal.
The ability to build AMIs and run them on Snowcones gives you the power to build applications that do all sorts of interesting filtering, pre-processing, and analysis at the edge.
To me the product feels like snakeoil and I'm skeptical it will take off in a big way, but I think more than enough customers will use it to justify their investment.
Remember, AWS is selling a platform. The more claws they can sink into their customers, the harder it is for them to switch to a competing one.
you can cloud compute separated from the cloud, but together, with your snowcone!
Yeah. When you have to migrate 100TB data from your own data store to AWS it is much easier and practical to just send the drives. They even help you with that, for a price of course.
That won't work if the recipient doesn't have a need to mail something back, but for a use case where you expected most boxes would be shipped back (maybe a phone repair company?), it could absolutely make sense.
Seems fairly trivial to have those drivers pick up last week’s carriers when they drop off this one’s.
That said, grocery delivery is much more "bursty" than package delivery.
"Bill the people who keep the plastic boxes," is the oft-heard refrain!
What if they're stolen off your porch due to living in a not-great neighborhood? You still owe?
Billing the customer and then penalizing them for being a victim of theft introduces so much friction and frustration.
Maybe I'm a germophobe, but isn't it kind of gross that this thing is shipped in no container and then put on your desk?
How long do germs last on an e-ink display?
I know on paper and cardboard and such it's not very long. From what I can remember, they die while still in the mail stream.
If you're concerned, hit it with some Lysol or soap and water.
I'm not a germophobe, but even so, this probably isn't a device you want to be handling while also eating a sandwich. Lysoling it is probably wise.
The snow products solve the same issues. Despite fiber connections and such it just doesn’t make sense to transfer massive volumes of data over the network. It’s often literally faster and cheaper to ship a box of hard drives via UPS or FedEx.
Snowball was for big sets of files and is the size of a suitcase. Snowmobile is for petabyte scale and is literally a tractor trailer full of disks.
The use case here seems to be more towards remote situations with smaller data. You have something that collects a lot of data and need to get that into your cloud. Instead of running around with a bunch if portable hard drives and then having someone transfer the data manually to S3 over the internet you just dump your data into the snowcone and hand it to your local UPS guy and let AWS take care of the rest. Lots of remote data collection devices and such would fit into that model.
Clearly the use case is rather specific but for people in the business of collecting data on stuff and then needing to get it into the cloud this is actually a nifty little device.
And that includes a $ 0.03 bandwidth fee from S3 tot Snowcone that I guess they're going to reduce over time since it's all on their internal network.
Not sure where AWS is going with this, but I'd like to see AWS offer a tiny version of AWS Outposts, where you can get any kind of AWS service in a box.
The other thought I have is that maybe there's a market for shipping around bytes in mail boxes not just between a business and AWS, but just any people and businesses. I've seen B2 and Dropbox (I think) also have these "we'll ship you a drive" things, but maybe they'd outsource that for example to a third party who just did it really well and cheaply.
We're running a sort of sneakernet between our data collection agents and our data ingestion locations, each day each location receives 2-4 encrypted SSD's (Samsung T5) with up to 1TB of data. That then gets uploaded to our central location (overnight) for processing, and the next morning they're drained and ready for the next mission.
If Amazon had launched this earlier, and our cashflow (or funding :P) a bit better then maybe we'd have opted for running a constant stream of these snowcones to Amazon. Though processing costs are also a big concern, the cloud providers are at least twice as expensive as running metal, even when looking at 1 year paying for the hardware up front, and if you're cost sensitive when buying the hardware it could be 3-4 times cheaper than the managed cloud.
What I'd be afraid of with this server is losing them in the mail. I wonder if they've got a system where you could mirror two snowcones before you send one to them.
Maybe would be handy for serving video content etc on a local network?
Or if you have a network of video cameras not connected to the internet, use this for daily/weekly collection of recorded content?
A 1Gbps dedicated (uncontended) fibre line in Europe seems to be in the region of $/€/£600 per month. How much data can one push on that per day (assuming 1Gbit/s = 100Mb/s real world)?
In one day: 100 * 60 * 60 * 24 = 8.64Tb
So call it one snowcone per day. So you could in theory send 30 snowcones a month, a total snowcone value of $60*30 = $1800.
However, at $60/snowcone, you would have to send 10 snowcones per month before your own dedicated line breaks even.
So yeah, if you're sending 10 or more per month, every month, consider getting a dedicated line. But that seems like an unusual use case to me.
There's also a bunch of organisational reasons to use something like snowcone, I'm sure.
I say this given AWS prior gov/cia work. Securely capturing, transferring, and maintaining chain of custody for intel from various media and devices captured during raids or other activities was (several years ago) a total shit show. We had a closet full of trash bags from various raids. The analysts weren’t in the field, the op tempo and slow data rates prevented us from making good use of most of the data. Some of which was time sensitive (we would find out weeks later). Also some of the data captured was to be used as evidence in the host nation legal system (I don’t know if that ever happened) or (presumably) GITMO. I was just a grunt at the time, and this was a long time ago but I bet the problem still exists.
For many remote data collection activities this could remove the need for expensive and long lead fiber installation.
- snc1.micro, CPUs: 1, memory: 1 GiB
- snc1.small, CPUs: 1, memory: 2 GiB
- snc1.medium, CPUs: 2, memory: 4 GiB
What happens when the eink display is damaged or stops working during shipping though? I'm presuming if dynamic shipping labels like this ever become common, shipping companies will need their own independent identifier or a standardized physical identifier they can use to pull up shipping information from should such a case occur.
> I connect the Snowcone to the power supply and to my network, and power up! After a few seconds of initialization, the device shows its IP address and invites me to connect:
With a convincing e-Ink display, and an unusually long delay, you've probably got a good 10 minutes on this local network to 0-day your way into routers and client machines.
> Next, I download AWS OpsHub for Snow Family, install it, and then configure it to access the device. I select Snowcone and click Next:
By this point you make the device self-brick and print out an error about how it needs to be sent back to Amazon for repairs, due to being banged up during shipping. Extra scuffs or dents in the case will sell this. While the replacement is ordered, use your now client-resident malware to exfiltrate data as you like, since you know there's data worth them copying offline. Or trojan up every data format you see so that after the data is moved out via a working Snowball you can eventually find an internet-connected device to exfiltrate with.
If this was swapped in shipping it could potentially just work as expected while exfiltrating data whenever it could connect to the internet, potentially through builtin lte, etc.
Even the backup thing, last time I tried they all had some pretty simple UI built around a rsync fork
nor is it supposed to be. AWS is tools to build end-consumer products, not an actual end-consumer product itself.
It's akin to having an understanding in file system - just that it's in the cloud this time. I'm sure a lot of non-techie understand enough about file systems to work what they needed it to do. And the same goes for the cloud.
S3 is an eventually-consistent object store. We need to treat it as such.
It is an awesome box and an awesome solution to a real life problem. I really wanted to love snowball.
I was not filling them all the way up by any means, so the turnaround had to be fast enough for me to justify it over just uploading to s3 over slowish connections.
The interface in the console was very opaque and gave no information about when the boxes would get shipped out.
I had weeks long delays with zero contact when the box types I wanted were out of stock and only found out that was the cause when I cried to support.
I also had boxes stall at the import stage after they had already been shipped back.
The software to transfer was also just ok.
I think with more love this can be a great tool, but there are some things that could make it better.
I sure hope they don't use Amazon delivery. They'll deliver stuff to other houses, complete with a "delivery proof" picture of the wrong house and claim that you must have lost it.
EX https://media.amazonwebservices.com/blog/2020/snow_luna_1.jp... and https://www.slideshare.net/AmazonWebServices/new-launch-intr...
> "Perform local compute and storage workloads, without transferring data. You can order multiple devices in a cluster for increased durability and storage capacity."
> First, you should contact AWS Sales to discuss private pricing for the long-term AWS Snowcone deployment
(Seriously, at the moment, some teams literally offline their server and physically take it to the playa to run there instead of figuring out connectivity there. Very little of it's using newer tech)
I assumed it was here to give a sense of the relative size of the drive, but after staring at this picture for two minutes I genuinely have no idea what it is.
Actually at first I even wondered if that was the drive, since it's vaguely more in the shape of a snowcone than the drive itself.
https://acromove.com/products/serverpack-35/
They also have Serverpack Edge which is supposed to do the same.
"we invented on premise cloud"
"you mean It's just a small server?"
"no no it's like having a bit of cloud in your home"
I wonder what's special about these images.
I'm on a team that has a need for remote compute power, but getting to our devices on anything more frequent than a monthly basis is sometimes a challenge.
https://aws.amazon.com/snowcone/features/
> For a light workload at 25% CPU usage, the device can run on a 65 W battery for approximately 6 hours.
The docs are a little inconsistent on wattage requirement. The feature page above says "60 W+ (20 V) USB-C power adapters", but in the docs:
https://docs.aws.amazon.com/snowball/latest/snowcone-guide/s...
> any USB-C power adapter that is rated for 45W+
> AWS Snowcone weighs 4.5 pounds and includes 8 terabytes of usable storage
Having dealt with a few Snowballs from time to time, there is zero doubt they have space in those things for 100tb. They're not small or lightweight devices.
I'm super happy to see this device. It fills a niche a lot of my work falls into nicely.
Starlink will help with this, but sat data connections (IME) are perpetually saturated.