--- title: "SLA - KMS External Key Store" description: "Exoscale KMS External Key Store SLA, with the availability target and the split of availability and security responsibilities between Exoscale and the Client." url: https://community.exoscale.com/product/security/kms/service-boundaries/sla-external-key-store/ product: "Key Management Service (KMS)" section: product last_updated: 2026-11-09 --- > For AI agents: the documentation index is at https://community.exoscale.com/llms.txt. Every page is available as markdown at `index.md` or with `Accept: text/markdown`. # SLA - KMS External Key Store These product-specific SLAs define the Service Availability Target for KMS keys in an External Key Store of the Exoscale Key Management Service. It applies to each Client using External Key Stores. Capitalized terms used herein but not defined herein shall have the meanings set forth in the Exoscale Terms and Conditions or EUSA, whichever applies. > [!IMPORTANT] > **No SLA During Private Preview** > > External Key Store (XKS) is currently in private preview. This SLA applies once External Key Store becomes generally available. External Key Stores differ from other Exoscale services in that every cryptographic operation on their KMS keys is performed in part on infrastructure operated by the Client: the XKS proxy, the external key manager and the external keys, as described in [External Key Store Concepts](https://community.exoscale.com/product/security/kms/overview/index.md#external-key-store-concepts). This SLA covers only the part of each operation performed by Exoscale, and sets out the responsibilities of the Client for availability, durability and security. ## SLA Definitions | Metric | Target | Definition | | -------- | -------- | ------------ | | Availability | >= 99.95% Monthly Uptime Percentage | Calculated per Client and per External Key Store, for each 5-minute interval of a calendar month, as the percentage of eligible requests that do not fail with an HTTP `5xx` response attributable to Exoscale KMS. The Monthly Uptime Percentage is the average of these percentages over all intervals of the month. | Eligible requests are all requests to the Exoscale API on an External Key Store or its KMS keys, including requests made by Exoscale services on the Client's behalf. An interval without eligible requests counts as 100% available. An interval during which the Exoscale API does not accept requests on KMS keys in the zone of the key store counts as 0% available. A request that fails because of the XKS proxy, the external key manager, the external keys or their network connectivity, or for any other reason listed under [Exclusions](#exclusions), is not eligible. ## Shared Responsibility Model With standard KMS keys, Exoscale operates every component involved in a cryptographic operation. With KMS keys in an External Key Store, Exoscale KMS performs the inner layer of [double encryption](https://community.exoscale.com/product/security/kms/overview/index.md#double-encryption), and the external key manager of the Client performs the outer layer through the XKS proxy. Each party is responsible for the availability and the security of the components it operates: | Component | Operated by | Exoscale is responsible for | The Client is responsible for | | ----------- | ------------- | ----------------------------- | ------------------------------- | | Exoscale KMS | Exoscale | Availability of the KMS API, IAM authorization of every request, the key store resource, the key material of each KMS key, the inner layer of encryption, and the validation of every proxy response | IAM policies granting access to the key stores and their KMS keys | | Connection to the XKS proxy | Exoscale and the Client | Authentication of the proxy, signature of every request with the proxy credential, encrypted storage of that credential, and internet connectivity of the Exoscale zone | Reachability of the proxy endpoint from the internet over HTTPS, its DNS record and its TLS certificate | | Key store configuration | The Client | Application of the endpoint and credential provided by the Client, after a successful health check | Consistency of the endpoint and credential with the proxy, rotation of the credential, and connection or disconnection of the key store | | XKS proxy | The Client | — | Availability, capacity, security, conformance to the [AWS KMS External Key Store Proxy API Specification](https://github.com/aws/aws-kms-xksproxy-api-spec/), and forwarding of every request to the external key manager | | External key manager and external keys | The Client | — | Availability, capacity and security of the external key manager, and existence, state, backup and rotation of the external keys | ### Availability Every cryptographic operation on a KMS key in an External Key Store calls the XKS proxy, and fails if the proxy, the external key manager or the network between them and Exoscale does not answer or refuses the request. Exoscale cannot resolve these failures. The availability and latency of these operations, and of the Exoscale services and Client workloads that use these keys, are therefore bounded by those of the Client's infrastructure. While Exoscale is responsible for operating Exoscale KMS as defined above, and for periodically checking the health of the proxy of every connected key store, Client is responsible for: * Availability and capacity of the XKS proxy and the external key manager, sized for the Client's workloads, including the requests made by Exoscale services on the Client's behalf. * Reachability of the proxy endpoint from Exoscale over the public internet, with a valid certificate issued by a certificate authority trusted by Exoscale KMS. * Monitoring of the XKS proxy and the external key manager. * Planning of configuration changes to the key store. The Exoscale health check reflects only the connection between Exoscale KMS and the proxy. It does not report the state of the external key manager, and does not guarantee that a subsequent operation succeeds. Changing the proxy endpoint requires the key store to be disconnected, during which cryptographic operations on its KMS keys are rejected. Rotating the proxy credential does not interrupt operations, provided the new credential is configured on the proxy before the key store is updated. See [Operate an External Key Store](https://community.exoscale.com/product/security/kms/how-to/operate-external-key-store/index.md). A key store belongs to a single zone, and its KMS keys cannot be multi-zone keys. ### Durability Exoscale KMS holds the key material of each KMS key in an External Key Store, but never holds, and cannot recover, the external key. Client is responsible for: * Backup of the external keys. * Decisions to delete KMS keys in an External Key Store. If an external key is destroyed or lost, all data encrypted under the associated KMS keys becomes unrecoverable, by the Client or by Exoscale. A deleted KMS key cannot be recreated from its external key: a new KMS key referencing the same external key has different key material and cannot decrypt the ciphertext of the deleted key. Ciphertext produced by a KMS key in an External Key Store can only be decrypted through Exoscale KMS, not with the external key alone. ### Security The XKS proxy and the external key manager are outside the trust boundary of Exoscale. Exoscale KMS treats every response of the proxy as untrusted input. #### Exoscale Responsibilities For every request on an External Key Store and its KMS keys, Exoscale is responsible for: * Authorization of the request through IAM. * The inner layer of encryption, applied with the key material of the KMS key before any data is sent to the proxy. * Authentication of the proxy through TLS, and signature of the request with the proxy credential using AWS SigV4. * Encrypted storage of the proxy credential. * Validation of the proxy response before a result is returned. Plaintext never reaches the proxy or the external key manager. Requests to the proxy carry the inner ciphertext, the encryption context of the request, and request metadata such as the ERNs of the KMS key and of the calling principal. Exoscale KMS selects the key material used for decryption from its own records, never from the proxy response. A decryption either returns plaintext that was encrypted under the KMS key, or fails. Exoscale KMS never returns modified or attacker-chosen plaintext as a result of proxy misbehavior. #### Limitations The XKS proxy API provides no mechanism by which Exoscale KMS can verify that the external key manager took part in an operation. A proxy that does not forward requests to the external key manager can return responses that pass every validation performed by Exoscale KMS. Exoscale cannot mitigate the following cases: * *Fabricated responses.* The proxy never contacts the external key manager, returns well-formed encryption responses, records the inner ciphertext it receives, and returns it on decryption. Disabling the external key has no effect. A re-encryption handled this way affects the entire re-encrypted data set. * *Replayed responses.* The proxy records genuine responses of the external key manager, and returns them after the external key is disabled or destroyed. Only data decrypted at least once before the revocation is affected. * *Substituted key.* The proxy encrypts with a key other than the designated external key, such as a key held in software or copied by its operator. Its responses are indistinguishable from those of a correctly operating proxy. In each of these cases, the external key no longer protects the data. The data remains protected by the inner layer only, and [revoking access](https://community.exoscale.com/product/security/kms/overview/index.md#control-of-the-root-of-trust) to the external key does not make it inaccessible: any party able to have Exoscale KMS decrypt with the KMS key retains that ability after the revocation. This failure is silent: all requests succeed and no error is reported. Exoscale provides no mechanism to detect it. #### Client Responsibilities Client is responsible for: * Integrity of the XKS proxy, which must forward every request to the external key manager and use the designated external keys. * Independent verification that a revocation is effective. * Protection and rotation of the proxy credential on the proxy, and configuration of the proxy authorization rules. * Exclusion of confidential information from the encryption context of requests on KMS keys in an External Key Store, since the encryption context is sent to the proxy. A compromise of the XKS proxy is equivalent to a compromise of the external key. A successful disable or disconnect operation does not demonstrate that a revocation is effective: this is verified by correlating the audit logs of the external key manager with the expected cryptographic activity. The request metadata sent to the proxy, including the Exoscale KMS request ID, allows these logs to be correlated. See [Troubleshoot an External Key Store](https://community.exoscale.com/product/security/kms/how-to/troubleshoot-external-key-store/index.md#errors-from-your-proxy). A revocation does not affect plaintext data keys already held by applications or services, which remain usable until they are discarded. ## Exclusions No compensation or credit shall be granted if a service disruption, data unavailability, or data loss is caused by components or decisions under the Client's control, including: * Unavailability, errors, timeouts, throttling or latency of the XKS proxy, the external key manager, or the network between them and between the proxy and the internet. * Proxy responses that do not conform to the XKS Proxy API Specification or fail validation by Exoscale KMS. * DNS resolution failures, expired or untrusted certificates, or a proxy endpoint that is not reachable from Exoscale. * An endpoint or a credential in the key store that does not match the proxy. * Operations rejected while a key store is disconnected, including during a change of the proxy endpoint. * External keys that are disabled, deleted, lost or not usable for encryption and decryption, including data that becomes unrecoverable as a result. * Access to data persisting after a revocation because the proxy did not forward requests to the external key manager, as described under [Limitations](#limitations). * Disruption of Exoscale services or Client workloads using KMS keys in an External Key Store, when caused by any of the above. The exclusions of the [KMS SLA](https://community.exoscale.com/product/security/kms/service-boundaries/sla/index.md#exclusions) also apply. For the complete list of SLA exclusions, please refer to the [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/). These exclusions do not cover security incidents or data breaches resulting from a compromise of the underlying Exoscale infrastructure or failures within the Exoscale-managed KMS platform itself. ## Retribution Service credits apply only to the availability of Exoscale KMS for External Key Stores as defined above. The Affected Resources are the External Key Store that missed the target and the KMS keys it contains: the Service Credit is calculated on the connection fee of the External Key Store and the fees of these KMS keys for the calendar month concerned. The standard retribution and SLA credit schemes apply for Exoscale KMS External Key Stores as described under the [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. Service Credits shall be the Client's sole remedy in the event of a failure to meet the Service Level Objective. | Monthly Uptime Percentage | Service Credit Percentage of Monthly Service Fees for Affected Resources | | --------------------------- | ------------------------------------------------------------------------- | | from 99.95% to 98.3% | 50% | | below 98.3% | 100% | ### Claim Service Credit A claim identifies the External Key Store, the affected calendar month and 5-minute intervals, and, where available, the request IDs of the failed requests. To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies.