Renaming files

SnehaGunda · SnehaGunda · commit cdf70f7202ac · 2020-04-27T10:32:15.000-07:00
diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
@@ -2352,6 +2352,16 @@
       "redirect_url": "/azure/cosmos-db/conflict-resolution-policies",
       "redirect_document_id": true
     },
+    {
+      "source_path": "articles/cosmos-db/provision-throughput-autopilot.md",
+      "redirect_url": "/azure/cosmos-db/provision-throughput-autoscale",
+      "redirect_document_id": true
+    },
+    {
+      "source_path": "articles/cosmos-db/autopilot-faq.md",
+      "redirect_url": "/azure/cosmos-db/autoscale-faq",
+      "redirect_document_id": true
+    },
     {
       "source_path": "articles/cosmos-db/how-to-custom-synchronization.md",
       "redirect_url": "/azure/cosmos-db/how-to-multi-master",
diff --git a/articles/cosmos-db/TOC.yml b/articles/cosmos-db/TOC.yml
@@ -137,9 +137,9 @@
         displayName: request units, RUs, RU, limits, database throughput, shared throughput, container throughput
         href: set-throughput.md
       - name: Provision throughput - autoscale mode
-        href: provision-throughput-autopilot.md
+        href: provision-throughput-autoscale.md
       - name: Autoscale FAQ
-        href: autopilot-faq.md
+        href: autoscale-faq.md
     - name: SQL query
       items:
       - name: Getting started
diff --git a/articles/cosmos-db/autoscale-faq.md b/articles/cosmos-db/autoscale-faq.md
@@ -5,7 +5,7 @@ author: deborahc
 ms.author: dech
 ms.service: cosmos-db
 ms.topic: conceptual
-ms.date: 04/24/2020
+ms.date: 04/28/2020
 ---
 
 # Frequently asked questions about autoscale provisioned throughput in Azure Cosmos DB
@@ -44,7 +44,7 @@ For shared throughput databases with autoscale mode enabled, the number of allow
 
 ### What is the storage limit associated with each max RU/s option?  
 The storage limit in GB for each max RU/s is: Max RU/s of database or container / 100. For example, if the max RU/s is 20,000 RU/s, the resource can support 200 GB of storage. 
-See the [autoscale limits](provision-throughput-autopilot.md#autoscale-limits) article for the available max RU/s and storage options. 
+See the [autoscale limits](provision-throughput-autoscale.md#autoscale-limits) article for the available max RU/s and storage options. 
 
 ### What happens if I exceed the storage limit associated with my max throughput?
 If the storage limit associated with the max throughput of the database or container is exceeded, Azure Cosmos DB will automatically increase the max throughput to the next highest tier that can support that level of storage. For example, suppose a database or container is provisioned with the 4000 RU/s max throughput option, which has a storage limit of 50 GB. If the storage of the resource increases to 100 GB, the max RU/s of the database or container will be automatically increased to 20,000 RU/s, which can support up to 200 GB. 
@@ -53,7 +53,7 @@ If the storage limit associated with the max throughput of the database or conta
 In autoscale mode, you can instantaneously scale up or scale down the RU/s within the minimum and maximum RU/s range, based on incoming traffic. Billing is done at a 1-hour granularity, where you are charged for the highest RU/s in a particular hour.
 
 ### Can I specify a custom max throughput (RU/s) value for autoscale mode?
-Currently, you can select between [four options](provision-throughput-autoscale.md#autopilot-limits) for max throughput (RU/s).
+Currently, you can select between [four options](provision-throughput-autoscale.md#autoscale-limits) for max throughput (RU/s).
 
 ### Can I increase the max RU/s (move to a higher tier) on the database or container? 
 Yes. From the **Scale & Settings** option for your container, or **Scale** option for your database, you can select a higher max RU/s for autoscale mode. This is an asynchronous scale-up operation that may take sometime to complete (typically 4-6 hours, depending on the RU/s selected) as the service provisions more resources to support the higher scale. 
@@ -70,9 +70,9 @@ The Max RU/s of the database or container is divided evenly across all physical
 If the overall consumed RU/s exceeds the max RU/s of the container or database, requests that exceed the max RU/s will be throttled and return a 429 status code. Requests that result in over 100% normalized utilization will also be throttled. Normalized utilization is defined as the max of the RU/s utilization across all physical partitions. For example, suppose your max throughput is 20,000 RU/s and you have two physical partitions, P_1 and P_2, each capable of scaling to 10,000 RU/s. In a given second, if P_1 has used 6000 RUs, and P_2 8000 RUs, the normalized utilization is MAX(6000 RU / 10,000 RU, 8000 RU / 10,000 RU) = 0.8.
 
 > [!NOTE]
-> The Azure Cosmos DB client SDKs and data import tools (Azure Data Factory, bulk executor library) automatically retry on 429s, so occasional 429s are fine. A sustained high number of 429s may indicate you need to increase the max RU/s or review your partitioning strategy for a [hot partition](#is-it-still-possible-to-see-429s-throttlingrate-limiting-when-autopilot-is-enabled).
+> The Azure Cosmos DB client SDKs and data import tools (Azure Data Factory, bulk executor library) automatically retry on 429s, so occasional 429s are fine. A sustained high number of 429s may indicate you need to increase the max RU/s or review your partitioning strategy for a [hot partition](#autoscale-rate-limiting).
 
-### Is it still possible to see 429s (throttling/rate limiting) when autoscale is enabled? 
+### <a id="autoscale-rate-limiting"></a> Is it still possible to see 429s (throttling/rate limiting) when autoscale is enabled? 
 Yes. It is possible to see 429s in two scenarios. First, when the overall consumed RU/s exceeds the max RU/s of the container or database, the service will throttle requests accordingly. 
 
 Second, if there is a hot partition, i.e. a logical partition key value that has a disproportionately higher amount of requests compared to other partition key values, it is possible for the underlying physical partition to exceed its RU/s budget. As a best practice, to avoid hot partitions, [choose a good partition key](partitioning-overview.md#choose-partitionkey) that results in an even distribution of both storage and throughput. 
@@ -81,6 +81,6 @@ For example, if you select the 20,000 RU/s max throughput option and have 200 GB
 
 ## Next steps
 
-* Learn how to [enable autoscale on an Azure Cosmos container or database](provision-throughput-autopilot.md#create-a-database-or-a-container-with-autopilot-mode).
-* Learn about the [benefits of provisioned throughput in autoscale mode](provision-throughput-autopilot.md#benefits-of-autopilot-mode).
+* Learn how to [enable autoscale on an Azure Cosmos container or database](provision-throughput-autoscale.md#create-db-container-autoscale).
+* Learn about the [benefits of provisioned throughput in autoscale mode](provision-throughput-autoscale.md#autoscale-benefits).
 * Learn more about [logical and physical partitions](partition-data.md).
diff --git a/articles/cosmos-db/concepts-limits.md b/articles/cosmos-db/concepts-limits.md
@@ -135,7 +135,7 @@ Cosmos DB supports execution of triggers during writes. The service supports a m
 
 ## Autoscale mode limits
 
-See the [Autoscale](provision-throughput-autopilot.md#autoscale-limits) article for the throughput and storage limits in autoscale mode.
+See the [Autoscale](provision-throughput-autoscale.md#autoscale-limits) article for the throughput and storage limits in autoscale mode.
 
 ## SQL query limits
 
diff --git a/articles/cosmos-db/manage-scale-cassandra.md b/articles/cosmos-db/manage-scale-cassandra.md
@@ -45,7 +45,7 @@ The Azure Cosmos DB's API for Cassandra provides the capability to adjust throug
 
 The advantage of this method is that you can automate the scaling up or down of resources based on a timer to account for peak activity, or periods of low activity. Take a look at our sample [here](https://github.com/Azure-Samples/azure-cosmos-throughput-scheduler) for how to accomplish this using Azure Functions and Powershell.
 
-A disadvantage with this approach may be that you cannot respond to unpredictable changing scale needs in real-time. Instead, you may need to leverage the application context in your system, at the client/SDK level, or using [Autoscale](provision-throughput-autopilot.md).
+A disadvantage with this approach may be that you cannot respond to unpredictable changing scale needs in real-time. Instead, you may need to leverage the application context in your system, at the client/SDK level, or using [Autoscale](provision-throughput-autoscale.md).
 
 ## <a id="use-cql-queries"></a>Use CQL queries with a specific SDK
 
@@ -55,7 +55,7 @@ The advantage of this approach is that it allows you to respond to scale needs d
 
 ## <a id="use-autoscale"></a>Use Autoscale
 
-In addition to manual or programmatic way of provisioning throughput, you can also configure Azure cosmos containers in Autoscale mode. Autoscale mode will automatically and instantly scale to your consumption needs within specified RU ranges without compromising SLAs. To learn more, see the [Create Azure Cosmos containers and databases in autoscale mode](provision-throughput-autopilot.md) article.
+In addition to manual or programmatic way of provisioning throughput, you can also configure Azure cosmos containers in Autoscale mode. Autoscale mode will automatically and instantly scale to your consumption needs within specified RU ranges without compromising SLAs. To learn more, see the [Create Azure Cosmos containers and databases in autoscale mode](provision-throughput-autoscale.md) article.
 
 The advantage of this approach is that it is the easiest way to manage the scaling needs in your system. It guarantees not to apply rate-limiting **within the configured RU ranges**. The disadvantage is that, if the scaling needs in your system are predictable, Autoscale may be a less cost-effective way of handling your scaling needs than using the bespoke control plane or SDK level approaches mentioned above.
 
diff --git a/articles/cosmos-db/media/provision-throughput-autoscale/create-container-autoscale-mode.png b/articles/cosmos-db/media/provision-throughput-autoscale/create-container-autoscale-mode.png
diff --git a/articles/cosmos-db/media/provision-throughput-autoscale/enable-autoscale-azure-portal.png b/articles/cosmos-db/media/provision-throughput-autoscale/enable-autoscale-azure-portal.png
diff --git a/articles/cosmos-db/mongodb-pre-migration.md b/articles/cosmos-db/mongodb-pre-migration.md
@@ -25,7 +25,7 @@ If you have already completed the above pre-requisites for migration, you can [M
 
 The following are specific characteristics about Azure Cosmos DB's API for MongoDB:
 
-- **Capacity model**: Database capacity on Azure Cosmos DB is based on a throughput-based model. This model is based on [Request Units per second](request-units.md), which is a unit that represents the number of database operations that can be executed against a collection on a per-second basis. This capacity can be allocated at [a database or collection level](set-throughput.md), and it can be provisioned on an allocation model, or using the [Autoscale model](provision-throughput-autopilot.md).
+- **Capacity model**: Database capacity on Azure Cosmos DB is based on a throughput-based model. This model is based on [Request Units per second](request-units.md), which is a unit that represents the number of database operations that can be executed against a collection on a per-second basis. This capacity can be allocated at [a database or collection level](set-throughput.md), and it can be provisioned on an allocation model, or using the [Autoscale model](provision-throughput-autoscale.md).
 
 - **Request Units**: Every database operation has an associated Request Units (RUs) cost in Azure Cosmos DB. When executed, this is subtracted from the available request units level on a given second. If a request requires more RUs than the currently allocated RU/s there are two options to solve the issue - increase the amount of RUs, or wait until the next second starts and then retry the operation.
 
diff --git a/articles/cosmos-db/provision-throughput-autoscale.md b/articles/cosmos-db/provision-throughput-autoscale.md
@@ -1,27 +1,27 @@
 ---
 title: Create Azure Cosmos containers and databases in autoscale mode.
-description: Learn about the benefits, use cases, and how to provision Azure Cosmos databases and containers in autopilot mode.
+description: Learn about the benefits, use cases, and how to provision Azure Cosmos databases and containers in autoscale mode.
 author: kirillg
 ms.author: kirillg
 ms.service: cosmos-db
 ms.topic: conceptual
-ms.date: 11/04/2019
+ms.date: 04/28/2020
 ---
 
 # Create Azure Cosmos containers and databases in autoscale mode
 
 Azure Cosmos DB allows you to provision throughput on your containers in either manual or autoscale mode. This article describes the benefits and use cases of autoscale mode.
 
 > [!NOTE]
-> You can [enable autoscale for new databases and containers](#create-a-database-or-a-container-with-autopilot-mode) only. It is not available for existing containers and databases.
+> You can [enable autoscale for new databases and containers](#create-db-container-autoscale) only. It is not available for existing containers and databases.
 
 In addition to manual provisioning of throughput, you can now configure Azure Cosmos containers in autoscale mode. Containers and databases configured in autoscale mode will **automatically and instantly scale the provisioned throughput based on your application needs without impacting the availability, latency, throughput, or performance of the workload globally.**
 
 When configuring containers and databases in autoscale mode, you need to specify the maximum throughput `Tmax` not to be exceeded. Containers can then scale their throughput so that `0.1*Tmax < T < Tmax`. In other words, containers and databases scale instantly based on the workload needs, from as low as 10% of the maximum throughput value that you have configured up to the configured maximum throughput value. After configuring autoscale, you can change the maximum throughput (`Tmax`) setting on a database or container at any point in time. With the autoscale option, the 400 RU/s minimum throughput per container or database is no longer applicable.
 
 For the specified maximum throughput on the container or the database, the system allows operating within the calculated storage limit. If the storage limit is exceeded, then the maximum throughput is automatically adjusted to a higher value. When using database level throughput with autoscale mode, the number of containers allowed within a database is calculated as: `0.001*TMax`. For example, if you provision 20,000 autoscale RU/s, then the database can have 20 containers.
 
-## Benefits of autoscale mode
+## <a id="autoscale-benefits"></a> Benefits of autoscale mode
 
 Azure Cosmos containers that are configured in autoscale mode have the following benefits:
 
@@ -33,7 +33,7 @@ Azure Cosmos containers that are configured in autoscale mode have the following
 
 * **Highly available:** Containers in autoscale mode use the same globally distributed, fault-tolerant, highly available backend to ensure data durability and high availability.
 
-## Use cases of autoscale mode
+## <a id="autoscale-usecases"></a> Use cases of autoscale mode
 
 The use cases for Azure Cosmos containers configured in autoscale mode include:
 
@@ -61,7 +61,7 @@ Solutions to the previous problems not only require an enormous amount of time i
 | **Pricing** | Manually provisioned RU/s per hour. | For single write region accounts, you pay for the throughput used on an hourly basis, by using the autoscale RU/s per hour rate. <br/><br/>For accounts with multiple write regions, there is no extra charge for autoscale. You pay for the throughput used on hourly basis using the same multi-master RU/s per hour rate. |
 | **Best suited for workload types** |  Predictable and stable workloads|   Unpredictable and variable workloads  |
 
-## Create a database or a container with autoscale mode
+## <a id="create-db-container-autoscale"></a> Create a database or a container with autoscale mode
 
 You can configure autoscale for new databases or containers when creating them through the Azure portal. Use the following steps to create a new database or container, enable autoscale, and specify the maximum throughput (RU/s).
 
@@ -71,7 +71,7 @@ You can configure autoscale for new databases or containers when creating them t
 
 1. Select **New Container.** Enter a name for your database, container, and a partition key. Under **Throughput**, select the **Autoscale** option, and choose the maximum throughput (RU/s) that the database or container cannot exceed when using the autoscale option.
 
-   ![Creating a container and configuring Autoscale throughput](./media/provision-throughput-autopilot/create-container-autopilot-mode.png)
+   ![Creating a container and configuring Autoscale throughput](./media/pprovision-throughput-autoscale/create-container-autoscale-mode.png)
 
 1. Select **OK**.
 
@@ -90,7 +90,7 @@ The following table shows the maximum throughout and storage limits for differen
 
 ## Next steps
 
-* Review the [autoscale FAQ](autopilot-faq.md).
+* Review the [autoscale FAQ](autoscale-faq.md).
 * Learn more about [logical partitions](partition-data.md).
 * Learn how to [provision throughput on an Azure Cosmos container](how-to-provision-container-throughput.md).
 * Learn how to [provision throughput on an Azure Cosmos database](how-to-provision-database-throughput.md).
