Does a stopped EC2 instance cost money? (2026)

Stopping an instance is the first thing anyone reaches for when a bill looks wrong, and it does work: the compute meter stops within seconds. What surprises people is the invoice that arrives anyway. Storage, addresses and commitments do not care what state your instance is in, and one of them can cost more than the instance did.

Does a stopped EC2 instance cost money?

Not for instance usage. AWS publishes a state-by-state table in the instance lifecycle documentation, and it is the clearest answer available:

The sentence under that table is the one that costs people money. AWS writes it in the same breath as the answer:

"Some AWS resources, such as Amazon EBS volumes and Elastic IP addresses, incur charges regardless of the instance's state."

And on the stop transition specifically: "you are not charged for usage or data transfer fees for your instance when it is stopped. Charges are incurred for the storage of any Amazon EBS volumes."

What are you still paying for when an EC2 instance is stopped?

Four meters keep running. Only one of them is obvious.

The EBS volumes. This is almost always the largest remaining charge. Per the Amazon EBS pricing page: "volume storage for all EBS volume types is charged by the amount of GB you provision per month until you release the storage." Provisioned, not used, and until released, not until detached. A stopped instance with a 500 GB root volume is paying for 500 GB whether the filesystem holds 500 GB or 5 GB. On io1, io2 and gp3 volumes the provisioned IOPS and throughput above baseline are separate meters on the same volume, and they do not pause either.

Any Elastic IP address. An auto-assigned public IPv4 address actually does stop costing you, because AWS takes it away. Per the EC2 instance IP addressing documentation: "we release the public IP address when the instance is stopped, hibernated, or terminated. We assign a new public IP address when you start your stopped or hibernated instance." An Elastic IP is the opposite. It stays allocated to your account, and the VPC pricing page charges it either way: "hourly charge for In-use Public IPv4 Address $0.005" and "hourly charge for Idle Public IPv4 Address $0.005". AWS states the equivalence directly: "the price is the same whether the public IPv4 address is in-use public IPv4 addresses that is associated with an AWS resource you own, or an idle public IPv4 addresses in your AWS account not associated with any AWS resources." That is $3.65 a month per address, and it is covered in detail in what AWS charges for a public IPv4.

Snapshots of those volumes. They are a separate resource with a separate lifecycle, and AWS's unwanted-charges checklist is blunt about it: "deleting a volume doesn't automatically delete the associated snapshots." Snapshot billing has its own surprising shape, which what an EBS snapshot actually costs covers.

Anything you committed to. A Savings Plan or Reserved Instance keeps billing on its own schedule regardless of whether an instance exists to consume it. That is the next section, and it is the one that turns a cost-saving action into a no-op.

Does stopping an EC2 instance save money if a Savings Plan covers it?

No, and this is the most expensive misunderstanding on this page. A Savings Plan or a Reserved Instance is a commitment to spend, not a discount voucher attached to a machine. Stop the instance and the commitment still bills; you have simply removed the usage that was absorbing it.

AWS spells the extreme case out in the lifecycle table itself, for terminated instances: "Reserved Instances that applied to terminated instances are billed until the end of their term according to their payment option." Terminating the instance does not terminate the reservation.

In Savings Plans terms, stopping covered instances drops your utilization, which is the metric where waste is unrecoverable. Coverage falling is a missed discount; utilization falling is money spent on nothing, as Savings Plans coverage vs utilization works through. Before you schedule dev instances off overnight, check whether a commitment is sitting under them. The saving may be zero.

The same logic applies to an EC2 Capacity Reservation, which bills at the On-Demand rate whether or not anything is running in it.

What happens to your data when you stop an EC2 instance?

EBS volumes persist. Instance store volumes do not, and the loss is silent. The stop and start documentation states both halves:

"You can stop and start your Amazon EBS-backed instances (instances with EBS root volumes). You can't stop and start instances with an instance store root volume."

And for attached instance store volumes: "when you stop an instance, the data on any instance store volumes is erased." There is no warning and no recovery. There is also no storage saving to be had, because that capacity was never a separate charge: per the instance store documentation, "there is no additional charge to use the instance store volumes provided for your instance. Instance store volumes are included as part of the usage cost of the instance." You lose the contents and save nothing on storage.

Is hibernating an EC2 instance cheaper than stopping it?

No. It is slightly more expensive, in two places, and both are documented.

First, the transition is billed. From the lifecycle guide: "you are not charged for usage for a hibernated instance when it is in the stopped state, but you are charged while it is in the stopping state, unlike when you stop an instance without hibernating it."

Second, the memory has to go somewhere, and that somewhere is billed storage. The hibernation documentation says: "hibernation saves the contents from the instance memory (RAM) to your Amazon Elastic Block Store (Amazon EBS) root volume", and on charges: "you're not charged for instance usage for a hibernated instance when it is in the stopped state or for data transfer when the contents of the RAM are transferred to the EBS root volume. You are charged for storage of any EBS volumes, including storage for the RAM contents."

So a hibernated 64 GB instance needs its root volume to be large enough to hold 64 GB of RAM image, and you pay for that capacity every hour of the month. Hibernation is a startup-latency feature. Treat it as a cost increase bought for faster resume, not as a cheaper stop.

Does a terminated EC2 instance cost money?

The instance itself, no: "as soon as the status of an instance changes to shutting-down or terminated, you stop incurring charges for that instance." Three things commonly survive it.

• Volumes with DeleteOnTermination set to false. AWS's checklist notes that "most Amazon EC2 instances are configured so that their associated Amazon EBS volumes are deleted when they are terminated, but it's possible to set up an instance that preserves its volume and the data." The default is not one value, and this is where orphaned volumes come from. AWS publishes the whole matrix, because "the default DeleteOnTermination value differs depending on the volume type, whether the volume was attached at launch or after, and the method (console or CLI) used to attach the volume":

  Volume type	Attached when	Method	Default on termination
  Root volume	At launch	Console or CLI	Delete
  Root volume	After launch	Console or CLI	Preserve
  Data volume	At launch	Console	Preserve
  Data volume	At launch	CLI	Delete
  Data volume	After launch	Console and CLI	Preserve

  Note the third and fourth rows: the same volume attached at launch defaults to Preserve from the console and Delete from the CLI, so two teams doing the same thing through different tools end up with different bills. The source is Preserve Amazon EBS volumes on instance termination, which also advises that "we recommend that you verify the default setting for the DeleteOnTermination attribute after you launch an instance."
• Elastic IP addresses. "Any Elastic IP addresses that are attached to an instance that you terminate are unattached, but they are still allocated to you." Unattached means idle, and idle is billed at the same $0.005 an hour.
• Reserved Instances. Billed until the end of their term, per the quote above.

Does stopping and starting an instance repeatedly cost extra?

It can, because each start opens a fresh billing period with a floor. AWS: "each time you transition an instance from stopped to running, you are charged per second when the instance is running, with a minimum of one minute per instance start."

A reboot behaves differently and is the cheaper operation when you only need the OS restarted: "rebooting an instance doesn't start a new instance billing period; per second billing continues without a further one-minute minimum charge."

The practical consequence is narrow but real. An automation that stops and starts instances every few seconds pays a full minute each time. Scheduling fleets off at night is unaffected, since one extra minute a day against eight hours saved is noise.

How do you find stopped EC2 instances that are still billing?

Start with the instances themselves, then follow the volumes, because the volumes are where the money is.

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=stopped \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,StateTransitionReason]' \
  --output table

StateTransitionReason is documented only as "the reason for the most recent state transition", and AWS warns that it "might be an empty string", but in practice a user-initiated stop populates it with a date, which is enough to tell an instance stopped last night from one stopped eight months ago. Where it is empty, fall back to the age of the attached volumes. Then find volumes with nothing attached at all:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' \
  --output table

available is the state AWS defines as "the volume is not attached to an instance", per the volume states documentation. Every volume in that list is billing at its full provisioned size for zero benefit.

In the CUR, the tell is a resource that has EBS usage types and no compute usage types in the same period. Because the charge lands under EBS rather than under an instance, it also lands in the grouping described in what is EC2 - Other in Cost Explorer, which is why a stopped fleet shows up as an unexplained line rather than as EC2 spend.

One more source worth reading in full when you are hunting a charge you cannot place: AWS's own checklist for unexpected charges walks the same ground from the billing side.

What should you do with a long-stopped instance?

• Stopping is not deleting. If an instance has been stopped for a quarter, the decision you are avoiding is termination. Snapshot the volume, terminate the instance, delete the volume. A snapshot of a lightly-used 500 GB volume is a fraction of the volume's monthly cost, because snapshots bill on used blocks rather than provisioned size.
• Release Elastic IPs you are not using. Idle and in-use cost the same, so an address held "in case we need it" is a full-price address.
• Check for a commitment first. Stopping instances covered by a Savings Plan or Reserved Instance saves nothing and hides the waste in a utilization number nobody is watching.
• Right-size the volume, not just the instance. Instance type is the number everyone reviews. Provisioned volume size is the number that keeps billing after the instance is switched off.