Inside Logic Apps Standard: Understanding Compute Units (CU) for Storage Scaling

Source: Dev.to

Introduction

When your Logic App Standard workflows grow in volume and complexity, Azure provides a powerful horizontal‑scaling mechanism through Compute Units (CU). This post explains how CU architecture enables Logic Apps to distribute storage load across multiple storage accounts while maintaining data consistency and routing integrity.

Why Storage Scaling Matters

A single Azure Storage account has inherent limits:

Note: Exceeding these thresholds triggers request throttling.

When a Logic App processes thousands of runs, each with dozens of actions, a single storage account can become a bottleneck very quickly.

Guidance from Microsoft

• ≈ 100 K action executions per minute per storage account is the recommended threshold for evaluating additional storage.
• Compute‑heavy workflow actions may reduce this threshold considerably, so monitor usage closely.

What Are Compute Units?

Compute Units (also called Scale Units) are Azure Logic Apps’ mechanism for horizontal storage scaling. Instead of overloading a single storage account with all workflow‑execution data, Logic Apps can spread the load across up to 32 storage accounts (CU00 through CU31).

How to configure

Add the Runtime.ScaleUnitsCount setting to your host.json file:

{
  "runtime": {
    "scaleUnitsCount": 4   // Number of compute units (1‑32)
  }
}

• Replace 4 with the desired number of compute units (minimum 1, maximum 32).
• The value determines how many storage accounts the runtime will provision and use.

Single‑Storage Architecture

In the simplest deployment, all workflows use a single storage account:

Logic App → CU00 (Master) → Single Storage Account

With a single storage account:

• All workflow definitions, runs, and actions reside in one storage account.
• The storage account uses the CU00 suffix.
• This setup works well for low‑to‑moderate workloads.

Scale‑Out Storage Architecture

When a Logic App must handle high‑volume workflows, it can scale out by using multiple storage accounts—one per compute unit. This enables parallel reads and writes across many storage endpoints.

Logic App → CU00 (Master) → Storage Account 1
         → CU01           → Storage Account 2
         → CU02           → Storage Account 3
         → …              → …
         → CU31           → Storage Account 32

Each compute unit (CU) maps to its own dedicated storage account, allowing the Logic App to distribute load across up to 32 storage endpoints.

How CU Routing Works

The key to this architecture is the Run ID. Every workflow run includes a CU suffix that identifies which storage account contains its action data:

08584345852018133305811297792-CU00
08584345852018133305811297793-CU01
08584345852018133305711297794-CU02

Routing Steps

1. Extract CU suffix from the Run ID (e.g., -CU01).
2. Lookup the storage‑account mapping for the Logic App + CU combination.
3. Query the appropriate storage account for the action data.

This ensures that when you request run details, the system knows exactly which storage account to query.

Table Distribution Across CUs

Not all tables are distributed the same way. The distinction is shown below:

Two Different Assignment Mechanisms

1. Workflow Tables (ScaleUnit field)

• When you deploy a new workflow, Logic Apps assigns it to a Compute Unit (CU).
• Non‑deterministic from the developer’s perspective – you cannot specify “put this workflow on CU02”.
• Decided at deployment time – as soon as a workflow is added, Logic Apps picks a CU.
• The assignment is stored in the workflow’s metadata (ScaleUnit column in the flows table).

The workflow’s flows, runs, and histories tables all reside in the storage account that belongs to the assigned CU.

2. Action Tables (RunId‑CUXX suffix)

Action tables are distributed per‑run, not per‑workflow. Each run execution gets its own CU, which is reflected in the RunId suffix:

08584345852018133305811297792-CU01
08584345852115148130432249577-CU00

Consequences

• A single workflow’s actions can be spread across multiple CU storage accounts.
• On any given date you may see action tables for the same workflow in CU00, CU01, CU02, etc.

Each storage account creates its own date‑stamped action table, e.g.:

{WFIdentifier}20250114T000000Zactions

Example: Distributed Actions

For a workflow with ScaleUnit = CU00, runs may execute across different compute units (CUs):

Workflow: MyWorkflow (ScaleUnit = CU00)

Run 1 → RunId‑CU00 → actions stored in Storage Account CU00
Run 2 → RunId‑CU01 → actions stored in Storage Account CU01
Run 3 → RunId‑CU02 → actions stored in Storage Account CU02

Thus, while the workflow definition resides in CU00, its action data can be scattered across any of the provisioned compute units, enabling true horizontal scaling of storage I/O.

Metadata (flows, runs, histories) → CU00 storage

Runs

Example (January 14 2025)

On this date the workflow could have action tables in three different storage accounts:

• CU00: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU01: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
• CU02: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions

What This Means

• App‑level metadata stays centralized – Base tables remain in CU00 (the master).
• Workflow metadata has a home – flows, runs, and histories live in the workflow’s assigned CU.
• Actions are truly distributed – Action data spreads across CUs based on the run execution.
• Query complexity increases – To retrieve all actions for a date range, you may need to query multiple storage accounts.

Why This Matters

For High‑Volume Workflows

If a Logic App processes thousands of runs daily, each run may execute dozens of actions. Without CU distribution:

• A single storage account becomes a bottleneck.
• Table‑partition limits can throttle performance.
• Query latency grows as tables become larger.

With CU distribution:

• Write operations are spread across multiple endpoints.
• Each storage account handles only a fraction of the load.
• Queries can be directed straight to the relevant storage account.

For Run‑History Queries

When building tooling that queries run history (e.g., export utilities or monitoring dashboards), you must account for CU routing:

1. Parse the Run ID to extract the CU suffix.
2. Resolve the correct storage account for that CU.
3. Query the CU‑specific storage for action data.

Ignoring CU routing will cause missing action data.

Configuring Scale Units

To enable multiple storage accounts, add the following to host.json:

{
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.ScaleUnitsCount": 4
      }
    }
  }
}

This tells Logic Apps to use four storage accounts (CU00‑CU03). You must provision the additional storage accounts and configure their connection strings or managed‑identity access.

Authentication options

• Connection strings in app settings.
• Managed identity (recommended for production).

Summary

• Compute Units (CUs) enable Logic Apps Standard to scale storage horizontally.
• CU00 is the master unit that holds app‑level base tables.
• Workflow tables (flows, runs, histories) reside in the CU indicated by the ScaleUnit field.
• Action tables are sharded per run using the RunId‑CUXX suffix.
• A single workflow’s actions can span multiple storage accounts.
• Configure the number of CUs with Runtime.ScaleUnitsCount in host.json (maximum 32).
• Threshold guidance: ~100 K action executions per minute per storage account.

Understanding this architecture is essential when:

• Building tooling around Logic Apps.
• Querying run histories programmatically.
• Troubleshooting high‑volume workflow performance.

References

• Scaling Logic App Standard for high‑throughput scenarios – Microsoft Tech Community

This article is part of the “Inside Logic Apps Standard” series, exploring the internals of Azure Logic Apps Standard architecture.