Skip to article
Databases Azure Cosmos DB

Dedicated gateway

Dedicated gateway is documented by Microsoft as part of the Azure Cosmos DB area in Azure.

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

Exam trap
Treating Dedicated gateway as isolated instead of checking its resource group, identity, networking, monitoring, and cost impact.
Production check
Can you identify the subscription and resource group that own Dedicated gateway?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
intermediate
CLI mappings
11
Last verified
2026-05-03
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Think of Dedicated gateway 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 gateway 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.

Technical context

In Azure, Dedicated gateway 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 sql, help turn the term from a definition into something you can inventory, verify, automate, or troubleshoot.

Exam context

Compare with

Azure Cosmos DB Database

Where it is used

Where you see it

  1. Azure Cosmos DB
  2. database account or server overview
  3. connection strings and networking
  4. metrics and diagnostic logs
  5. 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 gateway during a production Azure change

Before a team changes a live workload, they can review Dedicated gateway, 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 gateway when you need repeatable evidence or automation instead of a one-off portal check. Commands near az cosmosdb sql 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 gateway 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

Cosmos operations

direct 
az cosmosdb list --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb show --name <account> --resource-group <resource-group>
az cosmosdbdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb create --name <account> --resource-group <resource-group> --locations regionName=<region>
az cosmosdbprovisionDatabases
cost-impacting Microsoft Learn 
az cosmosdb update --name <account> --resource-group <resource-group> --enable-automatic-failover true
az cosmosdbconfigureDatabases
mutating Microsoft Learn 
az cosmosdb keys list --name <account> --resource-group <resource-group>
az cosmosdb keysdiscoverDatabases
security-impacting Microsoft Learn 
az cosmosdb sql database list --account-name <account> --resource-group <resource-group>
az cosmosdb sql databasediscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql database create --account-name <account> --resource-group <resource-group> --name <database>
az cosmosdb sql databaseprovisionDatabases
cost-impacting Microsoft Learn 
az cosmosdb sql container list --account-name <account> --resource-group <resource-group> --database-name <database>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container create --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --partition-key-path <path>
az cosmosdb sql containerprovisionDatabases
cost-impacting Microsoft Learn 
az cosmosdb sql container throughput show --account-name <account> --resource-group <resource-group> --database-name <database> --name <container>
az cosmosdb sql container throughputdiscoverDatabases
read-only Microsoft Learn 
az cosmosdb sql container throughput update --account-name <account> --resource-group <resource-group> --database-name <database> --name <container> --throughput <ru>
az cosmosdb sql container throughputconfigureDatabases
cost-impacting Microsoft Learn

Architecture context

In Cosmos DB for NoSQL, a dedicated gateway is an architectural layer between clients and the account that provides gateway compute and integrated cache behavior separate from direct data access. It is not a replacement for good partitioning or indexing; it is a read-path design option for workloads where repeated point reads or queries can benefit from cached responses and a stable gateway endpoint. Architects evaluate it alongside consistency expectations, cache staleness tolerance, private endpoints, client SDK configuration, and RU usage on the backend containers. The gateway becomes part of the reliability and scaling plan because its SKU, regional placement, and endpoint path influence latency, cache hit ratio, and failure troubleshooting.

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 gateway as isolated instead of checking its resource group, identity, networking, monitoring, and cost impact.
  • Changing Dedicated gateway in production without reviewing the matching Microsoft Learn source and command safety labels.
  • Treating Dedicated gateway 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.