Skip to main content

Different ways of buying Azure Services (Pay-As-You-Go, EA, Direct CSP, Indirect CSP)

How do you buy Azure Services?

This simple question it's tricky in most of the cases. For many companies, it is not clear how they buy Azure Services, what kind of provider they are using.
Additional to this, they don't know what the difference between different ways of buying resources and which one is more suitable for their needs is.
Let's take a look at the 4 different ways on how we can buy Azure Services and try to identify the pros and cons of each option.

Direct from Microsoft
You can buy Azure Services directly from Microsoft. It means that the invoice is generated directly by Microsoft, and any issues that you have will be handled directly with them. This provides you with a clear process related to how tickets and incidents are handled and a direct link to Microsoft support. Even so, because you interact with support, they might ask you initially some dummy questions that help them to understand better your business and technical problem.
Besides this, Microsoft does not offer support from how to setup and configure Azure Services. You just buy Azure Services, and you are fully responsible for configuring and managing them.
From the cost perspective, usually, when you buy directly from Microsoft, you have Pay-As-You-Go subscriptions, where the Azure resources price are the same as the one listed on Azure Pricing. You don't get special discounts or deals.
Pros
  • Strong technical support with good experience
  • Standard procurement flow

Cons
  • Support might be slow
  • Rares are without discounts
  • No business consultancy
  • No direct support related to setup/implementation


Enterprise Agreement (EA)
You still buy Azure Services directly from Microsoft, but this is design for a large organisation that can make a commitment related to consumptions. The minimum commitment is for 3 years, where you need to put upfront the amount of money that you commit will consume.
You can combine under the same agreement the Azure Services and the licenses part, that can simplify internally the procurement procedures. The customer can create a new Azure subscription directly.
The most significant advantage of it is the level of discount that you get - that is pretty substantial. For this nice discount, you are hooked for at least 3 years, and you cannot reduce the cost of consumption for this period. You can anytime increase the commitment, but you cannot reduce it, and the extras that you need might not come with the expected discount.
Pros
  • Substantial discounts for high volume
  • Combine licenses and Azure Services under the same agreement 

Cons
  • Locked into a 3-year program
  • Lack of flexibility


Indirect CSP
Involves buying Azure Services from a partner that is indirect CSP. This involves a two-tiered structure where each Indirect CSP works with a Cloud Distributor that result in Azure Services to them.
This structure works great for small companies but can generate issues when things become a little more complex. Because of the two-tiered structure, two layers try to get their own margin on top of the price. Even so, Microsoft is offering good discounts to Cloud Distributor and the final price is much better in comparison with a Pay-As-You-Go. Creating a new Azure subscription involves requiring it from the Indirect CSP that needs to follow-up the request to the Cloud Distributor.
A second problem that can appear it is related to support. Because you don't buy directly from Microsoft a part of the support is offered by this two-tier structure. In general, small indirect CSP don't provide support, and you need to rely on CSP Distributor for technical support.
Pros
  • More personable experience
  • Each purchasing mechanism for local, small companies

Cons
  • Support offered by a 3d party
  • Profit margin is split between two tiers


Direct CSP
A direct CSP is buying Azure Services directly from Microsoft. The profit margin is not split into two different tiers as for Indirect CSPs. They get pretty nice discounts from Microsoft that can be seen by their customers also.
By working directly with the customers, they know the customer business and can provide better support and services but also at the same time to be able to offer reasonable prices. From the size perspective a direct CSP it is a larger organisation than an indirect CSP, that ensure better technical support. The support is more customer oriented in comparison with the one that you can get directly from Microsoft.
As for indirect CSP, you can scale up or down your resources based on your needs. Still, if the customer needs a new Azure Subscription, he needs to contact the Direct CSP to fulfil the request.
Pros
  • Ability to turn services off or on
  • Consultants that know the customer and the business
  • A better technical support team
  • More significant discounts in comparison with Indirect CSP or what Microsoft is offering
Cons

  • Price can be higher than EA

What option best suits you? 
You need to take into account all the pros and cons. It is important to know that going with a CSP can have significant advantages especially because you don't need to manage by yourself the subscriptions in comparison with EA and you also get more personalised support from a consultancy team that knows your business and needs.

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see