Due to commercial and technical issues, there some discrepancies between capabilities of Azure Subscriptions allocated within Nebula and Subscriptions purchased directly from Microsoft. This article lays out some of the key differences.
Azure Cost Management Differs from NTT Transactional Model
As described in Introduction to Usage Reporting, all usage of Nebula Subscriptions is transacted based on the NTT Transactional Model’s foundation of Microsoft’s Pay-As-You-Go offers. When viewing usage in Azure Cost Management, the ACM system is unaware of this pricing model and instead will base its calculations on Enterprise Agreement pricing offers (AZR-0017P and AZR-0148P), which introduces discrepancies between the Azure Cost Management view and Nebula charges due to the differences in the pricing model:
- Pay-As-You-Go offer has lower unit prices for higher usage tiers, while EA uses a single rate for all usage
- Azure Pay-As-You-Go offer uses prices with 6 decimal place accuracy, while Enterprise Agreement price list only uses two decimal places with different quantities of measurement
- Pay-As-You-Go offer uses a simpler usage aggregation and rounding approach than EA methodology
- EA rates have some price protection clauses that in some cases blunt the impact of price increases that may occur with Pay-As-You-Go rates
For USD customers, Azure Cost Management will use “list price” EA rates. The EA rates are not published publicly, but the discrepancies are fairly small. In aggregate usage, the EA list price will be within +/- 1.5% of the equivalent Pay-As-You Go list price used in the Transactional Model. However, specific subscriptions may vary more depending on usage types. For example, a Subscription with a lot of internet bandwidth usage and a small amount of compute would show a larger discrepancy as Internet egress pricing is tiered under Pay-As-You go, resulting in significantly lower charges that the EA list price when the internet bandwidth usage is high.
With the introduction of changing exchange rates described in NTT Transactional Model JPY and AUD Exchange Rates, the discrepancies have become more problematic with JPY and AUD subscriptions. Because of the unique nature of the MACC agreement that underpins the EA, the discounts NTT receives are calculated manually. This means Microsoft’s Azure Cost Management system is unaware of them and the “price protection” functions described above cause the system to use EA “list prices” based on a mix of different exchange rates. This is causing larger discrepancies in the range of 10-15%.
Note NTT has active development requests with Microsoft to address this issue and so we hope to solve it in the future.
No “Shared” Scope Reserved Instance Option
When purchasing an Azure Reserved Instance, users choose the scope of the RI as discussed in the Reservation scoping options section of the Azure RI documentation. Because Nebula-provisioned Subscriptions are provisioned in a SCE that is shared with other Provisioning Entities and Nebula Organizations, the “Shared” scope option is disabled. In the context of the EA, shared scope means that the RI can apply to usage anywhere in the SCE, so if this option was allowed, an RI purchased by one Nebula Organization could be applied to usage of other Nebula Organizations.
Azure Savings Plans are Not Supported
Azure Savings Plan is a Microsoft offering that allows users to commit to an hourly spend on compute resources for a one or three year period (similar to Reserved Instances) in exchange for a discounted rate. Unlike RI, you do not need to specify a specific VM type for the hourly spend commitment.
This option is currently disabled for all Nebula Organizations as the NTT Transactional Model doesn’t define how such an offering would work in relation to the Pay-As-You-Go Model used as the pricing basis. Given the lack of definition and development, the Nebula system isn’t set up to rate savings plan usage and wouldn’t pass on the underlying discounts to the purchasing Nebula Organization.re.
Tools Requiring EA Administrator Access are Not Supported
Microsoft and some third parties offer tools that require EA Administrator access. For example, the Azure Cost Management Power BI Connector requires this level of access. Similarly, some (but not all) third party tools that perform spend access functionality sometimes have similar requirements – Anodot is an example of one that requires it, whereas VMware CloudHalth does not require it and can be enabled as discussed in How to Enable VMware CloudHealth to Consume an Azure Subscription.
By policy, we do not provide administrator access to the Enterprise Agreement SCE, because the SCE are all shared (“multi-tenant”), meaning they have Subscriptions belonging to over 60 separate legal entities. Many of the entities using the agreement aren’t even part of the NTT Ltd. corporate structure as the structure of the strategic deal allows any majority-owned NTT entity to use it. The contractual requirements with those entities require that we not provide their data to other entities.