Azure integrations overview

Aspire provides a comprehensive set of integrations for Azure services that enable you to build cloud-native distributed applications. These integrations handle configuration, health checks, telemetry, and deployment for various Azure services.

What are Azure integrations?

Azure integrations in Aspire provide two main capabilities:

Add Azure resources

All Aspire Azure hosting integrations expose Azure resources and by convention are added using AddAzure* APIs. When you add these resources to your Aspire AppHost, they represent an Azure service. The AddAzure* API returns an IResourceBuilder<T> where T is the type of Azure resource. These IResourceBuilder<T> (builder) interfaces provide a fluent API that allows you to configure the underlying Azure resource within the app model. There are APIs for adding new Azure resources, marking resources as existing, and configuring how the resources behave in various execution contexts.

Typical developer experience

When your Aspire AppHost contains Azure resources, and you run it locally (typical developer or dotnet run experience), the Azure resources are provisioned in your Azure subscription. This allows you as the developer to debug against them locally in the context of your AppHost.

Aspire aims to minimize costs by defaulting to Basic or Standard Stock Keeping Unit (SKU) for its Azure integrations. While these sensible defaults are provided, you can customize the Azure resources to suit your needs. Additionally, some integrations support emulators or containers, which are useful for local development, testing, and debugging. By default, when you run your app locally, the Azure resources use the actual Azure service. However, you can configure them to use local emulators or containers, avoiding costs associated with the actual Azure service during local development.

Local emulators

Some Azure services can be emulated to run locally. Currently, Aspire supports the following Azure emulators:

To have your Azure resources use the local emulators, chain a call the RunAsEmulator method on the Azure resource builder. This method configures the Azure resource to use the local emulator instead of the actual Azure service.

Local containers

Some Azure resources can be substituted locally using open-source or on-premises containers. To substitute an Azure resource locally in a container, chain a call to the RunAsContainer method on the Azure resource builder. This method configures the Azure resource to use a containerized version of the service for local development and testing, rather than the actual Azure service.

Currently, Aspire supports the following Azure services as containers:

Understand Azure integration APIs

Aspire's strength lies in its ability to provide an amazing developer inner-loop. The Azure integrations are no different. They provide a set of common APIs and patterns that are shared across all Azure resources. These APIs and patterns are designed to make it easy to work with Azure resources in a consistent manner.

In the preceding containers section, you saw how to run Azure services locally in containers. If you're familiar with Aspire, you might wonder how calling AddAzureRedis("redis").RunAsContainer() to get a local docker.io/library/redis container differs from AddRedis("redis")—as they both result in the same local container.

The answer is that there's no difference when running locally. However, when they're published you get different resources:

The same is true for SQL and PostgreSQL services:

For more information on the difference between run and publish modes, see Aspire AppHost: Execution context.

APIs for expressing Azure resources in different modes

The distributed application builder, part of the AppHost, uses the builder pattern to AddAzure* resources to the app model. Developers can configure these resources and define their behavior in different execution contexts. Azure hosting integrations provide APIs to specify how these resources should be "published" and "run."

When the AppHost executes, the execution context is used to determine whether the AppHost is in Run or Publish mode. The naming conventions for these APIs indicate the intended action for the resource.

The following table summarizes the naming conventions used to express Azure resources:

For more information on execution modes, see Execution context.

General run mode API use cases

Use RunAsExisting when you need to dynamically interact with an existing resource during runtime without needing to deploy or update it. Use PublishAsExisting when declaring existing resources as part of a deployment configuration, ensuring the correct scopes and permissions are applied. Finally, use AsExisting when declaring existing resources in both configurations, with a requirement to parameterize the references.

You can query whether a resource is marked as an existing resource, by calling the IsExisting extension method on the IResource. For more information, see Use existing Azure resources.

Use existing Azure resources

Aspire provides support for referencing existing Azure resources. You mark an existing resource through the PublishAsExisting, RunAsExisting, and AsExisting APIs. These APIs allow developers to reference already-deployed Azure resources, configure them, and generate appropriate deployment manifests using Bicep templates.

Existing resources referenced with these APIs can be enhanced with role assignments and other customizations that are available with Aspire's infrastructure as code capabilities. These APIs are limited to Azure resources that can be deployed with Bicep templates.

Configure existing Azure resources for run mode

The RunAsExisting method is used when a distributed application is executing in "run" mode. In this mode, it assumes that the referenced Azure resource already exists and integrates with it during execution without provisioning the resource. To mark an Azure resource as existing, call the RunAsExisting method on the resource builder. Consider the following example:

var builder = DistributedApplication.CreateBuilder();
  
var existingServiceBusName = builder.AddParameter("existingServiceBusName");
var existingServiceBusResourceGroup = builder.AddParameter("existingServiceBusResourceGroup");
  
var serviceBus = builder.AddAzureServiceBus("messaging")
                        .RunAsExisting(existingServiceBusName, existingServiceBusResourceGroup);
  
serviceBus.AddServiceBusQueue("queue");

The preceding code:

• Creates a new builder instance.
• Adds a parameter named existingServiceBusName to the builder.
• Adds an Azure Service Bus resource named messaging to the builder.
• Calls the RunAsExisting method on the serviceBus resource builder, passing the existingServiceBusName parameter—alternatively, you can use the string parameter overload.
• Adds a queue named queue to the serviceBus resource.

By default, the Service Bus parameter reference is assumed to be in the same Azure resource group. However, if it's in a different resource group, you can pass the resource group explicitly as a parameter to correctly specify the appropriate resource grouping.

Configure existing Azure resources for publish mode

The PublishAsExisting method is used in "publish" mode when the intent is to declare and reference an already-existing Azure resource during publish mode. This API facilitates the creation of manifests and templates that include resource definitions that map to existing resources in Bicep.

To mark an Azure resource as existing in for the "publish" mode, call the PublishAsExisting method on the resource builder. Consider the following example:

var builder = DistributedApplication.CreateBuilder();
  
var existingServiceBusName = builder.AddParameter("existingServiceBusName");
var existingServiceBusResourceGroup = builder.AddParameter("existingServiceBusResourceGroup");
  
var serviceBus = builder.AddAzureServiceBus("messaging")
                        .PublishAsExisting(existingServiceBusName, existingServiceBusResourceGroup);
  
serviceBus.AddServiceBusQueue("queue");

The preceding code:

• Creates a new builder instance.
• Adds a parameter named existingServiceBusName to the builder.
• Adds an Azure Service Bus resource named messaging to the builder.
• Calls the PublishAsExisting method on the serviceBus resource builder, passing the existingServiceBusName parameter—alternatively, you can use the string parameter overload.
• Adds a queue named queue to the serviceBus resource.

After the AppHost is executed in publish mode, the generated Bicep output will reference the existing Azure resource using the existingServiceBusName parameter. Consider the following generated Bicep template:

@description('The location for the resource(s) to be deployed.')
param location string = resourceGroup().location
  
param existingServiceBusName string
  
param principalType string
  
param principalId string
  
resource messaging 'Microsoft.ServiceBus/namespaces@2024-01-01' existing = {
  name: existingServiceBusName
}
  
resource messaging_AzureServiceBusDataOwner 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(messaging.id, principalId, subscriptionResourceId(
    'Microsoft.Authorization/roleDefinitions', '090c5cfd-751d-490a-894a-3ce6f1109419'))
  properties: {
    principalId: principalId
    roleDefinitionId: subscriptionResourceId(
        'Microsoft.Authorization/roleDefinitions', '090c5cfd-751d-490a-894a-3ce6f1109419')
    principalType: principalType
  }
  scope: messaging
}
  
resource queue 'Microsoft.ServiceBus/namespaces/queues@2024-01-01' = {
  name: 'queue'
  parent: messaging
}
  
output serviceBusEndpoint string = messaging.properties.serviceBusEndpoint

For more information on the generated Bicep templates, see Customize Azure resources and consider other publishing APIs.

Configure existing Azure resources in all modes

The AsExisting method is used when the distributed application is running in "run" or "publish" mode. Because the AsExisting method operates in both scenarios, it only supports a parameterized reference to the resource name or resource group name. This approach helps prevent the use of the same resource in both testing and production environments.

To mark an Azure resource as existing, call the AsExisting method on the resource builder. Consider the following example:

var builder = DistributedApplication.CreateBuilder();
  
var existingServiceBusName = builder.AddParameter("existingServiceBusName");
var existingServiceBusResourceGroup = builder.AddParameter("existingServiceBusResourceGroup");
  
var serviceBus = builder.AddAzureServiceBus("messaging")
    .AsExisting(existingServiceBusName, existingServiceBusResourceGroup);
  
serviceBus.AddServiceBusQueue("queue");

The preceding code:

• Creates a new builder instance.
• Adds a parameter named existingServiceBusName to the builder.
• Adds an Azure Service Bus resource named messaging to the builder.
• Calls the AsExisting method on the serviceBus resource builder, passing the existingServiceBusName parameter.
• Adds a queue named queue to the serviceBus resource.

Add existing Azure resources with connection strings

Aspire provides the ability to connect to existing resources, including Azure resources. Expressing connection strings is useful when you have existing Azure resources that you want to use in your Aspire app. The AddConnectionString API is used with the AppHost's execution context to conditionally add a connection string to the app model.

Consider the following example, where in publish mode you add an Azure Storage resource while in run mode you add a connection string to an existing Azure Storage:

var builder = DistributedApplication.CreateBuilder(args);
  
var storage = builder.ExecutionContext.IsPublishMode
    ? builder.AddAzureStorage("storage")
    : builder.AddConnectionString("storage");
  
builder.AddProject<Projects.Api>("api")
    .WithReference(storage);
  
// After adding all resources, run the app...

The preceding code:

• Creates a new builder instance.
• Adds an Azure Storage resource named storage in "publish" mode.
• Adds a connection string to an existing Azure Storage named storage in "run" mode.
• Adds a project named api to the builder.
• The api project references the storage resource regardless of the mode.

The consuming API project uses the connection string information with no knowledge of how the AppHost configured it. In "publish" mode, the code adds a new Azure Storage resource—which would be reflected in the deployment manifest accordingly. When in "run" mode the connection string corresponds to a configuration value visible to the AppHost. It's assumed that all role assignments for the target resource are configured. This means, you'd likely configure an environment variable or a user secret to store the connection string. The configuration is resolved from the ConnectionStrings__storage (or ConnectionStrings:storage) configuration key. These configuration values can be viewed when the app runs. For more information, see Resource details.

Unlike existing resources modeled with the first-class AsExisting API, existing resource modeled as connection strings can't be enhanced with additional role assignments or infrastructure customizations.

Publish as Azure Container App

Aspire allows you to publish primitive resources as Azure Container Apps, a serverless platform that reduces infrastructure management. Supported resource types include:

• ContainerResource: Represents a specified container.
• ExecutableResource: Represents a specified executable process.
• ProjectResource: Represents a specified .NET project.

To publish these resources, use the following APIs:

• PublishAsAzureContainerApp for containers
• PublishAsAzureContainerApp for executables
• PublishAsAzureContainerApp for projects

These APIs configure the resource to be published as an Azure Container App and implicitly call AddAzureContainerAppsInfrastructure to add the necessary infrastructure and Bicep files to your AppHost. As an example, consider the following code:

var builder = DistributedApplication.CreateBuilder();
  
var env = builder.AddParameter("env");
  
var api = builder.AddProject<Projects.AspireApi>("api")
    .PublishAsAzureContainerApp<Projects.AspireApi>((infra, app) =>
    {
        app.Template.Containers[0].Value!.Env.Add(new ContainerAppEnvironmentVariable
        {
            Name = "Hello",
            Value = env.AsProvisioningParameter(infra)
        });
    });

The preceding code:

• Creates a new builder instance.
• Adds a parameter named env to the builder.
• Adds a project named api to the builder.
• Calls the PublishAsAzureContainerApp method on the api resource builder, passing a lambda expression that configures the Azure Container App infrastructure—where infra is the AzureResourceInfrastructure and app is the ContainerApp.
  • Adds an environment variable named Hello to the container app, using the env parameter.
  • The AsProvisioningParameter method is used to treat env as either a new ProvisioningParameter in infrastructure, or reuses an existing bicep parameter if one with the same name already exists.

To configure the Azure Container App environment, see Configure Azure Container Apps environments. For information about publishing resources as Azure Container App Jobs, see Azure Container App Jobs. For more information, see Azure.Provisioning.AppContainers.ContainerApp and the AsProvisioningParameter API documentation.

See also

• Local Azure provisioning
• Customize Azure resources
• Azure role assignments
• Aspire integrations overview