About CloudPriceFinder

Data Collection

Pricing data is collected periodically using Python scripts. Official public pricing APIs are used where available; web scraping is used where no machine-readable API endpoint exists.

Price Normalisation

All prices are converted to USD at the time of collection. Original currency values are preserved in the raw data. Prices displayed are effective hourly rates — for commitment pricing this is the total cost amortised to an hourly equivalent (e.g. a 1-year upfront payment divided by 8,760 hours).

Derived Metrics

• $/vCPU/hr Effective hourly price ÷ vCPU count. Lower means better cost-efficiency per CPU core — useful for CPU-bound workloads.
• $/GiB/hr Effective hourly price ÷ memory in GiB. Lower means better cost-efficiency per gigabyte of RAM — useful for memory-intensive workloads.
• Savings % Percentage reduction vs the same instance's on-demand price: (1 − effective_hourly / on_demand) × 100.

Commitment Pricing

For AWS, commitment options include Reserved Instances (1yr/3yr, Partial/No/All Upfront) and Savings Plans. For Azure, Reservations are shown. For GCP, Committed Use Discounts (CUDs) are included. OCI commitment pricing is managed via Universal Credits at the account level and is not available per-instance. OVH, Scaleway, Vultr, and VAST do not publish public commitment or reserved pricing — only on-demand prices are shown for these providers.

Data Freshness

Data is refreshed periodically. The "Last Updated" date shown on the homepage reflects when the data was last collected. Pricing changes made by providers between updates will not be reflected until the next refresh.

Cross-Provider Equivalent Matching

When you open the Compare page or expand a row, CloudPriceFinder suggests equivalent instances from other providers. These suggestions are computed automatically — here's how, and what the limits are.

Instances are grouped into families (e.g. AWS m7i, Azure D-v5). For each family we compute a representative point — the trimmed median vCPU and RAM across the middle 60% of the family's sizes — to avoid large or small outliers skewing the result.

To find the closest equivalent in another provider, we compare that representative point against every individual instance in the target provider using Euclidean distance in log₂(vCPU, RAM) space. A log scale is used so that the difference between 2 and 4 vCPU is treated the same as between 64 and 128 vCPU. We then pick the target provider's family that contains the closest matching instance.

Two filters prevent bad matches from appearing:

• Distance limit: if the closest instance is more than ~2× different in both vCPU and RAM simultaneously, no match is shown. A genuine mismatch — such as a 2 GiB family being forced onto a 16 GiB family — scores well above this threshold and is filtered out.
• RAM-per-vCPU band: the GiB-per-vCPU ratio of the source and target must be within 3×. This prevents compute-optimised families (≈ 2 GiB/vCPU) from being paired with memory-optimised families (≈ 16 GiB/vCPU).

Matching is profile-based (vCPU + RAM only). It does not account for CPU generation, network throughput, storage type, GPU presence, or burstability. Families with no close counterpart in another provider — such as AWS's 16 TB+ bare-metal instances — will show no suggestion rather than a forced bad match. Always review the full instance spec before treating a suggestion as a direct substitute.