Apply suggestions from code review

Co-authored-by: Jon Torre <[email protected]>
Co-authored-by: Puneet Singh Sarna <[email protected]>

Author: 3 people

content/nginxaas-azure/quickstart/disaster-recovery.md

@@ -30,7 +30,7 @@ This guide describes how to configure disaster recovery (DR) for F5 NGINX as a S
 
 - Each region has its own VNet, subnet, and NGINXaaS for Azure deployment.
 - VNet peering enables cross-region connectivity.
-- Upstreams (e.g., VMs) are accessible from either NGINX deployment.
+- Upstreams (for example, VMs) are accessible from either NGINX deployment.
 
 ---
 
@@ -47,8 +47,9 @@ This guide describes how to configure disaster recovery (DR) for F5 NGINX as a S
 
 ---
 
+## Configure disaster recovery 
 
-## Step 1: Deploy Prerequisite Infrastructure
+### Step 1: Deploy prerequisite infrastructure
 
 Each region requires its own resource group, VNet, subnet, public IP, network security group, and user-assigned identity. Example allocation in the prerequisites module:
 
@@ -72,7 +73,7 @@ resource "azurerm_subnet" "deployment_secondary_subnet" {
 ```
 ---
 
-## Step 2: Deploy NGINXaaS for Azure Deployment in Each Region
+### Step 2: Deploy NGINXaaS for Azure in each region
 
 ```hcl
 resource "azurerm_nginx_deployment" "deployment_primary_nginxaas" {
@@ -98,7 +99,7 @@ resource "azurerm_nginx_deployment" "deployment_secondary_nginxaas" {
 
 ---
 
-## Step 3: Peer the VNets
+### Step 3: Peer the VNets
 
 ```hcl
 resource "azurerm_virtual_network_peering" "vnet_primary_to_vnet_secondary" {
@@ -118,9 +119,9 @@ resource "azurerm_virtual_network_peering" "vnet_secondary_to_vnet_primary" {
 
 ---
 
-## Step 4: Configure Upstreams
+### Step 4: Configure upstreams
 
-Deploy upstream VMs in a subnet separate from the NGINXaaS deployment subnet in the primary region. Example:
+Deploy upstream VMs in a subnet separate from the NGINXaaS deployment subnet in the **primary region**. Example:
 
 ```hcl
 resource "azurerm_subnet" "upstreams" {
@@ -150,10 +151,10 @@ upstream backend {
 
 ---
 
-## Step 6: DNS and Failover
+### Step 6: DNS and failover
 
 - Use Azure Traffic Manager or an external DNS solution to direct traffic to the healthy NGINX deployment.
-- In case of a regional outage, update DNS to point to the public IP of the surviving region's NGINX.
+- In case of a regional outage, update DNS record to point to the public IP of the NGINXaas deployment in the secondary region.
 
 ---
 
@@ -180,28 +181,47 @@ az network vnet peering create \
 ## Failover Process
 
 1. **Monitor**: Continuously monitor NGINXaaS deployment health in both regions.
-2. **Failover**: If a region fails, update DNS or Traffic Manager to route traffic to the surviving region's NGINXaaS deployment.
-3. **Recovery**: Restore the failed region and verify peering and upstream connectivity before re-enabling traffic.
+1. **Failover**: If a region fails, update DNS or Traffic Manager to route traffic to the surviving region's NGINXaaS deployment.
+1. **Recovery**: Restore the failed region and verify peering and upstream connectivity before re-enabling traffic.
 
 ---
 
 ## Diagram
 
-```plaintext
-+-----------------------+      Peering      +-----------------------+
-|  Region 1             |<----------------->|  Region 2             |
-|  NGINXaaS Deployment 1|                   |  NGINXaaS Deployment 2|
-|  Upstreams (VMs)      |                   |                       |
-+-----------------------+                   +-----------------------+
-         |                                         |
-         +-------------------+   +-----------------+
-                             |   |
-                         Users/Clients (via DNS/Traffic Manager)
+```mermaid
+flowchart LR
+
+    subgraph Region1[Region 1]
+        direction TB
+        NGINX1[NGINXaaS Deployment 1]
+        VM1["Upstreams (VMs)"]
+    end
+
+    subgraph Region2[Region 2]
+        direction TB
+        NGINX2[NGINXaaS Deployment 2]
+    end
+
+    Users["웃 Users/Clients<br/>&#40;using DNS/traffic manager&#41;"]
+
+    Region2 <-->|Peering| Region1
+    NGINX1 --> Users
+    NGINX2 --> Users
+
+    %% Styling
+    style Region1 fill:#9bb1de,stroke:#4a90e2,stroke-width:2px
+    style Region2 fill:#9bb1de,stroke:#4a90e2,stroke-width:2px
+    style NGINX1 fill:#d9fade,stroke:#2e7d32,stroke-width:2px,color:#000
+    style NGINX2 fill:#d9fade,stroke:#2e7d32,stroke-width:2px,color:#000
+    style VM1 fill:#e8f3fe,stroke:#3075ff,stroke-width:2px,color:#000
+    style Users fill:#faefd9,stroke:orange,color:orange,stroke-width:2px
+    
+    accDescr: Diagram showing Region 1 on the left and Region 2 on the right. Region 1 contains "NGINXaaS Deployment 1" and "Upstreams (VMs)". Region 2 contains "NGINXaaS Deployment 2". A directional arrow labeled "Peering" points from Region 1 to Region 2. Both NGINXaaS deployments have arrows pointing to a box labeled "Users/Clients (using DNS/traffic manager)", indicating user traffic flows from both regions.
 ```
 
 
 ---
 
-**Summary:**
+## Summary
 
-By deploying NGINX in separate regions with unique subnets and peered VNets, and configuring upstreams and DNS for failover, this topology ensures high availability and DR for your upstreams. Use subnet peering if address spaces overlap. Always monitor and test your failover paths.
+By deploying NGINXaaS in separate regions with unique subnets and peered VNets, and configuring upstreams and DNS for failover, this topology ensures high availability and DR for your applications. Use subnet peering if address spaces overlap. Lastly, always monitor and test your failover paths.