When one starts using Azure, there are many new things to learn, like how resources are configured and used in the environment. So, I headed over to the Azure portal (https://portal.azure.com) and created an account. There are several things to consider here; you can pay as you go, configure an Enterprise Agreement, use an Azure Pass, sign up for Dev Essentials, or use an MSDN subscription to set up how you will pay for the resources. You can also configure spending limits to help control costs and also control enterprise costs. With an Enterprise Agreement, you can use a Dev/Test subscription to help offset costs. Enterprise Agreement Dev/Test subscriptions get you a significant price reduction, percentage-wise, over production versions. If you plan on using Azure a lot, I would recommend engaging with Microsoft to get an Enterprise Agreement. To get an Enterprise Agreement, you will need to reach out to a Microsoft account representative for the requirements, which you can review here: https://www.microsoft.com/en-us/licensing/licensing-programs/enterprise.aspx. As a side note, you can also create your account through Office 365 services, but for the sake of simplification, we will stick with the Azure portal side. Once your account has been created, you will access the portal and be presented with the Azure default dashboard. For a Tenant to be created, you must have what is referred to as a privileged account, which is defined as an Azure account in the Tenant or Enterprise Agreement. At the end of the day, it is an organization's network account.
Once the Tenant has been created, it will act as a virtual representation of your organization within Azure. This equates to the earlier physical network structures that were used within an organization which was secured by firewalls, network resources, and directory services that were usually housed in a data center. A Tenant in Azure follows the same structural basis but is a virtual instance of the organization that is backed by the Azure Active Directory (AAD) services. All Tenants require AAD, as this is the digital identity service model for securing all SaaS, IaaS, and PaaS resources. Think of the Tenant as your organization container, with the same type of physical boundaries as a physical data center network would have. The following diagram shows a simplified view of a Tenant:
AAD services, as shown in the preceding diagram, can be synchronized with an on-premise Active Directory (AD) through a process called Active Directory Federation Service (ADFS). This is the process of syncing users/groups and helps with providing access to cloud and on-premises resources without the need to add users to both directory services. Now that we have our Tenant, it has hard resource sharing boundaries that can’t be broken, just like your physical network. A Tenant is also assigned a Tenant ID that is used to identify the organization, and the privileged account is assigned the owner. Within your Tenant, you have an Office 365 or O365 container that houses your SaaS products such as Exchange, SharePoint, Power App, and so on, and the Azure Container that houses your subscriptions and resource groups. This book isn’t about O365 and the SaaS-based container, but more about the Azure container and the guidance needed to architect, develop and deploy solutions. Now, regarding Azure, we need to discuss the structure of how resources are handled: you start with a Tenant, then you have a subscription, and then you have a resource group, as shown in the following diagram:
A Subscription (Sub) in Azure is a container that groups together resources and users, and also has limits. The limits have changed over time and can be increased with support tickets from Microsoft. You can review the limits at https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits. Subs themselves have sharing limits as well. For instance, currently, Key Vaults, App Service Certs, and Express Routes, to name a few, do not span subscriptions. You can also include resources in Resource Groups (RG) from another subscription. You also do not have the intellisense in the portal for resources, not in the same subscriptions. RGs are application life cycle resource containers within a subscription that houses all the resources that make an application or piece of an application or infrastructure. You create a subscription when your tenant is created. You can also do this through your Enterprise Portal.
When you have created your Tenant and start building out your Subs, you should keep to a simplistic approach. This means that you should start minimally, for example, you should have a Tenant and a Sub or two. I generally start with a production Sub and a non-production Sub. In your non-production Sub, you should get Dev/Test pricing through you EA or use MSDN as your non-production Sub by using resource groups at application containers.
The reason for this suggestion is that resources have boundaries, and hybrid solutions require VPNs or Express Route, which have Sub boundaries and require VNet integration to other Subs, which will become multiple points of failure. I suggest you only add more Subs based on very specific needs, such as client work you need to transfer later on to a client.
