Systems Manager (SSM)

On this page

• Coverage by target cloud
• How the backends compare
  • Max adaptation
  • Infrastructure-only adaptation
• On Google Cloud
  • Via Secret Manager
  • Via Google Parameter Manager
• On Azure
• On OCI
• On Private Kubernetes
• Costs
• Service level agreements
  • Systems Manager (SSM) to Azure App Configuration
  • Systems Manager (SSM) to Google Parameter Manager
  • Systems Manager (SSM) to Secret Manager
  • Systems Manager (SSM) to OCI Vault
  • Systems Manager (SSM) to Kubernetes Secrets
• Debug this service

​

Coverage by target cloud

​

How the backends compare

Each row compares a capability of Systems Manager (SSM) with its adaptation on each backend. A dash means this row is not stated for that backend.

​

Max adaptation

​

Infrastructure-only adaptation

​

On Google Cloud

​

Via Secret Manager

​

Requests and durable parameter state

Your application keeps its AWS SDK Parameter Store calls; with Max adaptation they go to the Tensor9 adapter. The adapter saves a record of each parameter: name, type, current value, version counter, description and tags. Reads use that record. A background worker reconciles the current value to Google Secret Manager, meaning it copies the value there and keeps the copy up to date. PutParameter creates a parameter, or updates it when Overwrite=true. Writing an existing name with Overwrite=false returns ParameterAlreadyExists. Each write increases the AWS version counter and waits a limited time for the value to reach Google Secret Manager; if Google Secret Manager rejects the value outright, the error is returned. DeleteParameter removes the parameter from reads at once, and backend cleanup proceeds separately. Direct provider edits in Google Secret Manager do not update the AWS parameter record and can be overwritten by the next copy.

Reads come from the adapter’s records; the storage service holds a copy kept up to date in the background.

​

Batch reads, paths, and metadata

GetParameter and GetParameters read the records the caller is allowed to see. A batch read returns found and missing names separately. GetParametersByPath picks current records by path, follows the recursion setting, and returns pages in name order. It does not fetch each matching value from Google Secret Manager, so a deep path does not cost one storage-service read per parameter. DescribeParameters returns paginated metadata, including names, types, versions and descriptions, without parameter values. Tag operations update a parameter’s metadata.

​

Versions and labels

This mapping retains parameter history and named SSM labels. The adapter keeps the earlier values and the label-to-version references that GetParameterHistory, LabelParameterVersion, and version-qualified reads need. Moving a Secret Manager alias directly does not move an SSM label.

​

Storage and encryption

Google Secret Manager holds a copy of the current value in the customer’s project, accessed with Google workload identity. Its own versions and aliases describe that copy only; AWS reads and version selection are handled by the adapter. All three parameter types are supported. Secret Manager encrypts its copy at rest. Protect the adapter’s saved parameter state and its backups as well as the Secret Manager copy. Storing an ordinary String as a secret does not make its contents any less sensitive.

​

Limitations

Where this differs from Parameter Store

• Custom KMS keys, parameter policies and the Advanced tier are not supported. A per-parameter KMS key, parameter policies and Advanced-tier parameters are rejected.
• SecureString reads behave differently: they need decryption. Reading AWS ciphertext with WithDecryption=false is not supported. Where the mapping supports SecureString, read it with WithDecryption=true.
• Public, shared and change-event parameters are not supported. AWS-published public parameters, parameters shared from another account, and parameter-change events are outside this mapping.
• Full ParameterFilters behavior is not supported. DescribeParameters lists metadata, but complete ParameterFilters behavior is outside the documented scope.
• Systems Manager features beyond Parameter Store are not supported. Run Command, Session Manager, patching, State Manager and documents are outside this mapping.

​

Other considerations

Before switching the application. Load values through the Parameter Store API, and check reads, overwrites and deletion. Existing AWS values and history in Google Secret Manager are not imported automatically. Deployment can also set the stack’s own literal values from the release. Parameters the stack only reads are supplied by the customer during installation, which is separate from managing parameters at runtime. Operating it. Protect and back up the adapter’s saved state as well as Google Secret Manager. The storage service, access permissions, the background copy and the availability of the adapter’s state all affect operation. Performance figures. Historical direct-proxy measurements describe their recorded request path; they do not establish Max latency, throughput, or per-read provider charges.

​

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.

SSM Parameter Store · Standard read requests

Feature: SSM Parameter Store. Estimated monthly service charges by Standard read 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained active provider versions, independent of logical source objects; access operations are separate from local adapter reads, and management operations are free. The account-wide free tier (6 versions, 10,000 accesses a month) is not applied.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Secret Manager pricing: https://cloud.google.com/secret-manager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-3bea5aaf7f762bd82d5da337677696dfad4c50a5 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing.

SSM Parameter Store · Standard parameters

Feature: SSM Parameter Store. Estimated monthly service charges by Standard parameters. 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained active provider versions, independent of logical source objects; access operations are separate from local adapter reads, and management operations are free. The account-wide free tier (6 versions, 10,000 accesses a month) is not applied.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Secret Manager pricing: https://cloud.google.com/secret-manager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-3bea5aaf7f762bd82d5da337677696dfad4c50a5 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing. SSM Parameter Store → Secret Manager: 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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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: 10,000 operations.
• Translated resident physical data: 0.0143 GiB-month.
• Native provider operations: 55,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: 2,000 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained active provider versions, independent of logical source objects; access operations are separate from local adapter reads, and management operations are free. The account-wide free tier (6 versions, 10,000 accesses a month) is not applied.
• 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-3bea5aaf7f762bd82d5da337677696dfad4c50a5 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing.

​

Via Google Parameter Manager

​

Requests and durable parameter state

Your application keeps its AWS SDK Parameter Store calls; with Max adaptation they go to the Tensor9 adapter. The adapter saves a record of each parameter: name, type, current value, version counter, description and tags. Reads use that record. A background worker reconciles the current value to Google Parameter Manager, meaning it copies the value there and keeps the copy up to date. PutParameter creates a parameter, or updates it when Overwrite=true. Writing an existing name with Overwrite=false returns ParameterAlreadyExists. Each write increases the AWS version counter and waits a limited time for the value to reach Google Parameter Manager; if Google Parameter Manager rejects the value outright, the error is returned. DeleteParameter removes the parameter from reads at once, and backend cleanup proceeds separately. Direct provider edits in Google Parameter Manager do not update the AWS parameter record and can be overwritten by the next copy.

Reads come from the adapter’s records; the storage service holds a copy kept up to date in the background.

​

Batch reads, paths, and metadata

GetParameter and GetParameters read the records the caller is allowed to see. A batch read returns found and missing names separately. GetParametersByPath picks current records by path, follows the recursion setting, and returns pages in name order. It does not fetch each matching value from Google Parameter Manager, so a deep path does not cost one storage-service read per parameter. DescribeParameters returns paginated metadata, including names, types, versions and descriptions, without parameter values. Tag operations update a parameter’s metadata.

​

Versions and labels

This mapping retains parameter history and named SSM labels. The adapter keeps earlier values and label-to-version references for GetParameterHistory, LabelParameterVersion, and version-qualified reads. Parameter Manager has no version aliases of its own, and reads never just pick its highest version.

​

Storage and encryption

Google Parameter Manager holds a copy of the parameter value in the customer’s project, accessed with Google workload identity. Parameter Manager resources and their versions are only that copy; the adapter keeps the AWS parameter name, current version and read behavior. All three parameter types are supported. Parameter Manager encrypts its copy at rest. Protect the adapter’s saved state and its backups too. Parameter Manager resources can hold sensitive values, so choose access controls by what they contain, not by the service’s name.

​

Limitations

Where this differs from Parameter Store

• Custom KMS keys, parameter policies and the Advanced tier are not supported. A per-parameter KMS key, parameter policies and Advanced-tier parameters are rejected.
• SecureString reads behave differently: they need decryption. Reading AWS ciphertext with WithDecryption=false is not supported. Where the mapping supports SecureString, read it with WithDecryption=true.
• Public, shared and change-event parameters are not supported. AWS-published public parameters, parameters shared from another account, and parameter-change events are outside this mapping.
• Full ParameterFilters behavior is not supported. DescribeParameters lists metadata, but complete ParameterFilters behavior is outside the documented scope.
• Systems Manager features beyond Parameter Store are not supported. Run Command, Session Manager, patching, State Manager and documents are outside this mapping.

​

Other considerations

Before switching the application. Load values through the Parameter Store API, and check reads, overwrites and deletion. Existing AWS values and history in Google Parameter Manager are not imported automatically. Deployment can also set the stack’s own literal values from the release. Parameters the stack only reads are supplied by the customer during installation, which is separate from managing parameters at runtime. Operating it. Protect and back up the adapter’s saved state as well as Google Parameter Manager. The storage service, access permissions, the background copy and the availability of the adapter’s state all affect operation. Performance figures. Historical direct-proxy measurements describe their recorded request path; they do not establish Max latency, throughput, or per-read provider charges.

​

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.

SSM Parameter Store · Standard read requests

Feature: SSM Parameter Store. Estimated monthly service charges by Standard read 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained parameter versions; get and render calls are access operations and management operations are free. The account-wide free tier (6 versions, 10,000 operations a month) is not applied.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Secret Manager pricing (Parameter Manager section): https://cloud.google.com/secret-manager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-a17979490370f05e38868d643e884b5a5628ef05 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing (Parameter Manager section).

SSM Parameter Store · Standard parameters

Feature: SSM Parameter Store. Estimated monthly service charges by Standard parameters. 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained parameter versions; get and render calls are access operations and management operations are free. The account-wide free tier (6 versions, 10,000 operations a month) is not applied.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Secret Manager pricing (Parameter Manager section): https://cloud.google.com/secret-manager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-a17979490370f05e38868d643e884b5a5628ef05 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing (Parameter Manager section). SSM Parameter Store → Google Parameter Manager: 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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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: 10,000 operations.
• Translated resident physical data: 0.0143 GiB-month.
• Native provider operations: 55,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: 2,000 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Monthly resource quantity is retained parameter versions; get and render calls are access operations and management operations are free. The account-wide free tier (6 versions, 10,000 operations a month) is not applied.
• 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-a17979490370f05e38868d643e884b5a5628ef05 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Secret Manager pricing (Parameter Manager section).

​

On Azure

​

Requests and durable parameter state

Your application keeps its AWS SDK Parameter Store calls; with Max adaptation they go to the Tensor9 adapter. The adapter saves a record of each parameter: name, type, current value, version counter, description and tags. Reads use that record. A background worker reconciles the current value to Azure App Configuration, meaning it copies the value there and keeps the copy up to date. PutParameter creates a parameter, or updates it when Overwrite=true. Writing an existing name with Overwrite=false returns ParameterAlreadyExists. Each write increases the AWS version counter and waits a limited time for the value to reach Azure App Configuration; if Azure App Configuration rejects the value outright, the error is returned. DeleteParameter removes the parameter from reads at once, and backend cleanup proceeds separately. Direct provider edits in Azure App Configuration do not update the AWS parameter record and can be overwritten by the next copy.

Reads come from the adapter’s records; the storage service holds a copy kept up to date in the background.

​

Batch reads, paths, and metadata

GetParameter and GetParameters read the records the caller is allowed to see. A batch read returns found and missing names separately. GetParametersByPath picks current records by path, follows the recursion setting, and returns pages in name order. It does not fetch each matching value from Azure App Configuration, so a deep path does not cost one storage-service read per parameter. DescribeParameters returns paginated metadata, including names, types, versions and descriptions, without parameter values. Tag operations update a parameter’s metadata.

​

Versions and labels

This mapping retains numeric parameter versions; named SSM version labels are unsupported. App Configuration labels can hold earlier versions of the copy, but they are not SSM labels. The adapter owns the AWS version counter and selection, so the highest App Configuration label never decides what a read returns.

​

Storage and encryption

Azure App Configuration holds a copy of the value in the customer’s store, accessed with the deployment’s managed identity. Its key prefixes and labels organize that copy. GetParametersByPath searches the adapter’s records; it does not run a prefix query against App Configuration. String and StringList are supported. SecureString is not supported on this App Configuration mapping, and encrypting the store does not add it. Using Azure Key Vault directly is a separate option that needs application changes. Protect the adapter’s state and the encrypted App Configuration store.

​

Limitations

Where this differs from Parameter Store

• Custom KMS keys, parameter policies and the Advanced tier are not supported. A per-parameter KMS key, parameter policies and Advanced-tier parameters are rejected.
• SecureString reads behave differently: they need decryption. Reading AWS ciphertext with WithDecryption=false is not supported. Where the mapping supports SecureString, read it with WithDecryption=true.
• Public, shared and change-event parameters are not supported. AWS-published public parameters, parameters shared from another account, and parameter-change events are outside this mapping.
• Full ParameterFilters behavior is not supported. DescribeParameters lists metadata, but complete ParameterFilters behavior is outside the documented scope.
• Systems Manager features beyond Parameter Store are not supported. Run Command, Session Manager, patching, State Manager and documents are outside this mapping.

​

Other considerations

Before switching the application. Load values through the Parameter Store API, and check reads, overwrites and deletion. Existing AWS values and history in Azure App Configuration are not imported automatically. Deployment can also set the stack’s own literal values from the release. Parameters the stack only reads are supplied by the customer during installation, which is separate from managing parameters at runtime. Operating it. Protect and back up the adapter’s saved state as well as Azure App Configuration. The storage service, access permissions, the background copy and the availability of the adapter’s state all affect operation. Performance figures. Historical direct-proxy measurements describe their recorded request path; they do not establish Max latency, throughput, or per-read provider charges.

​

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.

SSM Parameter Store · Standard read requests

Feature: SSM Parameter Store. Estimated monthly service charges by Standard read 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Each Standard configuration store bills USD 1.20/day (36.50 for a 730-hour month) and includes 200,000 requests a day; only overage requests bill. The included 200,000 x 30.4167 days = 6,083,340 requests are one store’s monthly allowance; raise it when storeCount is above one. Each store includes 1 GB of storage. Free (USD 0) and Developer (0.12/day) stores are not 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices
• Azure App Configuration pricing: https://azure.microsoft.com/en-us/pricing/details/app-configuration/

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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-bea878d9f12ef87e1c7850166ff352935ca15b1e / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Azure Retail Prices API, Azure App Configuration pricing.

SSM Parameter Store · Standard parameters

Feature: SSM Parameter Store. Estimated monthly service charges by Standard parameters. 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Each Standard configuration store bills USD 1.20/day (36.50 for a 730-hour month) and includes 200,000 requests a day; only overage requests bill. The included 200,000 x 30.4167 days = 6,083,340 requests are one store’s monthly allowance; raise it when storeCount is above one. Each store includes 1 GB of storage. Free (USD 0) and Developer (0.12/day) stores are not 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• Azure Retail Prices API: https://prices.azure.com/api/retail/prices
• Azure App Configuration pricing: https://azure.microsoft.com/en-us/pricing/details/app-configuration/

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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-bea878d9f12ef87e1c7850166ff352935ca15b1e / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Azure Retail Prices API, Azure App Configuration pricing. SSM Parameter Store → Azure App Configuration: 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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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: 10,000 operations.
• Translated resident physical data: 0.0143 GiB-month.
• Native provider operations: 55,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: 2,000 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Each Standard configuration store bills USD 1.20/day (36.50 for a 730-hour month) and includes 200,000 requests a day; only overage requests bill. The included 200,000 x 30.4167 days = 6,083,340 requests are one store’s monthly allowance; raise it when storeCount is above one. Each store includes 1 GB of storage. Free (USD 0) and Developer (0.12/day) stores are not 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-bea878d9f12ef87e1c7850166ff352935ca15b1e / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Azure Retail Prices API, Azure App Configuration pricing.

​

On OCI

​

Requests and durable parameter state

Your application keeps its AWS SDK Parameter Store calls; with Max adaptation they go to the Tensor9 adapter. The adapter saves a record of each parameter: name, type, current value, version counter, description and tags. Reads use that record. A background worker reconciles the current value to OCI Vault, meaning it copies the value there and keeps the copy up to date. PutParameter creates a parameter, or updates it when Overwrite=true. Writing an existing name with Overwrite=false returns ParameterAlreadyExists. Each write increases the AWS version counter and waits a limited time for the value to reach OCI Vault; if OCI Vault rejects the value outright, the error is returned. DeleteParameter removes the parameter from reads at once, and backend cleanup proceeds separately. Direct provider edits in OCI Vault do not update the AWS parameter record and can be overwritten by the next copy.

Reads come from the adapter’s records; the storage service holds a copy kept up to date in the background.

​

Batch reads, paths, and metadata

GetParameter and GetParameters read the records the caller is allowed to see. A batch read returns found and missing names separately. GetParametersByPath picks current records by path, follows the recursion setting, and returns pages in name order. It does not fetch each matching value from OCI Vault, so a deep path does not cost one storage-service read per parameter. DescribeParameters returns paginated metadata, including names, types, versions and descriptions, without parameter values. Tag operations update a parameter’s metadata.

​

Versions and labels

This mapping retains numeric parameter versions; named SSM labels are not supported. OCI stores versions of the copy, while the adapter maintains AWS version identity and selection. A vault versionNumber never bypasses the parameter record.

​

Storage and encryption

OCI Vault holds a copy of each value as a secret, including ordinary String configuration. You configure the vault, compartment, encryption key, and resource-principal access to manage and read secrets. The vault’s own secret versions describe the copy; the adapter keeps the AWS parameter record and serves reads from it. All three parameter types use the configured vault key for the copy. OCI schedules the final deletion of a secret, so that cleanup can finish after the parameter is no longer readable through AWS. When a parameter name is reused while OCI still keeps the old vault secret, the two must be reconciled without mixing the old secret’s version sequence into the new AWS parameter’s versions. Protect the adapter’s saved state and backups as well as the vault.

​

Limitations

Where this differs from Parameter Store

• Custom KMS keys, parameter policies and the Advanced tier are not supported. A per-parameter KMS key, parameter policies and Advanced-tier parameters are rejected.
• SecureString reads behave differently: they need decryption. Reading AWS ciphertext with WithDecryption=false is not supported. Where the mapping supports SecureString, read it with WithDecryption=true.
• Public, shared and change-event parameters are not supported. AWS-published public parameters, parameters shared from another account, and parameter-change events are outside this mapping.
• Full ParameterFilters behavior is not supported. DescribeParameters lists metadata, but complete ParameterFilters behavior is outside the documented scope.
• Systems Manager features beyond Parameter Store are not supported. Run Command, Session Manager, patching, State Manager and documents are outside this mapping.

​

Other considerations

Before switching the application. Load values through the Parameter Store API, and check reads, overwrites and deletion. Existing AWS values and history in OCI Vault are not imported automatically. Deployment can also set the stack’s own literal values from the release. Parameters the stack only reads are supplied by the customer during installation, which is separate from managing parameters at runtime. Operating it. Protect and back up the adapter’s saved state as well as OCI Vault. The storage service, access permissions, the background copy and the availability of the adapter’s state all affect operation. Performance figures. Historical direct-proxy measurements describe their recorded request path; they do not establish Max latency, throughput, or per-read provider charges.

​

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.

SSM Parameter Store · Standard read requests

Feature: SSM Parameter Store. Estimated monthly service charges by Standard read requests. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; 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-ashburn-1, 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• OCI Secret Management has no charge for secret versions or retrieval; only an HSM-protected protecting key above 20 versions or a private vault (USD 3.724/hour) would bill, and the default software-protected key is free.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• OCI Secret Management: https://www.oracle.com/security/cloud-security/secrets/

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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-f1d938dac22a5be9a1ea14f9d47946ed474017a3 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, OCI Secret Management.

SSM Parameter Store · Standard parameters

Feature: SSM Parameter Store. Estimated monthly service charges by Standard parameters. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; 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-ashburn-1, 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• OCI Secret Management has no charge for secret versions or retrieval; only an HSM-protected protecting key above 20 versions or a private vault (USD 3.724/hour) would bill, and the default software-protected key is free.
• 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
• OCI Secret Management: https://www.oracle.com/security/cloud-security/secrets/

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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-f1d938dac22a5be9a1ea14f9d47946ed474017a3 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, OCI Secret Management. SSM Parameter Store → OCI 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: us-ashburn-1. 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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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: 10,000 operations.
• Translated resident physical data: 0.0143 GiB-month.
• Native provider operations: 55,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: 2,000 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• OCI Secret Management has no charge for secret versions or retrieval; only an HSM-protected protecting key above 20 versions or a private vault (USD 3.724/hour) would bill, and the default software-protected key is free.
• 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-f1d938dac22a5be9a1ea14f9d47946ed474017a3 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, OCI Secret Management.

​

On Private Kubernetes

​

Requests and durable parameter state

Your application keeps its AWS SDK Parameter Store calls; with Max adaptation they go to the Tensor9 adapter. The adapter saves a record of each parameter: name, type, current value, version counter, description and tags. Reads use that record. A background worker reconciles the current value to Kubernetes Secrets, meaning it copies the value there and keeps the copy up to date. PutParameter creates a parameter, or updates it when Overwrite=true. Writing an existing name with Overwrite=false returns ParameterAlreadyExists. Each write increases the AWS version counter and waits a limited time for the value to reach Kubernetes Secrets; if Kubernetes Secrets rejects the value outright, the error is returned. DeleteParameter removes the parameter from reads at once, and backend cleanup proceeds separately. Direct provider edits in Kubernetes Secrets do not update the AWS parameter record and can be overwritten by the next copy.

Reads come from the adapter’s records; the storage service holds a copy kept up to date in the background.

​

Batch reads, paths, and metadata

GetParameter and GetParameters read the records the caller is allowed to see. A batch read returns found and missing names separately. GetParametersByPath picks current records by path, follows the recursion setting, and returns pages in name order. It does not fetch each matching value from Kubernetes Secrets, so a deep path does not cost one storage-service read per parameter. DescribeParameters returns paginated metadata, including names, types, versions and descriptions, without parameter values. Tag operations update a parameter’s metadata.

​

Versions and labels

This mapping retains the latest value and its increasing version counter. Previous values and named SSM labels are unsupported. The counter records how many writes happened; it does not make old values readable. Choose a mapping that keeps history if your application needs it.

​

Storage and encryption

A Kubernetes Secret holds a copy of the current value in the customer cluster, accessed with the deployment’s service account. AWS reads come from the adapter’s parameter records, not from a Kubernetes Secret lookup on each request, and the version counter belongs to those records. All three parameter type markers are kept. Kubernetes Secret values are base64-encoded, and base64 is not encryption. Configure Kubernetes access control and storage encryption, and protect the adapter’s saved state and backups. This option keeps everything inside the customer cluster, including in disconnected deployments.

​

Limitations

Where this differs from Parameter Store

• Custom KMS keys, parameter policies and the Advanced tier are not supported. A per-parameter KMS key, parameter policies and Advanced-tier parameters are rejected.
• SecureString reads behave differently: they need decryption. Reading AWS ciphertext with WithDecryption=false is not supported. Where the mapping supports SecureString, read it with WithDecryption=true.
• Public, shared and change-event parameters are not supported. AWS-published public parameters, parameters shared from another account, and parameter-change events are outside this mapping.
• Full ParameterFilters behavior is not supported. DescribeParameters lists metadata, but complete ParameterFilters behavior is outside the documented scope.
• Systems Manager features beyond Parameter Store are not supported. Run Command, Session Manager, patching, State Manager and documents are outside this mapping.

​

Other considerations

Before switching the application. Load values through the Parameter Store API, and check reads, overwrites and deletion. Existing AWS values and history in Kubernetes Secrets are not imported automatically. Deployment can also set the stack’s own literal values from the release. Parameters the stack only reads are supplied by the customer during installation, which is separate from managing parameters at runtime. Operating it. Protect and back up the adapter’s saved state as well as Kubernetes Secrets. The storage service, access permissions, the background copy and the availability of the adapter’s state all affect operation. Performance figures. Historical direct-proxy measurements describe their recorded request path; they do not establish Max latency, throughput, or per-read provider charges.

​

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.

SSM Parameter Store · Standard read requests

Feature: SSM Parameter Store. Estimated monthly service charges by Standard read 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Self-hosted target: Tensor9-built Parameter Store 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-c9e30a21ca59da8a1b0b6ec5bb0dd3d3105fa347 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

SSM Parameter Store · Standard parameters

Feature: SSM Parameter Store. Estimated monthly service charges by Standard parameters. 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Self-hosted target: Tensor9-built Parameter Store 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 Systems Manager pricing: https://aws.amazon.com/systems-manager/pricing/
• AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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-c9e30a21ca59da8a1b0b6ec5bb0dd3d3105fa347 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. SSM Parameter Store → Kubernetes Secrets: 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.
• Systems Manager sessions, Run Command, patching, automation, secure-string custom-key calls and physical regional replicas.
• 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: 10,000 operations.
• Translated resident physical data: 0.0143 GiB-month.
• Native provider operations: 55,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: 2,000 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.
• Application reads use durable adapter records. Managed operations estimate independent backend reconciliation, not a provider secret-access charge on every application read.
• Only Parameter Store is represented. A paid advanced source meter does not imply support for advanced parameter policies on the selected backend.
• Parameter history is stored in durable ParameterFacet records; the provider copy is maintained independently.
• Self-hosted target: Tensor9-built Parameter Store 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-c9e30a21ca59da8a1b0b6ec5bb0dd3d3105fa347 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Systems Manager pricing, AWS Price List API, AWSSystemsManager offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

​

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: Systems Manager (SSM) 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.

​

Systems Manager (SSM) to Azure App Configuration

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

Parameter reads are adapter lookups plus AWS-shape conversion; writes validate names, types, encryption choices and version transitions before committing durable adapter state. Reconciliation to azure::1.0.0::app-configuration is asynchronous unless the directed profile explicitly states otherwise, so provider execution is not hidden inside the proposed fabric latency.

​

How the latency targets were chosen

Point parameter reads: +3 ms monthly p99 (adapter-added). GetParameter, GetParameterHistory. Local lookup, authorization and AWS response conversion. Bounded batch and path reads: +10 ms monthly p99 (adapter-added). DescribeParameters, GetParameters, GetParametersByPath. Bounded fan-out/page assembly without provider execution. Parameter and version mutation: +10 ms monthly p99 (adapter-added). DeleteParameter, DeleteParameters, LabelParameterVersion, PutParameter. Validation and serialized durable mutation per parameter. 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

Independent parameter names shard naturally. Path and discovery calls are bounded page operations and must be qualified with a fixed returned-entry and examined-entry limit. Hot-name writes, version-label moves and encryption-key use are measured separately from broad read traffic; no target-store quota is represented as adapter capacity. 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

Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.

​

Example and diagnosis

An application reads ten parameters while a deployment updates one unrelated name. The batch-read target covers the adapter’s lookup and response assembly for those ten names. The write target covers validation and durable version creation; later target reconciliation is observable separately and cannot rewrite the version returned to the caller. 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.

​

Systems Manager (SSM) to Google Parameter Manager

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

Parameter reads are adapter lookups plus AWS-shape conversion; writes validate names, types, encryption choices and version transitions before committing durable adapter state. Reconciliation to google::1.0.0::parameter-manager is asynchronous unless the directed profile explicitly states otherwise, so provider execution is not hidden inside the proposed fabric latency.

​

How the latency targets were chosen

Point parameter reads: +3 ms monthly p99 (adapter-added). GetParameter, GetParameterHistory. Local lookup, authorization and AWS response conversion. Bounded batch and path reads: +10 ms monthly p99 (adapter-added). DescribeParameters, GetParameters, GetParametersByPath. Bounded fan-out/page assembly without provider execution. Parameter and version mutation: +10 ms monthly p99 (adapter-added). DeleteParameter, DeleteParameters, LabelParameterVersion, PutParameter. Validation and serialized durable mutation per parameter. 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

Independent parameter names shard naturally. Path and discovery calls are bounded page operations and must be qualified with a fixed returned-entry and examined-entry limit. Hot-name writes, version-label moves and encryption-key use are measured separately from broad read traffic; no target-store quota is represented as adapter capacity. 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

Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.

​

Example and diagnosis

An application reads ten parameters while a deployment updates one unrelated name. The batch-read target covers the adapter’s lookup and response assembly for those ten names. The write target covers validation and durable version creation; later target reconciliation is observable separately and cannot rewrite the version returned to the caller. 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.

​

Systems Manager (SSM) to Secret Manager

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

Parameter reads are adapter lookups plus AWS-shape conversion; writes validate names, types, encryption choices and version transitions before committing durable adapter state. Reconciliation to google::1.0.0::secret-manager is asynchronous unless the directed profile explicitly states otherwise, so provider execution is not hidden inside the proposed fabric latency.

​

How the latency targets were chosen

Point parameter reads: +3 ms monthly p99 (adapter-added). GetParameter, GetParameterHistory. Local lookup, authorization and AWS response conversion. Bounded batch and path reads: +10 ms monthly p99 (adapter-added). DescribeParameters, GetParameters, GetParametersByPath. Bounded fan-out/page assembly without provider execution. Parameter and version mutation: +10 ms monthly p99 (adapter-added). DeleteParameter, DeleteParameters, LabelParameterVersion, PutParameter. Validation and serialized durable mutation per parameter. 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

Independent parameter names shard naturally. Path and discovery calls are bounded page operations and must be qualified with a fixed returned-entry and examined-entry limit. Hot-name writes, version-label moves and encryption-key use are measured separately from broad read traffic; no target-store quota is represented as adapter capacity. 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

Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.

​

Example and diagnosis

An application reads ten parameters while a deployment updates one unrelated name. The batch-read target covers the adapter’s lookup and response assembly for those ten names. The write target covers validation and durable version creation; later target reconciliation is observable separately and cannot rewrite the version returned to the caller. 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.

​

Systems Manager (SSM) to OCI 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

Parameter reads are adapter lookups plus AWS-shape conversion; writes validate names, types, encryption choices and version transitions before committing durable adapter state. Reconciliation to oci::1.0.0::vault is asynchronous unless the directed profile explicitly states otherwise, so provider execution is not hidden inside the proposed fabric latency.

​

How the latency targets were chosen

Point parameter reads: +3 ms monthly p99 (adapter-added). GetParameter, GetParameterHistory. Local lookup, authorization and AWS response conversion. Bounded batch and path reads: +10 ms monthly p99 (adapter-added). DescribeParameters, GetParameters, GetParametersByPath. Bounded fan-out/page assembly without provider execution. Parameter and version mutation: +10 ms monthly p99 (adapter-added). DeleteParameter, DeleteParameters, PutParameter. Validation and serialized durable mutation per parameter. 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

Independent parameter names shard naturally. Path and discovery calls are bounded page operations and must be qualified with a fixed returned-entry and examined-entry limit. Hot-name writes, version-label moves and encryption-key use are measured separately from broad read traffic; no target-store quota is represented as adapter capacity. 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

Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.

​

Example and diagnosis

An application reads ten parameters while a deployment updates one unrelated name. The batch-read target covers the adapter’s lookup and response assembly for those ten names. The write target covers validation and durable version creation; later target reconciliation is observable separately and cannot rewrite the version returned to the caller. 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.

​

Systems Manager (SSM) to Kubernetes Secrets

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

Parameter reads are adapter lookups plus AWS-shape conversion; writes validate names, types, encryption choices and version transitions before committing durable adapter state. Reconciliation to tensor9::1.0.0::emu::aws/1.0.0/ssm::kube is asynchronous unless the directed profile explicitly states otherwise, so provider execution is not hidden inside the proposed fabric latency.

​

How the latency targets were chosen

Point parameter reads: +3 ms monthly p99 (adapter-added). GetParameter. Local lookup, authorization and AWS response conversion. Bounded batch and path reads: +10 ms monthly p99 (adapter-added). DescribeParameters, GetParameters, GetParametersByPath. Bounded fan-out/page assembly without provider execution. Parameter and version mutation: +10 ms monthly p99 (adapter-added). DeleteParameter, DeleteParameters, PutParameter. Validation and serialized durable mutation per parameter. 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

Independent parameter names shard naturally. Path and discovery calls are bounded page operations and must be qualified with a fixed returned-entry and examined-entry limit. Hot-name writes, version-label moves and encryption-key use are measured separately from broad read traffic; no target-store quota is represented as adapter capacity. 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

Successful writes preserve value bytes, type, version and label ownership. SecureString never falls back to plaintext, WithDecryption=false retains ciphertext semantics where supported, and unsupported Advanced-tier policies or public/shared parameters fail explicitly rather than widening access.

​

Example and diagnosis

An application reads ten parameters while a deployment updates one unrelated name. The batch-read target covers the adapter’s lookup and response assembly for those ten names. The write target covers validation and durable version creation; later target reconciliation is observable separately and cannot rewrite the version returned to the caller. 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.