AWS Spot Instances Still Charged for 1 Hour? That's an Old Myth Many People Still Believe

There’s a belief that keeps living among engineers, even those with years of AWS experience: if an EC2 Spot Instance runs for 17 minutes, you still get charged for a full hour. This belief was once true — but it hasn’t been relevant for a long time. Unfortunately, this myth still frequently appears in technical discussions, architecture reviews, and even cost optimization proposals that end up rejected because of wrong cost calculations. This article dissects where this myth comes from, how Spot Instance billing actually works today, when the hourly model is still relevant, and why this misunderstanding can have a real impact on architecture decisions and infrastructure budgets.

The Origin of the Myth: It Really Was Per Hour Back Then

Before 2017, AWS EC2 used an hourly billing model for all instance types. The rule was simple but rigid:

Billing model before 2017:
  Instance running 1 minute  → still charged a full hour
  Instance running 17 minutes → still charged a full hour
  Instance running 59 minutes → still charged a full hour

This round-up rule applied uniformly to On-Demand, Reserved, and Spot Instances. No exceptions — anyone who started an instance, even for just one minute, was billed as if the instance ran for a full hour.

So historically, this myth was indeed fact. The problem isn’t the belief itself when it was first formed, but the fact that AWS has fundamentally changed its billing model, while many engineers never updated this old assumption to current conditions.

The experience of “I used AWS before and was indeed charged per hour” isn’t a faulty memory — it was accurate for its time. The problem is when this old experience is considered still valid without re-verifying against AWS’s current billing documentation.

The Big Change: Per-Second Billing Since 2017

In 2017, AWS introduced per-second billing for EC2 Linux, a change that completely transformed cost calculations for short-lived workloads.

flowchart LR
    A[Before 2017] -->|Hourly Billing| B[All durations rounded up to 1 hour]
    C[Since 2017] -->|Per-Second Billing| D[Billed per second with a 60-second minimum]
    A -.->|AWS model change| C

The billing rules in effect today:

• Billed per second, not per hour.
• There’s a 60-second minimum charge — instances alive for less than a minute still pay for one minute.
• After passing 60 seconds, costs are calculated based on actual usage duration, down to the second.
• Applies to On-Demand Linux and Spot Instance Linux.

The following table shows how instance lifetime translates into cost under the per-second billing model:

There’s no rounding to a full hour under any condition beyond the initial 60-second minimum charge. This is the core change that makes the “charged 1 hour” myth no longer accurate for modern EC2 Linux.

How Spot Instances Are Actually Billed

Spot Instances still use the exact same pay-as-you-go billing model as On-Demand. No contracts, no minimum usage hours, no penalties when the instance is terminated, and no rounding to a full hour.

The only difference between Spot and On-Demand: Spot Instances can be terminated by AWS at any time, when the capacity AWS needs for On-Demand or Reserved increases in that availability zone. That’s about availability, not billing.

The Spot Instance price discount versus On-Demand is AWS’s incentive to utilize currently unused capacity. The trade-off is only interruption risk, not any additional burden on the billing side.

Why So Many People Still Believe This Myth

There are several common reasons this misunderstanding persists, even among senior engineers.

Old Memories Never Updated

Engineers who used AWS before 2017, never re-checked billing details afterward, and rely on “past experience” as the source of truth is a very common pattern. Cloud infrastructure changes fast, and billing models are one of the things rarely re-checked because they’re considered “already known”.

Wrongly Blaming Other Resources

This is a subtler cause that often escapes attention. Often an EC2 instance lives only 17 minutes, but the monthly bill still shows per-hour patterns. The problem isn’t the EC2 — it’s other components in the architecture that are indeed still billed per hour:

The EC2 itself is already per-second, but supporting components like NAT Gateway, ALB, or idle Elastic IPs remain hourly-based. When looking at the total bill without breaking it down per line item, it’s easy to mistakenly conclude that EC2 is causing the “per-hour” pattern.

Windows Instances — an Edge Case Still Relevant

For EC2 Windows, billing is still per hour, and this also applies to Windows-based Spot Instances. However, the majority of modern workloads suited for Spot — CI/CD runners, batch processing, queue workers — generally run on Linux, so this edge case is often practically irrelevant, even though it drags along the reputation of the per-hour billing myth in general.

If your specific workload indeed runs on Windows EC2, verify its billing model separately — the generalization “all EC2 is already per-second” doesn’t universally apply to Windows.

Spot Interruption Mechanics and Its Billing

One common concern about Spot Instances: what if AWS unilaterally terminates the instance mid-process? Are there additional costs or penalties?

sequenceDiagram
    participant App as Workload (CI/CD, Batch, etc.)
    participant EC2 as Spot Instance
    participant AWS as AWS Capacity Manager
    App->>EC2: Job running
    AWS->>EC2: Interruption notice (2 minutes before termination)
    EC2->>App: Signal for graceful shutdown / checkpoint
    AWS->>EC2: Terminate instance
    Note over EC2: Billing counted until the last second the instance was alive

When a spot interruption occurs — whether because AWS needs the capacity back, or because the Spot price exceeds the maximum you set — billing still follows the same rules:

• Counted until the last second the instance is truly alive.
• Not rounded up to the hour.
• No termination fee or any additional penalty.

As a concrete example: if the instance lives 20 minutes before AWS terminates it for capacity reasons, the cost billed is for those 20 minutes only — not a full hour.

AWS also provides an interruption notice about two minutes before the instance is actually terminated, giving applications a short window for graceful shutdown, saving checkpoints, or moving important state — an important detail for designing interruption-resilient workloads, regardless of billing.

How to Prove It Yourself via AWS Cost Explorer

Rather than arguing based on opinion or old memories, the most objective way to verify this claim is looking directly at the billing data from AWS.

The steps:

1. Open AWS Cost Explorer from the AWS Console.
2. Filter by Service: EC2 - Other or EC2 - Compute, then narrow with Usage Types containing SpotUsage.
3. Look at the usage granularity detail — you’ll see a breakdown in decimal hours (for example 0.283 hours, not rounded to 1.0 hours), equivalent to the actual minutes and seconds of usage.

For more precise verification down to the individual instance level, the Cost and Usage Report (CUR) can provide data with explicit instance start and stop times, so the actual usage duration can be manually calculated and compared directly against the cost figure that appears.

Data from Cost Explorer or CUR is evidence that opinions can’t refute — if the team or stakeholders still doubt, invite them to look directly at the usage breakdown in the AWS account in use.

This Myth’s Impact on Architecture Decisions

Misunderstanding billing isn’t just technical trivia — it can directly affect architecture decisions and budgets.

Common negative impacts when this myth is believed:

✗ CI/CD pipelines stay on On-Demand, even though Spot fits far better
✗ Batch jobs run on On-Demand because "Spot will still be expensive for short-lived jobs"
✗ Cost optimization proposals get rejected due to over-estimating Spot costs
✗ Teams hesitate to adopt auto-scaling with short-lived instances

In reality, Spot Instances are actually ideal for exactly the kinds of short-lived, no-long-term-state workloads:

The shared characteristic of these workloads: short-lived, retryable without side effects, and not dependent on local state that’s lost if the instance suddenly dies. This combination of characteristics — not assumptions about per-hour billing — should be the main consideration when deciding whether Spot Instances are suitable.

Practical Strategies for Adopting Spot Instances

Once the per-hour billing myth is no longer a barrier, the next step is adopting Spot Instances with a strategy that accommodates the interruption risk — not a cost risk.

flowchart TD
    A[New workload] --> B{Stateless & retryable?}
    B -- No --> C[Consider On-Demand or Reserved]
    B -- Yes --> D{Tolerant of sudden interruption?}
    D -- Not at all --> C
    D -- Yes, with graceful handling --> E[Strong candidate for Spot Instances]
    E --> F[Combine with Mixed Instance Policy / Spot Fleet for redundancy]

Several approaches commonly used to add resilience when adopting Spot:

• Mixed Instance Policy on Auto Scaling Groups — combining Spot and On-Demand in one group, so if Spot capacity for one instance type is unavailable, the group can still fall back to On-Demand or another Spot instance type.
• Spot Fleets with instance type diversification — reducing the risk of all instances being interrupted at once by spreading requests across several instance types and availability zones.
• Interruption handlers at the application level — using the roughly two-minute window from the interruption notice to checkpoint, deregister from the load balancer, or move in-flight jobs.

A short checklist before deciding to use Spot Instances: the workload doesn’t store important state locally, the process can be restarted or retried without side effects, and there’s a mechanism (whether from AWS services or custom) to handle interruption gracefully.

Summary

• The myth “Spot Instances are charged 1 hour even when they only run 17 minutes” was indeed fact before 2017, but has been obsolete since AWS introduced per-second billing.
• EC2 Linux (On-Demand and Spot) is billed per second with a 60-second minimum charge — no rounding to a full hour under any condition afterward.
• The difference between Spot and On-Demand is purely about availability — Spot can be terminated by AWS at any time — not about the billing model.
• Bills that look hourly often come from other resources like NAT Gateways, Application Load Balancers, or idle Elastic IPs, not from the EC2 itself.
• EC2 Windows still bills per hour, and that also applies to Spot — this edge case is valid but rarely relevant for modern Linux-based workloads.
• When AWS terminates a Spot Instance, costs are counted until the last second the instance was alive, with no termination fee.
• AWS Cost Explorer and the Cost and Usage Report are the most objective way to verify billing granularity directly from your own account data.
• Spot Instances are ideal for stateless, retryable workloads like CI/CD runners, batch processing, and queue workers — combine them with Mixed Instance Policy or Spot Fleets to add interruption resilience.