MLOps

AI Spend Quotas in Real Time: Jamf's IAM Pattern for Bedrock

Jamf caps AI spend quotas on Amazon Bedrock in real time using IAM, Athena and Lambda, with no proxy and no re-auth. The architecture, the real numbers.

AI Spend Quotas in Real Time: Jamf's IAM Pattern for Bedrock

AI Spend Quotas in Real Time: Jamf's IAM Pattern for Bedrock

AI spend quotas enforced in real time, not discovered in a monthly bill weeks after the fact — that's what Jamf, the Apple device management vendor, built after opening Amazon Bedrock to its engineering org. The company published the full technical write-up on September 1, 2026 on the AWS Machine Learning blog, and the interesting part isn't the idea, it's how little infrastructure it took to build.

The problem with invisible usage

Jamf's starting point will sound familiar to any platform team that has given developers broad Bedrock access: usage stays invisible until the bill arrives, which makes both cost control and proving return on investment hard. One engineer running hundreds of Claude Opus calls in a test loop never sees a counter, and the platform team only finds out the following month, buried in a consolidated AWS invoice.

The usual fix is binary. Either leave access open and hope, or route every AI call through a central internal proxy — which adds latency and a single point of failure on every request. A proxy also means someone now owns another piece of always-on infrastructure, with its own on-call rotation, right in the path of every production request. Jamf picked a third option: keep direct access to Bedrock, but drive the IAM permissions themselves off spend measured in near real time.

This isn't an isolated case. As platform teams roll LLM access out beyond data teams alone, the question stops being "how do we grant AI access" and becomes "how do we grant AI access without losing control of the least predictable line item in the cloud budget." AI spend quotas are becoming a FinOps pattern in their own right, and Jamf's is one of the more complete versions made public so far.

The architecture: IAM, Athena and Lambda instead of a proxy

The system runs entirely on managed AWS building blocks, with no intermediary service to operate. Bedrock already logs every invocation — model ID, input and output token counts, user identity — to Amazon S3. An Amazon Athena view, bedrock_cost_today, computes each user's daily spend by multiplying tokens consumed against the published per-token rate for each model.

Every 15 minutes, an AWS Lambda function triggered by Amazon EventBridge queries that view and cross-references it against an Amazon DynamoDB table tracking granted exceptions. For any user over threshold, the Lambda publishes a new version of their IAM Customer Managed Policy using iam:CreatePolicyVersion, with condition keys keyed on saml:sub — the SSO identity, wired in through AWS IAM Identity Center.

Why this beats an application-layer proxy

The key detail: IAM evaluates the updated policy on the user's very next Bedrock call, with no re-authentication required. There's no session to kill, no client-side token to revoke, no service to call on every request. The restriction lives in the cloud's native authorization layer, not in an application layer bolted on top of it.

A tiered AI spend ceiling, not a hard stop

Rather than a blanket cutoff the moment a budget is crossed, Jamf built a graceful degradation of what's available:

  • At 80% of the daily budget: Claude Opus gets denied, cheaper models stay available.
  • At 100% of the daily budget: Claude Sonnet gets denied too.
  • Always available, no matter what: Claude Haiku, so nobody is fully cut off from AI mid-day.

A developer with a legitimate one-off need past the ceiling isn't stuck: a Slack slash command, /bedrock-limit, lets an admin grant a time-boxed elevated limit, stored in DynamoDB with a TTL that cleans up the exception automatically once it expires.

The engineering detail that prevents silent drift

The Lambda never applies incremental changes. Every run, it recomputes the full list of restricted users from that day's cumulative spend, rather than adding or removing restrictions as it goes. That's a standard idempotence choice, but it matters enormously here: a poorly handled incremental approach would sooner or later leave someone wrongly restricted after a load spike, or forget to lift an expired restriction. The daily reset works the same way — the Athena view scopes spend to a rolling daily window anchored at midnight in a chosen reference time zone, and once that window rolls over, the next run's recomputed list naturally excludes users who dropped back under threshold.

One real constraint the team ran into: an IAM managed policy retains a maximum of five versions. The Lambda has to delete the oldest non-default version before it can create a new one — an API detail that's easy to discover by breaking things, harder to anticipate up front. It's a small reminder that even a "serverless, fully managed" design still has quotas of its own buried a few layers down, and a production-grade version of this pattern has to handle them explicitly rather than assume the API will always oblige.

What these AI spend quotas actually cost

The number that stands out in Jamf's write-up: AWS Lambda, DynamoDB and S3 together generate costs well under $10 a month, for hundreds of engineers. Restrictions take effect within minutes and revert automatically at the next daily reset, with no manual intervention.

The real payoff isn't only financial, it's organizational. According to Jamf, putting a hard per-user cap in place made leadership comfortable expanding access to Bedrock, not restricting it. That's the classic paradox of a well-designed control: an explicit, automated limit builds more confidence than an unenforced trust policy, and it unlocks adoption instead of throttling it.

One less glamorous point that says a lot about the real hidden costs of a FinOps architecture: Bedrock logs are stored as JSON in S3, which means every Athena query scans every byte regardless of which columns are selected — Athena has to deserialize each row before it can apply any filter. That works out to a full scan of roughly 11 GB on every run, even for queries filtering on just a few fields. At that size the scan cost is still trivial in absolute terms, but it scales with usage: an org running this at 10x Jamf's volume would want to revisit the log format long before the Lambda schedule or the DynamoDB design need a second look. The compute cost of the control isn't zero — it's just far lower than the cost of the overrun it prevents.

What this means for AI teams

This pattern flips an assumption a lot of platform teams carry around without questioning it: that controlling AI costs requires a central application proxy, with its own uptime to guarantee and its own latency added to every call on the critical path. Jamf shows that IAM — already in place for authentication — can carry the FinOps governance logic directly, without adding a network hop to the request path.

For a team operating AI agents in production, three lessons carry over directly:

  • Tiered degradation beats a hard cutoff. Automatically stepping down from a premium model to a cheaper one as the ceiling approaches keeps the service usable while still cutting the bill.
  • Idempotence protects against silent drift. Recomputing full state every cycle instead of accumulating deltas avoids the hardest class of bug in self-remediating systems: a phantom restriction that stays active for weeks after the underlying problem is gone.
  • Log format has a query cost, not just a storage cost. JSON is convenient to write but expensive to query at scale. For a pattern like this one, a columnar format (Parquet) or an intermediate aggregation step avoids paying for a full scan on every single run of the control.

The project's code is open-sourced by AWS, which makes it a concrete starting point rather than just a write-up to admire from a distance. For a team that doesn't have this kind of guardrail yet, it's also a solid basis for the conversation with security and finance: the pattern answers the two requirements that usually block extending AI access — per-user traceability, and a hard, automatic ceiling that doesn't need a manual negotiation every time someone goes over.

Key takeaways

  • Jamf built a per-user Bedrock spend cap driven entirely by IAM, Athena, Lambda, DynamoDB and EventBridge.
  • The control runs every 15 minutes and directly modifies IAM managed policies, with no re-authentication needed on the user side.
  • Tiered degradation: Claude Opus cut at 80% of budget, Claude Sonnet at 100%, Claude Haiku always available.
  • Running cost of the control itself: under $10/month for hundreds of engineers.
  • Organizational effect: the hard cap let the company expand AI access with confidence, not restrict it.
  • Real caveat: JSON logs in Athena force a full scan (~11 GB) on every run — a columnar format would cut that query cost.

Well-designed AI spend quotas don't slow down enterprise LLM adoption — they make it defensible in front of leadership, which is often the missing piece for going from pilot to production.

Industrialising AI agents? SeedVision offers 3-5 day AI audits and 15-30 day production rollouts. See the packages or book a 30-min call.

Cover photo: Photo by Alex Shuper on Unsplash.