Skip to content

Managed Tier Key Capacity Exhausted

URI: https://docs.ankatech.co/errors/managed-tier-key-capacity-exhausted
HTTP Status: 409 Conflict

When you see this

Assigning an Edition tier to a tenant establishes that tenant's own key-encryption key on the tier's carrier — the PKCS#11 token, or the cloud account and key ring, that the ANKA-managed tier sits on. Every backend publishes a ceiling on how many key objects it will hold, and this refusal says the carrier is at it.

The refusal is raised before anything is written: no Edition is assigned, no custody row is created, no audit row is filed and no key object exists on the carrier. That is stated in the detail outright, because an operator reading a refusal needs to know whether they are now in a half-applied state.

It is a 409 rather than a 503 because retrying the same assignment cannot resolve it, and rather than a 507 because nothing about the platform's own storage is exhausted — the constrained resource is the third party's.

Common Causes

  • The tier's carrier has taken on as many tenants as the backend will hold. On an ENTERPRISE tier backed by AWS CloudHSM the ceiling is 3,300 key objects per hsm1.medium cluster, which AWS publishes on its non-adjustable System-quotas table.
  • Key objects on the carrier that this platform did not provision — the tier's own key-encryption key, anything the host activation step placed on the token, or objects another system created — consume the same ceiling but are invisible to the platform's count. The projected headroom is therefore an upper bound, and a refusal can arrive slightly earlier than the projection suggested.
  • A tier pointed at a backend whose published ceiling is much lower than the tenant population it is being asked to carry.

Response Example

{
  "type": "https://docs.ankatech.co/errors/managed-tier-key-capacity-exhausted",
  "title": "Managed tier key capacity exhausted",
  "status": 409,
  "detail": "The ENTERPRISE tier's key-protection backend holds 3300 of 3300 key objects. Assigning this Edition establishes custody for a further tenant, which requires 1 object. No Edition was assigned and no key object was created.",
  "instance": "/api/v3/admin/platform/tenants/7c9e6679-7425-40de-944b-e07fc1f90ae7/key-backend/edition",
  "extensions": {
    "tier": "ENTERPRISE",
    "ceiling": 3300,
    "objectsRequired": 1,
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The body names the tier, the object counts and how many objects the operation requires, and nothing else. Three of them are also machine-readable extension members — extensions.tier, extensions.ceiling and extensions.objectsRequired — beside the usual extensions.requestId; branch on those rather than parsing detail. It carries no credential, no ARN, no endpoint, no token label, no PIN path, no KEK label, no carrier string and no tenant identifier. That set is an allow-list, not a list of things that happen to be absent.

How to Resolve

  1. Read the tier's capacity projection on the ANKA-managed backend tiers surface in the Admin Console. It reports the carrier's ceiling, how many key objects this platform has provisioned on it, and how many further tenants it can take. See Backend Key Capacity*.
  2. Free objects on the carrier, or move the tier to a backend with a higher published ceiling. Note that a tenant moved off a carrier by a key custody move leaves its key-encryption key on that carrier, RETIRED, for its 30-day retention, so a roll back can return to it; the object keeps occupying a key slot after that too, because the KEK stays RETIRED until a platform administrator requests its destruction, and the capacity count keeps counting it even once destroyed. A custody row revoked by a provisioning that left the carrier also still occupies its slot.
  3. Do not expect the ceiling to be raised by a support request when the tier is on CloudHSM: that figure is on AWS's System-quotas table, which is not adjustable. AWS KMS's 100,000 keys per region per account is adjustable through AWS Service Quotas, but it is a fact about the AWS account rather than a setting this platform keeps.
  4. Place the tenant on a different Edition tier, or give it its own BYOK backend*, which does not consume the managed tier's carrier at all.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.

* restricted content — see higher-tier documentation