Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Branch: master
@d6veteran d6veteran
41 lines (25 sloc) 3.249 kB

Azure Platform Concepts

A Resource Provider (RP, for short) is simply an HTTPS RESTful API contract that Add-on owners will implement so a trusted Azure endpoint can provision, delete, and manage services on a user's behalf. Azure uses the Response from an RP to render and show a set of simple management operations in the Azure Management Portal.

The figure below gives a simplified view of how a user interacts directly with Azure through the Azure Management Portal, PowerShell scripts or *NIX command-line tools. Azure, in turn, communicates with your RP to manage the user's service.


Azure Concepts

Before we dive into RP concepts, it will be helpful to understand several Azure concepts first.

  • Every user who signs up for Azure logs in with a Microsoft account (e.g. or

  • The user then creates a Azure Subscription. A Subscription is a named entity e.g. 3-month Free Trial or MyApp Production associated with billing information. You can view your own Subscriptions on the Account Portal.

  • Next, the user creates one or more Resources such as a Website, Virtual Machine or Add-on. Website and Virtual Machine are two different ResourceTypes. Each Resource is deployed under exactly one Azure Subscription.

This is a conceptual view of a user's Resources:

  • There are two Subscriptions, Subscription A and Subscription B.
  • Subscription A has two Resources, named Resource 1 and Resource 2.
  • Subscription B has one Resource, named Resource 1.


Resource Provider Concepts

  • Each Resource's lifecycle is managed by a ResourceProvider. This is a common software design pattern, where a manager / orchestrator (Azure) relies on a provider (ResourceProvider) to provide specific functionality.

  • An RP introduces an additional concept, called a CloudService. Instead of nesting a Resource directly under a Subscription, Resources are nested under a named entity called a CloudService. Think of a CloudService as a container of resources, roughly analogous to an application.

Tying it together, this is a conceptual view of the user's resources:


  • There are two Subscriptions, Subscription A and Subscription B.
  • Subscription A has two CloudServices, named CloudService X and CloudService Y.
    • CloudService X has a single Resource, named Resource 1.
    • CloudService Y has a single Resource, named Resource 2. This Resource is provided by a Resource Provider named 'clouditrace' which exposes a single Resource of type 'monitoring'. Note that the combination of Subscription ID, Cloud Service ID and Resource Name must be unique.
  • Subscription B has a single CloudService, named Cloud Service X with a single Resource, named Resource 1.


Jump to Line
Something went wrong with that request. Please try again.