Cost Allocation in Confluent Cloud
Cost allocation itemizes a Confluent Cloud bill by the service account, user, identity pool, or resource that drove each charge. Use it to feed your internal chargeback or showback process, split a shared cluster across the teams that use it, reconcile Confluent Cloud usage to internal cost centers, and give engineering leaders visibility into what their workloads cost.
Note
Cost allocation is an Early Access feature in Confluent Cloud.
An Early Access feature is a component of Confluent Cloud introduced to gain feedback. This feature should be used only for evaluation and non-production testing purposes or to provide feedback to Confluent, particularly as it becomes more widely available in follow-on preview editions.
Early Access Program features are intended for evaluation use in development and testing environments only, and not for production use. Early Access Program features are provided: (a) without support; (b) “AS IS”; and (c) without indemnification, warranty, or condition of any kind. No service level commitment will apply to Early Access Program features. Early Access Program features are considered to be a Proof of Concept as defined in the Confluent Cloud Terms of Service. Confluent may discontinue providing preview releases of the Early Access Program features at any time in Confluent’s sole discretion.
To request access, contact your Confluent account team.
The native cost allocation export provides customers a Confluent-managed pipeline. It does not replace or deprecate chitragupta, an open-source Python chargeback helper, which remains fully supported. For a comparison, see Native export versus chitragupta.
Considerations
Cost allocation attributes cost to the lowest entity that the source usage data can resolve. For most usage, that is a service account, user, or identity pool. For some metrics, such as Cluster Linking, Custom Connect, Stream Governance, and Flink SQL at the pool level, the entity is a resource ID, and
owner_idis set to that resource ID rather than a principal.All time buckets align to UTC. Weekly buckets start on Monday by ISO week, and monthly buckets start on the first of the calendar month. Reconcile against the UTC invoice period, not your local calendar.
The bucket total reconciles to usage charges for the period. Tax, marketplace pass-through, and prior-period adjustments are billed separately and are not included in the export.
Per-topic and user-defined-tag attribution are not supported.
Identity pool usage rolls up to the pool. Per-member attribution is not available.
Data can lag actual usage by up to 48 hours. For monthly reconciliation, run the export at least 48 hours after the period ends so the period’s usage data is complete.
Cost allocation has no service level agreement (SLA) during Early Access.
How cost allocation works
For every billable metric on your account, cost allocation splits the cost across the entities that contributed to it. A principal is an authenticated identity, such as a service account, user, or identity pool, that performs actions in Confluent Cloud. Cost allocation attributes usage to the principal that generated it.
Usage-driven costs, such as Apache Kafka® network read/write, Connect tasks, Confluent Units for Flink (CFUs), and Confluent Streaming Units (CSUs), are split in proportion to each principal’s measured usage.
Shared or fixed costs, such as Confluent Units for Kafka (CKUs), partitions, storage, Schema Registry base, and Confluent Support, are allocated using a weighted average. The weight depends on the metric, such as read/write throughput, equal split across active principals, or owner-of-record.
Costs that cannot be attributed to a principal, such as promotional credits, refunds, and product lines that do not yet emit per-principal usage, appear in a single unallocated row per bucket. For details, see The unallocated row.
Within a bucket, the sum of chargeback_cost across every row equals the total billable usage for that bucket. The split does not create or lose any usage cost.
Request a cost allocation export
Export your cost allocation data as a CSV file from the Confluent Cloud Console. Export creation has no public API.
Prerequisites
An organization with Cost Allocation Early Access. Contact your Confluent account team to request access.
A user account with the OrganizationAdmin or BillingAdmin role in the target organization. For role details, see Predefined RBAC Roles in Confluent Cloud.
Request allocation
Sign in to Confluent Cloud and open Billing and payment.
Select the Cost allocation data tab.
In the Request download panel, provide the request details:
Name of the report: An identifier for this export. For example, April Finance Close.
Description: Optional context for your team, up to 100 characters.
Period: Last 7 Days, Last 30 Days, or Custom Date Range with date picker for start and end.
Granularity: Daily, Weekly, or Monthly.
Click Submit. The request appears in the Previous cost allocation downloads table with a status of Incomplete.
When the status changes to Ready, click Download in the Action column to retrieve the CSV file.
Statuses in the table:
Status | Meaning |
|---|---|
Incomplete | The export is being generated, or usage data for the period is still arriving. |
Ready | The file is ready to download. |
Failed | The export could not be generated. Retry the export. If the problem persists, contact Confluent Support and include the request name. |
Expired | The export exceeded the seven-day retention window and is no longer available. Submit a new export request for the same period. |
Most exports complete within minutes. Filter the table by month and year to find past requests.
Cost allocation export format
Each row in the export represents the cost attributed to one entity for one billable metric on one resource in one time bucket. The file is a CSV file with the following columns:
Column | Description |
|---|---|
| Bucket start in UTC, in ISO 8601 format: |
| The entity that incurred the cost: a service account ( |
| Confluent Cloud environment ID. Empty for organization-level rows, such as Support. |
| Logical resource ID: cluster |
| Product category as a lowercase string: |
| Specific billable metric in CamelCase: |
| Unit of measure for the metric: |
| Cost attributed to this entity for this bucket, in USD. |
| Total billed amount for this metric and resource before the split, in USD. |
| This entity’s share of usage, calculated as |
The export excludes rows with a zero billable amount.
Generated files are retained for seven days. After that, the file is removed and the request shows a status of Expired. To get the data again, submit a new export request for the same period.
Custom date ranges produce partial boundary buckets. A partial bucket contains only the days inside the requested range. The timestamp field still points to the bucket start. When summing across buckets, treat partial buckets accordingly.
The export does not include human-readable names, such as cluster display name, environment name, service-account name, or cost center. Map IDs to names using your existing service-account inventory or the Confluent Cloud Identity APIs.
The unallocated row
Every export contains a single unallocated row per time bucket. This row captures cost that cannot be attributed to a specific entity at export time. These categories include:
Promotional credits and refunds, which are applied at the organization level and reduce the total bill. They appear as a negative
chargeback_coston theunallocatedrow. For example, a $562.29 promotional credit applied in April appears aschargeback_cost = -562.29in the April monthly bucket.Product lines without per-principal usage. Some products, such as Tableflow, do not emit usage tagged with a principal. Their full cost appears in the
unallocatedrow.Adjustments and credit notes issued for prior periods.
For the unallocated row, chargeback_cost equals original_amount because the row is not split. The usage_share is set to 0 by design. The unit is USD. When you reconcile the export to your invoice, the sum of all chargeback_cost values, including the unallocated row and its negative values, equals the total billable usage for the period.
You control how you internally distribute the unallocated total. Common patterns include charging it to a shared organization-level cost center or pro-rating it across business units in proportion to their total chargeback cost.
Cost allocation by product
The following table shows how each product type’s costs are split and which entity appears in the owner_id column.
Product or metric | Allocation method |
|
|---|---|---|
Kafka network read or write | Split across service accounts in proportion to read or write throughput. |
|
Kafka CKUs | Split using a weighted ratio of |
|
Kafka storage, partitions, base | Split equally across active principals on the cluster in the bucket. |
|
Connect capacity, tasks, and throughput | Attributed to the Kafka cluster. |
|
Custom Connect tasks and throughput | Attributed to the Custom Connect cluster. |
|
Cluster Linking per link, read, and write | Attributed to the source logical cluster. |
|
Flink SQL (CFU) | Attributed to the environment or compute pool. |
|
Schema Registry, Stream Governance, NumRules | Attributed to the Kafka cluster. |
|
ksqlDB (CSU) | Attributed to the service account that owns the ksqlDB application. |
|
Audit Log read ( | Split across service accounts in proportion to read volume. |
|
Confluent Support ( | Allocated last, in proportion to each entity’s total chargeback cost from all other metrics. | varies based on |
When a metric cannot be attributed to a principal, the cost is recorded against the resource ID with owner_id set to that resource. For example, the base cost on a cluster with no service-account activity for the bucket would be attributed to the resource owner.
To bill that cost to a team in your internal pipeline, attribute it to the team that owns the resource using your own resource-ownership inventory.
Important
Attribution quality depends on principal hygiene and how your organization manages service accounts. If a single service account is shared across applications or business units, the export cannot split that cost further. The entire row attributes to the shared service account. Organizations with shared, personal, or provisional service accounts might need to rationalize principals before the export produces useful chargeback data.
Allocation example
This example shows how Confluent Cloud costs are allocated across principals.
A Confluent Cloud environment incurs $33 in a month, across one Kafka cluster (lkc-123), one Connect cluster (lcc-456), one Flink SQL compute pool (lfcp-789), and Confluent Support. Four service accounts (sa-abc, sa-def, sa-ghi, sa-jkl) are active during the month.
This is how cost allocation is distributed across rows with owner_id values:
The $2 of CKU cost on
lkc-123is split across the four service accounts (owner_id = sa-abc / sa-def / sa-ghi / sa-jkl) using the read/write weighted ratio.The $6 of write throughput is split between the two accounts that wrote (
sa-abc,sa-def).The $15 of read throughput is split between the two accounts that read (
sa-ghi,sa-jkl).The $4 of Connect tasks is attributed to the Connect cluster (
owner_id = lkc-123). The internal pipeline maps that cluster to its owning team.The $3 of Flink cost is attributed to the environment (
owner_id = env-xxx).The $1 of Cluster Linking cost is attributed to the source Kafka cluster (
owner_id = lkc-123).The $1 of Schema Registry base cost is attributed to the Kafka cluster (
owner_id = lkc-123).The $1 of Confluent Support is allocated last, in proportion to each entity’s share of the other metrics.
The sum of every chargeback_cost value is $33, the original usage charge.
Reconcile with your invoice
To reconcile an export with your Confluent Cloud invoice, sum the chargeback_cost column and compare the total to the usage charges subtotal on the invoice for the same period.
For a monthly close, follow these steps:
Run a Monthly export at least 48 hours after the month ends so the month’s usage data is complete.
Sum the
chargeback_costcolumn across every row, includingunallocated, which can contain negative values for promotional credits.Compare the sum to the usage charges subtotal on your Confluent Cloud invoice for the same period. Tax, marketplace pass-through, and prior-period adjustments appear on the invoice but are not in the export, so exclude them when reconciling.
If the export and invoice usage subtotal disagree, re-run the export after another 24 hours to capture any late-arriving usage data. If the values still disagree, contact Confluent Support with both artifacts.
If Confluent issues a credit note or adjustment for a closed period, re-run the export for that period to capture the change. The cost allocation pipeline reflects the current state of the source usage data, not an immutable snapshot of the prior export.
Multi-organization usage
Cost allocation exports cover a single organization. If your business runs more than one Confluent Cloud organization under a single contract, request a separate export per organization, then combine the files in your downstream pipeline.
The export currently does not include an org_id column. If you combine exports from multiple organizations into one table, add an org_id column at ingest time so downstream queries can group by organization.
Service-account, user, and resource IDs are organization-scoped, so the same ID does not appear in two organizations. Track ownership using a customer-maintained crosswalk from (org, owner_id) to your internal team or cost center.
Native export versus chitragupta
You can run cost allocation natively in the Confluent Cloud Console or with chitragupta. Both paths are supported. Use this table to decide which to run:
Need | Native cost allocation export | chitragupta (open source) |
|---|---|---|
Monthly finance close, single CSV | Recommended | Possible |
Custom allocation rules and weights | Not supported | Supported. You control the script. |
Live dashboards refreshed every few minutes | Not supported | Supported |
Topic-level attribution | Not supported | Supported, subject to API limits |
Multi-organization rollup in one report | Not supported | Supported, compose against multiple organizations |
No infrastructure to operate | Managed by Confluent | Managed by customer |
Audit-ready, vendor-published methodology | Confluent documentation | Customer-defined |
It is common to run both options: the native export for monthly finance close and chitragupta or another in-house pipeline for live dashboards and custom views. You do not have to migrate from chitragupta to the native export.