Allocate the cost of a shared Cloud SQL database to the teams using it

​

Prerequisites

1. Identify what drives your database cost increases:
   • Storage size: choose this if the last resource increase was due to growing storage.
   • Compute resources: choose this if the last resource increase was due to CPU or memory pressure.
2. Know where the usage metric is available (e.g., Datadog, Google Cloud Monitoring).

​

Output

• Gain visibility into each team’s cost contribution.
• Schedule recurring reports to share cost allocation with stakeholders.
• Set alerts if a team’s share grows unexpectedly.

​

Steps

1

Choose the correct metric

Select the metric that matches your cost driver. Below are example queries for Datadog and Google Cloud SQL.Storage size

• Datadog
• Google Cloud SQL

avg:postgresql.database_size{<yourWhereClause>} by {db}.rollup(avg, daily, 'UTC')

Not available. Use a Datadog-sourced metric instead.

Compute resources

• Datadog
• Google Cloud SQL

sum:postgresql.queries.time{<yourWhereClause>} by {user}.rollup(sum, daily, 'UTC')

sum by ("user")(
  rate({
    "__name__"="cloudsql.googleapis.com/database/postgresql/insights/aggregate/execution_time",
    "monitored_resource"="cloudsql_instance_database"
  }[${__interval}])
)

2

Import the metric in Costory

Go to Costory Metrics and import the metric.For both compute resources and storage size, we recommend using SUM when aggregating the metric at weekly or monthly levels. Using a maximum aggregation might over-allocate cost to the team responsible for a single-day spike.Click Import. The first import may take a few minutes to complete.

3

Preview the result using the Advanced Explorer

Go to the Advanced Explorer and query the metric you just imported. Verify that the per-team breakdown looks reasonable before creating a virtual dimension.

4

Create a virtual dimension to allocate the cost

1. Go to Virtual Dimensions and create a new virtual dimension.
2. Rely on a filter on resource_id or resource name to scope the database cost correctly.
3. Instead of relying on dimension value mapping, use the Dynamic allocation based on usage metrics option:
4. Map the group-by dimensions to the correct team or owner. You have three options:
   • Identity mapping: your database name equals your team name.
   • Regex mapping: your database name contains your team name (extract it with a regex).
   • Manual mapping: your database name has no relation to the team name; map each name manually.
   

If you choose manual mapping and a new database appears later, you will need to edit the virtual dimension to allocate the new database to the correct team.

5. Save the virtual dimension.

5

Create a report to visualize the cost allocation

Go to the Cost Explorer and create a new report using your virtual dimension as a group-by. You can also schedule the report to be sent to Slack on a weekly or monthly basis.

​

Related

• Need to allocate a shared API instead of a database? See Split Shared API Costs Across Teams for a step-by-step guide using an external usage metric like API call counts.