Tired of managing AWS Bedrock with console chaos and untracked costs? Here are three real-world strategies, from IAM guardrails to full IaC pipelines, to get your GenAI deployments under control.

So, How ARE We Managing Bedrock? A View from the Trenches

I got a Slack message at 7 PM on a Thursday. It was from one of our lead developers. “Hey Darian, quick question. Prod is behaving… differently than Staging. The Bedrock responses are totally off.” My heart sank. I knew exactly what this was before I even looked. Someone, somewhere, had “fixed” something directly in the AWS console. Sure enough, after 20 minutes of frantic clicking, I found it: a developer, trying to be helpful, had provisioned a brand new throughput for Claude 3 Sonnet in the `staging-us-east-1` account to “test something out.” The production app, still running our Terraform-deployed Claude 2.1 model, was now completely out of sync. This, right here, is the core of the Bedrock management headache.

The “Why”: The Console is Just Too Easy

Let’s be honest. The root of the problem is a culture clash. GenAI development is fast, experimental, and iterative. DevOps and Cloud Architecture are (or should be) disciplined, repeatable, and automated. The AWS Bedrock console is a beautiful, easy-to-use playground that practically begs developers to click “Provision Throughput” to see what happens. This directly encourages bypassing the very Infrastructure as Code (IaC) pipelines we’ve spent years building. The result? Configuration drift, untraceable costs, and environments that are impossible to replicate reliably. It’s not about blaming developers; it’s about recognizing that the tool’s design conflicts with our operational principles. So, how do we fix it?

Solution 1: The “Stop the Bleeding” Fix – IAM Guardrails

This is my first move when I walk into a messy situation. You can’t rebuild the world in a day, but you can stop people from making it worse. The goal here isn’t to achieve perfect IaC, but to enforce visibility and basic accountability, even for console actions.

We use a combination of IAM policies and Service Control Policies (SCPs) at the AWS Organization level. The idea is simple: you can’t provision a new model unless you attach a few critical tags. This forces the “drive-by” experimenter to at least leave a breadcrumb trail.

Here’s a sample IAM policy you can attach to your developer roles. It denies the ability to provision a model unless the request includes tags for ‘owner’, ‘project’, and ‘cost-center’.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceTagsOnBedrockProvisioning",
            "Effect": "Deny",
            "Action": "bedrock:CreateProvisionedModelThroughput",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:RequestTag/owner": "true",
                    "aws:RequestTag/project": "true",
                    "aws:RequestTag/cost-center": "true"
                }
            }
        }
    ]
}

Pro Tip: This is a hacky, but effective, stopgap. It doesn’t put the model into Git, but it immediately surfaces who is creating resources and why. When the finance team asks about a new $5k/month charge, you can pinpoint the owner in seconds via Cost Explorer.

Solution 2: The “Right Way” – Full Infrastructure as Code

Once the bleeding has stopped, it’s time to build the permanent solution. Bedrock resources—provisioned throughput, agents, knowledge bases—are just like any other cloud resource. They belong in code, managed by a CI/CD pipeline. For us at TechResolve, that means Terraform.

The workflow becomes what it should be:

1. A developer needs a new model. They open a Pull Request against our `infra-live` repository.
2. They add a new Terraform resource block, defining the model, the commitment term, and the name.
3. The PR is reviewed by the team for cost and architectural impact.
4. On merge, our Jenkins pipeline triggers a `terraform apply` against the target account (e.g., `dev-genai-account`).

Here’s how simple provisioning Sonnet 3 looks in HCL. It’s declarative, version-controlled, and peer-reviewed.

resource "aws_bedrock_provisioned_model_throughput" "claude_sonnet_prod" {
  provisioned_model_name = "claude3-sonnet-prod-v1"
  model_arn              = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"
  commitment_duration    = "OneMonth"
  model_units            = 1

  tags = {
    Environment = "prod"
    Project     = "core-api"
    ManagedBy   = "Terraform"
  }
}

The difference this makes is night and day. Here’s how I see it:

Solution 3: The “Enterprise” Play – A Centralized Model Registry

At a certain scale, even managing IaC across dozens of teams and accounts becomes a burden. If you have multiple application teams all wanting to use the same few foundational models, you can end up with redundant provisioned throughputs, which gets expensive fast. The solution is to treat your models like a shared service.

Here’s the pattern:

• The Platform Account: Designate a single AWS account (e.g., `ai-platform-prod`) to be the home for all provisioned models. The central Cloud Platform team owns this account.
• Provision Centrally: The platform team uses IaC (Solution 2) to provision a curated set of models (e.g., one for Claude Sonnet, one for Titan) in this central account.
• Share via Resource Policies: The magic happens here. You use resource-based IAM policies attached to the provisioned models to grant `bedrock:InvokeModel` permissions to specific IAM roles in your application accounts (e.g., the EC2 instance role for `app-team-a-prod`).
• Private Access: Application accounts access the central models securely over AWS PrivateLink using a VPC Endpoint for Bedrock.

With this setup, your application teams can’t provision models at all. Their IAM permissions are restricted to `InvokeModel`. They consume AI as a managed, internal service. This centralizes cost management, versioning, and security into a single expert team.

Warning: This is a powerful pattern, but it’s not for everyone. It introduces organizational dependency. If your central platform team is slow to approve and provision new models, you will stifle innovation. This requires a dedicated team and a clear process for handling requests from developers.

Ultimately, there’s no single perfect answer. The key is to move away from the wild west of console clicking. Start with IAM guardrails today. It will take you ten minutes and save you hours of pain. Then, begin the journey of bringing your Bedrock resources into your IaC tooling. Your future self—and your finance department—will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions