KMS

On this page

• Coverage by target cloud
• How the backends compare
  • Max adaptation
• On Google Cloud
  • Via Cloud KMS
• On Google Cloud, Azure, and OCI
  • Via Appliance-hosted software keys
• On Azure
  • Via Key Vault
• Costs
• Service level agreements
  • KMS Keys to Key Vault
  • KMS Keys to Cloud KMS
• Debug this service

​

Coverage by target cloud

​

How the backends compare

Each row compares a capability of KMS with its adaptation on each backend. A dash means this row is not stated for that backend.

​

Max adaptation

​

On Google Cloud

​

Via Cloud KMS

​

How it works

Tensor9 runs a KMS adapter in your environment and sets AWS_ENDPOINT_URL_KMS to its local endpoint, so your AWS SDK calls such as Encrypt, Decrypt and GenerateDataKey reach it unchanged. The adapter performs each call with a Cloud KMS crypto key. Cloud KMS keeps the key material; data-key operations can return a plaintext data key for your application to use. Each AWS key becomes one symmetric crypto key in the key ring the installation creates for this deployment. Encryption, decryption, data keys, the encryption context and automatic rotation work as in AWS. Asymmetric keys, HMAC, grants and key policies are not supported; see Limitations.

Your KMS calls go to a Tensor9 adapter, which uses a crypto key in Google Cloud KMS.

​

Key identity and lifecycle

The adapter keeps records of your AWS key IDs, aliases, tags and key state. CreateKey creates the matching crypto key, and later requests resolve the AWS key ID to it. Cloud KMS performs the cryptographic operations and keeps the key material. An alias is a name the adapter keeps. Updating it changes which key later alias-based requests use; it does not move key material or rewrite existing ciphertext. Back up the adapter’s records, and keep the crypto keys and versions needed to decrypt stored data. ScheduleKeyDeletion records a waiting period of 7 to 30 days, 30 by default. Cancelling it leaves the key disabled; enable it before using it again. Final destruction follows Cloud KMS’s own retention rules, which can keep the key material longer than the adapter’s waiting period.

​

The key ring and its crypto keys

A Cloud KMS crypto key belongs to a key ring in a location. Each key has immutable versions, one of them primary. The adapter resolves an AWS key ID to its crypto key, and keeps alias/… mappings itself because Cloud KMS has no alias object. The key ring’s location decides where cryptographic operations run, for example us-east1 or the us multi-region. Encryption uses the primary version; decryption uses the version recorded in the ciphertext.

Each AWS key is one crypto key in a regional key ring; new encryption uses its primary version.

​

Supported keys and operations

CreateKey creates a symmetric Cloud KMS crypto key with purpose ENCRYPT_DECRYPT. A request for any other KeySpec or KeyUsage (RSA, ECC or HMAC keys), an imported-material Origin, or MultiRegion is rejected with UnsupportedOperationException. Encrypt, Decrypt, ReEncrypt, GenerateDataKey and GenerateDataKeyWithoutPlaintext are supported. Sign, Verify, GetPublicKey, data-key pairs, GenerateMac and VerifyMac return UnsupportedOperationException.

​

How GenerateDataKey works

GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. The application uses the plaintext key to encrypt its data locally, then discards that key and stores the wrapped copy beside the encrypted data. To read the data later, it asks the key service to decrypt the wrapped key. Cloud KMS has no single data-key call, so the adapter generates a random data key of the requested size and calls cryptoKeys.encrypt to wrap it, returning the usual Plaintext and CiphertextBlob. cryptoKeys.decrypt unwraps it later. Both calls bind the encryption context. The adapter adds the key ID to the Cloud KMS ciphertext so Decrypt can find the key; treat the blob as opaque.

The adapter generates a random data key and wraps it with cryptoKeys.encrypt .

​

Encryption context and authenticated data

An encryption context is a non-secret key/value map bound to ciphertext as additional authenticated data (AAD). Decryption requires the same context. Applications can use it to bind encrypted values to a tenant or purpose. Cloud KMS accepts up to 64 KiB of additionalAuthenticatedData. The adapter writes the context map in a fixed byte order, so the order of its entries does not affect decryption, and uses the same encoding for encryption and data-key wrapping. A different context makes decryption fail.

The adapter encodes the encryption context as additionalAuthenticatedData . Decryption requires the same context.

​

Rotation

Rotation creates a new version for later encryption. Older versions that stay enabled still decrypt existing ciphertext. EnableKeyRotation sets the crypto key’s rotation_period, which creates new versions on schedule and makes each one primary; GetKeyRotationStatus reports whether rotation is on. RotateKeyOnDemand returns UnsupportedOperationException. Older enabled versions stay usable until disabled or destroyed.

Rotation creates a primary version for new encryption. Earlier enabled versions can still decrypt existing data.

​

Limitations

Where Cloud KMS and AWS KMS differ

• Asymmetric keys and HMAC are not supported. CreateKey accepts only symmetric ENCRYPT_DECRYPT keys. Sign, Verify, GetPublicKey, data-key pairs, GenerateMac and VerifyMac return UnsupportedOperationException, and DeriveSharedSecret is not available.
• On-demand rotation is not supported. RotateKeyOnDemand returns UnsupportedOperationException. Automatic rotation works.
• Key policies and grants are not supported. Access to the crypto keys uses Google IAM. Grant operations and custom key policies are rejected; an encryption context does not replace a grant that limited callers or contexts.
• The ciphertext format behaves differently. The adapter wraps Cloud KMS ciphertext with the key ID that Decrypt needs. Treat CiphertextBlob as opaque. Existing AWS ciphertext cannot be decrypted with a new Google key.
• Imported key material and Multi-Region keys are not supported. A CreateKey with an imported-material origin or MultiRegion is rejected; import material through a Cloud KMS import job instead. A key ring’s location does not give separately addressable replica keys.
• ReEncrypt behaves differently. It decrypts and encrypts again under the destination key. The plaintext exists briefly inside the adapter but is never returned to the caller.

​

Other considerations

• Access and protection. Give the deployment identity the Cloud KMS permissions it needs at the key or key-ring scope; workload identity supplies its credentials. Google operates the key service; choose software or HSM protection for your keys.
• Keep data recoverable. Keep old key versions while ciphertext needs them, and back up the adapter’s key and alias records with your key inventory. Test disabling, cancelling deletion, rotation and recovery before you change production keys.
• Moving from AWS. Decrypt AWS ciphertext or unwrap data keys with the AWS key, then encrypt or wrap them under the new key. Keep AWS available until that is done and verified; creating a key does not convert stored ciphertext.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

AWS KMS · Crypto requests

Feature: AWS KMS. Estimated monthly service charges by Crypto requests. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 operations/s to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 operations/s. Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Resource inventory is retained SOFTWARE key versions; symmetric crypto work prices managedOperations and admin operations are free. HSM versions list USD 1/month and EXTERNAL 3/month.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Cloud KMS pricing: https://cloud.google.com/kms/pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-41eda65ede57a26b9cc517002df79c1d2a25e63d / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, awskms offer, Cloud KMS pricing.

AWS KMS · Logical keys

Feature: AWS KMS. Estimated monthly service charges by Logical keys. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Resource inventory is retained SOFTWARE key versions; symmetric crypto work prices managedOperations and admin operations are free. HSM versions list USD 1/month and EXTERNAL 3/month.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Cloud KMS pricing: https://cloud.google.com/kms/pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-41eda65ede57a26b9cc517002df79c1d2a25e63d / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, awskms offer, Cloud KMS pricing. AWS KMS → Cloud KMS: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 1,000,000 operations.
• Translated writes: 0 operations.
• Translated resident physical data: under 0.01 GiB-month.
• Native provider operations: 1,050,000 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 200 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Resource inventory is retained SOFTWARE key versions; symmetric crypto work prices managedOperations and admin operations are free. HSM versions list USD 1/month and EXTERNAL 3/month.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: plan-41eda65ede57a26b9cc517002df79c1d2a25e63d / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, awskms offer, Cloud KMS pricing.

​

On Google Cloud, Azure, and OCI

​

Via Appliance-hosted software keys

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

AWS KMS · Crypto requests

Feature: AWS KMS. Estimated monthly service charges by Crypto requests. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 operations/s to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 operations/s. Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Self-hosted target: Tensor9-built in-cluster KMS service; no vendor charge. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-903666407ef5896ce7f56d4a406ea675be6cb655 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, awskms offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

AWS KMS · Logical keys

Feature: AWS KMS. Estimated monthly service charges by Logical keys. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Self-hosted target: Tensor9-built in-cluster KMS service; no vendor charge. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
• Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
• Network pricing: https://cloud.google.com/vpc/network-pricing

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-903666407ef5896ce7f56d4a406ea675be6cb655 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, awskms offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. AWS KMS → Appliance-hosted software keys: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 1,000,000 operations.
• Translated writes: 0 operations.
• Translated resident physical data: under 0.01 GiB-month.
• Native provider operations: 1,050,000 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 200 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Self-hosted target: Tensor9-built in-cluster KMS service; no vendor charge. Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: plan-903666407ef5896ce7f56d4a406ea675be6cb655 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, awskms offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

On Azure

​

Via Key Vault

​

How it works

Tensor9 runs a KMS adapter in your environment and sets AWS_ENDPOINT_URL_KMS to its local endpoint, so your AWS SDK calls such as Encrypt, Decrypt and GenerateDataKey reach it unchanged. For each Encrypt, the adapter makes a new AES-256-GCM data key, encrypts your data locally, and has an RSA key in Key Vault wrap the data key with RSA-OAEP-256. Your plaintext size is not limited by the RSA key, and the encryption context is bound to the ciphertext as in AWS. The private key never leaves the vault. Every Decrypt is a vault operation that appears in the vault’s audit log, and removing the adapter’s access to the key makes every existing ciphertext undecryptable. Each Encrypt and Decrypt costs one round trip to the vault.

Your KMS calls go to a Tensor9 adapter; an RSA key in Azure Key Vault wraps each data key.

​

Key identity and lifecycle

The adapter keeps records of your AWS key IDs, aliases, tags and key state. CreateKey creates the matching key in the vault, and later requests resolve the AWS key ID to it. Key Vault performs the cryptographic operations and keeps the key material. An alias is a name the adapter keeps. Updating it changes which key later alias-based requests use; it does not move key material or rewrite existing ciphertext. Back up the adapter’s records, and keep the vault keys and versions needed to decrypt stored data. ScheduleKeyDeletion records a waiting period of 7 to 30 days, 30 by default. Cancelling it leaves the key disabled; enable it before using it again. Final removal from the vault follows Key Vault’s own retention rules, which can keep the key longer than the adapter’s waiting period.

​

The key in your vault

Each KMS key is an RSA 3072 key in your vault whose permitted operations are wrapKey and unwrapKey. A standard vault holds RSA and EC keys only; it has no symmetric AES key, so the adapter does the symmetric encryption itself. DescribeKey reports the key’s ID and state, and the adapter stores the AWS key description as a tag. Key Vault keeps every version of a key. The version that wrapped a data key is written into the ciphertext, and Decrypt unwraps with that exact version, so a new key version never strands older ciphertext.

Each KMS key is one RSA key in the vault that may only wrap and unwrap data keys.

​

Envelope encryption and data keys

GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. Your application encrypts its data locally with the plaintext key, discards it, and stores the wrapped copy beside the encrypted data. To read the data later, it asks KMS to decrypt the wrapped key. GenerateDataKeyWithoutPlaintext returns only the wrapped copy. Behind both, the adapter uses the same envelope as Encrypt: the vault’s RSA key wraps the data key, and the encryption context is bound to the result. ReEncrypt decrypts and encrypts again under the destination key inside the adapter, and never returns the plaintext.

The adapter encrypts with a random data key; the vault’s RSA key wraps and unwraps that data key.

​

Encryption context and supported operations

An encryption context is a non-secret key/value map bound to the ciphertext as additional authenticated data. Decrypt succeeds only with the same context, so you can tie encrypted values to a tenant or purpose. The adapter binds it inside the AES-256-GCM layer, so it works as it does in AWS. The symmetric operations are supported: Encrypt, Decrypt, ReEncrypt, GenerateDataKey and GenerateDataKeyWithoutPlaintext. Asymmetric operations (Sign, Verify, GetPublicKey), data-key pairs and HMAC (GenerateMac, VerifyMac) return UnsupportedOperationException. Ciphertext made by a different Tensor9 KMS backend is rejected rather than opened with the wrong key.

​

Key versions and rotation

Automatic key rotation is not supported on Key Vault: EnableKeyRotation is rejected, and RotateKeyOnDemand returns UnsupportedOperationException. Because each ciphertext names the key version that wrapped its data key, a new version created in Key Vault does not break older ciphertext. Keep old versions enabled and accessible while data encrypted under them is still needed; removing access to an old version makes that data undecryptable.

​

Limitations

Where Key Vault and AWS KMS differ

• Symmetric keys behave differently: the vault key is RSA. The adapter encrypts with AES-256-GCM itself and the vault’s RSA 3072 key wraps each data key. A caller inspecting the key in Key Vault finds an RSA key, not the symmetric key AWS would show.
• Asymmetric keys and HMAC are not supported. Sign, Verify, GetPublicKey, data-key pairs, GenerateMac and VerifyMac return UnsupportedOperationException. Azure Managed HSM and Key Vault Premium’s preview AES/HMAC keys are separate offerings outside this mapping.
• Key rotation is not supported. EnableKeyRotation is rejected and RotateKeyOnDemand returns UnsupportedOperationException.
• Grants and key policies are not supported. Grant operations and PutKeyPolicy are rejected. Use Azure role assignments for Key Vault access.
• Importing key material is not supported. The AWS import handshake is not available at runtime; imported material uses Key Vault’s own import procedure at provisioning.
• Multi-Region keys are not supported. A key lives in one vault and region; replica keys sharing material are not created.
• Deletion behaves differently. The adapter’s 7 to 30 day waiting period and the vault’s soft-delete retention are separate; vault retention and purge protection can delay final removal.

​

Other considerations

• Key protection. Key Vault Premium can protect RSA keys in an HSM; Managed HSM is a separate service. This mapping does not use their symmetric-key features.
• Access. Use the deployment’s Azure identity and narrowly scoped role assignments. Keep permission to manage keys separate from permission to unwrap data keys.
• Moving from AWS. Key material does not move. Decrypt AWS ciphertext with the AWS key and encrypt it again under the new key before you retire AWS access. Keep old Key Vault key versions while ciphertext needs them.

​

Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.

AWS KMS · Crypto requests

Feature: AWS KMS. Estimated monthly service charges by Crypto requests. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 operations/s to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 operations/s. Curve assumptions

• Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Key Vault crypto calls price managedOperations. Standard software-protected keys have no per-version storage meter; Premium HSM-protected keys list USD 1 per key-month and automated rotation 1 per rotation, neither selected.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-ef50affc42e0701bc747b2bf76645106c0ea8eb2 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, awskms offer, Azure Retail Prices API.

AWS KMS · Logical keys

Feature: AWS KMS. Estimated monthly service charges by Logical keys. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD. Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample. Curve assumptions

• Inventory varies independently of monthly reads and mutations. Retention remains an explicit planning assumption. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
• Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month.
• Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
• Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
• Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Key Vault crypto calls price managedOperations. Standard software-protected keys have no per-version storage meter; Premium HSM-protected keys list USD 1 per key-month and automated rotation 1 per rotation, neither selected.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
• AWS Price List API, awskms offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/awskms/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices

Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

List prices read: 2026-10-22. Model: plan-ef50affc42e0701bc747b2bf76645106c0ea8eb2 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, awskms offer, Azure Retail Prices API. AWS KMS → Key Vault: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:

• Free allowances, committed discounts, credits, taxes and negotiated rates.
• Commercial Tensor9 fees and operations labor unless entered separately.
• HSM/private vault allocations, asymmetric algorithm pricing, external key managers, imported-key handling and geographic replication.
• Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
• Unmodeled dependent services, task execution and operations outside the selected workload family.

Scenario assumptions

• Translated reads: 1,000,000 operations.
• Translated writes: 0 operations.
• Translated resident physical data: under 0.01 GiB-month.
• Native provider operations: 1,050,000 operations.
• Published payload: 0 GiB.
• Delivered payload: 0 GiB.
• Allocated execution CPU: 0 vCPU-hour.
• Allocated execution RAM: 0 GiB-hour.
• Independent resource allocation: 0 resource-hour.
• Independent inventory: 200 resource-month.
• Input tokens: 0 tokens.
• Output tokens: 0 tokens.
• Billable network: 0 GiB.
• Dependent object sink retained data: 0 GiB-month.
• Dependent object sink writes: 0 writes.
• Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
• Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
• Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
• Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
• A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
• This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
• Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
• ReEncrypt performs one decrypt and one encrypt. GenerateDataKey wraps a locally generated data key once. Public-key verification is local in this planning mix.
• Cloud-managed key versions and AWS logical key inventory use different billing units. Software-key custody and managed HSM custody are not equivalent.
• Key Vault crypto calls price managedOperations. Standard software-protected keys have no per-version storage meter; Premium HSM-protected keys list USD 1 per key-month and automated rotation 1 per rotation, neither selected.
• Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
• Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
• Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
• CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
• No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
• Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
• Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
• The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
• Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: plan-ef50affc42e0701bc747b2bf76645106c0ea8eb2 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, awskms offer, Azure Retail Prices API.

​

Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications. Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: KMS Keys costs.

​

Service level agreements

Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​

KMS Keys to Key Vault

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

Cryptographic calls include adapter authorization, request decoding, key/version lookup, policy enforcement and response encoding. Native HSM or provider cryptographic execution is separately spanned for azure::1.0.0::keyvault; local envelope handling, grant evaluation, encryption-context checks and retry policy remain covered adapter work.

​

How the latency targets were chosen

Cryptographic operations: +5 ms monthly p99 (adapter-added). Decrypt, Encrypt, GenerateDataKey, GenerateDataKeyWithoutPlaintext, ReEncrypt. Authorization, key resolution and bounded envelope conversion. Key metadata and bounded lists: +8 ms monthly p99 (adapter-added). DescribeKey, GetKeyRotationStatus, ListAliases, ListKeys, ListResourceTags. Local metadata lookup and bounded page encoding. Key, alias, policy and grant mutation: +15 ms monthly p99 (adapter-added). CancelKeyDeletion, CreateAlias, CreateKey, DeleteAlias, DisableKey, EnableKey, ScheduleKeyDeletion, TagResource, UntagResource, UpdateAlias, UpdateKeyDescription. Serialized durable metadata transition per key or alias. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Encrypt/decrypt and data-key calls scale across keys and adapter replicas. Mutations serialize per key or alias, and list operations use bounded pages. Qualification fixes plaintext/ciphertext size, encryption-context entries, grant count, key type and concurrency, and reserves capacity for authorization and audit work. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them.

​

Example and diagnosis

GenerateDataKey authorizes the caller and returns plaintext plus ciphertext bound to the selected key and context. Decrypt with a changed context must fail. Alias updates use the metadata-write group and become visible atomically; they do not silently retarget an in-flight cryptographic request. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

KMS Keys to Cloud KMS

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​

What this adapter does

Cryptographic calls include adapter authorization, request decoding, key/version lookup, policy enforcement and response encoding. Native HSM or provider cryptographic execution is separately spanned for google::1.0.0::kms; local envelope handling, grant evaluation, encryption-context checks and retry policy remain covered adapter work.

​

How the latency targets were chosen

Cryptographic operations: +5 ms monthly p99 (adapter-added). Decrypt, Encrypt, GenerateDataKey, GenerateDataKeyWithoutPlaintext, ReEncrypt. Authorization, key resolution and bounded envelope conversion. Key metadata and bounded lists: +8 ms monthly p99 (adapter-added). DescribeKey, GetKeyRotationStatus, ListAliases, ListKeys, ListResourceTags. Local metadata lookup and bounded page encoding. Key, alias, policy and grant mutation: +15 ms monthly p99 (adapter-added). CancelKeyDeletion, CreateAlias, CreateKey, DeleteAlias, DisableKey, DisableKeyRotation, EnableKey, EnableKeyRotation, ScheduleKeyDeletion, TagResource, UntagResource, UpdateAlias, UpdateKeyDescription. Serialized durable metadata transition per key or alias. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​

What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​

Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​

Scaling and target-service capacity

Encrypt/decrypt and data-key calls scale across keys and adapter replicas. Mutations serialize per key or alias, and list operations use bounded pages. Qualification fixes plaintext/ciphertext size, encryption-context entries, grant count, key type and concurrency, and reserves capacity for authorization and audit work. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​

Data and behavior guarantees

The adapter never substitutes a key, drops encryption context, returns plaintext to an unauthorized principal or acknowledges key-policy state before it is durable. Disabled and pending-deletion keys fail closed. Unsupported asymmetric, HMAC, import or multi-region shapes fail explicitly on profiles that do not cover them.

​

Example and diagnosis

GenerateDataKey authorizes the caller and returns plaintext plus ciphertext bound to the selected key and context. Decrypt with a changed context must fail. Alias updates use the metadata-write group and become visible atomically; they do not silently retarget an in-flight cryptographic request. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​

Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.