Jamf introduced a serverless pipeline that measures each engineer’s Amazon Bedrock token usage and automatically tightens IAM permissions when daily spend crosses predefined thresholds. This change gives platform teams a way to enforce cost caps in near‑real‑time without interrupting active sessions, which is directly relevant to anyone responsible for AI‑enabled workloads, cloud platforms, or security governance.
Why Token‑Based Cost Control Matters
Generative AI pricing is tied to token consumption rather than traditional compute units, so a single developer can generate a bill that dwarfs a team’s weekly spend. Without visibility, cost‑overrun risk is high and ROI calculations become opaque. Engineers, SREs, and security staff need a mechanism that surfaces per‑user spend early enough to act before the bill arrives.
Architecture Overview
The solution consists of three serverless components that work together:
- Measure: Bedrock logs every
bedrock:InvokeModelcall—including model ID, input and output token counts, and the caller’s IAM Identity Center identity—to an Amazon S3 bucket. - Decide and Notify: An Amazon Athena view named
bedrock_cost_todayreads the S3 logs in place and calculates per‑user daily spend by applying the published model rates. A Lambda function, triggered every 15 minutes by an EventBridge schedule, queries this view, checks an Amazon DynamoDB table for any exception limits, and compares spend against tiered thresholds (e.g., 80 % of the daily budget blocks Claude Opus, 100 % blocks Claude Sonnet, while Claude Haiku remains available). When a threshold is crossed, the function sends a one‑time Slack direct message to the affected engineer. - Enforce: The same Lambda creates a new version of the appropriate Customer Managed Policy (CMP) using
iam:CreatePolicyVersion. The updated policy denies access to the higher‑cost model for the specific user, taking effect within minutes and automatically resetting with the next daily cycle.
Key Implementation Pieces
- Use IAM Identity Center for single sign‑on so that Bedrock can attribute usage to individual identities.
- Configure Bedrock to write invocation logs to a dedicated S3 bucket; no additional data pipeline is required.
- Define the Athena view
bedrock_cost_todayto multiply token counts by model rates and aggregate by user. - Maintain two DynamoDB tables: one for exception overrides (time‑boxed higher limits) and one for tracking each user’s last notified threshold.
- Implement the Lambda handler with permissions to read Athena, query DynamoDB, send Slack messages, and manage CMP versions.
Operational and Security Implications
Because enforcement relies on IAM policy versions, the approach respects the existing AWS authorization model and does not require custom proxy services. However, frequent policy updates increase the number of policy versions; teams should monitor version limits and implement cleanup if needed. The S3 bucket storing Bedrock logs must be protected with appropriate bucket policies to prevent unauthorized read or tampering, as the logs are the source of truth for spend calculations. The Lambda’s ability to modify CMPs is a privileged action; restricting this capability to a dedicated service role limits blast‑radius in case of compromise. Exception handling via DynamoDB introduces a manual process that should be auditable and time‑boxed to avoid permanent cost bypasses.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting this pattern gives you real‑time visibility into token‑driven spend and an automated, policy‑based enforcement loop that integrates with existing IAM workflows. Evaluate the impact of policy version churn, secure the logging bucket, and establish clear exception governance. With those controls in place, you can provide engineers with flexible AI access while keeping budgets predictable and compliant.
