Cloud GPU Storage That Moves Across Providers: What Actually Makes State Portable

Look at how a price-conscious GPU renter actually works and you will see the same tell everywhere: before they even start a job, they have already written the script that will move their state off the box. A cron that rsyncs checkpoints to S3 every fifteen minutes. A 200-line setup file that re-pulls models from Hugging Face. An rclone config pointed at a bucket in a neutral cloud. I build the infrastructure layer under rented GPU boxes rather than the models on top, and after a week reading r/LocalLLaMA, r/MachineLearning, and a stack of provider docs, the pattern is hard to miss. People are hand-building cloud GPU storage that moves across providers, one duct-taped script at a time, because the storage the providers sell them does not move at all. This post is about why it doesn't, what moving your state actually costs, and what portable storage really requires.

TL;DR: A cloud GPU network volume solves persistence but not portability. It is attached at one provider's datacenter fabric, so it is physically region-locked, and it keeps billing while the GPU is off. The workaround, syncing your state to object storage, does move across providers, but you pay egress to move it and it only carries your data, not your environment. Storage that genuinely moves needs three things: no region pin, a cheap or free path out, and a capture of the whole box rather than just the data volume.

Why can't a cloud GPU volume just follow you to another provider?

Because a network volume is a block device attached inside one provider's datacenter, and block storage is bound to the compute fabric it lives on. RunPod's own documentation is explicit: attaching a volume "constrains worker deployments to that volume's datacenter," and "data does not sync automatically between volumes" (RunPod network volumes docs). The lock is physical, not a policy you can appeal.

This is the part most people miss when they first shop for persistence. A volume feels like a hard drive you own, but it is really a slice of one region's storage array wired to one region's GPUs over a low-latency backplane. That backplane is exactly what makes it fast, and exactly what makes it un-portable. The moment the cheapest H100 this hour is in a different region or a different provider, your volume cannot come with you. It stays where it was born, still billing at roughly $0.10/GB per month whether or not a GPU is attached, which is the second half of the same trap. You are paying rent on storage you can neither use nor move. If you want the full ranked breakdown of ways around that, I wrote a companion piece on the network volume alternatives worth considering; here I want to stay on the mechanics of why moving is hard in the first place.

What it actually costs to move your state

Say you accept the region lock and decide to move state the only way you can: copy it out to neutral object storage, then pull it down onto the next box. Now you meet the cost nobody quotes on the pricing page. Egress.

Egress is the fee for data leaving a provider's network, and the range is wild. Across a comparison of dozens of clouds, outbound transfer runs from $0 all the way past $0.50/GB, a spread of more than 100x between the cheapest and most expensive (GPUPerHour egress reference). The hyperscalers sit at the painful end, roughly $0.074 to $0.12 per gigabyte after a small free tier. That sounds like rounding error until you remember what you are moving. Model libraries are measured in tens to hundreds of gigabytes. On AWS, moving 1TB of checkpoints out costs about $90 on top of the GPU bill, and a team pushing 10TB a month is quietly adding $900 a month just to relocate their own files (Thunder Compute's egress writeup lays out the same math).

The reason this fee exists is not the cost of bandwidth. It is a leash. Providers charge nothing to bring data in and a premium to take it out, an asymmetry the industry openly calls bandwidth lock-in. Free ingress removes friction from onboarding; egress makes leaving expensive enough that you think twice. So the very act of making your storage portable, copying it somewhere neutral, is the act the pricing model is designed to tax.

There is a real escape here, and it is worth naming because it changes the calculus. Most GPU-focused neoclouds have dropped egress entirely. Lambda, RunPod, Vast.ai, and Vultr fold outbound transfer into the instance rate or charge nothing for it (GPU cloud egress comparison, Lyceum). Roughly half the GPU clouds in that survey charge zero. That is the structural reason a price-shopping renter gravitates to neoclouds and away from hyperscalers: on a free-egress provider, moving your state costs time but not money. On a hyperscaler, it costs both. Either way, "portable" is doing a lot of quiet work, because someone is paying the transfer, in dollars or in minutes.

Moving your data isn't the same as moving your environment

Here is the deeper problem, and it is the one the object-storage workaround never solves no matter how cheap the egress gets. When you rsync to a bucket, you move your data. You do not move your environment. And on a GPU box, the environment is the expensive part.

Think about what actually has to be true for a fresh box to run your job. The models need to be present, yes, and those live cleanly in a bucket. But so does the virtualenv with its resolved dependency tree, the custom nodes pinned to the exact commits that don't throw red errors, the system packages, the CUDA toolkit that matches your driver, and a dozen config files at their original paths. None of that survives a bucket sync in usable form. You can copy a requirements.txt, but re-resolving it on the new box re-runs the whole fragile install, often against a different driver, and half the time it silently pulls a different CUDA build than the one you tested on. One practitioner who moved workloads to chase price put the switching motion plainly:

"On Lambda, I was spending around $1,400/month for a mix of A100 and H100 time, averaging about 80 GPU-hours per week. When I moved the same workload to vast.ai, my monthly bill dropped to about $590. Same jobs. Same results." @velinxs, GPU cloud pricing writeup on Medium

"Same jobs, same results" is the whole point, and it is also the hardest thing to get back. The bill dropped because the work moved. The work only moves cleanly if the entire environment moves with it, and a bucket of model files is not an environment. This is why the manual-sync crowd still burns 30 to 60 minutes rebuilding on every cold start even when their data restored in seconds. They moved layer one and left layers two and three behind. I walked through this three-layer split in more detail in the guide on keeping a persistent environment when you switch providers, and it is the crux of why "just use object storage" is a half-answer.

What does storage that actually moves across providers require?

Three properties, and a model is only portable if it has all three. It must be provider-neutral at rest, so nothing pins it to one datacenter. It must be cheap or free to move, so egress does not tax every hop. And it must capture the environment, not just the data, so a restore rebuilds the working machine.

Measure the common options against those three and the gaps are obvious:

The volume fails property one. The object-storage sync clears one and two but fails three, which is the layer that actually costs you the hour. The baked image gets closer but freezes at build time and drifts the second you tweak a node on a live box. The only model that clears all three is snapshotting the whole box, the filesystem, the venv, the pinned commits, the models, the CUDA context, so that a restore puts the machine back exactly as it was on whatever provider is cheapest and in stock. Practitioners already treat multi-cloud as a survival strategy rather than an optimization, scanning five to ten providers before a job (dstack's state-of-cloud-GPU report). Portable full-box state is what makes that scan cheap to act on, because switching stops meaning rebuilding.

What I'd actually do

If you never leave one provider, a right-sized volume is fine and you can stop reading. If you hop to chase price, which is the whole reason to use rented GPUs bursty, then treat storage portability as three separate questions and answer each honestly. Keep your live models on a volume inside a working session so you are not re-downloading mid-project, but never treat that volume as your source of truth, because it cannot leave the building. Prefer free-egress neoclouds so a move costs minutes instead of dollars. And stop pretending a bucket of model files is your environment, because the reinstall tax is the part that hurts, and object storage does not touch it.

The layer that closes all three at once is a portable snapshot of the whole box. That is the gap we are building ogre to fill, in the open: an open-source tool that snapshots a full GPU box and restores it on whatever provider you rent next, so your state is portable by design instead of region-locked by default. It is early, and we are proving the cross-provider restore in public rather than asking you to take the claim on faith, so treat it as a direction, not a finished pitch. The principle underneath it is simple and worth saying plainly. A network volume was never really portable storage. It was storage with a fence around it and a meter running. State should follow you, and it should cost close to nothing to move.

About the author

I'm Ansh, and I work on the infrastructure layer at Aquanode, the plumbing under rented GPU boxes rather than the models on top. I have spent the last stretch deep in how CLI-native GPU renters actually work, reading the provider docs and the r/LocalLLaMA threads where the region lock and the egress bill get complained about, and building the snapshot layer that would make state genuinely portable. I would rather move a GPU box in one command than rsync one back together by hand.

Sources

• RunPod network volumes documentation. Volumes constrain deployments to one datacenter; data does not sync automatically between volumes; storage bills while the pod is stopped.
• GPUPerHour data egress reference. Egress ranges from $0 to over $0.50/GB across dozens of providers, a 100x-plus spread; hyperscalers charge roughly $0.074 to $0.12/GB.
• Thunder Compute: understanding egress fees on cloud GPUs. Moving 1TB out of AWS costs about $90; 10TB a month adds roughly $900; free ingress plus charged egress is bandwidth lock-in.
• Lyceum: egress fees GPU cloud comparison. Roughly half of GPU clouds charge zero egress; Lambda, RunPod, Vast.ai, and Vultr fold transfer into the instance rate.
• dstack: the state of cloud GPUs in 2025. Teams treat multi-cloud as a survival strategy, scanning five to ten providers before a job.
• @velinxs, GPU cloud pricing writeup. Same workload moved from Lambda to Vast.ai cut the monthly bill from about $1,400 to about $590.