--- title: "Stopping a GPU Instance Leaves Other Billing Clocks Running" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/gpu-cloud-stopped-compute-retained-resource-billing" last-updated: "2026-10-20" --- # Stopping a GPU Instance Leaves Other Billing Clocks Running Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A stopped compute instance can stop accruing instance-usage charges while separately retained resources remain billable. Evaluate a proposed GPU cloud pause resource by resource: the instance state, provisioned volumes, stored snapshots and enabled extras each have their own charge basis and interval. A zero instance-usage line does not establish a zero bill for the environment. ## Identify which meter the instance state changes A project can finish its GPU job while leaving the instance running. AWS documents that running instance usage is billed even when the instance is idle. Application inactivity therefore supplies no evidence that the compute billing interval has ended. For an ordinary stop, EC2 instance-usage billing ends at the stopping state. Hibernation differs: usage remains billable during stopping and ceases at stopped; RAM contents are saved to EBS. A reboot continues instance billing. These distinctions explain why the word paused is too imprecise for a cost comparison. This article uses EC2 and EBS documentation checked October 20, 2026. Stop/start requires an EBS-backed root volume; hibernation has further eligibility conditions. No GPU instance type is assumed to support every state. Apply the selected provider product's actual state and charging rules to its offer. The buyer's question is what remains purchased during the pause. The instance state answers only part of it. Separate the resources that must remain available from those whose disposition has yet to be decided. References: [CB1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html), [CB3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) ## A retained volume keeps its own charge basis EBS storage remains chargeable when its EC2 instance is stopped. AWS's EBS pricing explanation bases volume storage on provisioned GB over time until the storage is released. The application having fewer files, doing no I/O or using no GPU time does not change that provisioned quantity. For gp3, storage, additional provisioned IOPS and additional provisioned throughput are separately described charge components. Their relevant quantities are the purchased capacity and performance above the included baseline, rather than the I/O operations the application happened to complete. A proposal that accounts for storage capacity alone can therefore omit a provisioned-performance component. Read the unit and timing description separately. The EBS billing-code reference lists volume storage in GB-Month, provisioned IOPS in IOPS-Month and provisioned throughput in MB/s-Month, with hourly granularity in those report tables. The gp3 pricing explanation separately specifies per-second billing increments with a 60-second minimum. Report granularity is not the same statement as the pricing increment. For a planned pause, the useful supplier answer identifies the retained volume type, provisioned quantities, applicable performance components and period of retention. The stopped instance's usage duration cannot stand in for the volume's duration. References: [CB1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html), [CB2](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-billing-usage-reports.html), [CB4](https://aws.amazon.com/ebs/pricing/) ## Snapshot storage follows retained data An EBS snapshot is a point-in-time backup resource. Its storage charge concerns the amount of snapshot data stored. Standard snapshots are incremental, so a count of snapshots multiplied by each source volume's provisioned capacity is not a supported calculation of the billed storage quantity. AWS's billing-code reference lists standard-tier snapshot storage and archive-tier snapshot storage in GB-Month, with hourly report granularity. It also lists archive retrieval and early-deletion categories separately. The tier and charge category matter; the label backup does not identify the entire billing basis. A source volume's removal does not automatically remove its snapshots. AWS also explains that data still referenced by another snapshot is preserved, so a reduction in snapshot count need not produce a corresponding reduction in stored data. Neither the instance count nor the snapshot count alone establishes the storage remaining on the bill. For the pause decision, ask which snapshot data and tier the proposal retains over the relevant period. Whether those retained contents can support the intended application return is a different question, developed in Training Checkpoint or Storage Snapshot and the restored EBS volume initialization guide. References: [CB2](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-billing-usage-reports.html), [CB5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html), [CB6](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html) ## Optional resources can follow an allocation or enablement clock Fast snapshot restore, or FSR, illustrates a charge tied to an enabled capability. AWS bills it for each snapshot and Availability Zone pair where it is enabled, in Data Services Unit-Hours, or DSU-Hours. Billing is per minute with a one-hour minimum. Its charge basis is the enablement interval, rather than the number of volumes restored or the GPU job's running time. An AWS-provided Elastic IP allocation is another resource to consider if present. EC2's Elastic IP documentation describes charges for in-use and idle addresses and says a disassociated address remains allocated until released. Disassociation and the end of an allocation are different conditions. These items are conditional parts of an environment, not mandatory additions to every instance. A proposal without FSR has no FSR line to add. A proposal retaining an enabled snapshot/AZ pair cannot make that line zero merely by showing no running compute. Ask which separately purchased allocations and features actually remain. References: [CB2](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-billing-usage-reports.html), [CB7](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html), [CB8](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) ## Work through four compute hours and forty-eight storage hours Consider a wholly fictional offer using invented accounting units called CU. It charges 10 CU per compute-hour and 1 CU per hour for retaining one stipulated storage allocation. The storage rate is invented for this example; it is neither an AWS price nor AWS's GB-Month storage meter. Assume no other resources, commitments, discounts, minimums or charges. Both resources begin at hour 0. Compute is billable through hour 4 and has no further charge through hour 48. The same storage allocation remains billable from hour 0 through hour 48, including the first four hours. Compute therefore contributes 4 x 10 = 40 CU. Storage contributes 48 x 1 = 48 CU. The complete stipulated charge across the interval is 40 + 48 = 88 CU. A 40 CU estimate has omitted storage entirely. Counting only the 44 hours after compute ends would instead produce 40 + 44 = 84 CU, omitting the four hours when both resources were billable. Separate resources can accrue charges at the same time; their intervals need not divide the project into mutually exclusive phases. Now replace the toy storage line with the documented EBS basis. The real comparison needs the applicable provisioned GB, any separately chargeable provisioned performance, the relevant rate basis and retention interval. Snapshot storage requires its own stored-data quantity and tier; FSR uses its own snapshot/AZ enablement interval. The invented 1 CU storage-hour cannot be converted into those quantities by assumption. The example demonstrates completeness of the stated charge scope. It predicts no actual bill or savings and supplies no basis for choosing which data to retain. References: [CB2](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-billing-usage-reports.html), [CB4](https://aws.amazon.com/ebs/pricing/), [CB5](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html), [CB7](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html) ## An ended instance does not settle retention or other purchases Termination ends EC2 instance usage, but the disposition of attached EBS volumes depends on their DeleteOnTermination settings. An instance's end state alone therefore cannot establish that every associated storage resource has ended. Snapshots remain a separate resource question. That distinction does not make deletion the recommended next action. A retained volume or snapshot may be the intended input to a later run or recovery requirement. The data and application owners must identify what is needed, for how long, and who can authorize a change. A billing observation answers none of those retention questions. Likewise, a retained storage object alone does not prove that the workload can resume correctly. Keep pricing commitments and capacity reservations alongside this resource comparison under their own conditions. A stopped instance observation is not evidence that those separate purchases have been canceled. GPU Capacity Reservation or Savings Commitment? explains the hourly-commitment and unused-capacity questions; repeating that purchase analysis would obscure the retention decision here. A useful returned pause proposal states which instance-usage interval ends, which resources remain billable and for what period, and which retention or purchase decisions remain open. An unknown storage quantity or unresolved disposition should remain visible instead of being treated as zero. References: [CB1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html), [CB6](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html) ## Keep a later equipment installation on its own scope If temporary GPU cloud use bridges a later installation of customer-owned equipment, compare the cloud retention period with that project's actual readiness assumptions. GPU Cloud or Colocation: Who Operates Each Layer? explains the different operating boundaries. Leviathan's Colocation Infrastructure Installation service and its project inquiry concern agreed customer-side physical IT work. Share the facility, customer-supplied equipment, intended rack and cabling work, access dependencies and required handoff to discuss that scope. The cloud provider and appointed account, data and application owners address the resource-billing and retention decisions above. References: [L1](https://www.leviathansystems.co/services/colocation-installation) ## Primary sources - [CB1 — AWS: Amazon EC2 instance state changes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html). Checked 2026-10-20. State-dependent instance billing, hibernation and reboot distinctions, and volume-specific termination behavior. - [CB2 — AWS: Understand codes for Amazon EBS in billing and usage reports](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-billing-usage-reports.html). Checked 2026-10-20. Charge categories, exact units and report granularity. These tables do not supply a current regional quote. - [CB3 — AWS: Stop and start Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html). Checked 2026-10-20. EBS-root-volume applicability of stop/start. No GPU-family eligibility or operational method is inferred. - [CB4 — AWS: Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). Checked 2026-10-20. Provisioned storage and gp3 performance charge basis, with per-second increments and a 60-second minimum. No example price is adopted. - [CB5 — AWS: Amazon EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html). Checked 2026-10-20. Point-in-time, incremental snapshot storage and the relationship between retained references and stored-data charges. - [CB6 — AWS Billing: Understanding unexpected charges](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/checklistforunwantedcharges.html). Checked 2026-10-20. EBS volumes and snapshots have separate lifetimes. Resource-removal recommendations are not adopted as a retention decision. - [CB7 — AWS: Amazon EBS fast snapshot restore](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html). Checked 2026-10-20. Snapshot/AZ enablement scope and per-minute billing with a one-hour minimum. Performance eligibility is outside this billing comparison. - [CB8 — AWS: Elastic IP addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html). Checked 2026-10-20. Allocation, disassociation and in-use/idle charging concepts for a retained AWS-provided address; no rate is quoted. - [L1 — Leviathan Systems: Colocation Infrastructure Installation](https://www.leviathansystems.co/services/colocation-installation). Checked 2026-10-20. Agreed customer-side physical IT installation and project inquiry, with hosting and facility services retained by the colocation provider. ## Related Leviathan resources - [GPU capacity reservation or savings commitment: separate availability from the bill](/articles/gpu-cloud-capacity-reservation-versus-savings-commitment) - [GPU cloud or colocation: operating and ownership boundaries](/articles/gpu-cloud-vs-colocation-ownership) - [Restored EBS volumes: initialization and application recovery](/articles/gpu-ebs-snapshot-volume-initialization-versus-recovery) - [Training checkpoint or storage snapshot: identify retained application state](/articles/gpu-training-checkpoint-versus-storage-snapshot) - [Customer-side colocation installation](/services/colocation-installation) - [Discuss a customer-equipment installation project](/contact?service=colocation-installation&from=%2Farticles%2Fgpu-cloud-stopped-compute-retained-resource-billing) ## Planning a later customer-equipment installation? Share the facility, customer-supplied equipment, proposed rack and cabling work, access dependencies and physical handoff needed to discuss installation scope and availability. [Discuss the scope](/contact?service=colocation-installation&from=/articles/gpu-cloud-stopped-compute-retained-resource-billing)