AWS IAM - Tensor9

On this page

Coverage by target cloud
How the backends compare
- Max adaptation
- Infrastructure-only adaptation
On Google Cloud, Azure, OCI, and Private Kubernetes
- Via Cedar
On Google Cloud
- Via IAM
On Azure
- Via IAM
On OCI
- Via OCI IAM
Costs
Service level agreements
- IAM to Cedar
Debug this service

Coverage by target cloud

Target cloud	Available
Google Cloud	✓
Azure	✓
OCI	✓
Private Kubernetes	✓

How the backends compare

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

Max adaptation

Capability	IAM	Google Cloud, Azure, OCI, and Private Kubernetes · Cedar
Adaptation mechanism	AWS-managed IAM and STS	Max: IAM and STS requests
Access keys and secret keys	AWS account and IAM user credentials	Appliance-issued logical-account credentials
Policy language · authoring	IAM JSON	Supported IAM JSON translated to Cedar
Evaluation model · enforcement	Explicit deny overrides allow	Deny-wins in enforce mode
Policy consistency · freshness and revocation	AWS-managed propagation	Eventually consistent
Explicit deny wins	Yes - native	Yes - Cedar decision; enforce mode blocks
Condition keys	Yes	Partial - Time and selected DNS keys; separate trust conditions
Permissions boundaries	Yes	No - Not enforced by local Cedar
Resource-based policies	Yes	No - No general resource-policy evaluation in this IAM adapter
Cross-account role assumption	Yes	Partial - Configured local accounts and caller authorization
Organizations SCPs	Yes	No - Not enforced by this authorizer
Authorization diagnostics · denial investigation	CloudTrail and Access Analyzer	Denial and would-be-denial diagnostics
API coverage	full	high

Infrastructure-only adaptation

Capability	IAM	Google Cloud · IAM	Azure · IAM	OCI · OCI IAM
Adaptation mechanism	AWS-managed IAM and STS	Infrastructure only: native permission translation	Infrastructure only: native permission translation	Infrastructure only: native permission translation
API coverage	full	partial	partial	partial

On Google Cloud, Azure, OCI, and Private Kubernetes

Via Cedar

Operation	Area	Support	Depth	Notes
CreatePolicy / GetPolicy / ListPolicies / DeletePolicy	Customer-managed policies	Supported	Common	Uses the deployment’s customer-managed policy records; the runtime AWS-managed policy catalog is not supplied.
CreatePolicyVersion / GetPolicyVersion / ListPolicyVersions / SetDefaultPolicyVersion / DeletePolicyVersion	Customer-managed policies	Supported	Most usage	Maintains policy versions and the default version; up to five versions per policy.
TagPolicy / UntagPolicy / ListPolicyTags	Customer-managed policies	Supported	Most usage	-
PutRolePolicy / GetRolePolicy / ListRolePolicies / DeleteRolePolicy	Inline role policies	Supported	Common	Validates supported policy syntax; policy changes propagate eventually and may not affect authorization immediately after success.
AddRoleToInstanceProfile / RemoveRoleFromInstanceProfile	Instance profiles	Supported	Most usage	Maintains the association used by compute workloads to obtain role credentials.
CreateInstanceProfile / GetInstanceProfile / ListInstanceProfiles / ListInstanceProfilesForRole / DeleteInstanceProfile	Instance profiles	Supported	Most usage	-
TagInstanceProfile / UntagInstanceProfile / ListInstanceProfileTags	Instance profiles	Supported	Most usage	-
CreateOpenIDConnectProvider / GetOpenIDConnectProvider / ListOpenIDConnectProviders / DeleteOpenIDConnectProvider	OIDC providers	Supported	Common	Registers the providers used by web-identity federation.
TagOpenIDConnectProvider / UntagOpenIDConnectProvider / ListOpenIDConnectProviderTags	OIDC providers	Supported	Most usage	-
UpdateOpenIDConnectProviderThumbprint / AddClientIDToOpenIDConnectProvider / RemoveClientIDFromOpenIDConnectProvider	OIDC providers	Supported	Most usage	-
Access Analyzer / credential reports / Access Advisor	Out of scope	Out of scope	Full surface	These AWS IAM tools are not implemented by the adapter.
Permissions boundaries	Out of scope	Out of scope	Full surface	Role creation that attaches a boundary is rejected unless the operator acknowledges it explicitly. AWS IAM evaluates a boundary as an AND with the identity policy, and this models only the identity-policy layer, so honouring the attach silently would widen the role past what was asked for.
Users / groups / access-key administration / SAML federation	Out of scope	Out of scope	Full surface	These administration and federation operations are not served.
AttachRolePolicy / DetachRolePolicy / ListAttachedRolePolicies / ListEntitiesForPolicy	Policy attachments	Supported	Common	Attaches customer-managed policies to roles and returns their recorded relationships.
CreateRole / GetRole / ListRoles / DeleteRole	Roles	Supported	Common	Creates and reads role records; deletion invalidates sessions bound to that role incarnation.
TagRole / UntagRole / ListRoleTags	Roles	Supported	Most usage	Stores role tags; this does not enable general PrincipalTag policy conditions.
UpdateAssumeRolePolicy / UpdateRole / UpdateRoleDescription	Roles	Supported	Most usage	Updates role configuration. Trust is evaluated separately from Cedar identity-policy authorization.
AssumeRole	STS	Supported	Common	Checks role trust and issues expiring credentials. Role chaining, session policies, ExternalId and MFA inputs are unsupported.
AssumeRoleWithWebIdentity	STS	Supported	Common	Verifies the OIDC token and role trust before issuing a session. Issuer discovery and signing-key retrieval may need network access.
GetCallerIdentity	STS	Supported	Common	Returns account, ARN and user ID; an assumed-role session has an assumed-role ARN.
SimulateCustomPolicy	Simulation	Out of scope	Full surface	The IAM administration endpoint does not implement ad-hoc policy simulation.
SimulatePrincipalPolicy	Simulation	Partial	Most usage	Only the separate workload-identity endpoint supports simulation for its configured principal, with a supplied policy evaluator and concrete resources; not the IAM administration endpoint.

Max IAM and STS

Max adaptation serves AWS IAM and Security Token Service (STS) requests within each appliance. The adapter supports 50 IAM administration operations across roles, customer-managed policies, instance profiles and OIDC providers, plus GetCallerIdentity, AssumeRole and AssumeRoleWithWebIdentity. Your applications keep their AWS SDK and CLI calls for the supported operations. Each appliance has its own identities, policies and authorization state. Appliances do not share policies or distribute policy updates to one another. Policy updates reach only the relevant replicas within the same appliance; changing permissions in one appliance does not change permissions in another. Account IDs in adapted resource ARNs identify logical accounts within the appliance. These account records do not create cloud-provider accounts or billing relationships and do not provide AWS Organizations governance. The adapter handles IAM administration and STS credential exchanges, and translates supported IAM policies into rules for Cedar, an open-source policy engine. When another service adapter in the appliance receives a request, Cedar evaluates those rules to allow or deny it. Role trust is checked separately, when a session is created. Native permission translation is a different choice: it converts declared permissions into the target cloud’s own grants during provisioning, and does not handle AWS IAM administration calls at run time. This page is about the IAM in your application’s stack. The permissions your control plane needs inside a customer’s environment are a separate subject with its own model; see Permissions Model and Cross-Cloud IAM.

Three separate paths in one appliance: IAM edits are validated, recorded and applied; STS checks identity and role trust before issuing temporary credentials; and each supported service call is verified and authorized against the current policies.

IAM edits, STS trust checks and downstream authorization are separate steps.

Access keys and secret keys

Access keys and secret keys work on Google Cloud, Azure, OCI and Private Kubernetes. Use the appliance-issued pair supplied by your appliance administrator with your AWS SDK or CLI. Configure AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, the appliance endpoint and its signing region. Supported service requests use AWS Signature Version 4 (SigV4); the service adapter that receives each request verifies the signature and looks up the account the key belongs to. This long-term pair identifies a logical account root within the appliance, not an IAM user or a cloud-provider account. Keep the secret when it is issued; it is shown once. It is not valid at AWS endpoints or in another appliance. Native permission translation does not issue this runtime credential. A long-term pair has no session token. Temporary credentials from the supported STS operations identify a role session and also require AWS_SESSION_TOKEN; they expire. Credential use does not provide IAM user access-key administration: CreateAccessKey, ListAccessKeys, UpdateAccessKey and DeleteAccessKey are unsupported. The combined IAM and STS management endpoint is protected separately, as described below.

Authentication and management access

Temporary credentials identify a verified role session. The service adapter that receives a request verifies its signature, the session and the account before using that identity to authorize it. GetCallerIdentity returns the account, ARN and user ID; an assumed-role session has an assumed-role ARN, not simply its role’s IAM ARN. Protect the combined IAM and STS management endpoint with authenticated deployment access. Requests without issued session credentials use its configured bootstrap caller; this endpoint is not a general lookup of arbitrary AWS access keys. The separate public web-identity route accepts only AssumeRoleWithWebIdentity and verifies the token before issuing credentials. You configure authorization enforcement on the service adapters. In enforce mode, a denied decision stops the operation and returns the receiving service’s error. Report-only mode records would-be denials without blocking requests. Policy propagation does not turn report-only mode into enforcement.

Policy authoring and runtime changes

Keep authoring supported policies in IAM JSON. Declared stack policies and runtime IAM operations are separate ways to supply them. IAM reads return stored role, policy and relationship records, not documents reconstructed from compiled Cedar rules. Runtime policy edits are validated before acceptance. Accepted changes update the IAM records and then propagate to the policies used for authorization, so a change can be saved before a later request sees its effect. Creating a non-default managed-policy version does not change effective permissions. Making it the default changes the version used by attached roles. Inline policies and policy attachments also affect permissions. Role-trust changes instead govern future session creation; they are evaluated separately from Cedar identity policies. IAM Allow statements translate to Cedar permit rules and Deny statements to forbid rules. Supported actions, resource ARNs and conditions determine their scope. A policy with a restriction that Cedar authorization cannot express is rejected; the restriction is never silently dropped. Role trust is still evaluated separately, as an IAM policy.

Eventual consistency for policy changes

IAM policy changes are eventually consistent, as in AWS IAM. Policy consistency is not customer-configurable. Changes take time to reach reads and authorization checks, including updates made through another replica in the same appliance. A successful IAM response does not guarantee that subsequent reads or authorization checks already reflect the change. New grants may not be usable immediately, and revoked permissions may remain effective until the change propagates. With enforcement enabled, a request is blocked when the policies used for that check deny it; those policies can still be older than the latest accepted edit. Work already authorized can continue. Other appliances keep their own policies. An error or timeout after commit does not imply rollback. The change may have committed even though the caller did not receive success; do not treat a failed response as proof that the old permissions remain in effect.

Within one appliance, policy propagation may continue after a successful IAM response. Verify the dependent operation; one result does not prove every replica is up to date.

Success can precede propagation. A dependent-operation check is not a freshness guarantee for every replica.

Propagation and dependent workflows

Verify propagation before starting a workflow that depends on the change; a fixed sleep is not proof that propagation has completed. Check the relevant IAM state and the allowed or denied result needed by that workflow. One observed result does not prove that every replica is up to date or that the next request will observe the same policy state. Avoid putting IAM changes in a critical request path that assumes immediate visibility. There is no fixed propagation deadline. An unavailable replica or policy service can delay visibility or make requests fail. Eventual consistency does not guarantee offline availability, and there is no universal rule that permissions become denied after a fixed cache age. Test propagation, failure and recovery across the appliance’s replicas with the required enforcement settings.

Authorization decisions

Cedar evaluates the principal, action, resource and supported request context against the selected policies. Any matching forbid overrides a permit. With no matching permit, the decision is deny. Policy order does not change that decision. These rules describe supported identity-policy authorization. IAM management also has a privileged account-root path, and STS uses separate trust checks. They do not imply that every AWS policy layer or every receiving service is covered.

In enforce mode, a matching deny blocks the request; otherwise a matching allow permits it, and the default is deny.

Explicit deny overrides allow; without a matching allow, the decision is deny.

Supported conditions

Identity policies support aws:CurrentTime, aws:EpochTime, and three Route 53 change keys: route53:ChangeResourceRecordSetsNormalizedRecordNames, route53:ChangeResourceRecordSetsRecordTypes and route53:ChangeResourceRecordSetsActions. The DNS subset includes supported set, wildcard, negation and existence tests. Accepted operators depend on the key. aws:SourceIp, aws:PrincipalTag, aws:SecureTransport and MFA identity-policy keys are unsupported. A value being available in the deployment does not itself make its condition supported. Stored role tags do not imply general tag-based authorization. Role-trust conditions are separate. OIDC trust supports issuer-qualified audience and subject comparisons using StringEquals and StringLike. Pod Identity trust supports those operators on its six verified request-tag keys. Neither capability adds general identity-policy condition coverage.

Role trust and temporary credentials

AssumeRole evaluates role trust before creating an expiring session. Conditional cross-account assumption is supported between accounts in the same appliance when caller-side authorization and target-role trust both permit it. This does not provide cross-appliance trust or policy sharing. Account-root delegation and assumption into arbitrary real AWS accounts are outside this scope. AssumeRoleWithWebIdentity verifies the token signature, issuer, audience, subject and expiry against a registered OIDC provider and evaluates role trust. The dedicated Pod Identity exchange verifies the agent and pod token, selects the role from its association and issues a session with attested tags. These are real credential exchanges, not static credentials derived from a role name. Configured replicas within one appliance can share session verification. This does not make credentials valid in another appliance. Sessions expire and are tied to the role’s identity, so deleting and recreating a role with the same name does not revive its old sessions. Trust changes govern future assumptions; permission changes affect later authorization checks as they propagate. Neither effect is guaranteed to be visible immediately after a successful IAM response. Normal AssumeRole does not support role chaining, session policies, arbitrary session tags, ExternalId, MFA, SourceIdentity or ProvidedContexts. The trusted Pod Identity tag path is separate. Neither session issuance nor GetCallerIdentity calls AWS STS, but OIDC discovery and signing-key retrieval may require access to the configured issuer.

Administration and simulation scope

Administration includes role updates and tags; customer-managed policy creation, versions and tags; inline role policies and attachments; instance-profile lifecycle, membership and tags; and OIDC-provider lifecycle, audiences, thumbprints and tags. Policy versioning supports up to five versions per policy. AWS-managed policy documents are not supplied by the runtime catalog; use supported customer-managed policies. The IAM administration endpoint does not implement SimulatePrincipalPolicy or SimulateCustomPolicy. A separate workload-identity endpoint supports restricted principal simulation when configured with a policy evaluator. That simulation uses its configured workload and explicit actions and resource ARNs; it does not accept arbitrary principals or ad-hoc policy documents. A simulated deny may differ from the allowed response in report-only mode. User, group and access-key administration, SAML federation, service-linked roles, Access Analyzer, credential reports and Access Advisor are outside the implemented API scope.

Diagnostics and deployment

Authorization diagnostics record denials and would-be denials, including the principal, action, resource, result, enforcement mode and readiness. They do not record every successful permit or identify the matched policy statements. Policy validation and offline evaluation help test examples; they are not an Access Analyzer equivalent. The IAM and STS endpoints and Cedar evaluation run within each appliance. There is no shared policy distribution mechanism between appliances. Use the deployment configuration supported for that target environment; portable policy evaluation does not imply identical native identity provisioning on every cloud. AWS adapter permissions and the target cloud’s native grants remain separate. Tensor9 operates the adapter and policy propagation within each appliance. Diagnostic destinations and retention follow the appliance’s logging configuration. Before cutover, test administration, denied requests, credential renewal, permission-change propagation and outages across that appliance’s replicas. A healthy replica count does not prove that a particular policy change has reached every authorization check.

Limitations

Parts of the IAM policy language are not supported. In identity policies, NotAction, NotResource and NotPrincipal, policy variables, ? wildcards and unsupported principal forms are rejected. Action wildcards are limited to * or service:*; resource patterns accept broader * matching.
Some condition keys are not supported. aws:SourceIp, aws:PrincipalTag, aws:SecureTransport and MFA keys are rejected in identity policies. The supported keys are listed under Supported conditions.
Permissions boundaries are not enforced. Creating a role with a boundary is rejected unless you acknowledge it. Acknowledging keeps the attribute but does not enforce it, so the role can have broader permissions than the boundary allows.
Resource policies behave differently: each receiving service handles them. Translating an identity policy does not add resource-policy APIs or AWS’s rules for combining resource and identity policies.
Organizations SCPs are not enforced by this authorizer. Successful IAM administration or a token exchange adds no account or organization restrictions.
Several AssumeRole options are not supported. Role chaining, session policies, arbitrary session tags, ExternalId, MFA, SourceIdentity and ProvidedContexts are not available on normal AssumeRole.
User, group and access-key administration is not supported. CreateAccessKey, ListAccessKeys, UpdateAccessKey and DeleteAccessKey, SAML federation, service-linked roles, Access Analyzer, credential reports and Access Advisor are outside the supported API.
Policy simulation behaves differently. SimulatePrincipalPolicy and SimulateCustomPolicy are not available on the IAM endpoint; a separate workload-identity endpoint offers restricted simulation for its configured workload.
AWS-managed policies are not supplied. Their documents are not in the runtime catalog; write the permissions you need as customer-managed policies.
Permission changes behave differently: they propagate eventually. New permissions can take time to become usable, and revoked permissions can stay effective while the change propagates. Report-only mode does not block denied requests even after the updated policy is visible.
Sharing policies between appliances is not supported. Policies, policy updates and authorization state stay within one appliance. Credentials shared by its replicas work only in that appliance and grant no access at AWS.

Example monthly charges

AWS IAM and STS · Local authorization decisions

Feature: AWS IAM and STS. Estimated monthly service charges by Local authorization decisions. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more.

Local authorization decisions (operations/s)	Target scenario	Cedar	Difference
0	Cedar (one copy)	80.90	80.90
0	Cedar (two copies)	161.79	161.79
1	Cedar (one copy)	80.90	80.90
1	Cedar (two copies)	161.79	161.79
10	Cedar (one copy)	80.90	80.90
10	Cedar (two copies)	161.79	161.79
100	Cedar (one copy)	80.90	80.90
100	Cedar (two copies)	161.79	161.79
1,000	Cedar (one copy)	80.90	80.90
1,000	Cedar (two copies)	161.79	161.79
10,000	Cedar (one copy)	1,144.34	1,144.34
10,000	Cedar (two copies)	2,288.68	2,288.68

Estimated allocation, not benchmark calibrated: sized from 2 vCPU, 8 GiB memory and 100 GiB SSD at 0 operations/s to 32 vCPU, 128 GiB memory and 100 GiB SSD at 10,000 operations/s. Curve assumptions

Target scenario	Assumption	Value	Unit
Cedar (one copy)	Origin list price · IAM / STS management requests	0	USD/requests
Cedar (one copy)	Origin list price · In-process policy authorization decisions	0	USD/decisions
Cedar (one copy)	Principals and roles	1,000	principals
Cedar (one copy)	Policies per principal	2	policies/principal
Cedar (one copy)	Mean policy document size	4,096	bytes
Cedar (one copy)	Policy record expansion	1.5	multiplier
Cedar (one copy)	Management requests that mutate state	0.1	fraction
Cedar (one copy)	Target price guess · read	0	USD/read
Cedar (one copy)	Target price guess · write	0	USD/write
Cedar (one copy)	Target price guess · provider operation	0	USD/provider operation
Cedar (one copy)	Target list price · GiB-month	0.1	USD/GiB-month
Cedar (one copy)	Target price guess · published GiB	0	USD/published GiB
Cedar (one copy)	Target price guess · delivered GiB	0	USD/delivered GiB
Cedar (one copy)	Target list price · network GiB	0.12	USD/network GiB
Cedar (one copy)	Target price guess · replica GiB-month	0	USD/replica GiB-month
Cedar (one copy)	Target list price · vCPU-hour	0.031611	USD/vCPU-hour
Cedar (one copy)	Target list price · GiB-hour	0.004237	USD/GiB-hour
Cedar (one copy)	Target price guess · resource-hour	0	USD/resource-hour
Cedar (one copy)	Target price guess · resource-month	0	USD/resource-month
Cedar (one copy)	Target price guess · input token	0	USD/input token
Cedar (one copy)	Target price guess · output token	0	USD/output token
Cedar (one copy)	Target monthly base charge	0	USD/month
Cedar (one copy)	Approximate target service minimum	0	USD/month
Cedar (one copy)	Minimum primary CPU	2	vCPU
Cedar (one copy)	Minimum primary RAM	8	GiB
Cedar (one copy)	Minimum primary disk	100	GiB
Cedar (one copy)	Additional full-price standby copy	0	0 or 1
Cedar (one copy)	Allocated share of provisioned cost	1	fraction
Cedar (one copy)	Read/write work per vCPU-second	1,500	operations/vCPU-second
Cedar (one copy)	Planning peak / mean work	2	multiplier
Cedar (one copy)	Planning primary CPU utilization	0.7	fraction
Cedar (one copy)	Resident state reserved in RAM	0.1	fraction
Cedar (one copy)	Planning disk utilization	0.8	fraction
Cedar (one copy)	Maintenance and log disk reserve	20	GiB
Cedar (one copy)	Staging database CPU unit-price guess	0.0413	USD/vCPU-hour
Cedar (one copy)	Staging database RAM unit-price guess	0.007	USD/GiB-hour
Cedar (one copy)	Staging database disk unit-price guess	0.17	USD/GiB-month
Cedar (one copy)	Dependent object sink storage price guess	0.023	USD/GiB-month
Cedar (one copy)	Dependent object sink write price guess	0.000005	USD/write
Cedar (two copies)	Origin list price · IAM / STS management requests	0	USD/requests
Cedar (two copies)	Origin list price · In-process policy authorization decisions	0	USD/decisions
Cedar (two copies)	Principals and roles	1,000	principals
Cedar (two copies)	Policies per principal	2	policies/principal
Cedar (two copies)	Mean policy document size	4,096	bytes
Cedar (two copies)	Policy record expansion	1.5	multiplier
Cedar (two copies)	Management requests that mutate state	0.1	fraction
Cedar (two copies)	Target price guess · read	0	USD/read
Cedar (two copies)	Target price guess · write	0	USD/write
Cedar (two copies)	Target price guess · provider operation	0	USD/provider operation
Cedar (two copies)	Target list price · GiB-month	0.1	USD/GiB-month
Cedar (two copies)	Target price guess · published GiB	0	USD/published GiB
Cedar (two copies)	Target price guess · delivered GiB	0	USD/delivered GiB
Cedar (two copies)	Target list price · network GiB	0.12	USD/network GiB
Cedar (two copies)	Target price guess · replica GiB-month	0	USD/replica GiB-month
Cedar (two copies)	Target list price · vCPU-hour	0.031611	USD/vCPU-hour
Cedar (two copies)	Target list price · GiB-hour	0.004237	USD/GiB-hour
Cedar (two copies)	Target price guess · resource-hour	0	USD/resource-hour
Cedar (two copies)	Target price guess · resource-month	0	USD/resource-month
Cedar (two copies)	Target price guess · input token	0	USD/input token
Cedar (two copies)	Target price guess · output token	0	USD/output token
Cedar (two copies)	Target monthly base charge	0	USD/month
Cedar (two copies)	Approximate target service minimum	0	USD/month
Cedar (two copies)	Minimum primary CPU	2	vCPU
Cedar (two copies)	Minimum primary RAM	8	GiB
Cedar (two copies)	Minimum primary disk	100	GiB
Cedar (two copies)	Additional full-price standby copy	1	0 or 1
Cedar (two copies)	Allocated share of provisioned cost	1	fraction
Cedar (two copies)	Read/write work per vCPU-second	1,500	operations/vCPU-second
Cedar (two copies)	Planning peak / mean work	2	multiplier
Cedar (two copies)	Planning primary CPU utilization	0.7	fraction
Cedar (two copies)	Resident state reserved in RAM	0.1	fraction
Cedar (two copies)	Planning disk utilization	0.8	fraction
Cedar (two copies)	Maintenance and log disk reserve	20	GiB
Cedar (two copies)	Staging database CPU unit-price guess	0.0413	USD/vCPU-hour
Cedar (two copies)	Staging database RAM unit-price guess	0.007	USD/GiB-hour
Cedar (two copies)	Staging database disk unit-price guess	0.17	USD/GiB-month
Cedar (two copies)	Dependent object sink storage price guess	0.023	USD/GiB-month
Cedar (two copies)	Dependent object sink write price guess	0.000005	USD/write

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

AWS IAM and STS · IAM / STS management requests

Feature: AWS IAM and STS. Estimated monthly service charges by IAM / STS management requests. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.

IAM / STS management requests (operations/s)	Target scenario	Cedar	Difference
0	Cedar (one copy)	80.90	80.90
0	Cedar (two copies)	161.79	161.79
1	Cedar (one copy)	80.90	80.90
1	Cedar (two copies)	161.79	161.79
10	Cedar (one copy)	80.90	80.90
10	Cedar (two copies)	161.79	161.79
100	Cedar (one copy)	80.90	80.90
100	Cedar (two copies)	161.79	161.79
1,000	Cedar (one copy)	80.90	80.90
1,000	Cedar (two copies)	161.79	161.79
10,000	Cedar (one copy)	1,144.34	1,144.34
10,000	Cedar (two copies)	2,288.68	2,288.68

Target scenario	Assumption	Value	Unit
Cedar (one copy)	Origin list price · IAM / STS management requests	0	USD/requests
Cedar (one copy)	Origin list price · In-process policy authorization decisions	0	USD/decisions
Cedar (one copy)	Principals and roles	1,000	principals
Cedar (one copy)	Policies per principal	2	policies/principal
Cedar (one copy)	Mean policy document size	4,096	bytes
Cedar (one copy)	Policy record expansion	1.5	multiplier
Cedar (one copy)	Management requests that mutate state	0.1	fraction
Cedar (one copy)	Target price guess · read	0	USD/read
Cedar (one copy)	Target price guess · write	0	USD/write
Cedar (one copy)	Target price guess · provider operation	0	USD/provider operation
Cedar (one copy)	Target list price · GiB-month	0.1	USD/GiB-month
Cedar (one copy)	Target price guess · published GiB	0	USD/published GiB
Cedar (one copy)	Target price guess · delivered GiB	0	USD/delivered GiB
Cedar (one copy)	Target list price · network GiB	0.12	USD/network GiB
Cedar (one copy)	Target price guess · replica GiB-month	0	USD/replica GiB-month
Cedar (one copy)	Target list price · vCPU-hour	0.031611	USD/vCPU-hour
Cedar (one copy)	Target list price · GiB-hour	0.004237	USD/GiB-hour
Cedar (one copy)	Target price guess · resource-hour	0	USD/resource-hour
Cedar (one copy)	Target price guess · resource-month	0	USD/resource-month
Cedar (one copy)	Target price guess · input token	0	USD/input token
Cedar (one copy)	Target price guess · output token	0	USD/output token
Cedar (one copy)	Target monthly base charge	0	USD/month
Cedar (one copy)	Approximate target service minimum	0	USD/month
Cedar (one copy)	Minimum primary CPU	2	vCPU
Cedar (one copy)	Minimum primary RAM	8	GiB
Cedar (one copy)	Minimum primary disk	100	GiB
Cedar (one copy)	Additional full-price standby copy	0	0 or 1
Cedar (one copy)	Allocated share of provisioned cost	1	fraction
Cedar (one copy)	Read/write work per vCPU-second	1,500	operations/vCPU-second
Cedar (one copy)	Planning peak / mean work	2	multiplier
Cedar (one copy)	Planning primary CPU utilization	0.7	fraction
Cedar (one copy)	Resident state reserved in RAM	0.1	fraction
Cedar (one copy)	Planning disk utilization	0.8	fraction
Cedar (one copy)	Maintenance and log disk reserve	20	GiB
Cedar (one copy)	Staging database CPU unit-price guess	0.0413	USD/vCPU-hour
Cedar (one copy)	Staging database RAM unit-price guess	0.007	USD/GiB-hour
Cedar (one copy)	Staging database disk unit-price guess	0.17	USD/GiB-month
Cedar (one copy)	Dependent object sink storage price guess	0.023	USD/GiB-month
Cedar (one copy)	Dependent object sink write price guess	0.000005	USD/write
Cedar (two copies)	Origin list price · IAM / STS management requests	0	USD/requests
Cedar (two copies)	Origin list price · In-process policy authorization decisions	0	USD/decisions
Cedar (two copies)	Principals and roles	1,000	principals
Cedar (two copies)	Policies per principal	2	policies/principal
Cedar (two copies)	Mean policy document size	4,096	bytes
Cedar (two copies)	Policy record expansion	1.5	multiplier
Cedar (two copies)	Management requests that mutate state	0.1	fraction
Cedar (two copies)	Target price guess · read	0	USD/read
Cedar (two copies)	Target price guess · write	0	USD/write
Cedar (two copies)	Target price guess · provider operation	0	USD/provider operation
Cedar (two copies)	Target list price · GiB-month	0.1	USD/GiB-month
Cedar (two copies)	Target price guess · published GiB	0	USD/published GiB
Cedar (two copies)	Target price guess · delivered GiB	0	USD/delivered GiB
Cedar (two copies)	Target list price · network GiB	0.12	USD/network GiB
Cedar (two copies)	Target price guess · replica GiB-month	0	USD/replica GiB-month
Cedar (two copies)	Target list price · vCPU-hour	0.031611	USD/vCPU-hour
Cedar (two copies)	Target list price · GiB-hour	0.004237	USD/GiB-hour
Cedar (two copies)	Target price guess · resource-hour	0	USD/resource-hour
Cedar (two copies)	Target price guess · resource-month	0	USD/resource-month
Cedar (two copies)	Target price guess · input token	0	USD/input token
Cedar (two copies)	Target price guess · output token	0	USD/output token
Cedar (two copies)	Target monthly base charge	0	USD/month
Cedar (two copies)	Approximate target service minimum	0	USD/month
Cedar (two copies)	Minimum primary CPU	2	vCPU
Cedar (two copies)	Minimum primary RAM	8	GiB
Cedar (two copies)	Minimum primary disk	100	GiB
Cedar (two copies)	Additional full-price standby copy	1	0 or 1
Cedar (two copies)	Allocated share of provisioned cost	1	fraction
Cedar (two copies)	Read/write work per vCPU-second	1,500	operations/vCPU-second
Cedar (two copies)	Planning peak / mean work	2	multiplier
Cedar (two copies)	Planning primary CPU utilization	0.7	fraction
Cedar (two copies)	Resident state reserved in RAM	0.1	fraction
Cedar (two copies)	Planning disk utilization	0.8	fraction
Cedar (two copies)	Maintenance and log disk reserve	20	GiB
Cedar (two copies)	Staging database CPU unit-price guess	0.0413	USD/vCPU-hour
Cedar (two copies)	Staging database RAM unit-price guess	0.007	USD/GiB-hour
Cedar (two copies)	Staging database disk unit-price guess	0.17	USD/GiB-month
Cedar (two copies)	Dependent object sink storage price guess	0.023	USD/GiB-month
Cedar (two copies)	Dependent object sink write price guess	0.000005	USD/write

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

Monthly component	USD
Origin: IAM / STS management requests	0.00
Origin: In-process policy authorization decisions	0.00
Target: Provisioned primary CPU	46.15
Target: Provisioned primary RAM	24.74
Target: Provisioned primary disk	10.00
Target: Selected billable network	0.00
Target: Independent provisioned resources	0.00
Target: Independent managed resources	0.00
Origin service subtotal	0.00
Target service subtotal	80.90

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.
Premium identity licenses, external federation providers, directory synchronization and all protected resource-service 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

Input	Value	Unit
Origin list price · IAM / STS management requests	0	USD/requests
Origin list price · In-process policy authorization decisions	0	USD/decisions
Principals and roles	1,000	principals
Policies per principal	2	policies/principal
Mean policy document size	4,096	bytes
Policy record expansion	1.5	multiplier
Management requests that mutate state	0.1	fraction
Target price guess · read	0	USD/read
Target price guess · write	0	USD/write
Target price guess · provider operation	0	USD/provider operation
Target list price · GiB-month	0.1	USD/GiB-month
Target price guess · published GiB	0	USD/published GiB
Target price guess · delivered GiB	0	USD/delivered GiB
Target list price · network GiB	0.12	USD/network GiB
Target price guess · replica GiB-month	0	USD/replica GiB-month
Target list price · vCPU-hour	0.031611	USD/vCPU-hour
Target list price · GiB-hour	0.004237	USD/GiB-hour
Target price guess · resource-hour	0	USD/resource-hour
Target price guess · resource-month	0	USD/resource-month
Target price guess · input token	0	USD/input token
Target price guess · output token	0	USD/output token
Target monthly base charge	0	USD/month
Approximate target service minimum	0	USD/month
Minimum primary CPU	2	vCPU
Minimum primary RAM	8	GiB
Minimum primary disk	100	GiB
Additional full-price standby copy	0	0 or 1
Allocated share of provisioned cost	1	fraction
Read/write work per vCPU-second	1,500	operations/vCPU-second
Planning peak / mean work	2	multiplier
Planning primary CPU utilization	0.7	fraction
Resident state reserved in RAM	0.1	fraction
Planning disk utilization	0.8	fraction
Maintenance and log disk reserve	20	GiB
Staging database CPU unit-price guess	0.0413	USD/vCPU-hour
Staging database RAM unit-price guess	0.007	USD/GiB-hour
Staging database disk unit-price guess	0.17	USD/GiB-month
Dependent object sink storage price guess	0.023	USD/GiB-month
Dependent object sink write price guess	0.000005	USD/write
IAM / STS management requests	1,000,000	requests
In-process policy authorization decisions	10,000,000	decisions

Translated reads: 10,900,000 operations.
Translated writes: 100,000 operations.
Translated resident physical data: 0.0114 GiB-month.
Native provider operations: 1,000,000 operations.
Published payload: 0 GiB.
Delivered payload: 0 GiB.
Allocated execution CPU: 0 vCPU-hour.
Allocated execution RAM: 0 GiB-hour.
Independent resource allocation: 0 resource-hour.
Independent inventory: 0 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.
Free source IAM APIs do not imply zero adapted compute/state cost. In-process Cedar decisions are not separately billed cloud IAM decisions.
Native policy translation does not create paid Entra seats or premium identity licenses automatically. Those licensed users require explicit separate quantities.
Self-hosted target: Cedar (Apache-2.0, https://github.com/cedar-policy/cedar/blob/main/LICENSE). Selected CPU, RAM and physical disk allocation grow with workload; no per-operation price is assumed. No vendor charge: the target runs on the customer’s Kubernetes nodes, so CPU, RAM and disk bill at the Kubernetes node reference rates, Compute Engine N2 in us-central1 (USD 0.031611/vCPU-hour, 0.004237/GiB-hour) with pd-balanced disk (0.10/GiB-month) and Premium Tier egress. The cost-optimized E2 series lists 0.02181159/vCPU-hour and 0.00292353/GiB-hour; AWS m6i/r6i and Azure D2s v5/E2s v5 both decompose to 0.033/vCPU-hour and 0.00375/GiB-hour. Requested CPU and RAM are billed; node bin-packing waste, system reservations and the cluster control-plane fee are not.
Row-store throughput (capacityOpsPerVcpuSecond, default 1500) is measured-by-tensor9 as a lower bound: the DynamoDB adapter on Cloud SQL db-custom-2-7680 (2 vCPU, PostgreSQL 16, us-west1) served 2,974 ops/s of YCSB-A at 16 threads without recorded saturation (src/main/kotlin/t9/prime/equiv/generated/eval/CloudsqlPostgresqlYcsbAT16GoYcsbV1_0_0.kt). Published CPU-bound pgbench reaches 3,101 read-write transactions and 20,289 point reads per vCPU-second (AWS z1d.2xlarge, PostgreSQL 14.5), so actual capacity is likely higher. Reads and writes share one coefficient: at the same adapter version, read-only YCSB-C was not faster than 50%-update YCSB-A.
Log-broker throughput (capacityStreamMiBPerVcpuSecond 20 at 0.5 utilization, 4 GiB RAM per vCPU) is provider-documented by Google Managed Service for Apache Kafka sizing (https://docs.cloud.google.com/managed-service-for-apache-kafka/docs/plan-cluster-size): write-equivalent bytes are replicated writes plus a quarter of reads. Producer batches below 10 KB lower per-CPU throughput; that penalty is not modeled.
Disk utilization 0.8 is provider-documented headroom below Cloud SQL automatic storage increase, which triggers near 91-95% full (https://docs.cloud.google.com/sql/docs/postgres/instance-settings). The 20 GiB reserve exceeds PostgreSQL’s 1 GB default max_wal_size; the remainder of that reserve is unmeasured.
CPU tiers double from 2 vCPUs to the target’s largest node at 4 GiB per vCPU; each target’s documented largest node bounds CPU, RAM, RAM per vCPU and disk, and the durable staging database uses Cloud SQL Enterprise (96 vCPU, 6.5 GiB per vCPU, 624 GiB, 64 TiB). Targets billed per capacity unit or throughput unit are sized by their backend instead.
No public evidence: peak/mean work (2) and the RAM working-set fraction (0.1). Proposed measurements: the p99 one-minute rate over the monthly mean from customer CloudWatch metrics; the buffer hit ratio while stepping RAM under a fixed YCSB-B load.
Node bounds: Cloud SQL Enterprise allows 1-96 vCPUs at 0.9-6.5 GB per vCPU and up to 64 TB with a dedicated vCPU (https://docs.cloud.google.com/sql/docs/postgres/instance-settings).
Stored GiB already includes the origin family’s physical footprint assumptions; no second storage amplification is applied.
The operations/vCPU coefficient supplies the compute requirement alongside explicit resource-hour minima.
Copies and allocation fractions change cost only; they do not increase modeled primary capacity.

List prices read: 2026-10-22. Model: plan-2337a2bb066032b30f6de3e2e31d3c204810929d / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS IAM User Guide: What is IAM, Compute Engine general-purpose machine pricing, Disk and image pricing, Network pricing.

On Google Cloud

Via IAM

Infrastructure only: native permissions

Tensor9 translates the roles, policies, and attachments declared by your stack into Google Cloud IAM grants during provisioning. Google Cloud IAM binds predefined or custom roles to principals. Tensor9 maps supported AWS actions to permissions; the generated scope and supported condition mapping can differ. The resulting grants use predefined or custom role permissions and resource scopes.

Permission differences

AWS policies can restrict individual resources and request conditions. This mapping does not preserve every restriction. Mappings that broaden access require explicit acceptance; incompatible restrictions stop translation. Some mappings grant fewer permissions. Review generated actions and scopes before deployment. The Cedar-based adapter separately serves supported AWS IAM calls and evaluates supported AWS identity policies.

Application and identity changes

This mapping provisions grants; it does not serve runtime AWS IAM calls such as iam:CreateRole or iam:AttachRolePolicy. Replace references to AWS role ARNs in trust policies, assume-role calls, and resource policies with the appropriate Google identity. New backend grants are created during deployment; AWS policy objects are not copied.