Merge pull request #188638 from sebansal/patch-119

updating limits

Author: ShannonLeavitt

articles/key-vault/general/rest-error-codes.md

@@ -26,7 +26,7 @@ A request is authenticated if:
 - The key vault knows the identity of the caller; and
 - The caller is allowed to try to access Key Vault resources. 
 
-There are several different reason why a request may return 401.
+There are several reasons why a request may return 401.
 
 ### No authentication token attached to the request. 
 
@@ -126,15 +126,15 @@ HTTP 403 means that the request was authenticated (it knows the requesting ident
 - There is no access policy for the identity.
 - The IP address of the requesting resource is not approved in the key vault's firewall settings.
 
-HTTP 403 often occurs when the customer's application is not using the client ID that the customer thinks it is. That usually means that the access policies is not correctly set up for the actual calling identity.
+HTTP 403 often occurs when the customer's application is not using the client ID that the customer thinks it is. That usually means that the access policies are not correctly set up for the actual calling identity.
 
 If you receive a 403 error immediately after adding an identity to the access policy, you can handle it by adding periodic retry.
 
 ### Troubleshooting 403
 
 First, turn on logging. For instructions on how to do so, see [Azure Key Vault logging](logging.md).
 
-Once logging is turned on, you can determine if the 403 is due to access policy or firewall policy.
+After logging is turned on, you can determine if the 403 is due to access policy or firewall policy.
 
 #### Error due to firewall policy
 
@@ -144,15 +144,15 @@ There is a limited list of "Azure Trusted Services". Azure Web Sites are **not**
 
 You must add the IP address of the Azure Web Site to the Key Vault in order for it to work.
 
-If due to access policy: find the object ID for the request and ensure that the object ID matches the object to which the user is trying to assign the access policy. There will often be multiple objects in the AAD which have the same name, so choosing the correct one is very important. By deleting and re-adding the access policy, it is possible to see if multiple objects exist with the same name.
+If due to access policy: find the object ID for the request and ensure that the object ID matches the object to which the user is trying to assign the access policy. There will often be multiple objects in Azure AD which have the same name, so choosing the correct one is very important. By deleting and re-adding the access policy, it is possible to see if multiple objects exist with the same name.
 
-In addition, most access policies do not require the use of the "Authorized application" as shown in the portal. Authorized application are used for "on-behalf-of" authentication scenarios, which are rare. 
+In addition, most access policies do not require the use of the "Authorized application" as shown in the portal. Authorized applications are used for "on-behalf-of" authentication scenarios, which are rare. 
 
 
 ## HTTP 429: Too Many Requests
 
-Throttling occurs when the number of requests exceeds the stated maximum for the timeframe. If throttling occurs, the Key Vault's response will be HTTP 429. There are stated maximums for types of requests made. For instance: the creation of an HSM 2048-bit key is 5 requests per 10 seconds, but all other HSM transactions have a 1000 request/10 seconds limit. Therefore it is important to understand which types of calls are being made when determining the cause of throttling.
-In general, requests to the Key Vault are limited to 2000 requests/10 seconds. Exceptions are Key Operations, as documented in [Key Vault service limits](service-limits.md)
+Throttling occurs when the number of requests exceeds the stated maximum for the timeframe. If throttling occurs, the Key Vault's response will be HTTP 429. There are stated maximums for types of requests made. For instance: the creation of an HSM 2048-bit key is 10 requests per 10 seconds, but all other HSM transactions have a limit of 2,000 requests/10 seconds. Therefore it is important to understand which types of calls are being made when determining the cause of throttling.
+In general, requests to the Key Vault are limited to 4,000 requests/10 seconds. Exceptions are Key Operations, as documented in [Key Vault service limits](service-limits.md)
 
 ### Troubleshooting 429
 Throttling is worked around using these techniques:
@@ -163,4 +163,4 @@ Throttling is worked around using these techniques:
 
 - If the number of requests cannot be reduced by caching and timed backoff does not work, then consider splitting the keys up into multiple Key Vaults. The service limit for a single subscription is 5x the individual Key Vault limit. If using more than 5 Key Vaults, consideration should be given to using multiple subscriptions. 
 
-Detailed guidance including request to increase limits, can be find here: [Key Vault throttling guidance](overview-throttling.md)
+Detailed guidance including request to increase limits, can be found here: [Key Vault throttling guidance](overview-throttling.md)