Skip to main content
Preview On this page

​
Coverage by target cloud

​
How the backends compare

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

​
Infrastructure-only adaptation

​
Runtime surface

​
Management surface

​
On Google Cloud

​
How it works

On AWS, CloudTrail records who called which API, when, and from where. When your Install selects CloudTrail, Tensor9 runs the CloudTrail API itself. Every AWS request your application makes goes through the Cloud Adapter, which records the original request, its verified caller, its time and its outcome in a durable history. LookupEvents reads that history, and each trail you create with CreateTrail delivers its selected events to the S3 bucket it names. CloudTrail is Preview: it is selected explicitly for an Install and qualified first on Google Cloud. Requests that do not pass through the Cloud Adapter, such as console sign-ins or direct calls to the cloud’s own APIs, are not in this history.
  • Your requests, as you made them. Each event is the original AWS request your application sent through the Cloud Adapter, with the verified caller, not the service account Tensor9 uses underneath.
  • One history, many trails. The history records continuously. Trails choose what they deliver, and stopping or deleting a trail does not erase the history.
  • Selected explicitly. CloudTrail runs only in an Install that selects it.
Your application's AWS SDK calls go through the Tensor9 Cloud Adapter, which records each original request with its verified caller, time and outcome in a durable history. LookupEvents reads that history, and each trail delivers its selected events to the S3 bucket it names. The cloud's own audit log is separate, and you turn it on.Your application's AWS SDK calls go through the Tensor9 Cloud Adapter, which records each original request with its verified caller, time and outcome in a durable history. LookupEvents reads that history, and each trail delivers its selected events to the S3 bucket it names. The cloud's own audit log is separate, and you turn it on.

Tensor9 records the requests made through the Cloud Adapter and answers CloudTrail from that history; the cloud’s own audit log is separate.

​
Reading history (LookupEvents)

LookupEvents answers from Tensor9’s history in the CloudTrail response shape: event ID, name, source, time, caller and the resources involved. It returns management events and supports a subset of LookupAttributes, paging with a NextToken that stays bound to your account and region. Data events are delivered by trails rather than returned by LookupEvents, as on AWS. If the history could not record some requests, for example while its database was unreachable, those requests are reported as a gap instead of silently missing, and LookupEvents does not present the history as complete across that gap.
  • Caller identity is the verified one. An unauthenticated or rejected request is recorded with an unknown caller, not the identity it asserted.
  • Gaps are explicit. Your other services keep working while CloudTrail records a gap.

​
Trails, logging and delivery

CreateTrail stores a trail that delivers to the S3 bucket it names; that bucket is provided by your Install like any other S3 bucket. StartLogging and StopLogging start and stop that trail’s delivery, GetTrailStatus reports whether it is delivering, and PutEventSelectors chooses which recorded requests it delivers. DescribeTrails, GetTrail, ListTrails, UpdateTrail, DeleteTrail and the trail tag calls work on the stored trails. Each delivered batch has a fixed object key, so if the delivery restarts partway it writes the same object again instead of a duplicate.
  • Rejected, not ignored. Multi-region and organization trails, log-file validation, and KMS, SNS or CloudWatch Logs settings are rejected with an error.
  • StopLogging stops one trail. The history keeps recording, and other trails keep delivering.

​
Your cloud’s own audit log

Each cloud also keeps its own audit log of calls made to its APIs, such as Google Cloud Audit Logs or a Kubernetes cluster’s API-server audit log. That log is separate from Tensor9’s CloudTrail history and records the cloud’s own API calls under the cloud’s own identities. Customers who want it turn it on directly with that cloud’s normal tools, for example the Google Cloud Audit Logs Data Access settings. Tensor9 does not read or configure it.

​
Limitations

Check these differences from AWS CloudTrail against your workload. Where Tensor9’s CloudTrail differs from AWS
  • Activity outside the Cloud Adapter is not recorded. Console sign-ins, direct calls to the cloud’s own APIs and other non-API activity do not appear in the history.
  • LookupEvents behaves differently: it supports a subset of filters. A subset of LookupAttributes is supported, and only management events are returned.
  • Multi-region and organization trails are not supported. A trail covers its own account and region; IsMultiRegionTrail or IsOrganizationTrail set to true is rejected.
  • Only S3 delivery is supported. KMS encryption, SNS notification and CloudWatch Logs delivery settings are rejected.
  • CloudTrail Insights and Lake are not supported. PutInsightSelectors / GetInsightSelectors anomaly detection and event data stores are not offered.
  • Log-file integrity validation is not supported. EnableLogFileValidation set to true is rejected, and ListPublicKeys is not offered.
  • Existing AWS history is not migrated. Your AWS trail history stays in its S3 bucket on AWS; Tensor9’s history starts when the Install selects CloudTrail.
  • CloudTrail is in Preview. It is qualified first on Google Cloud; delivery over TLS, other clouds and the service levels are still being qualified.

​
On Azure and Private Kubernetes

​
How it works

On AWS, CloudTrail records who called which API, when, and from where. When your Install selects CloudTrail, Tensor9 runs the CloudTrail API itself. Every AWS request your application makes goes through the Cloud Adapter, which records the original request, its verified caller, its time and its outcome in a durable history. LookupEvents reads that history, and each trail you create with CreateTrail delivers its selected events to the S3 bucket it names. CloudTrail is Preview: it is selected explicitly for an Install and qualified first on Google Cloud. Requests that do not pass through the Cloud Adapter, such as console sign-ins or direct calls to the cloud’s own APIs, are not in this history.
  • Your requests, as you made them. Each event is the original AWS request your application sent through the Cloud Adapter, with the verified caller, not the service account Tensor9 uses underneath.
  • One history, many trails. The history records continuously. Trails choose what they deliver, and stopping or deleting a trail does not erase the history.
  • Selected explicitly. CloudTrail runs only in an Install that selects it.
Your application's AWS SDK calls go through the Tensor9 Cloud Adapter, which records each original request with its verified caller, time and outcome in a durable history. LookupEvents reads that history, and each trail delivers its selected events to the S3 bucket it names. The cloud's own audit log is separate, and you turn it on.Your application's AWS SDK calls go through the Tensor9 Cloud Adapter, which records each original request with its verified caller, time and outcome in a durable history. LookupEvents reads that history, and each trail delivers its selected events to the S3 bucket it names. The cloud's own audit log is separate, and you turn it on.

Tensor9 records the requests made through the Cloud Adapter and answers CloudTrail from that history; the cloud’s own audit log is separate.

​
Reading history (LookupEvents)

LookupEvents answers from Tensor9’s history in the CloudTrail response shape: event ID, name, source, time, caller and the resources involved. It returns management events and supports a subset of LookupAttributes, paging with a NextToken that stays bound to your account and region. Data events are delivered by trails rather than returned by LookupEvents, as on AWS. If the history could not record some requests, for example while its database was unreachable, those requests are reported as a gap instead of silently missing, and LookupEvents does not present the history as complete across that gap.
  • Caller identity is the verified one. An unauthenticated or rejected request is recorded with an unknown caller, not the identity it asserted.
  • Gaps are explicit. Your other services keep working while CloudTrail records a gap.

​
Trails, logging and delivery

CreateTrail stores a trail that delivers to the S3 bucket it names; that bucket is provided by your Install like any other S3 bucket. StartLogging and StopLogging start and stop that trail’s delivery, GetTrailStatus reports whether it is delivering, and PutEventSelectors chooses which recorded requests it delivers. DescribeTrails, GetTrail, ListTrails, UpdateTrail, DeleteTrail and the trail tag calls work on the stored trails. Each delivered batch has a fixed object key, so if the delivery restarts partway it writes the same object again instead of a duplicate.
  • Rejected, not ignored. Multi-region and organization trails, log-file validation, and KMS, SNS or CloudWatch Logs settings are rejected with an error.
  • StopLogging stops one trail. The history keeps recording, and other trails keep delivering.

​
Your cloud’s own audit log

Each cloud also keeps its own audit log of calls made to its APIs, such as Google Cloud Audit Logs or a Kubernetes cluster’s API-server audit log. That log is separate from Tensor9’s CloudTrail history and records the cloud’s own API calls under the cloud’s own identities. Customers who want it turn it on directly with that cloud’s normal tools, for example the Google Cloud Audit Logs Data Access settings. Tensor9 does not read or configure it.

​
Limitations

Check these differences from AWS CloudTrail against your workload. Where Tensor9’s CloudTrail differs from AWS
  • Activity outside the Cloud Adapter is not recorded. Console sign-ins, direct calls to the cloud’s own APIs and other non-API activity do not appear in the history.
  • LookupEvents behaves differently: it supports a subset of filters. A subset of LookupAttributes is supported, and only management events are returned.
  • Multi-region and organization trails are not supported. A trail covers its own account and region; IsMultiRegionTrail or IsOrganizationTrail set to true is rejected.
  • Only S3 delivery is supported. KMS encryption, SNS notification and CloudWatch Logs delivery settings are rejected.
  • CloudTrail Insights and Lake are not supported. PutInsightSelectors / GetInsightSelectors anomaly detection and event data stores are not offered.
  • Log-file integrity validation is not supported. EnableLogFileValidation set to true is rejected, and ListPublicKeys is not offered.
  • Existing AWS history is not migrated. Your AWS trail history stays in its S3 bucket on AWS; Tensor9’s history starts when the Install selects CloudTrail.
  • CloudTrail is in Preview. It is qualified first on Google Cloud; delivery over TLS, other clouds and the service levels are still being qualified.

​
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.
CloudTrail management audit records · Management audit events
Feature: CloudTrail management audit records. Estimated monthly service charges by Management audit events. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
CloudTrail management audit records · Management audit events: monthly service charges by Management audit events. Exact values are in the following table.CloudTrail management audit records · Management audit events: monthly service charges by Management audit events. 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 from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 events/s to 96 vCPU, 624 GiB memory and 62,682 GiB SSD at 10,000 events/s. Curve assumptions
  • Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • Declared native management-audit comparison: the estimate covers selected native log resources and dependent archives. It establishes no runtime adapter, compiled-deployment availability or full CloudTrail feature 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.
  • This recipe accepts management events and native history lookups only. Free first-copy events remain physical workload even with zero paid copies.
  • Kubernetes audit policy and its selected log/index backend own the self-operated allocation, which is not a SQL service. The optional PostgreSQL history store prices CloudTrail’s own audit-family database; neither is the runtime adapter-state database.
  • CloudTrail is a free foundation in the default license profiles, so its Tensor9 fee is zero when entered; selection stays explicit. Target resources are cost of goods for installations that select it. Since the 2026-10-20 fold the history store runs inside sipsvr: adapter hosting is a share of sipsvr, with no separate worker or placement-controller allocation.
  • Source archive GiB-months, native event quantities, paid delivery-copy units, primary retained state and dependent archives are independent resource roles.
  • Retained data assumes steady average arrivals over a 730-hour month; event mix, burst concentration and retention policy require separate workload qualification.
  • The default includes one selected dependent archive copy. Disabling it does not establish a free all-inclusive installation; hosting and fees remain separately supplied or unknown.
  • Self-operated Kubernetes management-audit log/index allocation (Kubernetes, Apache-2.0): bounded CPU, RAM and retained physical disk, not a SQL service or adapter-state database. Audit policy, event payload and native-history scan work are explicit hypotheses; no cluster, log backend or query-capacity qualification is implied. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
  • Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
  • Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
  • Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
  • CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
  • No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
  • Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AWSCloudTrail offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSCloudTrail/current/us-east-1/index.json
  • AWS CloudTrail pricing: https://aws.amazon.com/cloudtrail/pricing/
  • AWS Price List API, AmazonS3 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonS3/current/us-east-1/index.json
  • Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
  • Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
  • Network pricing: https://cloud.google.com/vpc/network-pricing
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • Data-event collection, CloudTrail Insights, digest validation and custom SIEM queries.
  • Source archive PUT/retrieval charges, archive queries, network egress, archive encryption, source/target cluster workloads and cross-region aggregation.
  • Native feature fidelity and query behavior remain the directed profile’s separate qualifications; no recipe promotes a declared mapping to delivered support.
  • 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-335870c96376023a59ef2519b714864964e29890 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AWSCloudTrail offer, AWS CloudTrail pricing, AWS Price List API, AmazonS3 offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.
CloudTrail management audit records · Native event-history lookups
Feature: CloudTrail management audit records. Estimated monthly service charges by Native event-history lookups. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
CloudTrail management audit records · Native event-history lookups: monthly service charges by Native event-history lookups. Exact values are in the following table.CloudTrail management audit records · Native event-history lookups: monthly service charges by Native event-history lookups. 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 from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 lookups/s to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10 lookups/s. From 100 lookups/s the workload exceeds the planning range and the target is unpriced. Curve assumptions
  • Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • Declared native management-audit comparison: the estimate covers selected native log resources and dependent archives. It establishes no runtime adapter, compiled-deployment availability or full CloudTrail feature 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.
  • This recipe accepts management events and native history lookups only. Free first-copy events remain physical workload even with zero paid copies.
  • Kubernetes audit policy and its selected log/index backend own the self-operated allocation, which is not a SQL service. The optional PostgreSQL history store prices CloudTrail’s own audit-family database; neither is the runtime adapter-state database.
  • CloudTrail is a free foundation in the default license profiles, so its Tensor9 fee is zero when entered; selection stays explicit. Target resources are cost of goods for installations that select it. Since the 2026-10-20 fold the history store runs inside sipsvr: adapter hosting is a share of sipsvr, with no separate worker or placement-controller allocation.
  • Source archive GiB-months, native event quantities, paid delivery-copy units, primary retained state and dependent archives are independent resource roles.
  • Retained data assumes steady average arrivals over a 730-hour month; event mix, burst concentration and retention policy require separate workload qualification.
  • The default includes one selected dependent archive copy. Disabling it does not establish a free all-inclusive installation; hosting and fees remain separately supplied or unknown.
  • Self-operated Kubernetes management-audit log/index allocation (Kubernetes, Apache-2.0): bounded CPU, RAM and retained physical disk, not a SQL service or adapter-state database. Audit policy, event payload and native-history scan work are explicit hypotheses; no cluster, log backend or query-capacity qualification is implied. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
  • Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
  • Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
  • Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
  • CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
  • No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
  • Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
  • AWS Price List API, AWSCloudTrail offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSCloudTrail/current/us-east-1/index.json
  • AWS CloudTrail pricing: https://aws.amazon.com/cloudtrail/pricing/
  • AWS Price List API, AmazonS3 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonS3/current/us-east-1/index.json
  • Compute Engine general-purpose machine pricing: https://cloud.google.com/products/compute/pricing/general-purpose
  • Disk and image pricing: https://cloud.google.com/compute/disks-image-pricing
  • Network pricing: https://cloud.google.com/vpc/network-pricing
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • Data-event collection, CloudTrail Insights, digest validation and custom SIEM queries.
  • Source archive PUT/retrieval charges, archive queries, network egress, archive encryption, source/target cluster workloads and cross-region aggregation.
  • Native feature fidelity and query behavior remain the directed profile’s separate qualifications; no recipe promotes a declared mapping to delivered support.
  • 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-335870c96376023a59ef2519b714864964e29890 / 2026-10-22.planning.2. Curve: workload-2. Sources: AWS Price List API, AWSCloudTrail offer, AWS CloudTrail pricing, AWS Price List API, AmazonS3 offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing. CloudTrail management audit records → Kubernetes Audit Log: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD for this scenario. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Free allowances, committed discounts, credits, taxes and negotiated rates.
  • Commercial Tensor9 fees and operations labor unless entered separately.
  • Data-event collection, CloudTrail Insights, digest validation and custom SIEM queries.
  • Source archive PUT/retrieval charges, archive queries, network egress, archive encryption, source/target cluster workloads and cross-region aggregation.
  • Native feature fidelity and query behavior remain the directed profile’s separate qualifications; no recipe promotes a declared mapping to delivered support.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 1,000,000 operations.
  • Translated writes: 1,000,000 operations.
  • Translated resident physical data: 1.907 GiB-month.
  • Native provider operations: 0 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: 0 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0.9537 GiB-month.
  • Dependent object sink writes: 1,000 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.
  • Declared native management-audit comparison: the estimate covers selected native log resources and dependent archives. It establishes no runtime adapter, compiled-deployment availability or full CloudTrail feature 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.
  • This recipe accepts management events and native history lookups only. Free first-copy events remain physical workload even with zero paid copies.
  • Kubernetes audit policy and its selected log/index backend own the self-operated allocation, which is not a SQL service. The optional PostgreSQL history store prices CloudTrail’s own audit-family database; neither is the runtime adapter-state database.
  • CloudTrail is a free foundation in the default license profiles, so its Tensor9 fee is zero when entered; selection stays explicit. Target resources are cost of goods for installations that select it. Since the 2026-10-20 fold the history store runs inside sipsvr: adapter hosting is a share of sipsvr, with no separate worker or placement-controller allocation.
  • Source archive GiB-months, native event quantities, paid delivery-copy units, primary retained state and dependent archives are independent resource roles.
  • Retained data assumes steady average arrivals over a 730-hour month; event mix, burst concentration and retention policy require separate workload qualification.
  • The default includes one selected dependent archive copy. Disabling it does not establish a free all-inclusive installation; hosting and fees remain separately supplied or unknown.
  • Self-operated Kubernetes management-audit log/index allocation (Kubernetes, Apache-2.0): bounded CPU, RAM and retained physical disk, not a SQL service or adapter-state database. Audit policy, event payload and native-history scan work are explicit hypotheses; no cluster, log backend or query-capacity qualification is implied. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
  • Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
  • Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
  • Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
  • CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
  • No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
  • Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
  • Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
  • The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
  • Copies and allocation fractions change cost only; they do not increase modeled primary capacity.
List prices read: 2026-10-22. Model: plan-335870c96376023a59ef2519b714864964e29890 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AWSCloudTrail offer, AWS CloudTrail pricing, AWS Price List API, AmazonS3 offer, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

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