What Is Amazon EC2 On-Demand Pricing and How Is It Calculated?

Amazon EC2 On-Demand pricing is a pay-as-you-go billing model that allows users to pay for compute capacity by the hour or by the second without any long-term commitments or upfront payments. This article explores how the On-Demand pricing model works in Amazon Elastic Compute Cloud, the factors that influence instance rates, how billing increments are structured across different operating systems, and the mathematical formulas used to calculate total compute costs.

Understanding the Amazon EC2 On-Demand Pricing Model

Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the Amazon Web Services (AWS) cloud. Among its various purchasing options—such as Reserved Instances, Savings Plans, and Spot Instances—the On-Demand pricing model is the default and most flexible option.

With On-Demand instances, you only pay for the exact time your instances are in a running state. There are no minimum spend commitments, long-term contracts, or upfront fees. You have full control over the lifecycle of the instance, deciding when to launch, stop, hibernate, start, or terminate it. When you stop or terminate an instance, compute billing stops immediately, although any attached storage volumes like Amazon Elastic Block Store (EBS) may continue to incur storage charges until deleted.

Key Factors That Determine On-Demand Rates

Before calculating the total cost of an On-Demand instance, it is important to understand the variables that dictate the base rate of the instance:

  • Instance Type and Size: AWS categorizes instances into families based on workload optimization (General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, and Accelerated Computing). Within each family, the size (such as large, xlarge, or 2xlarge) determines the number of virtual CPUs (vCPUs), memory (RAM), network performance, and local instance storage. Generally, doubling the instance size within the same family doubles the price.
  • AWS Region: Prices vary depending on the geographic location (Region) of the data center due to local infrastructure, energy, and operational costs.
  • Operating System and Software Licensing: Instances running open-source Linux distributions (such as Amazon Linux, Ubuntu, or Debian) carry the lowest base rates because they do not include commercial licensing fees. Instances running Microsoft Windows Server, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), or pre-installed commercial software (like SQL Server) have higher rates to cover license costs.
  • Tenancy: By default, On-Demand instances run on shared hardware (Shared Tenancy). If compliance or licensing requires Dedicated Instances or Dedicated Hosts, additional hourly charges or higher per-instance rates apply.

How Billing Increments Work: Per-Second vs. Per-Hour Billing

AWS calculates On-Demand usage using either per-second or per-hour billing increments, depending on the operating system and how the software is licensed:

  1. Per-Second Billing: Applies to instances running open-source Linux distributions (Amazon Linux, Ubuntu), Windows Server, and Red Hat Enterprise Linux (RHEL). Per-second billing features a 60-second (1-minute) minimum charge every time an instance is launched or started from a stopped state. After the first 60 seconds, usage is billed down to the exact second.
  2. Per-Hour Billing: Applies to specific commercial distributions or third-party AWS Marketplace AMIs that do not support per-second billing. Under per-hour billing, any partial hour of usage is rounded up to the nearest full hour. Even if an instance runs for only 10 minutes before being stopped, it is billed for a full hour. Note that if you stop and restart an instance multiple times within the same clock hour under per-hour billing, each start triggers a new one-hour billing minimum.

How to Calculate Amazon EC2 On-Demand Costs

Even when an instance is billed by the second, AWS publishes its On-Demand prices as an hourly rate (\(R_{\text{hour}}\)). To calculate the exact cost of an instance, you convert the running duration into hours or convert the hourly rate into a per-second rate.

1. Per-Second Billing Formula

For instances eligible for per-second billing (assuming the instance runs for at least the 60-second minimum), the total compute cost (\(C_{\text{total}}\)) is calculated by multiplying the published hourly rate (\(R_{\text{hour}}\)) by the total number of seconds the instance ran (\(t_{\text{seconds}}\)) divided by \(3600\) seconds per hour:

\[C_{\text{total}} = R_{\text{hour}} \times \left(\frac{\max(t_{\text{seconds}}, 60)}{3600}\right)\]

If you run \(N\) identical instances simultaneously for the same duration, the formula becomes:

\[C_{\text{total}} = N \times R_{\text{hour}} \times \left(\frac{\max(t_{\text{seconds}}, 60)}{3600}\right)\]

Example Calculation (Per-Second Billing)

Suppose you launch a Linux m6i.large instance with an On-Demand rate of \(\$0.096\) per hour. You run a batch processing job that takes exactly 2 hours, 15 minutes, and 30 seconds, and then terminate the instance.

First, convert the total running time into seconds:

\[t_{\text{seconds}} = (2 \times 3600) + (15 \times 60) + 30 = 7200 + 900 + 30 = 8130 \text{ seconds}\]

Next, apply the per-second billing formula:

\[C_{\text{total}} = \$0.096 \times \left(\frac{8130}{3600}\right) = \$0.096 \times 2.258333 = \$0.2168\]

Your total On-Demand compute charge for that workload is \(\$0.2168\) (rounded to the nearest cent on the monthly invoice).

2. Monthly Continuous Usage Calculation

If you plan to run an On-Demand instance continuously for an entire month, AWS pricing calculators standardize a month as \(730\) hours (calculated as \(\frac{365 \text{ days} \times 24 \text{ hours}}{12 \text{ months}}\)). In practice, a specific calendar month will have \(672\) hours (28 days), \(696\) hours (29 days), \(720\) hours (30 days), or \(744\) hours (31 days).

Using the standard 730-hour average, the monthly cost (\(C_{\text{month}}\)) is:

\[C_{\text{month}} = N \times R_{\text{hour}} \times 730\]

For a single instance at \(\$0.096\) per hour running continuously:

\[C_{\text{month}} = 1 \times \$0.096 \times 730 = \$70.08\]

3. Unlimited Mode Charges for Burstable Instances (T-Family)

If you use burstable performance instances (such as t3, t3a, or t4g), On-Demand pricing includes an additional calculation if the instance runs in Unlimited mode and exceeds its baseline CPU utilization over a 24-hour period.

When average CPU usage exceeds the baseline and accrued CPU credits are exhausted, you pay a flat surplus rate per vCPU-hour (\(R_{\text{vCPU}}\)). The total cost is the base On-Demand compute cost plus the surplus CPU cost:

\[C_{\text{burstable}} = C_{\text{total}} + \left(\text{Surplus vCPU-Hours} \times R_{\text{vCPU}}\right)\]

Additional Costs Associated with EC2 Instances

When calculating the full cost of running an Amazon EC2 workload, the On-Demand instance rate only covers the compute capacity (vCPU and memory). A complete total cost of ownership (TCO) calculation must also factor in peripheral services:

  • Amazon EBS Storage: Charged per gigabyte-month (\(\text{GB-month}\)) provisioned, plus additional charges for provisioned IOPS or throughput depending on the volume type (such as gp3 or io2). EBS charges continue even when the EC2 instance is in a stopped state.
  • Public IPv4 Addresses: AWS charges an hourly fee (\(\$0.005\) per hour) for all public IPv4 addresses associated with your account, whether attached to a running EC2 instance or idle as an unattached Elastic IP address.
  • Data Transfer: Data transferred into EC2 from the internet is generally free, while data transferred out to the internet or across different Availability Zones and Regions is billed per gigabyte (\(\text{GB}\)).

\[C_{\text{complete}} = C_{\text{compute}} + C_{\text{storage}} + C_{\text{IPv4}} + C_{\text{data\_transfer}}\]

When to Use the On-Demand Pricing Model

Because On-Demand pricing does not offer the volume discounts of Savings Plans (up to 72% off) or Spot Instances (up to 90% off), it is best suited for specific operational scenarios:

  • Unpredictable or Spiky Workloads: Applications with short-term, irregular, or erratic traffic patterns that cannot be forecasted in advance.
  • New Application Development and Testing: Environments where developers spin up instances for a few hours to test code or benchmark instance types before committing to a 1-year or 3-year Savings Plan.
  • Mission-Critical Short-Term Jobs: Workloads that only run briefly (from a few minutes to a few days) where the job cannot tolerate the interruption risk of Spot Instances.