Azure Managed HSM Scaling Guidance

This document describes how to correctly plan capacity for Azure Managed HSM.

Common customer scenarios for capacity planning

Customer Managed Keys Encryption at Rest

Azure services that use customer-managed keys perform a small number of get key, wrap, and unwrap operations, then cache the results while periodically checking access permissions. This means only a few calls are made per hour. Because of this behavior, it is very unlikely that you will reach the throughput limits described in this document when using Managed HSM for encryption at rest.

Custom Applications

For customers using Managed HSM for custom applications, the benchmark numbers can be used as approximate expectations for architecting the custom application. Managed HSM does not throttle on cryptographic operation transactions, and uses the HSM hardware and CPUs to their fullest. The numbers should be used as guidance for capacity planning, though we recommend load testing and validating performance numbers. The numbers are an inherent limit of the HSM and its current firmware.

Planning for transaction capacity for cryptographic operations

Each Managed HSM instance constitutes three load balanced HSM partitions. The throughput limits are a function of underlying hardware capacity allocated for each partition. The tables show internally measured approximate maximum throughput with at least one partition available. Actual throughput may be up to 3x higher if all three partitions are available. Partitions are occasionally taken down while healing failing hardware, patching servers, and during other service code updates. For capacity planning, it is safe to assume that 2 partitions will be available. If you need a guaranteed number of operations per second, capacity plan with only one partition available in mind.

For scaling the encryption of large amounts of data, we recommend using a key hierarchy where only the Key Encryption Key is stored in Managed HSM and it is used to wrap lower level keys. For more information, see Azure Data Encryption-at-Rest: Envelope Encryption with a Key Hierarchy

The benchmark numbers were calculated from internal performance testing one key operation a time on our current hardware with its current firmware. Each key operation was run against a single-partition MHSM pool, using the same key for each request. The numbers shown are the average number of operations per second, sustained over 5 minutes.

These numbers assume that one single key is being used to achieve maximum throughput. For example, if a single RSA-2048 key is used, the maximum throughput is 900 sign operations. If you use 900 different keys with one transaction per second each, they will not be able to achieve the same throughput.

These numbers will be updated after Managed HSM firmware updates, based on our internal performance testing.

RSA key operations (number of operations per second per HSM instance)

EC key operations (number of operations per second per HSM instance)

This table describes number of operations per second for each curve type.

AES key operations (number of operations per second per HSM instance)

Throughput limits for Wrap/Unwrap apply to AES-KW algorithm.

Transaction limits for administrative operations (number of concurrent operations per HSM instance)

For Azure Managed HSM service limits, see Managed HSM service limits.