News: 1584606548

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

NASA to launch 247 petabytes of data into AWS – but forgot about eye-watering cloudy egress costs before lift-off

(2020/03/19)


NASA needs 215 more petabytes of storage by the year 2025, and expects Amazon Web Services to provide the bulk of that capacity. However, the space agency didn’t realize this would cost it plenty in cloud egress charges. As in, it will have to pay as scientists download its data.

That omission alone has left NASA's cloud strategy pointing at the ground rather than at the heavens.

The data in question will come from NASA’s Earth Science Data and Information System ( [1]ESDIS ) program, which collects information from the many missions that observe our planet. NASA makes those readings available through the Earth Observing System Data and Information System ( [2]EOSDIS ).

To store all the data and run EOSDIS, NASA operates a dozen Distributed Active Archive Centers (DAACs) that provide pleasing redundancy. But NASA is tired of managing all that infrastructure, so in 2019, it picked AWS to host it all, and started migrating its records to the Amazon cloud as part of a project dubbed [3]Earthdata Cloud . The first cut-over from on-premises storage to the cloud was planned for Q1 2020, with more to follow. The agency expects to transfer data off-premises for years to come.

NASA also knows that a torrent of petabytes is on the way. Some 15 imminent missions, such as the NASA-ISRO Synthetic Aperture Radar ( [4]NISAR ) and the Surface Water and Ocean Topography ( [5]SWOT ) satellites, are predicted to deliver more than 100 terabytes a day of data. We mention SWOT and NISAR because they’ll be the first missions to dump data directly into Earthdata Cloud.

The agency therefore projects that by 2025 it will have 247 petabytes to handle, rather more than the 32 it currently wrangles.

NASA thinks this is all a great idea: in its documentation for the migration, it said:

Researchers and commercial users of NASA Earth Science data will have increased opportunity to access and process large quantities of data quickly, allowing new types of research and analysis. Data that was previously geographically dispersed will now be accessible via the cloud, saving time and resources.

And it will – if NASA can afford to operate it.

And that’s a live question because a March [6]audit report [PDF] from NASA's Inspector General noticed EOSDIS hadn’t properly modeled what data egress charges would do to its cloudy plan.

“Specifically, the agency faces the possibility of substantial cost increases for data egress from the cloud,” the Inspector General’s Office wrote, explaining that today NASA doesn’t incur extra costs when users access data from its DAACs. “However, when end users download data from Earthdata Cloud, the agency, not the user, will be charged every time data is egressed.

“That means EDSIS wearing cloud egress costs. Ultimately, ESDIS will be responsible for both cloud costs, including egress charges, and the costs to operate the 12 DAACS.”

Scientific data may become less available to end users if NASA imposes limitations on the amount of data egress for cost control reasons

And to make matters worse, NASA “has not yet determined which data sets will transition to Earthdata Cloud nor has it developed cost models based on operational experience and metrics for usage and egress.

"As a result, current cost projections may be lower than what will actually be necessary to cover future expenses and cloud adoption may become more expensive and difficult to manage.”

There’s more. The watchdog concluded: “Collectively, this presents potential risks that scientific data may become less available to end users if NASA imposes limitations on the amount of data egress for cost control reasons.”

And to put a cherry on top, the report found the project's organizers didn't consult widely enough, didn't follow [7]NIST data integrity standards, and didn't look for savings properly during internal reviews, in part because half of the review team worked on the project itself.

The result is three recommendations from the auditors:

Once NISAR and SWOT are operational and providing sufficient data, complete an independent analysis to determine the long-term financial sustainability of supporting the cloud migration and operation while also maintaining the current DAAC footprint.

Incorporate in appropriate agency guidance language specifying coordination with ESDIS and OCIO early in a mission’s life cycle during data management plan development.

Ensure all applicable information types are considered during DAAC categorization, that appropriate premises are used when determining impact levels, and that the appropriate categorization procedures are standardized.

At least NASA seems to have bagged a good deal from AWS: The Register used Amazon’s [8]cloudy cost calculator to tot up the cost of storing 247PB in the cloud giant’s S3 service. The promised pay-as-you-go price for us on the street was a staggering $5,439,526.92 per month, not taking into account the free tier discount of 12 cents. The audit, meanwhile, suggests an increased cloud spend of around $30m a year by 2025, on top of NASA’s $65m-per-year deal with AWS.

The existence of data egress costs are not obscure nor arcane knowledge. Which left The Register wondering how an agency capable of sending stuff into orbit or making marvelously long-lived Mars rovers could also make such a dumb mistake.

It turns out NASA makes plenty: your humble vulture found this story after looking into Tuesday’s [9]audit of the agency's development work on its mobile launchers – the colossal vehicles designed to assemble, transport, and launch SLS and Orion rockets and capsules.

That audit found the project “has greatly exceeded its cost and schedule targets in developing [10]ML-1 . As of January 2020, modification of ML-1 to accommodate the SLS has cost $693 million — $308 million more than the agency's March 2014 budget estimate — and is running more than 3 years behind schedule.” ®



[1] https://earthdata.nasa.gov/esdis

[2] https://earthdata.nasa.gov/eosdis

[3] https://earthdata.nasa.gov/eosdis/cloud-evolution

[4] https://nisar.jpl.nasa.gov/

[5] https://swot.jpl.nasa.gov/

[6] https://www.oversight.gov/sites/default/files/oig-reports/IG-20-011.pdf

[7] https://www.nist.gov/about-nist

[8] https://calculator.s3.amazonaws.com/index.html

[9] https://www.oversight.gov/report/nasa/audit-nasas-development-its-mobile-launchers

[10] https://en.wikipedia.org/wiki/Mobile_Launcher_Platform_1

Just wondering

Pascal Monett

I wonder if anybody at NASA made a comparative cost evaluation of how much it would be for NASA to upgrade its DAACs to meet the 240+ PB storage mark vs properly costing AWS to get the job done.

With the download costs added to the mix, I really wonder if it wouldn't be better to go and upgrade the DAACs.

Re: Just wondering

A Non e-mouse

I've seen numerous reports which say that cloud is great for bursty/on-demand workloads, but for a constant load, on-prem usually works out cheaper.

Re: Just wondering

lglethal

But, but, CLOUD!!!

Re: Just wondering

Wellyboot

Clouds only look good from a distance!

Re: Just wondering

BebopWeBop

Yes, frequently white fluffy and inherently cuddly.

Re: Just wondering

DwarfPants

I have been in a cloud it was cold and wet.

What if the Cloud also catches Corona?

SJA

We all know that computers are at risk from viruses/ii... what if corona spreads into the cyberspace? Mutations are not uncommon among viruses/ii

Re: What if the Cloud also catches Corona?

DavCrav

"Mutations are not uncommon among viruses/ii"

It's viruses. Viri are men. (Virus in Latin means venom or slimy liquid, and is neuter. It didn't have a plural in Latin, but if it did, it would have been vira.)

Re: What if the Cloud also catches Corona?

KarMann

Actually, in classical Latin, it's a fourth declension noun, not the usual second declension, so the plural would have been 'vīrūs'. But, in checking my reply, I did find that there's a Neo-Latin form which does use standard second declension inflexions outside of the nominative/accusative, so then it's 'vīra', as you said. OK, I'll allow it, with that Neo-Latin caveat .

Re: What if the Cloud also catches Corona?

Jonathon Desmond

Romani ite domum

Re: What if the Cloud also catches Corona?

KarMann

Actually, in classical Latin, it's 'Romanes eunt domus.'

Re: What if the Cloud also catches Corona?

BebopWeBop

Ahh - a better and more educated class of pedant here

Re: What if the Cloud also catches Corona?

Andy The Hat

Hang on, my red-lead brush is running out ...

Now, if can you conjugate that verb again please ...

Cloud costing...

2+2=5

Cloud costing ... if only it were as easy as rocket science...

Hang on...

Steve K

I may well be missing something here but:

* If scientists are going to download so much data locally that went to the cloud first, then surely that data should have gone directly to a NASA data centre first anyway (either for use or for pre-processing prior to AWS ingress)

* They still have to store that data locally (and back it up since you don't want to incur the egress charges again if it gets lost), so you still need some kind of significant storage capability within NASA

* This could be mitigated by pre-processing/sifting data sets in AWS (incurring CPU/GPU compute charges of course) - assuming that the workloads don't require specialised hardware unavailable in AWS - so that there is less to download. You still have to store that reduced data set locally though

* Assuming that there is no specialised hardware required then can they sidestep this by working on the data in the cloud entirely (i.e. no need to download most of the data) using cloud compute/virtual workstations? I imagine that the CPU/GPU compute charges would be eye-watering BUT they would have burst capacity on demand (although they would soon learn about marginal costs of instances spinning all year long...)

Re: Hang on...

diodesign

"surely that data should have gone directly to a NASA data centre first anyway"

That's the rub. NASA didn't want to run its own data centers: it opted to upload all the stuff gradually to the cloud. According to the audit report, it didn't realize that people can't download this stuff "for free" from the cloud – someone has to pay for the bandwidth. NASA, in this case.

C.

Re: Hang on...

Anonymous Coward

"“Collectively, this presents potential risks that scientific data may become less available to end users if NASA imposes limitations on the amount of data egress for cost control reasons.”"

And that's why cloud deals shouldn't be decided only by freaking accountants who don't have a clue data is going both ways in whatever pattern the business needs it to.

They failed to understand that and that's what it is gonna costs NASA.

Next time, NASA, understand IT pros are useful ...

Just charge the users

Blergh

Ok the users might not be too happy to be incurring a new cost but presumably spread out among all the users it might not be so expensive for each of them. This is assuming ti is possible to set up a system to pass on these costs.

Re: Just charge the users

Hawkeye Pierce

Assuming that we're talking about data held in AWS S3 buckets then that already supports "Requester Pays" buckets. Yes it means that the requester has to have an AWS account but that's not unreasonable.

Re: Just charge the users

A Non e-mouse

Isn't there some rule in America that all research data paid for by the tax payer has to be freely available?

Re: Just charge the users

Anonymous Coward

It is indeed possible to charge users by passing on the cost to them, but they need to have an AWS account in order for the billing etc to be handled.

Someone got a good kickback

tallenglish

This cloud business seems very similar to the energy ponzi scheme that brought down Enron, buy cheap and sell at extortionate rates leaving people in Calefornia with large bills and power outages.

I guess with AWS, this will be high rates to get your data back and lost data because do we really think amazon will have redundancy to keep data over multiple DC securely. Just look how they treat the staff, cheap and nasty, so why do we think the staff will care much about the data they care for.

Re: Someone got a good kickback

Cederic

Yes, we do really think Amazon will have redundancy to keep data over multiple DC securely.

Mainly because there's plenty of evidence that they already do.

So no, no lost data. How do Amazon pay for this remarkable service? By charging for things like data transfer out of their cloud. It's almost as though it's a transparently priced self sustaining model that's been in operation for a couple of decades.

At that scale

John Robson

You're already going to be getting most of the benefits of scale associated with being "cloudy" anyway, even if you run it in house.

What's the annual storage budget for that, I bet most of use could plan some hardware (including power costs and disk replacements) that would cope for 5 years and pay a healthy salary for a (small) team to look after it.

BebopWeBop

So a decent accountant might have (been of) value after all

Outsourcing 101

Jason Bloomberg

"Oooh; look at all the savings we can make!" - With hardly a thought given to the hidden costs and downsides.

Of course, in most cases, the downsides are borne by the users so they can usually be disregarded as they rub their hands with glee.

The one with the convincing advert in the pocket.

Insert coin for new game