Then again, the more I think about it, the more this makes sense. Satellite business is hard and capital intensive enough as it is, for starters in the micro-satellite business it would be absolutely prohibitive to run their own hardware just to receive those signals.
Nope, this was actually announced [0] about 18 months ago.
---
[0]: https://aws.amazon.com/blogs/aws/aws-ground-station-ingest-a...
https://aws.amazon.com/snowmobile/
> AWS Snowmobile is an Exabyte-scale data transfer service used to move extremely large amounts of data to AWS. You can transfer up to 100PB per Snowmobile, a 45-foot long ruggedized shipping container, pulled by a semi-trailer truck. (...)
(Ended up doing it from university, where I had symmetric 100mbit in my dorm room).
(I work at Google, don't work on that product.)
You'll get supplied (at least) two SSDs.
With instructions for how to use in both Windows and Linux.
Unfortunately even though it was "GA", it appears that they never really actually tested using it in Linux.
I submitted (and they were merged) a number of documentation bugfixes related to Linux.
Two firmware updates later, one bricked disk, one which failed to verify the copied data -- and 9 months of time all down the drain.
This reason is why I will never use Azure. It wasn't the bugs and device failures that was the problem. Just the sheer work in having to teach Azures' support staff about their own product (after fighting to get them to record the support case -- you normally can't raise one if you don't pay).
Why did I pick Azure for this?
Because (at the time) both GCP and AWS catered for 100Gb+ volumes. And we were (and remain) around 50Gb.
I haven't re-evaluated to see if either GCP or AWS have better options now.
In particular if you have ~100PB of data to move and you are in a location that can be reached by a 45-foot long shipping container on a truck with access to the ~350KW of power it takes to run Snowmobile, you're clearly not somewhere _completely_ inaccessible. Given that 100PB of data will cost you $400k/mo in storage costs on AWS Glacier (before the discounts that you'll obviously negotiate for), even relatively remote locations become "accessible" for 100 Gbps+ fiber or microwave connectivity, and _very_ remote locations for tens of Gbps. The Snowmobile itself is only 1 Tb/s, so if you think you're going to save time this work, consider how long it takes to move it to you and then move it to an AWS facility versus the time it takes to fill it.
I don't get where this is the right call for _any_ customers, even as a one-off. I'd love it if someone from AWS could tell me where my math is off on this.
Say I have datacentre in london, Sure I could plumb in 4 100gig lines. But they are typically on a year lease and have a long lead time.
Plus, once its on the datatruck its AWS's problem.
Snowmobile was built because a pre-sales engineer sarcastically said backing up a truck full of hard drives to a customers datacenter would be the fastest way to import X PB of data. It's probably loading from a tape silo and spent 18 months at the customer site.
I’m guessing:
1. You’ve never priced out said circuits before
2. Never seen the lead times and minimum contract periods on them
3. Don’t realize in general how hard it is to actually max out circuits like that.
Shipping / freight company is generally still a preferred solution to moving very very large amounts of data even in 2020. Your own employer still ships large datasets that way too. Here’s a link from 2007:
https://royal.pingdom.com/fedex-still-faster-than-the-intern...
But from contacts I know inside Google, it’s still done regularly.
If I had 1-10 PB to move I could totally see most people using FedEx to ship JBODs around. For small transfers it makes sense, and we also have a product for this. Internally I'd use our WAN for those, which is where this now starts to make sense: Amazon does not have anywhere near the global WAN capacity that we do, nor so far have they had a good reason to have that capacity.
If you've got the global capacity to allow a customer to peer to your nearest location (and your nearest location likely isn't too far away for most of the world), fiber makes sense for large (~EB-scale, which I assume anyone with 100PB+ is well on their way to 1EB+) amounts of data. We have a product for these peerings (primarily for customers in colos): https://cloud.google.com/interconnect/docs/concepts/dedicate...
Also, when I go to: https://www.infrastructure.aws/
(annoyingly I can't link to the network) it says 100Gbps of WAN capacity around the AWS global network.
I did a quick search and wasn't able to find what it is for GCP -- do you have a link handy?
https://cloud.google.com/transfer-appliance
Also, if you want to know an extreme edge case that can't (currently) be done any other way, consider the astronomical observatories at the South Pole.
Antarctica was the only place that came to mind, but I wasn't sure about the costs of getting a shipping container in / out.
Those are big fucking planes, so maybe you can?
Most of the intro decisions around moving to the cloud happen before Amazon is ever involved in the sales cycle. There are some managerial accountants and IT people getting involved to evaluate options in a process called "Evaluation of Alternatives." At some point, Amazon probably started hearing that the IT people were saying "we can't possibly move all of that data to the cloud, it would swamp our network or take five years just to finish the network transfer."
Enter Snowmobile, which cuts that conversation thread off at the knees. Amazon can go to a Fortune 100 company that is evaluating a move and honestly claim that they are prepared to move exabytes of data, physically, into the cloud. And it's not some premium feature that they're going to get charged bajillions for, it's a stock feature of AWS. (Even if it costs a lot of money)
Snowmobile isn't targeted at the average customer, it's targeted specifically at the accountants, IT architects, and management consultants evaluating the decision to move all of Fortune 100 Company X from on-prem data centers into 100% AWS. One extra hug from Amazon to let the most risk-averse person know that they have it covered, and would they please go ahead and write their 9-figure check to AWS.
Unless you literally do everything by hand (which is a niche, but a tiny one), the cubesat is still going to cost at least 10-50k and the launch 100-400k. In the grand scheme of things, it's not the huge improvement that the rest of AWS infrastructure was.
I think this could be a huge deal for students and academics though. It's not uncommon for companies to give away free secondary/tertiary slots (at least in my experience pre-SpaceX) because the logistics infrastructure is expensive to keep around and they can write off costs that they normally would have to eat. Even if this only shaves 10% off the cost of a sat project, that's a lot of extra money for aerospace clusters like LA, Cal Poly, MIT, etc. and might be enough to start hitting more economies of scale leading to a snowball of development.
Between university machine shops and subsidized labor, Ground Station, and low cost launches once SpaceX volume increases, it might become feasible for student groups to pull off launches for $50-100k total which would be well within the realm of rotary clubs, small-to-medium educational grants, and university budgets.
You were always able to just rent servers running in someone else's data center.
AWS as we know it launched in 2006, [1] is Hetzner's homepage from 2001 offering dedicated servers for $125/month + $125 setup fee. By 2005 [2] you can get a AMD Athlon XP 3000+ with 1 GB RAM and 350GB traffic for 39€/month.
1: https://web.archive.org/web/20010813053224/http://www.hetzne...
2: https://web.archive.org/web/20050507034045/http://www.hetzne...
What’s the target customer profile of this service exactly?
What's the threat model for a ground station? Interception? Sabotage? Hardware theft? Can you even sell these things on eBay?
Satellites and their attendant infrastructure cost billions of dollars to deploy and maintain. They are incredibly valuable targets, making it worth an attacker's while to penetrate them. This is way beyond simple vandalism or ransomware.
https://en.wikipedia.org/wiki/Captain_Midnight_broadcast_sig...
Not to mention just plain destruction of bringing down a fleet of satellites.
The rule at Raytheon was that Lockheed got the easy end of the job — they just had to design, build, and launch the new fleet. It was Raytheon who got the really hard end of the job, because they had to be able to seamlessly manage both the new and old fleets.
I would submit that designing, building, and operating the ground control systems remains the hardest part of the job, even if you don’t have a legacy fleet of satellites that you have to manage on top of the new fleet.
Think about it — when you’re doing the operations side of the house, you have to be perfect, all the time. That one time you aren’t perfect and your opsec fails, you lose. The other guys just have to be right once, and they can keep trying and trying and trying indefinitely, until they get that one time they win. That’s definitely the harder job.
The core competency of a business you describe is building, launching and maintaining satellites. On-ground network infrastructure, computing hardware, data processing, machine learning etc. is something AWS is a lot more familiar with.
S-band and beyond will cost you more, but a fully-featured VHF/UHF/S-band one from a proper vendor will be under $100K.
X-band, yeah... But not that many cubesats have X-band transceivers anyway.
What the Amazon website doesn't cover is:
- download guarantee. They rent you the antenna, they don't commit to a successful reception (and consequent refund if it fails)
- link status report (needed for a positive confirmation of successful reception.) This is basically a series of SNR measurements
- competition with other users of the same antenna: first-come first served? Maybe your spacecraft needs more storage to save the downlink data if the Amazon antenna is busy.
And of course they don't talk about the competition.
And it's normally better to just have more redundancy instead of higher individual uptime, at least as long as space, weight and power are not an issue (i.e., on the ground).