Amazon EC2 often looks straightforward when you first estimate the cost.
Choose an instance type, check the hourly rate, estimate how many hours it will run, and calculate the monthly cost.
But when the AWS bill arrives, the amount associated with running an EC2-based workload can look very different from that original calculation.
The reason is simple: the EC2 instance is often only one part of the infrastructure you’re paying for.
EBS volumes, snapshots, public IPv4 addresses, data transfer, load balancers, NAT Gateways and other supporting resources can all affect the overall cost of running an application around EC2.
This guide explains how Amazon EC2 billing works, what happens when you stop or terminate an instance, and what to investigate when EC2-related costs are higher than expected.
1. How Does Amazon EC2 Billing Work?
At the simplest level, EC2 billing starts with the compute capacity your instance consumes.
The amount you pay depends on factors such as:
- Instance Type
- AWS Region
- Operating System
- How Long the Instance Runs
- Purchase Model
- Number of Instances
For many On-Demand EC2 instances, AWS bills running compute per second with a 60-second minimum. AWS documentation notes that billing begins once an instance transitions into the running state.
For example, if you run an eligible instance for 3 minutes and 40 seconds, you are generally billed for those 3 minutes and 40 seconds. If you start it and stop it after only 20 seconds, the one-minute minimum applies.
That’s the compute side.
The important part is that your complete EC2 workload cost may not end there.
A production environment might look more like:
EC2 Compute + EBS + Snapshots + Networking + Public IPs + Load Balancer + NAT Gateway + Monitoring
That’s why an EC2 price estimate and the eventual AWS bill aren’t always the same thing.
2. When Does EC2 Billing Start?
For a typical On-Demand instance, compute billing begins when the instance reaches the running state.
AWS doesn’t bill EC2 instance usage while an instance is in the pending state. Once it moves to running, instance usage becomes billable.
This distinction matters when you’re launching and terminating instances frequently—for example, in development environments, test workloads or automated deployments.
It also helps explain why simply creating an instance isn’t necessarily the same as paying for hours of compute. The instance state matters.
3. What Is The EC2 Minimum Billing Time?
For EC2 instances eligible for per-second billing, AWS applies a minimum charge of 60 seconds each time the instance starts running.
After that first minute, eligible usage is billed by the second.
For example:
Run for 20 seconds → billed for 60 seconds
Run for 3 minutes 40 seconds → billed for 3 minutes 40 seconds
This probably won’t make a meaningful difference to an instance that runs continuously for a month.
But it can matter when you’re repeatedly starting short-lived instances through automation, testing or development workflows.
4. What Happens To Billing When You Stop An EC2 Instance?
This is one of the most common areas of confusion.
When an eligible EBS-backed EC2 instance is stopped, AWS stops charging for the instance’s compute usage.
AWS also states that you aren’t charged instance data-transfer fees while the instance is stopped.
So if your instance is:
Running → compute is billed
Stopped → instance compute isn’t billed
Terminated → instance compute isn’t billed
However, this does not necessarily mean your AWS cost drops to zero.
That’s because some of the resources associated with the instance can continue to exist.
5. Why Can A Stopped EC2 Instance Still Cost Money?
Suppose you stop an EC2 instance on Friday and don’t start it again for a month.
You might reasonably expect:
“The server is stopped, so there shouldn’t be any charges.”
The EC2 compute portion may indeed stop.
But the instance’s EBS volumes remain available so your data is still there when you restart the server.
AWS continues charging for provisioned EBS storage even while the associated EC2 instance is stopped.
Other resources associated with your architecture may also remain billable.
This is why stopping an instance and removing an environment are two different things.
Stopping is useful when you want to temporarily stop compute while preserving the environment.
If you’re permanently decommissioning the workload, you need to review the supporting resources too.
6. EBS Volume Charges
Most EC2 workloads use Amazon Elastic Block Store (EBS) for persistent storage.
Think of EBS as storage that exists separately from the compute lifecycle.
Stopping the instance doesn’t automatically delete that storage.
Even detaching an EBS volume doesn’t eliminate its storage charge. AWS continues billing the provisioned volume until you delete it.
This creates a common situation:
EC2 instance → terminated
but
EBS volume → still exists
If the volume is no longer required, it can quietly remain in the account and continue contributing to the bill.
Before deleting anything, of course, make sure the data is no longer needed or has been backed up appropriately.
7. EBS Snapshots And AMI-Related Storage
Snapshots are another area worth checking.
Teams often create snapshots before:
- Upgrades
- Migrations
- Application changes
- Instance replacements
- Testing
- Decommissioning
That’s sensible operational practice.
The problem comes when nobody revisits the retention policy.
An EC2 instance might disappear. Its original EBS volume might also disappear.
But snapshots can remain.
AWS specifically identifies retained EBS snapshots as one reason customers may continue seeing charges after terminating EC2 instances.
So when reviewing an old EC2 environment, don’t check only:
EC2 → Instances
Also review:
EC2 → Volumes
EC2 → Snapshots
and any AMIs or other related resources you intentionally created.
8. Public IPv4 And Elastic IP Costs
Public IP addressing is another component that can be missed when estimating an EC2 workload.
If your architecture requires public IPv4 addresses or Elastic IP addresses, include those in your cost model rather than assuming networking around the EC2 instance is automatically free.
AWS also identifies retained Elastic IP addresses as a possible source of continuing charges after an instance has been terminated.
This becomes particularly relevant in environments where infrastructure is created and destroyed frequently.
The compute resource may disappear while networking resources remain behind.
9. EC2 Data Transfer Charges
Network traffic can materially change the cost of an application.
Depending on your architecture, you may need to consider traffic such as:
- Data transferred to the internet
- Cross-Region traffic
- Cross-Availability Zone traffic
- Traffic involving other AWS services
- Traffic passing through networking components
AWS’s own EC2 estimation guidance specifically recommends considering expected monthly data transfer when building an EC2 estimate.
This is why two applications running on the same EC2 instance type can have very different monthly costs.
One may process very little external traffic.
The other may serve large files, communicate heavily across infrastructure layers, or send significant amounts of data outside AWS.
Same compute.
Very different architecture.
Potentially very different bill.
10. Load Balancer And NAT Gateway Costs Around EC2
Imagine a production application that starts with this architecture:
Users → EC2
As the application grows, you might introduce:
Users → Load Balancer → EC2 → Database
Then perhaps private subnets and outbound connectivity:
Private EC2 → NAT Gateway → Internet
These components exist for legitimate architectural reasons.
But they also change the cost model.
A common mistake is to ask:
“How much will my EC2 server cost?”
when the better question is:
“How much will the architecture required to operate this application cost?”
That’s a much more useful question during cloud planning.
11. Reserved Instances And Savings Plans
Not every EC2 workload needs to stay on pure On-Demand pricing.
AWS offers commitment-based options that can reduce eligible compute costs when you have predictable usage.
Two concepts you’ll commonly encounter are:
Reserved Instances
and
Savings Plans
These shouldn’t be treated as interchangeable in every situation, but both involve making commitments in exchange for pricing benefits under applicable terms.
The important billing consideration is that a commitment doesn’t simply disappear because you stop using the underlying workload.
For example, AWS notes that Reserved Instance charges can continue according to the contract even when the instances they previously applied to have been terminated.
Similarly, Savings Plans involve committed hourly spend for the term of the plan.
That’s why optimization shouldn’t start with:
“Buy the biggest discount available.”
It should start with:
“How stable and predictable is this workload?”
Then evaluate the appropriate pricing model.
12. Why Am I Still Being Charged After Terminating EC2?
This is probably the most important troubleshooting question in this article.
You terminate every EC2 instance.
You check the console.
Nothing is running.
But AWS still shows charges.
That doesn’t automatically mean AWS is continuing to charge you for a terminated instance.
There are several possible explanations.
AWS specifically recommends checking for resources such as:
- Remaining EBS volumes
- EBS snapshots
- Elastic IP addresses
- Resources in another AWS Region
- Automatically launched instances
- Reserved Instance commitments
Also remember that billing reflects usage that already occurred during the billing period.
A resource can therefore be gone today while charges associated with its earlier usage still appear on the month’s bill.
The first troubleshooting question shouldn’t be:
“Where is my EC2 instance?”
It should be:
“Which exact resource or usage type is generating this charge?”
13. How To Investigate Unexpected EC2 Charges
When an EC2-related bill looks wrong, avoid randomly deleting resources.
Use a structured approach.
Step 1: Check AWS Billing And Cost Management
Identify which service is actually producing the charge.
What looks like an “EC2 bill” from an architecture perspective may involve separate AWS billing components.
Step 2: Check The Region
A forgotten resource may exist outside the Region you’re currently viewing.
AWS specifically recommends checking billing information to identify Regions where resources may still be generating charges.
Step 3: Review Running EC2 Instances
Check whether anything is still running.
Also consider automation.
Auto Scaling, Elastic Beanstalk or other configurations can potentially create new instances even after you’ve manually removed one.
Step 4: Review EBS Volumes
Look for:
- Unattached volumes
- Old volumes
- Development volumes
- Volumes belonging to terminated workloads
Step 5: Review Snapshots
Check whether old snapshots are still required.
Don’t delete snapshots simply because they’re old—confirm retention, backup and recovery requirements first.
Step 6: Review IP And Networking Resources
Look at public IPv4/Elastic IP resources and the wider network architecture.
Step 7: Check Commitments
Review Reserved Instances and Savings Plans separately from the lifecycle of individual EC2 instances.
Step 8: Compare The Timing
Find when the cost increased and compare that date against infrastructure changes.
This is often more useful than looking only at the current state of the environment.
14. Example Of An EC2 Monthly Bill
Suppose you’re planning a relatively simple web application.
The architecture includes:
1 EC2 instance
100 GB EBS volume
EBS snapshots
Public IPv4
Application Load Balancer
Outbound data transfer
CloudWatch monitoring/logging
The mistake would be calculating only:
EC2 hourly price × monthly runtime
A better planning model is:
EC2 compute
- EBS storage
- snapshot storage
- public IPv4
- load balancing
- data transfer
- monitoring
= more realistic infrastructure estimate
And if the application uses a database, NAT Gateway, S3 or other AWS services, those need to be considered too.
This is why architecture-level cost estimation is much more useful than instance-level estimation.
CTA:
Estimate Your EC2 Cost
Use the free EC2 Cost Calculator to estimate your compute requirements before deployment.
15. EC2 Pricing Vs EC2 Billing
These terms sound similar, but the search intent is slightly different.
EC2 Pricing answers:
“How much does an EC2 instance cost?”
EC2 Billing answers:
“Why was I charged this amount?”
Pricing is about estimating.
Billing is about understanding what actually happened.
You need both.
Before deploying an environment, understand the pricing model.
After deployment, monitor the bill and compare actual usage against your original assumptions.
16. How To Reduce EC2 Costs
Cost optimization shouldn’t mean blindly selecting the smallest instance available.
The goal is to align infrastructure cost with what the workload actually needs.
Start with a few practical checks:
Right-size instances
Review CPU, memory and workload patterns rather than keeping oversized instances indefinitely.
Schedule non-production environments
Development and test environments may not need to run 24/7.
Remove unused EBS volumes
A terminated instance doesn’t necessarily mean its storage disappeared.
Review snapshot retention
Keep what your recovery and compliance requirements need, but don’t let forgotten snapshots accumulate forever.
Review data transfer
Understand where application traffic is going and whether the architecture is creating unnecessary network movement.
Review commitment options
For stable workloads, evaluate Savings Plans or Reserved pricing where appropriate.
Review the complete architecture
Optimizing EC2 while ignoring networking, databases and storage can miss a large part of the opportunity.
17. Estimate Before You Deploy
The easiest time to discover a cloud-cost problem is before the architecture goes into production.
Instead of estimating only the instance, identify every component the workload requires.
I use a simple planning model:
Compute + Storage + Database + Networking + Availability + Monitoring + Backup
AWS Cost Estimation Checklist to review 15 common AWS cost areas before deployment.
EC2 Billing FAQs
Does AWS Charge For A Stopped EC2 Instance?
AWS doesn’t charge instance compute usage while an eligible EC2 instance is stopped. However, associated resources such as EBS volumes can continue generating charges.
Why Am I Being Charged For EC2 When I Have No Running Instances?
Possible causes include EBS volumes, snapshots, Elastic IP addresses, resources in another Region, Reserved Instance commitments, or charges for usage that occurred earlier in the billing period.
Does Stopping EC2 Stop EBS Charges?
No. EBS storage can continue to be billed while an EC2 instance is stopped. Detaching the volume also doesn’t eliminate its storage cost; the volume must be deleted when it is genuinely no longer required.
Does EC2 Bill By The Second?
Many On-Demand EC2 instances are billed per second with a 60-second minimum, although billing behavior can vary by operating system and offering.
Am I Charged When I Restart A Stopped EC2 Instance?
When an eligible stopped instance is started again, a new instance billing period begins. AWS applies a minimum of one minute and then per-second billing for eligible instances.
Can Snapshots Cost Money After An EC2 Instance Is Terminated?
Yes. EBS snapshots can continue to incur storage charges after the original instance and volume are gone.
How Can I Find Unexpected EC2 Charges?
Start with AWS Billing and Cost Management or Cost Explorer to identify the service, usage and Region associated with the cost. Then review the corresponding EC2 resources, EBS volumes, snapshots, IP resources, automation and commitments rather than checking only the Instances screen.
Final Thoughts
Understanding EC2 billing requires looking beyond the virtual machine.
The instance may be the most visible part of the architecture, but it’s rarely the only resource involved.
A workload can gradually evolve from:
EC2
to:
EC2 + EBS + Snapshots + Load Balancer + NAT Gateway + Data Transfer + Monitoring + Database
without anyone revisiting the original estimate.
That’s when AWS bills can start feeling unexpected.
The better approach is simple:
Estimate the architecture before deployment. Monitor actual usage after deployment. Investigate the specific cost driver before making changes.
That gives you a much clearer picture of what you’re actually paying for—and where optimization will make a meaningful difference.
One Response