# data[].attributes.attachment_link.readable_text
Azure offers many ways to host your application code. The term compute refers to the hosting model for the resources that your application runs on. This article helps choose a compute service for your application.

Use the following flowchart to select a candidate compute service.

This diagram refers to two migration strategies:

Lift and shift: A strategy for migrating a workload to the cloud without redesigning the application or making code changes. It's also called rehosting. For more information, see Azure migration and modernization center.

Cloud optimized: A strategy for migrating to the cloud by refactoring an application to take advantage of cloud-native features and capabilities.

The output from this flowchart is your starting point. Next, evaluate the service to see if it meets your needs.

This article includes several tables that can help you choose a service. The initial candidate from the flowchart might be unsuitable for your application or workload. In that case, expand your analysis to include other compute services.

If your application consists of multiple workloads, evaluate each workload separately. A complete solution can incorporate two or more compute services.

Understand the basic features

If you're not familiar with the Azure service selected in the previous section, see this overview documentation:

Azure Virtual Machines: A service where you deploy and manage virtual machines (VMs) inside an Azure virtual network.

Azure App Service: A managed service for hosting web apps, mobile app back ends, RESTful APIs, or automated business processes.

Azure Functions: A managed function as a service.

Azure Kubernetes Service (AKS): A managed Kubernetes service for running containerized applications.

Azure Container Apps: A managed service built on Kubernetes, which simplifies the deployment of containerized applications in a serverless environment.

Azure Container Instances: This service is a fast and simple way to run a container in Azure. You don't have to provision any VMs or adopt a higher-level service.

Azure Red Hat OpenShift: A fully managed OpenShift cluster for running containers in production with Kubernetes.

Azure Spring Apps: A managed service designed and optimized for hosting Spring Boot apps.

Azure Service Fabric: A distributed systems platform that can run in many environments, including Azure or on-premises.

Azure Batch: A managed service for running large-scale parallel and high-performance computing (HPC) applications.

Understand the hosting models

For hosting models, cloud services fall into three categories:

Infrastructure as a service (IaaS): Lets you provision VMs along with the associated networking and storage components. Then you can deploy whatever software and applications you want onto those VMs. This model is the closest to a traditional on-premises environment. Microsoft manages the infrastructure. You still manage the VMs.

Platform as a service (PaaS): Provides a managed hosting environment where you can deploy your application without needing to manage VMs or networking resources. Azure App Service and Azure Container Apps are PaaS services.

Functions as a service (FaaS): Lets you deploy your code to the service, which automatically runs it. Azure Functions is a FaaS service.

There's a spectrum from IaaS to pure PaaS. For example, Azure VMs can automatically scale by using virtual machine scale sets. This capability isn't strictly a PaaS, but it's the type of management feature found in PaaS.

There's a tradeoff between control and ease of management. IaaS gives the most control, flexibility, and portability, but you have to provision, configure, and manage the VMs and network components you create. FaaS services automatically manage nearly all aspects of running an application. PaaS falls somewhere in between.

Notes

1. If you're using a Consumption plan. For an App Service plan, functions run on the VMs allocated for your App Service plan. See Choose the correct service plan for Azure Functions.

2. Higher service-level agreement (SLA) with two or more instances.

3. Recommended for production environments.

4. Can scale down to zero after job completes.

5. Three for primary nodes and three for worker nodes.

6. When using Durable Functions.

Networking

Notes

1. Requires App Service Environment.

2. Use Azure App Service Hybrid Connections.

3. Requires App Service plan or Azure Functions Premium plan.

DevOps

Service

Local debugging

Programming model

Application update

Azure App Service

Web and API applications, WebJobs for background tasks

Deployment slots

Notes

Options include IIS Express for ASP.NET or node.js (iisnode), PHP web server, Azure Toolkit for IntelliJ, and Azure Toolkit for Eclipse. App Service also supports remote debugging of deployed web app.

Scalability

Azure Kubernetes Service

Azure Load Balancer or Azure Application Gateway

5,000 nodes when using Uptime SLA

Azure Container Apps

Integrated

5 environments per region, 20 container apps per environment, 30 replicas per container app

Notes

1. See Automatically scale a cluster to meet application demands on Azure Kubernetes Service.

2. See Azure subscription and service limits, quotas, and constraints.

3. See Set scaling rules in Azure Container Apps.

Availability

For guided learning on service guarantees, see Core Cloud Services - Azure architecture and service guarantees.

Security

Review and understand the available security controls and visibility for each service:

Other criteria

Consider limits and cost

Along with the previous comparison tables, do a more detailed evaluation of the following aspects of the candidate service:

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

Core Cloud Services - Azure compute options. This Learn module explores how compute services can solve common business needs.

# data[].attributes.attachment_link.title
Choose an Azure compute service - Azure Architecture Center

# data[].attributes.attachment_link.description
Use this chart and other information to decide which compute service, or hosting model for computing resources, best suits your application.

# data[].attributes.attachment_link.title
Phippy & Friends | Cloud Native Computing Foundation

# data[].attributes.attachment_link.description
Phippy is a simple PHP app, exploring the cloud native world with her friends. Are you a maintainer on a graduated project? Do you want to help others better understand the concepts of cloud native…

# data[].attributes.attachment_link.readable_text
This tutorial is part one of a series. In this tutorial, you learn how to deploy a web app. The web app uses the Azure Blob Storage client library to upload images to a storage account.

In part one of the series, you do the following tasks:

Create a storage account

Create a container and set permissions

Retrieve an access key

Deploy a web app to Azure

Configure app settings

Interact with the web app

Prerequisites

To complete this tutorial, you need an Azure subscription. Create a free account before you begin.

Azure Cloud Shell

Azure hosts Azure Cloud Shell, an interactive shell environment that you can use through your browser. You can use either Bash or PowerShell with Cloud Shell to work with Azure services. You can use the Cloud Shell preinstalled commands to run the code in this article, without having to install anything on your local environment.

To start Azure Cloud Shell:

Option

Example/Link

Select Try It in the upper-right corner of a code or command block. Selecting Try It doesn't automatically copy the code or command to Cloud Shell.

Go to https://shell.azure.com, or select the Launch Cloud Shell button to open Cloud Shell in your browser.

Select the Cloud Shell button on the menu bar at the upper right in the Azure portal.

To use Azure Cloud Shell:

1. Start Cloud Shell.

2. Select the Copy button on a code block (or command block) to copy the code or command.

3. Paste the code or command into the Cloud Shell session by selecting Ctrl+ Shift+ V on Windows and Linux, or by selecting Cmd+ Shift+ V on macOS.

4. Select Enter to run the code or command.

Create a resource group

Important

In step 2 of the tutorial, you use Azure Event Grid with the blob storage you create in this step. Create your storage account in an Azure region that supports Event Grid. For a list of supported regions, see Azure products by region.

1. In the Azure Cloud Shell, select Bash in the top-left corner if it's not already selected.

2. Create a resource group with the az group create command. An Azure resource group is a logical container into which Azure resources are deployed and managed.

Note

Set appropriate values for region and rgName (resource group name).

region="eastus" rgName="egridtutorialrg" az group create --name $rgName --location $region

1. In the Azure Cloud Shell, select PowerShell in the top-left corner if it's not already selected.

2. Create a resource group with the New-AzResourceGroup command. An Azure resource group is a logical container into which Azure resources are deployed and managed.

Note

Set appropriate values for region and rgName (resource group name).

$region="eastus" $rgName="egridtutorialrg" New-AzResourceGroup -Name $rgName -Location $region

Create a storage account

The sample uploads images to a blob container in an Azure storage account.

blobStorageAccount="myblobstorage$RANDOM" az storage account create --name $blobStorageAccount --location $region \ --resource-group $rgName --sku Standard_LRS --kind StorageV2 --access-tier hot --allow-blob-public-access true

$blobStorageAccount="myblobstorage" + (Get-Random).ToString() echo $blobStorageAccount New-AzStorageAccount -ResourceGroupName $rgName -Name $blobStorageAccount -SkuName Standard_LRS -Location $region -Kind StorageV2 -AccessTier Hot -AllowBlobPublicAccess $true

Create Blob storage containers

The app uses two containers in the Blob storage account. The images container is where the app uploads full-resolution images. In the second step of the series, an Azure function app uploads resized image thumbnails to the thumbnails container.

The images container's public access is set to off. The thumbnails container's public access is set to container. The container public access setting permits users who visit the web page to view the thumbnails.

blobStorageAccountKey=$(az storage account keys list -g $rgName \ -n $blobStorageAccount --query "[0].value" --output tsv) az storage container create --name images \ --account-name $blobStorageAccount \ --account-key $blobStorageAccountKey az storage container create --name thumbnails \ --account-name $blobStorageAccount \ --account-key $blobStorageAccountKey --public-access container

$blobStorageAccountKey = ((Get-AzStorageAccountKey -ResourceGroupName $rgName -Name $blobStorageAccount)| Where-Object {$_.KeyName -eq "key1"}).Value $blobStorageContext = New-AzStorageContext -StorageAccountName $blobStorageAccount -StorageAccountKey $blobStorageAccountKey New-AzStorageContainer -Name images -Context $blobStorageContext New-AzStorageContainer -Name thumbnails -Permission Container -Context $blobStorageContext

The sample app connects to the storage account using its name and access key.

Create an App Service plan

An App Service plan specifies the location, size, and features of the web server farm that hosts your app. The following example creates an App Service plan named myAppServicePlan in the Free pricing tier:

planName="MyAppServicePlan" az appservice plan create --name $planName --resource-group $rgName --sku Free

$planName="MyAppServicePlan" New-AzAppServicePlan -ResourceGroupName $rgName -Name $planName -Tier "Free" -Location $region

Create a web app

The web app provides a hosting space for the sample app code that's deployed from the GitHub sample repository.

webapp="mywebapp$RANDOM" az webapp create --name $webapp --resource-group $rgName --plan $planName

$webapp="MyWebApp" + (Get-Random).ToString() echo $webapp New-AzWebApp -ResourceGroupName $rgName -Name $webapp -AppServicePlan $planName

Deploy the sample app from the GitHub repository

App Service supports several ways to deploy content to a web app. In this tutorial, you deploy the web app from a public GitHub sample repository. Configure GitHub deployment to the web app with the az webapp deployment source config command.

The sample project contains an ASP.NET MVC app. The app accepts an image, saves it to a storage account, and displays images from a thumbnail container. The web app uses the Azure.Storage, Azure.Storage.Blobs, and Azure.Storage.Blobs.Models namespaces to interact with the Azure Storage service.

az webapp deployment source config --name $webapp --resource-group $rgName \ --branch master --manual-integration \ --repo-url https://github.com/Azure-Samples/storage-blob-upload-from-webapp

az webapp deployment source config --name $webapp --resource-group $rgName ` --branch master --manual-integration ` --repo-url https://github.com/Azure-Samples/storage-blob-upload-from-webapp

Configure web app settings

The sample web app uses the Azure Storage APIs for .NET to upload images. Storage account credentials are set in the app settings for the web app. Add app settings to the deployed app with the az webapp config appsettings set or New-AzStaticWebAppSetting command.

az webapp config appsettings set --name $webapp --resource-group $rgName \ --settings AzureStorageConfig__AccountName=$blobStorageAccount \ AzureStorageConfig__ImageContainer=images \ AzureStorageConfig__ThumbnailContainer=thumbnails \ AzureStorageConfig__AccountKey=$blobStorageAccountKey

Set-AzWebApp -ResourceGroupName $rgName -Name $webapp -AppSettings ` @{ ` 'AzureStorageConfig__AccountName' = $blobStorageAccount; ` 'AzureStorageConfig__ImageContainer' = 'images'; ` 'AzureStorageConfig__ThumbnailContainer' = 'thumbnails'; ` 'AzureStorageConfig__AccountKey' = $blobStorageAccountKey ` }

After you deploy and configure the web app, you can test the image upload functionality in the app.

Upload an image

To test the web app, browse to the URL of your published app. The default URL of the web app is https://<web_app>.azurewebsites.net. Then, select the Upload photos region to specify and upload a file, or drag a file onto the region. The image disappears if successfully uploaded. The Generated Thumbnails section remains empty until we test it later in this tutorial.

Note

Run the following command to get the name of the web app: echo $webapp

In the sample code, the UploadFileToStorage task in the Storagehelper.cs file is used to upload the images to the images container within the storage account using the UploadAsync method. The following code sample contains the UploadFileToStorage task.

public static async Task<bool> UploadFileToStorage(Stream fileStream, string fileName, AzureStorageConfig _storageConfig) { // Create a URI to the blob Uri blobUri = new Uri("https://" + _storageConfig.AccountName + ".blob.core.windows.net/" + _storageConfig.ImageContainer + "/" + fileName); // Create StorageSharedKeyCredentials object by reading // the values from the configuration (appsettings.json) StorageSharedKeyCredential storageCredentials = new StorageSharedKeyCredential(_storageConfig.AccountName, _storageConfig.AccountKey); // Create the blob client. BlobClient blobClient = new BlobClient(blobUri, storageCredentials); // Upload the file await blobClient.UploadAsync(fileStream); return await Task.FromResult(true); }

The following classes and methods are used in the preceding task:

Verify the image is shown in the storage account

1. Sign in to the Azure portal. From the left menu, select Storage accounts, then select the name of your storage account.

Note

Run the following to get the name of the storage account: echo $blobStorageAccount.

2. On the left menu, in the Data storage section, select Containers.

3. Select the images blob container.

4. Verify the image is shown in the container.

Test thumbnail viewing

To test thumbnail viewing, you upload an image to the thumbnails container to check whether the app can read the thumbnails container.

1. Sign in to the Azure portal. From the left menu, select Storage accounts, then select the name of your storage account. Select Containers, then select the thumbnails container. Select Upload to open the Upload blob pane.

2. Choose a file with the file picker and select Upload.

3. Navigate back to your app to verify that the image uploaded to the thumbnails container is visible.

4. In part two of the series, you automate thumbnail image creation so you don't need this image. In the thumbnails container, select the image you uploaded, and select Delete to remove the image.

Next steps

# data[].attributes.attachment_link.title
Upload image data in the cloud with Azure Storage - Azure Event Grid

# data[].attributes.attachment_link.description
This tutorial creates a web app that stores and displays images from Azure storage. It's a prerequisite for an Event Grid tutorial that's linked at the end of this article.

# data[].attributes.attachment_link.readable_text
This tutorial extends the Upload image data in the cloud with Azure Storage tutorial to add serverless automatic thumbnail generation using Azure Event Grid and Azure Functions. Here's the high-level workflow:

In this tutorial, you do the following steps:

Create an Azure Storage account

Create, configure, and deploy a function app

Create an event subscription to storage events

Test the sample app

Prerequisites

To complete this tutorial:

Create an Azure Storage account

Azure Functions requires a general storage account. In addition to the Blob storage account you created in the previous tutorial, create a separate general storage account in the resource group. Storage account names must be between 3 and 24 characters in length and may contain numbers and lowercase letters only.

Set variables to hold the name of the resource group that you created in the previous tutorial, the location for resources to be created, and the name of the new storage account that Azure Functions requires. Then, create the storage account for the Azure function.

functionstorage="funcstorage$RANDOM" az storage account create --name $functionstorage --location $region --resource-group $rgName --sku Standard_LRS --kind StorageV2 --allow-blob-public-access true

$functionstorage="funcstorage" + (Get-Random).ToString() New-AzStorageAccount -ResourceGroupName $rgName -AccountName $functionstorage -Location $region -SkuName Standard_LRS -Kind StorageV2 -AllowBlobPublicAccess $true

Create a function app

You must have a function app to host the execution of your function. The function app provides an environment for serverless execution of your function code. In the following command, provide your own unique function app name. The function app name is used as the default DNS domain for the function app, and so the name needs to be unique across all apps in Azure. Specify a name for the function app that's to be created, then create the Azure function.

functionapp="funcapp$RANDOM" az functionapp create --name $functionapp --storage-account $functionstorage --resource-group $rgName --consumption-plan-location $region --functions-version 4

$functionapp="funcapp" + (Get-Random).ToString() New-AzFunctionApp -Location $region -Name $functionapp -ResourceGroupName $rgName -Runtime PowerShell -StorageAccountName $functionstorage

Now configure the function app to connect to the Blob storage account you created in the previous tutorial.

Configure the function app

The function needs credentials for the Blob storage account, which are added to the application settings of the function app using either the az functionapp config appsettings set or Update-AzFunctionAppSetting command.

storageConnectionString=$(az storage account show-connection-string --resource-group $rgName --name $blobStorageAccount --query connectionString --output tsv) az functionapp config appsettings set --name $functionapp --resource-group $rgName --settings AzureWebJobsStorage=$storageConnectionString THUMBNAIL_CONTAINER_NAME=thumbnails THUMBNAIL_WIDTH=100 FUNCTIONS_EXTENSION_VERSION=~2 FUNCTIONS_WORKER_RUNTIME=dotnet

$storageConnectionString=$(az storage account show-connection-string --resource-group $rgName --name $blobStorageAccount --query connectionString --output tsv) Update-AzFunctionAppSetting -Name $functionapp -ResourceGroupName $rgName -AppSetting @{'AzureWebJobsStorage'=$storageConnectionString; 'THUMBNAIL_CONTAINER_NAME'='thumbnails'; 'THUMBNAIL_WIDTH'=100; 'FUNCTIONS_EXTENSION_VERSION'='~2'; 'FUNCTIONS_WORKER_RUNTIME'='dotnet'}

The FUNCTIONS_EXTENSION_VERSION=~2 setting makes the function app run on version 2.x of the Azure Functions runtime. You can now deploy a function code project to this function app.

Deploy the function code

The sample C# resize function is available on GitHub. Deploy this code project to the function app by using the az functionapp deployment source config command.

az functionapp deployment source config --name $functionapp --resource-group $rgName --branch master --manual-integration --repo-url https://github.com/Azure-Samples/function-image-upload-resize

The image resize function is triggered by HTTP requests sent to it from the Event Grid service. You tell Event Grid that you want to get these notifications at your function's URL by creating an event subscription. For this tutorial, you subscribe to blob-created events.

The data passed to the function from the Event Grid notification includes the URL of the blob. That URL is in turn passed to the input binding to obtain the uploaded image from Blob storage. The function generates a thumbnail image and writes the resulting stream to a separate container in Blob storage.

This project uses EventGridTrigger for the trigger type. Using the Event Grid trigger is recommended over generic HTTP triggers. Event Grid automatically validates Event Grid Function triggers. With generic HTTP triggers, you must implement the validation response.

To learn more about this function, see the function.json and run.csx files.

The function project code is deployed directly from the public sample repository. To learn more about deployment options for Azure Functions, see Continuous deployment for Azure Functions.

Create an event subscription

An event subscription indicates which provider-generated events you want sent to a specific endpoint. In this case, the endpoint is exposed by your function. Use the following steps to create an event subscription that sends notifications to your function in the Azure portal:

1. In the Azure portal, at the top of the page search for and select Function App and choose the function app that you created. Select Functions and choose the Thumbnail function.

2. Select select Integration then choose the Event Grid Trigger and select Create Event Grid subscription.

3. Use the event subscription settings as specified in the table.

Setting

Suggested value

Description

Name
imageresizersub

Name that identifies your new event subscription.

Topic type
Storage accounts

Choose the Storage account event provider.

Subscription
Your Azure subscription

By default, your current Azure subscription is selected.

Resource group
myResourceGroup

Select Use existing and choose the resource group you have been using in this tutorial.

Resource
Your Blob storage account

Choose the Blob storage account where images are stored, not the one used by the Azure function app.

System Topic Name
imagestoragesystopic

Specify a name for the system topic. To learn about system topics, see System topics overview.

Event types
Blob created

Uncheck all types other than Blob created. Only event types of Microsoft.Storage.BlobCreated are passed to the function.

Endpoint type
autogenerated

Predefined as Azure Function.

Endpoint
autogenerated

Name of the function. In this case, it's Thumbnail.

4. Switch to the Filters tab, and do the following actions:

1. Select Enable subject filtering option.

2. For Subject begins with, enter the following value: /blobServices/default/containers/images/.

5. Select Create to add the event subscription to create an event subscription that triggers the Thumbnail function when a blob is added to the images container. The function resizes the images and adds them to the thumbnails container.

Now that the backend services are configured, you test the image resize functionality in the sample web app.

Test the sample app

To test image resizing in the web app, browse to the URL of your published app. The default URL of the web app is https://<web_app>.azurewebsites.net.

Select Upload photos to select and upload a file. You can also drag a photo to this region.

Notice that after the uploaded image disappears, a copy of the uploaded image is displayed in the Generated Thumbnails carousel. This image was resized by the function, added to the thumbnails container, and downloaded by the web client.

Next steps

See other tutorials in the Tutorials section of the table of content (TOC).

# data[].attributes.attachment_link.title
Tutorial: Use Azure Event Grid to automate resizing uploaded images - Azure Event Grid

# data[].attributes.attachment_link.description
In this tutorial, you learn how to integrate Azure Blob Storage and Azure Functions via Azure Event Grid. When a blob is uploaded to a container, an event is triggered. The event is delivered to an Azure function by Azure Event Grid.

# data[].attributes.attachment_link.title
Compare the database engine features of SQL Database and SQL Managed Instance - Azure SQL Database & SQL Managed Instance

# data[].attributes.attachment_link.description
This article compares the database engine features of Azure SQL Database and Azure SQL Managed Instance

# data[].attributes.attachment_link.readable_text
Comparison: Traffic Manager vs Front Door in Azure.

Azure Load-balancing: Traffic Manager and Front Door

When choosing a global load balancer between Traffic Manager and Azure Front Door for global routing, you should consider what's similar and what's different about the two services. Both services provide

Multi-geo redundancy: If one region goes down, traffic seamlessly routes...

# data[].attributes.attachment_link.title
Azure - Difference between Traffic Manager and Front Door Service in Azure

# data[].attributes.attachment_link.description
When choosing a global load balancer between Traffic Manager and Azure Front Door for global routing, you should consider what's similar and what's different about the two services.

# data[].attributes.attachment_link.readable_text
APPLIES TO: NoSQL MongoDB Cassandra Gremlin Table

This article provides an overview of several common use cases for Azure Cosmos DB. The recommendations in this article serve as a starting point as you develop your application with Azure Cosmos DB.

After reading this article, you'll be able to answer the following questions:

What are the common use cases for Azure Cosmos DB?

What are the benefits of using Azure Cosmos DB for retail applications?

What are the benefits of using Azure Cosmos DB as a data store for Internet of Things (IoT) systems?

What are the benefits of using Azure Cosmos DB for web and mobile applications?

Introduction

Azure Cosmos DB is the Azure solution for a fast NoSQL database, with open APIs for any scale. The service is designed to allow customers to elastically (and independently) scale throughput and storage across any number of geographical regions. Azure Cosmos DB is the first globally distributed database service in the market today to offer comprehensive service level agreements encompassing throughput, latency, availability, and consistency.

Azure Cosmos DB is a global distributed, multi-model database that is used in a wide range of applications and use cases. It is a good choice for any serverless application that needs low order-of-millisecond response times, and needs to scale rapidly and globally. It supports multiple data models (key-value, documents, graphs and columnar) and many Azure Cosmos DB APIs for data access including API for MongoDB, API for NoSQL, API for Gremlin, and API for Table natively, and in an extensible manner.

The following are some attributes of Azure Cosmos DB that make it well-suited for high-performance applications with global ambition.

Azure Cosmos DB natively partitions your data for high availability and scalability. Azure Cosmos DB offers 99.99% guarantees for availability, throughput, low latency, and consistency on all single-region accounts and all multi-region accounts with relaxed consistency, and 99.999% read availability on all multi-region database accounts.

Azure Cosmos DB has SSD backed storage with low-latency order-of-millisecond response times.

Azure Cosmos DB's support for consistency levels like eventual, consistent prefix, session, and bounded-staleness allows for full flexibility and low cost-to-performance ratio. No database service offers as much flexibility as Azure Cosmos DB in levels consistency.

Azure Cosmos DB has a flexible data-friendly pricing model that meters storage and throughput independently.

Azure Cosmos DB's reserved throughput model allows you to think in terms of number of reads/writes instead of CPU/memory/IOPs of the underlying hardware.

Azure Cosmos DB's design lets you scale to massive request volumes in the order of trillions of requests per day.

These attributes are beneficial in web, mobile, gaming, and IoT applications that need low response times and need to handle massive amounts of reads and writes.

IoT and telematics

IoT use cases commonly share some patterns in how they ingest, process, and store data. First, these systems need to ingest bursts of data from device sensors of various locales. Next, these systems process and analyze streaming data to derive real-time insights. The data is then archived to cold storage for batch analytics. Microsoft Azure offers rich services that can be applied for IoT use cases including Azure Cosmos DB, Azure Event Hubs, Azure Stream Analytics, Azure Notification Hub, Azure Machine Learning, Azure HDInsight, and Power BI.

Bursts of data can be ingested by Azure Event Hubs as it offers high throughput data ingestion with low latency. Data ingested that needs to be processed for real-time insight can be funneled to Azure Stream Analytics for real-time analytics. Data can be loaded into Azure Cosmos DB for adhoc querying. Once the data is loaded into Azure Cosmos DB, the data is ready to be queried. In addition, new data and changes to existing data can be read on change feed. Change feed is a persistent, append only log that stores changes to Azure Cosmos DB containers in sequential order. Then all data or just changes to data in Azure Cosmos DB can be used as reference data as part of real-time analytics. In addition, data can further be refined and processed by connecting Azure Cosmos DB data to HDInsight for Pig, Hive, or Map/Reduce jobs. Refined data is then loaded back to Azure Cosmos DB for reporting.

For a sample IoT solution using Azure Cosmos DB, Event Hubs and Apache Storm, see the hdinsight-storm-examples repository on GitHub.

For more information on Azure offerings for IoT, see Create the Internet of Your Things.

Retail and marketing

Azure Cosmos DB is used extensively in Microsoft's own e-commerce platforms, that run the Windows Store and XBox Live. It is also used in the retail industry for storing catalog data and for event sourcing in order processing pipelines.

Catalog data usage scenarios involve storing and querying a set of attributes for entities such as people, places, and products. Some examples of catalog data are user accounts, product catalogs, IoT device registries, and bill of materials systems. Attributes for this data may vary and can change over time to fit application requirements.

Consider an example of a product catalog for an automotive parts supplier. Every part may have its own attributes in addition to the common attributes that all parts share. Furthermore, attributes for a specific part can change the following year when a new model is released. Azure Cosmos DB supports flexible schemas and hierarchical data, and thus it is well suited for storing product catalog data.

Azure Cosmos DB is often used for event sourcing to power event driven architectures using its change feed functionality. The change feed provides downstream microservices the ability to reliably and incrementally read inserts and updates (for example, order events) made to an Azure Cosmos DB. This functionality can be leveraged to provide a persistent event store as a message broker for state-changing events and drive order processing workflow between many microservices (which can be implemented as serverless Azure Functions).

In addition, data stored in Azure Cosmos DB can be integrated with HDInsight for big data analytics via Apache Spark jobs. For details on the Spark Connector for Azure Cosmos DB, see Run a Spark job with Azure Cosmos DB and HDInsight.

Gaming

The database tier is a crucial component of gaming applications. Modern games perform graphical processing on mobile/console clients, but rely on the cloud to deliver customized and personalized content like in-game stats, social media integration, and high-score leaderboards. Games often require single-millisecond latencies for reads and writes to provide an engaging in-game experience. A game database needs to be fast and be able to handle massive spikes in request rates during new game launches and feature updates.

Azure Cosmos DB is used by games like The Walking Dead: No Man's Land by Next Games, and Halo 5: Guardians. Azure Cosmos DB provides the following benefits to game developers:

Azure Cosmos DB allows performance to be scaled up or down elastically. This allows games to handle updating profile and stats from dozens to millions of simultaneous gamers by making a single API call.

Azure Cosmos DB supports millisecond reads and writes to help avoid any lags during game play.

Azure Cosmos DB's automatic indexing allows for filtering against multiple different properties in real-time, for example, locate players by their internal player IDs, or their GameCenter, Facebook, Google IDs, or query based on player membership in a guild. This is possible without building complex indexing or sharding infrastructure.

Social features including in-game chat messages, player guild memberships, challenges completed, high-score leaderboards, and social graphs are easier to implement with a flexible schema.

Azure Cosmos DB as a managed platform-as-a-service (PaaS) required minimal setup and management work to allow for rapid iteration, and reduce time to market.

Web and mobile applications

Azure Cosmos DB is commonly used within web and mobile applications, and is well suited for modeling social interactions, integrating with third-party services, and for building rich personalized experiences. The Azure Cosmos DB SDKs can be used build rich iOS and Android applications using the popular Xamarin framework.

Social Applications

A common use case for Azure Cosmos DB is to store and query user generated content (UGC) for web, mobile, and social media applications. Some examples of UGC are chat sessions, tweets, blog posts, ratings, and comments. Often, the UGC in social media applications is a blend of free form text, properties, tags, and relationships that are not bounded by rigid structure. Content such as chats, comments, and posts can be stored in Azure Cosmos DB without requiring transformations or complex object to relational mapping layers. Data properties can be added or modified easily to match requirements as developers iterate over the application code, thus promoting rapid development.

Applications that integrate with third-party social networks must respond to changing schemas from these networks. As data is automatically indexed by default in Azure Cosmos DB, data is ready to be queried at any time. Hence, these applications have the flexibility to retrieve projections as per their respective needs.

Many of the social applications run at global scale and can exhibit unpredictable usage patterns. Flexibility in scaling the data store is essential as the application layer scales to match usage demand. You can scale out by adding additional data partitions under an Azure Cosmos DB account. In addition, you can also create additional Azure Cosmos DB accounts across multiple regions. For Azure Cosmos DB service region availability, see Azure Regions.

Personalization

Nowadays, modern applications come with complex views and experiences. These are typically dynamic, catering to user preferences or moods and branding needs. Hence, applications need to be able to retrieve personalized settings effectively to render UI elements and experiences quickly.

JSON, a format supported by Azure Cosmos DB, is an effective format to represent UI layout data as it is not only lightweight, but also can be easily interpreted by JavaScript. Azure Cosmos DB offers tunable consistency levels that allow fast reads with low latency writes. Hence, storing UI layout data including personalized settings as JSON documents in Azure Cosmos DB is an effective means to get this data across the wire.

Next steps

To get started with Azure Cosmos DB, follow our quick starts, which walk you through creating an account and getting started with Azure Cosmos DB.

If you'd like to read more about customers using Azure Cosmos DB, see the customer case studies page.

# data[].attributes.attachment_link.title
Common use cases and scenarios for Azure Cosmos DB

# data[].attributes.attachment_link.description
Learn about the top five use cases for Azure Cosmos DB: user generated content, event logging, catalog data, user preferences data, and Internet of Things (IoT).

# data[].attributes.headline
Day 2 Whiteboard - Non-relational storage

# data[].attributes.subject
Day 2 Whiteboard - Non-relational storage

# data[].attributes.attachment_link.readable_text
This article analyzes the differences and similarities between the two types of queues offered by Microsoft Azure: Storage queues and Service Bus queues. By using this information, you can make a more informed decision about which solution best meets your needs.

Introduction

Azure supports two types of queue mechanisms: Storage queues and Service Bus queues.

Storage queues are part of the Azure Storage infrastructure. They allow you to store large numbers of messages. You access messages from anywhere in the world via authenticated calls using HTTP or HTTPS. A queue message can be up to 64 KB in size. A queue may contain millions of messages, up to the total capacity limit of a storage account. Queues are commonly used to create a backlog of work to process asynchronously. For more information, see What are Azure Storage queues.

Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing, publish/subscribe, and more advanced integration patterns. They're designed to integrate applications or application components that may span multiple communication protocols, data contracts, trust domains, or network environments. For more information about Service Bus queues/topics/subscriptions, see the Service Bus queues, topics, and subscriptions.

Technology selection considerations

Storage queues and Service Bus queues have a slightly different feature set. You can choose either one or both, depending on the needs of your particular solution.

When determining which queuing technology fits the purpose of a given solution, solution architects and developers should consider these recommendations.

Consider using Storage queues

As a solution architect/developer, you should consider using Storage queues when:

Your application must store over 80 gigabytes of messages in a queue.

Your application wants to track progress for processing a message in the queue. It's useful if the worker processing a message crashes. Another worker can then use that information to continue from where the prior worker left off.

You require server side logs of all of the transactions executed against your queues.

Consider using Service Bus queues

As a solution architect/developer, you should consider using Service Bus queues when:

Your solution needs to receive messages without having to poll the queue. With Service Bus, you can achieve it by using a long-polling receive operation using the TCP-based protocols that Service Bus supports.

Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.

Your solution needs to support automatic duplicate detection.

You want your application to process messages as parallel long-running streams (messages are associated with a stream using the session ID property on the message). In this model, each node in the consuming application competes for streams, as opposed to messages. When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions.

Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.

Your application handles messages that can exceed 64 KB but won't likely approach the 256 KB or 1 MB limit, depending on the chosen service tier (although Service Bus queues can handle messages up to 100 MB).

You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers. For more information, see the following articles:

Your queue size won't grow larger than 80 GB.

You want to use the AMQP 1.0 standards-based messaging protocol. For more information about AMQP, see Service Bus AMQP Overview.

You envision an eventual migration from queue-based point-to-point communication to a publish-subscribe messaging pattern. This pattern enables integration of additional receivers (subscribers). Each receiver receives independent copies of either some or all messages sent to the queue.

Your messaging solution needs to support the "At-Most-Once" and the "At-Least-Once" delivery guarantees without the need for you to build the additional infrastructure components.

Your solution needs to publish and consume batches of messages.

Compare Storage queues and Service Bus queues

The tables in the following sections provide a logical grouping of queue features. They let you compare, at a glance, the capabilities available in both Azure Storage queues and Service Bus queues.

Foundational capabilities

This section compares some of the fundamental queuing capabilities provided by Storage queues and Service Bus queues.

Comparison Criteria

Storage queues

Service Bus queues

Ordering guarantee

Delivery guarantee

At-Least-Once

At-Least-Once (using PeekLock receive mode. It's the default)

At-Most-Once (using ReceiveAndDelete receive mode)

Learn more about various Receive modes

Receive behavior

Non-blocking

(completes immediately if no new message is found)

Blocking with or without a timeout

(offers long polling, or the "Comet technique")

Non-blocking

(using .NET managed API only)

Lease/Lock duration

30 seconds (default)

You can renew the message lock for the same lock duration each time manually or use the automatic lock renewal feature where the client manages lock renewal for you.

Lease/Lock precision

Queue level

(each queue has a lock precision applied to all of its messages, but the lock can be renewed as described in the previous row)

Additional information

Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order. For example, when the visibility-timeout duration of a message expires because a client application crashed while processing a message. When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. At that point, the newly visible message might be placed in the queue to be dequeued again.

The guaranteed FIFO pattern in Service Bus queues requires the use of messaging sessions. If the application crashes while it's processing a message received in the Peek & Lock mode, the next time a queue receiver accepts a messaging session, it will start with the failed message after the session's lock duration expires.

Storage queues are designed to support standard queuing scenarios, such as the following ones:

Decoupling application components to increase scalability and tolerance for failures

Load leveling

Building process workflows.

Inconsistencies regarding message handling in the context of Service Bus sessions can be avoided by using session state to store the application's state relative to the progress of handling the session's message sequence, and by using transactions around settling received messages and updating the session state. This kind of consistency feature is sometimes labeled exactly once processing in other vendor's products. Any transaction failures will obviously cause messages to be redelivered and that's why the term isn't exactly adequate.

Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs - both for developers and for operations teams.

Service Bus queues provide support for local transactions in the context of a single queue.

The Receive and Delete mode supported by Service Bus provides the ability to reduce the messaging operation count (and associated cost) in exchange for lowered delivery assurance.

Storage queues provide leases with the ability to extend the leases for messages. This feature allows the worker processes to maintain short leases on messages. So, if a worker crashes, the message can be quickly processed again by another worker. Also, a worker can extend the lease on a message if it needs to process it longer than the current lease time.

Storage queues offer a visibility timeout that you can set upon the enqueuing or dequeuing of a message. Also, you can update a message with different lease values at run-time, and update different values across messages in the same queue. Service Bus lock timeouts are defined in the queue metadata. However, you can renew the message lock for the pre-defined lock duration manually or use the automatic lock renewal feature where the client manages lock renewal for you.

The maximum timeout for a blocking receive operation in Service Bus queues is 24 days. However, REST-based timeouts have a maximum value of 55 seconds.

Client-side batching provided by Service Bus enables a queue client to batch multiple messages into a single send operation. Batching is only available for asynchronous send operations.

Features such as the 200-TB ceiling of Storage queues (more when you virtualize accounts) and unlimited queues make it an ideal platform for SaaS providers.

Storage queues provide a flexible and performant delegated access control mechanism.

Advanced capabilities

This section compares advanced capabilities provided by Storage queues and Service Bus queues.

Comparison Criteria

Storage queues

Service Bus queues

Storage metrics

State management

No

Yes (Active, Disabled, SendDisabled, ReceiveDisabled. For details on these states, see Queue status)

Additional information

Both queuing technologies enable a message to be scheduled for delivery at a later time.

Queue autoforwarding enables thousands of queues to autoforward their messages to a single queue, from which the receiving application consumes the message. You can use this mechanism to achieve security, control flow, and isolate storage between each message publisher.

Storage queues provide support for updating message content. You can use this functionality for persisting state information and incremental progress updates into the message so that it can be processed from the last known checkpoint, instead of starting from scratch. With Service Bus queues, you can enable the same scenario by using message sessions. For more information, see Message session state.

Service Bus queues support dead lettering. It can be useful for isolating messages that meet the following criteria:

Messages can't be processed successfully by the receiving application

Messages can't reach their destination because of an expired time-to-live (TTL) property. The TTL value specifies how long a message remains in the queue. With Service Bus, the message will be moved to a special queue called $DeadLetterQueue when the TTL period expires.

To find "poison" messages in Storage queues, when dequeuing a message the application examines the DequeueCount property of the message. If DequeueCount is greater than a given threshold, the application moves the message to an application-defined "dead letter" queue.

Storage queues enable you to obtain a detailed log of all of the transactions executed against the queue, and aggregated metrics. Both of these options are useful for debugging and understanding how your application uses Storage queues. They're also useful for performance-tuning your application and reducing the costs of using queues.

Message sessions supported by Service Bus enable messages that belong to a logical group to be associated with a receiver. It creates a session-like affinity between messages and their respective receivers. You can enable this advanced functionality in Service Bus by setting the session ID property on a message. Receivers can then listen on a specific session ID and receive messages that share the specified session identifier.

The duplication detection feature of Service Bus queues automatically removes duplicate messages sent to a queue or topic, based on the value of the message ID property.

Capacity and quotas

This section compares Storage queues and Service Bus queues from the perspective of capacity and quotas that may apply.

Comparison Criteria

Storage queues

Service Bus queues

Maximum queue size

Maximum message size

64 KB

(48 KB when using Base64 encoding)

Azure supports large messages by combining queues and blobs - at which point you can enqueue up to 200 GB for a single item.

256 KB or 100 MB

(including both header and body, maximum header size: 64 KB).

Depends on the service tier.

Additional information

Service Bus enforces queue size limits. The maximum queue size is specified when creating a queue. It can be between 1 GB and 80 GB. If the queue's size reaches this limit, additional incoming messages will be rejected and the caller receives an exception. For more information about quotas in Service Bus, see Service Bus Quotas.

In the Standard messaging tier, you can create Service Bus queues and topics in 1 (default), 2, 3, 4, or 5-GB sizes. When enabling partitioning in the Standard tier, Service Bus creates 16 copies (16 partitions) of the entity, each of the same size specified. As such, if you create a queue that's 5 GB in size, with 16 partitions the maximum queue size becomes (5 * 16) = 80 GB. You can see the maximum size of your partitioned queue or topic in the Azure portal.

With Storage queues, if the content of the message isn't XML-safe, then it must be Base64 encoded. If you Base64-encode the message, the user payload can be up to 48 KB, instead of 64 KB.

With Service Bus queues, each message stored in a queue is composed of two parts: a header and a body. The total size of the message can't exceed the maximum message size supported by the service tier.

When clients communicate with Service Bus queues over the TCP protocol, the maximum number of concurrent connections to a single Service Bus queue is limited to 100. This number is shared between senders and receivers. If this quota is reached, requests for additional connections will be rejected and an exception will be received by the calling code. This limit isn't imposed on clients connecting to the queues using REST-based API.

If you require more than 10,000 queues in a single Service Bus namespace, you can contact the Azure support team and request an increase. To scale beyond 10,000 queues with Service Bus, you can also create additional namespaces using the Azure portal.

Management and operations

This section compares the management features provided by Storage queues and Service Bus queues.

Additional information

Storage queues provide support for arbitrary attributes that can be applied to the queue description, in the form of name/value pairs.

Both queue technologies offer the ability to peek a message without having to lock it, which can be useful when implementing a queue explorer/browser tool.

The Service Bus .NET brokered messaging APIs use full-duplex TCP connections for improved performance when compared to REST over HTTP, and they support the AMQP 1.0 standard protocol.

Names of Storage queues can be 3-63 characters long, can contain lowercase letters, numbers, and hyphens. For more information, see Naming Queues and Metadata.

Service Bus queue names can be up to 260 characters long and have less restrictive naming rules. Service Bus queue names can contain letters, numbers, periods, hyphens, and underscores.

Authentication and authorization

This section discusses the authentication and authorization features supported by Storage queues and Service Bus queues.

Additional information

Every request to either of the queuing technologies must be authenticated. Public queues with anonymous access aren't supported.

Using shared access signature (SAS) authentication, you can create a shared access authorization rule on a queue that can give users a write-only, read-only, or full access. For more information, see Azure Storage - SAS authentication and Azure Service Bus - SAS authentication.

Both queues support authorizing access using Microsoft Entra ID. Authorizing users or applications using OAuth 2.0 token returned by Microsoft Entra ID provides superior security and ease of use over shared access signatures (SAS). With Microsoft Entra ID, there is no need to store the tokens in your code and risk potential security vulnerabilities. For more information, see Azure Storage - Microsoft Entra authentication and Azure Service Bus - Microsoft Entra authentication.

Conclusion

By gaining a deeper understanding of the two technologies, you can make a more informed decision on which queue technology to use, and when. The decision on when to use Storage queues or Service Bus queues clearly depends on many factors. These factors may depend heavily on the individual needs of your application and its architecture.

You may prefer to choose Storage queues for reasons such as the following ones:

If your application already uses the core capabilities of Microsoft Azure

If you require basic communication and messaging between services

Need queues that can be larger than 80 GB in size

Service Bus queues provide many advanced features such as the following ones. So, they may be a preferred choice if you're building a hybrid application or if your application otherwise requires these features.

Next steps

The following articles provide more guidance and information about using Storage queues or Service Bus queues.

# data[].attributes.attachment_link.title
Compare Azure Storage queues and Service Bus queues - Azure Service Bus

# data[].attributes.attachment_link.description
Analyzes differences and similarities between two types of queues offered by Azure.

# data[].attributes.attachment_link.readable_text
Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication. You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud.

A Domain Services managed domain lets you run legacy applications in the cloud that can't use modern authentication methods, or where you don't want directory lookups to always go back to an on-premises AD DS environment. You can lift and shift those legacy applications from your on-premises environment into a managed domain, without needing to manage the AD DS environment in the cloud.

Domain Services integrates with your existing Microsoft Entra tenant. This integration lets users sign in to services and applications connected to the managed domain using their existing credentials. You can also use existing groups and user accounts to secure access to resources. These features provide a smoother lift-and-shift of on-premises resources to Azure.

Take a look at our short video to learn more about Domain Services.

How does Domain Services work?

When you create a Domain Services managed domain, you define a unique namespace. This namespace is the domain name, such as aaddscontoso.com. Two Windows Server domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.

You don't need to manage, configure, or update these DCs. The Azure platform handles the DCs as part of the managed domain, including backups and encryption at rest using Azure Disk Encryption.

A managed domain is configured to perform a one-way synchronization from Microsoft Entra ID to provide access to a central set of users, groups, and credentials. You can create resources directly in the managed domain, but they aren't synchronized back to Microsoft Entra ID. Applications, services, and VMs in Azure that connect to the managed domain can then use common AD DS features such as domain join, group policy, LDAP, and Kerberos/NTLM authentication.

In a hybrid environment with an on-premises AD DS environment, Microsoft Entra Connect synchronizes identity information with Microsoft Entra ID, which is then synchronized to the managed domain.

Domain Services replicates identity information from Microsoft Entra ID, so it works with Microsoft Entra tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Domain Services features exists for both environments.

If you have an existing on-premises AD DS environment, you can synchronize user account information to provide a consistent identity for users. To learn more, see How objects and credentials are synchronized in a managed domain.

For cloud-only environments, you don't need a traditional on-premises AD DS environment to use the centralized identity services of Domain Services.

You can expand a managed domain to have more than one replica set per Microsoft Entra tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Domain Services. By adding replica sets in different Azure regions, you can provide geographical disaster recovery for legacy applications if an Azure region goes offline. For more information, see Replica sets concepts and features for managed domains.

Take a look at this video about how Domain Services integrates with your applications and workloads to provide identity services in the cloud:

To see Domain Services deployment scenarios in action, you can explore the following examples:

Domain Services features and benefits

To provide identity services to applications and VMs in the cloud, Domain Services is fully compatible with a traditional AD DS environment for operations such as domain-join, secure LDAP (LDAPS), Group Policy, DNS management, and LDAP bind and read support. LDAP write support is available for objects created in the managed domain, but not resources synchronized from Microsoft Entra ID.

To learn more about your identity options, compare Domain Services with Microsoft Entra ID, AD DS on Azure VMs, and AD DS on-premises.

The following features of Domain Services simplify deployment and management operations:

Simplified deployment experience: Domain Services is enabled for your Microsoft Entra tenant using a single wizard in the Microsoft Entra admin center.

Integrated with Microsoft Entra ID: User accounts, group memberships, and credentials are automatically available from your Microsoft Entra tenant. New users, groups, or changes to attributes from your Microsoft Entra tenant or your on-premises AD DS environment are automatically synchronized to Domain Services.
Accounts in external directories linked to your Microsoft Entra ID aren't available in Domain Services. Credentials aren't available for those external directories, so can't be synchronized into a managed domain.

Use your corporate credentials/passwords: Passwords for users in Domain Services are the same as in your Microsoft Entra tenant. Users can use their corporate credentials to domain-join machines, sign in interactively or over remote desktop, and authenticate against the managed domain.

NTLM and Kerberos authentication: With support for NTLM and Kerberos authentication, you can deploy applications that rely on Windows-integrated authentication.

High availability: Domain Services includes multiple domain controllers, which provide high availability for your managed domain. This high availability guarantees service uptime and resilience to failures.

In regions that support Azure Availability Zones, these domain controllers are also distributed across zones for additional resiliency.

Replica sets can also be used to provide geographical disaster recovery for legacy applications if an Azure region goes offline.

Some key aspects of a managed domain include the following:

The managed domain is a stand-alone domain. It isn't an extension of an on-premises domain.

Your IT team doesn't need to manage, patch, or monitor domain controllers for this managed domain.

For hybrid environments that run AD DS on-premises, you don't need to manage AD replication to the managed domain. User accounts, group memberships, and credentials from your on-premises directory are synchronized to Microsoft Entra ID via Microsoft Entra Connect. These user accounts, group memberships, and credentials are automatically available within the managed domain.

Next steps

To learn more about Domain Services compares with other identity solutions and how synchronization works, see the following articles:

To get started, create a managed domain using the Microsoft Entra admin center.

# data[].attributes.attachment_link.title
Overview of Microsoft Entra Domain Services - Microsoft Entra ID

# data[].attributes.attachment_link.description
In this overview, learn what Microsoft Entra Domain Services provides and how to use it in your organization to provide identity services to applications and services in the cloud.

# data[].attributes.attachment_link.readable_text
Microsoft Entra Cloud Sync is a new offering from Microsoft designed to meet and accomplish your hybrid identity goals for synchronization of users, groups, and contacts to Microsoft Entra ID. It accomplishes this by using the Microsoft Entra cloud provisioning agent instead of the Microsoft Entra Connect application. However, it can be used alongside Microsoft Entra Connect Sync and it provides the following benefits:

Support for synchronizing to a Microsoft Entra tenant from a multi-forest disconnected Active Directory forest environment: The common scenarios include merger & acquisition (where the acquired company's AD forests are isolated from the parent company's AD forests), and companies that have historically had multiple AD forests.

Simplified installation with light-weight provisioning agents: The agents act as a bridge from AD to Microsoft Entra ID, with all the sync configuration managed in the cloud.

Multiple provisioning agents can be used to simplify high availability deployments, particularly critical for organizations relying upon password hash synchronization from AD to Microsoft Entra ID.

Support for large groups with up to 50,000 members. It's recommended to use only the OU scoping filter when synchronizing large groups.

How is Microsoft Entra Cloud Sync different from Microsoft Entra Connect Sync?

With Microsoft Entra Cloud Sync, provisioning from AD to Microsoft Entra ID is orchestrated in Microsoft Online Services. An organization only needs to deploy, in their on-premises or IaaS-hosted environment, a light-weight agent that acts as a bridge between Microsoft Entra ID and AD. The provisioning configuration is stored in Microsoft Entra ID and managed as part of the service.

Microsoft Entra Cloud Sync video

The following short video provides an excellent overview of Microsoft Entra Cloud Sync:

Choose the right sync client

To determine if cloud sync is right for your organization, use the link below. It will take you to a tool that will help you evaluate your synchronization needs. For more information, evaluate your options using the Wizard to evaluate sync options

Comparison between Microsoft Entra Connect and cloud sync

The following table provides a comparison between Microsoft Entra Connect and Microsoft Entra Cloud Sync:

Next steps

# data[].attributes.attachment_link.title
What is Microsoft Entra Cloud Sync? - Microsoft Entra ID

# data[].attributes.attachment_link.readable_text
This article helps you configure gateway transit for virtual network peering. Virtual network peering seamlessly connects two Azure virtual networks, merging the two virtual networks into one for connectivity purposes. Gateway transit is a peering property that lets one virtual network use the VPN gateway in the peered virtual network for cross-premises or VNet-to-VNet connectivity.

The following diagram shows how gateway transit works with virtual network peering. In the diagram, gateway transit allows the peered virtual networks to use the Azure VPN gateway in Hub-RM. Connectivity available on the VPN gateway, including S2S, P2S, and VNet-to-VNet connections, applies to all three virtual networks.

The transit option is available for peering between the same, or different deployment models and can be used with all VPN Gateway SKUs except the Basic SKU. If you're configuring transit between different deployment models, the hub virtual network and virtual network gateway must be in the Resource Manager deployment model, not the legacy classic deployment model.

In hub-and-spoke network architecture, gateway transit allows spoke virtual networks to share the VPN gateway in the hub, instead of deploying VPN gateways in every spoke virtual network. Routes to the gateway-connected virtual networks or on-premises networks propagate to the routing tables for the peered virtual networks using gateway transit.

You can disable the automatic route propagation from the VPN gateway. Create a routing table with the " Disable BGP route propagation" option, and associate the routing table to the subnets to prevent the route distribution to those subnets. For more information, see Virtual network routing table.

There are two scenarios in this article. Select the scenario that applies to your environment. Most people use the Same deployment model scenario. If you aren't working with a classic deployment model VNet (legacy VNet) that already exists in your environment, you won't need to work with the Different deployment models scenario.

Same deployment model: Both virtual networks are created in the Resource Manager deployment model.

Different deployment models: The spoke virtual network is created in the classic deployment model, and the hub virtual network and gateway are in the Resource Manager deployment model. This scenario is useful when you need to connect a legacy VNet that already exists in the classic deployment model.

Note

If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client.

Prerequisites

This article requires the following VNets and permissions. If you aren't working with the different deployment model scenario, you don't need to create the classic VNet.

Virtual networks

Permissions

The accounts you use to create a virtual network peering must have the necessary roles or permissions. In the example below, if you were peering the two virtual networks named Hub-RM and Spoke-Classic, your account must have the following roles or permissions for each virtual network:

Learn more about built-in roles and assigning specific permissions to custom roles (Resource Manager only).

Same deployment model

This is the more common scenario. In this scenario, the virtual networks are both in the Resource Manager deployment model. Use the following steps to create or update the virtual network peerings to enable gateway transit.

To add a peering and enable transit

1. In the Azure portal, create or update the virtual network peering from the Hub-RM. Go to the Hub-RM virtual network. Select Peerings, then + Add to open Add peering.

2. On the Add peering page, configure the values for This virtual network.

Peering link name: Name the link. Example: HubRMToSpokeRM

Traffic to remote virtual network: Allow

Traffic forwarded from remote virtual network: Allow

Virtual network gateway: Use this virtual network's gateway or Route Server

3. On the same page, continue on to configure the values for the Remote virtual network.

Peering link name: Name the link. Example: SpokeRMtoHubRM

Virtual network deployment model: Resource Manager

I know my resource ID: Leave blank. You only need to select this if you don't have read access to the virtual network or subscription you want to peer with.

Subscription: Select the subscription.

Virtual Network: Spoke-RM

Traffic to remote virtual network: Allow

Traffic forwarded from remote virtual network: Allow

Virtual network gateway: Use the remote virtual network's gateway or Route Server

4. Select Add to create the peering.

5. Verify the peering status as Connected on both virtual networks.

To modify an existing peering for transit

If you have an already existing peering, you can modify the peering for transit.

1. Go to the virtual network. Select Peerings and select the peering that you want to modify. For example, on the Spoke-RM VNet, select the SpokeRMtoHubRM peering.

2. Update the VNet peering.

Traffic to remote virtual network: Allow

Traffic forwarded to virtual network; Allow

Virtual network gateway or Route Server: Use the remote virtual network's gateway or Route Server

3. Save the peering settings.

PowerShell sample

You can also use PowerShell to create or update the peering. Replace the variables with the names of your virtual networks and resource groups.

$SpokeRG = "SpokeRG1" $SpokeRM = "Spoke-RM" $HubRG = "HubRG1" $HubRM = "Hub-RM" $spokermvnet = Get-AzVirtualNetwork -Name $SpokeRM -ResourceGroup $SpokeRG $hubrmvnet = Get-AzVirtualNetwork -Name $HubRM -ResourceGroup $HubRG Add-AzVirtualNetworkPeering ` -Name SpokeRMtoHubRM ` -VirtualNetwork $spokermvnet ` -RemoteVirtualNetworkId $hubrmvnet.Id ` -UseRemoteGateways Add-AzVirtualNetworkPeering ` -Name HubRMToSpokeRM ` -VirtualNetwork $hubrmvnet ` -RemoteVirtualNetworkId $spokermvnet.Id ` -AllowGatewayTransit

Different deployment models

In this configuration, the spoke VNet Spoke-Classic is in the classic deployment model and the hub VNet Hub-RM is in the Resource Manager deployment model. When configuring transit between deployment models, the virtual network gateway must be configured for the Resource Manager VNet, not the classic VNet.

For this configuration, you only need to configure the Hub-RM virtual network. You don't need to configure anything on the Spoke-Classic VNet.

1. In the Azure portal, go to the Hub-RM virtual network, select Peerings, then select + Add.

2. On the Add peering page, configure the following values:

Peering link name: Name the link. Example: HubRMToClassic

Traffic to remote virtual network: Allow

Traffic forwarded from remote virtual network: Allow

Virtual network gateway or Route Server: Use this virtual network's gateway or Route Server

Peering link name: This value disappears when you select Classic for the virtual network deployment model.

Virtual network deployment model: Classic

I know my resource ID: Leave blank. You only need to select this if you don't have read access to the virtual network or subscription you want to peer with.

3. Verify the subscription is correct, then select the virtual network from the dropdown.

4. Select Add to add the peering.

5. Verify the peering status as Connected on the Hub-RM virtual network.

For this configuration, you don't need to configure anything on the Spoke-Classic virtual network. Once the status shows Connected, the spoke virtual network can use the connectivity through the VPN gateway in the hub virtual network.

PowerShell sample

You can also use PowerShell to create or update the peering. Replace the variables and subscription ID with the values of your virtual network and resource groups, and subscription. You only need to create virtual network peering on the hub virtual network.

$HubRG = "HubRG1" $HubRM = "Hub-RM" $hubrmvnet = Get-AzVirtualNetwork -Name $HubRM -ResourceGroup $HubRG Add-AzVirtualNetworkPeering ` -Name HubRMToClassic ` -VirtualNetwork $hubrmvnet ` -RemoteVirtualNetworkId "/subscriptions/<subscription Id>/resourceGroups/Default-Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/Spoke-Classic" ` -AllowGatewayTransit

Next steps

# data[].attributes.attachment_link.title
Configure VPN gateway transit for virtual network peering - Azure VPN Gateway

# data[].attributes.attachment_link.description
Learn how to configure gateway transit for virtual network peering in order to seamlessly connect two Azure virtual networks into one for connectivity purposes.

# data[].attributes.attachment_link.title
Connectivity providers and locations: Azure ExpressRoute

# data[].attributes.attachment_link.description
This article provides a detailed overview of locations where services are offered and how to connect to Azure regions. Sorted by connectivity provider.