Processed feedback and applied DocuMentor suggestions.

Author: EldertGrootenboerMS

articles/service-bus-messaging/enable-partitions-premium.md

@@ -8,17 +8,17 @@ ms.devlang: azurecli
 ---
 
 # Enable partitioning for an Azure Service Bus Premium namespace
-Service Bus partitions enable queues and topics, or messaging entities, to be partitioned across multiple message brokers. Partitioning means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker. Partitioned queues and topics can contain all advanced Service Bus features, such as support for transactions and sessions. For more information, see [Partitioned queues and topics](service-bus-partitioning.md). This article shows you different ways to enable partitioning for a Service Bus Premium namespace. All entities in this namespace will be partitioned.
+Service Bus partitions enable queues and topics, or messaging entities, to be partitioned across multiple message brokers. Partitioning means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker. Partitioned queues and topics can contain all advanced Service Bus features, such as support for transactions and sessions. For more information, see [Partitioned queues and topics](service-bus-partitioning.md). This article shows you different ways to enable partitioning for a Service Bus Premium namespace. All entities in this namespace are partitioned.
 
 > [!NOTE]
-> - Partitioning can be enabled during namespace creation in the Premium tier.
-> - Creating non-partitioned entities in a partitioned namespace isn't allowed.
-> - Changing the partitioning option on any existing namespace isn't possible. The number of partitions can only be set during namespace creation.
-> - The number of assigned messaging units are always a multiplier of the number of partitions in a namespace, and are equally distributed across the partitions. For example, in a namespace with 16MU and 4 partitions, each partition is assigned 4MU.
-> - Using multiple partitions with lower messaging units (MU) gives you a better performance over a single partition with higher MUs.
-> - When using the Service Bus [Geo-disaster recovery](service-bus-geo-dr.md) feature, ensure not to pair a partitioned namespace with a non-partitioned namespace.
-> - It's not possible to [migrate](service-bus-migrate-standard-premium.md) a Standard tier namespace to a Premium tier partitioned namespace.
-> - JMS is currently not supported on partitioned namespaces.
+> - JMS isn't currently supported on partitioned namespaces.
+> - You can enable partitioning during namespace creation in the Premium tier.
+> - You can't create non-partitioned entities in a partitioned namespace.
+> - You can't change the partitioning option on any existing namespace. You set the number of partitions during namespace creation.
+> - The number of assigned messaging units is always a multiplier of the number of partitions in a namespace, and is equally distributed across the partitions. For example, in a namespace with 16 MU and 4 partitions, each partition is assigned 4 MU.
+> - Using multiple partitions with lower messaging units (MU) gives you better performance over a single partition with higher MUs.
+> - When using the Service Bus [Geo-disaster recovery](service-bus-geo-dr.md) feature, don't pair a partitioned namespace with a non-partitioned namespace.
+> - You can't [migrate](service-bus-migrate-standard-premium.md) a Standard tier namespace to a Premium tier partitioned namespace.
 > - Batching messages with distinct SessionId or PartitionKey isn't supported on partitioned namespaces.
 > - This feature is currently available in all regions except West India and Austria East.
 
@@ -115,7 +115,7 @@ resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2024-01-01' = {
 ---
 
 ## Next steps
-Explore Azure Service Bus features using the samples in the language of your choice. 
+Explore Azure Service Bus features by using the samples in the language of your choice. 
 
 - [Azure Service Bus client library samples for .NET (latest)](/samples/azure/azure-sdk-for-net/azuremessagingservicebus-samples/) 
 - [Azure Service Bus client library samples for Java (latest)](/samples/azure/azure-sdk-for-java/servicebus-samples/)

articles/service-bus-messaging/network-security.md

@@ -11,43 +11,46 @@ ms.date: 06/08/2023
 This article describes how to use the following security features with Azure Service Bus: 
 
 - Service tags
-- IP Firewall rules
+- IP firewall rules
 - Network service endpoints
 - Private endpoints
 
 
 ## Service tags
 A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules. For more information about service tags, see [Service tags overview](../virtual-network/service-tags-overview.md).
 
-You can use service tags to define network access controls on [network security groups](../virtual-network/network-security-groups-overview.md#security-rules) or [Azure Firewall](../firewall/service-tags.md). Use service tags in place of specific IP addresses when you create security rules. By specifying the service tag name (for example, **ServiceBus**) in the appropriate *source* or *destination* field of a rule, you can allow or deny the traffic for the corresponding service.
+Use service tags to define network access controls on [network security groups](../virtual-network/network-security-groups-overview.md#security-rules) or [Azure Firewall](../firewall/service-tags.md). Use service tags in place of specific IP addresses when you create security rules. By specifying the service tag name (for example, **ServiceBus**) in the appropriate *source* or *destination* field of a rule, you can allow or deny the traffic for the corresponding service.
+
+> [!NOTE]
+> In the context of service tags, the term **outbound** refers to traffic that is outbound from an Azure Virtual Network, which represents inbound traffic to Service Bus. In other words, the service tag contains the IP addresses that are used for traffic flowing into Service Bus from your virtual network.
 
 | Service tag | Purpose | Can use inbound or outbound? | Can be regional? | Can use with Azure Firewall? |
 | --- | -------- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
 | **ServiceBus** | Azure Service Bus traffic. | Outbound | Yes | Yes |
 
 > [!NOTE]
->Previously, Service Bus service tags included only the IP addresses of namespaces on the **Premium** tier. This has now been updated to include the IP addresses of **all namespaces**, regardless of the tier.
+> Previously, Service Bus service tags included only the IP addresses of namespaces on the **Premium** tier. They now include the IP addresses of **all namespaces**, regardless of the tier.
 
 ## IP firewall 
-By default, Service Bus namespaces are accessible from internet as long as the request comes with valid authentication and authorization. With IP firewall, you can restrict it further to only a set of IPv4 addresses or IPv4 address ranges in [CIDR (Classless Inter-Domain Routing)](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation.
+By default, users can access Service Bus namespaces from the internet as long as the request comes with valid authentication and authorization. By using the IP firewall, you can restrict access to only a set of IPv4 addresses or IPv4 address ranges in [CIDR (Classless Inter-Domain Routing)](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation.
 
-This feature is helpful in scenarios in which Azure Service Bus should be only accessible from certain well-known sites. Firewall rules enable you to configure rules to accept traffic originating from specific IPv4 addresses. For example, if you use Service Bus with [Azure Express Route](../expressroute/expressroute-introduction.md), you can create a **firewall rule** to allow traffic from only your on-premises infrastructure IP addresses or addresses of a corporate NAT gateway. 
+This feature is helpful in scenarios where Azure Service Bus should be accessible only from certain well-known sites. Firewall rules enable you to configure rules to accept traffic originating from specific IPv4 addresses. For example, if you use Service Bus with [Azure Express Route](../expressroute/expressroute-introduction.md), you can create a **firewall rule** to allow traffic from only your on-premises infrastructure IP addresses or addresses of a corporate NAT gateway. 
 
-The IP firewall rules are applied at the Service Bus namespace level. Therefore, the rules apply to all connections from clients using any supported protocol. Any connection attempt from an IP address that doesn't match an allowed IP rule on the Service Bus namespace is rejected as unauthorized. The response doesn't mention the IP rule. IP filter rules are applied in order, and the first rule that matches the IP address determines the accept or reject action.
+The Service Bus namespace applies the IP firewall rules. Therefore, the rules apply to all connections from clients using any supported protocol. The Service Bus namespace rejects any connection attempt from an IP address that doesn't match an allowed IP rule as unauthorized. The response doesn't mention the IP rule. IP filter rules are applied in order, and the first rule that matches the IP address determines the accept or reject action.
 
-For more information, see [How to configure IP firewall for a Service Bus namespace](service-bus-ip-filtering.md)
+For more information, see [How to configure IP firewall for a Service Bus namespace](service-bus-ip-filtering.md).
 
 ## Network service endpoints
-The integration of Service Bus with [Virtual Network (VNet) service endpoints](service-bus-service-endpoints.md) enables secure access to messaging capabilities from workloads like virtual machines that are bound to virtual networks, with the network traffic path being secured on both ends.
+By integrating Service Bus with [Virtual Network (VNet) service endpoints](service-bus-service-endpoints.md), you can securely access messaging capabilities from workloads like virtual machines that are bound to virtual networks. The network traffic path is secured on both ends.
 
-Once configured to be bound to at least one virtual network subnet service endpoint, the respective Service Bus namespace will no longer accept traffic from anywhere but authorized virtual network(s). From the virtual network perspective, binding a Service Bus namespace to a service endpoint configures an isolated networking tunnel from the virtual network subnet to the messaging service.
+When you configure a Service Bus namespace to be bound to at least one virtual network subnet service endpoint, the Service Bus namespace no longer accepts traffic from anywhere but authorized virtual networks. From the virtual network perspective, binding a Service Bus namespace to a service endpoint configures an isolated networking tunnel from the virtual network subnet to the messaging service.
 
-The result is a private and isolated relationship between the workloads bound to the subnet and the respective Service Bus namespace, in spite of the observable network address of the messaging service endpoint being in a public IP range.
+The result is a private and isolated relationship between the workloads bound to the subnet and the respective Service Bus namespace, even though the observable network address of the messaging service endpoint is in a public IP range.
 
 > [!IMPORTANT]
 > Virtual Networks are supported only in [Premium tier](service-bus-premium-messaging.md) Service Bus namespaces.
 > 
-> When using VNet service endpoints with Service Bus, you should not enable these endpoints in applications that mix Standard and Premium tier Service Bus namespaces. Because Standard tier does not support VNets. The endpoint is restricted to Premium tier namespaces only.
+> When you use VNet service endpoints with Service Bus, don't enable these endpoints in applications that mix Standard and Premium tier Service Bus namespaces. Because Standard tier doesn't support VNets. The endpoint is restricted to Premium tier namespaces only.
 
 ### Advanced security scenarios enabled by VNet integration 
 
@@ -57,29 +60,29 @@ Any immediate IP route between the compartments, including those carrying HTTPS
 
 That means your security sensitive cloud solutions not only gain access to Azure industry-leading reliable and  scalable asynchronous messaging capabilities, but they can now use messaging to create communication paths between secure solution compartments that are inherently more secure than what is achievable with any peer-to-peer communication mode, including HTTPS and other TLS-secured socket protocols.
 
-### Bind Service Bus to Virtual Networks
+### Bind Service Bus to virtual networks
 
 *Virtual network rules* are the firewall security feature that controls whether your Azure Service Bus server accepts connections from a particular virtual network subnet.
 
-Binding a Service Bus namespace to a virtual network is a two-step process. You first need to create a **Virtual Network service endpoint** on a Virtual Network subnet and enable it for **Microsoft.ServiceBus** as explained in the [service endpoint overview](service-bus-service-endpoints.md). Once you have added the service endpoint, you bind the Service Bus namespace to it with a **virtual network rule**.
+Binding a Service Bus namespace to a virtual network is a two-step process. First, create a **Virtual Network service endpoint** on a Virtual Network subnet and enable it for **Microsoft.ServiceBus** as explained in the [service endpoint overview](service-bus-service-endpoints.md). After you add the service endpoint, bind the Service Bus namespace to it by using a **virtual network rule**.
 
-The virtual network rule is an association of the Service Bus namespace with a virtual network subnet. While the rule exists, all workloads bound to the subnet are granted access to the Service Bus namespace. Service Bus itself never establishes outbound connections, doesn't need to gain access, and is therefore never granted access to your subnet by enabling this rule.
+The virtual network rule associates the Service Bus namespace with a virtual network subnet. While the rule exists, all workloads bound to the subnet are granted access to the Service Bus namespace. Service Bus itself never establishes outbound connections, doesn't need to gain access, and is therefore never granted access to your subnet by enabling this rule.
 
-For more information, see [How to configure virtual network service endpoints for a Service Bus namespace](service-bus-service-endpoints.md)
+For more information, see [How to configure virtual network service endpoints for a Service Bus namespace](service-bus-service-endpoints.md).
 
 ## Private endpoints
 
-Azure Private Link Service enables you to access Azure services (for example, Azure Service Bus, Azure Storage, and Azure Cosmos DB) and Azure hosted customer/partner services over a **private endpoint** in your virtual network.
+By using Azure Private Link Service, you can access Azure services (for example, Azure Service Bus, Azure Storage, and Azure Cosmos DB) and Azure hosted customer or partner services over a **private endpoint** in your virtual network.
 
-A private endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. The private endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. All traffic to the service can be routed through the private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. You can connect to an instance of an Azure resource, giving you the highest level of granularity in access control.
+A private endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. The private endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. You can route all traffic to the service through the private endpoint, so you don't need any gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses. Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. You can connect to an instance of an Azure resource, giving you the highest level of granularity in access control.
 
 For more information, see [What is Azure Private Link?](../private-link/private-link-overview.md)
 
 > [!NOTE]
-> This feature is supported with the **premium** tier of Azure Service Bus. For more information about the premium tier, see the [Service Bus Premium and Standard messaging tiers](service-bus-premium-messaging.md) article.
+> This feature is supported by the **premium** tier of Azure Service Bus. For more information about the premium tier, see the [Service Bus Premium and Standard messaging tiers](service-bus-premium-messaging.md) article.
 
 
-For more information, see [How to configure private endpoints for a Service Bus namespace](private-link-service.md)
+For more information, see [How to configure private endpoints for a Service Bus namespace](private-link-service.md).
 
 
 ## Next steps