On-Demand Pricing: Paying Only for the Seconds You Run

On-demand pricing is the list price for cloud capacity with no commitment attached. AWS puts it this way: with On-Demand Instances “you pay for compute capacity by the second with no long-term commitments”, and only for the seconds an instance is in the running state, with a 60-second minimum. Google Cloud and Azure call the same model on-demand and pay-as-you-go respectively. Every discount program, from spot to reservations, is priced as a reduction from this rate, which is why it is the baseline for every cost comparison.

How each provider meters it

AWS EC2. Charges stop as soon as an instance moves to shutting-down or terminated, and each start of a stopped instance is billed for at least one minute. Partial instance-hours are billed per second for Linux, Windows, Windows with SQL Server, RHEL and Ubuntu Pro instances, with a 60-second minimum. SUSE Linux Enterprise Server instances are the documented exception and are billed as a full hour.

Google Compute Engine. vCPUs, GPUs and memory are charged a minimum of one minute; Google’s example is that a VM run for 30 seconds is billed for one minute. After the first minute, billing is in one-second increments.

Azure Virtual Machines. Microsoft’s VM states page is the clearest guide to when the meter runs. A VM that is Stopped from inside the guest OS (or via the PowerOff operation) is still allocated and still billed. Only Stopped (deallocated), where the VM has released its lease on the underlying hardware, stops the compute charge.

What on-demand does not stop billing for

Per-second compute billing makes it tempting to assume a stopped machine costs nothing. It does not:

• AWS states that you are not charged for usage or data transfer of a stopped instance, but “charges are incurred to store Amazon EBS storage volumes”, and Elastic IP addresses associated with a stopped instance are charged.
• Stopping an EC2 instance loses data on instance store volumes and in RAM; only EBS volumes persist. You also cannot stop an instance whose root volume is instance store.
• Google warns that after you stop a Compute Engine instance “you keep incurring charges for any resources that remain attached to it”, such as persistent disks.
• On Azure, a guest-OS shutdown leaves the VM in the billed Stopped state; you need a deallocate.

When on-demand is the right price

On-demand costs the most per hour but carries no obligation, which makes it correct for:

• Part-time capacity. Development, test and demo environments that run business hours only. A 50-hour working week is about 217 hours of a 730-hour month, and on-demand is the only model where those unused hours cost nothing for the compute itself.
• New or changing workloads whose steady size is not yet known. Commit only once a usage floor has held.
• Burst above a commitment. AWS and Azure both bill usage above a savings plan commitment at on-demand or pay-as-you-go rates, so on-demand is also the overflow price.

The workloads that should move off it are the opposite: capacity that runs every hour of every day (a commitment candidate) and fault-tolerant batch work (a spot candidate). The trade-off between keeping part-time capacity on-demand and committing to always-on capacity is worked through in Scheduling vs Reserved Instances.

Where ZopNight fits

ZopNight uses the providers’ pricing APIs (AWS Pricing and Azure Retail Prices) to compute an hourly rate for each resource and multiplies it by time in the running state, so the cost of an on-demand machine tracks its actual uptime; where billing sync is configured, the billed cost replaces that rack rate per resource-day. Start/stop scheduling handles provider-specific operations such as Azure deallocate rather than a guest shutdown. See scheduling Azure VMs or scheduling EC2.