Azure News - 2026-07-30

1. The Core Mental Model: The Water Park Analogy

To understand Copilot billing, think of your enterprise as a water park:

• The Shared Pool (Included Usage): Every Copilot Business ($19/mo) and Enterprise ($39/mo) seat license adds a set number of free AI credits into a shared corporate water tank (1,900 or 3,900 credits/seat, respectively).
• Phase 1 (Pool Phase): All licensed developers drink from this central pool for free until it runs empty.
• Phase 2 (Metered Overage): Once the pool is dry, extra water costs $0.01 per credit. This phase only activates if your enterprise explicitly enables the "AI Credit Paid Usage" policy.
• User-Level Budgets (ULBs): Personal wristbands limiting how much water one person can consume across both Phase 1 and Phase 2 combined.
• Group / Enterprise Budgets: Group bar tabs that kick in only during Phase 2 to cap overage spending.

2. How GitHub Evaluates Requests (The 3-Step Decision Flow)

Every time a developer uses an AI credit feature (like GitHub Copilot Chat or custom Agents), GitHub evaluates the request through a 3-step hierarchy:

Step 1: The Personal Guardrail (User-Level Budgets)

ULBs cap total consumption (Pool + Metered). These are always hard stops. The system selects the most specific rule:

1. Individual ULB: Overrides everything (e.g., $50 for a Lead Data Scientist).
2. Cost Center ULB: Overrides Universal (e.g., $20/dev for Engineering, $5/dev for Marketing).
3. Universal ULB: The global baseline for all licensed users.

Step 2: The Included Pool Check

If the user hasn't hit their ULB, the system checks if pooled credits remain. You can also configure Included Usage Controls on Cost Centers to ring-fence a team's pool draw to match their contributed seats.

Step 3: Group & Enterprise Overage Caps

Once the pool is empty, metered charges begin ($0.01/credit). The system checks overage budgets in order:

1. Cost Center Budget
2. Organization Budget
3. Enterprise Budget

⚠️ Critical FinOps Note: Group/Enterprise budgets do NOT stop usage by default. You must explicitly enable the setting:

Stop usage when budget limit is reached

Without this setting toggled ON, overage charges will accrue uncapped!

3. Key Takeaways & Common Pitfalls

The "Lowest Headroom Wins" Rule

If a developer has $10 remaining on their personal ULB, but the Enterprise Overage Budget only has $1 left before hitting its limit, the Enterprise limit will block the user. Whichever budget hits its ceiling first wins.

What Gets Blocked vs. What Keeps Working?

When a developer hits a budget limit:

• ❌ Blocked: Copilot Chat, CLI, Agents, and complex reasoning models (anything consuming AI credits).
• ✅ Unblocked: Standard inline code completions and next edit suggestions (included free with seat licenses).

Conclusion: Best Practices for Admins

1. Establish a Universal ULB First: Set a reasonable baseline (e.g., $10–$15/user) to ensure fair pool access.
2. Use Cost Center ULBs for Group Granularity: Avoid managing thousands of individual budgets by setting per-user caps at the Cost Center level.
3. Always Turn On "Stop Usage": Ensure your enterprise and cost center overage budgets have the hard stop toggle enabled to prevent unexpected monthly bills.
4. Isolate R&D with Cost Center Exclusion: Use exclusion rules for teams that require independent spending authority outside the general enterprise cap.

Azure Container Apps Jobs are a good fit for batch processing, ETL, machine learning, reports, and other tasks that run to completion. But when those tasks have dependencies, retries, or fan-out, you still need an orchestrator.

Many teams already have one. The community-maintained Bring Your Own Orchestrator collection provides 13 templates that connect existing workflow engines to Azure Container Apps Jobs. The collection is also listed in the Microsoft Azure Container Apps template index.

The idea is simple:

• Your orchestrator manages schedules, dependencies, retries, and workflow history.
• Azure Container Apps Jobs runs each containerized task and reports the result.

You keep the control plane your team knows while ACA Jobs provides the execution layer.

How it works

Each integration follows the same flow:

1. The orchestrator authenticates to Azure.
2. It starts an ACA Job execution.
3. It waits for that execution to succeed or fail.
4. It uses the result to continue, retry, or stop the workflow.

Your orchestrator  --->  Azure Container Apps Job
  ^                         |
  +---- execution result ---+

The templates package this flow in the native model of each platform: an Airflow operator, a Temporal Activity, an Argo workflow template, a Camunda service task, or visual actions in Logic Apps and n8n.

The workload container stays independent of the orchestrator that launched it.

Choose the orchestrator that fits the workflow

There is no single best orchestrator for every workload. The useful question is which control plane matches the way your team models work.

The Bring Your Own Orchestrator catalog keeps this comparison current and links to deployment instructions for every option.

Before production

The existing-orchestrator templates are designed around managed identity, scoped Azure RBAC, failure handling, and native fan-out/fan-in examples. Their fan-out samples default to five shards and accept configurations from 1 to 50.

Treat higher shard counts as configuration support, not a throughput guarantee. Test them against your Azure quotas, orchestrator limits, and downstream systems.

Two template-specific boundaries are worth calling out:

Dapr Workflow is a preview architecture

Azure Container Apps Jobs do not host Dapr sidecars. The Dapr workflow runtime must run in a separate Dapr-enabled host and start ACA Jobs through Azure Resource Manager. The template is therefore labeled preview architecture.

Fabric still needs a native workspace run

The Azure Data Factory path has live validation. The included Fabric pipeline is structurally validated but still needs a native run in a Fabric workspace.

Each repository README documents its validation scope and limitations.

Get started

1. Open the template catalog.
2. Choose the orchestrator your team already uses.
3. Review that template's prerequisites and validation notes.
4. Deploy the sample ACA Job with azd up.
5. Run the single-job example, then test fan-out and failure behavior.

For example, if Airflow is already your standard:

git clone https://github.com/hetvip2/airflow-on-aca-jobs
cd airflow-on-aca-jobs
azd up

The exact setup differs by orchestrator, but the target remains ACA Jobs.

Try the templates

• Compare all 13 orchestrator templates and choose the control plane that matches your team.
• Review the Azure Container Apps Jobs documentation for triggers, permissions, and platform limits.
• Browse the ACA community template collections to find the collection in the Microsoft Azure Container Apps repository.

Closing thoughts

Using Azure Container Apps Jobs should not require an orchestrator migration. Keep the workflow engine your team already trusts and use ACA Jobs for containerized task execution.

Explore all 13 options in the Bring Your Own Orchestrator to Azure Container Apps Jobs collection.

References

1. Azure Container Apps Jobs overview
2. Azure Container Apps Jobs management API
3. Managed identities in Azure Container Apps
4. Azure Developer CLI documentation
5. Bring Your Own Orchestrator template catalog
6. Azure Container Apps community template collections