Share via

Plan an Azure managed application for an Azure application offer

  • Article

An Azure managed application plan is one way to publish an Azure application offer in the Commercial Marketplace. If you haven't already done so, read Plan an Azure Application offer for the commercial marketplace. Managed applications are transactable offers that are deployed and billed via Marketplace. Use Managed application plans to provide and monetize managed services.

Managed application offer requirements

Requirements Details
Billing and metering The resources are provided in a customer's Azure subscription. VMs that use the pay-as-you-go payment model are transacted with the customer via Microsoft and billed via the customer's Azure subscription.

For bring-your-own-license VMs, Microsoft bills any infrastructure costs that are incurred in the customer subscription, but you transact software licensing fees with the customer directly.
Customer usage attribution For more information about customer usage attribution and how to enable it, see Azure partner customer usage attribution.
Deployment package You'll need a deployment package that will let customers deploy your plan. If you create multiple plans that require the same technical configuration, you can use the same package. For details, see the next section: Deployment package.

Note

Managed applications must be deployable through Azure Marketplace. If customer communication is a concern, reach out to interested customers after you've enabled lead sharing.

Deployment package

The deployment package contains all the template files needed for this plan, as well as any additional resources, packaged as a .zip file.

All Azure applications must include these two files in the root folder of a .zip archive:

Note

The deployment package must not include binaries such as Virtual Machine images. All images deployed by the Azure Application must be images referenced from marketplace. Make sure your offer is compliant with our recommended practices by using the ARM template test toolkit before publishing your Azure Application.

Azure regions

You can publish your plan to the Azure public region, Azure Government region, or both. Before publishing to Azure Government, test and validate your plan in the environment as certain endpoints might differ. To set up and test your plan, request a trial account from Microsoft Azure Government trial.

You, as the publisher, are responsible for any compliance controls, security measures, and best practices. Azure Government uses physically isolated data centers and networks (located in the U.S. only).

For a list of countries and regions supported by the commercial marketplace, see Geographic availability and currency support.

Azure Government services handle data that is subject to certain government regulations and requirements. For example, FedRAMP, NIST 800.171 (DIB), ITAR, IRS 1075, DoD L4, and CJIS. To bring awareness to your certifications for these programs, you can provide up to 100 links that describe them. These can be either links to your listing on the program directly or links to descriptions of your compliance with them on your own websites. These links visible to Azure Government customers only.

Choose who can see your plan

You can configure each plan to be visible to everyone (public) or to only a specific audience (private). You can create up to 100 plans and up to 45 of them can be private. You might want to create a private plan to offer different pricing options or technical configurations to specific customers.

You grant access to a private plan using Azure subscription IDs with the option to include a description of each subscription ID you assign. You can add a maximum of 10 subscription IDs manually or up to 10,000 subscription IDs using a .CSV file. Azure subscription IDs are represented as GUIDs and letters must be lowercase.

Private plans aren't supported with Azure subscriptions established through a reseller of the Cloud Solution Provider program (CSP). For more information, see Private offers in the Microsoft commercial marketplace.

Note

If you publish a private plan, you can change its visibility to public later. However, once you publish a public plan, you can't change its visibility to private.

Define pricing

Note

Pricing for your Managed Application using the per-month and metered billing price must only account for the management fee and may not be used for IP/software costs, Azure infrastructure, or add-ons. Use the underlying Virtual Machine or Container Offer to transact IP/software costs. You must provide the per-month price for each plan. This price is in addition to any Azure infrastructure or pay-as-you-go software costs incurred by the resources deployed by this solution. In addition to the per-month price, you can also set prices for consumption of non-standard units using metered billing. You can set the per-month price to zero and charge exclusively using metered billing.

Prices are set in USD (USD = United States Dollar) and are converted into the local currency of all selected markets using the current exchange rates when saved. Pricing is published in local currency and isn't updated as exchange rates fluctuate. To specify customer prices for each market, export the prices from the pricing and availability page, update the respective market and currency, save, and import the file. For more information, see How we convert currencies.

Publisher Management

Enabling management access gives publisher access to the managed resource group that hosts your application in the customer tenant. If you choose to enable publisher management access, you will need to specify the Azure tenant and Principal ID that will manage the application.

Note

Publisher management can't be modified after the plan is published to live in marketplace.

Just in time (JIT) access

JIT access enables you to request elevated access to a managed application's resources for troubleshooting or maintenance. You always have read-only access to the resources, but for a specific time period you can have greater access. For more information, see Enable and request just-in-time access for Azure Managed Applications.

Note

Be sure to update your createUiDefinition.json file in order to support this feature.

Choose who can manage the application

This option is only available when Publisher Management is enabled.

When Publisher Management is enabled you must indicate who can manage a managed application in each of the selected clouds: Public Azure and Azure Government Cloud. Collect the following information:

  • Microsoft Entra tenant ID – The Microsoft Entra tenant ID (also known as directory ID) containing the identities of the users, groups, or applications you want to grant permissions to. You can find your Microsoft Entra tenant ID on the Azure portal, in Properties for Microsoft Entra ID.
  • Authorizations – Add the Microsoft Entra object ID of each user, group, or application that you want to be granted permission to the managed resource group. Identify the user by their Principal ID, which can be found at the Microsoft Entra users blade on the Azure portal.

For each principal ID, you will associate one of the Microsoft Entra built-in roles (Owner or Contributor). The role you select describes the permissions the principal will have on the resources in the customer subscription. For more information, see Azure built-in roles. For more information about role-based access control (RBAC), see Get started with RBAC in the Azure portal.

Note

Although you can add up to 100 authorizations per Azure region, we recommend you create an Active Directory user group and specify its ID in the "Principal ID." This lets you add more users to the management group after the plan is deployed and reduces the need to update the plan just to add more authorizations.

Customer access

Enabling customer access gives customers full access to the managed resource group deployed to their Azure tenant. Restricting Access with deny assignments disables customer access to the managed resource group in their Azure tenant. Note that Disabling customer access with deny assignment removes customer access but allows publishers to customize allowed customer actions.

Note

Customer Access can't be modified after the offer is live in marketplace.

Deployment mode

You can configure a managed application plan to use either the Complete or Incremental deployment mode. In complete mode, a redeployment of the application by the customer results in removal of resources in the managed resource group if the resources aren't defined in the mainTemplate.json. In incremental mode, a redeployment of the application leaves existing resources unchanged. To learn more, see Azure Resource Manager deployment modes.

Notification endpoint URL

You can optionally provide an HTTPS Webhook endpoint to receive notifications about all CRUD operations on managed application instances of a plan.

Azure appends /resource to the end of your webhook URI before calling it. So, your webhook URL must end in /resource, although it should not be included in the URI entered into the Notification Endpoint URL box in Partner Center. For example, entering https://contoso.com as the Notification Endpoint URI results in a call to https://contoso.com/resource.

When listening for events from your managed app notifications, make sure you listen to https://<url>/resource and not the set URL alone. For a sample notification, see Notification schema.

Customize allowed customer actions (optional)

You can optionally specify which actions customers can perform on the managed resources in addition to the */read actions that is available by default.

If you choose this option, you need to provide either the control actions or the allowed data actions, or both. For more information, see Understanding deny assignments for Azure resources. For available actions, see Azure Resource Manager resource provider operations. For example, to permit consumers to restart virtual machines, add Microsoft.Compute/virtualMachines/restart/action to the allowed actions.

Policy settings

You can apply Azure Policies to your managed application to specify compliance requirements for the deployed solution. For policy definitions and the format of the parameter values, see Azure Policy Samples.

You can configure a maximum of five policies, and only one instance of each Policy type. Some policy types require additional parameters.

Policy type Policy parameters required
Azure SQL Database Encryption No
Azure SQL Server Audit Settings Yes
Azure Data Lake Store Encryption No
Audit Diagnostic Setting Yes
Audit Resource Location compliance No

For each policy type you add, you must associate Standard or Free Policy SKU. The Standard SKU is required for audit policies. Policy names are limited to 50 characters.

Related content

Video tutorial