Indexeren

Why Every Neocloud Deployment Needs a Persistent Object Storage That Isn't AWS

You signed CoreWeave or Lambda for the GPU economics. Six months later your AWS bill hasn't moved because the training data is still on S3. A 50TB dataset read four times a month is roughly $13,800 in egress alone, eating the GPU savings line by line. Compute-agnostic storage is the structural fix, not a partner-network exemption.

Stefaan Vervaet

You signed the CoreWeave contract. The GPU rate dropped by half against your old AWS quote, procurement signed off, and six months later you're staring at an AWS invoice that didn't move. The compute cost dropped. The data layer didn't. Before you read the diagnosis, calculate your egress exposure, the number is usually bigger than the GPU savings you just booked. Sign up for a free trial. No commitment, no migration.

That gap is the architecture decision nobody walks through during a neocloud RFP. The decision isn't where the GPUs live. It's where the persistent training data lives. For most teams that moved compute in 2024–2025, the answer is still "S3, in us-east-1, and we pay for every byte that crosses out of AWS."

‍

The architecture decision nobody mentions

A neocloud contract, CoreWeave, Lambda, Crusoe, Baseten, is a GPU contract. The provider sells GPU-hours, fabric networking, and scratch storage. That's the deliverable.

Persistent storage is sometimes in the contract: CoreWeave's AI Object Storage prices at $0.06/GB/month Hot, $0.03 Warm, $0.015 Cold, with no egress or request fees. But pick the neocloud's own storage and you're locked to that neocloud. The next GPU contract, different generation, better price, means moving the data again.

So what teams do instead is leave the training data on AWS S3 and point neocloud-hosted jobs at it across the public internet. The GPU lives in one cloud, the data in another, and every training epoch reads multi-terabyte datasets across the boundary. That's where the AWS invoice doesn't drop.

‍

The cost of leaving data on S3

The compute migration is fast, repoint the training script, swap the credentials, restart. The data migration gets deferred to "after the next training run," and eighteen months later it still hasn't happened.

Here's what the deferral costs. A team reading a 50TB dataset out of S3 four times a month moves 200TB of egress:

9.9TB × $0.09 + 40TB × $0.085 + 100TB × $0.07 + 50.1TB × $0.05 ≈ $13,800/month in egress alone

That's before the first GPU-hour bill arrives. At training intensity any serious AI team hits, the egress line passes five figures fast, and it eats exactly the margin the compute migration was supposed to deliver.

‍

What "compute-agnostic" actually means, and how Akave delivers it

Vendors say "compute-agnostic storage." Most readers hear "S3-compatible" and stop there. They aren't the same thing.

S3 compatibility means the API surface matches, a boto3 client points at a new endpoint and the calls work. Necessary, not sufficient. Compute-agnostic means the read path doesn't penalize you for putting compute somewhere other than the storage vendor's own region. The penalty in the S3 model is egress: free inside AWS, billed the moment a read leaves for a non-AWS network like a neocloud.

This is where Akave Cloud fits the stack. Akave is S3-compatible, the training script, the boto3 client, and the Snowflake external volume don't change, because the interface is S3. What's different sits below the API: data is sharded across independent storage operators, so reads to a neocloud GPU cluster don't traverse a hyperscaler egress boundary. There's no AWS region for the data to leave. Zero-egress isn't marketing layered on a hyperscaler architecture, it's a structural property of how the operators connect.

For a team that wants to run CoreWeave this week and Lambda next week, keeping the data layer on a compute-agnostic store makes switching GPU providers operational, not architectural. The training data doesn't move. Only the job assignment does.

Test the drop-in claim against one training job. Start a free trial, generate S3-compatible credentials, point one epoch at the Akave endpoint, and compare the egress line on the next invoice.

‍

Why S3 compatibility alone isn't enough

A vendor can advertise S3 compatibility and still charge for the read path. The details vary, and they matter:

Provider	Storage Rate	Read-Path Catch
Wasabi	$7.99 / TB / month (from July 1, 2026)	No per-GB egress fee, but a 1:1 stored-to-downloaded cap. Heavy-read training workloads can hit usage limits.
Backblaze B2	$6.95 / TB / month (from May 1, 2026)	Free egress up to 3× stored data, then $0.01 / GB. A 50TB store read at 4× costs approximately $500/month in overage fees.
Cloudflare R2	Standard rates	No egress in any direction, but data residency and auditability may require additional evaluation for compliance-sensitive workloads.
Akave Cloud	S3-compatible	No egress charge on reads leaving the network. Structural pricing model rather than a partner-network exemption.

Partner-network deals (Backblaze's Cloudflare integrations, for example) can close the egress gap for specific compute targets, CoreWeave is not on the published Bandwidth Alliance list, so check yours before sizing the line. A storage layer that's free to one neocloud but billed to another keeps the lock-in question alive. The real question isn't "does this look like S3?" It's "what's the read path for my compute provider, and does the storage layer charge for it?"

‍

The migration path

Moving from S3 to a compute-agnostic store is a standard S3-to-S3 migration. The mechanics are well understood; the sequencing is the work:

Mirror the active training datasets from S3 to the new store. Budget the mirror window, it's the longest single step and depends on dataset size and bandwidth.
Repoint the training jobs: swap the endpoint and credentials, then validate that runs produce identical results.
Move new checkpoint and artifact writes to the new store. Old ones age out or migrate in a cleanup batch.
Cut over the read path, keeping the S3 buckets read-only for 30 days for rollback.
Retire the old buckets after the rollback window. The egress line on training reads drops to zero.

Most teams do steps 1–3 inside a quarter; the cutover itself is a configuration change measured in hours. For standard S3 object-storage patterns the endpoint and credential swap is often the only application-layer change, but teams using Lambda triggers, KMS-managed keys, or custom IAM logic need separate planning.

‍

Looking ahead: the data layer becomes the dominant cost

The 2024–2025 story was that GPU price-per-hour was the dominant cost. That held while compute was scarce. In 2026 the picture is shifting: neocloud competition has compressed GPU rates, and the line item with the most variance is no longer compute, it's the data layer. Egress patterns, retrieval-tier transitions, cross-region replication, and the audit overhead that lands on storage rather than compute.

Teams that keep training data on S3 while running compute on a neocloud will spend the next eighteen months watching the data layer eat their compute savings. Teams that move both layers together get the full neocloud economics, and the freedom to switch GPU providers without re-architecting storage every time. The architecture decision is the procurement decision.

‍

FAQ

Why is my AWS bill still high after moving compute to CoreWeave or Lambda?

The training data is still on AWS S3. Every read from S3 to a neocloud GPU cluster crosses an AWS egress boundary and gets billed at AWS's egress rate. Compute moved; the data didn't, so the egress line stays roughly the same.

Can I just use the neocloud's own object storage?

You can, but you'll be locked to that neocloud. The next time you move compute to a different GPU provider for capacity, generation, or pricing, you'll pay egress on the data again, this time out of the neocloud you previously chose. A compute-agnostic store is the structural fix.

What's the difference between S3 compatibility and zero-egress?

S3 compatibility means the API surface matches, so boto3 clients work unchanged. Zero-egress is a separate property: the storage layer doesn't charge for reads leaving its network. A vendor can be S3-compatible and still charge egress, many are. Neocloud architectures need both.

If a partner-network deal already gives me free egress, why change architecture?

Partner exemptions are tied to specific compute targets. The moment you move to a neocloud that isn't on the partner list, the egress charge returns. Akave's zero-egress is structural, it isn't conditional on which neocloud you point at.

How long does the migration from S3 actually take?

Most teams complete it inside a quarter. The mirror copy is the longest step and scales with dataset size and bandwidth. The cutover, repointing jobs at the new endpoint, is a configuration change measured in hours, plus 1–2 weeks of validation against existing results.

How do I start without committing to anything?

Generate S3-compatible credentials, point a single training job or eval run at the Akave endpoint, and compare the next invoice. No migration, no contract.

Moderne infra. Verifieerbaar door ontwerp

Whether you're scaling your AI infrastructure, handling sensitive records, or modernizing your cloud stack, Akave Cloud is ready to plug in. It feels familiar, but works fundamentally better.

Probeer zonder risico

Neem contact met ons op

Bekijk onze documenten ›