Frequently Asked Questions

This filter is specific to reserved instance purchases.

Within the Health Check Report, the Fully Optimized Purchase section displays the highest possible savings (e.g., $85,774) that will be achieved assuming you make the upfront reservation purchase (e.g., $510,065).

CloudHealth scans your infrastructure to determine your on-demand EC2 usage and then recommends the optimal up-front reservation purchase to cover that usage. But because of budgeting constraints, not all businesses can make the fully optimized upfront payment.

CloudHealth uses the setting in the % Fully Optimized filter to calculate savings with a budget that allows for the same percentage of the optimal purchase price.

In the CloudHealth platform, Non-Recurring Costs are those costs for which the Item Description field has one of these values:

• Sign up charge for subscription
• Hours purchased
• Tax of type
• Recurring Fee
• Prorated recurring fee
• AWS re:Invent Ticket
• AWS Support

In addition, CloudHealth looks at the product and usage_type columns to filter out any line items with the following values:

• product = "PN_REDSHIFT" AND usage_type =~ "HeavyUsage"
• product = "PN_RDS" AND description =~ "hourly fee per"

These two filters are used for RedShift All Upfront and RDS Heavy Reservation unused charges (Legacy type of RDS RI).

aws_volumes.iops - (max_VolumeWriteOps + max_VolumeReadOps)

As part of the configuration settings for generating volumes in AWS, you have to preselect the amount of IOPS you’d like provisioned into the volume. Amazon then bills you for that corresponding amount provisioned IOPS (PIOPS). When you don’t execute enough reads and writes on the volumes, the volumes are underutilized and PIOPs are classified as wasted.

So if a volume has 3000 PIOPS, and for the given interval, the max write + max read IOPS is only 1000, then that volume has 2000 wasted PIOPS.

Projected Cost for AWS

For AWS, CloudHealth calculates the Projected Cost as the sum of the following individual costs:

• Already incurred costs: Current month's month-to-date (MTD) costs, excluding support & unused RI costs
• Projected unused RI costs: Previous month's unused RI costs. The assumption here is that the same amount of unused RI costs will be incurred in the current month.
• Projected recurring costs: (Number of days remaining in the current month) x (Weighted average of previous and current month's recurring costs). The assumption here is that for every day in the remainder of the month, the daily average recurring costs will be similar to those incurred in the previous month / MTD costs.

• Projected support costs

  • For direct customers who do not receive bills from a Partner, this cost is derived from the sum of the projected non-support costs as follows: (a) AWS Support cost is increased as a proprotion of the total cost, (b) the "projected non-support costs" are used to project "support costs."
  • For customers who receive bills from a Partner, this cost is derived from previous month's support costs. The costs are adjusted to reflect custom support costs in Partner-generated bills. It is also assumed that the support costs are similar to those incurred in the previous month.

Projected Cost for Other Clouds

The projected cost is the sum of the following individual costs:

• Already incurred costs: Current month's month-to-date (MTD) costs, excluding support & unused RI costs.
• Projected recurring costs: (Number of days remaining in the current month) x (Weighted average of previous and current month's recurring costs). The assumption here is that for every day in the remainder of the month, the daily average recurring costs will be similar to those incurred in the previous month / MTD costs.

As such, the Projected Cost is merely a guide that becomes more accurate as the month progresses and more actual MTD data is available. CloudHealth does not calculate the Projected Monthly Cost for Reserved Instance purchases.

You do not have to create a new user and insert the proper policy if you do not want to, but you can. If you wanted to create a consistent standalone IAM user within each account that will have the privileges to Purchase Reservations and receive the Temporary Secure Token, then create the user and enter in this policy:

   {
      "Version": "2012-10-17",
      "Statement": [
       {
       "Effect": "Allow",
       "Action": [
          "ec2:DescribeReservedInstancesOfferings",
          "ec2:PurchaseReservedInstancesOffering",
          "ec2:ModifyReservedInstances",
          "rds:DescribeReservedDBInstancesOfferings",
          "rds:PurchaseReservedDBInstancesOffering",
          "sts:GetFederationToken"
       ],
       "Resource": "*"
       }
       ]
    }

Make sure you validate the policy after editing it.

This policy, with the corresponding Access and Secret Key for the user, gives CloudHealth the ability to look into that account, get the token, and execute the purchase within a 15-30 minute interval.

This policy also includes the ability to modify reservations. This way, you have a CloudHealth RI Management User. Save the Access Key and Secret Key so that you can enter the credentials in whenever you want to execute purchase actions.

Use the RI Optimizer to evaluate your AWS instance usage and determine if you can benefit from the use of reserved instances. The Optimizer analyzes current and historical on-demand usage of instances on a hourly basis. It then displays high-level and detailed reserved instance purchase recommendations. Purchases are recommended and made in the form of quotes that you can modify, delete, or execute.

Use the RI Analyzer to get an overview of what reserved instance usage looks like in your environment. The information reported is based on analyzing hourly reserved usage based on your Amazon Detailed Billing Record. The Analyzer displays the number of instances within the environment, the number of reservations, the percentage of hourly instance usage in the month that was covered by a reservation, and the total savings per month from the usage of reserved instances.

When using the EC2 RI Optimizer for making a purchase, you might see the purchase action fail with an error similar to the following:

Encountered error: Your current quota does not allow you to purchase the required number of reserved instances when attempting to purchase reservation: Partial Upfront for 11 r3.4xlarge(s)...

The error occurs because you have reached the quota limit that AWS assigns for certain instance types in a region for an account.

You can resolve this error by requesting your AWS representative to increase your quota limits for those instance types in that region.

Preferably not. Although purchasing reservations in the consolidated billing account has the advantage of simplifying the purchase and management of reservations, because reservations have the ability to float through linked accounts, you may not be able to launch a reserved instance in the same account that you purchased the reservation for.

The best practice is to purchase reservations in the accounts in which the attributes of the reservation match the running instances that will be utilized in that account. By purchasing reservations in the linked accounts, you ensure that the discounted reservation rate are applied to the desired instances within the desired account.

For more information, see Accounts and Billing.

Your AWS account has hit a service limit in regards to RI purchases. In order to resolve this error, open a ticket with AWS support. For instructions on creating this ticket, see AWS Service Limits.

The CloudHealth platform assumes that an Authorizer fulfills these requirements:

• They have the basic privileges required to make Reserved Instance purchases.
• They can receive a Secure Temporary Token that will allow CloudHealth to execute the purchase on their behalf.

If you want to purchase RIs for only specific accounts, you can apply a filter for that account in your purchase quote. When you execute the quote, a confirmation email is sent to the Authorizer, who must provide an Access Key and Secret Key for each account.

Ensure that the Authorizer has sufficient privileges to at least purchase RIs within your accounts.

1. Login to the AWS Console. Select Services > IAM and select Users from the left menu.

2. Select the user who you want to assign as Authorizer. In the user management console, click the Permissions tab.

3. Expand the user policy to which you want to add Authorizer privileges and click View and edit policy.

4. In the Policy Document tab, click Edit and add these privileges.

   The ability to purchase RIs.

   {
   "Effect": "Allow",
   "Action": [
       "ec2:DescribeReservedInstancesOfferings",
       "ec2:PurchaseReservedInstancesOffering"
       ],
   "Resource": "*"
   }
   

   The ability to receive the temporary token, allowing CloudHealth to execute the action on behalf of the user.

   {
   "Effect": "Allow",
   "Action": "sts:GetFederationToken",
   "Resource": "*"
   }
   

5. Click Validate Policy to test the changes.

There is no cost associated with an RI Modification. However, modifying instance types does lead to instances switching on and off, a process that incurs minimal costs.

You can divide a reservation containing larger instance types into smaller ones. For example, you can convert 5 m3.large reservations into 10 m3.medium reservations.

You can also combine more than one reservation containing smaller instance types into larger ones. For example, you can convert 10 m3.medium reservations into 5 m3.large reservations, provided the reservations being combined have the same expiration date and time.

For more information, see Considerations When Managing RIs.

• Network
• Storage
• Telemetry
• Compute
• Object Store
• Compartment
• Oracle Cloud Infrastructure VM Instance
• Tenancy

• App Service
• App Service Environment
• App Service Plan
• Application Gateway
• Application Insights
• Azure IP Address
• Backup Vault
• Batch Account
• CDN Profile
• CosmosDB
• Disk
• Express Route Circuit
• HD Insight Cluster
• Key Vault
• Log Analytics Workspace
• Network Interface
• Recovery Services Vault
• Redis Cache
• Reservation
• Reservation Order
• Resource Group
• Search Service
• Service Bus Namespace
• Snapshot
• SQL Data Warehouse
• SQL Server DB
• Storage Account
• StorSimple Device Manager
• Virtual Machine
• Virtual Machine Scale Set
• Virtual Network
• Virtual Network Gateway

• EC2 Instance
• AWS Image
• Security Group
• EBS Volume
• EBS Snapshot
• AWS Auto Scaling Groups
• Spot Instance Request
• Elastic File System
• Elastic Load Balancer
• EMR Cluster
• RDS Instance
• S3 Bucket
• VPC
• VPC Subnet
• Redshift Cluster
• ElastiCache Cluster
• ElasticSearch Domain
• CloudFront Distribution
• DynamoDB Table
• Workspace
• Kinesis Stream
• Route 53 Hosted Zone

Amazon Web Services

• Accounts
• CloudFormation Stack
• DynamoDB Table
• EC2 Instance
• EC2 Instance Reservation
• Elastic Load Balancer
• S3 Bucket
• RDS Instance
• RDS Instance Reservation
• EBS Volume
• EBS Snapshot
• AWS Image
• Security Group
• EMR Cluster
• VPC
• VPC Subnet
• Redshift Cluster
• Route 53 Hosted Zone
• ElastiCache Cluster
• Spot Instance Request

Microsoft Azure

• Virtual Machine
• Resource Group
• Cloud Service
• IP Address
• Storage
• Security Group
• VM Scale Set
• Virtual Network Gateway
• SQL Server
• SQL Database
• Redis Cache
• App Service Plan
• Service Bus Namespace
• Batch Account
• Virtual Network
• Backup Vault
• Recovery Services Vault
• HD Insight Cluster
• Search Service
• SQL Data Warehouse
• StorSimple Device Manager
• Log Analytics Workspace
• App Service
• Express Route Circuit
• CDN profile
• Snapshot
• Network Interface
• Managed Disk
• App Insight

Google Cloud

• Compute Disk
• Compute Image
• Compute Instance
• Compute Snapshot
• Compute Project

Oracle Cloud

• Network
• Storage
• Telemetry
• Compute
• Object Store
• Compartment
• Oracle Cloud Infrastructure VM Instance
• Tenancy

The allocation of an asset and its related assets to Perspectives and Groups can change depending on how each of them is tagged.

Here's an example. Consider that you have an EC2 Instance (let's call it Instance1) that is tagged as Env = Prod. You also have an EBS Volume (let's call it Volume1) tagged as Env = Dev that is attached to Instance1.

CloudHealth groups these assets in one of two ways, depending on the Asset Type you select when building a Perspective.

Asset Type is Asset: Instance1 is allocated to the Prod group and Volume1 is also allocated to the Prod group, because it is related to Instance1. Asset Type is Any Taggable Asset: Instance1 is allocated to the Prod group and Volume1 is allocated to the Dev group, even though it is related to Instance1.

For AWS users, Perspectives allow you to take full advantage of AWS tags but allows you much greater flexibility by leveraging a resource-based approach to grouping your assets.

You can only have + - = . _ : / @ in your tags.

The CloudHealth platform supports 13 months of historical data.

NOTE: For Oracle Cloud, CloudHealth retains the historical data, starting from May 1, 2020, or from the time the tenant was created in the Oracle Cloud, whichever occurs later. This is because, since May 2020, Oracle Cloud introduced new cost reports for tenants, which include cost data for each resource, and the CloudHealth platform leverages these cost reports.

For all time intervals (hourly, daily, weekly, monthly), CloudHealth runs calculations based on what is present in the AWS DBR at that moment. Unfortunately, the AWS DBR is only an estimate until the end of the month.

During the current billing period (monthly), AWS generates estimated billing reports. The billing reports are not bills, but estimates of costs and charges for AWS usage. Only the monthly invoice you receive each month contains your actual charges.

Due to this method used by AWS, even after a day or week has concluded, AWS may post adjustments to cost and usage for that time period up until the final invoice from AWS is completed, which is usually by Day 5 of the following month.

This delay can result in apparent discrepancies when comparing your reports for the current month (hours, days, weeks, or current month) at different times during the month.

AWS and Azure reports two types of costs.

• Direct Cost: These costs have a resource ID or asset ID associated with them. CloudHealth can attribute these costs to an asset or resource and can therefore allocate them to a Perspective group.
• Indirect Cost: These costs are not associated with a resource ID or an asset ID. Support costs are an example of indirect cost. Therefore, they cannot be attributed to a group.

CloudHealth classifies an AWS or Azure Service as a Direct Cost or Indirect Cost. When AWS or Azure introduces a service, CloudHealth initially classifies the service cost as an Indirect Cost. Then, when support for that service is built into the CloudHealth platform, the service cost becomes a Direct Cost that can be allocated to Perspective Groups.

First define the Cost Allocation view/report that you want by using the "Configure Visualization" tool. Then "Subscribe" to that report and include a comma-separated email list of recipients.

You can subscribe to Daily, Weekly, or Monthly reports.

By default, CloudHealth platform displays reports in UTC time. To change the time zone, click on the profile photo at the upper right corner and select your profile name. Scroll down to Settings and select the preferred Time Zone, then click Save the Profile Changes.

A file called cert.pem is required to successfully run the Aggregator with Secure Sockets Layer (SSL) certificate verification. For more information, see the Integrate with VMware topic.

If cert.pem does not exist and the Aggregator was initially installed as v1.7.30, then the Aggregator fails to run.

However, If cert.pem does not exist and the Aggregator has been upgraded from v1.7.29 to v1.7.30, then the Aggregator runs with no SSL certificate verification. This method is not secure, and CloudHealth recommends completing cert.pem configuration so that the Aggregator can run with SSL certificate verification.

Matching New Relic hosts is complicated because typically, no other metadata associated with a New Relic server exists. The primary assumption during the matching process is that only the server name is available for matching.

Nevertheless, CloudHealth attempts matching based on the following attributes. The attributes are matched in this sequence.

1. EC2 Instance ID
2. EC2 Private IP
3. EC2 Instance Name
4. Instance ID embedded in server name (not an exact match): regex /(i-\w{17}|i-\w{8})/
5. Private IP embedded in server name (not an exact match): regex /(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/
6. Public IP embedded in server name (same regex)
7. Partial instance ID with the 'i-' stripped off embedded in the server name
8. Partial matching using the first part of a dot delimited server name, for example, api-lb1.va.example.net -> api-lb1

If you want to match the New Relic Server name using tags, contact support@cloudhealthtech.com.

The status Late upload indicates that the Agent has not uploaded data to CloudHealth for over 2 hours.

Here are some reasons why the this status appears:

• The Agent was stopped.
• The Agent was uninstalled.
• The Agent crashed (low-likelihood scenario).
• There was a period of network disconnection.

To diagnose the situation, check the log file at /opt/cht_perfmon/cht_perfmon_collector.output.

In addition, check the output of this command:

ls -l /var/lib/chtcollectd/*

The right number of Perspectives varies by organization and depends on your requirements. Typically, organizations tend to require 4 to 6 Perspectives to cover their entire infrastructure. When determining how many Perspectives to create, consider how many lenses you want into your infrastructure on an ongoing basis.

By default, you can create a maximum of 6 Perspectives in the CloudHealth platform. As the number of Perspectives grows, managing asset membership within Perspective Groups incurs a high computational and maintenance cost.

If you need to increase the 6-Perspective limit, contact Support (support@cloudhealthtech.com).

The number of potential Groups in a Perspective varies widely across organizations. Groups offer a powerful way to filter down into specific parts of your infrastructure in CloudHealth InterActive reports, policies, and optimization capabilities. But be careful to not represent every unique attribute of your infrastructure as a Group name. Typically, organizations tend to require fewer than 20 Groups per Perspective.

By default, you can create a maximum of 200 Groups per Perspective in the CloudHealth platform. As the number of Groups grows, managing asset membership within Perspective Groups incurs a high computational and maintenance cost.

If you need to increase the 200-Group-per-Perspective limit, contact Support (support@cloudhealthtech.com).

CloudHealth supports different CloudWatch custom metrics in the Platform depending on your CloudWatch setup.

Once a month has ended, the cloud provider starts its closing process where all of that month’s cost information is finalized and becomes the official bill, which is then generated and invoiced by the cloud provider.

Note: Prior to the last day of the month, all costs and usage information sent by the cloud provider and displayed in the CloudHealth platform is unofficial.

During this closing and invoicing process, there is a delay of up to about 4 business days during which no bills for the new month are delivered by the cloud provider. Many of the reports and features in the CloudHealth platform utilize the cost and usage data displayed in the month-end bill. Therefore, for the first few days of each month, many features tend to be blank or absent until the initial bill for the new month is created and distributed by the cloud provider. During this time, most reports can still be filtered and analyzed for the previous month’s data for forecasting and budgeting purposes.

• For information on AWS, see AWS Billing FAQ.
• For information on Azure, see Azure Understanding Your Bill.
• For information on Google Compute, see Google Cloud Billing Help.

Note that depending on the size of your organization, updating asset information can take up to several hours to complete.

1. Log in to the AWS Billing and Cost Management Console.

2. From the left menu, select Reports.

3. Verify that a Cost and Usage Report has been created using an Hourly interval.

4. In the AWS Console, select Services > S3.

5. Select the S3 bucket that stores the hourly CUR data.

6. Within the bucket, locate the hourly CUR .csv file and download it.

7. Open a terminal session and move to the directory where the CUR .csv is saved.

8. Run this command to break down the CSV data in your terminal: Tail -n 2000 <filename>.csv This command outputs the last 2000 entries of your CSV file in your terminal.

9. The beginning of each output should have the following syntax:

   <instanceID>, <time interval>

   Example: 2m7a5gvrrilqmkhwf5fxgfgd3ao2knj584672dzhmczoya,2017-03-06T06:00:00Z/2017-03-06T07:00:00Z

10. Review outputs to verify that the Time Interval is progressing instead of showing T00:00:00 for all entries. If you see this behavior, you are using your Daily CUR data instead of Hourly Data.

CloudHealth does not support multiple currencies for Azure enrollments. If your Azure enrollments use different currencies, contact your technical account manager.

It is possible that you need to assign a reader role to your reservation orders. For more information, refer to Assign a Reader Role to Azure Reservation Orders.

CloudHealth does not support multiple currencies for Oracle Cloud tenancies. If your Oracle Cloud tenancies use different currencies, contact your technical account manager.

Single-Sign-On (SSO) uses Security Assertion Markup Language (SAML).

SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, particularly between an identity provider (such as Okta, Ping, Azure AD, ADFS, or Google Apps) and a service provider (such as Auth0 or CloudHealth).

An Identity Provider (IDP) is software that is built around managing user access. When configured, an IDP sends SAML assertions to the CloudHealth platform when configured.

When a user logs in, the IDP sends data to the CloudHealth platform. This data is called an assertion, and it contains attributes like “email,” “name,” and “roles.” These attributes allow CloudHealth to create the user in the platform.

When you move a user from source organization to a target organization, the user loses access to any saved reports that were private to them in the source organization.

API access to CloudHealth is provided through an API key assigned to a user. Users within an organization can only retrieve the data that is available to their assigned organization.

Data from the customers vSphere environment to CloudHealth is processed through two different calls:

• Every 15 min: vCenter connection health check.
• Every 60 min: Collection of metrics, assets, and tags on all VMs.

In order to determine if MFA is enabled, CloudHealth checks only IAM users that have regular passwords.

When you launch an EC2 instance, it first enters the pending state and then transitions to the running state. When you stop that instance, it first enters the stopping state and then transitions to the stopped state.

Each time an instance transitions from stopped to running, AWS charges for a full instance hour, even if these transitions happen multiple times within a single hour.

Therefore, if you restart an EC2 instance multiple times in an hour, each restart incurs an hour of usage. When these restarts occur consistently throughout a month, the instance usage hours tend to exceed the total available hours in that month.

For more information, see EC2 Instance Lifecycle.

The Assets > AWS > Instances report lists all active instances, including instances that are in a stopped state. The Usage > EC2 Instance report, on the other hand, only lists instances that are running.

CloudHealth supports reporting customer costs as though their accounts were not linked into a partner-managed consolidated bill. This includes reporting discounts provided by Amazon for both permanent free tiers and tiered volume discounts, but not new customer free tier discounts.  The below table summarizes, by service, the free tier and tiered discounts that Partner Generated Billing will support:

Permanent free tier does not include any new account discount (e.g., first 12 months as AWS customer)

No, they cannot. In the CloudHealth Platform, each Customer Tenant is isolated from the others and cannot see data in any other customer account. The Partner is the highest level tenant in the multi-tenant hierarchy, and can view and manage all customers.