I noticed that a large number our untaggable resources are currently showing up under AppID-"Not Set" in Cloudability, as it should because of the business mapping set up. But this makes it difficult to distinguish between resources that can be tagged but aren't and resources that cannot be tagged at all.

I was wondering if there is way to categorize untaggable resources separately, perhaps by using business mapping to assign them an identifier like "untaggable" instead of "not set". This would help us differentiate between truly untagged resources and those that simply don't support tagging. 

I'd love to hear your thoughts, suggestion, or any alternative solution you might recommend. 

Thank you

Hello @Jesie Mbiatem I'll get back to you with appropriate solution on it.
Thanks!

- Varad

I noticed that a large number our untaggable resources are currently showing up under AppID-"Not Set" in Cloudability, as it should because of the business mapping set up. But this makes it difficult to distinguish between resources that can be tagged but aren't and resources that cannot be tagged at all.

I was wondering if there is way to categorize untaggable resources separately, perhaps by using business mapping to assign them an identifier like "untaggable" instead of "not set". This would help us differentiate between truly untagged resources and those that simply don't support tagging. 

I'd love to hear your thoughts, suggestion, or any alternative solution you might recommend. 

Thank you

Not sure of the CSP in use, but curious to know how is the group identifying the resources that can not be tagged at all? 

It's been said, typically the rule in CLDY has been if the CSP is passing a resource ID, then this should be a taggable resource.

However, we recently uncovered in our environment this is not the case. Products Names containing Amazon Bedrock display a resource ID but not all of them are taggable.

For example resource IDs containing:

• "foundation-model" or "inference-profile" can not be tagged with an APP-ID.
• "application-inference-profile" and "guardrail" can be tagged with an APP-ID.

Hello @Jesie Mbiatem I'll get back to you with appropriate solution on it.
Thanks!

- Varad

I noticed that a large number our untaggable resources are currently showing up under AppID-"Not Set" in Cloudability, as it should because of the business mapping set up. But this makes it difficult to distinguish between resources that can be tagged but aren't and resources that cannot be tagged at all.

I was wondering if there is way to categorize untaggable resources separately, perhaps by using business mapping to assign them an identifier like "untaggable" instead of "not set". This would help us differentiate between truly untagged resources and those that simply don't support tagging. 

I'd love to hear your thoughts, suggestion, or any alternative solution you might recommend. 

Thank you

I noticed that a large number our untaggable resources are currently showing up under AppID-"Not Set" in Cloudability, as it should because of the business mapping set up. But this makes it difficult to distinguish between resources that can be tagged but aren't and resources that cannot be tagged at all.

I was wondering if there is way to categorize untaggable resources separately, perhaps by using business mapping to assign them an identifier like "untaggable" instead of "not set". This would help us differentiate between truly untagged resources and those that simply don't support tagging. 

I'd love to hear your thoughts, suggestion, or any alternative solution you might recommend. 

Thank you

Hello @Jesie Mbiatem,
The answer for query is "Yes you can do this within the business mapping logic. Typically anything without a resource ID is "untaggable", so you can add a rule for that into the business mapping, and default everything else that isn't tagged but has a resource ID to "not set".

Thanks @Taylor Stallings for your help.

I noticed that a large number our untaggable resources are currently showing up under AppID-"Not Set" in Cloudability, as it should because of the business mapping set up. But this makes it difficult to distinguish between resources that can be tagged but aren't and resources that cannot be tagged at all.

I was wondering if there is way to categorize untaggable resources separately, perhaps by using business mapping to assign them an identifier like "untaggable" instead of "not set". This would help us differentiate between truly untagged resources and those that simply don't support tagging. 

I'd love to hear your thoughts, suggestion, or any alternative solution you might recommend. 

Thank you