Architectural approaches for cost management and allocation in a multitenant solution

Multitenant solutions often require special consideration when you measure and allocate costs, and when you optimize costs. On this page, we describe some key guidance for solution architects to consider about the measurement, allocation, and optimization of costs for a multitenant application.

Key considerations and requirements

Consider the requirements you have for measuring the consumption for your solution. This is discussed in more detail on Measure the consumption of each tenant.

Purpose of measurement

It's important to decide what your goal is. The following are examples of goals:

• Calculate an approximate cost of goods sold for each tenant. For example, if you deploy a significant number of shared resources, you might only be interested in a rough approximation of the cost incurred for each tenant.
• Calculate the exact cost incurred by each tenant. For example, if you charge your tenants for the exact amount of consumption they incur, you need to have precise information about how much each tenant's resources cost.
• Identify outlier tenants that cost significantly more than others. For example, if you provide a flat-rate pricing model, you might need to determine whether any tenants are consuming a disproportionate amount of your provisioned capacity, so that you can apply fair-use policies. In many situations, this use case doesn't require precise measurement of costs.
• Reduce the overall Azure cost for your solution. For example, you might want to look at the cost of every component, and then determine whether you have over-provisioned for the workload.

By understanding the goal of measuring the consumption by a tenant, you can determine whether the cost allocations need to be approximate or highly precise, which affects the specific tools you can use and the practices you can follow.

Shared components

You might be able to reduce the cost of a multitenant solution by moving tenants to shared infrastructure. However, you need to carefully consider the impact of sharing resources, such as whether your tenants will begin to experience the Noisy Neighbor problem.

You also need to consider how you measure and allocate the costs of shared components. For example, you can evenly divide the cost between each of the tenants that use the shared component. Or, you can meter each tenant's usage to get a more precise measurement of their consumption of shared components.

Approaches and patterns to consider

Azure enables you to apply tags to your resources. A tag is a key-value pair. You use tags to add custom metadata. Tags are useful for many management operations, and they're also useful for analyzing the cost of your Azure consumption. After you apply tags, you can determine costs associated with each tag.

The way you use tags in a multitenant solution is likely to be different, depending on your architecture.

In some solutions, you might deploy dedicates resources for each tenant, such as if you deploy dedicated Deployment Stamps for each tenant. In these situations, it's clear that any Azure consumption for those resources should be allocated to that tenant, and so you can tag your Azure resources with the tenant ID.

In other situations, you might have sets of shared resources. For example, when you apply the Sharding pattern, you might deploy multiple databases and spread your tenants across them. Consider tagging the resources with an identifier for the group of tenants. You might not be able to easily allocate costs to a single tenant, but you can at least narrow down the cost to a set of tenants, when you use this approach. You can also use the consumption information to help you rebalance tenants across the shards, if you notice that a specific shard is accruing higher costs than the others.

The tagging strategy employed here is as follows:

• Every resource has a stamp-id tag.
• Every sharded database has a shard-id tag.
• Every resource dedicated to a specific tenant has a tenant-id tag.

With this tagging strategy, it's easy to filter the cost information to a single stamp. It's also easy to find the cost of the tenant-specific resources, such as the total cost of the database for tenant C. Shared components don't have a tenant-id tag, but the cost of the shared components for a stamp can be divided between the tenants who are assigned to use that stamp or shard.

Instrument your application

In situations where you don't have a direct relationship between an Azure resource and a tenant, consider instrumenting your application to collect telemetry.

Your application tier may already collect logs and metrics that are helpful to answer the following questions, for example:

• Approximately how many API requests are made per tenant?
• What times of the day are specific tenants busiest?
• How do tenant A's usage patterns compare to tenant B's usage patterns?

In Azure, these metrics are often captured by Application Insights. By using telemetry initializers, you can enrich the telemetry captured by Application Insights, to include a tenant identifier or other custom data.

However, Application Insights and other logging and monitoring solutions are not appropriate for precise cost measurement or for metering purposes. Application Insights is designed to sample data, especially when your application has a high volume of requests. Sampling is designed to reduce the cost of monitoring your solution, because capturing every piece of telemetry can often become expensive.

If you need to track precise details about consumption or usage for billing purposes, you should instead build a custom pipeline to log the necessary data. You should then aggregate the data, based on your requirements. Azure services that can be helpful for this purpose include Event Hubs, to capture large volumes of telemetry, and Stream Analytics, to process it in real time.

Use Azure Reservations to reduce costs

Azure Reservations enable you to reduce your Azure costs by pre-committing to a certain level of spend. Reservations apply to a number of Azure resource types.

Reservations can be used effectively in a multitenant solution. Note the following considerations:

• When you deploy a multitenant solution that includes shared resources, consider the baseline level of consumption that you need for the workload. You might consider a reservation for that baseline consumption, and then you'd pay standard rates for higher consumption during unpredictable peaks.
• When you deploy resources for each tenant, consider whether you can pre-commit to the resource consumption for a specific tenant, or across your portfolio of tenants.

Azure Reservations enables you to scope your reservations to apply to a resource group, a subscription, or a set of subscriptions. This means that you can take advantage of reservations, even if you shard your workload across multiple subscriptions.

Reservation scopes can also be helpful, when you have tenants with unpredictable workloads. For example, consider a solution in which tenant A only needs one instance of a specific resource, but tenants B and C each need two. Then tenant B becomes less busy, so you reduce the instance count, and tenant A gets busier, so you increase the instance count. Your reservations are applied to the tenants that need them.

Antipatterns to avoid

• Not tracking costs at all. It's important to have at least an approximate idea of the costs you're incurring, and how each tenant impacts the cost of delivering your solution. Otherwise, if your costs change over time, you have no baseline to compare against.
• Making assumptions or guessing. Ensure your cost measurement is based on real information. You might not need a high degree of precision, but even your estimates should be informed by real measurements.
• Unnecessary precision. You may not need to have a detailed accounting of every cost that's incurred for every tenant. Building unnecessarily precise cost measurement and optimization processes can be counterproductive, which adds engineering complexity and creates brittle processes.
• Real-time measurement. Most solutions don't need up-to-the-minute cost measurements. Because metering and consumption data can be complex to process, you should log the necessary data and then asynchronously aggregate and process the data later.
• Using monitoring tools for billing. As described in Instrument your application, ensure you use tools that are designed for cost monitoring and metering. Application monitoring solutions are typically not good candidates for this type of data, especially when you need high precision.

Original Post>