-| Firefox | ✅ | ❌ | ❌ |

- > The PDF can only be downloaded for one Authorization System at a time. If more than one Authorization System is selected, the **Export PDF** button will be disabled.

-4. To download the report in PDF format, click on **Export PDF**.

- Once the PDF is generated, the report is automatically sent to your email.

-| Huawei (API 26) | pass² | pass | fail | pass | pass | pass |

-| Oppo | pass | not applicable³ | not applicable | not applicable | not applicable | not applicable |

-²Huawei's built-in browser is Huawei Browser.<br/>

-³The default browser can't be changed inside the Oppo device setting.

-## View and filter your devices (preview)

-In this preview, you have the ability to infinitely scroll, reorder columns, and select all devices. You can filter the device list by these device attributes:

-To enable the preview in the **All devices** view:

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Global Reader](../roles/permissions-reference.md#global-reader).

-1. Browse to **Identity** > **Devices** > **All devices**.

-1. Select the **Preview features** button.

-1. Turn on the toggle that says **Enhanced devices list experience**. Select **Apply**.

-1. Refresh your browser.

-You can now experience the enhanced **All devices** view.

-Here's an example that shows how to use PowerShell to add a user to the Guest Inviter role:

-```

-Add-MsolRoleMember -RoleObjectId 95e79109-95c0-4d8e-aee3-d01accf2d47b -RoleMemberEmailAddress <RoleMemberEmailAddress>

-For more information, see: [Manage devices in Azure AD using the Azure portal](../devices/manage-device-identities.md#view-and-filter-your-devices-preview).

-

- You can identity roles, permissions, and role assignments that are privileged by looking for the **PRIVILEGED** label. For more information, see [Privileged roles and permissions in Microsoft Entra ID](privileged-roles-permissions.md).

- |name.givenName|String||

- |externalId|String||

- * (Recommended) Select **Automatic updates** to give Microsoft Entra ID Governance over data capture and permission settings in Gong.

-Azure OpenAI Service supports Azure role-based access control (Azure RBAC), an authorization system for managing individual access to Azure resources. Using Azure RBAC, you assign different team members different levels of permissions based on their needs for a given project. For more information, see the [Azure RBAC documentation](../../../role-based-access-control/index.yml) for more information.

-description: This article shows you how to create an Azure AI Translator resource.

-In this article, you learn how to create a Translator resource in the Azure portal. [Azure AI Translator](translator-overview.md) is a cloud-based machine translation service that is part of the [Azure AI services](../what-are-ai-services.md) family. Azure resources are instances of services that you create. All API requests to Azure AI services require an **endpoint** URL and a read-only **key** for authenticating access.

-To get started, you need an active [**Azure account**](https://azure.microsoft.com/free/cognitive-services/). If you don't have one, you can [**create a free 12-month subscription**](https://azure.microsoft.com/free/).

-The Translator service can be accessed through two different resource types:

-* [**Multi-service**](https://portal.azure.com/#create/Microsoft.CognitiveServicesAllInOne) resource types enable access to multiple Azure AI services using a single API key and endpoint.

-1. **Name**. Enter the name you have chosen for your resource. The name you choose must be unique within Azure.

- > If you are using a Translator feature that requires a custom domain endpoint, such as Document Translation, the value that you enter in the Name field will be the custom domain name parameter for the endpoint.

- * Only one free tier is available per subscription.

- * Document Translation is supported in paid tiers. The Language Studio only supports the S1 or D3 instance tiers. We suggest you select the Standard S1 instance tier to try Document Translation.

-1. If you've created a multi-service resource, you need to confirm more usage details via the check boxes.

-1. Review the service terms and select **Create** to deploy your resource.

-* **Endpoint URL**. Use the Global endpoint in your API request unless you need a specific Azure region or custom endpoint. *See* [Base URLs](reference/v3-0-reference.md#base-urls). The Global endpoint URL is `api.cognitive.microsofttranslator.com`.

-1. After your new resource deploys, select **Go to resource** or navigate directly to your resource page.

-1. In the left rail, under *Resource Management*, select **Keys and Endpoint**.

-1. Copy and paste your keys and endpoint URL in a convenient location, such as *Microsoft Notepad*.

-To remove an Azure AI multi-service or Translator resource, you can **delete the resource** or **delete the resource group**.

-1. Navigate to your Resource Group in the Azure portal.

-1. Type *yes* in the **Deleted Resources** dialog box.

-1. Navigate to your Resource Group in the Azure portal.

-1. Select the **Delete resource group** from the top menu bar near the left edge.

-## How to get started with Translator

-## More resources

-* [Microsoft Translator code samples](https://github.com/MicrosoftTranslator). Multi-language Translator code samples are available on GitHub.

-# Auto-upgrade Azure Kubernetes Service cluster node OS images

-| `Unmanaged`|OS driven security updates. AKS has no control over these updates|Nightly around 6AM UTC for Ubuntu and Mariner, Windows every month.|

-| `SecurityPatch`|AKS|Weekly|

-| `NodeImage`|AKS|Weekly|

-## Is Kubernetes different on Windows and Linux?

-Windows Server node pool support includes some limitations that are part of the upstream Windows Server in Kubernetes project. These limitations are not specific to AKS. For more information on the upstream support from the Kubernetes project, see the [Supported functionality and limitations][upstream-limitations] section of the [Intro to Windows support in Kubernetes][intro-windows] document.

-Historically, Kubernetes is Linux-focused. Many examples used in the upstream [Kubernetes.io][kubernetes] website are intended for use on Linux nodes. When you create deployments that use Windows Server containers, the following considerations at the OS level apply:

- Windows Server uses a larger binary security identifier (SID) that's stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers.

- In pod specs that mount volumes, specify the path correctly for Windows Server containers. For example, rather than a mount point of */mnt/volume* in a Linux container, specify a drive letter and location such as */K/Volume* to mount as the *K:* drive.

-> * The Consumption tier isn't available in the US Government cloud or the Microsoft Azure operated by 21Vianet cloud.

-description: Follow this to tutorial to learn how to customize the API Management developer portal, an automatically generated, fully customizable website with the documentation of your APIs.

-1. Select the **Developer portal** button in the top navigation bar. A new browser tab with an administrative version of the portal will open.

-description: Learn how to set up and configure Azure API Management in a virtual network using internal mode

-# Connect to a virtual network in internal mode using Azure API Management

-With Azure virtual networks (VNets), Azure API Management can manage internet-inaccessible APIs using several VPN technologies to make the connection. For VNet connectivity options, requirements, and considerations, see [Using a virtual network with Azure API Management](virtual-network-concepts.md).

-For configurations specific to the *external* mode, where the API Management endpoints are accessible from the public internet, and backend services are located in the network, see [Connect to a virtual network using Azure API Management](api-management-using-with-vnet.md).

-description: Learn how to set up a connection to a virtual network in Azure API Management and access API backends through it.

-# Connect to a virtual network using Azure API Management

-Azure API Management can be deployed inside an Azure virtual network (VNet) to access backend services within the network. For VNet connectivity options, requirements, and considerations, see [Using a virtual network with Azure API Management](virtual-network-concepts.md).

-For configurations specific to the *internal* mode, where the endpoints are accessible only within the VNet, see [Connect to an internal virtual network using Azure API Management](./api-management-using-with-internal-vnet.md).

-The following table summarizes the compute platforms currently used for instances in the different API Management service tiers.

-description: Learn about scenarios and requirements to secure your API Management instance using an Azure virtual network.

-# Use a virtual network with Azure API Management

-API Management provides several options to secure access to your API Management instance and APIs using an Azure virtual network. API Management supports the following options, which are mutually exclusive:

-* **Integration (injection)** of the API Management instance into the virtual network, enabling the gateway to access resources in the network.

- You can choose one of two integration modes: *external* or *internal*. They differ in whether inbound connectivity to the gateway and other API Management endpoints is allowed from the internet or only from within the virtual network.

-* **Enabling secure and private inbound connectivity** to the API Management gateway using a *private endpoint*.

-|**[Virtual network - external](#virtual-network-integration)** | Developer, Premium | Developer portal, gateway, management plane, and Git repository | Inbound and outbound traffic can be allowed to internet, peered virtual networks, Express Route, and S2S VPN connections. | External access to private and on-premises backends

-|**[Virtual network - internal](#virtual-network-integration)** | Developer, Premium | Developer portal, gateway, management plane, and Git repository. | Inbound and outbound traffic can be allowed to peered virtual networks, Express Route, and S2S VPN connections. | Internal access to private and on-premises backends

-|**[Inbound private endpoint](#inbound-private-endpoint)** | Developer, Basic, Standard, Premium | Gateway only (managed gateway supported, self-hosted gateway not supported). | Only inbound traffic can be allowed from internet, peered virtual networks, Express Route, and S2S VPN connections. | Secure client connection to API Management gateway |

-## Virtual network integration

-With Azure virtual networks (VNets), you can place ("inject") your API Management instance in a non-internet-routable network to which you control access. In a virtual network, your API Management instance can securely access other networked Azure resources and also connect to on-premises networks using various VPN technologies. To learn more about Azure VNets, start with the information in the [Azure Virtual Network Overview](../virtual-network/virtual-networks-overview.md).

-* [Connect to an external virtual network using Azure API Management](./api-management-using-with-vnet.md).

-* [Connect to an internal virtual network using Azure API Management](./api-management-using-with-internal-vnet.md).

- :::image type="content" source="media/virtual-network-concepts/api-management-vnet-external.png" alt-text="Diagram showing a connection to external VNet." lightbox="media/virtual-network-concepts/api-management-vnet-external.png":::

-### Network resource requirements

-The following are virtual network resource requirements for API Management. Some requirements differ depending on the version (`stv2` or `stv1`) of the [compute platform](compute-infrastructure.md) hosting your API Management instance.

-For more information, see [Integrate API Management in an internal virtual network with Application Gateway](api-management-howto-integrate-internal-vnet-appgateway.md).

-* [Connect to an external virtual network using Azure API Management](./api-management-using-with-vnet.md).

-* [Connect to an internal virtual network using Azure API Management](./api-management-using-with-internal-vnet.md).

-In order to upgrade resource bridge, its status must be online and the [credentials in the appliance VM](maintenance.md#update-credentials-in-the-appliance-vm) must be valid.

-Arc resource bridge can be manually upgraded from the management machine. The management machine must have the kubeconfig and appliance configuration files stored locally. Manual upgrade generally takes between 30-90 minutes, depending on network speeds.

-For example: `az arcappliance upgrade vmware --config-file c:\contosoARB01-appliance.yaml`

-[Azure Arc VM management (preview) on Azure Stack HCI](/azure-stack/hci/manage/azure-arc-vm-management-overview) handles upgrades across all components as a "validated recipe" package, and upgrades are applied using the LCM tool. You must manually apply the packaged upgrade using the LCM tool.

-* Standard or datacenter license

-* Attest to the number of associated cores (broken down by the number of 2-core and 16-core packs).

-> In all cases, you are required to attest to their conformance with SA or SPLA. There is no exception for these requirements. Software Assurance or an equivalent Server Subscription is required for you to purchase Extended Security Updates on-premises and in hosted environments. You will be able to purchase Extended Security Updates from Enterprise Agreement (EA), Enterprise Subscription Agreement (EAS), a Server & Cloud Enrollment (SCE), and Enrollment for Education Solutions (EES). On Azure, you do not need Software Assurance to get free Extended Security Updates, but Software Assurance or Server Subscription is required to take advantage of the Azure Hybrid Benefit.

->

-### Network Security Group rules for subnets with private endpoints

-Currently, you can't configure [Network Security Group](../virtual-network/network-security-groups-overview.md) (NSG) rules and user-defined routes for private endpoints. NSG rules applied to the subnet hosting the private endpoint are applied to the private endpoint. A limited workaround for this issue is to implement your access rules for private endpoints on the source subnets, though this approach may require a higher management overhead.

-### Network Security Group rules for subnets with private endpoints

-Currently, you can't configure [Network Security Group](../virtual-network/network-security-groups-overview.md) (NSG) rules and user-defined routes for private endpoints. NSG rules applied to the subnet hosting the private endpoint are applied to the private endpoint. A limited workaround for this issue is to implement your access rules for private endpoints on the source subnets, though this approach may require a higher management overhead.

-**Maximum backup frequency to vault** | **On-premises Windows machines or Azure VMs running MARS:** Three per day<br/><br/> **DPM/MABS:** Two per day<br/><br/> **Azure VM backup:** One per day

-This document details how to use Bash and PowerShell in Azure Cloud Shell from the

-[Azure portal][03].

-### Registering your subscription with Azure Cloud Shell

-Azure Cloud Shell needs access to manage resources. Access is provided through namespaces that must

-be registered to your subscription. Use the following commands to register the

-**Microsoft.CloudShell** namespace in your subscription:

-<!-- markdownlint-disable MD023 -->

-<!-- markdownlint-disable MD024 -->

-<!-- markdownlint-disable MD051 -->

-#### [Azure CLI](#tab/azurecli)

-```azurecli-interactive

-az account set --subscription <Subscription Name or Id>

-az provider register --namespace Microsoft.CloudShell

-```

-#### [Azure PowerShell](#tab/powershell)

-```azurepowershell-interactive

-Select-AzSubscription -SubscriptionId <SubscriptionId>

-Register-AzResourceProvider -ProviderNamespace Microsoft.CloudShell

-```

-<!-- markdownlint-enable MD023 -->

-<!-- markdownlint-enable MD024 -->

-<!-- markdownlint-enable MD051 -->

-> [!NOTE]

-> You only need to register the namespace once per subscription.

-<!-- markdownlint-disable MD023 -->

-<!-- markdownlint-disable MD024 -->

-<!-- markdownlint-disable MD051 -->

-<!-- markdownlint-enable MD023 -->

-<!-- markdownlint-enable MD024 -->

-<!-- markdownlint-enable MD051 -->

-

-<!-- markdownlint-disable MD023 -->

-<!-- markdownlint-disable MD024 -->

-<!-- markdownlint-disable MD051 -->

-<!-- markdownlint-enable MD023 -->

-<!-- markdownlint-enable MD024 -->

-<!-- markdownlint-enable MD051 -->

-<!-- markdownlint-disable MD023 -->

-<!-- markdownlint-disable MD024-->

-<!-- markdownlint-disable MD051 -->

-<!-- markdownlint-enable MD023 -->

-<!-- markdownlint-enable MD024 -->

-<!-- markdownlint-enable MD051 -->

-description: This article helps you to get started with Cost Management + Billing to understand, report on, and analyze your invoiced Microsoft Cloud and AWS costs.

-# Get started with Cost Management + Billing reporting

-Cost Management + Billing includes several tools to help you understand, report on, and analyze your invoiced Microsoft Cloud and AWS costs. The following sections describe the major reporting components.

- > To create or modify a custom event trigger in Data Factory, you need to use an Azure account with appropriate role-based access control (Azure RBAC). No additional permission is required. The Data Factory service principle does *not* require special permission to your Event Grid. For more information about access control, see the [Role-based access control](#role-based-access-control) section.

- | [Running container images should have vulnerability findings resolved (powered by Qualys)](https://ms.portal.azure.com/#view/Microsoft_Azure_Security_CloudNativeCompute/KubernetesRuntimeVisibilityRecommendationDetailsBlade/assessmentKey/41503391-efa5-47ee-9282-4eff6131462c)ΓÇ»| Container image vulnerability assessment scans container images running on your Kubernetes clusters for security vulnerabilities and exposes detailed findings for each image. Resolving the vulnerabilities can greatly improve your containers' security posture and protect them from attacks. | 41503391-efa5-47ee-9282-4eff6131462c/ |

-> The information on this page relates to pre-release products or features, which may be substantially modified before they are commercially released, if ever. Microsoft makes no commitments or warranties, express or implied, with respect to the information provided here.

-| [Changes to the Defender for DevOps recommendations environment source and resource ID](#changes-to-the-defender-for-devops-recommendations-environment-source-and-resource-id) | August 2023 |

-| [Deprecate and replace recommendations App Service Client Certificates](#deprecate-and-replace-recommendations-app-service-client-certificates) | August 2023 |

-| [Replacing secret scanning recommendation results in Defender for DevOps from CredScan with GitHub Advanced Security for Azure DevOps powered secret scanning](#replacing-secret-scanning-recommendation-results-in-defender-for-devops-from-credscan-with-github-advanced-security-for-azure-devops-powered-secret-scanning) | September 2023 |

-| [Deprecating and replacing "Microsoft Defender for Storage plan should be enabled" recommendation](#deprecating-and-replacing-microsoft-defender-for-storage-plan-should-be-enabled-recommendation) | September 2023|

-| [DevOps Resource Deduplication for Defender for DevOps](#devops-resource-deduplication-for-defender-for-devops) | September 2023 |

-### Replacing secret scanning recommendation results in Defender for DevOps from CredScan with GitHub Advanced Security for Azure DevOps powered secret scanning

-**Estimated date for change: September 2023**

-Currently, the recommendations for secret scanning in Azure DevOps repositories by Defender for DevOps are based on the results of CredScan, which is manually run using the Microsoft Security DevOps Extension. However, this mechanism of running secret scanning is being deprecated in September 2023. Instead, you can see secret scanning results generated by GitHub Advanced Security for Azure DevOps (GHAzDO).

-As GHAzDO enters Public Preview, we're working towards unifying the secret scanning experience across both GitHub Advanced Security and GHAzDO. This unification enables you to receive detections across all branches, git history, and secret leak protection via push protection to your repositories. This process can all be done with a single button press, without requiring any pipeline runs.

-For more information about GHAzDO Secret Scanning, see [Set up secret scanning](/azure/devops/repos/security/configure-github-advanced-security-features#set-up-secret-scanning).

-### Defender for Cloud plan and strategy for the Log Analytics agent deprecation

-**Estimated date for change: August 2024**

-The Azure Log Analytics agent, also known as the Microsoft Monitoring Agent (MMA) will be [retired in August 2024.](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/) As a result, features of the two Defender for Cloud plans that rely on the Log Analytics agent are impacted, and they have updated strategies: [Defender for Servers](#defender-for-servers) and [Defender for SQL Server on machines](#defender-for-sql-server-on-machines).

-||Azure Monitor agent (AMA) required (for Defender for SQL or other scenarios)|FIM/EPP discovery/Baselined is required as part of Defender for Server|What should I do|

-| -- | -- | -- | -- |

-| |No |Yes |You can remove MMA starting April 2024, using GA version of Defender for Server capabilities according to your needs (preview versions will be available earlier)  |

-| |No |No |You can remove MMA starting now |

-| |Yes |No |You can start migration from MMA to AMA now |

-| |Yes |Yes |You can either start migration from MMA to AMA starting April 2024 or alternatively, you can use both agents side by side starting now. |

-### Replacing the "Key Vaults should have purge protection enabled" recommendation with combined recommendation "Key Vaults should have deletion protection enabled"

-**Estimated date for change: June 2023**

-The `Key Vaults should have purge protection enabled` recommendation is deprecated from the (regulatory compliance dashboard/Azure security benchmark initiative) and replaced with a new combined recommendation `Key Vaults should have deletion protection enabled`.

-| Recommendation name | Description | Effect(s) | Version |

-|--|--|--|--|

-| [Key vaults should have deletion protection enabled](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0b60c0b2-2dc2-4e1c-b5c9-abbed971de53)| A malicious insider in your organization can potentially delete and purge key vaults. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Microsoft will be able to purge your key vaults during the soft delete retention period. | audit, deny, disabled | [2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/KeyVault_Recoverable_Audit.json) |

-See the [full index of Azure Policy built-in policy definitions for Key Vault](../key-vault/policy-reference.md)

-### Changes to the Defender for DevOps recommendations environment source and resource ID

-**Estimated date for change: August 2023**

-The Security DevOps recommendations will be updated to align with the overall Microsoft Defender for Cloud features and experience. Affected recommendations will point to a new recommendation source environment and have an updated resource ID.

-Security DevOps recommendations impacted:

-The recommendation environment source will be updated from `Azure` to `AzureDevOps` or `GitHub`.

-The format for resource IDs will be changed from:

-`Microsoft.SecurityDevOps/githubConnectors/owners/repos/`

-To:

-`Microsoft.Security/securityConnectors/devops/azureDevOpsOrgs/projects/repos`

-`Microsoft.Security/securityConnectors/devops/gitHubOwners/repos`

-As a part of the migration, source code management system specific recommendations will be created for security findings:

-Customers that rely on the `resourceID` to query DevOps recommendation data will be affected. For example, Azure Resource Graph queries, workbooks queries, API calls to Microsoft Defender for Cloud.

-Queries will need to be updated to include both the old and new `resourceID` to show both, for example, total over time.

-Additionally, customers that have created custom queries using the DevOps workbook will need to update the assessment keys for the impacted DevOps security recommendations. The template DevOps workbook is planned to be updated to reflect the new recommendations, although during the actual migration, customers may experience some errors with the workbook.

-The experience on the recommendations page will be impacted and require customers to query under "All recommendations" to view the new DevOps recommendations. For Azure DevOps, deprecated assessments may continue to show for a maximum of 14 days if new pipelines are not run. Refer to [Defender for DevOps Common questions](/azure/defender-for-cloud/faq-defender-for-devops#why-don-t-i-see-recommendations-for-findings-) for details.

-### Preview alerts for DNS servers to be deprecated

-**Estimated date for change: August 2023**

-Following quality improvement process, security alerts for DNS servers are set to be deprecated in August. For cloud resources, use [Azure DNS](defender-for-dns-introduction.md) to receive the same security value.

-The following table lists the alerts to be deprecated:

-| AlertDisplayName | AlertType |

-|--|--|

-| Communication with suspicious random domain name (Preview) | DNS_RandomizedDomain

-| Communication with suspicious domain identified by threat intelligence (Preview) | DNS_ThreatIntelSuspectDomain |

-| Digital currency mining activity (Preview) | DNS_CurrencyMining |

-| Network intrusion detection signature activation (Preview) | DNS_SuspiciousDomain |

-| Attempted communication with suspicious sinkholed domain (Preview) | DNS_SinkholedDomain |

-| Communication with possible phishing domain (Preview) | DNS_PhishingDomain|

-| Possible data transfer via DNS tunnel (Preview) | DNS_DataObfuscation |

-| Possible data exfiltration via DNS tunnel (Preview) | DNS_DataExfiltration |

-| Communication with suspicious algorithmically generated domain (Preview) | DNS_DomainGenerationAlgorithm |

-| Possible data download via DNS tunnel (Preview) | DNS_DataInfiltration |

-| Anonymity network activity (Preview) | DNS_DarkWeb |

-| Anonymity network activity using web proxy (Preview) | DNS_DarkWebProxy |

-### Deprecate and replace recommendations App Service Client Certificates

-**Estimated date for change: August 2023**

-App Service policies are set to be deprecated and replaced so that they only monitor apps using HTTP 1.1 since HTTP 2.0 on App Service doesn't support client certificates. The existing policies that enforce client certificates require an additional check to determine if Http 2.0 is being used by the app. Adding this additional check requires a change to the policy "effect" from Audit to AuditIfNotExists. Policy "effect" changes require deprecation of the old version of the policy and the creation of a replacement.

-Policies in this scope:

-Customers who are currently using this policy will need to ensure they have the new policies with similar names enabled and assigned to their intended scope.

-### Change to the Log Analytics daily cap

-Azure monitor offers the capability to [set a daily cap](../azure-monitor/logs/daily-cap.md) on the data that is ingested on your Log analytics workspaces. However, Defender for Cloud security events are currently not supported in those exclusions.

-Starting on September 18, 2023 the Log Analytics Daily Cap will no longer exclude the following set of data types:

-At that time, all billable data types will be capped if the daily cap is met. This change improves your ability to fully contain costs from higher-than-expected data ingestion.

-Learn more about [workspaces with Microsoft Defender for Cloud](../azure-monitor/logs/daily-cap.md#workspaces-with-microsoft-defender-for-cloud).

-## Deprecating and replacing "Microsoft Defender for Storage plan should be enabled" recommendation

-**Estimated date for change: September 2023**

-The recommendation `Microsoft Defender for Storage plan should be enabled` will be deprecated on public clouds and will remain available on Azure Government cloud. This recommendation will be replaced by a new recommendation: `Microsoft Defender for Storage plan should be enabled with Malware Scanning and Sensitive Data Threat Detection`. This recommendation ensures that Defender for Storage is enabled at the subscription level with malware scanning and sensitive data threat detection capabilities.

-| Policy Name | Description | Policy Effect | Version |

-|--|--|--|--|

-| [Microsoft Defender for Storage should be enabled](https://ms.portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2fproviders%2fMicrosoft.Authorization%2fpolicyDefinitions%2f640d2586-54d2-465f-877f-9ffc1d2109f4) | Microsoft Defender for Storage detects potential threats to your storage accounts. It helps prevent the three major impacts on your data and workload: malicious file uploads, sensitive data exfiltration, and data corruption. The new Defender for Storage plan includes malware scanning and sensitive data threat detection.This plan also provides a predictable pricing structure (per storage account) for control over coverage and costs. | Audit, disabled | 1.0.0 |

-Learn more about [Microsoft Defender for Storage](defender-for-storage-introduction.md).

-### DevOps Resource Deduplication for Defender for DevOps

-**Estimated date for change: September 2023**

-To improve the Defender for DevOps user experience and enable further integration with Defender for Cloud's rich set of capabilities, Defender for DevOps will no longer support duplicate instances of a DevOps organization to be onboarded to an Azure tenant.

-If you don't have an instance of a DevOps organization onboarded more than once to your organization, no further action is required. If you do have more than one instance of a DevOps organization onboarded to your tenant, the subscription owner will be notified and will need to delete the DevOps Connector(s) they don't want to keep by navigating to Defender for Cloud Environment Settings.

-Customers will have until September 30, 2023 to resolve this issue. After this date, only the most recent DevOps Connector created where an instance of the DevOps organization exists will remain onboarded to Defender for DevOps. For example, if Organization Contoso exists in both connectorA and connectorB, and connectorB was created after connectorA, then connectorA will be removed from Defender for DevOps.

-An event domain is a management tool for large number of Event Grid topics related to the same application. You can think of it as a meta-topic that can have thousands of individual topics. It allows an event publisher to publish events to thousands of topics at the same time. Domains also give you authentication and authorization control over each topic so you can partition your tenants. This article describes how to use event domains to manage the flow of custom events to your various business organizations, customers, or applications. Use event domains to:

-Event domains also allow for domain-scope subscriptions. An event subscription on an event domain will receive all events sent to the domain regardless of the topic the events are sent to. Domain scope subscriptions can be useful for management and auditing purposes.

-When you create an event domain, you're given a publishing endpoint similar to if you had created a topic in Event Grid. To publish events to any topic in an event domain, push the events to the domain's endpoint the [same way you would for a custom topic](./post-to-custom-topic.md). The only difference is that you must specify the topic you'd like the event to be delivered to. For example, publishing the following array of events would send event with `"id": "1111"` to topic `foo` while the event with `"id": "2222"` would be sent to topic `bar`:

-1. On the **Create topic space** page, enter a name for the topic space.

-description: Learn about Azure Event Hubs, a Big Data streaming service that ingests millions of events per second.

-# What is Azure Event Hubs? ΓÇö A big data streaming platform and event ingestion service

-Event Hubs is a modern big data streaming platform and event ingestion service that can seamlessly integrate with other Azure and Microsoft services, such as Stream Analytics, Power BI, and Event Grid, along with outside services like Apache Spark. The service can process millions of events per second with low latency. The data sent to an event hub (Event Hubs instance) can be transformed and stored by using any real-time analytics providers or batching or storage adapters.

-## Why use Event Hubs?

-Data is valuable only when there's an easy way to process and get timely insights from data sources. Event Hubs provides a distributed stream processing platform with low latency and seamless integration, with data and analytics services inside and outside Azure to build your complete big data pipeline.

-Event Hubs represents the "front door" for an event pipeline, often called an **event ingestor** in solution architectures. An event ingestor is a component or service that sits between event publishers and event consumers to decouple the production of events from the consumption of those events. Event Hubs provides a unified streaming platform with time retention buffer, decoupling event producers from event consumers.

-The following sections describe key features of the Azure Event Hubs service:

-## Fully managed PaaS

-Event Hubs is a fully managed Platform-as-a-Service (PaaS) with little configuration or management overhead, so you focus on your business solutions. [Event Hubs for Apache Kafka ecosystems](azure-event-hubs-kafka-overview.md) gives you the PaaS Kafka experience without having to manage, configure, or run your clusters.

-## Event Hubs for Apache Kafka

-Azure Event Hubs for Apache Kafka ecosystems enables [Apache Kafka (1.0 and later)](https://kafka.apache.org/) clients and applications to talk to Event Hubs. You don't need to set up, configure, and manage your own Kafka and Zookeeper clusters or use some Kafka-as-a-Service offering not native to Azure. For more information, see [Event Hubs for Apache Kafka ecosystems](azure-event-hubs-kafka-overview.md).

-## Schema Registry in Azure Event Hubs

-Schema Registry in Event Hubs provides a centralized repository for managing schemas of events streaming applications. Azure Schema Registry comes free with every Event Hubs namespace, and it integrates seamlessly with your Kafka applications or Event Hubs SDK based applications.

-It ensures data compatibility and consistency across event producers and consumers, enabling seamless schema evolution, validation, and governance, and promoting efficient data exchange and interoperability. For more information, see [Schema Registry in Azure Event Hubs](schema-registry-overview.md).

-## Support for real-time and batch processing

-Ingest, buffer, store, and process your stream in real time to get actionable insights. Event Hubs uses a [partitioned consumer model](event-hubs-scalability.md#partitions), enabling multiple applications to process the stream concurrently and letting you control the speed of processing. Azure Event Hubs also integrates with [Azure Functions](../azure-functions/index.yml) for a serverless architecture.

-## Capture event data

-Capture your data in near-real time in an [Azure Blob storage](https://azure.microsoft.com/services/storage/blobs/) or [Azure Data Lake Storage](https://azure.microsoft.com/services/data-lake-store/) for long-term retention or micro-batch processing. You can achieve this behavior on the same stream you use for deriving real-time analytics. Setting up capture of event data is fast. There are no administrative costs to run it, and it scales automatically with Event Hubs [throughput units](event-hubs-scalability.md#throughput-units) or [processing units](event-hubs-scalability.md#processing-units). Event Hubs enables you to focus on data processing rather than on data capture. For more information, see [Event Hubs Capture](event-hubs-capture-overview.md).

-## Scalable

-With Event Hubs, you can start with data streams in megabytes, and grow to gigabytes or terabytes. The [Autoinflate](event-hubs-auto-inflate.md) feature is one of the many options available to scale the number of throughput units or processing units to meet your usage needs.

-## Rich ecosystem

-With a broad ecosystem available for the industry-standard AMQP 1.0 protocol and SDKs available in various languages: [.NET](https://github.com/Azure/azure-sdk-for-net/), [Java](https://github.com/Azure/azure-sdk-for-java/), [Python](https://github.com/Azure/azure-sdk-for-python/), [JavaScript](https://github.com/Azure/azure-sdk-for-js/), you can easily start processing your streams from Event Hubs. All supported client languages provide low-level integration. The ecosystem also provides you with seamless integration with Azure services like Azure Stream Analytics and Azure Functions and thus enables you to build serverless architectures.

-## Event Hubs premium and dedicated

-Event Hubs **premium** caters to high-end streaming needs that require superior performance, better isolation with predictable latency, and minimal interference in a managed multitenant PaaS environment. On top of all the features of the standard offering, the premium tier offers several extra features such as [dynamic partition scale up](dynamically-add-partitions.md), extended retention, and [customer-managed-keys](configure-customer-managed-key.md). For more information, see [Event Hubs Premium](event-hubs-premium-overview.md).

-Event Hubs **dedicated** tier offers single-tenant deployments for customers with the most demanding streaming needs. This single-tenant offering has a guaranteed 99.99% SLA and is available only on our dedicated pricing tier. An Event Hubs cluster can ingress millions of events per second with guaranteed capacity and subsecond latency. Namespaces and event hubs created within the dedicated cluster include all features of the premium offering and more. For more information, see [Event Hubs Dedicated](event-hubs-dedicated-overview.md).

-For more information, see [comparison between Event Hubs tiers](event-hubs-quotas.md).

-## Event Hubs on Azure Stack Hub

-The Event Hubs service on Azure Stack Hub allows you to realize hybrid cloud scenarios. Streaming and event-based solutions are supported for both on-premises and Azure cloud processing. Whether your scenario is hybrid (connected), or disconnected, your solution can support processing of events/streams at large scale. Your scenario is only bound by the Event Hubs cluster size, which you can provision according to your needs.

-The Event Hubs editions (on Azure Stack Hub and on Azure) offer a high degree of feature parity. This parity means SDKs, samples, PowerShell, CLI, and portals offer a similar experience, with few differences.

-For more information, see [Event Hubs on Azure Stack Hub overview](/azure-stack/user/event-hubs-overview).

-## Key architecture components

-Event Hubs contains the following key components.

-| Component | Description |

-| | -- |

-| Event producers | Any entity that sends data to an event hub. Event publishers can publish events using HTTPS or AMQP 1.0 or Apache Kafka (1.0 and higher). |

-| Partitions | Each consumer only reads a specific subset, or a partition, of the message stream. |

-| Consumer groups | A view (state, position, or offset) of an entire event hub. Consumer groups enable consuming applications to each have a separate view of the event stream. They read the stream independently at their own pace and with their own offsets. |

-| Event receivers | Any entity that reads event data from an event hub. All Event Hubs consumers connect via the AMQP 1.0 session. The Event Hubs service delivers events through a session as they become available. All Kafka consumers connect via the Kafka protocol 1.0 and later. |

-| [Throughput units (standard tier)](event-hubs-scalability.md#throughput-units) or [processing units (premium tier)](event-hubs-scalability.md#processing-units) or [capacity units (dedicated)](event-hubs-dedicated-overview.md) | Prepurchased units of capacity that control the throughput capacity of Event Hubs. |

-The following figure shows the Event Hubs stream processing architecture:

-

-> [!NOTE]

-> For more information, see [Event Hubs features or components](event-hubs-features.md).

-To get started using Event Hubs, see the **Send and receive events** tutorials:

-To learn more about Event Hubs, see the following articles: