+## Scope of availability

+|Tier | Basic, Standard, Premium |Enterprise, Enterprise Flash |

+||||

+|Available | Yes | Yes |

+> Currently, the [portal-based redis console](cache-configure.md#redis-console) is not supported with private link.

+>

+> [!IMPORTANT]

+> When using private link, you cannot export or import data to a to a storage account that has firewall enabled unless you're using [managed identity to autenticate to the storage account](cache-managed-identity.md).

+> For more information, see [How to export if I have firewall enabled on my storage account?](cache-how-to-import-export-data.md#how-to-export-if-i-have-firewall-enabled-on-my-storage-account)

+For **Basic, Standard, and Premium tier** caches, your application should connect to `<cachename>.redis.cache.windows.net` on port `6380`. A private DNS zone, named `*.privatelink.redis.cache.windows.net`, is automatically created in your subscription. The private DNS zone is vital for establishing the TLS connection with the private endpoint. We recommend avoiding the use of `<cachename>.privatelink.redis.cache.windows.net` in configuration or connection string.

+For **Enterprise and Enterprise Flash** tier caches, your application should connect to `<cachename>.<region>.redisenterprise.cache.azure.net` on port `10000`.

+- Private endpoints can't be used with your cache instance if your cache is already using the VNet injection network connection method.

+- You try to [persist data to a storage account](cache-how-to-premium-persistence.md) with firewall rules and you're not using managed identity to connect to the storage account.

+- Private links can't be added to Premium tier caches that are already geo-replicated. To add a private link to a cache using [passive geo-replication](cache-how-to-geo-replication.md): 1. Unlink the geo-replication. 2. Add a Private Link. 3. Last, relink the geo-replication.

+You can also change the value through a RESTful API PATCH request. For example, use the following code for a Basic, Standard, or Premium tier cache and edit the value to reflect the flag you want for your cache.

+ For more information, see [Redis - Update](/rest/api/redis/Redis/Update?tabs=HTTP).

+Before you update your cluster, confirm that you're a member of the [Owner](../../role-based-access-control/built-in-roles.md#owner) role on the AKS cluster resource to enable collection of custom performance metrics for nodes and pods. This requirement doesn't apply to Azure Arc-enabled Kubernetes clusters.

+You might need to enable collection of custom metrics for your cluster. See [Metrics collected by Container insights](container-insights-custom-metrics.md).

+

+Since *standard metrics* are pre-aggregated during collection, they have better performance at query time. This makes them a better choice for dashboarding and in real-time alerting. The *log-based metrics* have more dimensions, which makes them the superior option for data analysis and ad-hoc diagnostics. Use the [namespace selector](./metrics-store-custom-rest-api.md#namespace) to switch between log-based and standard metrics in [metrics explorer](./analyze-metrics.md).

+Azure makes some metrics available to you out of the box. These metrics are called [standard or platform](./metrics-supported.md). Custom metrics are performance indicators or business-specific metrics that can be collected via your application's telemetry, the Azure Monitor Agent, a diagnostics extension that runs on your Azure resources, or an external monitoring system. Once custom metrics are published to Azure Monitor, you can browse, query, and alert on them along side the standard Azure metrics.

+- Use Azure Application Insights SDK to instrument your application by sending custom telemetry to Azure Monitor.

+- Install the [Azure Monitor Agent](../agents/azure-monitor-agent-overview.md) on your Windows or Linux Azure virtual machine or virtual machine scale set and use a [data collection rule](../agents/data-collection-rule-azure-monitor-agent.md) to send performance counters to Azure Monitor metrics.

+- Send custom metrics [directly to the Azure Monitor REST API](./metrics-store-custom-rest-api.md).

+In general, there's no cost to ingest standard metrics (platform metrics) into an Azure Monitor metrics store, but custom metrics incur costs when they enter general availability. Queries to the metrics API do incur costs. For details on when billing is enabled for custom metrics and metrics queries, check the [Azure Monitor pricing page](https://azure.microsoft.com/pricing/details/monitor/).

+## Custom metric definitions

+Each metric data point published contains a namespace, name, and dimension information. The first time a custom metric is emitted to Azure Monitor, a metric definition is automatically created. This new metric definition is then discoverable on any resource that the metric is emitted from via the metric definitions. There's no need to predefine a custom metric in Azure Monitor before it's emitted.

+With this metric, if you have 10 regions, 20 departments, and 100 customers that gives you 10 x 20 x 100 = 20,000 time series.

+There's a limit of 64 KB on the combined length of all custom metrics names, assuming utf-8 or 1 byte per character. If the 64-KB limit is exceeded, metadata for additional metrics won't be available. The metric names for additional custom metrics won't appear in the Azure portal in selection fields, and won't be returned by the API in requests for metric definitions. The metric data is still available and can be queried.

+ - [Send custom metrics to the Azure Monitor using the REST API](./metrics-store-custom-rest-api.md)

+ - [Linux virtual machine using the Telegraf agent](../essentials/collect-custom-metrics-linux-telegraf.md)\

+## Send REST requests to ingest custom metrics

+When you send custom metrics to Azure Monitor, each data point, or value, reported in the metrics must include the following information.

+### Authentication

+To submit custom metrics to Azure Monitor, the entity that submits the metric needs a valid Microsoft Entra token in the **Bearer** header of the request. Supported ways to acquire a valid bearer token include:

+- [Managed identities for Azure resources](../../active-directory/managed-identities-azure-resources/overview.md). You can use a managed identity to give resources permissions to carry out certain operations. An example is allowing a resource to emit metrics about itself. A resource, or its managed identity, can be granted **Monitoring Metrics Publisher** permissions on another resource. With this permission, the managed identity can also emit metrics for other resources.

+- [Microsoft Entra service principal](../../active-directory/develop/app-objects-and-service-principals.md). In this scenario, a Microsoft Entra application, or service, can be assigned permissions to emit metrics about an Azure resource. To authenticate the request, Azure Monitor validates the application token by using Microsoft Entra public keys. The existing **Monitoring Metrics Publisher** role already has this permission. It's available in the Azure portal.

+ The service principal, depending on what resources it emits custom metrics for, can be given the **Monitoring Metrics Publisher** role at the scope required. Examples are a subscription, resource group, or specific resource.

+> [!TIP]

+> When you request a Microsoft Entra token to emit custom metrics, ensure that the audience or resource that the token is requested for is `https://monitoring.azure.com/`. Be sure to include the trailing slash.

+### Get an authorization token

+Once you have created your managed identity or service principal and assigned **Monitoring Metrics Publisher** permissions, you can get an authorization token by using the following request:

+--data-urlencode 'resource=https://monitoring.azure.com'

+The response body appears in the following format:

+### Subject

+The subject property captures which Azure resource ID the custom metric is reported for. This information is encoded in the URL of the API call. Each API can submit metric values for only a single Azure resource.

+> [!NOTE]

+> You can't emit custom metrics against the resource ID of a resource group or subscription.

+### Region

+The region property captures the Azure region where the resource you're emitting metrics for is deployed. Metrics must be emitted to the same Azure Monitor regional endpoint as the region where the resource is deployed. For example, custom metrics for a VM deployed in West US must be sent to the WestUS regional Azure Monitor endpoint. The region information is also encoded in the URL of the API call.

+### Timestamp

+Each data point sent to Azure Monitor must be marked with a timestamp. This timestamp captures the date and time at which the metric value is measured or collected. Azure Monitor accepts metric data with timestamps as far as 20 minutes in the past and 5 minutes in the future. The timestamp must be in ISO 8601 format.

+### Namespace

+Namespaces are a way to categorize or group similar metrics together. By using namespaces, you can achieve isolation between groups of metrics that might collect different insights or performance indicators. For example, you might have a namespace called **contosomemorymetrics** that tracks memory-use metrics which profile your app. Another namespace called **contosoapptransaction** might track all metrics about user transactions in your application.

+### Name

+The name property is the name of the metric that's being reported. Usually, the name is descriptive enough to help identify what's measured. An example is a metric that measures the number of memory bytes used on a VM. It might have a metric name like **Memory Bytes In Use**.

+### Dimension keys

+A dimension is a key/value pair that helps describe other characteristics about the metric that's being collected. By using the other characteristics, you can collect more information about the metric, which allows for deeper insights.

+For example, the **Memory Bytes In Use** metric might have a dimension key called **Process** that captures how many bytes of memory each process on a VM consumes. By using this key, you can filter the metric to see how much memory specific processes use or to identify the top five processes by memory usage.

+Dimensions are optional, and not all metrics have dimensions. A custom metric can have up to 10 dimensions.

+### Dimension values

+When you're reporting a metric data point, for each dimension key on the reported metric, there's a corresponding dimension value. For example, you might want to report the memory that ContosoApp uses on your VM:

+* The metric name would be **Memory Bytes in Use**.

+* The dimension key would be **Process**.

+* The dimension value would be **ContosoApp.exe**.

+When you're publishing a metric value, you can specify only a single dimension value per dimension key. If you collect the same memory utilization for multiple processes on the VM, you can report multiple metric values for that timestamp. Each metric value would specify a different dimension value for the **Process** dimension key.

+Although dimensions are optional, if a metric post defines dimension keys, corresponding dimension values are mandatory.

+### Metric values

+Azure Monitor stores all metrics at 1-minute granularity intervals. During a given minute, a metric might need to be sampled several times. An example is CPU utilization. Or a metric might need to be measured for many discrete events, such as sign-in transaction latencies.

+To limit the number of raw values that you have to emit and pay for in Azure Monitor, locally pre-aggregate and emit the aggregated values:

+* **Min**: The minimum observed value from all the samples and measurements during the minute.

+* **Max**: The maximum observed value from all the samples and measurements during the minute.

+* **Sum**: The summation of all the observed values from all the samples and measurements during the minute.

+* **Count**: The number of samples and measurements taken during the minute.

+> [!NOTE]

+> Azure Monitor doesn't support defining **Units** for a custom metric.

+For example, if there were four sign-in transactions to your app during a minute, the resulting measured latencies for each might be:

+|Transaction 1|Transaction 2|Transaction 3|Transaction 4|

+|||||

+|7 ms|4 ms|13 ms|16 ms|

+Then the resulting metric publication to Azure Monitor would be:

+* Min: 4

+* Max: 16

+* Sum: 40

+* Count: 4

+If your application can't pre-aggregate locally and needs to emit each discrete sample or event immediately upon collection, you can emit the raw measure values. For example, each time a sign-in transaction occurs on your app, you publish a metric to Azure Monitor with only a single measurement. So, for a sign-in transaction that took 12 milliseconds, the metric publication would be:

+* Min: 12

+* Max: 12

+* Sum: 12

+* Count: 1

+With this process, you can emit multiple values for the same metric/dimension combination during a given minute. Azure Monitor then takes all the raw values emitted for a given minute and aggregates them.

+### Sample custom metric publication

+In the following example, create a custom metric called **Memory Bytes in Use** under the metric namespace **Memory Profile** for a virtual machine. The metric has a single dimension called **Process**. For the timestamp, metric values are emitted for two processes.

+Store the following JSON in a file called *custommetric.json* on your local computer. Update the time parameter so that it's within the last 20 minutes. You can't put a metric into the store that's more than 20 minutes old.

+```json

+{

+ "time": "2024-01-07T11:25:20-7:00",

+ "data": {

+ "baseData": {

+ "metric": "Memory Bytes in Use",

+ "namespace": "Memory Profile",

+ "dimNames": [

+ "Process"

+ ],

+ "series": [

+ {

+ "dimValues": [

+ "ContosoApp.exe"

+ ],

+ "min": 10,

+ "max": 89,

+ "sum": 190,

+ "count": 4

+ },

+ {

+ "dimValues": [

+ "SalesApp.exe"

+ ],

+ "min": 10,

+ "max": 23,

+ "sum": 86,

+ "count": 4

+ }

+ ]

+ }

+ }

+ }

+```

+Submit the following HTTP POST request by using the following variables:

+1. In the **Metric Namespace** dropdown list, select **Memory Profile**.

+1. In the **Metric** dropdown list, select **Memory Bytes in Use**.

+## Troubleshooting

+If you receive an error message with some part of the process, consider the following troubleshooting information:

+- If you can't issue metrics against a subscription or resource group, or resource, check that your application or service principal has the **Monitoring Metrics Publisher** role assigned in **Access control (IAM)**.

+- Check that the number of dimension names matches the number of values.

+- Check that you're emitting metrics to the correct Azure Monitor regional endpoint. For example, if your resource is deployed in West US, you must emit metrics to the West US regional endpoint.

+- Check that the timestamp is within the last 20 minutes.

+- Check that the timestamp is in ISO 8601 format.

+- Check that the metric name is valid. For example, it can't contain spaces.

+This article presents how to profile SQL query performance on Azure Cosmos DB using [ServerSideCumulativeMetrics](/dotnet/api/microsoft.azure.cosmos.serversidecumulativemetrics) retrieved from the .NET SDK. `ServerSideCumulativeMetrics` is a strongly typed object with information about the backend query execution. It contains cumulative metrics that are aggregated across all physical partitions for the request, and a list of metrics for each physical partition. These metrics are documented in more detail in the [Tune Query Performance](./query-metrics.md#query-execution-metrics) article.

+## Get query metrics

+Query metrics are available as a strongly typed object in the .NET SDK beginning in [version 3.36.0](https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.36.0). Prior to this version, or if you're using a different SDK language, you can retrieve query metrics by parsing the `Diagnostics`. The following code sample shows how to retrieve `ServerSideCumulativeMetrics` from the `Diagnostics` in a [FeedResponse](/dotnet/api/microsoft.azure.cosmos.feedresponse-1):

+CosmosClient client = new CosmosClient(myCosmosEndpoint, myCosmosKey);

+Container container = client.GetDatabase(myDatabaseName).GetContainer(myContainerName);

+QueryDefinition query = new QueryDefinition("SELECT TOP 5 * FROM c");

+FeedIterator<MyClass> feedIterator = container.GetItemQueryIterator<MyClass>(query);

+while (feedIterator.HasMoreResults)

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ // Retrieve the ServerSideCumulativeMetrics object from the FeedResponse

+ ServerSideCumulativeMetrics metrics = feedResponse.Diagnostics.GetQueryMetrics();

+You can also get query metrics from the `FeedResponse` of a LINQ query using the `ToFeedIterator()` method:

+FeedIterator<MyClass> feedIterator = container.GetItemLinqQueryable<MyClass>()

+ .Take(5)

+ .ToFeedIterator();

+while (feedIterator.HasMoreResults)

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ ServerSideCumulativeMetrics metrics = feedResponse.Diagnostics.GetQueryMetrics();

+### Cumulative Metrics

+`ServerSideCumulativeMetrics` contains a `CumulativeMetrics` property that represents the query metrics aggregated over all partitions for the single round trip.

+// Retrieve the ServerSideCumulativeMetrics object from the FeedResponse

+ServerSideCumulativeMetrics metrics = feedResponse.Diagnostics.GetQueryMetrics();

+// CumulativeMetrics is the metrics for this continuation aggregated over all partitions

+ServerSideMetrics cumulativeMetrics = metrics.CumulativeMetrics;

+```

+You can also aggregate these metrics across all round trips for the query. The following is an example of how to aggregate query execution time across all round trips for a given query using LINQ:

+```csharp

+QueryDefinition query = new QueryDefinition("SELECT TOP 5 * FROM c");

+FeedIterator<MyClass> feedIterator = container.GetItemQueryIterator<MyClass>(query);

+List<ServerSideCumulativeMetrics> metrics = new List<ServerSideCumulativeMetrics>();

+TimeSpan cumulativeTime;

+while (feedIterator.HasMoreResults)

+ // Execute one continuation of the query

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ // Store the ServerSideCumulativeMetrics object to aggregate values after all round trips

+ metrics.Add(response.Diagnostics.GetQueryMetrics());

+// Aggregate values across trips for metrics of interest

+TimeSpan totalTripsExecutionTime = metrics.Aggregate(TimeSpan.Zero, (currentSum, next) => currentSum + next.CumulativeMetrics.TotalTime);

+DoSomeLogging(totalTripsExecutionTime);

+### Partitioned Metrics

+`ServerSideCumulativeMetrics` contains a `PartitionedMetrics` property that is a list of per-partition metrics for the round trip. If multiple physical partitions are reached in a single round trip, then metrics for each of them appear in the list. Partitioned metrics are represented as [ServerSidePartitionedMetrics](/dotnet/api/microsoft.azure.cosmos.serversidepartitionedmetrics) with a unique identifier for each physical partition.

+// Retrieve the ServerSideCumulativeMetrics object from the FeedResponse

+ServerSideCumulativeMetrics metrics = feedResponse.Diagnostics.GetQueryMetrics();

+// PartitionedMetrics is a list of per-partition metrics for this continuation

+List<ServerSidePartitionedMetrics> partitionedMetrics = metrics.PartitionedMetrics;

+```

+When accumulated over all round trips, per partition metrics allow you to see if a specific partition is causing performance issues when compared to others. The following is an example of how to group partition metrics for each trip using LINQ:

+```csharp

+QueryDefinition query = new QueryDefinition("SELECT TOP 5 * FROM c");

+FeedIterator<MyClass> feedIterator = container.GetItemQueryIterator<MyClass>(query);

+List<ServerSideCumulativeMetrics> metrics = new List<ServerSideCumulativeMetrics>();

+while (feedIterator.HasMoreResults)

+{

+ // Execute one continuation of the query

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ // Store the ServerSideCumulativeMetrics object to aggregate values after all round trips

+ metrics.Add(response.Diagnostics.GetQueryMetrics());

+}

+// Group metrics by partition key range id

+var groupedPartitionMetrics = metrics.SelectMany(m => m.PartitionedMetrics).GroupBy(p => p.PartitionKeyRangeId);

+foreach(var partitionGroup in groupedPartitionMetrics)

+{

+ foreach(var tripMetrics in partitionGroup)

+ {

+ DoSomethingWithMetrics();

+ }

+}

+## Get the query request charge

+You can capture the request units consumed by each query to investigate expensive queries or queries that consume high throughput. You can get the request charge by using the `RequestCharge` property in `FeedResponse`. To learn more about how to get the request charge using the Azure portal and different SDKs, see [find the request unit charge](find-request-unit-charge.md) article.

+QueryDefinition query = new QueryDefinition("SELECT TOP 5 * FROM c");

+FeedIterator<MyClass> feedIterator = container.GetItemQueryIterator<MyClass>(query);

+while (feedIterator.HasMoreResults)

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ double requestCharge = feedResponse.RequestCharge;

+You can capture query execution time for each trip from the query metrics. When looking at request latency, it's important to differentiate query execution time from other sources of latency, such as network transit time. The following example shows how to get cumulative query execution time for each round trip:

+QueryDefinition query = new QueryDefinition("SELECT TOP 5 * FROM c");

+FeedIterator<MyClass> feedIterator = container.GetItemQueryIterator<MyClass>(query);

+TimeSpan cumulativeTime;

+while (feedIterator.HasMoreResults)

+ FeedResponse<MyClass> feedResponse = await feedIterator.ReadNextAsync();

+ ServerSideCumulativeMetrics metrics = response.Diagnostics.GetQueryMetrics();

+ cumulativeTime = metrics.CumulativeMetrics.TotalTime;

+DoSomeLogging(cumulativeTime);

+## Get the index utilization

+Looking at the index utilization can help you debug slow queries. Queries that can't use the index result in a full scan of all documents in a container before returning the result set.

+Here's an example of a scan query:

+Query Preparation Time : 0.2 milliseconds

+Index Lookup Time : 0.01 milliseconds

+Document Load Time : 4,177.66 milliseconds

+Runtime Execution Time : 407.9 milliseconds

+Document Write Time : 0.01 milliseconds

+This query is now able to be served from the index. Alternatively, you can use [computed properties](query/computed-properties.md) to index the results of system functions or complex calculations that would otherwise result in a full scan.

+* Examples of how to utilize SQL query execution metrics to debug query performance

+In Azure Cosmos DB data is stored in containers, which can grow to any [storage size or request throughput](../partitioning-overview.md). Azure Cosmos DB seamlessly scales data across physical partitions under the covers to handle data growth or increases in provisioned throughput. You can issue SQL queries to any container using the REST API or one of the supported [SQL SDKs](sdk-dotnet-v3.md).

+A brief overview of partitioning: you define a partition key like "city", which determines how data is split across physical partitions. Data belonging to a single partition key (for example, "city" == "Seattle") is stored within a physical partition, and a single physical partition can store data from multiple partition keys. When a partition reaches its storage limit, the service seamlessly splits the partition into two new partitions. Data is distributed evenly across the new partitions, keeping all data for a single partition key together. Since partitions are transient, the APIs use an abstraction of a partition key range, which denotes the ranges of partition key hashes.

+* If the query includes a filter against the partition key, like `SELECT * FROM c WHERE c.city = "Seattle"`, it's routed to a single partition. If the query doesn't have a filter on the partition key, then it's executed in all partitions and results from each partition are merged client side.

+* The query is executed within each partition in series or parallel, based on client configuration. Within each partition, the query might make one or more round trips depending on the query complexity, configured page size, and provisioned throughput of the collection. Each execution returns the number of [request units](../request-units.md) consumed by query execution and query execution statistics.

+The SDKs provide various options for query execution. For example, in .NET these options are available in the [`QueryRequestOptions`](/dotnet/api/microsoft.azure.cosmos.queryrequestoptions) class. The following table describes these options and how they affect query execution time.

+| `EnableScanInQuery` | Only applicable if indexing for the requested filter path is disabled. Must be set to true if you opted out of indexing and want to run queries using a full scan. |

+| `MaxItemCount` | The maximum number of items to return per round trip to the server. You can set it to -1 to let the server manage the number of items to return. |

+| `MaxBufferedItemCount` | The maximum number of items that can be buffered client side during parallel query execution. A positive property value limits the number of buffered items to the set value. You can set it to less than 0 to let the system automatically decide the number of items to buffer. |

+| `MaxConcurrency` | Gets or sets the number of concurrent operations run client side during parallel query execution. A positive property value limits the number of concurrent operations to the set value. You can set it to less than 0 to let the system automatically decide the number of concurrent operations to run. |

+| `PopulateIndexMetrics` | Enables collection of [index metrics](./index-metrics.md) to understand how the query engine used existing indexes and how it could use potential new indexes. This option incurs overhead, so it should only be enabled when debugging slow queries. |

+| `ResponseContinuationTokenLimitInKb` | You can limit the maximum size of the continuation token returned by the server. You might need to set this if your application host has limits on response header size, but it can increase the overall duration and RUs consumed for the query. |

+For example, here's a query on a container partitioned by `/city` using the .NET SDK:

+```csharp

+QueryDefinition query = new QueryDefinition("SELECT * FROM c WHERE c.city = 'Seattle'");

+QueryRequestOptions options = new QueryRequestOptions()

+{

+ MaxItemCount = -1,

+ MaxBufferedItemCount = -1,

+ MaxConcurrency = -1,

+ PopulateIndexMetrics = true

+};

+FeedIterator<dynamic> feedIterator = container.GetItemQueryIterator<dynamic>(query);

+FeedResponse<dynamic> feedResponse = await feedIterator.ReadNextAsync();

+Each query execution corresponds to a REST API `POST` with headers set for the query request options and the SQL query in the body. For details on the REST API request headers and options, see [Querying resources using the REST API](/rest/api/cosmos-db/querying-cosmosdb-resources-using-the-rest-api).

+The following factors commonly have the biggest effect on Azure Cosmos DB query performance. We dig deeper into each of these factors in this article.

+| Network latency | Run your application in the same region as your Azure Cosmos DB account wherever possible to reduce latency. |

+| Indexing policy | Ensure that you have the required indexing paths/policy for the query. |

+In Azure Cosmos DB, you create containers of data, each with reserved throughput expressed in request units (RU) per-second. A read of a 1-KB document is one RU, and every operation (including queries) is normalized to a fixed number of RUs based on its complexity. For example, if you have 1000 RU/s provisioned for your container, and you have a query like `SELECT * FROM c WHERE c.city = 'Seattle'` that consumes 5 RUs, then you can execute (1000 RU/s) / (5 RU/query) = 200 of these queries per second.

+If you submit more than 200 queries/sec (or some other operations that saturate all provisioned RUs), the service starts rate-limiting incoming requests. The SDKs automatically handle rate-limiting by performing a backoff/retry, therefore you might notice higher latency for these queries. Increasing the provisioned throughput to the required value improves your query latency and throughput.

+With Azure Cosmos DB, the following scenarios for reading data are ordered from what is typically fastest/most efficient to the slowest/least efficient.

+* GET on a single partition key and item id, also known as a point read

+* Query with an equality or range filter clause on any property

+Queries that need to be executed on all partitions have higher latency, and can consume higher RUs. Since each partition has automatic indexing against all properties, the query can be served efficiently from the index in this case. You can make queries that span partitions faster by using the parallelism options.

+See [query performance tips](performance-tips-query-sdk.md) and [performance testing](performance-testing.md) for how to get the best client-side performance from Azure Cosmos DB using our SDKs.

+See [Azure Cosmos DB global distribution](tutorial-global-distribution.md) for how to set up global distribution and connect to the closest region. Network latency has a significant effect on query performance when you need to make multiple round-trips or retrieve a large result set from the query.

+You can use [query execution metrics](#query-execution-metrics) to retrieve the server execution time of queries, allowing you to differentiate time spent in query execution from time spent in network transit.

+### Indexing policy

+See [configuring indexing policy](../index-policy.md) for indexing paths, kinds, and modes, and how they impact query execution. By default, Azure Cosmos DB applies automatic indexing to all data and uses range indexes for strings and numbers, which is effective for equality queries. For high performance insert scenarios, consider excluding paths to reduce the RU cost for each insert operation.

+You can use the [index metrics](./index-metrics.md) to identify which indexes are used for each query and if there are any missing indexes that would improve query performance.

+## Query execution metrics

+Detailed metrics are returned for each query execution in the [Diagnostics](./troubleshoot-dotnet-sdk.md#capture-diagnostics) for the request. These metrics describe where time is spent during query execution and enable advanced troubleshooting.

+Learn more about [getting the query metrics](./query-metrics-performance.md).

+| `TotalTime` | milliseconds | Total query execution time |

+| `DocumentLoadTime` | milliseconds | Time spent loading documents |

+| `DocumentWriteTime` | milliseconds | Time spent writing and serializing the output documents |

+| `IndexLookupTime` | milliseconds | Time spent in physical index layer |

+| `QueryPreparationTime` | milliseconds | Time spent in preparing query |

+| `RuntimeExecutionTime` | milliseconds | Total query runtime execution time |

+| `VMExecutionTime` | milliseconds | Time spent in query runtime executing the query |

+| `OutputDocumentCount` | count | Number of output documents in the result set |

+| `OutputDocumentSize` | count | Total size of outputted documents in bytes |

+| `RetrievedDocumentCount` | count | Total number of retrieved documents |

+| `RetrievedDocumentSize` | bytes | Total size of retrieved documents in bytes |

+| `IndexHitRatio` | ratio [0,1] | Ratio of number of documents matched by the filter to the number of documents loaded |

+The client SDKs can internally make multiple query requests to serve the query within each partition. The client makes more than one call per-partition if the total results exceed the max item count request option, if the query exceeds the provisioned throughput for the partition, if the query payload reaches the maximum size per page, or if the query reaches the system allocated timeout limit. Each partial query execution returns query metrics for that page.

+| `SELECT TOP 100 * FROM c` | `"RetrievedDocumentCount": 101` | The number of documents retrieved is 100+1 to match the TOP clause. Query time is mostly spent in `WriteOutputTime` and `DocumentLoadTime` since it's a scan. |

+| `SELECT TOP 500 c.N FROM c` | `"IndexLookupTime": "00:00:00.0017700"` | Same time spent on `DocumentLoadTime` as previous queries, but lower `DocumentWriteTime` because we're projecting only one property. |

+| `SELECT TOP 500 udf.toPercent(c.N) FROM c` | `"RuntimeExecutionTime": "00:00:00.2136500"` | About 213 ms is spent in `RuntimeExecutionTime` executing the UDF on each value of `c.N`. |

+| `SELECT TOP 500 c.Name FROM c WHERE STARTSWITH(c.Name, 'Den')` | `"IndexLookupTime": "00:00:00.0006400", "RuntimeExecutionTime": "00:00:00.0074100"` | About 0.6 ms is spent in `IndexLookupTime` on `/Name/?`. Most of the query execution time (~7 ms) in `RuntimeExecutionTime`. |

+> [!NOTE]

+> Starting March 1, 2024, Defender CSPM must be enabled to have premium DevOps security capabilities that include code-to-cloud contextualization powering security explorer and attack paths and pull request annotations for Infrastructure-as-Code security findings. See DevOps security [support and prerequisites](devops-support.md) to learn more.

+|What Azure regions are supported? | You can discover Azure storage accounts in:<br/><br/> Asia East; Asia South East; Australia Central; Australia Central 2; Australia East; Australia South East; Brazil South; Brazil Southeast; Canada Central; Canada East; Europe North; Europe West; France Central; France South; Germany North; Germany West Central; India Central; India South; Japan East; Japan West; Jio India West; Korea Central; Korea South; Norway East; Norway West; South Africa North; South Africa West; Sweden Central; Switzerland North; Switzerland West; UAE North; UK South; UK West; US Central; US East; US East 2; US North Central; US South Central; US West; US West 2; US West 3; US West Central; <br/><br/> You can discover Azure SQL Databases in any region where Defender CSPM and Azure SQL Databases are supported. |

+|What AWS regions are supported? | S3:<br /><br />Asia Pacific (Mumbai); Asia Pacific (Singapore); Asia Pacific (Sydney); Asia Pacific (Tokyo); Canada (Montreal); Europe (Frankfurt); Europe (Ireland); Europe (London); Europe (Paris); Europe (Stockholm); South America (São Paulo); US East (Ohio); US East (N. Virginia); US West (N. California): US West (Oregon).<br/><br/><br />RDS:<br /><br/>Africa (Capetown); Asia Pacific (Hong Kong SAR); Asia Pacific (Hyderabad); Asia Pacific (Melbourne); Asia Pacific (Mumbai); Asia Pacific (Osaka); Asia Pacific (Seoul); Asia Pacific (Singapore); Asia Pacific (Sydney); Asia Pacific (Tokyo); Canada (Central); Europe (Frankfurt); Europe (Ireland); Europe (London); Europe (Paris); Europe (Stockholm); Europe (Zurich); Middle East (UAE); South America (São Paulo); US East (Ohio); US East (N. Virginia); US West (N. California): US West (Oregon).<br /><br /> Discovery is done locally within the region. |

+|What's the cost? | The feature is included with the Defender CSPM and Defender for Storage plans, and doesnΓÇÖt incur extra costs except for the respective plan costs. |

+The main steps for configuring data sensitivity settings include:

+- [Import custom sensitivity info types/labels from Microsoft Purview compliance portal](data-sensitivity-settings.md#import-custom-sensitivity-info-typeslabels)

+## Import custom sensitivity info types/labels

+To import custom sensitivity info types and labels, you need to have Enterprise Mobility and Security E5/A5/G5 licensing. Learn more about [sensitivity labeling licensing](/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance#microsoft-purview-information-protection-sensitivity-labeling).

+Since the principal of the role is a federated identity as defined in a trust relationship policy, the AWS identity provider validates the Microsoft Entra token against the Microsoft Entra ID through a process that includes:

+- token digital signature validation

+After the Microsoft Entra token is validated by the AWS identity provider, the AWS STS exchanges the token with AWS short-living credentials which the CSPM service uses to scan the AWS account.

+|API endpoints in Azure API Management should be authenticated|API endpoints published within Azure API Management should enforce authentication to help minimize security risk. Authentication mechanisms are sometimes implemented incorrectly or are missing. This allows attackers to exploit implementation flaws and to access data. For APIs published in Azure API Management, this recommendation assesses authentication through verifying the presence of Azure API Management subscription keys for APIs or products where subscription is required, and the execution of policies for validating [JWT](/azure/api-management/validate-jwt-policy), [client certificates](/azure/api-management/validate-client-certificate-policy), and [Microsoft Entra](/azure/api-management/validate-azure-ad-token-policy) tokens. If none of these authentication mechanisms are executed during the API call, the API will receive this recommendation.|High|

+## July 2023

+Updates in July include:

+|Date |Update |

+|-|-|

+| July 31 | [Preview release of containers Vulnerability Assessment powered by Microsoft Defender Vulnerability Management (MDVM) in Defender for Containers and Defender for Container Registries](#preview-release-of-containers-vulnerability-assessment-powered-by-microsoft-defender-vulnerability-management-mdvm-in-defender-for-containers-and-defender-for-container-registries) |

+| July 30 | [Agentless container posture in Defender CSPM is now Generally Available](#agentless-container-posture-in-defender-cspm-is-now-generally-available) |

+| July 20 | [Management of automatic updates to Defender for Endpoint for Linux](#management-of-automatic-updates-to-defender-for-endpoint-for-linux) |

+| July 18 | [Agentless secrets scanning for virtual machines in Defender for servers P2 & Defender CSPM](#agentless-secrets-scanning-for-virtual-machines-in-defender-for-servers-p2--defender-cspm) |

+| July 12 | [New Security alert in Defender for Servers plan 2: Detecting Potential Attacks leveraging Azure VM GPU driver extensions](#new-security-alert-in-defender-for-servers-plan-2-detecting-potential-attacks-leveraging-azure-vm-gpu-driver-extensions) |

+| July 9 | [Support for disabling specific vulnerability findings](#support-for-disabling-specific-vulnerability-findings) |

+| July 1 | [Data Aware Security Posture is now Generally Available](#data-aware-security-posture-is-now-generally-available) |

+### Preview release of containers Vulnerability Assessment powered by Microsoft Defender Vulnerability Management (MDVM) in Defender for Containers and Defender for Container Registries

+July 31, 2023

+We're announcing the release of Vulnerability Assessment (VA) for Linux container images in Azure container registries powered by Microsoft Defender Vulnerability Management (MDVM) in Defender for Containers and Defender for Container Registries. The new container VA offering will be provided alongside our existing Container VA offering powered by Qualys in both Defender for Containers and Defender for Container Registries, and include daily rescans of container images, exploitability information, support for OS and programming languages (SCA) and more.

+This new offering will start rolling out today, and is expected to be available to all customers by August 7.

+For more information, see [Container Vulnerability Assessment powered by MDVM](agentless-vulnerability-assessment-azure.md) and [Microsoft Defender Vulnerability Management (MDVM)](/microsoft-365/security/defender-vulnerability-management/defender-vulnerability-management).

+### Agentless container posture in Defender CSPM is now Generally Available

+July 30, 2023

+Agentless container posture capabilities are now Generally Available (GA) as part of the Defender CSPM (Cloud Security Posture Management) plan.

+Learn more about [agentless container posture in Defender CSPM](concept-agentless-containers.md).

+### Management of automatic updates to Defender for Endpoint for Linux

+July 20, 2023

+By default, Defender for Cloud attempts to update your Defender for Endpoint for Linux agents onboarded with the `MDE.Linux` extension. With this release, you can manage this setting and opt-out from the default configuration to manage your update cycles manually.

+Learn how to [manage automatic updates configuration for Linux](integration-defender-for-endpoint.md#manage-automatic-updates-configuration-for-linux).

+### Agentless secrets scanning for virtual machines in Defender for servers P2 & Defender CSPM

+July 18, 2023

+Secrets scanning is now available as part of the agentless scanning in Defender for Servers P2 and Defender CSPM. This capability helps to detect unmanaged and insecure secrets saved on virtual machines in Azure or AWS resources that can be used to move laterally in the network. If secrets are detected, Defender for Cloud can help to prioritize and take actionable remediation steps to minimize the risk of lateral movement, all without affecting your machine's performance.

+For more information about how to protect your secrets with secrets scanning, see [Manage secrets with agentless secrets scanning](secret-scanning.md).

+### New security alert in Defender for Servers plan 2: detecting potential attacks leveraging Azure VM GPU driver extensions

+July 12, 2023

+This alert focuses on identifying suspicious activities leveraging Azure virtual machine **GPU driver extensions** and provides insights into attackers' attempts to compromise your virtual machines. The alert targets suspicious deployments of GPU driver extensions; such extensions are often abused by threat actors to utilize the full power of the GPU card and perform cryptojacking.

+| Alert Display Name <br> (Alert Type) | Description | Severity | MITRE Tactic |

+|||||

+| Suspicious installation of GPU extension in your virtual machine (Preview) <br> (VM_GPUDriverExtensionUnusualExecution) | Suspicious installation of a GPU extension was detected in your virtual machine by analyzing the Azure Resource Manager operations in your subscription. Attackers might use the GPU driver extension to install GPU drivers on your virtual machine via the Azure Resource Manager to perform cryptojacking. | Low | Impact |

+For a complete list of alerts, see the [reference table for all security alerts in Microsoft Defender for Cloud](alerts-reference.md).

+### Support for disabling specific vulnerability findings

+July 9, 2023

+Release of support for disabling vulnerability findings for your container registry images or running images as part of agentless container posture. If you have an organizational need to ignore a vulnerability finding on your container registry image, rather than remediate it, you can optionally disable it. Disabled findings don't affect your secure score or generate unwanted noise.

+Learn how to [disable vulnerability assessment findings on Container registry images](disable-vulnerability-findings-containers.md).

+### Data Aware Security Posture is now Generally Available

+July 1, 2023

+Data-aware security posture in Microsoft Defender for Cloud is now Generally Available. It helps customers to reduce data risk, and respond to data breaches. Using data-aware security posture you can:

+- Automatically discover sensitive data resources across Azure and AWS.

+- Evaluate data sensitivity, data exposure, and how data flows across the organization.

+- Proactively and continuously uncover risks that might lead to data breaches.

+- Detect suspicious activities that might indicate ongoing threats to sensitive data resources

+For more information, see [Data-aware security posture in Microsoft Defender for Cloud](concept-data-security-posture.md).

+## January 2024

+| Date | Update |

+|--|--|

+| January 4 | [Recommendations released for preview: Nine new Azure security recommendations](#recommendations-released-for-preview-nine-new-azure-security-recommendations) |

+### Recommendations released for preview: Nine new Azure security recommendations

+January 4, 2024

+We have added nine new Azure security recommendations aligned with the Microsoft Cloud Security Benchmark. These new recommendations are currently in public preview.

+|Recommendation | Description | Severity |

+|-|-|-|

+| [Cognitive Services accounts should have local authentication methods disabled](recommendations-reference.md#identityandaccess-recommendations) | Disabling local authentication methods improves security by ensuring that Cognitive Services accounts require Azure Active Directory identities exclusively for authentication. Learn more at: https://aka.ms/cs/auth. (Related policy: [Cognitive Services accounts should have local authentication methods disabled](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f71ef260a-8f18-47b7-abcb-62d0673d94dc)). | Low |

+| [Cognitive Services should use private link](recommendations-reference.md#data-recommendations) | Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to Cognitive Services, you'll reduce the potential for data leakage. Learn more about [private links](https://go.microsoft.com/fwlink/?linkid=2129800). (Related policy: [Cognitive Services should use private link](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2fcddd188c-4b82-4c48-a19d-ddf74ee66a01)). | Medium |

+| [Virtual machines and virtual machine scale sets should have encryption at host enabled](recommendations-reference.md#compute-recommendations) | Use encryption at host to get end-to-end encryption for your virtual machine and virtual machine scale set data. Encryption at host enables encryption at rest for your temporary disk and OS/data disk caches. Temporary and ephemeral OS disks are encrypted with platform-managed keys when encryption at host is enabled. OS/data disk caches are encrypted at rest with either customer-managed or platform-managed key, depending on the encryption type selected on the disk. Learn more at https://aka.ms/vm-hbe. (Related policy: [Virtual machines and virtual machine scale sets should have encryption at host enabled](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2ffc4d8e41-e223-45ea-9bf5-eada37891d87)). | Medium |

+| [Azure Cosmos DB should disable public network access](recommendations-reference.md#data-recommendations) | Disabling public network access improves security by ensuring that your Cosmos DB account isn't exposed on the public internet. Creating private endpoints can limit exposure of your Cosmos DB account. [Learn more](/azure/cosmos-db/how-to-configure-private-endpoints#blocking-public-network-access-during-account-creation). (Related policy: [Azure Cosmos DB should disable public network access](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f797b37f7-06b8-444c-b1ad-fc62867f335a)). | Medium |

+| [Cosmos DB accounts should use private link](recommendations-reference.md#data-recommendations) | Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Cosmos DB account, data leakage risks are reduced. Learn more about [private links](/azure/cosmos-db/how-to-configure-private-endpoints). (Related policy: [Cosmos DB accounts should use private link](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f58440f8a-10c5-4151-bdce-dfbaad4a20b7)). | Medium |

+| [VPN gateways should use only Azure Active Directory (Azure AD) authentication for point-to-site users](recommendations-reference.md#identityandaccess-recommendations) | Disabling local authentication methods improves security by ensuring that VPN Gateways use only Azure Active Directory identities for authentication. Learn more about [Azure AD authentication](/azure/vpn-gateway/openvpn-azure-ad-tenant). (Related policy: [VPN gateways should use only Azure Active Directory (Azure AD) authentication for point-to-site users](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f21a6bc25-125e-4d13-b82d-2e19b7208ab7)). | Medium |

+| [Azure SQL Database should be running TLS version 1.2 or newer](recommendations-reference.md#data-recommendations) | Setting TLS version to 1.2 or newer improves security by ensuring your Azure SQL Database can only be accessed from clients using TLS 1.2 or newer. Using versions of TLS less than 1.2 is not recommended since they have well documented security vulnerabilities. (Related policy: [Azure SQL Database should be running TLS version 1.2 or newer](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f32e6bbec-16b6-44c2-be37-c5b672d103cf)). | Medium |

+| [Azure SQL Managed Instances should disable public network access](recommendations-reference.md#data-recommendations) | Disabling public network access (public endpoint) on Azure SQL Managed Instances improves security by ensuring that they can only be accessed from inside their virtual networks or via Private Endpoints. Learn more about [public network access](https://aka.ms/mi-public-endpoint). (Related policy: [Azure SQL Managed Instances should disable public network access](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f9dfea752-dd46-4766-aed1-c355fa93fb91)). | Medium |

+| [Storage accounts should prevent shared key access](recommendations-reference.md#data-recommendations) | Audit requirement of Azure Active Directory (Azure AD) to authorize requests for your storage account. By default, requests can be authorized with either Azure Active Directory credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over shared Key, and is recommended by Microsoft. (Related policy: [Storage accounts should prevent shared key access](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f8c6a50c6-9ffd-4ae7-986f-5fa6111f9a54)). |Medium |

+See the [list of security recommendations](recommendations-reference.md).

+| November 20 | [General Availability of the autoprovisioning process for SQL Servers on machines plan](#general-availability-of-the-autoprovisioning-process-for-sql-servers-on-machines-plan)|

+| November 15 | [General availability of Defender for APIs](#general-availability-of-defender-for-apis) |

+| **Suspicious installation of a GPU extension was detected on your virtual machine (Preview)**<br>(VM_GPUDriverExtensionUnusualExecution)<br>*This alert was [released in July 2023](release-notes-archive.md#new-security-alert-in-defender-for-servers-plan-2-detecting-potential-attacks-leveraging-azure-vm-gpu-driver-extensions).* | Suspicious installation of a GPU extension was detected on your virtual machine by analyzing the Azure Resource Manager operations in your subscription. Attackers might use the GPU driver extension to install GPU drivers on your virtual machine via the Azure Resource Manager to perform cryptojacking. This activity is deemed suspicious as the principal's behavior departs from its usual patterns. | Impact | Low |

+Defender API calls to AWS:

+Cost impact: When you onboard your AWS single or management account, our Discovery service initiates an immediate scan of your environment by executing API calls to various service endpoints in order to retrieve all resources that we secure.

+Following this initial scan, the service will continue to periodically scan your environment at the interval that you configured during onboarding. It's important to note that in AWS, each API call to the account generates a lookup event that is recorded in the CloudTrail resource.

+The CloudTrail resource incurs costs, and the pricing details can be found in [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/).

+Furthermore, if you have connected your CloudTrail to GuardDuty, you're also responsible for associated costs, which can be found in the [GuardDuty documentation](https://docs.aws.amazon.com/guardduty/latest/ug/monitoring_costs.html).

+**Getting the number of native API calls executed by Defender for Cloud**:

+There are two ways to get the number of calls made by Defender for Cloud and both rely on querying AWS CloudTrail logs:

+- **CloudTrail and Athena tables**:

+1. Use an existing or create a new *Athena table*. For more information, see [Querying AWS CloudTrail logs](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html).

+1. Navigate to the above Athena table and use one of the below predefined queries per your needs.

+- **CloudTrail lake**:

+1. Use an existing or create a new *Event Data Store*. For more information, see [Working with AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).

+1. Navigate to the above lake and use one of the below predefined queries per your needs.

+ Sample Queries:

+ - List the number of overall API calls by Defender for Cloud:

+ ```sql

+ SELECT COUNT(*) AS overallApiCallsCount FROM <TABLE-NAME>

+ WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

+ AND eventTime > TIMESTAMP '<DATETIME>'

+ ```

+ - List the number of overall API calls by Defender for Cloud aggregated by day:

+ ```sql

+ SELECT DATE(eventTime) AS apiCallsDate, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME>

+ WHERE userIdentity.arn LIKE 'arn:aws:sts:: <YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

+ AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY DATE(eventTime)

+ ```

+ - List the number of overall API calls by Defender for Cloud aggregated by event name:

+ ```sql

+ SELECT eventName, COUNT(*) AS apiCallsCountByEventName FROM <TABLE-NAME>

+ WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

+ AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY eventName

+ ```

+ - List the number of overall API calls by Defender for Cloud aggregated by region:

+ ```sql

+ SELECT awsRegion, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME>

+ WHERE userIdentity.arn LIKE 'arn:aws:sts::120589537074:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

+ AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY awsRegion

+ ```

+ - The TABLE-NAME is Athena table or Event data store ID

+Defender API calls to GCP:

+When you onboard your GCP single project or organization, our Discovery service initiates an immediate scan of your environment by executing API calls to various service endpoints in order to retrieve all resources that we secure.

+Following this initial scan, the service will continue to periodically scan your environment at the interval that you configured during onboarding.

+**Getting the number of native API calls executed by Defender for Cloud**:

+ 1. Go to **Logging** -> **Log Explorer**

+ 1. Filter the dates as you wish (for example, 1d)

+ 1. To show API calls executed by Defender for Cloud, run this query:

+ ```json

+ protoPayload.authenticationInfo.principalEmail : "microsoft-defender"

+ ```

+Refer to the histogram to see the number of calls over time.

+| [New version of Defender Agent for Defender for Containers](#new-version-of-defender-agent-for-defender-for-containers) | January 4, 2024 | February 2024 |

+## New version of Defender Agent for Defender for Containers

+**Announcement date: January 4, 2024**

+**Estimated date for change: February 2024**

+A new version of the [Defender Agent for Defender for Containers](tutorial-enable-containers-azure.md#deploy-the-defender-agent-in-azure) will be released in February 2024. It includes performance and security improvements, support for both AMD64 and ARM64 arch nodes (Linux only), and uses [Inspektor Gadget](https://www.inspektor-gadget.io/) as the process collection agent instead of Sysdig. The new version is only supported on Linux kernel versions 5.4 and higher, so if you have older versions of the Linux kernel, you'll need to upgrade. For more information, see [Supported host operating systems](support-matrix-defender-for-containers.md#supported-host-operating-systems).

+**Estimated date for change: May 2024**

+**Estimated date for change: January 2024**

+Backups on flexible servers are snapshot based. The first snapshot backup is scheduled immediately after a server is created. Snapshot backups are currently taken once daily. If none of the databases in the server receive any furhter modifications after the last snapshot backup is taken, snapshots backups are suspended until new modifications are made in any of the databases, point at which a new snapshot is immediately taken. **The first snapshot is a full backup and consecutive snapshots are differential backups.**

+During the geo-restore, the server configurations that can be changed include virtual network settings and the ability to remove geo-redundant backup from the restored server. Changing other server configurations -such as compute, storage, or pricing tier (Burstable, General Purpose, or Memory Optimized)- during geo-restore is not supported.

+ In the Azure portal, under **Monitoring**, select **Metrics**. In **Backup Storage Used**, you can monitor the total backup usage.

+| ResourceType | `FlexibleServers` |

+You don't need to assign the reservation to specific Azure Database for PostgreSQL servers. An already running Azure Database for PostgreSQL (or ones that are newly deployed) automatically get the benefit of reserved pricing. By purchasing a reservation, you're prepaying for the compute costs for one or three years. As soon as you buy a reservation, the Azure database for PostgreSQL compute charges that match the reservation attributes are no longer charged at the pay-as-you go rates. A reservation doesn't cover software, networking, or storage charges associated with the PostgreSQL Database servers. At the end of the reservation term, the billing benefit expires, and the vCores used by Azure Database for PostgreSQL are billed at the pay-as-you go price. Reservations don't autorenew. For pricing information, see the [Azure Database for PostgreSQL reserved capacity offering](https://azure.microsoft.com/pricing/details/postgresql/). </br>

+For details on how enterprise customers and Pay-As-You-Go customers are charged for reservation purchases, see [understand Azure reservation usage for your Enterprise enrollment](../../cost-management-billing/reservations/understand-reserved-instance-usage-ea.md) and [understand Azure reservation usage for your Pay-As-You-Go subscription](../../cost-management-billing/reservations/understand-reserved-instance-usage.md).

+You may save up to 65% on compute costs with reserved instances. In order to find the discount for your case, visit the [Reservation blade on the Azure portal](https://aka.ms/reservations) and check the savings per pricing tier and per region. Reserved instances help you manage your workloads, budget, and forecast better with an upfront payment for a one-year or three-year term. You can also exchange or cancel reservations as business needs change.

+The size of reservation should be based on total amount of compute used by the existing, or soon-to-be-deployed, servers within a specific region, and using the same performance tier and hardware generation.</br>

+For example, let's suppose that you're running one general purpose Gen5 ΓÇô 32 vCore PostgreSQL database, and two memory-optimized Gen5 ΓÇô 16 vCore PostgreSQL databases. Further, let's suppose that you plan to deploy an additional general purpose Gen5 ΓÇô 8 vCore database server, and one memory-optimized Gen5 ΓÇô 32 vCore database server within the next month. Let's suppose that you know that you need these resources for at least one year. In this case, you should purchase a 40 (32 + 8) vCores, one-year reservation for single database general purpose - Gen5 and a 64 (2x16 + 32) vCore one year reservation for single database memory optimized - Gen5.

+3. Select **Add** and then, in the Purchase reservations pane, select **Azure Database for PostgreSQL** to purchase a new reservation for your PostgreSQL databases.

+| Term | This term can be either One year or Three years.

+| Quantity | The amount of compute resources being purchased within the Azure Database for PostgreSQL reserved capacity reservation. Corresponds to the number of vCores in the selected Azure region and Performance tier that are being reserved and get the billing discount. For example, if you're running or planning to run an Azure Database for PostgreSQL servers with the total compute capacity of Gen5 16 vCores in the East US region, then you would specify quantity as 16 to maximize the benefit for all servers.

+vCore size flexibility helps you scale up or down within a performance tier and region, without losing the reserved capacity benefit. If you scale to higher vCores than your reserved capacity, you're billed for the excess vCores using pay-as-you-go pricing.

+You can view your reserved instance purchase details via the [Reservations](https://aka.ms/reservations) blade in the Azure portal.

+You receive email notifications, first one 30 days prior to reservation expiry and another one at expiration. Once the reservation expires, deployed VMs continue to run and are billed at a pay-as-you-go rate.

+If you see an error similar to the following error when running the deployment:

+You can either add the IP of the environment from which you're executing the deployment (recommended) or you can allow public access to the key vault. For more information about controlling access to the key vault, see [Allow public access to a key vault](/azure/key-vault/general/network-security#allow-public-access-to-a-key-vault).

+### Failed to get existing workspaces error

+If you see an error similar to the following error when running the deployment:

+```text

+Error: : Error retrieving keys for Storage Account "mgmtweeutfstate###": azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to

+https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MGMT-WEEU-SAP_LIBRARY/providers/Microsoft.Storage/storageAccounts/mgmtweeutfstate###/listKeys?api-version=2021-01-01

+: StatusCode=400 -- Original Error: adal: Refresh request failed. Status Code = '400'. Response body: {"error":"invalid_request","error_description":"Identity not found"} Endpoint

+http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy&resource=https%3A%2F%2Fmanagement.azure.com%2F

+```

+This error indicates that the credentials used to do the deployment doesn't have access to the storage account. To resolve this issue, assign the 'Storage Account Contributor' role to the deployment credential on the terraform state storage account, the resource group or the subscription (if feasible).

+You can verify if the deployment is being performed using a service principal or a managed identity by checking the output of the deployment. If the deployment is using a service principal, the output contains the following section:

+```text

+ [set_executing_user_environment_variables]: Identifying the executing user and client

+ [set_azure_cloud_environment]: Identifying the executing cloud environment

+ [set_azure_cloud_environment]: Azure cloud environment: public

+ [set_executing_user_environment_variables]: User type: servicePrincipal

+ [set_executing_user_environment_variables]: client id: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

+ [set_executing_user_environment_variables]: Identified login type as 'service principal'

+ [set_executing_user_environment_variables]: Initializing state with SPN named: <SPN Name>

+ [set_executing_user_environment_variables]: exporting environment variables

+ [set_executing_user_environment_variables]: ARM environment variables:

+ ARM_CLIENT_ID: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

+ ARM_SUBSCRIPTION_ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

+ ARM_USE_MSI: false

+```

+Look for the following line in the output: "ARM_USE_MSI: false"

+If the deployment is using a managed identity, the output contains the following section:

+```text

+ [set_executing_user_environment_variables]: Identifying the executing user and client

+ [set_azure_cloud_environment]: Identifying the executing cloud environment

+ [set_azure_cloud_environment]: Azure cloud environment: public

+ [set_executing_user_environment_variables]: User type: servicePrincipal

+ [set_executing_user_environment_variables]: client id: systemAssignedIdentity

+ [set_executing_user_environment_variables]: logged in using 'servicePrincipal'

+ [set_executing_user_environment_variables]: unset ARM_CLIENT_SECRET

+ [set_executing_user_environment_variables]: ARM environment variables:

+ ARM_CLIENT_ID: zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz

+ ARM_SUBSCRIPTION_ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

+ ARM_USE_MSI: true

+```

+Look for the following line in the output: "ARM_USE_MSI: true"

+You can assign the 'Storage Account Contributor' role to the deployment credential on the terraform state storage account, the resource group or the subscription (if feasible). Use the ARM_CLIENT_ID from the deployment output.

+```cloudshell-interactive

+export appId="<ARM_CLIENT_ID>"

+az role assignment create --assignee ${appId} \

+ --role "Storage Account Contributor" \

+ --scope /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MGMT-WEEU-SAP_LIBRARY/providers/Microsoft.Storage/storageAccounts/mgmtweeutfstate###

+```

+You may also need to assign the reader role to the deployment credential on the subscription containing the resource group with the Terraform state file. You can do that with the following command:

+```cloudshell-interactive

+export appId="<ARM_CLIENT_ID>"

+az role assignment create --assignee ${appId} \

+ --role "Reader" \

+ --scope /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

+```

+### Private DNS Zone Name 'xxx' wasn't found

+If you see an error similar to the following error when running the deployment:

+```text

+Private DNS Zone Name: "privatelink.file.core.windows.net" was not found

+or

+Private DNS Zone Name: "privatelink.blob.core.windows.net" was not found

+or

+Private DNS Zone Name: "privatelink.vaultcore.azure.net" was not found

+```

+This error indicates that the Private DNS zone listed in the error isn't available. You can resolve this issue by either creating the Private DNS or providing the configuration for an existing private DNS Zone. For more information on how to create the Private DNS Zone, see [Create a private DNS zone](/azure/dns/private-dns-getstarted-cli#create-a-private-dns-zone).

+You can specify the details for an existing private DNS zone by using the following variables:

+```terraform

+# Resource group name for resource group that contains the private DNS zone

+management_dns_resourcegroup_name="<resource group name for the Private DNS Zone>"

+# Subscription ID name for resource group that contains the private DNS zone

+management_dns_subscription_id="<subscription id for resource group name for the Private DNS Zone>"

+use_custom_dns_a_registration=false

+```

+Rerun the deployment after you made these changes.

+If you see an error similar to the following error when running the deployment:

+This error indicates that the version of Ansible installed on the agent doesn't support this task. To resolve this issue, upgrade to the latest version of Ansible on the agent virtual machine.

+This error indicates that the configured personal access token doesn't have permissions to access the variable group. Ensure that the personal access token has the **Read & manage** permission for the variable group and that it's still valid. The personal access token is configured in the Azure DevOps pipeline variable groups either as 'PAT' in the control plane variable group or as 'WZ_PAT' in the workload zone variable group.

+ Title: Microsoft Sentinel feature support for Azure commercial/other clouds

+# Microsoft Sentinel feature support for Azure commercial/other clouds

+> Microsoft Sentinel solution for SAP® applications uses the new *systemconfig.json* file for agent versions released on or after June 22, 2023. For previous agent versions, you must still use the *[systemconfig.ini file](reference-systemconfig.md)*.

+> Microsoft Sentinel solution for SAP® applications uses the new *[systemconfig.json file](reference-systemconfig-json.md)* for agent versions released on or after June 22, 2023. For previous agent versions, you must still use the *systemconfig.ini* file.