I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Jeremy,

How are you doing the split?  Are you using business mappings, did you create a business rule, or are you doing it outside of Cloudability?  

Curious on your implementation, as we are currently at a cross roads ourselves with this.

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Shanon,

                       We are currently doing this outside of Cloudability in Power BI as we couldn't do it in business mappings.

Jeremy,

How are you doing the split?  Are you using business mappings, did you create a business rule, or are you doing it outside of Cloudability?  

Curious on your implementation, as we are currently at a cross roads ourselves with this.

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Thanks Jeremy, I suspected as much.  We have been attempting to avoid doing that (we are trying to get from PowerBI to Cloudability) but sounds like we should stay on PowerBI for now.

Hi Shanon,

                       We are currently doing this outside of Cloudability in Power BI as we couldn't do it in business mappings.

Jeremy,

How are you doing the split?  Are you using business mappings, did you create a business rule, or are you doing it outside of Cloudability?  

Curious on your implementation, as we are currently at a cross roads ourselves with this.

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Jeremy, Shanon

Thanks for your advice, comments, will look at using the usage type.

Apptio - what I am slightly puzzled at still is that this is how I understood how ATUM maps these services in Cloudability.  At least for Azure this doesn't look to be implemented yet.  Is this something you are working on or should I submit a feature request?

        {
            "matchExpression": "(DIMENSION['enhanced_service_name'] == 'AWS EC2' || DIMENSION['enhanced_service_name'] == 'Azure Compute' || DIMENSION['enhanced_service_name'] == 'AWS ECS' || DIMENSION['enhanced_service_name'] == 'AWS Lambda')",
            "valueExpression": "'Compute'"
        },
        {
            "matchExpression": "DIMENSION['enhanced_service_name'] CONTAINS 'Azure Analysis Services'",
            "valueExpression": "'Platform'"
        },
        {
            "matchExpression": "DIMENSION['enhanced_service_name'] CONTAINS 'Azure Cosmos DB'",
            "valueExpression": "'Platform'" 

Thanks Jeremy, I suspected as much.  We have been attempting to avoid doing that (we are trying to get from PowerBI to Cloudability) but sounds like we should stay on PowerBI for now.

Hi Shanon,

                       We are currently doing this outside of Cloudability in Power BI as we couldn't do it in business mappings.

Jeremy,

How are you doing the split?  Are you using business mappings, did you create a business rule, or are you doing it outside of Cloudability?  

Curious on your implementation, as we are currently at a cross roads ourselves with this.

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)

Hi Shanon,

                       We are currently doing this outside of Cloudability in Power BI as we couldn't do it in business mappings.

Jeremy,

How are you doing the split?  Are you using business mappings, did you create a business rule, or are you doing it outside of Cloudability?  

Curious on your implementation, as we are currently at a cross roads ourselves with this.

Hi Drew,

                   To see the proper Azure service names we found them embedded in the usage type with a delimiter of '::', we split on that to get just Azure Service Name as Microsoft map it in their CUR data for our reports. So now we can see that is Virtual machines, virtual machine licenses etc instead of Microsoft.Compute.

Hi Thomas 

Sorry for the tardy reply, thought I'd replied to this.  The product name provides the same generic bucket e.g. Microsoft.compute.  It could be a possibility to cross refer to the usage family / type (that is what I ended up doing to break down AWS RDS into Aurora vs RDS vs Maria etc) but I'm starting to have to write a heap of custom excel lookups parsing multiple lines with no guarantee I'll be able to map all the Azure products correctly.

Hi Drew, have you considered breaking down the service name or product name by usage family and usage type?

Hi Thomas

Thanks for replying.  As far as I can tell, with respect to Azure the product name is too general.  As I understand, Microsoft.compute could mean its a virtual machine or AKS.  I need this to be more specific. I can potentially figure this out from fields like the description, but it's a lot of work.

AWS has this generalisation in places (AWS RDS, EMR, Elastic Load Balancers); not necessarily your fault because I think that is the way they provide the info.  But it makes it difficult for me to understand what service is actually being used. 

Hi, have you looked at the product name dimension instead?  Service name indeed is being normalized as discussed earlier, but product name should be the official product name as provided by the vendor (for example, Amazon Elastic Compute Cloud, GCP Cloud Storage, Microsoft.Compute or OCI Compute).  Please see here for a list of available cost and usage dimensions. https://help.apptio.com/en-us/cloudability/product/glossary-of-cost-dimensions-and-metrics.html?  Hope this helps.

Original Message:
Sent: 02-22-2024 09:27
From: Shanon Cole
Subject: Azure service names

I agree with statement, but rather than for ATUM, it is because it is very difficult to find necessary data when you are looking for something specific.  I can see the raw data from our cloud providers, but being able to re-create the data in Cloudability is difficult because I have to split using other methods.  i.e. Service = EC2 - Instance in AWS; Service = AWS EC2 in Cloudability; but AWS EC2 includes data transfer, and other services that are listed in EC2 - Other in AWS.  Trying to see total cost of eligible savings (calculated as we calculate it) is difficult because the tool doesn't allow and "exclude" for only one specific item (i.e. trying to see savings plans, EC2 (instance usage only), ECS, Lambda by lease type).  It would be ideal if the data that is sent in to Cloudability is the same as the data sent in from the providers (don't aggregate the fields) and then you can normalize the name if necessary (Account vs Subscription)