Skip to article
Databases Azure Cosmos DB

Cosmos DB serverless account

Cosmos DB serverless account is a Cosmos DB account created with the serverless capacity mode so databases and containers are billed by consumed request units and storage. It turns serverless billing into an account-level design choice rather than a per-container toggle. You see it when teams create accounts for prototypes, seasonal apps, low-duty-cycle workloads, or services with uncertain early demand. The production check is whether the account capacity mode supports the API, scale target, compliance need, and migration plan. Document the decision in code, templates, metrics, and runbooks.

Source: Microsoft Learn - Microsoft Learn - Cosmos DB serverless account Reviewed 2026-05-13

Exam trap
Assuming the portal, SDK code, and infrastructure template all describe the same current production state.
Production check
Verify the active subscription, resource group, account, database, and container before reading or changing any setting.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
6
Last verified
2026-05-13
Learning paths Graph Databases concept cluster Cosmos DB serverless account
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

Cosmos DB serverless account matters because it is the boundary where a product team commits to consumption-style capacity for the Cosmos DB resources inside that account. If it is ignored, teams can create accounts that cannot meet future scale needs, cost models that confuse serverless with autoscale, and environments that drift from production assumptions. Handled well, it gives architects and operators a shared way to connect code behavior, portal settings, CLI output, metrics, and incident runbooks. This is especially important for regulated, multi-tenant, or global workloads where one wrong assumption spreads across users and regions. The practical value is simple: the term turns a database detail into a measurable decision about correctness, cost, latency, recovery, and ownership.

Official wording and source

Cosmos DB serverless account is a Cosmos DB account created with the serverless capacity mode so databases and containers are billed by consumed request units and storage. Microsoft Learn places it in Microsoft Learn - Cosmos DB serverless account; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Cosmos DB serverless account is a Cosmos DB account whose capabilities identify it as serverless; databases and containers live under that account and inherit the capacity model. Inspect it through Azure portal account overview, ARM or Bicep definitions, Azure CLI account properties, cost analysis, metrics, and deployment records. Validate the account capability list, API kind, region configuration, consumed RU charts, storage metrics, alerts, and workload benchmark results. Review API support, region placement, partitioning, restore model, network isolation, identity, and the path to provisioned capacity if the service grows before release.

Exam context

Compare with

Cosmos DB serverless Cosmos DB provisioned throughput Cosmos DB throughput

Where it is used

Where you see it

  1. In the Azure portal, Cosmos DB serverless account appears around account, database, container, metrics, indexing, consistency, networking, or capacity pages where operators confirm current production behavior during releases.
  2. In code and IaC, Cosmos DB serverless account appears as SDK options, resource properties, policy JSON, deployment parameters, query logic, or migration notes that reviewers compare with live resources.
  3. In operations, Cosmos DB serverless account appears beside RU charts, latency, throttling, diagnostics, access failures, restore evidence, cost reviews, and incident tickets during production triage and post-release reviews.
  4. In architecture reviews, Cosmos DB serverless account appears when teams compare Cosmos DB APIs, partition strategy, consistency, retention, capacity mode, and application access patterns.

Common situations

  • Design or review a Cosmos DB workload that depends on serverless account behavior.
  • Troubleshoot latency, throttling, stale reads, indexing, retention, access, recovery, or regional behavior in production.
  • Create architecture, security, or operations evidence for a release, audit, migration, or incident review.

Illustrative Azure scenarios

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

Scenario 01 Operational rollout Scenario, objectives, solution, measured impact, and takeaway.
Scenario

HarborFleet Logistics, a transportation organization, ran a regional dispatch system on Azure Cosmos DB. The team used Cosmos DB serverless account to standardized early-stage product databases on serverless accounts while they needed to keep location and status data fresh for operators.

Goals
  • Improve pilot cost, rollout speed, and evidence for scale decisions with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB serverless account

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created separate serverless accounts for pilot workloads, tagged owners, enabled diagnostics, restricted public access, and compared consumed RUs with projected provisioned-throughput baselines. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • P95 data-access latency improved by 24 percent during the first production verification window
  • Avoidable RU usage or idle capacity dropped by 18 percent after noisy access patterns were corrected
  • Incident handoff time fell from 50 minutes to 28 minutes because owners, dashboards, and rollback triggers were documented
  • The architecture review could be completed with CLI output, deployment records, and metrics in under one hour
What to learn

Cosmos DB serverless account is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Scenario 02 Production remediation Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Summit Mutual, a insurance organization, ran a claims intake workflow on Azure Cosmos DB. The team used Cosmos DB serverless account to standardized early-stage product databases on serverless accounts while they needed to improve audit evidence during regulated releases.

Goals
  • Improve pilot cost, rollout speed, and evidence for scale decisions with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB serverless account

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created separate serverless accounts for pilot workloads, tagged owners, enabled diagnostics, restricted public access, and compared consumed RUs with projected provisioned-throughput baselines. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • Customer-impacting database alerts fell by 41 percent over the next two release cycles
  • The team reduced manual support checks by 36 percent using repeatable diagnostics and dashboard evidence
  • Monthly Cosmos DB spend moved within 7 percent of the forecast after capacity and query behavior were baselined
  • Auditors accepted the change record because identity scope, monitoring, and rollback evidence were attached
What to learn

Cosmos DB serverless account is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Scenario 03 Scale and governance review Scenario, objectives, solution, measured impact, and takeaway.
Scenario

OrionWorks Manufacturing, a manufacturing organization, ran an equipment telemetry application on Azure Cosmos DB. The team used Cosmos DB serverless account to standardized early-stage product databases on serverless accounts while they needed to reduce noisy alerts from plant-floor ingestion spikes.

Goals
  • Improve pilot cost, rollout speed, and evidence for scale decisions with measurable production evidence
  • Reduce incident triage or release-review effort by at least 30 percent
  • Keep customer-facing P95 latency within the approved service target
  • Document rollback, ownership, and security review steps before rollout
Approach using Cosmos DB serverless account

Architects reviewed the Cosmos DB account, API, database, container, partition key, region layout, and monitoring workbook. The implementation created separate serverless accounts for pilot workloads, tagged owners, enabled diagnostics, restricted public access, and compared consumed RUs with projected provisioned-throughput baselines. Engineers used read-only Azure CLI checks, SDK diagnostics, Azure Monitor metrics, and deployment records to compare intended state with live behavior. The rollout kept one workload, explicit owner tags, rollback steps, and a runbook for safe operator inspection. Security reviewers confirmed least privilege and logging, while developers tested with production-shaped data.

Potential outcomes
  • Peak-period requests stayed under the approved latency target while throttling remained below 1 percent
  • Developers cut reproduction time for database issues from several hours to less than 40 minutes
  • The product team avoided a duplicate data platform and saved an estimated 22 percent in operating cost
  • Operations gained a reusable checklist for future Cosmos DB releases using the same pattern
What to learn

Cosmos DB serverless account is valuable when teams connect a Cosmos DB design choice to measurable behavior, ownership, security, cost, and operational proof.

Azure CLI

Use CLI to inspect Cosmos DB serverless account consistently across subscriptions, compare live configuration with source-controlled intent, and capture review evidence without changing the JSON engine or runtime.

Useful for

  • Confirm the account, API, database, container, region, and relevant settings before approving a production change involving Cosmos DB serverless account.
  • Export current configuration for pull requests, incident timelines, architecture reviews, audit evidence, and handoff notes.
  • Compare development, staging, and production when latency, RU usage, access, restore, indexing, or networking behavior differs unexpectedly.

Before you run a command

  • Confirm the active tenant, subscription, resource group, Cosmos DB account name, database name, and container or table scope.
  • Start with read-only commands and avoid throughput, indexing, network, key, delete, or deployment changes unless a change ticket approves them.
  • Capture the expected state, owner, business impact, rollback plan, and maintenance window before modifying production resources.

What the output tells you

  • It shows where Cosmos DB serverless account is configured or observed and whether the live resource matches the intended design.
  • It exposes account, database, container, region, policy, throughput, identity, network, or backup details needed for troubleshooting.
  • It creates repeatable evidence that can be pasted into runbooks, incident summaries, audit records, and release reviews.

Mapped commands

Cosmos DB operations

direct 
az cosmosdb list --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb show --name <account-name> --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql database list --account-name <account-name> --resource-group <resource-group>
az cosmosdb sql databasediscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container list --account-name <account-name> --database-name <database-name> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container show --account-name <account-name> --database-name <database-name> --name <container-name> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb create --name <account-name> --resource-group <resource-group> --capabilities EnableServerless --locations regionName=<region>
az cosmosdbprovisionDatabases
mutating-cost-impacting Microsoft Learn

Architecture context

Architecturally, Cosmos DB serverless account sits inside the Cosmos DB resource model and influences how application code, platform controls, monitoring, and recovery plans meet. Review it with account topology, API selection, partition strategy, throughput, indexes, consistency, identity, networking, backup mode, and deployment source so the design is understandable before an outage or scale event.

Security
Security for Cosmos DB serverless account starts with knowing who can view data, change configuration, or retrieve operational evidence. Use Microsoft Entra identities, managed identities, scoped Cosmos DB data-plane roles, private endpoints, firewall rules, and monitored deployment pipelines wherever they apply. Avoid exposing account keys, connection strings, session tokens, request payloads, or restored data in logs and tickets. For the account owns endpoint exposure, keys, role assignments, diagnostics, private connectivity, and deployment permissions, document approval requirements before production changes. A secure design records the least-privilege role, owner, logging path, break-glass process, and review cadence so troubleshooting does not become an excuse for broad access.
Cost
Cost for Cosmos DB serverless account shows up through request units, storage, indexing overhead, gateway capacity, replication, backups, or nonproduction copies. Measure request-unit consumption, storage, backup usage, region count, dev/test idle time, and any service that should move to provisioned throughput before changing the setting or blaming the platform. A cheap configuration for one workload can be expensive for another when traffic patterns, payload size, indexing, consistency, or partition distribution change. Use tags, budgets, and per-resource dashboards so product owners can see which feature drives spend. The strongest cost review connects dollars to a real behavior, such as RU per read, write amplification, retained data, or fan-out queries.
Reliability
Reliability for Cosmos DB serverless account depends on predictable behavior during load spikes, regional events, deployment changes, and dependency failures. Test regional placement, failover expectations, backup settings, throttling behavior, and the application retry model with realistic data, SDK retry policies, consistency expectations, and Azure Monitor alerts. Operators should know which symptoms indicate throttling, stale reads, bad indexing, expired data, or network failure. Include restore or rollback steps before changing production resources, because Cosmos DB settings often affect more than one application path. The goal is not only service availability; users need correct data, acceptable latency, and a known recovery path when conditions are messy.
Performance
Performance for Cosmos DB serverless account is measured through latency, RU charge, throttling, query plan, cache behavior, and partition distribution. Review capacity ceilings, request charges, partition distribution, consistency choice, SDK connection behavior, and peak-time latency with production-shaped data instead of tiny development samples. SDK diagnostics, Azure Monitor metrics, query metrics, continuation tokens, and response headers should tell the same story. Tune the design only after separating application delays from Cosmos DB configuration. A good performance fix reduces latency or RU waste without weakening security, correctness, indexing accuracy, or recovery. Re-test after deployments because schema, index, consistency, and traffic changes can shift the result.
Operations
Operations for Cosmos DB serverless account should be repeatable enough that a second engineer can verify the same facts without tribal knowledge. Keep account mode, API kind, regions, backup configuration, network rules, diagnostic settings, owner tags, and support contacts documented with deployment source, owner, change history, and dashboard links. Use read-only Azure CLI checks, portal review, SDK diagnostics, and diagnostic logs to compare intended state with live behavior. Runbooks should say what is safe to inspect, what requires approval, and what evidence must be captured before and after a change. Good operations make the term a checked production control, not a hidden implementation choice.

Common mistakes

  • Assuming the portal, SDK code, and infrastructure template all describe the same current production state.
  • Testing Cosmos DB serverless account only with small development data and missing behavior that appears under real distribution or load.
  • Granting broad account permissions just to inspect one setting, troubleshoot one symptom, or run one script.