Merge pull request #59 from Azure/docs-update

Docs update

docs/AAC/LOB-ILB-ASEv3-content.md

@@ -0,0 +1,85 @@
+# Line of Business Applications using App Service Environment v3
+This article focused on a solution centered around App Service Environment (ASE) v3, the newest version of App Service Environment with foundational improvements from previous versions. The changes with ASE v3 which removes the stamp fee and simplifies networking configurations make ASE a compelling offer for enterprise customers who require additional security and network isolation around their App Services. The rarchitecture will be applicable for an internal LOB application using an internal load balancer. Customer will have the flexibility to leverage existing resources in the Azure Landing Zone (ie. Resources in the Hub VNet) or deploy this solution as a self-contained workload. 
+
+## Architecture
+
+![alt text.](./media/folder_name/architecture-diagram.png)
+
+_Download a [Visio file](https://arch-center.azureedge.net/architecture.vsdx) that contains this architecture diagram. This file must be uploaded to `https://arch-center.azureedge.net/`_
+
+### Components
+
+The solution uses the following Azure services:
+
+- **[App Service Environment v3 (ASEv3)](https://docs.microsoft.com/en-us/azure/app-service/environment/overview)** is a single tenant  service for customers that require high scale, network isolation and security, and/or high memory utilization. Apps are hosted in [App Service plans](https://docs.microsoft.com/en-us/azure/app-service/overview-hosting-plans) created in ASEv3 with options of using different tiers within an Isolated v2 Service Plan. Compared to earlier version of ASE numerous improvements have been made including, but not limited to, network dependency, scale time, and the removal of the stamp fee. This reference architecture uses an internal App Service Environment v3. 
+  
+ - **[Azure Private DNS Zones](https://docs.microsoft.com/en-us/azure/dns/private-dns-privatednszone)** allow users to manage and resolve domain names within a virtual network without needing to implement a custom DNS solution. A Private Azure DNS zone can be aligned to one or more virtual networks through [virtual network links](https://docs.microsoft.com/en-us/azure/dns/private-dns-virtual-network-links). Due to the internal nature of the ASEv3 this reference architecture uses, a private DNS zone is required to resolve the domain names of applications hosted on the App Service Environment.
+
+- **[Application Insights](https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview)** is a feature of Azure Monitor that helps Developers detect anomalies, diagnose issues, and understand usage patterns with extensible application performance management and monitoring for live web apps. A variety of platforms including .NET, Node.js, Java, and Python are supported for apps that are hosted in Azure, on-prem, hybrid, or other public clouds. Application Insights is included as part of this reference architecture to monitor behaviors of the deployed application.
+
+- **[Log Analytics](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview)** is a feature of Azure Monitor that allows users to edit and run log queries with data in Azure Monitor Logs, optionally from within the Azure portal. Developers can run simple queries for a set of records or use Log Analytics to perform advanced analysis and visualize the results. Log Analytics is configured as part of this reference architecture to aggregate all the monitoring logs for additional analysis and reporting.
+
+- **[Azure Virtual Machine](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/overview)** is an on-demand, scalable computing resource that can be used to host a number of different workloads. In this reference architecture, virtual machines are used to provide a management jumpbox server, as well as a host for the DevOps Agent / GitHub Runner. 
+
+- **[Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts)** is a cloud service to securely store and access secrets ranging from API keys and passwords to certificates and cryptographic keys. While this reference architecture does not store secrets in the Key Vault as part of the infrastructure deployment of this reference architecture, the Key Vault is deployed to facilitate secret management for future code deployments. 
+
+- **[Azure Bastion](https://docs.microsoft.com/en-us/azure/bastion/bastion-overview)** is a Platform-as-a-Service service provisioned within the developer's virtual network which provides secure RDP/SSH connectivity to the developer's virtual machines over TLS from the Azure portal. With Azure Bastion, virtual machines no longer require a public IP address to connect via RDP/SSH. This reference architecture uses Azure Bastion to access the DevOps Agent / GitHub Runner server or the management jumpbox server. 
+
+
+## Considerations
+
+These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see [Microsoft Azure Well-Architected Framework](/azure/architecture/framework).
+
+- Review the reference implementation resources at [LOB-ILB-ASEv3](../../reference-implementations/LOB-ILB-ASEv3/) to better understand the specifics of this implementation.
+- It is recommended that you clone this repo and modify the reference implementation resources to suit your requirements and your organization's specific landing zone guidelines.
+- Ensure that the service principal used to deploy the solution has the required permissions to create the resource types listed above.
+- Consider the CI/CD service you will use for deploying the reference implementation. As this reference implementation is an internal ASE, a self-hosted agent is needed to execute the deployment pipelines.  As such the choice is to use either a DevOps Agent or a GitHub Runner. Refer to the [user guide](../README.md) on specific configuration values required for each.
+- Consider the region(s) to which you intend deploying this reference implementation, and consult the [ASEv3 Regions list](https://docs.microsoft.com/en-us/azure/app-service/environment/overview#regions) to ensure the selected region(s) are enabled for deployment.
+
+### Reliability
+
+- Consider your requirements for zone redundancy in this reference implementation, as well as the zone redundancy capabilities of any other Azure Services in your solution. ASEv3 supports zone redundancy by spreading instances to all three zones in the target region. This can only be set at the time of ASE creation, and may not be available in all regions. See [Availability zone support for App Service Environment](https://docs.microsoft.com/en-us/azure/app-service/environment/overview-zone-redundancy) for more detail. This reference implementation does implement  zone redundancy, but this can be changed by cloning this repo and setting the `zoneRedundant` property to `false`.
+
+### Security
+
+- Employ the appropriate use of access restrictions so that the app service is only reachable from valid locations. For example, if the app service is hosting APIs, and is fronted by APIM, setup an access restriction so that the app service is only accessible from APIM.
+- Since this reference implementation deploys an ASE into a virtual network (referred to as an internal ASE), all applications deployed to the ASE are inherently network-isolated at the scope of the virtual network.
+- Store application secrets (database credentials, API tokens, private keys) in Azure Key Vault and configure your App Service app to access them securely with a Managed Identity. Determine when to use [Azure Key Vault vs Azure App Configuration](https://docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/appconfig-key-vault) with the guidance in mind.
+
+### Cost optimization
+
+- While there is no stamp fee for an ASEv3 instance, there is a charge levied when there are no App Service Plans configured within the ASEv3 instance. This charge is levied at the same rate as one instance of a Windows I1v2 instance for the region in which the ASEv3 instance is deployed.
+- When configured to be zone redundant, the charging model is adjusted to account for the underlying infrastructure deployed in this configuration, and you may therefore be liable for additional instances, as per [ASEv3 Pricing](https://docs.microsoft.com/en-us/azure/app-service/environment/overview#pricing)
+- Reserved instance pricing for ASEv3 App Service Plans (aka Isolated v2 App Service Plans) as per [How reservation discounts apply to Isolated v2 instances](https://docs.microsoft.com/en-us/azure/cost-management-billing/reservations/reservation-discount-app-service#how-reservation-discounts-apply-to-isolated-v2-instances)
+
+### Operational execellence
+
+- Use Application Insights or another Application Performance Management solution to monitor and learn how your application behaves in different environments.
+    - Two ways to enable [App Insights](https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview) currently exist.
+For different environments collect telemetry data into different Application Insights instances.
+    - If your application has multiple components separated into different services but you would like to examine their behavior together, then collect their telemetry data into same Application Insights instance but label them with different cloud role names.
+    - Export Application Insights data to an [Azure Log Analytics](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview) Workspace. A single Workspace for the organization is recommended.
+    - Include operational dashboards in application and feature design to ensure the solution can be supported in production.
+    - Implement health checks for your endpoints and use them for health probes, dependency checks and availability tests.
+- Use a different Application Insights instance for each environment, and potentially for each solution within an environment, to ensure no cross-pollination of telemetry data.
+- Consider using prefixes and suffixes with well-defined conventions to uniquely identify every deployed resource. These naming conventions avoid conflicts when deploying solutions next to each other and improve overall team agility and throughput.
+- Depending on the network configuration, App Services might not be reachable from the public internet and the use of public hosted agents will not work for deployments. Plan to use [self-hosted agents](https://azure.github.io/AppService/2021/01/04/deploying-to-network-secured-sites.html) in that scenario.
+
+
+## Deploy this scenario
+
+A deployment for the reference architecture that implements these recommendations and considerations is available on [GitHub](https://github.com/Azure/appservice-landing-zone-accelerator/tree/main/reference-implementations/LOB-ILB-ASEv3).
+
+
+
+## Next steps
+
+* [Security in Azure App Service](/azure/app-service/overview-security)
+* [Networking for App Service](/azure/app-service/networking-features)
+
+## Related resources
+
+
+* [High availability enterprise deployment using App Services Environment](docs/reference-architectures/enterprise-integration/ase-high-availability-deployment.yml)
+* [Enterprise deployment using App Services Environment](docs/reference-architectures/enterprise-integration/ase-standard-deployment.yml)
+* [Azure App Service landing zone accelerator](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/app-platform/app-services/landing-zone-accelerator)

docs/AAC/LOB-ILB-ASEv3.yml

@@ -0,0 +1,22 @@
+### YamlMime:Architecture
+metadata:
+  title: Line of Business Application using App Service Environmet v3
+  titleSuffix: Azure Architecture Center
+  description: Learn about deploying line of business applications with an internal App Service Environment v3 while considering networking boundaries, devops, management, and more. 
+  author: cykreng
+  ms.author: cykreng
+  ms.date: <publish or major update date - mm/dd/yyyy>
+  ms.topic: conceptual
+  ms.service: architecture-center
+  ms.subservice: reference-architecture
+azureCategories:
+  - compute
+  - security
+  - management-and-governance
+products:
+  - azure-app-service
+name: Deploy Line of Business Applications using App Service Environment v3
+summary: Learn about deploying line of business applications with an internal App Service Environment v3 while considering networking boundaries, devops, management, and more. 
+thumbnailUrl: /azure/architecture/browse/thumbs/<browse-png-filename>.png
+content: |
+  [!include[](LOB-ILB-ASEv3-content.md)]

docs/Design-Areas/networking.md

@@ -4,7 +4,7 @@
 
 ### Multi-Tenanted:
 - App Services in the multi-tenanted service share a single inbound and multiple outbound IP addresses with other App Services in the same deployment unit.  These can change for a [variety of reasons](https://docs.microsoft.com/en-us/azure/app-service/overview-inbound-outbound-ips#how-ip-addresses-work-in-app-service). If consistent outbound IP addresses are needed for multi-tenant App Service, a [NAT gateway](https://docs.microsoft.com/en-us/azure/app-service/networking/nat-gateway-integration#:~:text=%20Set%20up%20NAT%20gateway%20through%20the%20portal%3A,Basics%20information%20and%20pick%20the%20region...%20More%20) can be configured, or[ VNet  Integration](https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet) can be used.
-- If a dedicated IP address is required by which to address your App Service, you can make use of [App-assigned addresses](https://docs.microsoft.com/en-us/azure/app-service/networking/app-gateway-with-service-endpoints), or you could front your App Service with an [Application Gateway](https://docs.microsoft.com/en-us/azure/app-service/networking/app-gateway-with-service-endpoints) (which is assigned a static IP address).
+- If a dedicated IP address is required by which to address your App Service, you can make use of [App-assigned addresses](https://docs.microsoft.com/en-us/azure/app-service/networking-features#app-assigned-address), or you could front your App Service with an [Application Gateway](https://docs.microsoft.com/en-us/azure/app-service/networking/app-gateway-with-service-endpoints) (which is assigned a static IP address).
 - When there is a need to connect from an App Service to on-prem, private, or IP-restricted services, consider that:
     - When running in the multi-tenanted environment, the App Service call can originate from a wide range of IP addresses, and [VNet Integration](https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet) may be needed.
     - Services like [API Management (APIM)](https://docs.microsoft.com/en-us/azure/api-management/api-management-key-concepts) could be used to proxy calls between networking boundaries and can provide a static IP if needed.
@@ -31,7 +31,7 @@
 - Avoid [SNAT port exhaustion](https://docs.microsoft.com/en-us/azure/app-service/troubleshoot-intermittent-outbound-connection-errors) by utilizing connection pools.  The creation of new connections repetitively to the same host and port can cause slow response times, intermittent 5xx errors, timeouts, or external endpoint connection issues.
 - Review and follow the recommendations outlined in the [Network Security section](https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/app-service-security-baseline?toc=/azure/app-service/toc.json#network-security) of the Azure security baseline for App Service.
 ### Multi-Tenanted:
-•	If you need a dedicated outbound address when connecting to an multi-tenanted App Service, use a [NAT Gateway](https://docs.microsoft.com/en-us/azure/app-service/networking/nat-gateway-integration). 
-•	Since subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. To avoid any issues with subnet capacity, you should use a /26 with 64 addresses for Vnet integration.
+- If you need a dedicated outbound address when connecting to an multi-tenanted App Service, use a [NAT Gateway](https://docs.microsoft.com/en-us/azure/app-service/networking/nat-gateway-integration). 
+- Since subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. To avoid any issues with subnet capacity, you should use a /26 with 64 addresses for Vnet integration.
 ### App Service Enviornment:
-•	Your subnet should be sized with a /24 CIDR range, providing 256 addresses. 
+- Your subnet should be sized with a /24 CIDR range, providing 256 addresses.