Comparing compute pricing units with realistic workloads

To compare compute costs, hold the application action, demand and response-time requirement constant, then express the workload in each service’s billable units. EC2 On-Demand bills running instance time, a dedicated Azure App Service plan bills allocated VM-instance time, and Cloud Run bills request processing or the full instance lifecycle, depending on its billing setting. Multiply each quantity by the rate for the selected configuration and region to estimate compute cost.

Build one workload sheet

For normal, busy and quiet months, record operating hours, requests or jobs, concurrency, processing time, memory demand, storage, outbound data and the capacity needed for an acceptable response time. Keep storage and data transfer quantities separate from compute.

Include development and test environments if they stay running, and keep forecasts separate from observed quantities. Use the same workload assumptions when assessing each service.

For example, two EC2 instances running throughout a hypothetical 30-day month represent 2 × 24 × 30 = 1,440 instance-hours. The compute charge uses the selected instance type, operating system and region rate, before storage or networking charges.

Compare the billing models

EC2 On-Demand charges for running seconds at a fixed per-second price, with a 60-second minimum. EBS is billed separately by provisioned capacity, with extra charges for IOPS or throughput beyond baseline levels.

A dedicated Azure App Service plan charges an hourly rate based on its pricing tier, apportioned to the second for each VM instance while it is allocated. Apps in the same plan share compute resources, so low traffic to an individual app does not by itself stop the plan charge.

Cloud Run request-based billing covers instance processing, startup and shutdown; instance-based billing covers the full instance lifecycle, including time without requests. Its charges are rounded up to the nearest 100 milliseconds and depend on region and billing configuration.

Cloud Run scales to zero by default when there is no traffic, while minimum instances can keep instances idle. Assess vCPU-seconds, GiB-seconds and requests under the selected billing setting, including the effect of any minimum instances.

For one shared, always-on workload, assume two instances run or remain allocated for all 24 hours of a hypothetical 30-day month, with each configuration tested to handle the same application action and demand. That gives 2 × 24 × 30 = 1,440 instance-hours in each option.

For EC2, express those 1,440 instance-hours as the corresponding running seconds and multiply by the selected instance type, operating system and region’s fixed per-second rate. The 60-second minimum does not change this continuous-running workload calculation.

For App Service, the workload represents 1,440 allocated VM-instance hours. Multiply each instance’s allocated time by the selected tier’s hourly rate, prorated to seconds.

For instance-based Cloud Run, convert the same duration into instance-seconds. Calculate vCPU-seconds as 1,440 × seconds per hour × vCPUs per instance and GiB-seconds as 1,440 × seconds per hour × GiB per instance, then multiply each quantity by its selected regional rate and apply the free tier.

For request-based Cloud Run, use the workload’s request processing, startup and shutdown usage instead of the full instance lifecycle. Apply the selected rates to its vCPU-seconds, GiB-seconds and requests.

Add the missing lines

Include applicable persistent storage, data transfer and supporting services in each estimate. For EC2, price EBS provisioned capacity and any IOPS or throughput above baseline; EBS charges can continue while an EBS-backed instance is stopped.

The AWS Free Tier includes 30 GB of EBS storage, 2 million I/Os and 1 GB of snapshot storage. Azure App Service can have separate charges for storage used by diagnostic logs.

For Cloud Run, include applicable network transfer and Serverless VPC Access connector compute. There is no charge for data transfer to Google Cloud resources in the same region, such as traffic between Cloud Run services.

Cloud Run’s free tier is applied before the bill is calculated; its usage is aggregated across projects by billing account and resets each month. Require each proposed configuration to complete the same application action at the same demand level rather than forcing different services into an identical hardware label.

Key Cost Factors by Platform (Australia)

Calculate and challenge the estimate

For each normal, busy and quiet month, multiply the applicable billable quantities by the current rate for the selected configuration and region, then add the lines. For the shared workload, use the instance-time and resource-unit quantities above.

Use the AWS Pricing Calculator for EC2, the calculator on the Amazon EBS pricing page for EBS and architecture costs, the Azure pricing calculator for App Service, and the Google Cloud pricing calculator for Cloud Run.

Pin down the configuration before comparing results: EC2 instance type and operating system; App Service region, tier, VM size and instance count; or Cloud Run region, billing setting, resource allocation and minimum instances. Keep Cloud Run’s free-tier assumptions consistent across scenarios.

For an Australian purchase, record the billing currency, any conversion assumptions and whether quoted amounts include GST. Compare amounts on the same tax basis.

Test each proposed configuration against the workload and update the quantities the test reveals, including capacity, instance count, execution time and transfer. Recalculate each scenario using the updated quantities and current rates.