Share via

Azure Stack Validation Environment – Part 3: Subscriptions

  • Article

Azure Stack

Building an end-to-end validation environment

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:

Subscriptions

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.

  • Scale: Subscriptions are a logical limit of scale by which resources can be allocated. These limits include quotas of various resource types offered by an administrator. Scalability is the key element for understanding how the subscription strategy will account for growth as your user’s consumption of Azure services increases.
  • Administration: Resource Manager provides a granular RBAC model for assigning administrative privileges at the resource level, although administration of Azure Stack resources is ultimately defined at the subscription level.
  • Billing: Consumption of Azure services in Azure Stack is measured at the subscription level, forming a logical billing unit. Additionally, Resource Manager provides the ability to assign resource tags (see Tags) to provide additional information for granular chargeback/show back scenarios; this can be done based on either a resource group or resource.

Configuring Azure Active Directory users

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.

Defining subscriptions

There are a few aspects to consider when defining a subscription:

  • The subscription governs access to and use of the services via offers and plans to which the user will subscribe.
  • The Azure Stack operator manages the services offered to users in the subscription.
  • An Azure AD account is required, as this is how usage and billing will be managed.

We can think about how to use subscriptions in two key ways:

  • Self-service: The user selects Get a Subscription and browses the available offers their Azure Stack operator has created, and creates their own subscription.
  • Assigned: The administrator (or delegated administrator, see Delegation) creates subscriptions with offers, plans, and quotas aligned to them, and then assigns them to users.

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:

  • Different configurations of offers and plans for various user groups or organizations.
  • Segregation of users for security or compliance reasons.
  • Large-scale consumption or administrative isolation for a specific application.
  • Separate billing and usage monitoring for user groups or organizations.
  • Co-administrators from business units, departments, or other organizations.

Considering multiple subscriptions

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:

  • A subscription on its own does not carry any costs.
  • A subscription has its own administrators, and multiple subscriptions may require additional admins.
  • You need to overcome limits per subscription, such as number of virtual networks or CPU cores.

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.

Creating and deleting 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.

Choosing a subscription model

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.

Self-service subscription model

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.

Assigned subscription model

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.

Hybrid subscription model

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:

  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 a trial offer and configures it as public.
  3. The Azure Stack cloud operator (or delegated provider administrator) creates department user subscriptions and aligns to appropriate offers/plans/quotas.
  4. The Azure Stack cloud operator (or delegated provider administrator) assigns users to the required subscriptions.
  5. Self-service users can authenticate and access the Azure Stack user portal and select Get a Subscription for a public offer, such as a trial offer.
  6. Assigned users can authenticate and access the Azure Stack user portal and access their assigned subscriptions.
  7. All users can now deploy resources within the boundaries imposed by the quotas for their subscription.

Naming subscriptions

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:

  • Company: Service providers must ensure that the company name is included.
  • Department: Enterprises may want to use department names as an identifier for the groups within the organization.
  • Product line: Some enterprises need to include the name of a product or application.
  • Environment: Some enterprises have multiple environments for the lifecycle management of applications, such as PROD, QA, or DEV, and want to identify them.
  • Characters: Be aware that certain characters are not allowed, or will cause issues in naming conventions, like an ampersand.

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:

  • Storage names must be unique within an Azure Stack environment.
  • Some resource names must be alphanumeric.
  • Some resources are case sensitive.
  • Some objects’ names are constrained by length. You can determine this by reviewing the information provided in the portal, as shown in Figure 18.

Figure 18. Constraints error in Azure Stack portal

You can read more about the best practices for Azure naming conventions here: /en-us/azure/architecture/best-practices/naming-conventions

Adding additional subscription administrators

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.

Azure Resource Manager limits

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

 

Timers

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.

 

Azure CAT Guidance

"Hands-on solutions, with our heads in the Cloud!"

Comments

  • Anonymous
    November 19, 2017
    Hi Ed, Thank you for these Awesome Blogpost about Microsoft Azure Stack ! :-) I will Share the Blog posts with the community and with Education for the AzureStack (ASDK) in the Classroom.Cheers, James
    • Anonymous
      November 20, 2017
      Fantastic. Thanks, James!
  • Anonymous
    November 29, 2017
    UPDATE: I added the links to all five parts of this article series.