EC2 Stop vs. Terminate Cost: What Persists?

When an Amazon EC2 instance is identified as idle, compare stopping with termination based on whether you need to run it again. With an EBS root volume, stopping shuts the instance down without deleting it, so you can start it again; terminate it when you no longer need the instance.

Neither path guarantees a zero AWS bill. Amazon Elastic Block Store (EBS) volumes, snapshots, Elastic IP addresses, and other retained resources continue generating charges independent of the compute state. Furthermore, Savings Plan commitments can separate the compute removed from your verified net savings.

When future use is uncertain, stopping an instance first provides a reversible test. You then terminate the instance only after confirming its retirement, reviewing preserved data, and adjusting the surrounding automation. Through the FinOps AI platform, an idle-instance finding serves as the start of an approval-first AWS stop workflow, establishing a safe boundary before any resources disappear permanently.

The Short Answer: Compute Charges Stop Either Way

Compute billing behaves identically for both actions. A stopped instance incurs no hourly usage or data-transfer costs, and a terminated instance stops generating usage charges the moment its state changes from running to shutting-down. In both scenarios, the underlying compute capacity returns to the AWS pool, meaning you stop paying the hourly rate for that specific virtual machine.

That compute reduction does not guarantee a proportional drop in your monthly AWS invoice, because the surrounding infrastructure dictates the remaining cost. Stopping an instance leaves its EBS storage intact and any Elastic IP addresses allocated, keeping those billing meters running, while an automatically assigned public IPv4 address is released. Terminating an instance removes only the specific components configured for automatic deletion.

EC2 Stop vs. Terminate: Side-by-Side Cost and Risk

Comparing the two actions requires looking at the same criteria across usage, storage, memory, and automated recovery.

A practical cost model separates avoided compute charges from the remaining persistent charges. After stopping, your EBS volumes, snapshots, and retained Elastic IPs still bill at their standard rates. Following termination, any EBS volumes, snapshots, or Elastic IPs that remain allocated continue generating charges until you remove them. The incremental savings from terminating rather than stopping equal only the additional resources you remove, and you do not count the compute charges a second time since either action stops that hourly meter.

Stopping: What Still Costs and What Changes

Stopping an instance suspends the compute environment while preserving its configuration and persistent storage. Because the instance usage and data-transfer fees drop to zero, stopping provides a reliable method for pausing non-production environments overnight or testing the impact of an unowned server.

Attached EBS root and data volumes continue to incur storage charges while the instance is stopped. AWS bills EBS based on provisioned capacity rather than active read/write operations. If you stop a database instance attached to a 500 GB gp3 volume, you continue paying for 500 GB of storage each month, and provisioned IOPS or throughput above gp3's included baseline adds further costs.

Snapshots operate as a separate storage line, with AWS charging based on the stored data. Because Amazon EBS snapshots are incremental, deleting a snapshot may not reduce your storage charges if other snapshots still reference the same data blocks.

Network addresses also carry distinct billing rules. Amazon VPC pricing lists a $0.005 hourly charge for both in-use and idle public IPv4 addresses, including idle Elastic IPs in its pricing example, so a 730-hour planning month works out to about $3.65 per address.

Stopping has distinct limits regarding reversibility. While you can stop and start Amazon EC2 instances that use an EBS root volume, instances relying on an instance-store root volume cannot be stopped and restarted this way. In addition, data on any instance-store volumes is erased when an instance stops.

Infrastructure automation reacts to stopped instances according to health-check settings. By default, EC2 Auto Scaling treats an instance outside the running state as unhealthy and replaces it to maintain desired capacity, so stopping a managed instance can erase the intended cost savings unless you first place it in Standby or adjust the group's health-check behavior.

Terminating: What It Removes and What It Cannot Restore

Termination permanently removes the virtual machine from your account. The compute usage billing stops as the instance shuts down, but the cleanup of surrounding resources depends entirely on configuration flags and subsequent manual review.

EBS volume cleanup relies on the DeleteOnTermination setting applied to each attached volume. Its default varies by volume type, attachment time, and attachment method; at launch, the AMI sets the default, which can be overridden. Under AWS's documented defaults, root volumes attached at launch default to deletion, while root volumes and data volumes attached after launch default to preservation. Data volumes attached at launch default to preservation through the console and deletion through the CLI. Reviewing each volume's setting confirms what will happen, and preserved EBS volumes continue to incur charges after termination.

Network components detach during termination. The automatically assigned public IP returns to the AWS pool, and any Elastic IP detaches from the terminated instance while remaining allocated to your AWS account. Until you explicitly release the Elastic IP back to AWS, it stays billable as an idle address.

Termination is a permanent action, meaning you cannot restart the instance. Any instance-store data disappears, and an EBS volume deleted on termination remains unavailable unless a separate backup already exists.

Automation controllers respond to termination as designed. Auto Scaling groups and maintain-type EC2 Fleets can launch replacements if their configured capacity remains unchanged. Terminating an instance without updating its controller can erase the intended savings, because a replacement may launch and begin accruing charges to restore capacity.

Verdict: Stop First, Then Use This Checklist

Stop an idle instance first when its future use is uncertain. Terminate the instance only after making an explicit end-of-life decision and reviewing the associated data, addresses, and automation. A stop offers a reversible pause at the instance-state level, even though it cannot restore volatile RAM, instance-store data, or an automatically assigned public IP.

Before stopping

Work through these checks to safely pause compute without disrupting automated environments:

1. Confirm idleness across a representative workload cycle. Review the resource owner, applied tags, scheduled jobs, and seasonal usage patterns, because a quiet afternoon does not prove a server is obsolete.
2. Verify EBS-rooted stop support. Check the root volume type, and copy any local instance-store data that you intend to keep, as it will not survive the stop command.
3. Inventory persistent costs. Record each attached EBS volume, its provisioned IOPS or throughput, existing snapshots, and Elastic IPs to identify the specific storage and network charges that will continue.
4. Check network dependencies. If client applications, firewall allowlists, or DNS records rely on the automatically assigned public IPv4 address, plan for that address to change on restart.
5. Inspect automation and commitments. Verify that an Auto Scaling group or a maintain-type EC2 Fleet will not immediately replace the stopped node, and review Savings Plan coverage to understand how a stopped instance shifts your commitment to other workloads.
6. Request approval for a scoped stop. Verify the instance reaches the stopped state, watch for unexpected service impact across related applications, and compare the ongoing persistent resource costs with your pre-action estimate before executing a restart if verification fails.

Before terminating

Permanent changes call for owner approval and confirmed retirement before execution.

1. Decide which volumes and snapshots to preserve. Review the DeleteOnTermination boolean flag for every attached drive, adjusting the setting based on your data retention policy.
2. Adjust capacity controllers. Lower the desired capacity on the Auto Scaling group or update the EC2 Fleet's target capacity to prevent an unwanted replacement launch.
3. Release unneeded Elastic IPs. Identify detached addresses that no longer serve a purpose and release them to stop the hourly idle charge.
4. Confirm termination and inventory what remains. Record the verified charges removed, tracking the estimated compute reduction separately from the verified net savings in your reporting.

The FinOps AI platform supports this workflow by turning static cost findings into agentic remediation loops. When the platform surfaces an idle-instance finding, engineering teams can confirm the scope and require explicit approval before taking action. The platform applies the AWS stop command within defined account guardrails, runs an automated post-check that compares the result with what was intended, and rolls the reversible change back automatically if that check fails.

After a stop succeeds, FinOps AI books its estimated monthly saving as pending in its savings ledger, looks the instance up again about seven days later, and counts the saving only if the instance is still stopped or no longer exists, for example because it was terminated. These are estimates: they are not reconciled with your AWS invoice and do not reflect your discounts, so they are not the verified net savings described above. FinOps AI also shows Google Cloud cost and usage beside AWS, but remediation runs on AWS only.

Common EC2 Stop vs. Terminate Cost Questions

Does a stopped EC2 instance still cost money?

Yes. While instance usage and data-transfer fees stop immediately, storage and network configurations persist. Attached EBS volumes bill based on provisioned capacity, retained snapshots incur storage fees, and allocated Elastic IPs continue billing at the standard hourly rate.

Is termination cheaper than stopping?

Compute charges end with either action. Termination saves more money only when it removes separately billable resources. If an instance has its DeleteOnTermination flag set to true for its volumes, and you release its Elastic IP afterward, the total bill decreases further than a basic stop. If you terminate an instance but preserve its 1 TB EBS volume and leave its Elastic IP idle, the persistent costs remain identical to the stopped state.

Does termination always delete EBS volumes?

No. The outcome depends entirely on the DeleteOnTermination setting for each individual drive. Root volumes typically default to true and delete automatically, while additional data volumes attached after launch often default to false and persist after termination. Checking each volume confirms the expected behavior.

Does an Elastic IP still cost money when an instance is stopped or terminated?

A retained Elastic IP remains chargeable in both scenarios. When an instance is stopped, the Elastic IP stays attached but the instance is not running, meaning the address generates an hourly charge. When an instance terminates, the Elastic IP detaches. Until you explicitly release that allocated address back to the AWS pool, it remains an idle public IPv4 address and continues to bill.

Does stopping or terminating cancel a Savings Plan commitment?

No. Commitments remain active and apply hourly to eligible usage. With Savings Plans sharing enabled, coverage can shift to eligible usage in other accounts within the consolidated billing family. Unused hourly commitment does not roll forward to the next hour. When you remove a covered instance, AWS applies active Savings Plans automatically to eligible usage, so the commitment may cover workloads that were previously billed at On-Demand rates. Check your remaining eligible compute footprint before reporting net savings.

---

Stop idle AWS resources safely before making permanent cuts. Use FinOps AI to gate instance remediation behind team approvals, check each result after the change, and roll back reversible changes automatically if that check fails. Start building secure cost workflows at getfinops.cloud.