Cost Control and Security for AI Workloads on AWS, Budgets and IAM Guardrails

AWS shows you AI spend beautifully and stops almost none of it. Here is the layered guardrail that does the stopping.

There is a sentence in the AWS documentation that surprises people the first time they read it carefully. AWS Budgets do not stop spending, they send notifications, which means a budget is a smoke alarm rather than a sprinkler. For traditional infrastructure that distinction rarely bites, because an oversized instance costs a predictable amount per hour and someone notices by morning. An agent stuck in a retry loop against a frontier model is a different shape of problem, because it can spend more in an afternoon than your EC2 fleet does in a week, and nothing in the default configuration will interrupt it.

The good news is that AWS shipped real improvements here recently. Bedrock now attributes inference cost to the IAM principal that made each call, surfacing it in both Cost Explorer and Cost and Usage Report 2.0, and application inference profiles let you tag spend by team. The catch is timing: that data appears 24 to 48 hours after the fact, so it answers who spent what and never stops the spending. This tutorial builds the layered stack that does, combining visibility for chargeback with quotas for rate ceilings and IAM for the only control that genuinely blocks.

What cost control for AI workloads on AWS means

Cost control for AI workloads on AWS is the practice of layering four separate mechanisms so that inference spend is attributable, bounded, and interruptible: cost allocation for visibility, service quotas for rate ceilings, IAM policies and service control policies for hard access boundaries, and an automated circuit breaker that reacts to a threshold breach faster than a billing cycle.

Each layer does something the others cannot, which is why picking one is a common and expensive mistake. Visibility without enforcement tells you about the incident afterwards, and enforcement without visibility means you cannot tell a runaway agent from a successful product launch.

Know what each control can actually do

Read this table before designing anything, because most failed cost governance projects mistake a notification for a limit.

The last row is the circuit breaker, and it exists precisely because rows one through three cannot stop anything and rows four through six cannot count dollars.

Layer 1: Make spend attributable

You cannot govern what you cannot attribute, so start here even though it enforces nothing.

Two mechanisms combine well. IAM principal based cost allocation, which Bedrock gained in April 2026, attributes each inference cost to the calling identity automatically, whether that is a user, an assumed role, or a federated identity. Application inference profiles give you a taggable wrapper around a model, so you can attribute spend to a team or project regardless of which identity called it.

# 1. Tag the roles your workloads assume. These become cost dimensions.
aws iam tag-role --role-name agent-runtime-payments \
  --tags Key=team,Value=payments Key=cost-center,Value=CC-4417 \
         Key=environment,Value=production

# 2. Create an application inference profile so spend can be tagged per team
aws bedrock create-inference-profile \
  --inference-profile-name payments-claude-sonnet \
  --model-source '{"copyFrom":"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"}' \
  --tags '[{"key":"team","value":"payments"},{"key":"cost-center","value":"CC-4417"}]'

# 3. Activate the tags for billing. Nothing appears in reports until you do.
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
    TagKey=team,Status=Active TagKey=cost-center,Status=Active

Step three is the one people forget, and its absence produces a confusing failure where tags exist on resources but never appear in Cost Explorer. Activation happens in Billing and Cost Management, and the tags take up to 24 hours to show up after that.

Once activated, you can query attribution directly. In CUR 2.0 the line_item_iam_principal column carries the full ARN of the caller, and IAM principal tags appear with an iamPrincipal/ prefix.

-- Athena over CUR 2.0: which identities spent the most on inference last month
SELECT
  line_item_iam_principal              AS principal,
  resource_tags['iamPrincipal/team']   AS team,
  line_item_usage_type                 AS usage_type,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM cur2.bedrock_export
WHERE line_item_product_code = 'AmazonBedrock'
  AND billing_period = '2026-06'
GROUP BY 1, 2, 3
ORDER BY cost_usd DESC
LIMIT 25;

Treat this as your chargeback and forecasting tool, never as a control. The delay is inherent, so build the enforcement layers below rather than hoping this arrives faster.

Build the Bedrock foundation this assumes

Governing Bedrock properly is much easier when you know what it actually does, which models it fronts, and how inference profiles and guardrails fit together. The Introduction to Amazon Bedrock course on KodeKloud covers the service end to end in about five hours, which is the context every policy in this tutorial assumes.

Layer 2: Set the rate ceiling with service quotas

Service quotas are the most underrated control on this list, because they are always on, immediate, and free. A quota converts an infinite loop into a stream of throttling errors, which is an incident rather than an invoice.

# See your current on demand quotas for Bedrock in this region
aws service-quotas list-service-quotas --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

# Request a DECREASE for a workload that should never need burst capacity.
# Applied quotas can be set below the default, which is the useful direction here.
aws service-quotas request-service-quota-increase \
  --service-code bedrock \
  --quota-code L-EXAMPLE1 \
  --desired-value 20000

Two habits make quotas genuinely protective rather than incidental. Resist requesting quota increases reflexively when you hit a limit, because the limit is sometimes correctly telling you the workload is misbehaving rather than growing. And separate accounts by risk so quotas can differ, since an experimentation account with a low ceiling and a production account with a high one is a simpler and stronger design than one account trying to serve both.

Layer 3: IAM is the only thing that truly blocks

Now the layer with real teeth. Every other control notifies, throttles, or reports, while IAM refuses.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApprovedModelsOnly",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-*",
        "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/payments-*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    },
    {
      "Sid": "RequireGuardrailOnEveryInvocation",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/prod-guardrail"
        }
      }
    },
    {
      "Sid": "DenyExpensiveModelsOutrightForThisRole",
      "Effect": "Deny",
      "Action": "bedrock:InvokeModel*",
      "Resource": "arn:aws:bedrock:*::foundation-model/*opus*"
    }
  ]
}

Three things in that policy are worth copying deliberately.

Scoping Resource to specific model ARNs rather than * is the single highest value change most teams can make, because bedrock:InvokeModel on * means any identity holding it can reach your most expensive model, and that is exactly what an attacker with stolen credentials does. The industry has a name for that pattern now, LLMjacking, where compromised keys are used to run inference on somebody else's account and resold.

The bedrock:GuardrailIdentifier condition closes a real gap. Bedrock Guardrails are passed as a parameter on the invocation, which means a developer can simply not pass one, and no amount of documentation reliably prevents that. A deny statement conditioned on the guardrail identifier makes the guardrail mandatory at the API boundary rather than optional in application code.

Region conditions matter more for AI than for most services. Model availability differs by region, prices differ by region, and data residency commitments live there, so pinning aws:RequestedRegion prevents a well meaning developer from quietly moving inference somewhere your compliance answer does not cover.

For organization wide boundaries, push the same logic up into a service control policy so no account can opt out.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyModelAccessOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel*", "bedrock:CreateModelCustomizationJob"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "eu-central-1"]
        }
      }
    },
    {
      "Sid": "ProtectTheCircuitBreaker",
      "Effect": "Deny",
      "Action": ["iam:DeleteRolePolicy", "iam:PutRolePolicy"],
      "Resource": "arn:aws:iam::*:role/agent-runtime-*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/cost-guardrail-lambda"
        }
      }
    }
  ]
}

The second statement is the one people miss. If your circuit breaker works by attaching a deny policy, then anyone who can detach that policy can disable your only real enforcement, so restrict who may modify those roles to the automation itself.

Layer 4: Build the circuit breaker

Here is the part that closes the gap between an alert and an actual stop. Model invocation logging feeds CloudWatch, a metric filter counts tokens, an alarm fires, and a Lambda attaches a deny policy to the offending role.

# Turn on model invocation logging first. Everything downstream depends on it.
aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/aws/bedrock/invocations",
      "roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole"
    },
    "textDataDeliveryEnabled": false,
    "embeddingDataDeliveryEnabled": false
  }'

# Count output tokens per team from the log stream
aws logs put-metric-filter \
  --log-group-name /aws/bedrock/invocations \
  --filter-name payments-output-tokens \
  --filter-pattern '{ $.identity.arn = "*agent-runtime-payments*" }' \
  --metric-transformations \
    metricName=PaymentsOutputTokens,metricNamespace=BedrockGovernance,\
metricValue='$.output.outputTokenCount',defaultValue=0

Note textDataDeliveryEnabled set to false. Invocation logging can capture prompt and completion text, which is often the fastest accidental route to storing customer data in a log group with a retention policy nobody reviewed. Log the metadata you need for governance and leave the content out unless you have a specific, approved reason.

The Lambda is short, and its restraint is the point.

import json
import os
import boto3

iam = boto3.client("iam")
sns = boto3.client("sns")

DENY_POLICY = {
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "CostCircuitBreaker",
        "Effect": "Deny",
        "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
        "Resource": "*",
    }],
}

def lambda_handler(event, context):
    """Triggered by a CloudWatch alarm via SNS. Blocks inference for one role."""
    alarm = json.loads(event["Records"][0]["Sns"]["Message"])
    if alarm["NewStateValue"] != "ALARM":
        return {"action": "none", "reason": "alarm not in ALARM state"}

    role = os.environ["TARGET_ROLE"]          # never derived from the event payload
    iam.put_role_policy(
        RoleName=role,
        PolicyName="CostCircuitBreaker",
        PolicyDocument=json.dumps(DENY_POLICY),
    )
    sns.publish(
        TopicArn=os.environ["NOTIFY_TOPIC"],
        Subject=f"Bedrock access suspended for {role}",
        Message=(
            f"Alarm {alarm['AlarmName']} breached its threshold, so an explicit "
            f"deny policy is now attached to {role}. Inference is blocked until a "
            f"human removes CostCircuitBreaker. Investigate before restoring."
        ),
    )
    return {"action": "denied", "role": role}

Two design choices keep this safe. The target role comes from an environment variable rather than the alarm payload, because deriving a privileged action's target from an event body is how a small misconfiguration becomes a wide outage. And there is no automatic re enable, since a breaker that resets itself will simply trip again on the same loop and turn one incident into a recurring one. A human removing the policy is a feature.

Practice IAM policy design on real AWS

Policy conditions and deny logic are much easier to trust once you have watched a policy actually refuse a call. The AWS Solutions Architect Associate course on KodeKloud covers IAM, organizations, and the billing and cost management surfaces in depth, and the AWS playground gives you real AWS services to test policies against without touching a company account.

Layer 5: Alert on the things that indicate abuse

Cost anomalies and security incidents look identical at the metric level, so the same alerts serve both.

# Budget scoped to one team's Bedrock spend, with an action attached
aws budgets create-budget --account-id 123456789012 --budget '{
  "BudgetName": "bedrock-payments-monthly",
  "BudgetLimit": {"Amount": "4000", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "CostFilters": {"TagKeyValue": ["user:team$payments"]}
}' --notifications-with-subscribers '[{
  "Notification": {
    "NotificationType": "ACTUAL",
    "ComparisonOperator": "GREATER_THAN",
    "Threshold": 80,
    "ThresholdType": "PERCENTAGE"
  },
  "Subscribers": [{"SubscriptionType": "SNS", "Address": "arn:aws:sns:us-east-1:123456789012:cost-alerts"}]
}]'

Beyond spend thresholds, four signals are worth alarms because each one reads as both a cost event and a security event. A sudden jump in invocation volume from a single principal is the shape of both a retry loop and a stolen credential. Inference calls from an unexpected region often mean someone is working around a restriction. Repeated access denied errors on bedrock:InvokeModel suggest something enumerating what it can reach. And a rising ratio of output tokens to input tokens can indicate prompt manipulation coaxing longer generations, which costs more per call.

Where to start

1. Run Cost Explorer filtered to Bedrock and find out what you currently spend and whether you can attribute any of it, which is usually a sobering five minutes.
2. Tag the roles your AI workloads assume, create application inference profiles per team, and activate the tags in Billing so attribution starts accumulating.
3. Replace every bedrock:InvokeModel on * with an allow list of specific model ARNs and a region condition.
4. Add the deny statement requiring your guardrail identifier, so guardrails stop being optional in application code.
5. Check your service quotas and lower them deliberately in accounts that should never burst.
6. Turn on model invocation logging with content delivery disabled, then build the metric filter and alarm before you build the Lambda.
7. Deploy the circuit breaker with no automatic reset, and test it in a sandbox account by deliberately tripping it.

Conclusion

The uncomfortable truth about AI cost governance on AWS is that the tools you reach for first are the ones that cannot help. Budgets alert, cost allocation reports, and anomaly detection notices, all of them well and none of them fast enough or forceful enough to stop an agent spending your quarter's budget between lunch and dinner.

Enforcement comes from a different set of controls. Quotas cap the rate, IAM refuses the call, service control policies make the refusal organization wide, and a CloudWatch alarm wired to a Lambda gives you the circuit breaker AWS does not ship. Build attribution for the conversations about chargeback, and build those four for the afternoon when something goes wrong. Start with the IAM resource scoping this week, because it is the change with the largest security and cost benefit for the least effort.

Ready to Build Real AWS Governance Skills?

Every control in this tutorial is ordinary AWS practice pointed at a new workload, which makes the underlying skills worth having outright. The AWS Solutions Architect Associate course on KodeKloud covers IAM, organizations, and cost management in depth, Introduction to Amazon Bedrock covers the service these policies govern, and the AWS playground gives you live AWS to test a deny policy against. Start with one today.

FAQs