The Azure Bakery series: Resources

By adding resources to the previous layers, the cake comes together! We’ll look at the details of the resources and the design recipe. After this, we’ll bake the cake.

The Azure Bakery series: Resources

Welcome back for the fifth and last layer of our cake. Today, we’ll add resources to the previous layers. With these resources, the layers of the cake come together, making it ready to serve!

The resources represent the building blocks of your solution, like the service running the application, the database storing the data, the key vault containing the secrets, and the log analytics workspace for the metrics and logs.

An Azure cake.

We’ll examine the prerequisites, the resources, and the environment's design recipe. After going through all the details, we will bake the Azure cake.


Before you can start baking the cake, there are some prerequisites to fulfill:

  • Azure tenant and user account: You’ll need an Azure tenant, an Azure Active Directory (Azure AD) instance. This instance is the base layer of our cake, allowing you to create an identity (user account) to connect to Azure, set up the environment, and deploy the resources.
  • Subscriptions: You’ll need two subscriptions, which you use as management and landing zone subscriptions. You need owner permissions on these subscriptions to deploy the resources and delete lock. You’ll minimize the costs by removing the resources at the end.
  • Azure CLI: You’ll need the Azure command-line interface to deploy the resources. For the deployment, you use Azure Resource Manager (ARM) templates. You can find more information about the Azure CLI in the documentation.
  • Git: You’ll need Git to clone the GitHub repository that includes the ARM templates, and you can find more information about Git in the documentation.


This post will add the resources for a web application with an SQL database as a backend. Let’s review the solution's resources.

App Service plan: This plan includes the underlying virtual machines that host your app and defines the set of available compute resources. All the apps associated with this plan run in the same virtual machine instances.

There are three available tiers:

  • Shared: Runs the apps on the same resources as other customers.
  • Dedicated: Runs the apps on dedicated resources. Only the apps in the plan share these resources.
  • Isolated: Adds network isolation on top of the compute isolation of the dedicated tier.

You can find the App Service plan overview in the documentation.

App Service app: This is a fully managed platform for running your cloud applications in multiple programming languages without managing the underlying infrastructure with features such as autoscaling and virtual network integration.

The app is associated with a plan and contains two deployment slots: staging and production. The deployment slots allow you to stage deployments and swap them into production. You can find more information about App Service in the documentation.

Azure SQL Database: This is a relational database-as-a-service based on Microsoft SQL Server. Enabling you to use the tools, languages, and resources you know. The database runs on an Azure SQL Server containing multiple databases.

There are three available offerings:

  • Azure SQL Database: A managed database service that includes serverless computing.
  • Azure SQL Managed Instance: This fully managed instance is nearly 100% compatible with the latest SQL Server database engine. It's best suited for migrating existing apps.
  • SQL Server on Azure Virtual Machines: You can migrate your existing SQL Server instances with 100% compatibility and operating system-level access.

You can find more information about Azure SQL in the documentation.

Azure Key Vault: This is a service for storing and accessing API keys, passwords, certificates, or cryptographic keys. Azure Key Vault centralizes the storage of your sensitive information, enabling you to control its distribution and minimize the risk of accidentally leaking these secrets. You can find more information about Azure Key Vault in the documentation.

Azure Monitor: This Azure monitoring service allows you to collect, analyze, and act on telemetry from your cloud and on-premises environment, enabling you to maximize the performance and availability of your applications. You can find more information about Azure Monitor in the documentation.

Log Analytics workspace: This service is the other half of the Azure monitoring service and supports collecting and analyzing data from, for example, Azure Monitor. A sophisticated query language enables you to analyze millions of records quickly. You can find more information about Log Analytics in the documentation.


The environment's design recipe is based on the enterprise-scale landing zone architecture framework, illustrated in the diagram below.

The recipe diagram.

The management subscription contains a Log Analytics workspace for centralizing logs, metrics, and audit data. The landing zone subscription includes the web application based on an App Service app with an Azure SQL Database as a backend.

The App Service app uses a system-assigned managed identity to access and retrieve the Azure SQL Server’s connection string from the Azure Key Vault. There’s an access policy with the object’s identifier of the managed identity to access the key vault’s secrets.

And an auto-scaling rule is configured to scale the app based on the CPU load. Two deployment slots allow you to deploy into staging and swap this deployment into production—and four Azure Monitor alert rules to monitor the web application.

Baking the cake

Let’s bake the Azure cake! We’ll go through the baking procedure step-by-step. Ensure you’ve fulfilled the prerequisites mentioned at the beginning of this post. Everything, including the ARM templates, is in the supporting GitHub repository.

The management groups are not mandatory and are not part of this deployment. If you want to, you can (manually) set them up. You can find the instructions on creating a management group in the documentation.

Start your preferred terminal (create) and go to the code directory, for example, where you want to clone the GitHub repository.

mkdir code
cd code

Clone the the-azure-bakery-series GitHub repository. This repository contains the ARM templates to deploy the resource groups, Log Analytics workspace, and web application.

git clone

Move your terminal into the cloned the-azure-bakery-seriesdirectory.

cd the-azure-bakery-series

Start your preferred terminal for connecting and authenticating to Azure using the Azure CLI and your identity (user account).

az login

List the available subscriptions and locate the preferred subscription identifiers.

az account list --output table

Deploy the mgmt-rgresource group. The deployment requires a location (twice). And the management subscription identifier.

az deployment sub create \
  --location location \
  --template-file src/management/mgmt-rg.deploy.json \
  --parameters location=location \
  --subscription mgmt_subscription_id

Deploy the Log Analytics workspace. The deployment requires the management subscription identifier. And a unique identifier because of the global naming scope.

az deployment group create \
  --resource-group mgmt-rg \
  --template-file src/management/mgmt.deploy.json \
  --parameters uniqueId=unique_id \
  --subscription mgmt_subscription_id

After the deployment, the mgmt-rg resource group should look like this.

The portal showing the mgmt-rg resource group.

Deploy the app-rg resource group. The deployment requires a location (twice). And the landing zone subscription identifier.

az deployment sub create \
  --location location \
  --template-file src/landing-zone/app-rg.deploy.json \
  --parameters location=location \
  --subscription lz_subscription_id

Deploy the web application. The deployment requires a unique identifier because of the global naming scope of some resources. Use the same identifier as before.

It also needs the management and landing zone subscription identifiers. It'll prompt you for the Azure SQL Server’s admin password.

az deployment group create \
  --resource-group app-rg \
  --template-file src/landing-zone/app.deploy.json \
  --parameters uniqueId=uniqueId \
    mgmtSubscriptionId=mgmt_subscription_id> \
  --subscription lz_subscription_id

After the deployment, the app-rg resource group should look like this.

The portal showing the app-rg resource group.

Open the App Service app, copy the URL, and use it in your browser. The default web application will open.

Remove the delete locks, resource groups, and resources to prevent unnecessary costs. The removal requires the management and landing zone subscription identifiers. And it'll prompt you to confirm twice.

az lock delete \
  --name rgCanNotDelete \
  --resource-group app-rg \
  --subscription lz_subscription_id
az group delete \
  --name app-rg \
  --subscription lz_subscription_id
az lock delete \
  --name rgCanNotDelete \
  --resource-group mgmt-rg \
  --subscription mgmt_subscription_id
az group delete \
  --name mgmt-rg \
  --subscription mgmt_subscription_id


That's it! We’re finished with the resources and, therefore, baking the Azure cake! In the previous posts, we went through all the layers that make up our cake. You can find an overview of the posts, including the links, in the introduction to the series.

Thank you so much for taking the time to read this series. I hope you enjoyed it as much as I did. See you next time!