Step 1
Right-size CPU and memory before comparing providers
Start with the workload requirement, not the provider's product catalog. If an application needs 2 vCPU and 8 GB memory, compare that request first. If a provider selects a larger fixed shape, keep the extra capacity visible rather than manually forcing a smaller instance that would not meet the memory target.
- Check whether the selected result is exact sizing or closest available shape.
- Run a smaller and larger scenario if utilization history is weak.
- Separate latency-sensitive workloads from batch workloads; they often optimize differently.
- Do not compare burstable instances against fixed-performance shapes without noting the tradeoff.
Step 2
Model runtime hours honestly
Always-on production systems usually belong near 730 monthly hours, but development, testing, training, and proof-of-concept systems often do not. Reducing runtime hours can change the ranking between providers, especially when storage and licenses remain monthly while compute is stopped.
Always-on service730 h/mo baseline
Business-hours devAround 176 h/mo
Weekend batchUse custom monthly hours
Stopped VMCompute can stop, storage can remain
Step 3
Review storage class, capacity, and access pattern separately
Storage is often treated as a minor add-on during VM sizing, but it can dominate monthly cost for database, analytics, media, and backup workloads. Compare block storage class and size first, then decide whether object or file storage belongs in the same estimate.
- Use balanced SSD for general-purpose disks unless the workload needs higher performance.
- Keep archive object storage separate from hot object storage because retrieval behavior changes the bill.
- Add file storage only when a shared filesystem is part of the architecture.
- Record snapshot, backup, and replication assumptions outside the VM comparison if they matter.
Step 4
Treat Windows and BYOL as separate scenarios
Operating-system licensing can be the difference between two otherwise similar estimates. Run Linux, Windows PAYGO, and Windows BYOL as separate scenarios when the workload could plausibly use more than one license model. BYOL can be valid for some customers, but Stratos does not verify eligibility.
If the selected provider exposes a real Windows meter, Stratos separates the OS/license component from base compute. If a meter is unavailable, the provider result should be treated as incomplete rather than manually patched with a guessed license cost.
Step 5
List the costs that are intentionally outside Stratos
A clean VM comparison can still miss the service that drives the final invoice. Before using a result as a budget number, write down which surrounding items still need provider-specific modeling.
NetworkEgress, NAT gateways, load balancers, private links
OperationsMonitoring, logs, backups, snapshots, support plans
PlatformManaged databases, Kubernetes control planes, queues, caches
CommercialCredits, private discounts, taxes, currency conversion