First published on MSDN on Nov 18, 2017
Part 3: Subscriptions
By Paul Appleby, Kath McBride, and Joel Yoker. Edited by Derek Gamlyn and RoAnn Corbisier.
Azure Customer Advisory Team (AzureCAT)
This article is Part 3 in the Azure Stack Validation Environment series:
E-Book - This series of blog posts is available as an e-book on Azure.com:
Azure Stack subscriptions grant users access to the Azure Stack services being offered, as well as to the Azure Stack portal itself. Subscriptions are the first thing a user sees when beginning to use Azure. Like Azure, Azure Stack subscriptions provide a logical boundary of scale, administration, and billing for your users who are consuming services from Azure Stack.
You will need to configure your users in Azure Active Directory (Azure AD) to allow them to access resources within Azure Stack. Azure Stack users are usually configured as Azure AD users, while Azure Stack operators completing the infrastructure installation will need to be provisioned with global admin organizational rights. Users need to be members of your Azure AD domain and will use the account and password assigned to them when logging into Azure Stack. Figure 14 shows where to configure users in Azure AD.
Figure 14: Configuring users in Azure AD
Read the article Add a new Azure Stack account in Azure Active Directory for additional instructions.
There are a few aspects to consider when defining a subscription:
We can think about how to use subscriptions in two key ways:
Many of your early decisions in architecting and planning an Azure Stack environment, and related subscriptions, can have an impact on future decisions and designs as the cloud environment grows. Get participation and input from several groups within your organization, including IT leadership and those responsible for networking, security, and identity within your organization.
To help you in defining your subscriptions, consider whether you require:
A single subscription will work just fine for most of your user organizations, but others may require multiple subscriptions for more granular control.
Using multiple subscriptions can create complexity. If isolation is required, then you may opt for subscription administration. Some considerations for multiple subscriptions include:
Multiple subscriptions may introduce additional complexity when you consider that the on-premises networking and security infrastructures are typically shared resources within an organization. For most large organizations, core IT services such as patch management, monitoring, and auditing are frequently provided by dedicated staff who are trained in a set of centralized solutions. As you design your subscriptions, be aware that you may need to extend or duplicate services, including monitoring, patching, and antivirus to span these services across subscriptions.
As an Azure Stack operator, you can create or delete subscriptions via the portal or through the Azure Stack PowerShell module . This applies to both administrator subscriptions and user subscriptions. But be careful, because when you delete a subscription you will remove all resources that are part of that subscription, and recovery from backups will be your only option.
NOTE: A user who creates a subscription can also delete their own subscriptions. |
It is critical to develop your subscription, fabric, and administrative models together to have a cohesive approach towards subscription design. Understanding each component’s considerations, constraints, and how each impacts the others is critical to building an Azure Stack solution that can scale and be flexible enough to support the needs of your business.
If your organization allows for users to consume IT services on-demand or is choosing to monetize your Azure Stack deployment, you may want to leverage self-service for user subscriptions. The same care around configuring offers and plans is needed; however, each user will be allowed to get a subscription of the size and type they require directly from the Azure Stack portal. Once the subscription is created, assigned users can start consuming the services that are offered. Figure 15 provides an example of the self-service subscription model.
Figure 15: Example of a self-service subscription model
A high-level process for the self-service subscription model is as follows:
1. The Azure Stack cloud operator (or delegated provider administrator) creates offers, plans, and assigns quotas.
2. The Azure Stack cloud operator (or delegated provider administrator) makes offers public.
3. Users can authenticate and access the Azure Stack user portal and select Get a Subscription.
4. Users can browse the available offers and select one for their subscription.
5. Users can now deploy resources within the boundaries imposed by the quotas for that subscription.
In this model, users are specifically assigned to subscriptions via assignment at the plan level. The Azure Stack operator does this in the administrative portal under User Subscriptions. Offers are not made public, and the operator (or delegated administrator, see Delegation ) can choose to utilize custom URLs as well to ensure the boundaries imposed by these hidden subscriptions are not compromised. To onboard user subscriptions, the Azure Stack operator will send users a link to their specific URL, and after authentication, they will have access to the subscription and the offers, plans, and quotas that are configured for their subscription. You can see an example of the assigned subscription model in Figure 16.
While requiring slightly more management from IT, the assigned subscription model best fits service providers or enterprises where knowledge of other users is either a security issue or otherwise unwanted. Your organization may also choose this model to facilitate compliance, restrictions on co-administrators viewing other subscriptions, or special requirements for billing.
Figure 16: Example of an assigned subscription model
A high-level process for the self-service subscription model is as follows:
1. The Azure Stack cloud operator (or delegated provider administrator) creates offers, plans, and assigns quotas.
2. The Azure Stack cloud operator (or delegated provider administrator) creates department level subscriptions and aligns to appropriate offers/plans/quotas.
3. The Azure Stack cloud operator (or delegated provider administrator) assigns users to the subscription to which they require access.
4. Users access the Azure Stack user portal and assigned subscriptions are automatically available to them.
5. Users deploy resources within the boundaries imposed by the quotas for each assigned subscription.
Another scenario for this subscription model is for organizations requiring an additional level approval using an IT Service Management (ITSM) solution or process. In this scenario, some customers may require approvals before consuming Azure services within the organization. Those customers can easily achieve this by automation, with their existing ITSM portal listing offers through the APIs, possibly even syncing them in their Configuration Management Database (CMDB), and automation assigning the subscriptions after the required approval workflow.
Depending on circumstances, you may opt to use a hybrid subscription model that includes a combination of self-service and assigned subscriptions, as shown in Figure 17. For instance, your organization might have both experienced and novice users, each with different requirements. The experienced users need the ability easily acquire a subscription. But novices would have a trial offer that contains minimal quotas for resources, enabling users to get started quickly with Azure services within your organization. If you want them to consume a specific subscription, you can either use publicly visible offers or create offers that are private, assigning them to specific subscriptions.
Figure 17: Example of a hybrid subscription model
A high-level process for the self-service subscription model is as follows:
When naming your subscriptions or any other objects within Azure Stack, you will want to consider using a consistent set of naming conventions to ease management and facilitate billing. Considerations when naming subscriptions are provided below:
Naming standards extend beyond subscriptions. There are many objects in Azure Stack that require proper naming so they can be easily identified, for example, storage accounts, virtual machines, availability sets, and virtual networks. When choosing your naming standard, keep in mind that you must work within several constraints:
Figure 18. Constraints error in Azure Stack portal
You can read more about the best practices for Azure naming conventions here: https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions
You can add additional administrators to a subscription using role-based access, which will allow others to assist you in managing offers and plans. Select the subscription you want to add a co-administrator to, and then click on the Access icon as shown in Figure 19.
Figure 19: In the blade for the resource, click the Access icon
Clicking Access opens the Users blade where you can then add additional Azure AD users as Owners, Contributors, or Readers.
Figure 20: In the Users blade, add users and manage roles
Read the article Manage Role-Based Access Control for information on adding additional administrative users.
Like other Azure services, Resource Manager limits also apply to Azure Stack at the subscription level and are generally the same values as those found in Azure. The exception is any recent changes in Azure that have not yet propagated to Azure Stack.
These limits are applied per-region for each region accessible by your subscription. Service management limits are limits that are applied per-subscription, and the tables below provide examples of these limits.
Subscription level throttling
Resource | Default Limits |
Resource Quota Limit | 800 |
Resource Group Name Length Limit | 90 |
Resource Group Quota Limit | 800 |
Resource Move Limit | 800 |
Deployment Name Length Limit | 64 |
Deployment Quota Limit | 800 |
Subscription Tag Quota Limit | 900 |
Subscription Tag Name Quota Limit | 100 |
Tenant Resources Query Subscription Count Limit | 40 |
Tenant Resources Query Subscription Batch Size | 10 |
Tag Key Limit | 512 |
Tag Value Limit | 256 |
Max Tags per Resource | 15 |
Realtime Tag Count Threshold | 600 |
Tenant level request throttling
Resource | Default Limits |
Max Tenant Read Requests | 15000 |
Max Tenant Write Requests | 1200 |
Tenant Throttling Window Time | 01:00:00 |
Tenant Throttling Bucket Size | 00:05:00 |
Health check request throttling
Resource | Default Limits |
Unauthenticated Throttling Max Requests | 15000 |
Unauthenticated Throttling Window Time | 01:00:00 |
Unauthenticated Throttling Bucket Size | 00:05:00 |
Per subscription throttling
Resource | Default Limits | |
Max Subscription Bad Requests | 15000 | |
Max Subscription Write Requests | 1200 | |
Subscription Throttle Window Time | 01:00:00 | |
Subscription Throttle Bucket Size | 00:05:00 | |
Updates to subscriptions are made visible in the portal based on timers. If you create a new subscription, the change is immediate upon completion. However, to see the changes, you must refresh the portal.
General portal updates to subscriptions are hourly, so they will take place within 60 minutes after a given change.
This article is Part 3 in the Azure Stack Validation Environment series:
The next article in this series is Part 4: Services and Resource Manager.
AzureCAT Guidance
"Hands-on solutions, with our heads in the Cloud!"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.