EKS + Bedrock on One Bill: How to Get Unified Cost Visibility for Kubernetes and AI Spend

Key points:

• No single tool gives true unified cost visibility across Amazon EKS and Amazon Bedrock today. The setup that works has two layers. An allocation layer (the AWS Cost and Usage Report (CUR 2.0) with split cost allocation data, read by Kubecost, OpenCost, Finout or nOps) is joined to a provisioning layer (Terraform or OpenTofu through Spacelift, env0, HCP Terraform or an internal developer platform) that stamps identical team, service and environment tags on every EKS workload and every Bedrock application inference profile.
• EKS and Bedrock break cost attribution in opposite directions. EKS collapses dozens of pods into a handful of shared EC2, EBS, NAT gateway and load balancer line items. Bedrock bills per input and output token with no native link to the service, environment or pull request that made the call.
• Two free AWS features close most of the gap, and most teams have not enabled them. Split cost allocation data adds per-pod CPU and memory cost rows to CUR. Application inference profiles attach your own cost allocation tags to Bedrock invocations. Both depend on tag keys you activate in the Billing console, and activation only covers usage going forward.
• FinOps tools report spend after it happens, and IaC platforms only estimate it before it happens. Plan-time estimators such as Infracost see nothing per-token, because token volume is a property of runtime traffic, not of a Terraform plan.
• Qovery sits in the provisioning and guardrails layer, not the reporting layer. It runs in your own cloud account, deploys to your existing EKS cluster, provisions AWS resources through Terraform and Helm, gives every environment a consistent identity, and auto-stops non-production so the spend never happens. Pair it with Kubecost, Finout or Cost Explorer for reporting.

A team ships a Bedrock-powered feature, runs a big customer demo, and the following week someone in finance forwards a four-figure Bedrock line with one question: which team did this? Nobody can answer, because no single tool gives unified Amazon EKS and Amazon Bedrock cost visibility today. The answer that works is two layers: an allocation layer joined on the AWS Cost and Usage Report (CUR 2.0), and a provisioning layer that enforces the same tags on every pod and every model invocation. I have watched teams try to buy their way out of this with one dashboard, and the dashboard always ends up showing the same untagged blob.

Why are EKS and Bedrock costs so hard to track together?

EKS and Bedrock fail cost attribution in opposite directions. EKS hides dozens of workloads behind a handful of shared infrastructure line items, while Bedrock bills per token with no built-in link to the team or service that made the call. The only thing that joins them is one tag taxonomy applied at provisioning time and surfaced through CUR 2.0.

The symptom always looks the same. The AI feature ships, the next AWS bill arrives as one combined number, and "what did that feature cost?" turns into a week of spreadsheet archaeology.

On the EKS side, every one of these is shared across namespaces by default:

• Control plane: $0.10 per cluster per hour on standard support, and $0.60 per cluster per hour once a Kubernetes version enters extended support (AWS EKS pricing).
• Compute: EC2 nodes, or Fargate billed on the vCPU and memory a pod uses. EKS Auto Mode adds a per-instance management fee on top of the EC2 price (AWS EKS pricing).
• EBS volumes attached to nodes and persistent volume claims.
• NAT gateway: $0.045 per hour plus $0.045 per GB processed in US East (AWS VPC pricing), and no namespace owns that traffic.
• Load balancers created by ingress controllers and Service objects.

One m6i.2xlarge line item cannot tell you which of the 40 pods scheduled on it belonged to the payments team. Without split cost allocation data or a Kubernetes-aware allocation tool, you are guessing.

Bedrock looks nothing like that. You pay for input and output tokens separately, per model: Claude Sonnet 4.5 lists at $3 per million input tokens and $15 per million output tokens on the global endpoint, and Amazon Nova Pro at $0.0008 per 1,000 input tokens and $0.0032 per 1,000 output tokens in US East (Amazon Bedrock pricing). On-demand, batch and provisioned throughput each price differently, and cross-Region inference can route your request to another Region inside a geography (Bedrock User Guide).

Bedrock spend is also demand-driven and spiky. A retry loop, an agent that re-prompts itself, or one demo week can multiply the bill within 48 hours while node cost stays flat.

This is not a niche complaint. Flexera's 2026 State of the Cloud Report found 85% of organizations name managing cloud spend as a top challenge, and estimated waste rose to 29% for the first time in five years (Flexera, 2026). In CNCF's FinOps for Kubernetes survey, 68% of respondents saw Kubernetes costs rise, and 68% either did not monitor Kubernetes spend at all (24%) or relied on monthly estimates (44%) (CNCF, 2021). And 98% of FinOps practitioners now manage AI spend, up from 31% in 2024 (FinOps Foundation, State of FinOps 2026).

The fix is a tag taxonomy enforced at provisioning time with CUR 2.0 as the join key, not a single dashboard that claims to do both.

What does AWS give you natively for unified EKS and Bedrock cost visibility?

AWS covers more of this than most teams use. Split cost allocation data puts pod-level EKS cost into CUR, application inference profiles let Bedrock invocations carry your own cost allocation tags, and CUR 2.0 plus AWS Cost Categories puts both on one shared dimension. None of it provisions anything, and none of it works until you activate the tag keys.

Split cost allocation data adds container-level rows to CUR for every Kubernetes pod, allocated from the amortized instance cost by the share of CPU and memory each pod consumes (AWS Billing User Guide). You opt in from Cost Management preferences in the management or standalone account, then choose whether allocation follows pod resource requests alone or the higher of requests and actual usage from Amazon Managed Service for Prometheus or CloudWatch Container Insights (AWS). Idle node capacity lands in a separate split_line_item_unused_cost column, and data can take up to 24 hours to appear.

The underrated part: split cost allocation data can import Kubernetes pod labels as user-defined cost allocation tags, up to 50 labels per pod (AWS). A team=payments pod label can become the same team dimension your Bedrock spend uses.

Application inference profiles are profiles you create to track cost and model usage. You tag the profile, pass its ARN as the modelId in InvokeModel or Converse, and every on-demand invocation through it carries those tags (Bedrock User Guide). AWS walked through the full pattern in November 2024 (AWS Machine Learning Blog).

Tag activation is the step people skip. AWS states that tags must be activated before they appear in billing reports, and it can take up to 24 hours for a key to show up for activation plus up to 24 more to activate (AWS Billing User Guide). Activation applies going forward. A management account can request a backfill of up to twelve months, but only for tags that were actually on the resource at the time (AWS).

AWS Cost Categories map costs onto your own business structure (AWS). Build a Product category whose rules match both the EKS team tag and the Bedrock profile team tag, and the two services finally share one dimension.

AWS Budgets and Cost Anomaly Detection can then watch that category. Cost Anomaly Detection monitors can be scoped to a service, linked account, cost allocation tag or cost category, and the service runs approximately three times a day (AWS). Point one at Bedrock specifically, because that is the side that spikes.

Native tooling stops there. It does not provision anything, it offers no self-service, CUR refreshes in hours rather than minutes, it has no cost per request or per customer, and tag quality is only as good as whoever wrote the Terraform. Still, enabling split cost allocation data and application inference profiles costs nothing and removes most of the guesswork before you buy any tool.

Which tools actually give unified cost visibility across EKS and Bedrock?

No vendor today does allocation, provisioning and per-token AI cost well in one product. Split the market into three buckets (cost allocation platforms, IaC orchestration platforms and internal developer platforms), then pick one allocation tool and one provisioning layer joined on a shared tag taxonomy.

Allocation and FinOps tools read the bill. Kubecost (now part of IBM through Apptio) reconciles in-cluster spend against your AWS bill through a CUR integration (IBM Kubecost docs). OpenCost, a CNCF incubating project since October 2024 (CNCF), reads CUR through Athena for its Cloud Costs feature (OpenCost docs). Finout combines CUR, Kubernetes and SaaS spend in its MegaBill with Virtual Tags (Finout docs). nOps focuses on commitment management and EKS cost reporting, and CAST AI automates EKS node provisioning, bin-packing and Spot usage rather than tracking Bedrock.

IaC orchestration platforms gate what gets created. Spacelift and env0 both run Infracost for plan-time cost estimation (Spacelift docs, env0 docs), while HCP Terraform ships its own built-in estimation for supported AWS, GCP and Azure resources (HashiCorp). Spacelift and env0 run Terraform or OpenTofu, HCP Terraform runs Terraform, and all three add policy as code and drift detection.

Internal developer platforms (Qovery, Humanitec, Backstage with plugins) apply guardrails and consistent labels at creation time, so cost control happens before next month's bill instead of in it.

The gap is the same everywhere. Infracost's supported AWS resource list contains no Bedrock resources (Infracost), and even usage-based resources such as Lambda need usage values you supply (Infracost). No IaC platform can estimate tokens, because traffic decides them.

In the table below, Partial means the tool sees Bedrock spend only because it ingests CUR, and only for invocations already tagged through an application inference profile.

If you can adopt only one thing this quarter, turn on the AWS native layer first, because it is free and every tool in the table reads from it. If you can buy one product, buy the allocation tool your team will actually open every week. An allocation tool plus a provisioning layer with enforced tagging beats any single product that claims unified EKS and AI cost visibility.

How do you design a tagging scheme that makes EKS and Bedrock show up on the same dashboard?

Use one shared tag taxonomy, applied at provisioning time, with the same four keys everywhere: team, service, environment and cost-center. Put them on EKS resources, on Kubernetes namespace and pod labels, and on Bedrock application inference profiles, then activate every key in the Billing console before you trust any dashboard. This is the core of reliable EKS cost allocation and Bedrock cost tracking.

Activate each key, then confirm it appears in the resource_tags map column of your CUR 2.0 export before building a single report on it (AWS Data Exports). Only activated tags show up there.

Enforce the keys where infrastructure gets created. The Terraform AWS provider's default_tags block applies tags to every resource the provider manages, with one exception that bites EKS teams: aws_autoscaling_group is excluded, so self-managed node groups need explicit tags (HashiCorp). Add an OPA or Sentinel gate in Spacelift, env0 or HCP Terraform, or let your internal developer platform enforce the labels.

provider "aws" {
  default_tags {
    tags = {
      environment   = "production"
      "cost-center" = "cc-1042"
    }
  }
}

resource "aws_bedrock_inference_profile" "support_assistant" {
  name = "support-assistant-prod"
  model_source {
    copy_from = "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0"
  }
  tags = {
    team    = "support"
    service = "support-assistant"
  }
}

Your application then calls Bedrock with the profile ARN as modelId, and the invocation inherits all four tags.

Inside a single profile you still cannot tell features apart, so add a runtime dimension. Log input and output token counts per feature, endpoint and customer in your own application, and divide the tagged Bedrock spend by those counts to get cost per request.

Mind the AWS limits: 50 user-created tags per resource, keys up to 128 characters, values up to 256, the aws: prefix reserved, and keys and values case sensitive (AWS Tagging Best Practices). Team and team are two different keys, which is enough to split one team's spend across two columns.

Tags applied by hand in the console drift within weeks, which is why the enforcement point must be the provisioning layer and not a quarterly cleanup ticket. And Bedrock calls made against the base model ID, outside any application inference profile, carry no tags at all, so no backfill can ever attribute them.

What should you do about EKS cost before you blame the AI feature?

Fix the unglamorous EKS waste in parallel with the Bedrock tagging work, because in most teams I talk to the node bill still dwarfs the token bill. Rank the levers in this order: auto-stop non-production first, right-size requests second, commitment coverage third, Bedrock model and prompt tuning fourth.

1. Auto-stop non-production. Dev, staging and preview environments that run nights and weekends burn money for nobody. Datadog found 83% of container costs were associated with idle resources (Datadog State of Cloud Costs 2024).
2. Right-size requests. Over 65% of Kubernetes workloads use less than half of their requested CPU and memory (Datadog Container Report), and CAST AI measured average CPU utilization at 8% and memory at 20% across clusters in 2025 (CAST AI, 2026). Requested versus used is the single number to watch in Kubecost or OpenCost.
3. Cover commitments. Savings Plans and Reserved Instances only help if they sit in the account that owns the workload, which is why it matters who holds the cloud account.
4. Tune the AI feature. Covered below, with its own levers.

Automated node optimization with Karpenter or CAST AI handles bin-packing well. It cannot decide that staging should be off at 8 PM, so you still need organizational defaults: auto-stop schedules and sane request sizes baked into every environment template.

On the Bedrock side the levers differ, in this order: pick the cheapest model that passes your evals, cap prompt and response length, then use prompt caching, which AWS says can cut costs by up to 90% and latency by up to 85% on supported models (AWS). Move anything that can wait to batch inference, priced 50% below on-demand for selected models (Amazon Bedrock pricing). Reach for provisioned throughput last.

This matters more every quarter. Menlo Ventures counted $37 billion of enterprise generative AI spend in 2025, 3.2x the year before (Menlo Ventures, 2025). Still, if you have not turned off non-production at night, no AI cost dashboard is going to save you money.

Where does Qovery fit between a FinOps dashboard and a Terraform orchestrator?

Qovery is the provisioning and guardrails layer that runs inside your own cloud account. It deploys to your existing EKS cluster, provisions AWS resources through Terraform and Helm, gives every application and environment a consistent identity you can map onto your cost allocation tags, and auto-stops non-production so the spend never happens. It is not a cost-allocation dashboard and does not report per-token Bedrock spend.

• Your account, your bill. Qovery deploys into your AWS account, so the bill, Savings Plans and negotiated discounts stay yours, CUR stays complete, and Finout, Kubecost, nOps or Cost Explorer keep working exactly as before.
• Your existing EKS cluster. Bring Your Own Kubernetes connects an existing EKS cluster through the Qovery Operator (Qovery docs). It is currently in preview on the Enterprise plan.
• Consistent identity by construction. Every application, environment and preview environment follows one predictable structure, which you map onto the team, service and environment keys from the previous section.
• Auto-stop as a platform rule. Deployment rules put auto-stop and auto-start schedules on environments, for example stopping dev and staging after 7 PM and restarting them at 8 AM (Qovery docs), with no cron job for someone to forget.
• Bedrock plumbing in the same workflow. The Terraform Native Service runs Terraform or OpenTofu inside Qovery (Qovery docs), so IAM roles, VPC endpoints and the aws_bedrock_inference_profile above ship next to the service that calls the model.
• Self-service with guardrails. Developers deploy to Kubernetes without a dedicated DevOps engineer, and per-environment RBAC keeps production access scoped as the team grows.

AWS is the worked example here because the question is EKS plus Bedrock. The same pattern runs on GCP, Azure, Scaleway or your own existing Kubernetes cluster.

Pair Qovery with Kubecost, OpenCost, Finout or Cost Explorer for reporting, because those tools do the allocation job better than any provisioning layer will.

What does a working EKS plus Bedrock cost setup look like end to end?

A working setup is a six-step reference stack. CUR 2.0 with split cost allocation data is the source of truth, one tag taxonomy is enforced in IaC, an allocation tool reports, budgets and anomaly detection watch the spiky Bedrock side, and one provisioning layer creates both the EKS workload and the Bedrock access path.

1. Enable split cost allocation data for EKS in Cost Management preferences and activate your four tag keys, including imported Kubernetes labels.
2. Create one Bedrock application inference profile per team or feature and tag it with the identical keys.
3. Enforce the tag set in Terraform or OpenTofu with default_tags plus a policy gate in Spacelift, env0, HCP Terraform or your internal developer platform.
4. Point Kubecost, OpenCost, Finout or nOps at your CUR 2.0 export so Kubernetes and Bedrock land in one view on the same dimension.
5. Set AWS Budgets and a Cost Anomaly Detection monitor on the Bedrock cost category, with a threshold low enough to catch a retry loop within a day.
6. Apply auto-stop and right-sizing defaults to every non-production environment so baseline EKS cost shrinks while you tune the AI feature.

Copyable checklist:

• Split cost allocation data enabled for EKS in CUR 2.0
• team, service, environment, cost-center activated as cost allocation tags
• Every Bedrock call goes through a tagged application inference profile
• default_tags and a policy gate block untagged resources
• One allocation tool reads CUR 2.0 for both services
• Bedrock budget and anomaly monitor live on the cost category
• Non-production auto-stops outside working hours

Set expectations: CUR data lands in hours, not minutes. Treat this as monthly attribution plus near-real-time anomaly alerting, not live cost telemetry.

How do I set this up from Claude Code or Cursor?

Install the Qovery Agent Skills once, and your coding agent can provision the environment, deploy to your existing EKS cluster and run cost-optimization checks from plain-language instructions. The Qovery MCP Server then operates what already exists, read-only by default until you explicitly enable write access.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scoped to the current project instead of your whole machine
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want the agent to act (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills that matter for this job are qovery-onboard, qovery-deploy, qovery-optimize for cost, qovery-terraform for provisioning the Bedrock-side AWS resources next to the app, and qovery-preview for ephemeral environments that stop on their own. Then ask in plain language, for example "deploy this service to my EKS cluster on AWS with Qovery and auto-stop the staging environment at night". See the AI agent quickstart and the Claude Code integration.