You created a new site, your next step is to deploy to Azure, we need to consider which Azure services to leverage. Azure App Service provides a highly scalable self patching web hosting service for your applications. Now, we will look at how to use Visual Studio to publish your ASP dot net core web application to an Azure App Service Plan. Azure App Service is a service for hosting web applications, rest API's and back end services. App Service supports code written in .Net core, .Net framework, Java, Ruby, Node.js, PHP, and Python. App Service is ideal for most websites, particularly if you don't need tight control over the hosting infrastructure. The App Service plan defines the compute resources your app will consume. Where those resources are located, how many additional resources the plan can consume, and the pricing tier. These compute resources are analogous to the server farm and conventional web hosting. One or more apps can be configured to run on the same app service plan. When you deploy your apps, you can create an app service plan, or you can continue to add apps to an existing plan. However, apps in the same App Service plan share the same compute resources. You should determine whether the new app has the necessary resources, to do that. You need to understand the capacity of the existing App Service plan and the expected load for the new app. Overloading an App Service plan can cause reduced performance or downtime for your new and existing apps. You can define an app service plan in advance in the Azure portal with PowerShell. Or the Azure CLI or set one up as you publish your application in Visual Studio. Each App service plan defines regions such as West US, East US and so on, number of VM instances, size of VM instances. If it's small, medium or large and pricing tier, whether it's free, shared, basic standard premium, premium v2 or isolated. When creating an app service plan, you have to define a region or location where that plan will be hosted. Typically, you will choose a region geographically close to your expected customers. Let's now look at pricing and reliability levels, in shared compute free and shared the two base tiers. Run an app on the same as your VM as other app service apps, including apps of other customers. These tears allocate CPU quotas to each app that runs on the shared resources, and the resources cannot scale out. Free and shared plans are best for small scale personal projects with limited traffic demands, with a set limit of 165 megabytes of outbound data every 24 hours. In dedicated compute the basic, standard, premium and premium V2 tiers, run apps on dedicated as your VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more VM instances are available to you for scale out. The standard service plan is best suited for live production workloads where you are publishing commercial applications to customers. The premium service plans support high-capacity web apps where you do not want the additional costs of a dedicated or isolated plan. The isolated tier runs dedicated Azure VMs on dedicated as your virtual networks. Which provide network isolation on top of compute isolation to your apps, it provides the maximum scale out capabilities. You would only select an isolated service plan when you have a specific requirement for the highest levels of security and performance. You should isolate your app into a new app service plan when, the app is resource intensive. You want to scale the app independently from the other apps in the existing plan. And the app needs resources in a different geographical region, your App Service plan can be scaled up and down at any time. You can choose a lower pricing tier at first and scale up later when you need more app service features. A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed. It is a mechanism for organizing resources for the purpose of management, monitoring, and billing. You can use an existing resource group or create one directly from Visual Studio.