Last Updated on August 12, 2021 by Alam Mohammed
Create Azure App Service Web Apps is part of Develop Azure compute solutions topics. The total weight of this in the exam will be 25-30%. This training post is designed to help and provide readers with a better understanding of the topic mentioned.
Disclaimer: This is not a training article to help complete the Microsoft Azure AZ-204, but it provides a good insight into the areas within these topics. Labs and hands-on work are essential to passing most Microsoft Azure exams.
Create Azure App Service Web Apps:
Create an Azure App Service Web App
App Service
Azure App Service not only adds the power of Microsoft Azure to your application, such as security, load balancing, autoscaling, and automated management. You can also take advantage of its DevOps capabilities, such as continuous deployment from VSTS, GitHub, Docker Hub, and other sources; and package management, staging environments, custom domain, and SSL certificates.
With App Service, you pay for the Azure compute resources that you use. The compute resources you use are determined by the App Service plan that you run your apps on.
Scalable hosting for web applications:
- Provides a quick way to host your web application in the cloud
- Allows you to scale your web app without being required to redesign for scalability
- Integrates with Visual Studio
- Provides an open platform for many different programming languages
Advantages:
- Near instant deployment
- SSL and Custom Domain Names available in some tiers
- WebJobs provide background processing for independent scaling
- Can scale to larger machines without redeploying applications
Creating a Web App with Azure PowerShell
Command | Notes |
New-AzResourceGroup | Creates a resource group in which all resources are stored |
New-AzAppServicePlan | Creates an App Service plan |
New-AzWebApp | Creates an Azure Web App |
Set-AzResource | Modifies a resource in a resource group |
Creating a Web App with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Creating an App Service plan with Azure PowerShell

Create Azure App Service Web Apps:
enable diagnostics logging
Create Azure App Service Web Apps:
configure web app settings including SSL, API, and connection strings
App Service settings
For ASP.NET developers, configuring app settings in App Service is similar to configuring them in <appSettings> in Web.config or appsettings.json. The difference is that the values in App Service override the values in Web.config or appsettings.json. You can keep development settings in Web.config or appsettings.json (for example, local MySQL password), but keeping production secrets (such as Azure MySQL database password) in App Service is ideal. This is because the same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.
You can configure:

Path mappings
Windows:
- Custom IIS handler mappings
- Virtual applications/directories
Containerized:
- Custom-mounted storage
Updating app runtimes

When adding a new version (major or minor), it installs side-by-side with existing versions. You can also manually upgrade your app to the new version. If you configured the runtime version in a configuration file (such as web.config and package.json), you need to upgrade by using the same method. If you used an App Service setting to configure your runtime version, you can change it in the Azure portal or by running an Azure CLI command in the Cloud Shell.
To update the application runtime, use the az webapp config set command with the appropriate parameter for your runtime.
OS and runtime patching
App Service is a platform as a service (PaaS), which means that the OS and application stack are managed for you by Azure; you only manage your application and its data.
Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly. These updates are applied automatically, in a way that guarantees the high availability SLA of Azure services.
Inbound and outbound IP addresses
Each app has a single inbound IP address:
- Regardless of scale-out quantity
Inbound IP address can change:
- Delete an app and re-create it in a new resource group
- Delete the last app in a resource group + region combination and re-create it
- Delete an existing SSL binding
You can opt to use a state inbound IP
Each app has a set number of outbound IP addresses:
- The set and quantity changes as you scale your app between tiers
When IP addresses change
Regardless of the number of scaled-out instances, each app has a single inbound IP address.
The inbound IP address might change when you perform one of the following actions:
- Delete an app and recreate it in a different resource group.
- Delete the last app in a resource group and region combination and recreate it.
- Delete an existing SSL binding, such as during certificate renewal
Find outbound IP addresses

Create Azure App Service Web Apps:
Implement autoscaling rules, including scheduled autoscaling, and scaling by operational or system metrics
Autoscale
Autoscale is a built-in feature of Azure Cloud Services, Mobile Services, Virtual Machines, and websites that helps applications perform their best when demand changes. Of course, performance means different things for different applications. Some apps are CPU bound, others memory bound. For example, you could have a web app that handles millions of requests during the day and none at night. Autoscale can scale your service by any of these—or by a custom metric you define.
Autoscale metrics
Metric | Metric identifier | Description |
CPU | CpuPercentage | The average amount of CPU time used across all instances of the plan |
Memory | MemoryPercentage | The average amount of memory used across all instances of the plan |
Data in | BytesReceived | The average incoming bandwidth used across all instances of the plan |
Data out | BytesSent | The average outgoing bandwidth used across all instances of the plan |
HTTP queue | HttpQueueLength | The average number of both read and write requests that were queued on storage. A high disk queue length is an indication of an application that might be slowing down due to excessive disk I/O. |
Disk queue | DiskQueueLength | The average number of HTTP requests that had to sit in the queue before being fulfilled. A high or increasing HTTP queue length is a symptom of a plan under a heavy load. |
Autoscale patterns
- Scale based on CPU
- Scale differently on weekdays vs. weekends
- Scale differently during holidays
- Scale based on custom metrics
Autoscale concepts
Each resource can have one autoscale setting:
- Autoscale settings can have one-to-many profiles
- Profiles can have one-to-many rules
Autoscale increases instances horizontally within bounds:
- Bounds are set by using the minimum, maximum, and default values
Thresholds are calculated at an instance level
- Autoscale successful actions and failures are logged to the Activity Log
Autoscale workflow
1.Metrics are measured for a resource
2.When conditions are met (threshold surpassed), autoscale triggers:
a.Perform scale actions
b.Send notifications (alerts)
c.Send messages to webhooks for external automation

More topics on Develop Azure compute solutions:
Microsoft Azure AZ-204 exam topics:
If you have covered the current topics in Develop Azure compute solutions then you can have a look at the other topic areas:
Develop for Azure storage (10-15%)
Implement Azure security (15-20%)
Monitor, troubleshoot, and optimize Azure solutions (10-15%)
Connect to and consume Azure services and third-party services (25-30%)
View full documentation Microsoft Azure: AZ-204 exam content from Microsoft
Leave a Reply