- Más nuevo
- Más votos
- Más comentarios
I would design for one lead metric, which is the main driver for infrastructure costs (infrastructure in this case is the underlying shared DB instance). Then you can have secondary metrics, if user behavior needs to be limited / steered also regarding a second factor. An example for this is EBS, where capacity is the main metric that determines the pricing, while IOPS are a secondary metric.
The advantage of this use case is, that the tenants are (presumably) all using the same SaaS application, so the load which they are generating is probably comparable, making it easier to define a lead metric.
When you have your lead metric you can use that to split the costs of the service to the individual users. For that you have multiple inputs:
- The direct costs from the instance, where the DB is hosted
- The indirect/non-tagable costs from the account, where the DB is hosted (e.g. network traffic)
- The indirect costs form the platform operations (e.g. direct connect, identity provider connection, central logging account, ...)
- The non-AWS costs for running the service (e.g. license, personnel costs, ...)
That means they have to build it by themselves but it can be partially automated, e.g. if they can import their personnel costs form their ERP system, or provide the CURs to the account owners.
Contenido relevante
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años
- OFICIAL DE AWSActualizada hace 2 años