Redis and Partner Databases on Azure

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Examples on this page target Azure CLI 2.90.0 — re-verify exact flag names and command-group status against the Azure CLI release notes before relying on them, since the elastic and monitor account command groups in particular have moved quickly over the last few release cycles.

This page covers the databases and search/observability services Bookshelf reaches on Azure without running the database software itself end to end: Azure’s own first-party Redis offering (kept concise here, with the deep Redis coverage left to Deploying Redis on Azure), Elastic Cloud on Azure, four data-platform partners sold through Azure Marketplace (Couchbase Capella, Neo4j AuraDB, Qdrant Cloud, MongoDB Atlas), a brief look at self-hosting the same class of engines on AKS with operators and Helm when a managed offering doesn’t fit, and Azure Monitor managed Prometheus with Managed Grafana for observing whichever of these Bookshelf chooses. See Managed Databases on Azure for how these options compare against Azure’s own first-party managed databases (Azure Database for PostgreSQL, Cosmos DB, and the rest).

Azure Managed Redis, briefly

Azure Managed Redis (AMR) is Azure’s current first-party Redis offering, built on Redis Enterprise rather than the community edition the older, retiring Azure Cache for Redis was built on. It picks a tier at creation — Memory Optimized, Balanced, Compute Optimized, or Flash Optimized (trading RAM footprint for a much larger, flash-backed dataset with a reduced module set) — and a clustering policy (OSSCluster by default, EnterpriseCluster for clients that aren’t cluster-aware, or NoCluster up to 25 GB), neither of which can be changed after creation. Alongside legacy access keys, it authenticates over Microsoft Entra ID — a managed identity or service principal authenticates directly, with no long-lived shared key in configuration — and its endpoint listens on port 10000, not Redis’s usual 6379. Azure Cache for Redis, the older fork-of-Redis-OSS offering, is retiring in two waves (Enterprise/Enterprise Flash on March 31, 2027; Basic/Standard/Premium on September 30, 2028), so a new deployment should default to Azure Managed Redis rather than the legacy service.

In the Azure portal

  1. Select Create a resource, search for Azure Managed Redis, and select Create.

  2. On Basics, choose the subscription, resource group rg-bookshelf, Name redis-bookshelf, Region East US 2, then Data tier In-memory with a Cache Size and Performance combination that lands on the Balanced tier (the portal’s equivalent of Balanced_B1 below). The resulting host name is redis-bookshelf.eastus2.redis.azure.net.

  3. On Networking, pick Disable public access and use private access (then add a private endpoint into the Bookshelf VNet, see Virtual Networks) or Enable public access from all networks for a quick test.

  4. Skip Active geo-replication unless it’s needed — it can only be enabled at creation time.

  5. On Advanced, set Clustering policy to OSS (or Enterprise for RediSearch or non-cluster-aware clients, Non-clustered for small single-shard caches) and add any modules now, since neither can be changed later. Leave Microsoft Entra authentication on and Access Keys Authentication off, which are the defaults for a new cache.

  6. Select Review + create, then Create; the cache is ready when Status on Overview shows Running.

  7. Under Settings > Authentication > Microsoft Entra Authentication, select User or service principal, then + Select member, and add the managed identity the Bookshelf workload runs as.

This derives from Quickstart: Create an Azure Managed Redis instance and Use Microsoft Entra for cache authentication with Azure Managed Redis.

With the Azure CLI

export RG=rg-bookshelf
export LOCATION=eastus2

az group create --name "$RG" --location "$LOCATION"

az redisenterprise create \
  --cluster-name redis-bookshelf \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --sku Balanced_B1 \
  --minimum-tls-version "1.2" \
  --clustering-policy OSSCluster \
  --client-protocol Encrypted \
  --high-availability Enabled \
  --port 10000

# Grant the workload's managed identity data-plane access (preview command group);
# IDENTITY_PRINCIPAL_ID is its object (principal) ID
az redisenterprise database access-policy-assignment create \
  --resource-group "$RG" \
  --cluster-name redis-bookshelf \
  --database-name default \
  --access-policy-assignment-name bookshelfapi \
  --access-policy-name default \
  --object-id "$IDENTITY_PRINCIPAL_ID"

--sku picks the tier and size together (Balanced_B1, MemoryOptimized_M10, ComputeOptimized_X10, FlashOptimized_A250, …​). Entra-based data-plane access isn’t an Azure RBAC role assignment: it’s a per-database access policy assignment that maps the identity’s object ID (from Identity and Access) to a Redis user, with the default policy granting all commands and keys. az redisenterprise test-connection --name redis-bookshelf --resource-group "$RG" then checks the signed-in identity can reach the cache. The full tier/module matrix, active geo-replication, persistence (RDB/AOF), private endpoints, the Bicep template, and the Spring Boot redis-authx-entraid connection example (Jedis and Lettuce, both over DefaultAzureCredential, never a connection string) are covered in depth on Deploying Redis on Azure — this page only names the resource (redis-bookshelf) so the rest of Bookshelf’s Azure examples can reference it. See What is Azure Managed Redis? and az redisenterprise command reference. See also az redisenterprise database access-policy-assignment command reference.

Connecting from Spring Boot with Microsoft Entra ID

The documented Spring route is Spring Cloud Azure’s spring-cloud-azure-starter-data-redis-lettuce (alongside spring-boot-starter-data-redis, versions from the spring-cloud-azure-dependencies BOM), which plugs a DefaultAzureCredential-backed, auto-refreshing Entra token into Lettuce as the Redis password. The username is the object ID of the managed identity granted access above, TLS is mandatory for Entra authentication, and the port is 10000:

spring:
  data:
    redis:
      host: redis-bookshelf.eastus2.redis.azure.net
      port: 10000
      username: ${AZURE_REDIS_OBJECT_ID}   # object ID of the workload's managed identity
      ssl:
        enabled: true
      azure:
        passwordless-enabled: true

With that in place a plain StringRedisTemplate or @Cacheable works unchanged, with no access key anywhere in configuration. For explicit Jedis or Lettuce wiring through redis-authx-entraid instead of the starter, see Deploying Redis on Azure. This derives from Use Azure Redis Cache in Spring (Azure Managed Redis, Microsoft Entra ID tab) and Spring Cloud Azure Redis support.

Elastic Cloud on Azure

Elastic Cloud (Elasticsearch, Kibana, and the rest of the Elastic Stack) is offered on Azure as a native ISV service: Azure provisions an Microsoft.Elastic/monitors resource in the customer’s own resource group and region, while Elastic itself provisions and operates the actual Elasticsearch deployment — either a serverless project (auto-scaling, usage-based) or a dedicated cloud-hosted cluster — behind that resource. Billing flows through the customer’s Azure subscription as Marketplace SaaS (below), and the integration can also forward Azure Monitor logs and metrics from other resources in the subscription into that Elastic deployment for centralized log analytics and security monitoring, which is what makes it a "monitor" resource rather than a plain database listing.

In the Azure portal

  1. Search the Marketplace for Elastic Cloud (Elasticsearch) and select Create.

  2. On Basics, choose $RG, $LOCATION, a Resource name, and an Elastic Pricing plan; sign up for (or link) an Elastic organization when prompted.

  3. On Logs and metrics, optionally enable forwarding of subscription-level Azure Monitor data (activity logs, Azure resource metrics, or specific resource types via tag rules) into the new Elastic deployment.

  4. Review and Create; once provisioned, Go to Elastic resource deep-links into the Elastic Cloud console for the actual Elasticsearch/Kibana deployment.

With the Azure CLI

The elastic extension (auto-installed on first use, Azure CLI 2.75.0+) exposes the same resource as az elastic monitor:

az elastic monitor create \
  --monitor-name elastic-bookshelf \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --sku "ess-consumption-2024_Monthly" \
  --hosting-type Hosted \
  --monitoring-status Enabled \
  --generate-api-key true

--hosting-type Hosted provisions a dedicated cloud-hosted deployment; Serverless provisions an auto-scaling serverless project instead and additionally needs --project-details. --sku names the specific Marketplace plan (consumption-based plans bill per resource-hour rather than a fixed monthly price; confirm the current plan identifiers with az elastic elastic-version list and the Marketplace listing before scripting this, since plan names change with Elastic’s own pricing updates). az elastic monitor list-deployment-info returns the underlying Elastic Cloud deployment’s own endpoint once provisioning finishes.

Networking and security

Traffic filters (az elastic monitor create-and-associate-ip-filter, create-and-associate-pl-filter) restrict which networks can reach the Elastic deployment’s public endpoint — an IP allowlist or an Azure Private Link connection, respectively — and are managed the same way as Elastic Cloud’s own traffic filters on any other cloud. Elastic-side authentication (API keys, SAML/OIDC single sign-on) is configured in the Elastic Cloud console itself once the deployment exists; the Azure resource layer only controls provisioning, billing, and the optional Azure Monitor data forwarding.

Pricing model

Elastic Cloud on Azure bills as Marketplace SaaS: the customer picks a plan (typically consumption-based, billed per resource-hour actually consumed) from the Marketplace listing, Azure meters usage and folds the charge into the customer’s regular Azure invoice, and Microsoft remits the Elastic-owned portion to Elastic — no separate Elastic invoice or payment method. Current plans and rates are published on the Elastic Cloud (Elasticsearch) Marketplace listing and Elastic’s own pricing page; treat any specific number here as indicative, not contractual.

References: Elastic integrations overview, Elastic integration with Azure — FAQ, Troubleshooting Elastic Cloud (Elasticsearch), az elastic monitor command reference.

Couchbase Capella, Neo4j AuraDB, Qdrant Cloud, and MongoDB Atlas via Azure Marketplace

Four more data-platform vendors sell their fully managed cloud services directly through Azure Marketplace, each provisioned and billed inside the customer’s own Azure subscription rather than through a separate vendor account — the same Marketplace SaaS billing model covered for Elastic above, applied to a database instead of a search platform. The vendor operates the actual database (patching, backups, scaling, failover); the Marketplace listing is a procurement and billing wrapper around a subscription to the vendor’s own control plane.

Vendor / product What it is Private connectivity on Azure Typical fit

Couchbase Capella

Fully managed Couchbase (JSON document, key-value, SQL++, full-text and vector search) — see Comparing Vector Databases for how its vector search compares with the field.

Azure Private Link, configured from the Capella console per-cluster.

Teams already using Couchbase Server that want the same data model without operating clusters themselves.

Neo4j AuraDB

Fully managed Neo4j graph database (Professional and Enterprise tiers), reachable through the Neo4j Bolt protocol/drivers or Cypher over HTTP.

Azure Private Link, configured from Aura Console > Project settings > Security & Networking > Private endpoints (Enterprise tier).

Graph-shaped data — recommendation engines, fraud/relationship analysis, knowledge graphs — where a relational or document model would need heavy application-side joins.

Qdrant Cloud

Fully managed Qdrant vector database — see Comparing Vector Databases and The Vector Database Landscape for how it compares with Redis’s and Postgres’s own vector search.

Private endpoint connectivity, gated to the Premium tier (minimum spend, sales-assisted setup) rather than available on every plan.

A dedicated vector-search workload (RAG retrieval, similarity search) that has outgrown a general-purpose database’s bolted-on vector index.

MongoDB Atlas

Fully managed MongoDB, offered as an Azure Native Integration: the Atlas organization itself is created from, and billed through, the Azure portal rather than a separate MongoDB account.

Azure Private Link, general availability, configured from the Atlas console per project/cluster.

Document-modeled data where the team already standardizes on MongoDB, or wants Atlas’s search/vector-search and Atlas-native tooling without a separate vendor billing relationship.

In the Azure portal (representative flow — MongoDB Atlas)

The four listings differ in detail but follow the same shape; MongoDB Atlas’s Azure Native Integration is the most tightly wrapped, so it illustrates the flow:

  1. Search the Marketplace for MongoDB Atlas and select the Azure Native Integration offer, then Subscribe.

  2. On Basics, choose $RG, an Organization name (creates a new Atlas organization tied to this Azure subscription), and a support plan.

  3. Review the Terms (this is where the Marketplace SaaS billing agreement is presented) and Subscribe — this provisions an Microsoft.Mongo/organizations (or vendor-equivalent) resource that deep-links into the vendor’s own console.

  4. From the vendor console (Atlas, Capella, Aura, or Qdrant Cloud), create the actual cluster/project: region, tier, and — where offered — a Private Link/private endpoint connection back into a Bookshelf VNet, following the same portal-to-VNet peering flow regardless of vendor.

Couchbase Capella, Neo4j AuraDB, and Qdrant Cloud subscribe the same way from their own Marketplace listings (search the vendor name, Subscribe, then finish cluster creation in the vendor’s own console); none of the four currently expose their full cluster-creation surface through an az command of their own — Marketplace SaaS resources are provisioned and billed through Azure, but day-to-day cluster operations stay in the vendor’s own console/API/Terraform provider.

What Marketplace SaaS billing means

Subscribing through Marketplace does not move the database itself onto Azure’s infrastructure or under Azure’s own SLA — the vendor still runs the service (on its own infrastructure, which may itself sit on Azure, AWS, or GCP depending on the product). What Marketplace SaaS actually changes is procurement: usage is metered by the vendor and reported to Azure, the charge appears as a line item on the customer’s regular Azure invoice (consuming any pre-committed Azure spend/MACC where the vendor participates in that program), and the customer never opens a direct billing relationship or separate invoice with the vendor. This is the same mechanism Elastic Cloud on Azure uses above, and it is the reason all four listings show a support-plan/agreement step in the subscribe flow rather than a credit-card form.

Private connectivity where offered

Azure Private Link is the common mechanism across all four listings that support it: a private endpoint is created in the customer’s own VNet (the same Private Link primitive used elsewhere on Azure, e.g. Blob Storage's SAS/Entra coverage on the storage side), traffic to the vendor’s service stays on Microsoft’s backbone network instead of the public internet, and the endpoint is approved from the vendor’s own console (Capella, Aura, or Atlas) rather than from the Azure portal. Qdrant Cloud is the exception in degree rather than kind: private connectivity exists but is reserved for its Premium tier, with a minimum spend and a sales conversation, rather than being self-serve on every plan the way it is for the other three.

References: Azure Native ISV Services overview, MongoDB Atlas as an Azure Native Integration, Azure Private Link integration for MongoDB Atlas, Integrate Atlas with Azure, Add an Azure Private Link connection — Couchbase Capella, Couchbase Capella on Azure Marketplace, Aura with cloud provider marketplaces, Aura secure connections, Qdrant is now available on Azure Marketplace, Qdrant Cloud billing & payments.

Self-hosting on AKS: operators and Helm

Every product above also has an open-source core (or a close OSS relative) that can be self-hosted on AKS with a Kubernetes operator and a Helm chart instead of a managed offering: Solr (SolrCloud, via the Apache Solr Operator), Neo4j (the Neo4j Helm charts, no dedicated operator for Community Edition), Qdrant (the Qdrant Operator or its plain Helm chart), and Couchbase (the Couchbase Autonomous Operator).

When self-hosting on AKS makes sense

Self-hosting trades a vendor’s on-call rotation and managed backups/upgrades for full control over placement, networking, and cost — worth it when the workload needs to run in the same cluster as the application for data-locality or air-gapped/compliance reasons, when a managed tier’s pricing doesn’t fit an unusually large or bursty workload, or when the team already runs a mature platform team that operates other stateful workloads on Kubernetes and wants one operational model rather than N vendor consoles. It’s the wrong default otherwise: an operator still leaves the team responsible for capacity planning, upgrade testing, backup verification, and incident response that a managed SaaS/PaaS listing absorbs, and every extra self-hosted stateful set is another thing a small team has to keep patched.

With the Azure CLI and Helm (Qdrant on aks-bookshelf, representative)

export AKS=aks-bookshelf

az aks get-credentials --resource-group "$RG" --name "$AKS"

helm repo add qdrant https://qdrant.github.io/qdrant-helm
helm repo update

helm install qdrant-bookshelf qdrant/qdrant \
  --namespace databases --create-namespace \
  --set replicaCount=3 \
  --set persistence.size=50Gi \
  --set persistence.storageClassName=managed-csi

The same shape applies to the other three: add the vendor’s chart repo (or apply the operator’s CRDs/manifests for Solr/Couchbase, which ship as an operator plus a matching custom resource rather than a values-only Helm chart), then create a namespaced custom resource (SolrCloud, CouchbaseCluster) or release that references a StorageClass for its persistent volumes.

Storage classes: Azure Disk vs. Azure Files CSI

AKS provisions several StorageClass objects by default through the Azure Disk and Azure Files CSI drivers, and the choice between them matters for a stateful database workload:

StorageClass Backing store Fit for a self-hosted database

managed-csi

Azure Disk, Standard SSD LRS (ZRS automatically on a zone-spanning cluster from Kubernetes 1.29+).

ReadWriteOnce only — one pod per volume — which is exactly what a sharded/replicated database (Solr, Qdrant, Couchbase, Neo4j) wants: each replica pod gets its own disk, and cross-replica consistency is the database’s own replication protocol’s job, not the storage layer’s.

managed-premium

Azure Disk, Premium SSD LRS.

The same ReadWriteOnce shape as managed-csi, at higher IOPS/throughput for a latency-sensitive workload (the Query Engine/vector-search-heavy end of these products) — create a custom StorageClass referencing the disk.csi.azure.com provisioner with skuName: Premium_LRS if the built-in one isn’t granular enough.

azurefile-csi / azurefile-csi-premium

Azure Files (ReadWriteMany — shared across pods).

Rarely what a clustered database’s own data directory wants (most of these engines assume local, exclusively-owned disk semantics for their storage engine); reserve Azure Files for shared configuration, plugin/plugin-jar directories (Solr), or backup/restore staging rather than the primary data volume.

Bookshelf’s Qdrant example above pins managed-csi explicitly for this reason. See Storage options for applications in AKS, Use CSI drivers on AKS, and Azure Disk CSI driver.

References: Apache Solr Operator, Neo4j on Kubernetes, Qdrant Operator, Couchbase Autonomous Operator, Storage options for applications in AKS, Use CSI drivers on AKS.

Azure Monitor managed Prometheus and Managed Grafana

Whichever of the above Bookshelf runs — Azure Managed Redis, Elastic Cloud, a Marketplace partner database, or a self-hosted engine on aks-bookshelf — needs the same observability layer in front of it. Azure Monitor managed service for Prometheus is a fully managed, Prometheus-compatible metrics store: an Azure Monitor workspace holds the time series (retained 18 months), the AKS Metrics add-on (or a self-managed Prometheus with remote_write) ships scraped metrics into it, and PromQL queries it exactly as they would a self-hosted Prometheus server — see Prometheus & Monitoring for the Prometheus reference this builds on (data model, PromQL, recording/alerting rules) unchanged by which backend stores the series. Azure Managed Grafana is the companion visualization/alerting layer, a fully managed Grafana instance wired to that workspace (and to any other Azure Monitor/Log Analytics data) without operating Grafana’s own database or auth stack.

In the Azure portal

  1. Search for Azure Monitor workspaces → Create, choose $RG/$LOCATION and a Name (amw-bookshelf), then Review + create.

  2. Open aks-bookshelf → Monitoring → Insights → Monitor Settings, and enable Azure Monitor metrics against the workspace just created — this deploys the managed Prometheus collector (ama-metrics) as an AKS add-on and applies a default scrape-config ConfigMap covering common exporters, cAdvisor, and kube-state-metrics (see Containers & Kubernetes monitoring for what those metrics look like).

  3. Search for Azure Managed Grafana → Create, choose $RG/$LOCATION, a Name (grafana-bookshelf), and a pricing plan (Standard for production, Essential for dev/test).

  4. On the Grafana workspace’s Configuration → Data sources (or during creation, Link a workspace), link the amw-bookshelf Azure Monitor workspace so its dashboards can query the managed Prometheus data alongside any Log Analytics-based panels.

With the Azure CLI

az monitor account create \
  --name amw-bookshelf \
  --resource-group "$RG" \
  --location "$LOCATION"

WORKSPACE_ID=$(az monitor account show \
  --name amw-bookshelf \
  --resource-group "$RG" \
  --query id --output tsv)

# Attach the AKS cluster's managed-Prometheus metrics add-on to the workspace
az aks update \
  --name "$AKS" \
  --resource-group "$RG" \
  --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id "$WORKSPACE_ID"

az grafana create \
  --name grafana-bookshelf \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --sku Standard

az grafana update \
  --name grafana-bookshelf \
  --resource-group "$RG" \
  --set properties.grafanaIntegrations.azureMonitorWorkspaceIntegrations="[{azureMonitorWorkspaceResourceId:'$WORKSPACE_ID'}]"

az monitor account create provisions the workspace with no further required options beyond its name and resource group (--public-network-access Disabled restricts it to private connectivity, e.g. from an AKS cluster reached only through a private endpoint). az aks update --enable-azure-monitor-metrics is the AKS-side half of the wiring — it installs the ama-metrics DaemonSet/ReplicaSet and points it at the workspace; az grafana update …​ azureMonitorWorkspaceIntegrations is the Grafana-side half, making that workspace query- able from Grafana’s own Azure Monitor data source without a separate Prometheus data-source URL/credential pair to manage. See Grafana: Dashboards & visualization for what a data source and dashboard look like once wired up, and Grafana alerting for Grafana-managed alerting against these same metrics as an alternative to Prometheus/Alertmanager rules.

Networking and security

Both resources support private connectivity: an Azure Monitor workspace’s --public-network-access Disabled pairs with a private endpoint the same way Blob Storage’s account-level networking does (see Blob Storage for the general private-endpoint pattern), and Azure Managed Grafana supports private endpoint access (no public ingress) alongside Entra ID-backed sign-in and Azure RBAC roles (Grafana Admin, Grafana Editor, Grafana Viewer) scoped to the workspace resource — there is no separate Grafana-native user database to keep in sync, matching the Entra-first pattern used throughout this page.

Scaling and troubleshooting

No data in Grafana dashboards after linking the workspace. The most common cause is the AKS Metrics add-on not actually running yet — confirm with kubectl get pods -n kube-system -l rsName=ama-metrics (or the equivalent DaemonSet pods) before assuming the Grafana-side link is wrong; a freshly enabled add-on can take a few minutes to start scraping and for the first samples to reach the workspace.

Missing container-level metrics (cAdvisor, kube-state-metrics). The default ama-metrics scrape configuration covers common targets out of the box, but a custom scrape job (for a self-hosted database’s own /metrics endpoint, e.g. Qdrant’s or Solr’s Prometheus exporter) needs an explicit ama-metrics-prometheus-config ConfigMap entry — it is not picked up automatically the way node_exporter/cAdvisor targets are. See Service discovery & relabeling for the Kubernetes service-discovery mechanics a custom scrape config still relies on.

Cost growing faster than expected. Managed Prometheus bills per metric sample ingested, not a flat per-workspace fee — a database’s own exporter emitting high-cardinality labels (a label per document ID or per query, for example) inflates ingested-sample volume disproportionately; the same cardinality discipline covered on Data model & metric types applies here, and matters more once every extra label value has a direct, metered cost.

Pricing model

Azure Monitor managed Prometheus bills per metric sample ingested (plus standard Azure Monitor query/alert charges); Azure Managed Grafana bills per workspace on a flat per-plan rate (Essential vs. Standard), not per dashboard or per user. Exact current rates are published at the Azure Monitor pricing page and the Azure Managed Grafana pricing page; treat any specific number here as indicative, not contractual.

References: Overview of Azure Monitor managed service for Prometheus, Enable Prometheus and Grafana for an AKS cluster, az monitor account command reference, What is Azure Managed Grafana?, az grafana command reference, Azure Monitor pricing, Azure Managed Grafana pricing.

Clean up

# Remove the Qdrant self-hosted example from aks-bookshelf without deleting the whole cluster
helm uninstall qdrant-bookshelf --namespace databases

# Remove every ARM/Marketplace resource created on this page (Azure Managed Redis, Elastic monitor, Azure
# Monitor workspace, Azure Managed Grafana, and the resource group itself)
az group delete --name "$RG" --yes --no-wait

A Marketplace SaaS subscription to Couchbase Capella, Neo4j AuraDB, Qdrant Cloud, or MongoDB Atlas is cancelled from the vendor’s own console (or the Marketplace SaaS blade in the Azure portal), separately from az group delete, since the underlying cluster/project lives in the vendor’s own control plane rather than as an ARM resource inside $RG.

Related pages

References