edit

Author: anaharris-ms

articles/reliability/reliability-event-hubs.md

@@ -61,16 +61,15 @@ Need Info. Any pricing considerations when using availability zones?
 
 [!INCLUDE [introduction to disaster recovery](includes/reliability-disaster-recovery-description-include.md)]
 
-The all-active Azure Event Hubs cluster model with availability zone support provides resiliency against  hardware and datacenter outages. However, in the case of a disaster where an entire region and all its zones are unavailable for a period of time, you can use Geo-disaster recovery to recover your workload and application configuration. 
+The all-active Azure Event Hubs cluster model with availability zone support provides resiliency against  hardware and datacenter outages. However, if a disaster where an entire region and all zones are unavailable , you can use Geo-disaster recovery to recover your workload and application configuration. 
 
 Geo-Disaster recovery ensures that the entire configuration of a namespace (Event Hubs, Consumer Groups, and settings) is continuously replicated from a primary namespace to a secondary namespace when paired. 
+The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. The concepts and workflow described in this article apply to disaster scenarios, and not to temporary outages.  For a detailed discussion of disaster recovery in Microsoft Azure, see [this article](/azure/architecture/resiliency/disaster-recovery-azure-applications).
 
-The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. The concepts and workflow described in this article apply to disaster scenarios, and not to transient, or temporary outages.For a detailed discussion of disaster recovery in Microsoft Azure, see [this article](/azure/architecture/resiliency/disaster-recovery-azure-applications).
-
-With Geo-Disaster recovery, you can initiate a once-only failover move from the primary to the secondary at any time. The failover move re-points the chosen alias name for the namespace to the secondary namespace. After the move, the pairing is then removed. The failover is nearly instantaneous once initiated. 
+With Geo-Disaster recovery, you can initiate a once-only failover move from the primary to the secondary at any time. The failover move points the chosen alias name for the namespace to the secondary namespace. After the move, the pairing is then removed. The failover is nearly instantaneous once initiated. 
 
 > [!IMPORTANT]
-> - Geo-Disaster recovery **does not replicate the event data**. In learn how to recover event data from the primary Event Hub after the downed region is restored, see [replication guidance](../event-hubs/event-hubs-federation-overview.md) 
+> - Geo-Disaster recovery **doesn't replicate the event data**. In learn how to recover event data from the primary Event Hub after the downed region is restored, see [replication guidance](../event-hubs/event-hubs-federation-overview.md) 
 > - Microsoft Entra role-based access control (RBAC) assignments to entities in the primary namespace aren't replicated to the secondary namespace. You'll need to create role assignments manually in the secondary namespace to secure access to them. 
 
 
@@ -94,21 +93,22 @@ This section provides more considerations when using Geo-disaster recovery with
 
 
 ### New pairings
-If you try to create a pairing between a primary namespace with a private endpoint and a secondary namespace without a private endpoint, the pairing will fail. The pairing will succeed only if both primary and secondary namespaces have private endpoints. We recommend that you use same configurations on the primary and secondary namespaces and on virtual networks in which private endpoints are created.  
+If you try to create a pairing between a primary namespace with a private endpoint and a secondary namespace without a private endpoint, the pairing fails. The pairing succeeds only if both primary and secondary namespaces have private endpoints. We recommend that you use same configurations on the primary and secondary namespaces and on virtual networks in which private endpoints are created.  
 
 > [!NOTE]
-> When you try to pair the primary namespace with private endpoint and a secondary namespace, the validation process only checks whether a private endpoint exists on the secondary namespace. It doesn't check whether the endpoint works or will work after failover. It's your responsibility to ensure that the secondary namespace with private endpoint will work as expected after failover.
+> When you try to pair the primary namespace with private endpoint and a secondary namespace, the validation process only checks whether a private endpoint exists on the secondary namespace. It doesn't check whether the endpoint works after failover. It's your responsibility to ensure that the secondary namespace with private endpoint  work as expected after failover.
 >
 > To test that the private endpoint configurations are same on primary and secondary namespaces, send a read request (for example: [Get Event Hub](/rest/api/eventhub/get-event-hub)) to the secondary namespace from outside the virtual network, and verify that you receive an error message from the service.
 
 ### Existing pairings
-If pairing between primary and secondary namespace already exists, private endpoint creation on the primary namespace will fail. To resolve, create a private endpoint on the secondary namespace first and then create one for the primary namespace.
+If pairing between primary and secondary namespace already exists, private endpoint creation on the primary namespace fails. To resolve, create a private endpoint on the secondary namespace first and then create one for the primary namespace.
 
 > [!NOTE]
 > While we allow read-only access to the secondary namespace, updates to the private endpoint configurations are permitted. 
 
 ### Recommended configuration
-When creating a disaster recovery configuration for your application and Event Hubs namespaces, you must create private endpoints for both primary and secondary Event Hubs namespaces against virtual networks hosting both primary and secondary instances of your application. 
+
+You must create private endpoints for both primary and secondary Event Hubs namespaces against the virtual networks that host both of those instances of your application. 
 
 Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and secondary namespaces: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. You need to do the following steps: 
 
@@ -119,16 +119,16 @@ Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and se
 
 Advantage of this approach is that failover can happen at the application layer independent of Event Hubs namespace. Consider the following scenarios: 
 
-**Application-only failover:** Here, the application won't exist in VNET-1 but will move to VNET-2. As both private endpoints are configured on both VNET-1 and VNET-2 for both primary and secondary namespaces, the application will just work. 
+**Application-only failover:** The application doesn't exist in VNET-1 but moves to VNET-2. The application works because both private endpoints are configured on both VNET-1 and VNET-2 for both primary and secondary namespaces.
 
-**Event Hubs namespace-only failover**: Here again, since both private endpoints are configured on both virtual networks for both primary and secondary namespaces, the application will just work. 
+**Event Hubs namespace-only failover**: The application works because both private endpoints are configured on both virtual networks for both primary and secondary namespaces.
 
 > [!NOTE]
 > For guidance on geo-disaster recovery of a virtual network, see [Virtual Network - Business Continuity](../virtual-network/virtual-network-disaster-recovery-guidance.md).
 
 
 ## Role-based access control
-Microsoft Entra role-based access control (RBAC) assignments to entities in the primary namespace aren't replicated to the secondary namespace. Create role assignments manually in the secondary namespace to secure access to them.
+Microsoft Entra role-based access control (RBAC) assignments to entities in the primary namespace aren't replicated to the secondary namespace. To secure access to role assignments, create them manually in the secondary namespace.
 
 ## Supported namespace pairs
 The following combinations of primary and secondary namespaces are supported:  
@@ -174,7 +174,7 @@ You first create or use an existing primary namespace, and a new secondary names
     1. Manually fail over to the secondary namespace. Select **Failover** on the toolbar. 
 
         > [!WARNING]
-        > Failing over will activate the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. Create another namespace to have a new geo-disaster recovery pair. 
+        > Failing over activates the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. Create another namespace to have a new geo-disaster recovery pair. 
 
 Finally, you should add some monitoring to detect if a failover is necessary. In most cases, the service is one part of a large ecosystem, thus automatic failovers are rarely possible, as often failovers must be performed in sync with the remaining subsystem or infrastructure.
 
@@ -207,7 +207,7 @@ This section shows how to manually fail over using Azure portal, CLI, PowerShell
 1. Manually fail over to the secondary namespace. Select **Failover** on the toolbar. 
 
     > [!WARNING]
-    > Failing over will activate the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. Create another namespace to have a new geo-disaster recovery pair.
+    > Failing over activates the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. Create another namespace to have a new geo-disaster recovery pair.
 
 # [Azure CLI](#tab/cli)
 Use the [az eventhubs georecovery-alias fail-over](/cli/azure/eventhubs/georecovery-alias#az-eventhubs-georecovery-alias-fail-over) command.
@@ -230,23 +230,23 @@ If you made a mistake; for example, you paired the wrong regions during the init
 
 Note the following considerations to keep in mind:
 
-1. By design, Event Hubs geo-disaster recovery does not replicate data, and therefore you cannot reuse the old offset value of your primary event hub on your secondary event hub. We recommend restarting your event receiver with one of the following methods:
+1. By design, Event Hubs geo-disaster recovery doesn't replicate data, and therefore you can't reuse the old offset value of your primary event hub on your secondary event hub. We recommend restarting your event receiver with one of the following methods:
 
    - *EventPosition.FromStart()* - If you wish read all data on your secondary event hub.
    - *EventPosition.FromEnd()* - If you wish to read all new data from the time of connection to your secondary event hub.
    - *EventPosition.FromEnqueuedTime(dateTime)* - If you wish to read all data received in your secondary event hub starting from a given date and time.
 
 2. In your failover planning, you should also consider the time factor. For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the failover. 
 
-3. The fact that no data is replicated means that current active sessions aren't replicated. Additionally, duplicate detection and scheduled messages may not work. New sessions, scheduled messages, and new duplicates will work. 
+3. The fact that no data is replicated means that current active sessions aren't replicated. Additionally, duplicate detection and scheduled messages may not work. New sessions, scheduled messages, and new duplicates work. 
 
 4. Failing over a complex distributed infrastructure should be [rehearsed](/azure/architecture/reliability/disaster-recovery#disaster-recovery-plan) at least once. 
 
 5. Synchronizing entities can take some time, approximately 50-100 entities per minute.
 
 6. Some aspects of the management plane for the secondary namespace become read-only while geo-recovery pairing is active.
 
-7. The data plane of the secondary namespace will be read-only while geo-recovery pairing is active. The data plane of the secondary namespace will accept GET requests to enable validation of client connectivity and access controls.
+7. The data plane of the secondary namespace is read-only while geo-recovery pairing is active. The data plane of the secondary namespace accepts GET requests to enable validation of client connectivity and access controls.
 
 
 ## Next steps