- Coverage by target cloud
- How the backends compare
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Azure
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of EKS Pod Identity with its adaptation on each backend. A dash means this row is not stated for that backend.Max adaptation
Infrastructure-only adaptation
On Google Cloud, Azure, OCI, and Private Kubernetes
Via Cedar
AWS credential exchange
An EKS Pod Identity association records which role belongs to a cluster, namespace and service account. The EKS Auth broker (the Tensor9 adapter that answers EKS Auth requests) verifies the relaying agent and the pod’s service account token, looks up that association and checks the role trust before it issues a temporary AWS session. The caller cannot choose an arbitrary role in the credential request.Permissions and native resource access
The AssumeRoleForPodIdentity response supplies a temporary AWS role session. With enforcement enabled, the adapters that receive AWS API requests check them against the role’s supported IAM permissions using Cedar, the policy engine underpinning the adapter’s authorization decisions. The adapter handles the AWS credential exchange; Cedar evaluates the supported permissions. Native cloud APIs use separate provider credentials and grants, and Kubernetes RBAC governs access to the cluster API. Each appliance has its own identities and policies. Appliances do not share policies or distribute policy updates to one another. Policy changes are eventually consistent within that appliance. New grants may not be usable immediately, and revoked permissions may remain effective until the change propagates. Verify the dependent operation before relying on a policy change; a successful update alone does not show that it has taken effect.Deployment and renewal
Deploy association management, the EKS Auth broker and the cluster’s credential agent together. Register the broker’s backend role, authorize the agent to request credentials for the cluster, and configure an HTTPS broker address the agent can resolve and reach. The broker must be able to verify the cluster’s token issuer and signing keys. Configure the cluster’s admission webhook to mount a pod-bound token for audiencepods.eks.amazonaws.com and to select the AWS container credential provider. Check for other credentials that would take precedence. Then verify three things in a newly admitted pod: it gets the intended role, a denied exchange fails, and a denied resource action fails. Long-running pods must renew credentials. After an association or policy change, existing sessions and later exchanges can have different outcomes.
Association and trust limits
Associations use one role in the cluster’s appliance account. Role chaining, inline session policies and disabling session tags are unsupported. OmittargetRoleArn, policy and disableSessionTags from create and update requests, including an explicit false for disableSessionTags.
The role must trust pods.eks.amazonaws.com for both sts:AssumeRole and sts:TagSession. The broker sets the Kubernetes session tags from the verified pod. Trust conditions may use StringEquals or StringLike on the six aws:RequestTag keys it sets; other trust conditions are rejected.
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.Kubernetes workload identity exchange · Identity exchanges per second
Feature: Kubernetes workload identity exchange. Estimated monthly service charges by Identity exchanges per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Estimated allocation, not benchmark calibrated: sized at 2 vCPU, 8 GiB memory and 100 GiB SSD at every sample.
Curve assumptions
- Only this native meter varies; all other source usage and translation assumptions retain the displayed 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; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
- IRSA exchanges are served through STS; Pod Identity spans EKS association and EKS Auth exchange surfaces. This model does not invent a standalone IRSA endpoint.
- Identity exchanges do not imply additional application replicas, cluster nodes or database capacity.
- 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
- Shared cluster, application workloads, node-local agents, audit storage, network and separately allocated adapter hosting.
- 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.
plan-ae74feefce2da4401666ebf61d8e0b903c51976b / 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.
Kubernetes workload identity exchange → 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.
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:
- Shared cluster, application workloads, node-local agents, audit storage, network and separately allocated adapter hosting.
- 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.
- Translated reads: 0 operations.
- Translated writes: 0 operations.
- Translated resident physical data: 0 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; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
- IRSA exchanges are served through STS; Pod Identity spans EKS association and EKS Auth exchange surfaces. This model does not invent a standalone IRSA endpoint.
- Identity exchanges do not imply additional application replicas, cluster nodes or database capacity.
- 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.
plan-ae74feefce2da4401666ebf61d8e0b903c51976b / 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 Azure
Via IAM
Association management and AWS credential exchange
Maximum adaptation keeps the EKS association API and the EKS Auth credential exchange as separate services. The association records which role belongs to a cluster, namespace and service account. For AssumeRoleForPodIdentity, the broker verifies the relaying agent and the pod’s service account token, looks up the stored association and checks the role’s current trust policy. The caller does not choose an arbitrary role in the exchange request. For an unchanged AWS SDK the result is an AWS role session. Azure workload identity federation is a separate way to reach Azure resources and produces Azure tokens; it does not replace the AWS session format. Check the pod token’s issuer and audience, the association and role trust, and any Azure identity needed for target resources. Changing an association affects later exchanges; sessions already issued keep their own expiry. Associations use one role in the cluster’s appliance account. Role chaining, inline session policies and disabling session tags are unsupported. OmittargetRoleArn, policy and disableSessionTags from create and update requests, including an explicit false for disableSessionTags.
The role must trust pods.eks.amazonaws.com for both sts:AssumeRole and sts:TagSession. The broker sets the Kubernetes session tags from the verified pod. Trust conditions may use StringEquals or StringLike on the six aws:RequestTag keys it sets; other trust conditions are rejected.
Deploy association management, the EKS Auth broker and the cluster’s credential agent together. Register the broker’s backend role, authorize the agent to request credentials for the cluster, and configure an HTTPS broker address the agent can resolve and reach. The broker must be able to verify the cluster’s token issuer and signing keys.
Configure the cluster’s admission webhook to mount a pod-bound token for audience pods.eks.amazonaws.com and to select the AWS container credential provider. Check for other credentials that would take precedence. Then verify three things in a newly admitted pod: it gets the intended role, a denied exchange fails, and a denied resource action fails. Long-running pods must renew credentials. After an association or policy change, existing sessions and later exchanges can have different outcomes.
Native Azure identity
EKS Pod Identity associates a Kubernetes service account with an IAM role. An agent in the cluster gives the pod temporary credentials, without an OpenID Connect (OIDC) provider. Azure uses OIDC federation. The pod authenticates with its service-account token as a user-assigned managed identity. A federated identity credential records the AKS cluster’s issuer and the service account that may use that identity. The diagram shows native Azure access. For AWS SDK calls, Tensor9 separately keeps EKS association management and the EKS Auth credential exchange, described in “Association management and AWS credential exchange”. The pod still gets permissions without a stored client secret, but the AKS cluster must have its OIDC issuer enabled. Teams that moved to Pod Identity to stop running an OIDC provider take that dependency back on.
What the association becomes
One Pod Identity association becomes a user-assigned managed identity, a role (a built-in Azure role when one matches the policy statement exactly, a custom role otherwise), a role assignment scoped to the resource group, and a federated identity credential naming the cluster’s issuer and your service account. For native Azure access, the federated credential takes the association’s place. Its issuer, subject and audience say which service account in which namespace may sign in as the managed identity. Tensor9 creates all federated credentials for one identity together and checks Azure’s limit of 20 per identity when it builds the deployment; going over stops the build. If many service accounts share an identity, split them across more identities.Limitations
Where Azure workload identity and Pod Identity differ- You must enable the AKS cluster’s OIDC issuer. Azure workload identity needs it. EKS Pod Identity needs no OIDC provider, so this is a new deployment requirement.
- Associations and Azure federation behave differently: they are separate. EKS tooling uses the association API; native Azure access uses federated credentials on managed identities. Review both. An Azure credential alone does not create an EKS association or issue an AWS role session.
- You must keep each identity to 20 federated credentials. Azure allows 20 federated credentials per managed identity, and the build stops if an identity needs more. Split service accounts across more identities.
- IAM Users and Groups are not supported. This mapping creates workload identities, not directory objects for people or groups. Set up native Azure grants for people in Azure’s directory. Tensor9’s AWS IAM adapter handles IAM objects separately.
- Some permission conditions are not supported. AWS IAM statements become Azure RBAC roles over a scope hierarchy with fewer conditions. Review effective access where an IAM condition has no Azure equivalent.
Other considerations
- Enable the OIDC issuer before deployment. Without it, federated credentials are created but the first token exchange fails. The appliance template checks that the issuer is enabled when the stack is applied.
- Check both credential paths. Pods keep their service accounts. Native Azure access needs the Azure workload-identity labels; unchanged AWS SDK calls need the agent, association and EKS Auth route. The two paths produce different credentials, so test each.
- Read the generated roles before moving. The plan contains built-in role names or custom definitions with explicit actions. Compare them with the original IAM policy, especially where a broader Azure scope could grant more access.
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. Native or deployment mapping. This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels. Cost estimates describe the selected service resources; operation coverage remains separate.Kubernetes workload identity exchange · Identity exchanges per second
Feature: Kubernetes workload identity exchange. Estimated monthly service charges by Identity exchanges per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: global; currency: USD.
Curve assumptions
- Only this native meter varies; all other source usage and translation assumptions retain the displayed 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 → global, USD/month.
- Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
- Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
- Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
- Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
- Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
- Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
- Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
- A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
- This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
- Native/deployment comparison scope: This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels.
- Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
- IRSA exchanges are served through STS; Pod Identity spans EKS association and EKS Auth exchange surfaces. This model does not invent a standalone IRSA endpoint.
- Identity exchanges do not imply additional application replicas, cluster nodes or database capacity.
- Identity and access management APIs are free. Durable adapter state and hosting remain independent costs.
- AWS IAM User Guide: What is IAM: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
- What is Azure role-based access control (Azure RBAC)?: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
- Shared cluster, application workloads, node-local agents, audit storage, network and separately allocated adapter hosting.
- 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.
plan-5e3af5a69137df3d6a0f8e71fa0dd13f449fcdde / 2026-10-22.planning.2. Curve: workload-1.
Sources: AWS IAM User Guide: What is IAM, What is Azure role-based access control (Azure RBAC)?.
Kubernetes workload identity exchange → IAM: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.
Scenario source region: us-east-1. Scenario target region: global. Currency: USD.
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:
- Shared cluster, application workloads, node-local agents, audit storage, network and separately allocated adapter hosting.
- 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.
- Translated reads: 0 operations.
- Translated writes: 0 operations.
- Translated resident physical data: 0 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.
- Native/deployment comparison scope: This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels.
- Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
- IRSA exchanges are served through STS; Pod Identity spans EKS association and EKS Auth exchange surfaces. This model does not invent a standalone IRSA endpoint.
- Identity exchanges do not imply additional application replicas, cluster nodes or database capacity.
- Identity and access management APIs are free. Durable adapter state and hosting remain independent costs.
plan-5e3af5a69137df3d6a0f8e71fa0dd13f449fcdde / 2026-10-22.planning.2. Scenario: planning-example.
Sources: AWS IAM User Guide: What is IAM, What is Azure role-based access control (Azure RBAC)?.