Cost Allocation Roadmap Updates Thread

[Sophie_Mayerw]

Hi, dear DPS Cost Allocation users,

I'll use this thread to keep you updated about our DPS Cost Allocation roadmap. 

Next planned DPS SaaS Capabilities to be supported by DPS Cost Allocation:

• (delivered) CQ3'25 - Log Ingest
• Rollout Postponed to January '26 - Log Retain
• Rollout Postponed to January '26 - Log Retain with included Query
• (delivered) CQ3'25 - Traces Ingest
• January '26 - Metrics Ingest
• CQ1'26 - Traces Retain
• CQ2'26 - Metrics Retain
• CQ2'26 - Kubernetes Platform Monitoring
• CQ2'26 - Code Monitoring

Next planned configuration convenient features:

• CQ4'25 - AWS / Azure telemetry metadata enrichment for DPS Cost Allocation (similar to K8s telemetry metadata enrichment)

Next capabilities in priority, without a delivery date yet:

1. RUM
2. Synthetics

Feel free to provide you're feedback about the above-stated plans

Cheers,

Sophie

Changelog:

• July 4: changed AWS from CQ3 to CQ4. There will be a closed preview in CQ3 and GA in CQ4.
• July 4: changed CQ3 Traces Retain to CQ4 Metric Ingest. Based on feedback, we switched priorities. 
• November 10: updated postponed Log Retain/RwiQ and added detailed timeline for CQ1'26 and CQ2'26
• December 22: updated postponed Log Retain/RwiQ and Metric Ingest to January '26. 

[Jamey_Price]

Sophie,

Does your team have plans to use the existing entity ownership metadata we're already enriching Dynatrace with as part of Cost Allocation configuration?

It is cumbersome to assign additional ownership metadata just to use the Cost Allocation feature today.  Pairing that with the need to explicitly list entities as valid targets for billing allocations further increases the complexity.  Because of these factors, we're using our own DQL queries to analyze and apportion this data, not Cost Allocation.

I look forward to hearing more about this feature as it evolves.

Jamey

[Sophie_Mayerw · Accepted solution]

Hi @Jamey_Price 

Quick answer: No, we will not support the ownership metadata.

More context: We did receive this question several times and investigated in this direction. But it won't be supported. There are ways which this information can be used for migration/initial setup (for example: request the owner via API from the host - push it via API as a new attribute to the OneAgent of the host)

Instead, we do focus on reusing K8s and Cloud Provider Tags/Labels/Namespaces to be reused for Cost Allocation. 

K8s: https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/guides/metadata-automation/k8s-metadata-tel...

Cloud Provider: Will work similarly to K8s and will be coming in CQ3 this year. 

HTH,

Sophie

[Jamey_Price]

Thank you for the clear, concise answer!  It's always helpful to know the direction Dynatrace is heading so we can plan accordingly.

[JoSk]

Hi, we stumbled upon an issue that we cannot set a host tag/property for some hosts (in particular AWS Fargate containers with build-time injection). Now we tried to just add the tag via manual or automatic tagging to the host, but that doesn't seem to work.

Is this intended, will there be support for manual/automatic tagging of hosts? (knowing that removal from tags will result in missing data)

[Sophie_Mayerw]

Hi @JoSk!
It should work on AWS Fargate as on all our other supported platforms. Please check with support to identify the correct configuration. (e.g. environment variables)
Using auto-tagging rules or the tags you can set on the UI on hosts is not supported. Even though everything is called a "tag," those are two different kinds of tags. We need the ones directly on the OneAgent—those can be attached to our Cost Allocation feature and all the telemetry data as well. 

[JoSk]

Hi, we tested by adding environment variables to the AWS container and the tags appear both on PGs and PGIs but not on the Host Entity itself.

I assume this is because there is no actual OneAgent, the container are instrumented via Code Modules and the Host is indirectly created by Dynatrace.

It is also not possible to reconfigure these Host Entities afterwards using UI (Deployment Status) or API (/oneagents/remoteConfigurationManagement) to manually give them a Host Tag or Property afterwards (e.g. using automation).

[Sophie_Mayerw]

Hi @JoSk - that sounds like halfway there. Please check with support. This allows us to help you much faster.
We can bring the identified solution back here afterwards. 

[e5696287]

HI Sophie,

We have certain use case with respect to Cost allocation for Kubernetes,

1. We have a leveraged cluster which is nothing but shared between multiple apps, say shared between App A, App B etc.
2. As per doc this tagging will be applied at Dynakube level which is nothing same across all nodes in that cluster.
3. Now here is the tricky part with leveraged cluster as we have multiple apps which can report under any of the nodes we won't be able to find its costing based on App reporting in node.
4. This is where it gives me usage of cluster not the apps in that cluster.

I had a quick call with Dermanuelian, Chris <chris.dermanuelian@dynatrace.com> and explained the use case, it would really helpful if we can have app level cost allocation details at cluster.

Thanks,
Shri

[Sophie_Mayerw]

Hi Shri,

Thanks for taking the time to explain your use case in detail. I do understand the business case. Currently, the only way to receive usage per pod is if the FullStack app-only mode is used. This setup can then usually be aligned to have one pod per team/app, resulting in cost allocation values per team/app. 

As of today, we can't spread cluster usage between pods/apps due to the difference in usage calculation. 

If you need more details about this topic, please reach out to support. 

Best regards,

Sophie

[JoSk]

I feel you but this can get a quiet complex situation. Right now from what I see the dt.cost.costcenter approach mainly focues on the host entities.

We sometimes also do our own reporting based on management zones for example, but you really have to take care of the entities that are included. This can also introduce duplicate or missing billing and reports always have to be checked if they somewhat match real billing (and more often that not you will get some small (but often negligible) differences by a very few percent).

I think right now in practice it may be a good practice to somehow solve that issue on the organization level and not the technical. Try to get a compromise like:

a) Cluster belongs to e.g. 30% to the App A team and 70% App B team > also split monitoring cost accordingly (e.g. based on the customers infrastructure costs)

b) Assign the cluster to a separate cost center, customer will split costs internally based on how they think it is used.

It is not exact but it could be a solution the customer can work with.

[joanne_quan]

Great, thanks for the roadmap Sophia; is there a plan to include the Log Ingest, Log Retain, Log Retain with included Query, Traces Ingest? to the DPS Cost Allocation - Usage & Costs dashboard?

Thanks,

Joanne

[Sophie_Mayerw]

Hi @joanne_quan 
Yes there will be a bigger update of the Dashboard alongside the release of Log & Traces Ingest. I've added a sneak peak here. 

[Sophie_Mayerw]

Hi @joanne_quan - I just wanted to ping you - the new Dashboard is available see here

[J01am]

Hi @Sophie_Mayerw ,

I’m sharing some feedback on the structure of Billing Usage Events, because it currently prevents granular cost allocation for certain event types.

For most Dynatrace billing events, each record contains a single product / cost center pair, which enables a clean 1:1 mapping and accurate cost breakdown across dimensions.

However, for some newer billing event types (e.g. “Log Management & Analytics – Retain”), the event payload appears to provide these dimensions as two independent arrays within a single event:

• dt.cost.product: [ProductA, ProductB]

• dt.cost.costcenter: [CostCenterA, CostCenterB]

Because the two dimensions are stored as separate arrays, the relationship between a specific product and a specific cost center is ambiguous. With the example above, there’s no deterministic way to infer the allocation (e.g. whether ProductA maps to CostCenterA, or any other split).

More broadly, if we can’t do a 1:1 breakdown, what is the intended added value of having multiple cost-related tags in the same billing event, since it can’t be used for precise cost attribution?

Could you confirm if this array-based structure is the intended format for these new billing event types?

Thanks!

[Sophie_Mayerw]

Hi @J01am ,
thanks for reaching out.

Yes the structure is inteded. I see why there is the understanding that we want to support a combination from costcenters and products. This was never intended to be supported. I do acknowledge that this has not been stated clearly in our documentation and I'm sorry for any inconvenience this misconception will now bring upon you.

Would you like to jump on a call to see if we can support you to find a setup where the combination of products and costcenters are no longer needed?

Best regards,

Sophie

[DylanPTaylor]

Are there plans for propagation of the cost center property to other signals?

For example; if I set the host tag dt.cost.cost_center on a host, will that property value also exist on the logs & vulnerabilities ingested/reported on that host automatically?

[Sophie_Mayerw]

@DylanPTaylor 
Feel free to open up a separate thread for questions in the future. This makes the question more visible to other users and therefore even more helpful. 

To your question:
For telemetry data the important part is to have the cost allocation meta data on each data point. 
Since all host info are added to the data points when passing the OneAgent: Yes cost allocation configurations from the host are inherited. 

This is also stated here in the "How to get started" part:
https://docs.dynatrace.com/docs/license/cost-allocation#telemetry-ingest

Best,

Sophie