> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud KMS

> Cloud KMS APIs with Cloud Adapter.

This page describes how Cloud KMS maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

## Supported environments

| Environment | Mapping |
| ----------- | ------- |
| AWS         | API     |
| Azure       | API     |

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

## How the targets compare

Each row compares a capability of Cloud KMS with its adaptation on each target.
A dash means this profile does not state the capability for that target.

### Cloud Adapter

| Capability   | Cloud KMS | AWS  | Azure   |
| ------------ | --------- | ---- | ------- |
| API coverage | full      | high | partial |

## On AWS

### KMS Keys

| Operation                    | Area   | Support      | Depth        | Notes                                                                                                                                                  |
| ---------------------------- | ------ | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| encrypt / decrypt            | Crypto | Supported    | Common       | Encrypt and decrypt calls use the adapter and the target key service. Both must be available for a request to succeed.                                 |
| Automatic rotation           | Keys   | Partial      | Most usage   | The target's automatic rotation period is at least 90 days. The build identifies shorter source periods instead of rounding them up silently.          |
| Key rings and keys           | Keys   | Supported    | Common       | The adapter retains key-ring names and identifiers as a logical grouping; each key becomes an AWS KMS key. No native AWS key-ring resource is created. |
| Protection level             | Keys   | Partial      | Most usage   | Hardware and external key protection do not map directly to the target's key stores. The build shows the resulting protection level.                   |
| Version-addressed operations | Keys   | Out of scope | Full surface | The target does not expose individual rotated key versions, so it cannot encrypt with a selected version or disable one version independently.         |

Cloud KMS key rings and keys map to AWS KMS, with encrypt and decrypt requests handled by the Tensor9 adapter. Both the adapter and AWS KMS must be available for these requests to succeed.

### Key identity and existing ciphertext

The adapter resolves the source key identifier and submits the cryptographic operation to the target service. A newly created key with the same display name has different key material and cannot decrypt earlier ciphertext. Arrange a permitted key import or re-encryption process before retiring the source key.

### Permissions and key lifecycle

Authorize both access to the adapter and use of the target key. Test the application's algorithms, version references, and rotation behavior. Disabling or destroying a key can affect later reads of old data, so verify those effects before changing the key lifecycle policy.

### Compatibility differences

AWS KMS does not expose individual versions of a rotated key. Requests to encrypt with a chosen version, or disable only one version, therefore have no equivalent. The build identifies rotation periods shorter than 90 days instead of silently rounding them up.

## On Azure

### Key Vault

| Operation                   | Area   | Support      | Depth        | Notes                                                                                                                                                    |
| --------------------------- | ------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Asymmetric sign and verify  | Crypto | Supported    | Most usage   | The vault performs asymmetric signing and verification.                                                                                                  |
| MAC signing keys            | Crypto | Out of scope | Most usage   | Rejected at build time: message authentication code (MAC) keys are symmetric, which standard Key Vault does not support.                                 |
| Symmetric encrypt / decrypt | Crypto | Out of scope | Common       | Rejected at build time: symmetric keys, the Cloud KMS default, require Azure Managed HSM. This mapping uses standard Key Vault, which cannot store them. |
| Key deletion and name reuse | Keys   | Partial      | Full surface | Deleted vaults and keys retain their names until purged. The build identifies this limitation on deleting and recreating an object with the same name.   |
| Key rings and keys          | Keys   | Supported    | Common       | a key ring becomes a vault and a key becomes a vault key                                                                                                 |
| Key versions                | Keys   | Supported    | Common       | The target exposes individual key versions, supporting requests addressed to a particular version.                                                       |

Cloud KMS keys map to Azure Key Vault, which exposes individual key versions. Asymmetric keys support signing and verification.

### Key identity and existing ciphertext

The adapter resolves the source key identifier and submits the cryptographic operation to the target service. A newly created key with the same display name has different key material and cannot decrypt earlier ciphertext. Arrange a permitted key import or re-encryption process before retiring the source key.

### Permissions and key lifecycle

Authorize both access to the adapter and use of the target key. Test the application's algorithms, version references, and rotation behavior. Disabling or destroying a key can affect later reads of old data, so verify those effects before changing the key lifecycle policy.

### Compatibility differences

The build rejects symmetric keys, including the Cloud KMS default. Standard Key Vault does not store symmetric keys; Azure Managed HSM does, but this mapping does not use it. Deleted vaults and keys retain their names until purged, which affects attempts to recreate them.

## Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

## Configure, tune and debug

Start with [setup](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.