Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of ACM (certificates) 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

​
How it works

On AWS, ACM issues and renews the certificate, and a load balancer, CDN or API gateway uses it by ARN. By default, ACM does not expose the private key. On Google Cloud, Tensor9 creates one Google-managed certificate for each aws_acm_certificate during installation and points the HTTPS load balancer or proxy at it. Google issues and renews the certificate and never exposes its key. Tensor9 is not in the path of your application’s requests. The ACM operation names on this card describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the backend service and its access controls.
On AWS, ACM validates and issues the certificate and the load balancer uses it by ARN. On Google Cloud, Tensor9 creates a Google-managed certificate during installation and attaches it to your load balancer.On AWS, ACM validates and issues the certificate and the load balancer uses it by ARN. On Google Cloud, Tensor9 creates a Google-managed certificate during installation and attaches it to your load balancer.

Tensor9 creates a Google-managed certificate during installation and attaches it to your load balancer.

​
Managed and self-managed certificates

A google_certificate_manager_certificate is either managed or self_managed. Tensor9 creates a managed certificate whose domains are your domain_name and subject_alternative_names, with one dns_authorizations entry per domain. Google issues a publicly trusted certificate, chooses its key algorithm and renews it, as ACM does for RequestCertificate. In self_managed mode, Google serves a certificate, chain and pem_private_key you supply, and you renew it. Tensor9 does not use this mode: an ACM certificate imported with certificate_body and private_key stops the build with an error.
A Google certificate is either managed, issued and renewed by Google, or self-managed, a certificate you supply. Tensor9 creates managed certificates; it does not import certificates.A Google certificate is either managed, issued and renewed by Google, or self-managed, a certificate you supply. Tensor9 creates managed certificates; it does not import certificates.

Tensor9 creates managed certificates, which Google issues and renews.

​
DNS validation

For ACM DNS validation, RequestCertificate returns the certificate ARN. DescribeCertificate supplies its DNS validation CNAME while the certificate is PENDING_VALIDATION. Publishing that record proves domain control. ACM then marks the certificate ISSUED and uses the DNS authorization for subsequent renewal. A google_certificate_manager_dns_authorization similarly returns a dns_resource_record CNAME to publish in your zone. Tensor9 creates one authorization per domain; one authorization covers a domain and its wildcard, such as example.com and *.example.com. If your stack wrote ACM’s validation records to Route 53, Tensor9 writes Google’s CNAME records to the matching Cloud DNS zone instead. A certificate with validation_method EMAIL or HTTP stops the build with an error; DNS is the supported method.
On AWS, a CNAME record in your zone proves domain control before ACM issues the certificate. On Google Cloud, a DNS authorization produces its own CNAME record, which goes in the same zone. Only DNS validation is supported.On AWS, a CNAME record in your zone proves domain control before ACM issues the certificate. On Google Cloud, a DNS authorization produces its own CNAME record, which goes in the same zone. Only DNS validation is supported.

Both clouds prove domain control with a CNAME record in your zone; Google’s comes from a DNS authorization.

​
Attaching the certificate

On AWS, a TLS consumer references the certificate by ARN. The load balancer listener, CloudFront distribution, or API gateway performs the TLS handshake. Google Certificate Manager attaches certificates through a google_certificate_manager_certificate_map, whose certificate_map_entry records link hostnames to certificates. The target HTTPS proxy picks a certificate by the hostname the client sends (Server Name Indication, SNI). Tensor9 points each reference to the ACM certificate’s ARN at the Google certificate instead.
On AWS the certificate is an ARN set on the listener. On Google Cloud, a certificate map links each hostname to a certificate, and the HTTPS proxy picks the certificate by the hostname the client asks for.On AWS the certificate is an ARN set on the listener. On Google Cloud, a certificate map links each hostname to a certificate, and the HTTPS proxy picks the certificate by the hostname the client asks for.

On AWS the certificate is an ARN on the listener; on Google a certificate map links hostnames to certificates.

​
Private key access

Default ACM public certificates are non-exportable: GetCertificate returns the certificate and chain without the key. Since 2025, ACM has also offered opt-in exportable public certificates. Google never exposes a managed certificate’s private key, and a self-managed certificate’s pem_private_key is accepted as input but never returned on read. So moving here does not widen who can read the key. ACM’s opt-in key export is not reproduced.
ACM returns a default certificate and chain but never its private key. Google never returns a managed certificate's key, or the key supplied with a self-managed certificate.ACM returns a default certificate and chain but never its private key. Google never returns a managed certificate's key, or the key supplied with a self-managed certificate.

Google never returns managed private keys or the private keys supplied with imported certificates.

​
Limitations

Where Google Certificate Manager and ACM differ
  • Email and HTTP validation are not supported. This mapping uses DNS authorization. A certificate with validation_method EMAIL or HTTP stops the build with an error.
  • Imported ACM certificates are not supported. A certificate imported into ACM with certificate_body and private_key stops the build with an error. Tensor9 creates only Google-managed certificates.
  • Choosing the key algorithm is not supported. Google chooses the key for a managed certificate. A certificate whose key_algorithm is anything other than RSA_2048 stops the build with an error, and keys cannot be exported.
  • Private CA and exportable ACM certificates are not supported. A certificate that sets certificate_authority_arn, or options.export = ENABLED, stops the build with an error rather than being reissued as a public certificate with a new key.
  • Subject alternative names from variables behave differently. Alternative names Tensor9 cannot read when it builds the deployment are left off the certificate, and the build reports a warning. A primary domain_name from a variable is resolved at deployment.
  • Certificate attachment behaves differently. A certificate map links hostnames to certificates on the HTTPS proxy, instead of an ARN on each listener. Check each hostname and each attachment when the AWS ARN is replaced.
  • Other ACM options are not supported. Public certificates are logged; ACM has deprecated its transparency-logging opt-out, and this mapping does not keep it. ACM hosted-ACME settings are not reproduced.

​
Other considerations

  • DNS records. The Cloud DNS zone for each domain must exist. Keep the DNS authorization CNAME records in place: Google needs them to renew the certificate.
  • Who does what. You control the Google project, the DNS zone and the load balancer. Google issues and renews managed certificates. Confirm the proxy serves the right certificate for every hostname.
  • Moving from AWS. Google issues new certificates during installation. Existing ACM certificates and keys are not transferred.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
AWS ACM public certificates · Active public certificates
Feature: AWS ACM public certificates. Estimated monthly service charges by Active public certificates. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: global; currency: USD.
AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.
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 → global, 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate Manager bills deployed certificates per project: the first 100 a month are free, then USD 0.20 per certificate-month to 2,000 and 0.10 above. RSA-3072/4096 TLS and mTLS connections (0.45 per million) are not modeled; DNS challenges, hosting and durable adapter state remain separately allocated.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • Certificate Manager pricing: https://cloud.google.com/certificate-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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-168d6137ea51de31531b7d13e78d3b865c15f0df / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Certificate Manager pricing.
AWS ACM public certificates · Certificate issuances and renewals
Feature: AWS ACM public certificates. Estimated monthly service charges by Certificate issuances and renewals. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: global; currency: USD.
AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.
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 remains at its authored default; issuance and renewal traffic varies independently. 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 → global, 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate Manager bills deployed certificates per project: the first 100 a month are free, then USD 0.20 per certificate-month to 2,000 and 0.10 above. RSA-3072/4096 TLS and mTLS connections (0.45 per million) are not modeled; DNS challenges, hosting and durable adapter state remain separately allocated.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • Certificate Manager pricing: https://cloud.google.com/certificate-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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-168d6137ea51de31531b7d13e78d3b865c15f0df / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Certificate Manager pricing. AWS ACM public certificates → Certificate 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: global. 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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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: 10,000 operations.
  • Translated writes: 33 operations.
  • Translated resident physical data: under 0.01 GiB-month.
  • Native provider operations: 726 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: 100 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate Manager bills deployed certificates per project: the first 100 a month are free, then USD 0.20 per certificate-month to 2,000 and 0.10 above. RSA-3072/4096 TLS and mTLS connections (0.45 per million) are not modeled; DNS challenges, hosting and durable adapter state remain separately allocated.
  • 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-168d6137ea51de31531b7d13e78d3b865c15f0df / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Certificate Manager pricing.

​
On Azure

​
Via Key Vault

​
How it works

On AWS, your stack requests a certificate from ACM and attaches it by ARN to a load balancer, CDN or API gateway, which handles TLS. By default, ACM does not expose the private key. On Azure, Tensor9 creates one azurerm_key_vault_certificate for each aws_acm_certificate, in the deployment’s shared Key Vault, and points the service that handles TLS at it. The certificate is self-signed, so clients must be set up to trust it. The ACM operation names on this card describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the backend service and its access controls.
On AWS, your stack requests an ACM certificate and attaches it by ARN to the load balancer or gateway. On Azure, Tensor9 creates a Key Vault certificate during installation and points the same TLS endpoint at it.On AWS, your stack requests an ACM certificate and attaches it by ARN to the load balancer or gateway. On Azure, Tensor9 creates a Key Vault certificate during installation and points the same TLS endpoint at it.

During installation, Tensor9 creates a Key Vault certificate and points your TLS endpoint at it.

​
What the certificate contains

The certificate’s certificate_policy holds your request. domain_name becomes the subject (CN=example.com), and domain_name plus subject_alternative_names become the DNS names, wildcards included. The key is always RSA 2048 and exportable, and the certificate is valid for 12 months. The policy sets issuer_parameters.name = Self, so Key Vault generates the key and self-signs the certificate. Wait for its certificate operation to complete; no separate DNS approval is required. Tensor9 always creates a new certificate and key. It does not copy an existing certificate body or key; if you must keep one, import it into Key Vault yourself with its chain and passphrase.
Each ACM certificate becomes one Key Vault certificate. Its policy holds the subject, the alternative names and an exportable RSA 2048 key, is valid for 12 months, and names Self as the issuer.Each ACM certificate becomes one Key Vault certificate. Its policy holds the subject, the alternative names and an exportable RSA 2048 key, is valid for 12 months, and names Self as the issuer.

Each ACM certificate becomes one Key Vault certificate whose policy names Self as the issuer.

​
Trust and validation

There is no PENDING_VALIDATION stage and no CNAME record to create: Key Vault issues the certificate as soon as its certificate operation completes. In exchange, browsers and other clients do not trust it until you distribute its root to them. For a publicly trusted certificate you need a different issuer: a certificate authority (CA) that Key Vault integrates with, such as DigiCert or GlobalSign, or an App Service Managed Certificate for an eligible App Service hostname. Tensor9 does not set up either; you configure it.
Key Vault creates and self-signs the certificate without a DNS challenge. Unlike an ACM public certificate, clients do not trust it until you distribute its root.Key Vault creates and self-signs the certificate without a DNS challenge. Unlike an ACM public certificate, clients do not trust it until you distribute its root.

Key Vault issues the self-signed certificate without a DNS challenge. Clients must be configured to trust it.

​
Getting a publicly trusted certificate

If your TLS endpoint is an App Service, you can create an azurerm_app_service_managed_certificate yourself. It uses an existing custom_hostname_binding to validate the hostname. Azure and DigiCert issue a publicly trusted certificate, and Microsoft renews it at no certificate charge. It covers one exact hostname, does not support wildcards, and needs an internet-reachable App Service for validation. It cannot be attached to an arbitrary load balancer. Use a partner CA when these restrictions do not fit your deployment.
An App Service Managed Certificate is validated through the App Service hostname binding, issued by Azure and DigiCert, publicly trusted and renewed automatically. It covers one exact, internet-reachable App Service hostname and no wildcards.An App Service Managed Certificate is validated through the App Service hostname binding, issued by Azure and DigiCert, publicly trusted and renewed automatically. It covers one exact, internet-reachable App Service hostname and no wildcards.

App Service Managed Certificates are publicly trusted and renew automatically. They cover one reachable App Service hostname and no wildcards.

​
Private key access

ACM’s GetCertificate returns the certificate and chain without the key. Default public certificates are non-exportable; ACM has offered opt-in exportable public certificates since 2025. Tensor9 sets key_properties.exportable = true on every certificate it creates, so anyone allowed to read the backing Key Vault secret can retrieve the private key. Restrict read access to that secret. To prevent export altogether, the certificate policy would need exportable = false or a non-exportable RSA-HSM or EC-HSM key, which is a change from what Tensor9 generates.
ACM returns a default certificate and chain but never its private key. The Key Vault certificate is exportable, so anyone who can read its backing secret can read the private key.ACM returns a default certificate and chain but never its private key. The Key Vault certificate is exportable, so anyone who can read its backing secret can read the private key.

The Key Vault certificate is exportable: anyone who can read its backing secret can read the private key.

​
Renewal

Key Vault renews a certificate according to the lifetime_action in its policy (AutoRenew at days_before_expiry or lifetime_percentage). The policy Tensor9 generates does not set a lifetime action of its own, so check the certificate’s renewal setting in Key Vault after installation. The certificate is valid for 12 months. Each renewal creates a new certificate and secret version. The TLS endpoint must use a versionless secret reference, or you must update its versioned reference, to pick up the renewed certificate. Self-signed certificates (issuer = Self) and certificates from integrated partner CAs can renew automatically. Imported certificates (issuer = Unknown) cannot: you obtain and import a replacement before expiry.
When Key Vault renews a certificate it creates a new version. A versionless secret reference lets the TLS endpoint pick up the new version. Self-signed and partner-CA certificates can renew automatically; imported ones cannot.When Key Vault renews a certificate it creates a new version. A versionless secret reference lets the TLS endpoint pick up the new version. Self-signed and partner-CA certificates can renew automatically; imported ones cannot.

Renewal creates a new version. A versionless secret reference lets the TLS endpoint follow it.

​
Limitations

Where Key Vault certificates and ACM differ
  • Certificates are not publicly trusted. Tensor9 generates a self-signed certificate (issuer Self), so browsers and other clients reject it until you distribute its root. Public trust needs a Key Vault partner CA or an App Service Managed Certificate, which you set up.
  • ACM domain validation is not supported. Key Vault issues from the certificate policy, so DNS, email and CloudFront HTTP validation are not reproduced. A certificate with validation_method EMAIL or HTTP stops the build with an error; use DNS validation.
  • Only RSA 2048 keys are supported. Every generated key is RSA 2048. A certificate whose key_algorithm is anything else, such as EC_prime256v1 or RSA_4096, stops the build with an error.
  • The private key behaves differently: it can be read. The generated key is exportable through the backing Key Vault secret, while ACM never returns a default certificate’s key. Restrict who can read that secret.
  • Private CA certificates are not supported. A certificate that sets certificate_authority_arn stops the build with an error, because a self-signed Key Vault certificate would not keep the private CA’s trust. Use a public ACM certificate.
  • Exportable ACM certificates are not supported. A certificate with options.export = ENABLED stops the build with an error, because Tensor9 would create a new key rather than keep the existing one.
  • Subject alternative names from variables behave differently. Names Tensor9 cannot read when it builds the deployment (variables or expressions) are left off the certificate, and the build reports a warning. The certificate then covers the primary domain only.
  • You must declare certificates as resources in the root module. A data "aws_acm_certificate" lookup, or a certificate declared in a child module, stops the build with an error.

​
Other considerations

  • Permissions. Tensor9 grants the appliance identity the Key Vault Certificates Officer role on the shared vault so it can create certificates. The gateway or App Service that handles TLS needs read access to the backing secret under its own Azure identity. Grant only the vault or object scope it needs.
  • Before switching traffic. Distribute the certificate’s root to your clients, confirm they accept it, and confirm the TLS endpoint can read the certificate. Check the renewal setting, and use a versionless secret reference where the endpoint supports one.
  • Recovery and name reuse. Key Vault soft-delete keeps a deleted certificate for its retention period, which affects recovery and reusing the same name.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
AWS ACM public certificates · Active public certificates
Feature: AWS ACM public certificates. Estimated monthly service charges by Active public certificates. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.
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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate operations bill as vault operations; a certificate renewal request through an integrated CA lists USD 3 and is not modeled. ACME DNS challenges, hosting and durable state require separate allocation.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • Azure Retail Prices API: https://prices.azure.com/api/retail/prices
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-21c50979198015a1fe8b833ea00c654bdcb9a531 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Azure Retail Prices API.
AWS ACM public certificates · Certificate issuances and renewals
Feature: AWS ACM public certificates. Estimated monthly service charges by Certificate issuances and renewals. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.
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 remains at its authored default; issuance and renewal traffic varies independently. 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate operations bill as vault operations; a certificate renewal request through an integrated CA lists USD 3 and is not modeled. ACME DNS challenges, hosting and durable state require separate allocation.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • Azure Retail Prices API: https://prices.azure.com/api/retail/prices
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-21c50979198015a1fe8b833ea00c654bdcb9a531 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Azure Retail Prices API. AWS ACM public certificates → Key Vault: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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: 10,000 operations.
  • Translated writes: 33 operations.
  • Translated resident physical data: under 0.01 GiB-month.
  • Native provider operations: 726 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: 100 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • Certificate operations bill as vault operations; a certificate renewal request through an integrated CA lists USD 3 and is not modeled. ACME DNS challenges, hosting and durable state require separate allocation.
  • 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-21c50979198015a1fe8b833ea00c654bdcb9a531 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, Azure Retail Prices API.

​
On Azure, OCI, and Private Kubernetes

​
Via cert-manager Certificate

​
How it works

On AWS, ACM issues and renews the certificate, and a load balancer, CDN or API gateway uses it by ARN. By default, ACM does not expose the private key. On Kubernetes, Tensor9 creates a cert-manager Certificate for each aws_acm_certificate during installation, in the traefik namespace, and points the Ingress at its TLS Secret. cert-manager gets a publicly trusted certificate from Let’s Encrypt and stores the certificate and key in that Secret. The ACM operation names on this card describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the backend service and its access controls.
On AWS, ACM validates and issues the certificate and the load balancer uses it by ARN. On Kubernetes, Tensor9 creates a cert-manager Certificate; cert-manager gets it from Let's Encrypt and stores it in a TLS Secret that the Ingress uses.On AWS, ACM validates and issues the certificate and the load balancer uses it by ARN. On Kubernetes, Tensor9 creates a cert-manager Certificate; cert-manager gets it from Let's Encrypt and stores it in a TLS Secret that the Ingress uses.

cert-manager stores the certificate in a TLS Secret that the Ingress uses for TLS.

​
The Certificate and its issuer

The Certificate (cert-manager.io/v1) Tensor9 creates sets three fields. secretName is your ACM resource name followed by -tls. dnsNames holds domain_name and subject_alternative_names, wildcards and variables included. issuerRef selects the tensor9-letsencrypt-prod ClusterIssuer. Validity, renewal timing and the key are left to cert-manager’s defaults: a 90-day Let’s Encrypt certificate with an RSA 2048 key. Tensor9 also installs cert-manager and that issuer. Its spec.acme names the Let’s Encrypt production server, the contact email you provide, and a dns01 solver that proves domain control by writing a record in your Route 53 hosted zone. ACM’s hosted ACME service, introduced in 2026, uses the same protocol.
Tensor9 creates a Certificate that names the TLS Secret to write and, through issuerRef, uses a Let's Encrypt ClusterIssuer whose dns01 solver proves domain control through Route 53.Tensor9 creates a Certificate that names the TLS Secret to write and, through issuerRef, uses a Let's Encrypt ClusterIssuer whose dns01 solver proves domain control through Route 53.

The Certificate names the TLS Secret to write and uses the Let’s Encrypt ClusterIssuer through issuerRef .

​
Issuance and DNS validation

cert-manager opens an ACME Order and publishes an _acme-challenge DNS record. Let’s Encrypt checks that record and signs the certificate. cert-manager writes the certificate and private key to the TLS Secret, then sets the Certificate’s Ready condition to true. The Ready condition replaces ACM’s separate aws_acm_certificate_validation wait, which Tensor9 removes along with the Route 53 validation records. Only DNS validation is supported: a certificate with validation_method EMAIL or HTTP stops the build with an error.
cert-manager opens an ACME order, the dns01 solver publishes a DNS record, Let's Encrypt reads it to confirm you control the domain, and the certificate and key are stored in the TLS Secret as the Certificate becomes Ready.cert-manager opens an ACME order, the dns01 solver publishes a DNS record, Let's Encrypt reads it to confirm you control the domain, and the certificate and key are stored in the TLS Secret as the Certificate becomes Ready.

Let’s Encrypt checks a DNS record, then the certificate and key are stored in the TLS Secret and the Certificate becomes Ready .

​
Renewal

cert-manager renews the certificate before it expires. Because Tensor9 does not set renewBefore, cert-manager’s default applies: renewal starts about two-thirds of the way through the certificate’s life and repeats the DNS check and issuance. Renewal writes the new certificate and key under the same secretName, so the Ingress reference stays valid. A certificate you import as a TLS Secret yourself is not renewed automatically.
cert-manager renews about two-thirds of the way through the certificate's life. Renewal changes the contents of the TLS Secret, not its name, so the Ingress keeps working, the same way an ACM certificate keeps its ARN.cert-manager renews about two-thirds of the way through the certificate's life. Renewal changes the contents of the TLS Secret, not its name, so the Ingress keeps working, the same way an ACM certificate keeps its ARN.

Renewal changes the contents of the TLS Secret, not its name, just as an ACM certificate keeps its ARN.

​
Private key access

The Secret contains tls.crt and tls.key. Any principal permitted to read it can retrieve the private key. Default ACM public certificates do not expose that key. Restrict Secret reads with Kubernetes role-based access control (RBAC), using Role and RoleBinding permissions for the relevant ServiceAccount. ACM’s opt-in exportable public certificates, available since 2025, also allow key retrieval; this difference is relative to default, non-exportable ACM certificates.
ACM returns a default certificate and chain but never the private key. On Kubernetes the key is stored in tls.key in the TLS Secret, so anyone who can read the Secret can read the key.ACM returns a default certificate and chain but never the private key. On Kubernetes the key is stored in tls.key in the TLS Secret, so anyone who can read the Secret can read the key.

Read access to the TLS Secret includes access to the private key in tls.key .

​
Clusters without internet access

Public issuance needs the cluster to reach Let’s Encrypt and to publish DNS challenge records. The resulting certificate is trusted by any client that trusts Let’s Encrypt. For a cluster without that access, you configure a selfSigned or ca issuer. Its certificates are privately trusted: distribute the root to every client that must accept them. They do not provide public trust.
A cluster that can reach Let's Encrypt gets a publicly trusted certificate. A cluster that cannot needs a selfSigned or ca issuer, whose certificates browsers do not trust until you distribute the root.A cluster that can reach Let's Encrypt gets a publicly trusted certificate. A cluster that cannot needs a selfSigned or ca issuer, whose certificates browsers do not trust until you distribute the root.

Public trust needs a cluster that can reach Let’s Encrypt; otherwise a selfSigned or ca issuer gives private trust only.

​
Limitations

Where cert-manager and ACM differ
  • The private key behaves differently: it can be read. The TLS Secret holds both the certificate and the private key, and any identity that can read the Secret can read the key. Default ACM public certificates never expose their keys.
  • Public issuance needs internet and DNS access. The cluster must reach Let’s Encrypt and publish DNS challenge records. Without that, a self-signed or private CA issuer is needed, and every client must be set up to trust it.
  • Only Route 53 DNS validation is supported. The Let’s Encrypt issuer’s DNS-01 solver writes to Route 53. A deployment whose DNS is Cloud DNS, Azure DNS, OCI DNS or Cloudflare fails with a DNS-provider-not-supported error.
  • Email and HTTP validation are not supported. A certificate with validation_method EMAIL or HTTP stops the build with an error; it is not converted to an ACME HTTP-01 challenge.
  • Only RSA 2048 keys are supported. A certificate whose key_algorithm is anything else, such as EC_prime256v1 or RSA_4096, stops the build with an error.
  • Private CA and exportable ACM certificates are not supported. A certificate that sets certificate_authority_arn, or options.export = ENABLED, stops the build with an error rather than being reissued by Let’s Encrypt with a new key.
  • Other ACM options are not supported. ACM hosted-ACME endpoint settings and ManagedBy=CLOUDFRONT are not reproduced. Public certificates are logged; ACM has deprecated the transparency-logging opt-out.
  • You must have a Kubernetes cluster in the deployment on Azure. On Azure, the Certificate needs an AKS cluster created in the same stack or a cluster you bring. If the stack only uses an external cluster, the build reports a blocking issue.

​
Other considerations

  • You operate cert-manager. Tensor9 installs cert-manager and the Let’s Encrypt issuer; you provide the contact email and operate them with the cluster. Make sure the DNS solver can write to the hosted zone, and watch for failed Orders and Certificates that are not Ready.
  • Check renewal at the Ingress. Renewal writes a new certificate to the same Secret. Confirm the Ingress reloads it and serves the renewed certificate. A TLS Secret you imported yourself needs replacements from you.
  • Moving from AWS. Wait for each Certificate to become Ready before switching traffic. Existing ACM certificates are not copied; Let’s Encrypt issues new ones. If you must keep a certificate and key you already hold, import them as a kubernetes.io/tls Secret.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
AWS ACM public certificates · Active public certificates
Feature: AWS ACM public certificates. Estimated monthly service charges by Active public certificates. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: in-cluster; currency: USD.
AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.AWS ACM public certificates · Active public certificates: monthly service charges by Active public certificates. Exact values are in the following table.
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 → in-cluster, 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • cert-manager (Apache-2.0) with an ACME issuer has no vendor charge and Let’s Encrypt issuance is free; the controller’s pods use node capacity, and DNS-01 challenge records bill under the DNS provider.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • cert-manager license: https://github.com/cert-manager/cert-manager/blob/master/LICENSE
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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-b9997b072d064101c5df2449030afac695fbe44e / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, cert-manager license.
AWS ACM public certificates · Certificate issuances and renewals
Feature: AWS ACM public certificates. Estimated monthly service charges by Certificate issuances and renewals. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: in-cluster; currency: USD.
AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.AWS ACM public certificates · Certificate issuances and renewals: monthly service charges by Certificate issuances and renewals. Exact values are in the following table.
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 remains at its authored default; issuance and renewal traffic varies independently. 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 → in-cluster, 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • cert-manager (Apache-2.0) with an ACME issuer has no vendor charge and Let’s Encrypt issuance is free; the controller’s pods use node capacity, and DNS-01 challenge records bill under the DNS provider.
  • 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 Certificate Manager pricing: https://aws.amazon.com/certificate-manager/pricing/
  • AWS Price List API, ACM offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/ACM/current/us-east-1/index.json
  • cert-manager license: https://github.com/cert-manager/cert-manager/blob/master/LICENSE
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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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-b9997b072d064101c5df2449030afac695fbe44e / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, cert-manager license. AWS ACM public certificates → cert-manager Certificate: 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: in-cluster. 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.
  • ACM Private CA, exportable public certificates, paid external CA fees, authoritative DNS zones/queries and load-balancer/data-transfer charges.
  • 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: 10,000 operations.
  • Translated writes: 33 operations.
  • Translated resident physical data: under 0.01 GiB-month.
  • Native provider operations: 726 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: 100 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.
  • Public non-exportable source certificates have a zero authored source price. Exportable certificates and private-CA certificates require different models.
  • Certificate storage, issuance polling, DNS challenges and adapter state differ from load-balancer traffic. Certificate trust and issuer availability remain backend-specific.
  • The Azure native-provisioning Key Vault profile can use self-signed certificates; it must not be presented as the same public-trust workflow as the separate ACME backend.
  • cert-manager (Apache-2.0) with an ACME issuer has no vendor charge and Let’s Encrypt issuance is free; the controller’s pods use node capacity, and DNS-01 challenge records bill under the DNS provider.
  • 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-b9997b072d064101c5df2449030afac695fbe44e / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Certificate Manager pricing, AWS Price List API, ACM offer, cert-manager license.

​
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: ACM Certificate costs.

​
Service level agreements

These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
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.

​
ACM Certificate to Key Vault

SLA status: Pending Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.

​
ACM Certificate to cert-manager Certificate

SLA status: Pending Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.

​
ACM Certificate to Certificate Manager

SLA status: Pending Operation-specific service levels for this adapter have not yet been defined. This adapter does not inherit another target service’s latency budget. Your signed agreement sets the applicable terms.

​
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.