Azure Confidential Ledger

About Azure Confidential Ledger

Azure Confidential Ledger is a managed Azure service for records that need strong integrity guarantees, tamper evidence and independent verification. It uses confidential computing, cryptographic proofs and an append-only ledger model so organizations can record sensitive transactions, audit events and hashes of external data without relying on a conventional mutable database alone. It is aimed at compliance, security and assurance scenarios where proving that a record has not been altered is as important as storing the record itself.

What is Azure Confidential Ledger used for?

The service is designed for records whose history should be verifiable over time. Microsoft highlights examples such as business transactions, contract or document changes, administrative and control changes, operational security events and development or production records that may later need independent audit.

A common pattern is to keep primary business data in another system and store cryptographic digests or hashes in Azure Confidential Ledger. Microsoft documents this approach for Azure SQL ledger scenarios and for protecting the integrity of data stored elsewhere. That lets the ledger act as a point-in-time source of truth without forcing every application payload into the ledger itself.

How does the ledger protect integrity?

Azure Confidential Ledger is append-only and each committed transaction has a verifiable receipt based on Merkle tree data. Applications can use those receipts to check that a transaction was accepted and has not been changed after commitment.

Microsoft states that the service runs on hardware-backed secure enclaves and the Confidential Consortium Framework. The trusted computing base is intentionally small, and Microsoft describes the design as protecting records even from privileged insiders, including the cloud provider. The ledger spans multiple attested nodes and uses consensus to preserve ledger integrity.

What data model and access options does it support?

The service exposes a REST interface and Microsoft provides SDK support for languages including .NET, Java, Python and JavaScript. Collection IDs can be used to group and query related records. Microsoft currently documents support for up to 50,000 collection IDs per ledger.

Ledger instances can be private or public. Private ledgers store transaction data encrypted, while public ledgers store transaction data in plain text for transparency-oriented scenarios. This choice is important because Microsoft states that the ledger type cannot be changed after creation.

How do identity and security work?

Azure Confidential Ledger supports Microsoft Entra ID and certificate-based authentication. Authorization is unusual compared with many Azure services because user management is localized inside the ledger rather than relying on Azure RBAC for data-plane authorization. Microsoft positions this as a way to reduce external dependencies in the trusted computing base.

Client connections use TLS 1.3, with the connection terminating inside hardware-backed enclaves. Microsoft recommends that applications authenticate ledger nodes before exchanging data. For sensitive deployments, buyers should include node verification, credential handling, diagnostic logging and retention requirements in the implementation plan rather than treating the service as a drop-in database.

What are the current limits?

Microsoft currently documents a default limit of two Standard SKU ledgers per subscription. Each ledger supports up to 50,000 collection IDs. Current request-rate limits include 1,800 create-entry requests and transactions per second, 3,600 get-current-entry requests per second, 2,500 get-entry requests per second, 2,400 receipt requests per second and 3,300 list-entry requests per second.

These limits matter for high-volume event pipelines. Microsoft advises customers that need higher limits to contact the Azure Confidential Ledger team. Buyers should size expected write rates, verification reads and audit workloads before selecting the service for very high-throughput telemetry.

How does resiliency and recovery work?

Microsoft states that ledger nodes are deployed across Azure availability zones and that the network can self-heal during zone-wide failures. Ledger files are also periodically replicated to secondary storage for business continuity, and data is automatically replicated to Azure regional pairs for disaster recovery.

The service is not a conventional backup system, however. Microsoft warns that deleting an Azure Confidential Ledger instance is a hard delete and the data cannot be recovered afterward. Operational controls around deletion therefore deserve the same attention as the cryptographic design.

How is Azure Confidential Ledger priced?

Pricing checked: August 28, 2026. Microsoft's current pricing page lists Standard ledger pricing as an hourly charge per ledger instance plus storage billed per GB per month. The ledger compute charge includes the first 100 GB of storage across the three decentralized nodes, with additional storage charged separately.

Microsoft's public pricing page does not expose one universal fixed amount because rates vary with region, agreement, date and currency. Buyers should use the Azure pricing calculator or their own billing offer rather than assuming one published number applies globally. The product page also describes the service as usage-based, with cost driven by the number of ledgers and how long they run.

Where does Azure Confidential Ledger fit beside databases and storage?

Azure Confidential Ledger is not a replacement for a relational database, object store or general application database. Its value is the integrity layer. Microsoft specifically documents using the ledger alongside Azure SQL ledger features and external data sources so digests or important audit records can be independently verified.

If an application mainly needs flexible queries, transactional updates, large object storage or low-cost event retention, a conventional Azure database or storage service will usually be the primary system of record. Confidential Ledger makes more sense when immutability, tamper evidence and cryptographic proof are first-class requirements.

What deployment risks should buyers consider?

The main design risks are choosing the wrong ledger type, underestimating throughput needs and treating deletion as reversible. A private versus public ledger decision cannot be changed later. The default subscription limit is low, and the service has documented request-rate ceilings. Microsoft also notes that the service is available only in limited regions, so regional availability and data residency should be checked before architecture decisions are finalized.

Teams should also decide how receipts will be stored and verified. Collecting proofs without an operational process to validate them during audits or incident response leaves much of the service's assurance value unused.

Who should choose something else?

Choose another Azure service if the primary requirement is a mutable operational database, a data warehouse, low-cost blob retention, standard application logging or a broad SIEM platform. Azure SQL Database, Azure Cosmos DB, Azure Blob Storage, Azure Monitor or Microsoft Sentinel may be better foundations for those workloads depending on the use case.

Azure Confidential Ledger is most appropriate when records need strong tamper evidence, independent verification and append-only history. Teams that do not have a compliance, audit, integrity or trust requirement strong enough to justify those properties may add complexity without gaining enough business value.