This article will explain how client counts are counted in HCP Vault, and give insight on managing clients counts within your cluster.
The current pricing model includes base cost for cluster provisioning and operation and a marginal cost on a per client basis - you can view the pricing page here. The number of clients is calculated based on unique clients, and its unique clients per-month/hour. Depending on usage patterns, there can be scenarios where client counts may increase resulting in unanticipated costs, our goal with this guide is to provide information to help with this. The information summarized here can be viewed in detail within our What is a Client guide as well for more information.
What counts as a client?
Ultimately, clients represent anything that has authenticated to Vault to do something.
Vault Clients, for billing purposes, are simply all distinct Human Users, Applications/services (including CICD Pipelines using the Vault API), and Servers (including VMs/Containers) that authenticate, or communicate to Vault at least once over a billing cycle for access to and management of secrets or perform other operations within Vault.
E.g. if a client authenticated to Vault on the 1st, the client will be billed for the remainder of the month the same way if a client connected on the 15th of the month, the client will be billed from that day until the end of the month no matter how many times Vault is accessed. Within Vault, clients are considered distinct applications, services, and/or users that use Vault.
Here's an analogy that helps explain how client counts work in Vault:
If you suppose Vault was a stadium, and we bill on the number of patrons who attended games during the year. There are season ticket holders, whose identities can be verified [because an ID was required to purchase a season ticket], and non season ticket holders, whose identities cannot be verified. Not all season nor non-season tickets are actually used to attend games. For billing purposes, we would only count actual season ticket holders who attend games during the year, and all other tickets actually redeemed. In Vault, season ticket holders are akin to entities and non-season tickets are tokens. It is easy to count each distinct season ticket holder only once, no matter how many games he/ she attends. We can trace and associate an identity with each season ticket. However, this is not the case with normal tickets. We have no idea of the identities of these ticket holders, so we have to count every instance of a ticket that has been used. Only those actively used are counted.
For billing purposes, what is important with Vault, is how many clients actually authenticated over a year. For Vault, when it comes to client count for billing purposes, it does not matter how many season ticket holders are there (AKA entities), but how many actually used their season ticket at least once to attend a game i.e. authenticated at least once (Distinct Entities), in addition to all the other tickets that have been used to attend a game, that is authenticate to Vault. (Non-Entity Tokens).
If there are different stadiums in different regions, we count season ticket holders that attended in each region. It is not in aggregate. If someone is a season ticket holder in both regions, it does not mean there is 1 aggregate user. It simply means the count in stadium/region 1 is 1 client and the count in stadium/region 2 is 1 client.
Therefore from a Vault perspective, we are only concerned about Vault clients in each region, and we are not concerned with how many clients in Region 1 also are in Region 2. It does not matter.
Distinct Entities are known identities that are associated with one of Vault's authentication methods [season ticket holders], and Non-entity Tokens are unknown identities, that just used tokens to access Vault [non season tickets].
Vault Clients for billing purposes though are simply all distinct humans, applications/ services, and servers that authenticate, or communicate to Vault at least once over a billing cycle for access to and management of secrets, or to perform other Vault operations.
Some key points to consider:
- Does the client have a known identity when they authenticate at least once? [Distinct Entities as defined by Vault]
- Does the client have an unknown identity when they authenticate? [Non-Entity Tokens]
Tips for managing client counts
There is a section within the What is a Client guide here that provides some considerations on managing client counts in Vault which is also summarized below.
Issuing and using Vault tokens directly without an associated entity_alias and role can cause client counts to increase which is also called out in the guide here. If an entity_alias and role is not associated with the token, it will be counted as a non-entity client.
Since each unique client can be counted as an entity or non-entity just once within a billing period, you can have scenarios where multiple devices/clients may map to the same entity, such as if using AppRole auth, and it would count as one client count is the same Role ID was used - other associations between the different auth methods and the attribute within it which provides identity to a client can be viewed in the table in this section. Each authentication method has a unique identifier to determine a unique identity. As an example, if you identify a microservice by AppRole auth method make sure to assign a role id for that microservice. If microservices (or multiple VMs, or containers) are exact copies using the same role id, they will all have the same identity. Once authenticated to a cluster, the clients have unlimited access to that cluster for the remainder of the billing period.
In the event client counts start suddenly increasing and you would like to determine where they may be coming from within your environment, you can check the audit log of your cluster and view the display_name to try and narrow down the auth method and/or role it is coming from.