Tracking cloud cost

Turbonomic tracks your cloud costs based on the cost information it discovers from targets (for example, accounts, billing reports, and on-demand or discount costs) and price adjustments.

Note:

It is possible for Turbonomic to report negative amounts. For example, when discounts are larger than costs, the result is a negative amount. Currently, these amounts are not shown directly in cost-focused charts (such as the Expenses charts). To check for any negative amounts, hover on a data point in a chart and then review the data in the tooltip.

Cost for services

Turbonomic uses the billing reports from your cloud service providers, as they are associated with your cloud targets. Turbonomic parses these reports to get cost breakdowns by service, service provider, Azure Resource Group, and cloud account. You can see cost data in the Expenses charts and Cost Breakdown by Tag charts.

Workload expenses

Workloads are the VMs running in your environment, or other hosted processes such as database servers and containers. Turbonomic tracks the following expenses for your workloads:

  • Compute

    For compute expenses Turbonomic uses hourly expense per template as specified in the associated public cloud account.

  • Storage

    Turbonomic discovers the storage tier that supports a given workload, and uses the tier pricing to calculate storage cost.

  • License

    For AWS environments, Turbonomic can calculate OS costs. To calculate the OS cost for a VM, Turbonomic subtracts the template cost from the published workload cost. It assumes the difference is the license cost for that workload. If the OS is open source, then there will be no difference, and license cost is zero. Analysis does not consider AWS Marketplace costs.

    For Azure environments, Turbonomic can track OS costs for existing VMs. For actions to purchase reservations, Turbonomic does not include the OS cost. Analysis considers the base OS cost, but does not consider additional costs for support or other add-on features that are bundled with the OS. The affected OS types are Ubuntu PRO, SUSE 24/7, and RHEL with HA.

Turbonomic uses this cost information when making scaling decisions, both in real time and in plans. You can see this information in Expenses charts and in the results of Migrate to Cloud plans.

Costs for dedicated tenancy on AWS

When you create VMs on AWS, you can specify their tenancy. When you specify Dedicated Tenancy (DT), the VMs you create are Amazon EC2 instances running on hardware that is dedicated to a single customer. To understand DT in the context of Turbonomic, you should consider:

  • For AWS, the Turbonomic supply chain shows an Availability Zone as a Host. The supply chain does not indicate whether certain VMs have tenancy dedicated to specific resources in the given availability zone. Also, Turbonomic does not discover or show the costs for dedicated hosting of your workloads.

  • Pricing for DT workloads is different than pricing for Shared Tenancy. Turbonomic does not discover that difference, and uses Shared Tenancy cost for the DT workloads. In action descriptions, the listed savings or investments will be based on Shared Tenancy costs.

  • Turbonomic discovers the true costs of RIs for DT workloads. However, because the on-demand VM costs are based on Shared Tenancy, Turbonomic can overstate the savings you would get for purchasing and using RI capacity. In most cases, recommendations to purchase RIs will be correct. However, the time to achieve ROI could take longer than action descriptions and charts indicate.

  • Some instance types that are valid for Shared Tenancy are not valid for DT. To see which instance types are valid for your DT VMs, consult the AWS documentation or your AWS representative.

  • Under some circumstances Turbonomic can recommend changing a workload to a valid instance type for the tenant, even though the current type is already valid. This can happen when the instance type is not included in the Offer File for the tenancy. For example, assume the t3a template family does not support dedicated tenancy. However, assume that the user created a t3a instance with dedicated tenancy in the EC2 console. In that case, Turbonomic will see this as a misconfiguration and recommend changing to a different instance type.

To address these issues, you can create groups that set a scope to your DT workloads. For example, you can use naming conventions, tagging, or other means to identify your DT workloads. Then you can create dynamic groups based on those indicators. With those groups, you can create policies and dashboards that correspond to the differences you see in your DT environment. Use this approach to address issues for:

  • Available Instance Types

    To resize a workload, Turbonomic generates an action to change that workload to a different instance type. Because Turbonomic does not discover the difference between instance types that are valid for DT and for Shared Tenancy, it can recommend scaling a DT workload to an unavailable instance type. To avoid this, create a policy for the DT group, and exclude the unavailable instance types.

  • Displaying Costs

    Turbonomic charts show the costs for your environment. If the scope includes Dedicated Tenancy workloads, then the calculated cost will be incomplete. For example, since AWS does not return pricing data for converted RIs (that is, RIs that have been exchanged at least once) that are on All Upfront payment plans, Turbonomic does not include such RIs in its calculations of RI utilization or cost.

    Use scope to minimize this effect. You can create separate dashboards for your DT and Shared Tenancy workloads.