NetApp is expanding Kafka tiered storage to Microsoft Azure through Instaclustr for Apache Kafka.  Now available in Public Preview for new Azure clusters, the capability gives teams a more flexible way to retain historical event data without scaling broker storage at the same rate.

With Kafka tiered storage, recent data remains on the brokers for low-latency access while older, closed log segments move to a customer-provided or auto-provisioned Azure Blob Storage container. Producers and consumers continue to use Kafka in the same way, whether the requested data is local or remote. Our Apache Kafka Tiered Storage overview explains this local-and-remote model, retention controls, and consumer retrieval flow in more detail.

Expanding Tiered Storage across the hyperscalers

Azure is the latest step in NetApp’s continued expansion of Tiered Storage across the major public clouds. NetApp first introduced support on Amazon Web Services (AWS) in July 2024, and extended support to Google Cloud in December 2025.

With Azure joining AWS and Google Cloud, NetApp Instaclustr customers have a more consistent way to separate Kafka compute from historical storage across their preferred hyperscaler. Each implementation uses the cloud provider’s native object storage while preserving the Kafka client experience.

What are the benefits of Kafka tiered storage on Azure?

Traditional Kafka clusters couple compute and storage on each broker. As retained data grows, teams may need to expand broker disks or add brokers even when they do not need more compute. Tiered Storage separates those decisions, allowing teams to keep an appropriately sized local data window for latency-sensitive workloads while retaining older data in Azure Blob Storage for later replay, analytics, or audit needs. We explored this broader architectural shift in Part 1 of our Apache Kafka Tiered Storage series.

This gives customers several practical benefits:

  • More control over retention and cost. Move older segments to object storage while reserving broker storage for the data that needs the fastest access.
  • Independent storage and compute planning. Increase retained data without automatically increasing broker compute capacity.
  • Simpler cluster operations. Reduce the volume of historical data tied to individual brokers.
  • No Kafka client changes required. Producers and consumers use the same Kafka interfaces. Brokers retrieve remote data when a consumer requests an older offset.

For a closer look at the operational behavior behind these advantages, Part 2 of the series follows remote writes and reads on a Tiered Storage cluster. Our Kafka cluster sizing guidance for Tiered Storage discusses the storage, throughput, and performance trade-offs teams should consider when planning a deployment.

How Tiered Storage works on Azure

For this Public Preview, customers create a new Azure cluster using the Bring Your Own Cloud (BYOC) deployment model and provide an Azure Blob Storage container for the remote tier. NetApp Instaclustr uses the cluster data centre’s managed identity to grant the required access to that container, so storage account keys do not need to be placed on the brokers. The public support guide covers the Azure storage access model, recommended Blob Storage tier, and current limitations.

When Tiered Storage is enabled, active log segments remain on the brokers’ local disks while closed segments are copied asynchronously to Azure Blob Storage. Kafka retains the metadata needed to retrieve remote data through the broker, so consumers do not need to know which tier holds an offset. Tiered Storage is enabled per topic, letting teams choose which workloads need remote retention and configure local and total retention independently. Our original hands-on walkthrough shows how cluster-level enablement and topic-level configuration work together.

Which clusters are eligible for the public preview?

The Public Preview is available for new Azure BYOC clusters running an eligible Kafka version and can be provisioned through the NetApp Instaclustr Console, application programming interface (API), or Terraform. It is limited to non-production service level agreement (SLA) clusters without Payment Card Industry (PCI) compliance mode running with production node sizes. See the Apache Kafka Tiered Storage documentation for current Azure storage requirements, supported topic types, configuration guidance, limitations, and migration guidance for existing clusters.

How do you get started with Kafka tiered storage on Azure?

Consistent with our previous AWS and Google Cloud releases, Tiered Storage for Azure is offered as an Enterprise Add-On and is included with Instaclustr Enterprise Pricing. Once Enterprise Pricing is applied to the cluster, there is no separate Instaclustr charge for enabling additional enterprise features or add-ons.

Customers can select Tiered Storage when creating an eligible Kafka cluster and then enable it for the topics that need remote retention. Contact your Customer Success Representative to discuss applicable pricing.