Most GPU marketplaces give you a middle option between "running and billing" and "gone": a stop state that keeps the disk and drops the compute charge. Lambda Cloud doesn't have one. Its own docs say it plainly: "at the moment, Lambda Cloud instances can only be launched, restarted, or terminated" (Lambda, Creating and Managing Instances). I build the infrastructure layer under rented GPU boxes, and that single missing button changes the whole storage conversation for Lambda relative to a provider like RunPod, where stop-vs-terminate is the entire mental model.
TL;DR: There's no pause on a Lambda Cloud on-demand instance — you're either running and paying for the GPU, or you've terminated it and the local disk is gone. Lambda's answer to persistence is a separate product, Filesystems: regional network storage you attach at launch, priced per GiB per month, that survives an instance being terminated. The catch is the same one every regional volume has — it's pinned to its region and "cannot currently be transferred between regions."
Why there's no stop, and what that means for your disk
Lambda's own recommendation for surviving a terminate leans on that gap directly: "to preserve state, we recommend using Docker to containerize your environment and performing regular backups of important data" (Lambda, Creating and Managing Instances). Read between those two clauses and the implication is that whatever's on the instance's local disk when you terminate it does not survive — the docs don't spell out the local-disk fate explicitly, but the entire recommendation only makes sense if it doesn't.
Billing follows the same binary. Lambda's billing docs state instances "are billed for as long as they're running, regardless if they're actively being used," and for on-demand specifically, "billing begins the moment you launch an instance and the instance passes health checks, and ends the moment you terminate the instance" (Lambda, Billing Overview). There's no stopped-but-preserved state to reason about, because that state doesn't exist. You're either paying for the GPU, or the instance — and by implication, its local disk — no longer exists.
What a Filesystem actually is
Lambda's persistent option lives outside the instance entirely. A filesystem is "a high-capacity regional file store you can attach to your instance to store datasets and back up system state" (Lambda, Filesystems). Capacity is generous in most regions — up to 8 EB — with one documented exception: Texas caps at 10 TB. Pricing isn't published as a fixed platform rate in the docs (the billing page's own example, "$0.20 per GiB per month," is explicitly flagged as illustrative and not current pricing — check Lambda's billing page for the live number before budgeting against it).
Two constraints matter more than the price, though. First, attachment is launch-time only: "you can't attach filesystems to an instance or 1-Click Cluster after the instance or 1CC has been created" (Lambda, Filesystems). Decide you want persistent storage after the fact, and the fix is a new instance, not a config change on the running one. Second, and this is the RunPod-network-volume pattern again with a different vendor's name on it: "filesystems must reside in the same region as the instance or cluster" for attachment, and "filesystems cannot currently be transferred between regions." Your persistent storage is exactly as portable as the region it was created in, which is to say: not at all.
The billing trap that's specific to Lambda
Deleting the instance doesn't clear the meter if a filesystem is still attached. Lambda's docs are direct about this: "if you delete an instance but not its associated filesystem, you'll continue to be billed for the filesystem" (Lambda, Filesystems). That's the standard shape of network-volume billing — the storage exists independently of the compute, so deleting the compute alone doesn't stop the meter — but it lands harder on Lambda specifically because there's no stop state to fall back into while you decide what to do with the data. You go straight from "instance running" to "instance gone, filesystem still billing," with no pause in between to think it over.
What this actually means for your workflow
Lambda's model rewards two different disciplines than RunPod's does, because the failure modes are different. There's no accidental "I stopped it thinking the disk would survive" mistake, because there's no stop to accidentally reach for. The mistake Lambda invites instead is treating a terminate as final cleanup and forgetting the filesystem is a separate line item that keeps running.
If your workload is short and stateless enough to rebuild from a Docker image each launch, Lambda's docs already point you at the right answer: containerize the environment, back up the data, and treat every launch as fresh. If it isn't — if you're carrying pinned custom-node commits, a virtualenv that took real time to resolve, or model weights you don't want to re-download — a region-locked filesystem gets you persistence but not the ability to move. The moment the GPU you want is in a different region, or on a different provider entirely because Lambda's capacity or price doesn't work for you that week, the filesystem is exactly the thing keeping you from leaving.
That's the same trade-off every regional network volume makes, and the fix is the same shape too: capture the whole environment, not just a mount point. Pausing a box and resuming it elsewhere — on a different GPU, region, or provider — works by snapshotting the filesystem, venv, and pinned versions as a portable unit rather than an attached volume, so a region boundary doesn't decide where you're allowed to compute next. That's what workspace backups does on Aquanode. For the general version of this problem across any provider, see our guide to keeping a persistent GPU environment portable; if you're comparing what a move would cost, the live marketplace and pricing pages are the fastest read.
FAQ
Can I stop a Lambda Cloud instance without terminating it? No. Lambda's docs state instances can only be launched, restarted, or terminated — there's no stop/pause state that preserves the local disk while dropping the compute charge.
Does Lambda's local instance storage survive a terminate? Lambda's docs don't state it survives, and their own recommendation — containerize your environment and back up data regularly to preserve state across a terminate — only makes sense if it doesn't.
Can a Lambda filesystem move between regions? No. Lambda's docs say a filesystem "must reside in the same region as the instance" to attach, and filesystems "cannot currently be transferred between regions."
Does deleting my instance stop filesystem billing? No. If the filesystem is still attached (or just not deleted), Lambda continues billing for it independently of the instance.
How much does a Lambda filesystem cost? Lambda's billing docs give an example rate of $0.20/GiB/month but explicitly flag it as illustrative, not current pricing — check the live billing page before budgeting.
About the author
I'm Ansh Saxena. I work on the infrastructure layer under rented GPU boxes, mostly on making a machine's whole state portable so it isn't tied to one provider's region map. Lambda's missing stop button is a genuinely different design than most marketplaces — it's not worse, but it changes what "be careful" means when you're deciding whether to terminate.
Sources
- Lambda Cloud: Creating and Managing Instances. Instances can only be launched, restarted, or terminated; recommendation to containerize and back up to preserve state.
- Lambda Cloud Filesystems. Regional file store attachable at launch only; up to 8 EB capacity (10 TB in Texas); must reside in the instance's region; cannot transfer between regions; billed independently of the instance if not deleted.
- Lambda Cloud Billing Overview. On-demand billing runs from launch (post health-check) to terminate; example filesystem rate of $0.20/GiB/month flagged as illustrative only.
