IaaS Cloud Pricing
About Cloud Pricing
The IaaS Cloud Pricing feature simplifies the process of pricing and comparing cloud providers by determining the instance types that best fit the workloads in the environment, and the base costs associated with those instances.
The core functionality of the IaaS Cloud Pricing feature is its ability to determine which instance type for a given provider best fits a system. There are two types of instance matches, based on differing data, inventory and usage.
- Inventory matching compares the resources present and usable (provisioned) by the device against the various cloud instances, to provide a match on what is already present in the environment. However, many systems may not be utilizing the full potential of the hardware.
- Usage matching determines the instance type that is the best fit for the actual workload (performance) of the system, based on the data collected during the performance collection period of the assessment.
Instance matching is based solely on CPU and memory, so storage pricing is not a component of which instance a device best matches. Currently, storage cost is based on inventory data, so the inventory and usage matching will be the same. Instances typically include some storage built into the virtual machine for use as the root volume of the system, and is included in the base cost of the instance.
When calculating the storage cost for a device for a given provider, any storage included in the instance is deducted from a system's reported storage prior to calculating the cost. For instance, if a system has 200 GB of storage and matches an instance with 40 GB of included storage, storage cost is calculated for 160 GB.
The quantity of storage calculated for a system is the summation of all locally attached storage, using the total size of each volume rather than utilized storage, from which any included instance storage is subtracted as explained above.
The Storage Cost field of the IaaS Cloud Pricing page reports the cost per hour.
- By default (no flow data is being collected) we calculate the total bytes that each server sends (by watching its network interfaces through polling) in a given month and then apply the cloud provider’s cost to that number for a month. We then divide back to get the cost per hour. This assumes that ALL traffic leaving any server’s interface is charged traffic. So traffic between two servers in a stack will be counted even though it will not wind up being charged once migrated. Our Network costs are considered “worst case” scenarios. If you capture flow data, however, then we ARE able to discern which traffic leaves the stack and to which other stacks (infra services, on premise dbs, etc) it goes. You can then model the true network cost based on what you are migrating at any given point.
- If Netflow (Flow) data is collected – this enables us to see the source and destination of traffic on the wire and we can then model the network cost more accurately. There is a separate report that is generated to provide this analysis – so that you can model it in different ways and it can be requested via support.
The CloudScape platform field named - Instance Cost - reports the base cost of the matched instance.
Supported Cloud Providers
Google Cloud Platform
Quest Technology Management
Cloud Pricing Values
The following is a list of the information generated by the CloudScape cloud pricing module and reported to the user for each server for both inventory and usage based matching.
- CPU Calculation
- Memory Calculation
- Storage IO
- Network IO
- Total Daily Cost
View the Cloud Pricing Change Log