Databases Azure Cosmos DB

Dedicated container throughput

A database capability or setting in Azure Cosmos DB that helps teams store, query, scale, secure, and recover application data with clearer ownership, safety, and operational context.

Source: Microsoft Learn - Azure Cosmos DB documentation Reviewed 2026-05-03

Exam trap: Treating Dedicated container throughput as an isolated setting instead of checking the surrounding identity, network, data protection, and cost context.
Production check: Can you identify the subscription and resource group that own Dedicated container throughput?

Practice this topic Microsoft Learn

Article details and learning context

Aliases: None listed
Difficulty: intermediate
CLI mappings: 5
Last verified: 2026-05-03

Related context No curated learning path mapped yet; use the category trail.

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Think of Dedicated container throughput as part of the databases operating model. It gives architects, developers, and operators a named way to discuss what must be configured, checked, automated, or monitored before a production change.

Why it matters

Dedicated container throughput matters because databases decisions become production behavior: cost, security, reliability, performance, and supportability all depend on whether the team understands the resource, setting, or pattern before changing it.

Official wording and source

Dedicated container throughput is a Microsoft Learn database capability or setting for Azure Cosmos DB. It affects how teams store, query, scale, secure, and recover application data across relational, NoSQL, cache, and operational data services.

Open Microsoft Learn

Technical context

In Azure, Dedicated container throughput belongs to the Azure Cosmos DB area and usually shows up when a workload crosses resource configuration, identity, networking, data, or operations boundaries. The mapped CLI commands, especially commands near az cosmosdb list, help turn the term from a definition into something you can inventory, verify, automate, or troubleshoot.

Exam context

Compare with

Cosmos DB account Cosmos DB database

Where it is used

Where you see it

Azure Cosmos DB
database account or server overview
connection strings and networking
metrics and diagnostic logs
backup and failover settings

Common situations

Decide how application data is stored, indexed, scaled, cached, and protected.
Troubleshoot connection failures, throughput pressure, indexing, backup, or regional availability.
Explain why one database capability changes cost, latency, consistency, or recovery behavior.
Prepare production changes with source, identity, network, and command context visible.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Using Dedicated container throughput during a production Azure change

Before a team changes a live workload, they can review Dedicated container throughput, check the related terms, run read-only CLI discovery commands, and confirm the Microsoft Learn source. That gives the change owner enough context to decide whether the next step is safe, cost-impacting, security-impacting, or destructive.

Azure CLI

Use Azure CLI for Dedicated container throughput when you need repeatable evidence or automation instead of a one-off portal check. Commands near az cosmosdb list let you inspect current state, script environment setup, compare dev/test/prod, and document exactly what changed.

Useful for

Inspect account, server, database, throughput, replica, or cache configuration quickly.
Automate database provisioning for dev, test, staging, and production.
Capture current settings before changing scale, firewall, backup, or identity configuration.
Script repeatable checks across resource groups when auditing database fleets.

Before you run a command

Run az account show and confirm the tenant, subscription, and user or service principal context.
Confirm the resource group, resource name, and region match the environment you intend to inspect or change.
Prefer read-only discovery commands first; only run mutating, cost-impacting, security-impacting, or destructive commands after review.
Copy command output into a change record or incident notes when the command is used for production evidence.

What the output tells you

Whether Dedicated container throughput exists at the expected Azure scope and under the expected resource owner.
Which location, SKU, identity, network, state, or relationship fields are currently configured.
Whether the command is showing a resource problem, an access problem, a naming/scope problem, or a missing dependency.
What safe follow-up command or related term should be checked next.

Mapped commands

Azure Cosmos DB operations

direct

az cosmosdb list --resource-group <resource-group>

az cosmosdbdiscoverDatabases

az cosmosdb show --name <account-name> --resource-group <resource-group>

az cosmosdbdiscoverDatabases

az cosmosdb create --name <account-name> --resource-group <resource-group>

az cosmosdbprovisionDatabases

az cosmosdb sql database list --account-name <account-name> --resource-group <resource-group>

az cosmosdb sql databasediscoverDatabases

az cosmosdb delete --name <account-name> --resource-group <resource-group>

az cosmosdbremoveDatabases

Architecture context

Dedicated container throughput is a Cosmos DB capacity choice where request units are assigned to one container instead of being shared across a database. It belongs in the data-plane design for workloads with predictable ownership, heavier traffic, or stricter performance isolation. Architects use it when a container has its own partition-key strategy, indexing policy, query profile, and scaling expectations that should not be diluted by neighboring containers. The decision affects cost, hot-partition risk, autoscale behavior, and troubleshooting because RU consumption can be observed and tuned at the container boundary. It is especially useful when one business workload, tenant group, or API route would otherwise starve smaller containers sharing database throughput.

Security: Check identity, firewall, private endpoint, key, and data-plane access before connecting clients.
Cost: Watch throughput, compute tier, storage, backups, replicas, and cache nodes.
Reliability: Validate backup, failover, consistency, geo-replication, and recovery objectives.
Performance: Review indexing, partitioning, query shape, cache usage, and provisioned capacity before scaling.
Operations: Keep schema, settings, scale operations, and diagnostic checks repeatable and source-linked.

Common mistakes

Treating Dedicated container throughput as an isolated setting instead of checking the surrounding identity, network, data protection, and cost context.
Running mutating or destructive CLI commands without confirming subscription, resource group, and target resource names.
Treating Dedicated container throughput as just a label instead of checking the Azure scope, owner, and resource that it affects.
Running a mutating or destructive CLI command before confirming the active subscription, resource group, and target name.