Tag sharing #
There are use cases where a component used by multiple accounts, a ‘large’ or ‘expensive’ component and a component shared by some business scenario needs to have its cost ‘broken’ between several Tags .
A practical example would be a database that is used by several ‘cost centers’ and needs to be allocated between them. The scenario of a single tag for this database does not support this allocation.
Our engine is well advanced in several tracking scenarios. Contact us with your use case and we will configure it for you for now (we will have an interface soon and provide flexibility).
Allocation of values #
There are some use cases where it is necessary to prorate a certain Tag value among the other values, without losing the original information.
To make it more practical, imagine the scenario in which the Tag named “ centrocostos ” has a value of “ Infra ”. This “ infra ” contains all the peripheral services that support the cloud: logs , support, sending alerts, emails, etc. Even services that cannot be tagged natively (see “ Missing tags ”). Since it represents the cost of operating the cloud, it is necessary to apportion the ‘ infra ’ among the other values of the cost center.
In this scenario, Cloud8, in order not to lose information, would work as follows:
- An identical copy of the tag ‘ centrocustos ‘ is created, which we could call ‘ centrocustos-rated ‘;
- The apportionment rule is applied to suppress the ‘ infra ‘ values (and may include others such as ‘ infrastructure ‘, ‘ support ‘, etc.) and apportion them proportionally among the others. Whoever spends more, receives more ‘ infra ‘ costs.
The client continues to see the original value in ‘ centrocosts ‘ for reporting purposes, tagged , untagged and pivot table analysis and can now also have the view with the customized allocation they need.
Kubernetes – EKS and GKE #
With the migration of applications that previously ran on dedicated instances or clusters to a new Kubernetes structure , what could previously have had a well-organized FinOps , faces the challenge of reorganizing allocation and visibility.
The Kubernetes cluster is composed of several instances, of various types and subject to diverse cost models ( spot , on demand , reservations and/or savings plans applied). These, in turn, will have ‘ pods ‘ (applications) allocated and deallocated with rules and frequencies determined by a technical ‘ scheduler ‘ and partially consuming these resources. The challenge here is to know where and when each pod ran and how much resource it consumed.
To collect this data and calculate the allocation, we use native AWS and GCP (Azure coming soon) tools that can be enabled at any time. GKE has no additional costs, but AWS will incur CloudWatch costs that need to be monitored and evaluated. Depending on the number of instances, this cost can range from a few dollars to a few hundred . Therefore, the benefit of visualizing internal (and obscure) costs must be evaluated from the perspective of the investment in how to extract this data and how complex it would be to manage it. Our proposal is to simplify and integrate internal data with data from the entire infrastructure, without the need for additional management tools.
To enable both EKS and GKE costs, use the component list and right-click to select the activation option. It also provides instructions on how to do this.
See more : How to enable cost sharing in ECS and EKS .
