not understanding how unknown types are working

[Serge Scevenels]

Hi

i am trying to understand how the Look Up Table is being generated, in particular for Unknown types... and there is a hole in the code source i can't find :) 

So for example i do not understand how i can have a CO2 and kilowatthours factor for this item :

serviceName: AmazonRDS

region: us-east-1

usageType: Aurora:StorageIOUsage

usageUnit: IOs

knowing the usageunit & the usagetype are not present in the file

CostAndUsageTypes.ts 

Also, in the LUT i do not have other line items with this usageUnit... so i do not understand how even a total estimate can be obtained

Any help in explaining me how it works ?

[Cloud Carbon Footprint]

Hi Serge,
Thanks for reaching out. We will be looking closer at the Lookup Table and can dig deeper at that point (https://github.com/cloud-carbon-footprint/cloud-carbon-footprint/issues/839)
We will follow up then with more details - thank you for your patience.
Cheers,
The Cloud Carbon Footprint team

[Matthew Ferry]

Hello!

I'm also struggling to understand unknown usage types work in practice.

For example, CCF returns non-zero CO2e estimates for serviceName AWSSecretsManager.

Looking at the underlying CUR file, the only usages are:

- Usage type EU-AWSSecretsManager-Secrets with unit Secrets

- Usage type EU-AWSSecretsManager-APIRequests with unit API Requests

Since neither of these types can be estimated by usage unit, they shouldn't accumulate kilowatt hours and therefore the kilowattHoursByServiceAndUsageUnit (or KILOWATT_HOURS_BY_SERVICE_AND_USAGE_UNIT) should have no entry for the relevant usage units when we estimate the kilowatt hours for unknown usage.

Should the estimate be zero in this case, or is there some other fallback that I'm missing? Does the empty "constant" from the source code get filled some other way?

Thanks,
Matthew Ferry

[Cloud Carbon Footprint]

Hi Matthew,

 Thanks for reaching out!
We were aware of this issue and made a fix for it in the latest release. Would you be able to ensure you have the latest and rerun to see if the issue is persists?
Please let us know how it goes!

Thanks,

The Cloud Carbon Footprint team at Thoughtworks

[Matthew Ferry]

Thanks for your response!

I have now updated to the latest release and agree that the strategy has changed to remove estimates for unknown usage units, but now I see something new:

- Methodology states "For each of these line items we identify the best fit known usage type by looking at the service and usage unit" which implies that we would match both service and usage unit if it were available

- The core unknownEstimator does this by referencing unknownUsage.service, so theoretically this should match on both and fall back to usage units if the service is not present

- In practice, the AWS getEstimateForUnknownUsage function defines and passes an unknownUsage object without defining a service, so this match will never occur

From my local testing, it looks like the AWS unknown estimator exclusively uses usage unit-based estimates. Are you able to confirm this behaviour? Is this a bug or intended behaviour for this release?

Thanks,
Matt