[Proposal] Handle when SKU region is different from resource region

[flanakin]

Type

Dimensions: SkuRegion Normalized: No

Related dimensions: Region, AvailabilityZone

Description

The resource region and the SKU region may be different for various scenarios like zone-based pricing. We need a separate column from Region to be clear about what the region is for the SKU.

With this, we also need to clearly differentiate between the resource and SKU regions since Region and SkuRegion do not clearly indicate this. Consider using ResourceRegion and ResourceAvailabilityZone to clearly identify these are resource properties and differentiate from the SKU region.

Definition of done

• [x] Rationalize vendor-neutral, cross-cloud naming
• [x] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc.

Want this column in FOCUS 1.0 GA?

Give it a 👍 below ↴

If you can discuss and help finalize the change, add yourself as an assignee ↗

Comments are welcome and encouraged!

[mike-finopsorg]

+1 ResourceRegion feels natural with the other Resource* columns

[ijurica]

Questions:

• Resource Region represents the Region in which a Resource is provisioned and SKU Region (relevant for Pricing) might be different than Resource Region and that's the UC that this additional column should cover, right?
• Is this specific for Microsoft?
• If different SKUs or SKU Price IDs apply depending on on both From and To Location/Region, which of those two is SKU Region? And do we need yet another columns to cover this UC as well?

[marc-perreaut]

If SKU Region is related to SKU pricing, not strictly to the SKU, the column name should contain Pricing or Price? Or, are there are scenarios where a SKU Region makes sense, independently of pricing?

Moreover, to avoid the confusion with the classic resource regions, the generic term Location might be used. On top of the AZ-based pricing example, I am thinking of the continent-based pricing for Azure bandwidth.

So maybe SkuPricingLocation or SkuPriceLocation?

[flanakin]

As we've discussed SkuId, it includes a region. Including a SkuRegion column is just about making that explicit. As-is, we have scenarios where some charges have a different SKU region than the resource region, which will lead to confusion. (Ask me how I know 🙃)

I believe this was raised as also an issue with other providers, but I don't have examples. For Microsoft, we have some networking services that are not operated out of a single Azure region so the resource region is in Azure, but the SKU (meter) region is some other location. One example is third-party cache services and another is "zonal" SKUs that are billed based on what large geographic area they fit into.

I wasn't accounting for the from/to problem here. That's a separate issue. It makes sense to include that in the conversation to ensure we have a formal opinion.

[marc-perreaut]

The current definition of SKU does not tell anything explicit about the region:

A SKU ID is an unique identifier that defines a provider-supported construct for organizing properties that are common across one or more SKU Prices. SKU ID can be referenced on a catalog or price list published by a provider to look up detailed information about the SKU. The composition of the properties associated with the SKU ID may differ across providers. Some providers may not support the SKU construct and instead associate all such properties directly with the SKU Price. SKU ID is commonly used for analyzing cost based on SKU related properties above the pricing constructs.

https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/specification/columns/skuid.md?plain=1#L3

As a practitioner, I would prefer a provider to NOT include the region in the SKU, because I would like to make analyses for multi-region deployments. For example, I would like to understand if same SKUs are used by an application between primary and secondary regions.

[udam-f2]

Is this a common enough case across providers that is worthy of making it a required column for all rows across all providers? If this isn't a common case, maybe this can remain in the provider_ columns for the relevant providers only?

[flanakin]

Is this a common enough case across providers that is worthy of making it a required column for all rows across all providers?

I don't know. I'd need other providers to chime in to acknowledge one way or the other...

[rupagcp]

We have resource region (location.region in Detailed Billing Export) and sku region (geo_taxonomy.regions in Pricing Export). If the sku has no regions associated, the region will appear as null.

We also have a field of region type (geo_taxonomy.type). The Valid values are: GLOBAL – has no regions, REGIONAL – has 1 region, MULTI_REGION – has 2 or more regions.

All of the above fields have been requested by our customers.