DEV Community: Evgeny Anikiev

Bedrock Managed Agents vs AgentCore: Which Should Run Your Agents?

Evgeny Anikiev — Mon, 26 Oct 2026 16:03:52 +0000

AWS now offers two ways to run AI agents: an OpenAI agent loop that Amazon Bedrock manages for you, or your own agent code on AgentCore. Here is what each one does, what the preview can't do yet, and how to choose.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Checked against the Amazon Bedrock and AgentCore documentation on October 26, 2026.

TL;DR: Amazon Bedrock Managed Agents, powered by OpenAI, is a managed agent loop. You send instructions, skills, and a message, and AWS runs the conversation with an OpenAI model while the tools run on compute you provide. Amazon Bedrock AgentCore is a set of services for agents you build yourself, with any framework and any model: Runtime, Gateway, Memory, Identity, Policy, Observability, and Evaluations. Pick Managed Agents for internal agents on OpenAI models that work on files and run shell commands, and accept that it is a preview in three US Regions with no subagents or long-term memory. Pick AgentCore for customer-facing agents, non-OpenAI models, or anything that needs Cedar policy checks on tool calls. The two also combine: Managed Agents can run its tools inside AgentCore Runtime.

What this post covers:

What each service is, in one paragraph each.
A side-by-side table: models, Regions, tools, memory, security, and pricing.
What the Managed Agents preview does not support yet.
How to start a Managed Agents session, with the IAM role it needs.
A worked example: three agents, three choices.

What is Amazon Bedrock Managed Agents?

Amazon Bedrock Managed Agents, powered by OpenAI (BMA in the AWS docs), runs OpenAI-model agents in your AWS account. AWS announced the public preview at the end of September 2026. It is built on a customized version of OpenAI's Agents API, adapted to use AWS identities and resources.

The documentation describes how the work splits: "The service manages the agent's conversation and model interactions. Tools execute in the compute environment that you provide." You do not write the agent loop. You write instructions, add skills (folders with a SKILL.md file) and local MCP servers, and point the session at an execution environment.

That environment is one of two types:

self_hosted: a codex exec-server process on a machine or container you run. It opens an outbound HTTPS and WebSocket connection to the service, so it needs no inbound ports.
aws_bedrock_agentcore: an AgentCore Runtime that contains the exec server. AWS's example CDK app creates the Runtime, storage, and networking for you.

Model inference runs in the Bedrock service on the bedrock-mantle endpoint. Your environment only runs the tools.

What is Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore is a set of services for running agents that you write. AgentCore Runtime is framework-agnostic: AWS documents agents built with Strands Agents, LangGraph, and CrewAI running on it, and the agent can call models on Bedrock or from other providers. Each Runtime session gets its own microVM, lasts up to 8 hours, and ends after 15 minutes of inactivity by default.

Around Runtime sit the other parts, and you use only the ones you need:

Gateway turns APIs and Lambda functions into MCP tools.
Policy checks every tool call through Gateway against Cedar rules. It became generally available on March 3, 2026.
Memory keeps short-term conversation state and long-term records per user.
Identity handles inbound auth and outbound credentials, so tools don't need keys in code.
Observability sends traces to Amazon CloudWatch in your account.
Evaluations scores live traces with 13 built-in evaluators. It became generally available on March 31, 2026.

With AgentCore you own the loop: which model to call, when to call a tool, how to retry, and what to store. If you're moving an existing agent there, my 15-check AgentCore readiness score covers what to prepare.

Bedrock Managed Agents vs AgentCore: side by side

	Bedrock Managed Agents (preview)	AgentCore (your own agent)
Who writes the agent loop	AWS and OpenAI	You, with Strands, LangGraph, CrewAI, or your own code
Models	OpenAI models available in the Region	Any model on Bedrock or from another provider
Status	Public preview; "Preview functionality and APIs can change"	Runtime, Gateway, Policy, and Evaluations generally available
Regions	US East (N. Virginia), US West (Oregon), US East (Ohio)	More Regions; check the AgentCore Region list
Endpoint	`bedrock-mantle`, path `/openai/v1/agents/sessions`	`bedrock-agentcore`
Where tools run	Your machine or container, or AgentCore Runtime	AgentCore Runtime (microVM per session)
Tools	Skills (`SKILL.md` folders) and STDIO MCP servers; shell commands in the environment	Gateway MCP tools, plus whatever your framework supports
Tool-call policy	Not described in the BMA docs	Cedar rules in AgentCore Policy, enforced at Gateway
Memory	Session context only; "No built-in long-term memory integration"	AgentCore Memory, short-term and long-term
Subagents	"Not supported"	Whatever your framework supports
Input	Text	Whatever your code accepts
Console	None; APIs and deployment examples only	Console, CLI, and SDKs
Pricing	Model inference plus the AWS resources you use	Model inference plus a meter per AgentCore service

The table comes down to who owns the agent code. With Managed Agents, AWS and OpenAI own it, and you supply the workspace and the skills. With AgentCore, you own it, and AWS supplies the hosting and the governance parts around it.

What can't Bedrock Managed Agents do yet?

The preview's limitations page lists these, and each one decides a use case:

No subagents. One agent per session. If your design hands work from a planner to specialist agents, build it on AgentCore.
No cross-Region inference profiles. Inference runs in the Region you call, and you can't route it to other Regions for extra capacity.
Text input only. No images or files in the session input. Files go into the workspace instead.
No long-term memory. A session keeps its conversation, and that's all. Anything the agent should remember across sessions has to live in files or your own store.
No turn list or turn retrieval API. You follow progress through the event stream and the turn_id on each item.
No service-managed KMS key option for session data and no programmatic tool calling (code mode).
No console. Everything goes through the API and the example scripts.

Two behaviors matter in production. Deleting a session does not delete files in your workspace, S3 data, or the AgentCore Runtime stack, so clean those up yourself. Cancelling a turn does not undo what a tool already did: if the agent ran a command that changed something, cancel stops the next step, not that one.

How do I start a Bedrock Managed Agents session?

You need three pieces: a session role that the service assumes to call the model, permissions for your client, and an execution environment.

1. The session role

The trust policy lets the bedrock-mantle service assume the role, scoped to your account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "bedrock-mantle.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "123456789012" },
        "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-mantle:*:123456789012:*" }
      }
    }
  ]
}

The permissions policy allows inference on one model only. This is where you pin the model:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock-mantle:CreateInference",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "bedrock-mantle:Model": "openai.gpt-5.6-luna" }
      }
    }
  ]
}

2. Client permissions

The caller needs bedrock-mantle:CreateAgentSession, GetAgentSession, ListAgentSessions, CreateAgentSessionEvent, ListAgentSessionEvents, ListAgentSessionItems, and DeleteAgentSession. It also needs iam:PassRole on the session role, with the condition "iam:PassedToService": "bedrock-mantle.amazonaws.com". A self-hosted exec server additionally needs bedrock-mantle:RegisterEnvironment and bedrock-mantle:ConnectEnvironment.

3. Create the session and send a message

Requests are signed with SigV4 for the service name bedrock-mantle. curl can sign them with --aws-sigv4. With temporary credentials, pass the session token as a header:

ENDPOINT=https://bedrock-mantle.us-east-1.api.aws
SIGN=(--aws-sigv4 "aws:amz:us-east-1:bedrock-mantle"
      --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY"
      -H "x-amz-security-token: $AWS_SESSION_TOKEN"
      -H "Content-Type: application/json")

curl -s "${SIGN[@]}" -X POST "$ENDPOINT/openai/v1/agents/sessions" -d '{
  "agent": {
    "model": "openai.gpt-5.6-luna",
    "instructions": "Use the workspace tools to complete the user'\''s task."
  },
  "environment": {
    "type": "self_hosted",
    "workspace_directory": "/srv/agent/workspace",
    "capability_directories": ["/srv/agent/workspace/skills"]
  },
  "role_arn": "arn:aws:iam::123456789012:role/BedrockManagedAgentsSessionRole",
  "stream": false
}'

Take the session ID from the response, then submit a message as an event:

SESSION_ID=<id from the response>

curl -s "${SIGN[@]}" -X POST "$ENDPOINT/openai/v1/agents/sessions/$SESSION_ID/events" -d '{
  "events": [{
    "type": "agent.session.input.message",
    "input": [{"role": "user", "content": [
      {"type": "input_text", "text": "Find the failing test in this repo and propose a fix."}
    ]}]
  }]
}'

Follow progress with GET .../events (a text/event-stream) and read the results with GET .../items, which returns messages, reasoning summaries, command executions, and MCP calls, 20 per page by default. The session status moves between idle, in_progress, and failed. To run tools in AgentCore Runtime instead of your own host, set "type": "aws_bedrock_agentcore" with a runtime_arn and a runtime_qualifier such as DEFAULT.

One rule from the API reference is worth putting in your client: after a network error, check whether the create or submit call was accepted before you retry it, or you get a duplicate session or a duplicate turn.

How much do Bedrock Managed Agents and AgentCore cost?

The Managed Agents documentation lists two charges: model inference and the AWS resources your application uses. When I checked the Bedrock pricing page on October 26, it had no separate Managed Agents line. Pricing can change when the service reaches general availability.

The "AWS resources" part is not zero. AWS's AgentCore example creates a NAT gateway, which bills every hour whether or not a turn is running, and the Runtime bills for the compute your sessions use.

AgentCore has a meter per service. List prices from the AgentCore pricing page:

AgentCore service	Price
Runtime microVM (v1), CPU	$0.0895 per vCPU-hour
Runtime microVM (v1), memory	$0.00945 per GB-hour
Gateway, tool invocations	$0.005 per 1,000
Policy	$0.000025 per request
Memory, long-term records (built-in)	$0.75 per 1,000 records per month
Evaluations, custom	$1.50 per 1,000 evaluations, plus model usage

Runtime microVMs bill per second with a 1-second minimum. For scale: a session using 1 vCPU and 2 GB for one hour costs $0.0895 + 2 × $0.00945 = $0.1084 on v1. One million tool calls through Gateway cost $5, and a Policy check on each of them adds $25. Put these next to your monthly token spend in Cost Explorer before you decide which meter is worth optimizing.

Should I use Bedrock Managed Agents or AgentCore?

Use Managed Agents when the agent is internal, OpenAI-based, and workspace-shaped. Use AgentCore when you need a different model, memory, or policy on tool calls, or when customers see the output.

Here is how that plays out for a platform team with three agents to place.

1. A repo maintenance agent for engineers. It reads code, runs tests, and proposes fixes. Users are internal, the team already uses OpenAI models, and the work is files and shell commands. Choice: Managed Agents, self-hosted. The exec server runs in a build container with a checkout of the repo. Skills hold the team's conventions. There is no agent code to maintain.

2. A customer support agent with refunds. It runs on a Claude model, remembers each customer between conversations, and calls a refund API. Choice: AgentCore. It needs a non-OpenAI model, long-term memory, and a Cedar rule that blocks refunds above a set amount at Gateway. The preview offers none of those three.

3. A nightly data quality agent. It runs for up to six hours on an OpenAI model and should not run on anyone's laptop. Choice: Managed Agents with the AgentCore environment. The session fits inside a Runtime session's 8-hour limit, and the tools run in an isolated microVM in the team's account. The team deletes the Runtime stack and the NAT gateway when they retire the agent, because deleting the session does not.

FAQ

Is Bedrock Managed Agents the same as Amazon Bedrock Agents?
No. Amazon Bedrock Agents is the earlier Bedrock feature for building agents with action groups and knowledge bases. Bedrock Managed Agents, powered by OpenAI, is a separate preview service on the bedrock-mantle endpoint that runs OpenAI's agent loop.

Can Bedrock Managed Agents use Claude or other non-OpenAI models?
The preview documentation only covers OpenAI models supported in the Region and account. For Claude, Llama, or other models, build the agent on AgentCore Runtime.

Does Bedrock Managed Agents replace AgentCore?
No. Managed Agents can use AgentCore Runtime as its execution environment. AgentCore remains the place for agents with your own code, other models, Gateway tools, Memory, and Policy.

Which Regions support Bedrock Managed Agents?
During the preview: US East (N. Virginia), US West (Oregon), and US East (Ohio), through regional bedrock-mantle endpoints such as https://bedrock-mantle.us-east-1.api.aws.

Is Bedrock Managed Agents production-ready?
It is a public preview, and AWS says preview APIs can change. It has no subagents, no long-term memory, and no console. Use it for internal agents with a fallback, and plan for API changes before general availability.

What does Bedrock Managed Agents cost?
The docs list model inference plus the AWS resources you use, such as AgentCore Runtime compute or your own servers. No separate agent fee appeared on the Bedrock pricing page as of October 26, 2026.

Can I use MCP tools with Bedrock Managed Agents?
Yes, as STDIO MCP servers that run in the execution environment, configured in agent.tools or the BMA_MCP_SERVERS_JSON variable, each with an allowed_tools list. The preview docs do not describe remote MCP servers.

Sources

Choosing where your agents run? I set up Bedrock and AgentCore foundations for AI teams at DevOps Cloud Consult: IAM roles, networking without surprise NAT bills, observability, and cost tracking per team. Send me the agent you want to move and I'll tell you which side of this table it lands on.

Get one AWS cost fix every two weeks: subscribe on Substack.

Track Amazon Bedrock Costs per Team: 3 Methods Compared

Evgeny Anikiev — Mon, 26 Oct 2026 09:32:14 +0000

Your Bedrock bill shows models, Regions, and tokens, with no team names. Here is how to split it by team with IAM principals, application inference profiles, or Projects, and how to put a budget on each team.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Checked against the Amazon Bedrock documentation and AWS announcements on October 26, 2026.

TL;DR: Amazon Bedrock cost allocation now works three ways, and each one charges inference cost to a team. IAM principal cost allocation charges each request to the IAM user or role that made it. If each team calls Bedrock with its own role, it needs no code change. Application inference profiles carry tags for InvokeModel and Converse calls on the bedrock-runtime endpoint. Projects carry tags for Responses and Chat Completions calls on the bedrock-mantle endpoint. Start with IAM principals, add profiles or Projects where several teams share one role, and put an AWS Budget on each team's tag. Cost Anomaly Detection does not cover AWS Marketplace charges, so do not rely on it alone.

What this post covers:

Why the default Bedrock bill can't answer "which team spent this".
The three methods side by side, with the endpoints each one covers.
Setup commands for each method.
A per-team budget with the AWS CLI.
The limits: delays, the payer account, and what CUR does not show.

Why doesn't my Bedrock bill show which team spent the money?

By default, Cost Explorer and the Cost and Usage Report (CUR) group Bedrock spend by model, Region, and token type. A usage type such as USE1-Claude4.6Sonnet-input-tokens tells you what was used and where, but nothing on that line says who sent the request. When three teams share one AWS account and one model, their spend lands on the same lines.

You can't fix this by tagging the model. On-demand foundation models are AWS-owned resources, so there is nothing of yours to tag. AWS added three ways around that, and each one covers different APIs.

In May 2026, The Register reported on a reader who ran Claude Opus through Bedrock and received a $30,141.33 bill for April. Cost Anomaly Detection was set up and never fired. AWS told the publication that AWS Marketplace charges are not supported by Cost Anomaly Detection, and that AWS Budgets does cover Bedrock spend billed through Marketplace. A budget on that spend is the alert that would have covered it.

Which Bedrock cost allocation method should I use?

Use IAM principal cost allocation first, because it needs no code change when each team or application already has its own IAM role. Add application inference profiles when several teams share one role and call InvokeModel or Converse. Use Projects for apps on the OpenAI-compatible Responses or Chat Completions APIs. You can run all three in one account.

The three methods, side by side:

What cost is charged to: IAM principals charge the IAM user or role that made the call. Application inference profiles charge the profile the app called. Projects charge the project ID the app sent.
Endpoints and APIs: IAM principals cover bedrock-runtime (since April 9, 2026) and bedrock-mantle (since August 11, 2026). Application inference profiles cover InvokeModel and Converse on bedrock-runtime. Projects cover Responses and Chat Completions on bedrock-mantle.
Code change: IAM principals need none if each team has its own role. Profiles need the app to call the profile ARN in place of the model ID. Projects need the app to send a project ID.
Where you see it: IAM principal data needs a CUR 2.0 export with caller identity turned on, and principal tags also show in Cost Explorer. Profile and Project tags show in Cost Explorer, classic CUR, and CUR 2.0.
Scaling limit: IAM principals and session tags allow up to 50 tags per user or role. Application inference profiles are tied to one model, so you need one profile per model, team, and tag set. Projects allow up to 1,000 per account and are not tied to a model.

Method 1: How do I allocate Bedrock costs by IAM role?

Tag the IAM roles and users that call Bedrock and activate those tags in the management account. Then turn on caller identity data in a CUR 2.0 export. Bedrock records the caller's ARN on each CUR line and copies the role's tags with an iamPrincipal/ prefix.

1. Tag each role that calls Bedrock. One role per team or per application keeps this simple:

aws iam tag-role \
  --role-name support-agent-prod \
  --tags Key=team,Value=support Key=cost-center,Value=cc-1042

2. Pass session tags for shared roles. When one role serves many teams or tenants, pass tags when the caller assumes the role. A session tag overrides a principal tag with the same key for that session:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/bedrock-shared \
  --role-session-name tenant-acme \
  --tags Key=tenant,Value=acme

The role's trust policy must allow sts:TagSession for this to work. Federated users from an identity provider such as Okta or Microsoft Entra ID can carry session tags the same way.

3. Activate the tags. In the Billing and Cost Management console, open Cost allocation tags, select the iamPrincipal/ tags, and choose Activate. Do this from the management (payer) account. Member accounts can't activate them. A tag only appears in the list after that principal has made at least one Bedrock call.

4. Turn on caller identity in CUR 2.0. In Data Exports, create a CUR 2.0 export and select Include caller identity (IAM principal) allocation data. Legacy CUR does not carry these fields, and existing exports don't pick up identity data for past periods.

5. Query it. CUR 2.0 adds a line_item_iam_principal column with the caller's ARN, such as arn:aws:sts::123456789012:assumed-role/support-agent-prod/session-123. In Athena, group by it:

SELECT line_item_iam_principal,
       line_item_product_code,
       ROUND(SUM(line_item_unblended_cost), 2) AS cost_usd
FROM   cur2_export
WHERE  line_item_iam_principal <> ''
  AND  line_item_usage_start_date >= TIMESTAMP '2026-10-01 00:00:00'
GROUP  BY 1, 2
ORDER  BY cost_usd DESC;

Replace cur2_export with your export's table name. In Cost Explorer, principal tags appear under the IAM category of the Tags filter.

Method 2: How do I tag Bedrock usage with application inference profiles?

An application inference profile is a copy of a model ID that you own and can tag. Create one per team and model, then have each team's app call its profile ARN. The profile's tags go onto the billing record for every request made through it.

1. Create the profile. The source can be a foundation model or a cross-Region (system-defined) inference profile:

aws bedrock create-inference-profile \
  --inference-profile-name support-agent-gpt-oss-120b \
  --model-source copyFrom=arn:aws:bedrock:us-east-1::foundation-model/openai.gpt-oss-120b-1:0 \
  --tags key=team,value=support key=cost-center,value=cc-1042

The response returns inferenceProfileArn.

2. Call the profile ARN in place of the model ID:

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

response = bedrock.converse(
    modelId="arn:aws:bedrock:us-east-1:123456789012:inference-profile/abc123example",
    messages=[{"role": "user", "content": [{"text": "Summarize ticket 4821"}]}],
)

3. Activate the tags (team, cost-center) in Cost allocation tags, the same as in Method 1.

Application inference profiles don't work with the Responses or Chat Completions APIs on either endpoint. A request to those APIs that names a profile is rejected with a 400 error. Profiles also add up, since three teams on two models need six profiles. Keep them in Terraform or CloudFormation so the list stays readable.

Method 3: How do I track Bedrock costs with Projects?

Projects are the tagging method for the bedrock-mantle endpoint, which serves the OpenAI-compatible Responses and Chat Completions APIs. Create a project per team or application, tag it, and have the client send the project ID. A project is not tied to a model, so one project covers every model the team calls.

You manage projects through the Projects API under the mantle base URL. POST /organization/projects with a name and tags creates a project. POST /organization/projects/{id} with add_tags or remove_tag_keys changes its tags. There is no operation that replaces the whole tag set at once.

The client sends the project ID with each request. With the OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(project="proj_123")  # base_url and API key for bedrock-mantle set as usual

With plain HTTP, send the header OpenAI-Project: proj_123. Requests without a project ID go to your account's default project, which can't be tagged. An archived project rejects new requests and keeps its metrics for 30 days.

How do I set a Bedrock budget per team?

Create one AWS Budget per team with a tag filter. Budgets covers Bedrock spend billed through AWS Marketplace, which Cost Anomaly Detection does not. Use the tag key exactly as it appears in Cost Explorer's tag list.

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "bedrock-support-monthly",
    "BudgetLimit": {"Amount": "2000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST",
    "FilterExpression": {
      "Tags": {"Key": "team", "Values": ["support"], "MatchOptions": ["EQUALS"]}
    },
    "Metrics": ["UnblendedCost"]
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "FORECASTED",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "support-leads@example.com"}]
  }]'

A forecast alert at 80% gives the team warning before the month ends. Add a second notification of type ACTUAL at 100% for the hard line.

To see all teams at once, group Cost Explorer by the same tag:

aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-11-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=TAG,Key=team

What can't Bedrock cost allocation tell you?

All three methods report cost per team per day or per hour. None of them gives cost per request or per prompt. Plan around these limits before you promise finance a number:

Delay: Tags take up to 24 hours to appear in Cost Explorer and CUR after activation. AWS's launch blog says 24 to 48 hours.
Not retroactive: Cost allocation tags only apply from activation onward. Spend before that stays untagged.
Payer account only: Tag activation happens in the management account. If you're a team in a member account, ask whoever owns billing.
No per-request cost: CUR rows are aggregated by usage type and time period, with no request ID. For per-request or per-prompt cost, use model invocation logs and join them to CUR at the model and usage-type level. Session tags are not written to invocation logs.
STS limits: If you pass a session tag per tenant, every tenant switch is an AssumeRole call. The default STS quota is 500 AssumeRole calls per second per account.
Marketplace alerts: Cost Anomaly Detection does not support AWS Marketplace charges. Check how your model's charges are billed, and use Budgets for alerts.

Worked example: three teams in one Bedrock account

A company runs three AI workloads in one AWS account:

The support agent runs on EKS under the IAM role support-agent-prod and calls Converse. The role gets team=support. That is Method 1, with no code change.
The data science team signs in through Okta and runs notebooks against several models. Their identity provider passes team=data-science as a session tag. That is Method 1 again, with no code change.
The internal chatbot is built on the OpenAI SDK and calls the Responses API on bedrock-mantle. It gets a project tagged team=platform. That is Method 3, with one line of client config.

Application inference profiles enter only if the support agent and a second app later share one role. Each team gets a budget filtered on team. Finance gets one Cost Explorer view grouped by team, with every Bedrock dollar assigned to a team.

FAQ

Can I tag an Amazon Bedrock foundation model directly?

No. On-demand foundation models belong to AWS, so you can't tag them. Tag the IAM principal that calls the model, call it through a tagged application inference profile, or send a tagged project ID on bedrock-mantle.

How long until Bedrock cost allocation tags show up in Cost Explorer?

Up to 24 hours after you activate the tags. AWS's launch blog says 24 to 48 hours. IAM principal tags only appear after that principal has made at least one Bedrock call. Tags don't apply to spend from before activation.

Do I need CUR 2.0 for Bedrock cost allocation by IAM role?

Yes, for line-item caller data. The line_item_iam_principal column and principal tag data exist only in CUR 2.0 exports with "Include caller identity (IAM principal) allocation data" selected. Legacy CUR does not have them.

Do application inference profiles work with cross-Region inference?

Yes. Create the application inference profile from a cross-Region (system-defined) inference profile in place of a single-Region foundation model. Requests then route across Regions, and the profile's tags still apply.

Can I get the cost of a single Bedrock request?

Not from CUR or Cost Explorer. Both aggregate by usage type over an hour or a day. Use model invocation logs for token counts per request, multiply by the model's price, and reconcile the total against CUR.

Does AWS Cost Anomaly Detection catch Bedrock cost spikes?

Not when the charges are billed through AWS Marketplace. AWS told The Register in May 2026 that Cost Anomaly Detection does not support Marketplace charges, after a reader's $30,141.33 Claude bill raised no alert. AWS Budgets does cover Bedrock spend billed through Marketplace, so set a budget per team as well.

How do I split Bedrock costs per tenant in a SaaS product?

Pass the tenant as a session tag when your service assumes the Bedrock role. On bedrock-mantle, you can give each tenant its own project instead. Watch the STS quota of 500 AssumeRole calls per second if you assume a role per request.

Sources

Can't tell which team spent last month's Bedrock bill? I set up cost allocation and budgets for AI teams on AWS at DevOps Cloud Consult. Send me your Bedrock line from Cost Explorer and I'll map which method fits each workload.

Get one AWS cost fix every two weeks: subscribe on Substack.

Bedrock vs Self-Hosted LLMs on EKS: The Break-Even Math

Evgeny Anikiev — Fri, 23 Oct 2026 09:51:49 +0000

When do your own GPUs beat Amazon Bedrock for the same open-weight model? Official AWS prices, the tokens per second you need to break even, and the Karpenter and vLLM config to test it.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Prices pulled from the AWS Price List API on October 23, 2026 (US East, N. Virginia, on-demand list prices).

TL;DR: The same open-weight model costs per token on Bedrock and per hour on your own GPUs. One H100 on a p5.4xlarge running gpt-oss-120b costs $5,022 a month. To beat Bedrock's price for that model, it has to process about 7,300 tokens per second, around the clock, every day of the month. Unless your traffic is that high and that steady, Bedrock costs less. Self-hosting also makes sense when you need a model Bedrock doesn't offer.

The numbers in this post:

Bedrock prices for gpt-oss-120b, gpt-oss-20b, and Llama 3.3 70B.
EC2 GPU instance prices for the instances that fit each model.
The break-even volume in tokens per month and tokens per second.
The costs a per-token price hides and a per-hour price doesn't.
A Karpenter NodePool and vLLM Deployment to run your own benchmark.

Which costs less: Amazon Bedrock or self-hosting on EKS?

Unless a GPU stays busy around the clock, Bedrock costs less. Bedrock bills per token and costs nothing when idle. A self-hosted model on EKS bills per GPU-hour whether it serves traffic or not. Self-hosting only wins when a GPU stays busy enough that its hourly cost divided by its tokens drops below Bedrock's per-token price. For gpt-oss-120b on one H100, that point is about 19 billion tokens a month.

Bedrock and self-hosting on EKS, side by side:

Billing: Bedrock charges per million tokens. EKS charges per GPU-hour, plus $73 a month for the cluster control plane.
Idle cost: zero on Bedrock. Full hourly price on EKS until the node is removed.
Scaling: Bedrock scales within your tokens-per-minute quota. On EKS, you scale GPU nodes yourself, with cold starts of several minutes.
Models: Bedrock offers its catalog plus Custom Model Import. EKS runs any open-weight model that fits your GPUs.
Operations: AWS runs Bedrock. On EKS, your team owns drivers, the serving engine, autoscaling, and on-call.

What does each option cost?

Bedrock: per token

These are on-demand (Standard tier) prices per million tokens in US East, from the AWS Price List API:

gpt-oss-120b: $0.15 input, $0.60 output.
gpt-oss-20b: $0.07 input, $0.30 output.
Llama 3.3 70B Instruct: $0.72 input, $0.72 output.

Batch inference and the Flex tier halve these prices for work that can wait, for example $0.075 input and $0.30 output for gpt-oss-120b.

Agents send far more input than they get back, because every call resends the conversation and tool results. With 3 input tokens for every output token, the blended price per million tokens is:

gpt-oss-120b: $0.2625
gpt-oss-20b: $0.1275
Llama 3.3 70B: $0.72

Self-hosted: per GPU-hour

On-demand Linux prices in US East:

g6e.xlarge (1× NVIDIA L40S, 48 GB): $1.861 per hour, about $1,359 a month.
p5.4xlarge (1× NVIDIA H100, 80 GB): $6.88 per hour, about $5,022 a month.
g6e.12xlarge (4× L40S, 192 GB total): $10.49 per hour, about $7,660 a month.

Which instance fits which model:

gpt-oss-20b fits on one L40S (g6e.xlarge). OpenAI says it runs within 16 GB of memory.
gpt-oss-120b fits on one 80 GB GPU, per OpenAI, so one H100 (p5.4xlarge) works. Four L40S GPUs (g6e.12xlarge) also fit it, at a higher hourly price.
Llama 3.3 70B needs about 140 GB for its weights at 16-bit precision, so it needs g6e.12xlarge or larger.

Where is the break-even point?

Divide the monthly instance cost by Bedrock's blended price. The result is how many tokens the instance has to process each month to cost the same as Bedrock. Divide by the seconds in a month to get the tokens per second it has to sustain.

HOURS = 730  # hours in an average month

def break_even(instance_per_hour, bedrock_in, bedrock_out, ratio=3):
    """Prices: instance in USD/hour, Bedrock in USD per million tokens.
    ratio = input tokens per output token."""
    blended = (ratio * bedrock_in + bedrock_out) / (ratio + 1)
    monthly = instance_per_hour * HOURS
    tokens = monthly / blended * 1_000_000
    per_second = tokens / (HOURS * 3600)
    return round(monthly), round(tokens / 1e9, 1), round(per_second)

print(break_even(6.88, 0.15, 0.60))      # gpt-oss-120b on p5.4xlarge:   (5022, 19.1, 7280)
print(break_even(1.861, 0.07, 0.30))     # gpt-oss-20b on g6e.xlarge:    (1359, 10.7, 4054)
print(break_even(10.49264, 0.72, 0.72))  # Llama 3.3 70B on g6e.12xlarge: (7660, 10.6, 4048)

Each instance has to sustain this load 24 hours a day to match Bedrock:

gpt-oss-120b on one H100: 19.1 billion tokens a month, about 7,300 tokens per second.
gpt-oss-20b on one L40S: 10.7 billion tokens a month, about 4,100 tokens per second.
Llama 3.3 70B on four L40S: 10.6 billion tokens a month, about 4,000 tokens per second.

Two adjustments make the bar higher:

Real traffic isn't flat. If your GPU is busy 40% of the time on average, it needs to handle 2.5 times the break-even rate at peak. For gpt-oss-120b, that is about 18,000 tokens per second.
If your workload can wait, compare against Batch or Flex. Both are half price, which doubles every break-even number above.

Whether one GPU can hit these rates depends on your prompts, context length, batch size, and serving engine. Measure it. The config at the end of this post sets up that test.

Worked example: the support agent from the readiness checklist

This example is hypothetical. The support agent from my AI agents readiness checklist handles 10,000 tasks a month, with 6 model calls per task, 8,000 input tokens and 1,000 output tokens per call:

Input: 480 million tokens a month.
Output: 60 million tokens a month.

On Bedrock:

gpt-oss-120b: 480 × $0.15 + 60 × $0.60 = $108 a month.
gpt-oss-20b: 480 × $0.07 + 60 × $0.30 = $51.60 a month.

Self-hosting the same agent on one p5.4xlarge costs $5,022 a month, about 46 times more. Its 540 million tokens are under 3% of the 19.1 billion the H100 needs to break even, so the agent would need about 35 times its current volume before that GPU paid for itself.

What costs does the per-hour price leave out?

Add these to the GPU-hour:

The EKS control plane: $0.10 per hour, $73 a month per cluster, if you don't already run one.
Model downloads. gpt-oss-120b weights are tens of gigabytes. Every new node pulls them. If that goes through a NAT gateway from S3 or the internet, you pay NAT processing on every pull. An S3 gateway endpoint makes the S3 part free; see Cut AWS NAT Gateway Costs.
Cold starts. Scaling GPU nodes to zero saves money but means minutes of waiting for a node, an image, and the weights before the first answer. Keeping one node warm puts you back on the 24-hour cost.
Quotas. EC2 limits GPU instances through vCPU quotas for G and P instances. Check them before you plan on p5 instances, since an increase request can take days.
People. Someone owns the serving engine upgrades, GPU drivers, autoscaling, and on-call. Bedrock includes that in the token price.

Savings Plans and EC2 Capacity Blocks lower the hourly price for steady GPU use, which moves the break-even point down. Price them for your term and Region before deciding.

When does self-hosting on EKS make sense?

Self-host when at least one of these is true:

Steady, high volume. Your measured traffic stays above the break-even rate for most of the day.
A model Bedrock doesn't have. A fine-tuned or niche open-weight model that isn't on Bedrock and can't be imported.
Control over the serving stack. You need a specific engine, quantization, or batching setup that a managed API doesn't expose.

Stay on Bedrock when:

Traffic is spiky or still growing. Paying per token means idle hours cost nothing.
You switch models often. Bedrock lets you change the model ID instead of resizing GPU node pools.
Nobody on the team wants GPU on-call.

A practical path is to prototype on Bedrock, measure real token volume for a month, then run the break-even function above with real numbers.

How do I test self-hosting on EKS?

Two pieces: a Karpenter NodePool that launches GPU nodes only when a GPU pod is waiting, and a vLLM Deployment that serves the model with an OpenAI-compatible API.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu-inference
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["g6e"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule
  limits:
    nvidia.com/gpu: 4
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 10m

The taint keeps other pods off GPU nodes. WhenEmpty removes a GPU node 10 minutes after its last pod leaves, so a test cluster doesn't bill GPU hours overnight. The limits block caps the pool at four GPUs, which stops a runaway Deployment from launching more.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gpt-oss-20b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gpt-oss-20b
  template:
    metadata:
      labels:
        app: gpt-oss-20b
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args: ["--model", "openai/gpt-oss-20b"]
          ports:
            - containerPort: 8000
          resources:
            limits:
              nvidia.com/gpu: 1

Pin the vLLM image to a specific version once your test works. Then replay a day of real prompts against both endpoints, measure sustained tokens per second at your latency target, and put that number next to the break-even rate.

FAQ

Is Amazon Bedrock cheaper than running an LLM on EC2?

Unless the GPU stays busy around the clock, yes. Bedrock charges only for tokens processed, while an EC2 GPU instance charges every hour it runs. A single H100 serving gpt-oss-120b has to sustain about 7,300 tokens per second, 24 hours a day, to match Bedrock's on-demand price for that model.

How much does it cost to run gpt-oss-120b on AWS?

On Bedrock, $0.15 per million input tokens and $0.60 per million output tokens on demand in US East, or half that with Batch or Flex. Self-hosted on one p5.4xlarge (one H100), $6.88 per hour, about $5,022 a month on demand.

What EC2 instance do I need for gpt-oss-20b?

One GPU with at least 16 GB of memory. A g6e.xlarge with one NVIDIA L40S (48 GB) costs $1.861 per hour on demand in US East and leaves room for long contexts and batching.

Can I scale GPU nodes to zero on EKS?

Yes. Karpenter removes empty nodes based on the NodePool's disruption policy and launches new ones when a GPU pod is pending. The trade-off is cold start time, since a new node has to boot, pull the container image, and load the model weights before serving.

Is SageMaker cheaper than EKS for self-hosting an LLM?

The break-even logic is the same. A SageMaker real-time endpoint also bills per instance-hour while it runs, so it has to stay as busy as an EKS GPU node to beat Bedrock's per-token price. Compare the instance-hour prices for your Region, then run the same calculation.

Does Bedrock have a cheaper option for steady high volume?

Yes. Bedrock's Reserved service tier commits to a fixed tokens-per-minute capacity, with a minimum of 100,000 input and 10,000 output tokens per minute, arranged through your AWS account team. If your volume is close to the self-hosting break-even point, get a Reserved quote before buying GPUs.

Does Bedrock offer the same open-weight models I can self-host?

Some of them. gpt-oss-120b, gpt-oss-20b, and Llama 3.3 70B are available on Bedrock as serverless models. For a model Bedrock doesn't list, check Bedrock Custom Model Import before deciding to self-host.

Sources

Deciding between Bedrock and your own GPUs? I run cost reviews and build EKS platforms for AI teams at DevOps Cloud Consult. Bring a month of token counts and I'll run the break-even for your workload.

Get one AWS cost fix every two weeks: subscribe on Substack.

EKS 1.37 Upgrade Checklist: What Breaks and How to Test It

Evgeny Anikiev — Thu, 22 Oct 2026 14:11:39 +0000

Seven changes that break Amazon EKS clusters going from 1.36 to 1.37, with a test command for each.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Last verified: October 22, 2026, against the Amazon EKS 1.37 documentation.

TL;DR: Amazon EKS has supported Kubernetes 1.37 since October 2, 2026. Most of the release is additive, but seven changes can break running workloads. Test each one with the command in its section, rehearse on a staging cluster, then upgrade the control plane, add-ons, and nodes in that order.

The seven changes:

SELinux mount labeling is on by default.
Static pods can no longer reference Secrets or ConfigMaps.
The kubelet refuses to start with deprecated cAdvisor flags.
eventRecordQPS: 0 now means "no limit".
EKS Auto Mode defaults new NodePools to Balanced consolidation.
HPA scale-to-zero is enabled by default.
kube-proxy IPVS mode is deprecated.

What is new in Kubernetes 1.37 on EKS?

Kubernetes v1.37 ("Garhwal") shipped upstream on August 26, 2026, with 67 enhancements: 16 graduated to Stable, 23 to Beta, 27 new Alpha features, and 1 deprecation/removal. Amazon EKS and EKS Distro followed on October 2, 2026, in all commercial and GovCloud (US) regions.

Headline items for EKS users:

Metrics API GA: metrics.k8s.io/v1.
DRA device taints and tolerations GA. EKS does not install a DRA driver for you.
HPA configurable tolerance GA: per-HPA tolerance for scale-up and scale-down.
HPA scale-to-zero Beta, enabled by default (HPAScaleToZero).
Pod Certificates and ClusterTrustBundles GA.
StatefulSet maxUnavailable re-enabled by default after a bug held it back in 1.36.

None of those break you on their own. The list below is where upgrades actually fail.

The EKS 1.37 breaking-change checklist

1. SELinux mount labeling is on by default (`SELinuxMount`)

What changed: When a Pod sets seLinuxOptions and its CSI driver advertises seLinuxMount: true, the kubelet now mounts the volume with -o context=<label> instead of recursively relabeling every file. It is faster, but if two Pods share a volume with different SELinux labels, change policies, or privilege levels, one of them can sit in ContainerCreating indefinitely.

Who is affected: Mostly Bottlerocket nodes (SELinux enforcing) and anyone setting seLinuxOptions explicitly.

How to test:

# Which CSI drivers opt into SELinux mount labeling?
kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount

# Which Pods set SELinux options?
kubectl get pods -A -o json | jq -r '
  .items[] | select(.spec.securityContext.seLinuxOptions != null
    or any(.spec.containers[]; .securityContext.seLinuxOptions != null))
  | "\(.metadata.namespace)/\(.metadata.name)"'

Fix: For workloads that share volumes across differently labeled Pods, opt out per Pod:

spec:
  securityContext:
    seLinuxChangePolicy: Recursive

2. Static pods can no longer reference Secrets or ConfigMaps

What changed: Static pods referencing API objects (secretRef, configMapRef, and similar) are now strictly prohibited, and the PreventStaticPodAPIReferences feature gate that let you opt out has been removed.

Who is affected: Self-managed node groups with custom static pod manifests in /etc/kubernetes/manifests (log shippers, security agents, node-local proxies). Managed node groups and Auto Mode rarely use static pods.

How to test:

# On a node (SSM session), look for API references in static pod manifests
sudo grep -rnE 'secretRef|configMapRef|secretKeyRef|configMapKeyRef|projected' \
  /etc/kubernetes/manifests/ 2>/dev/null

Fix: Convert those static pods to DaemonSets, or render the values into files on the host at bootstrap time.

3. Kubelet refuses to start with deprecated cAdvisor flags

What changed: The kubelet no longer starts if a deprecated cAdvisor flag is set (except --housekeeping-interval). It also drops three metrics: container_cpu_load_average_10s, container_cpu_load_d_average_10s, and container_tasks_state.

Who is affected: Custom AMIs, custom launch templates with --kubelet-extra-args, or Karpenter kubelet blocks that inherited old flags. EKS-optimized AMIs do not set them.

How to test:

# Inspect the live kubelet command line and config on a node
ps -o args= -C kubelet | tr ' ' '\n' | grep -E '^--'

# Grep dashboards/alerts for the removed metrics
grep -rnE 'container_cpu_load_average_10s|container_cpu_load_d_average_10s|container_tasks_state' \
  ./dashboards ./alerts ./prometheus-rules

Fix: Remove deprecated flags from user data and launch templates. Rewrite dashboards and alerts that use the dropped metrics.

4. `eventRecordQPS: 0` now means "no limit"

What changed: Before 1.37, eventRecordQPS: 0 meant the default of 5 events/second. Now it means unlimited, so a noisy CrashLoopBackOff node can flood the API server with events.

How to test:

kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig.eventRecordQPS'

Fix: If you set 0 explicitly, change it to 5 to keep the old behavior. EKS-optimized AMIs do not set this field.

5. EKS Auto Mode: default consolidation policy is now `Balanced`

What changed: New Auto Mode NodePools that don't set consolidationPolicy default to Balanced instead of WhenEmptyOrUnderutilized. The built-in general-purpose and system NodePools also use Balanced, and you cannot change that on them.

Why it matters: Bin-packing behavior and node churn change. Cost dashboards may move; PodDisruptionBudget pressure patterns change.

How to test:

kubectl get nodepools -o custom-columns=NAME:.metadata.name,POLICY:.spec.disruption.consolidationPolicy

Any row showing <none> will pick up the new default.

Fix: Pin the old behavior explicitly on your own NodePools and target them from workloads that need it:

spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

6. HPA scale-to-zero is enabled by default

What changed: HPAScaleToZero is Beta and on by default. An HPA with minReplicas: 0 on Object or External metrics can now drive a Deployment to zero replicas.

Who is affected: Teams that templated minReplicas: 0 by accident (Helm defaults, copy-paste) where it was previously rejected or ignored. EKS does not install a metrics adapter, so this only applies if you run one (KEDA, Prometheus Adapter, CloudWatch adapter).

How to test:

kubectl get hpa -A -o json | jq -r '
  .items[] | select(.spec.minReplicas == 0)
  | "\(.metadata.namespace)/\(.metadata.name)"'

Fix: Set minReplicas: 1 anywhere zero is not intentional.

7. kube-proxy IPVS mode is deprecated

What changed: kube-proxy in ipvs mode now logs a deprecation warning on startup. Upstream plans to disable it by default around v1.40 and remove it around v1.43. Nothing breaks in 1.37, but this is the release to plan your move to nftables (or iptables), which now talks to the kernel through netlink instead of the nft CLI.

How to test:

kubectl -n kube-system get cm kube-proxy-config -o yaml | grep -i mode

Also on the radar

cgroup v1: failCgroupV1 has defaulted to true since 1.35. The temporary override still works in 1.37, but removal is coming. Move any remaining cgroup v1 nodes (old AL2 custom AMIs) to AL2023 or Bottlerocket.
kube-dns: No new packages expected after v1.40. EKS uses CoreDNS by default, so check that you are not running a legacy kube-dns.
kubectl run -f: The --filename/-f flag is deprecated. Fix scripts that use it.
Kubelet logs its full effective config at startup. Useful for verifying the items above, but check that your log pipeline does not alert on it.

How to test an EKS 1.37 upgrade safely

Step 1: Run EKS Upgrade Insights

aws eks list-insights --cluster-name my-cluster \
  --filter '{"categories":["UPGRADE_READINESS"]}'

aws eks describe-insight --cluster-name my-cluster --id <insight-id>

Insights flag deprecated API usage seen in audit logs and add-on/version-skew problems. Treat any ERROR as a blocker.

Step 2: Scan manifests for deprecated APIs

# Live cluster
kubent

# Helm charts and GitOps repos
pluto detect-files -d ./k8s --target-versions k8s=v1.37.0
pluto detect-helm -o wide --target-versions k8s=v1.37.0

Step 3: Check add-on compatibility

aws eks describe-addon-versions --kubernetes-version 1.37 \
  --query 'addons[].{name:addonName,default:addonVersions[?compatibilities[?defaultVersion==`true`]]|[0].addonVersion}' \
  --output table

Also check self-managed controllers: AWS Load Balancer Controller, Karpenter, cert-manager, external-dns, Istio/Cilium, the EBS/EFS CSI drivers, and your service mesh. Each publishes a supported-Kubernetes matrix; confirm 1.37 is on it.

Step 4: Rehearse on a staging clone

Create a staging cluster from the same IaC at 1.36, deploy production manifests, then upgrade it:

eksctl upgrade cluster --name staging --version 1.37 --approve
# or Terraform: bump cluster_version = "1.37" and apply

Then run the seven checks above, your smoke tests, and a synthetic load test. Watch for Pods stuck in ContainerCreating (SELinux), nodes failing to join (kubelet flags), and event volume spikes (eventRecordQPS).

Step 5: Upgrade production in the right order

Control plane: one minor version at a time (1.36 → 1.37 only).
EKS add-ons: VPC CNI, CoreDNS, kube-proxy, EBS CSI, Pod Identity Agent.
Data plane: managed node groups (rolling), Karpenter (drift), or Auto Mode (automatic).
Self-managed controllers.

Step 6: Post-upgrade verification

kubectl get nodes -o wide                        # all nodes Ready on v1.37
kubectl get pods -A | grep -vE 'Running|Completed'
kubectl get events -A --sort-by=.lastTimestamp | tail -50
kubectl get apiservices | grep -v True          # unhealthy aggregated APIs

EKS 1.37 upgrade checklist (copy-paste)

[ ] EKS Upgrade Insights: zero ERROR findings
[ ] kubent / pluto clean against v1.37
[ ] All EKS add-ons on a 1.37-compatible version
[ ] Third-party controllers confirm 1.37 support
[ ] SELinux: CSI drivers and seLinuxOptions Pods audited; seLinuxChangePolicy: Recursive where needed
[ ] Static pods: no Secret/ConfigMap references
[ ] Kubelet: no deprecated cAdvisor flags; dashboards don't use dropped metrics
[ ] eventRecordQPS: 0 replaced with 5 where set
[ ] Auto Mode NodePools: consolidationPolicy set explicitly
[ ] HPAs: no accidental minReplicas: 0
[ ] kube-proxy: IPVS migration plan logged
[ ] No cgroup v1 nodes left
[ ] Staging upgrade rehearsed, smoke + load tests passed
[ ] Rollback plan: blue/green node groups ready (control plane cannot be downgraded)

FAQ

When did Amazon EKS release Kubernetes 1.37?

EKS and EKS Distro added Kubernetes 1.37 on October 2, 2026, about five weeks after the upstream release on August 26, 2026.

Can I downgrade an EKS cluster from 1.37 to 1.36?

No. EKS control plane upgrades are one-way. Your rollback options are at the node level (keep a 1.36 node group until 1.37 nodes are proven) or a blue/green cluster migration.

Can I skip from EKS 1.35 straight to 1.37?

No. The control plane upgrades one minor version at a time: 1.35 → 1.36 → 1.37. Nodes may lag the control plane within the supported skew, but plan for both hops.

What is the biggest risk when upgrading to EKS 1.37?

For most clusters it is SELinux mount labeling on Bottlerocket nodes, followed by custom kubelet configuration (deprecated cAdvisor flags and eventRecordQPS: 0). Auto Mode users should check the Balanced consolidation default.

Does EKS 1.37 remove any APIs?

The upstream release lists one deprecation/removal. The practical removals are behavioral: the PreventStaticPodAPIReferences gate is gone and deprecated kubelet cAdvisor flags now stop the kubelet from starting. Still run kubent or pluto to catch older deprecated APIs you never migrated.

How long is EKS 1.37 supported?

EKS gives each version 14 months of standard support followed by 12 months of extended support. Check the official EKS Kubernetes version lifecycle page for exact dates.

Sources

Planning an EKS upgrade and want a second pair of eyes? I help teams run zero-downtime Kubernetes upgrades on AWS at DevOps Cloud Consult.

Cut AWS NAT Gateway Costs: 7 Fixes for Platform Teams

Evgeny Anikiev — Thu, 22 Oct 2026 14:10:21 +0000

Find what flows through your NAT gateways, then move it to free or cheaper paths. Prices, break-even math, and a command for each fix.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. Prices verified October 22, 2026, against AWS public pricing pages (US East list prices; check your Region).

TL;DR: A NAT gateway charges $0.045 per hour per AZ plus $0.045 for every GB it processes, including traffic to S3, ECR, and other AWS services. Most of that traffic doesn't need a NAT at all. Measure what flows through it first, then move AWS-bound traffic to VPC endpoints and keep the rest in the same AZ.

The seven fixes, roughly in order of savings:

Add free S3 and DynamoDB gateway endpoints.
Add interface endpoints for high-volume AWS APIs (ECR, CloudWatch Logs, STS).
Stop sending traffic across AZs to reach a NAT gateway.
Keep Kubernetes service traffic in-zone.
Send IPv6 egress through an egress-only internet gateway.
Release idle public IPv4 addresses.
Show each team its own NAT and data transfer bill.

What is an AWS NAT gateway?

An AWS NAT gateway is a managed service that lets resources in private subnets open connections to the internet and to public AWS service endpoints, while blocking connections coming in from outside. AWS bills it by the hour and by every GB it processes, which is why it shows up on so many networking bills.

How much does an AWS NAT gateway cost?

An AWS NAT gateway costs $0.045 per NAT gateway-hour and $0.045 per GB of data processed, at the US East list price AWS uses in its own pricing example. Partial hours bill as full hours, and the per-GB charge applies "regardless of the traffic's source or destination." Internet egress is billed on top.

The rates that matter for this playbook (US East, list price):

NAT gateway (zonal): $0.045 per hour, about $32.85 per month per gateway.
NAT gateway (regional mode): $0.045 per hour per AZ it runs in. Three AZs means three NAT gateway-hours every hour.
NAT data processing: $0.045 per GB, both directions, any destination.
Internet data transfer out: $0.09 per GB in the first tier, after 100 GB free per month across your account.
Gateway VPC endpoint (S3, DynamoDB): no hourly or data processing charge.
Interface VPC endpoint (PrivateLink): $0.01 per hour per AZ, plus $0.01 per GB processed.
Public IPv4 address: $0.005 per hour, in use or idle (about $3.65 per month).
Cross-AZ traffic inside a Region: $0.01 per GB, charged on each side of the transfer.

The processing fee is where the money goes. A node pulling a 1 GB container image from ECR through a NAT gateway pays $0.045 for that pull. Multiply that by hundreds of nodes scaling up and down every day. That traffic never needed to leave AWS.

How do I find what is using my NAT gateway?

Start with two numbers: how much each NAT gateway processes, and where those bytes go.

Cost Explorer. Filter Service = EC2-Other and group by Usage Type. Look for NatGateway-Bytes, NatGateway-Hours, and DataTransfer-Regional-Bytes (cross-AZ).

Cost and Usage Report (CUR) in Athena. Rank NAT gateways by cost:

SELECT line_item_resource_id,
       line_item_usage_type,
       ROUND(SUM(line_item_unblended_cost), 2) AS cost
FROM cur
WHERE line_item_usage_type LIKE '%NatGateway%'
  AND line_item_usage_start_date >= date_add('day', -30, current_date)
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 20;

VPC Flow Logs on the NAT gateway ENI. This tells you where the bytes go. Enable flow logs on the NAT's network interface, query them in Athena, and rank destinations:

SELECT dstaddr,
       ROUND(SUM(bytes) / 1e9, 1) AS gb
FROM vpc_flow_logs
WHERE interface_id = 'eni-0123456789abcdef0'
  AND day >= '2026/10/01'
GROUP BY dstaddr
ORDER BY gb DESC
LIMIT 25;

Match the top destination IPs against AWS's published ranges to see which ones are AWS services:

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq -r '.prefixes[] | select(.region=="us-east-1") | "\(.ip_prefix) \(.service)"' \
  > aws-ranges.txt

On container platforms, expect S3 (container image layers, artifacts, logs), ECR, CloudWatch Logs, and STS near the top. All of those can bypass the NAT.

How to reduce NAT gateway costs: seven fixes

1. Add S3 and DynamoDB gateway endpoints (free)

What it does: A gateway endpoint adds a route so traffic to S3 or DynamoDB stays on the AWS network and skips the NAT. AWS charges nothing for it, hourly or per GB.

Why it matters for containers: ECR stores image layers in S3. Without an S3 gateway endpoint, every layer download pays the NAT processing fee.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-0aaa rtb-0bbb rtb-0ccc

Attach it to every private route table, then repeat with com.amazonaws.us-east-1.dynamodb if you use DynamoDB. It costs nothing and needs no application changes, so ship it first.

2. Add interface endpoints for high-volume AWS APIs

What it does: An interface endpoint (PrivateLink) puts a private IP for an AWS service inside your subnets. Traffic costs $0.01 per GB at the endpoint instead of $0.045 per GB at the NAT.

Break-even: Each endpoint costs about $7.30 per AZ per month. You save $0.035 per GB moved off the NAT, so an endpoint pays for itself at roughly 210 GB per month per AZ. For a three-AZ VPC, that is about 630 GB per month per service.

Good candidates for container platforms:

ecr.api and ecr.dkr (image manifests and auth; layers go through S3)
logs (CloudWatch Logs, often the noisiest)
sts (IRSA and EKS Pod Identity token calls)
sqs, kinesis-streams, secretsmanager, depending on your workload

Use your flow log ranking from the queries above to decide. Don't create endpoints for services that move a few GB a month; they will cost more than they save.

3. Stop sending traffic across AZs to reach a NAT gateway

What it does: If private subnets in AZ b and AZ c route to a single NAT gateway in AZ a, every byte pays cross-AZ transfer on top of NAT processing.

The math: Two extra zonal NAT gateways cost about $65.70 per month. Cross-AZ traffic costs $0.02 per GB counting both sides. Above roughly 3.3 TB per month of cross-AZ NAT traffic, one NAT per AZ is cheaper, and it removes a single point of failure too.

Check your route tables:

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'RouteTables[].{rt:RouteTableId,subnets:Associations[].SubnetId,nat:Routes[?NatGatewayId].NatGatewayId}' \
  --output json

Each private subnet's route table should point at the NAT gateway in the same AZ.

Or use a regional NAT gateway. Since November 2025, a NAT gateway can run in regional availability mode: one gateway that expands into each AZ where you have workloads, with no public subnet per AZ and no per-AZ route table edits. It bills per AZ-hour, so it costs the same as one zonal NAT per AZ. AWS's launch post lists two caveats. Expansion into a new AZ takes 15 to 20 minutes on average, and up to 60. Until it finishes, traffic from that AZ goes to another AZ's NAT and pays cross-AZ charges.

4. Keep Kubernetes service traffic in-zone

Cross-AZ charges don't only come from NAT routing. Service-to-service traffic in EKS crosses AZs all the time because kube-proxy spreads connections across all endpoints by default.

On Kubernetes 1.33 and later, ask for zone-local routing per Service:

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  trafficDistribution: PreferClose
  selector:
    app: orders
  ports:
    - port: 80
      targetPort: 8080

PreferClose sends traffic to endpoints in the client's zone when they exist and falls back to others when they don't. Pair it with topology spread constraints so each zone has replicas to receive the traffic. This traffic never touches the NAT, so it won't show up in your NAT numbers. Size it with the DataTransfer-Regional-Bytes usage type in Cost Explorer. If you're also planning an upgrade, see my EKS 1.37 upgrade checklist.

5. Send IPv6 egress through an egress-only internet gateway

An egress-only internet gateway lets IPv6 workloads reach the internet without a NAT gateway, so there is no NAT hourly or processing charge on that traffic. Standard data transfer out still applies. If your EKS cluster runs in IPv6 mode, or your dependencies (package registries, SaaS APIs) support IPv6, route ::/0 to an egress-only internet gateway and keep the NAT for IPv4-only destinations.

6. Release idle public IPv4 addresses

Every public IPv4 address costs $0.005 per hour whether it is in use or not. Find Elastic IPs that aren't attached to anything:

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId,Tags]' \
  --output table

VPC IPAM's Public IP Insights view shows every public IPv4 in the account, including ones attached to load balancers and instances you may have forgotten.

7. Show each team its own network bill

Platform teams own the VPC, so NAT and data transfer costs usually land in one shared bucket that nobody feels responsible for. Split it:

Tag NAT gateways and endpoints with the owning team or environment and activate those tags as cost allocation tags.
Group flow logs by source subnet (or by pod CIDR in EKS) to attribute NAT bytes to the team that generated them.
Publish a monthly showback: GB through NAT per team, top destinations, and which fix from this list would remove it.

A monthly report line such as "your service pulled 4 TB of images through the NAT; an S3 gateway endpoint makes that free" gives a team a specific action to take.

Worked example: an EKS cluster across three AZs

This is an illustrative model using the list prices above, not a client bill. Assume three zonal NAT gateways process 20 TB (20,480 GB) per month:

15 TB to S3 (image layers, artifacts)
2 TB to CloudWatch Logs
3 TB to the internet

Before:

NAT hours: 3 × $0.045 × 730 = $98.55
NAT processing: 20,480 GB × $0.045 = $921.60
Total NAT cost: about $1,020 per month

After fixes 1 and 2:

S3 moves to a gateway endpoint: $0
CloudWatch Logs moves to an interface endpoint: 2,048 GB × $0.01 + 3 AZs × $7.30 = $42.38
NAT keeps only internet traffic: 3,072 GB × $0.045 + $98.55 = $236.79
Total: about $279 per month, a 73% cut

Internet data transfer out (about $276 at $0.09 per GB) is the same in both cases; endpoints don't change egress pricing. Your traffic mix will differ, so run the flow log queries above to get your own split before estimating savings.

NAT gateway cost checklist (copy-paste)

[ ] Cost Explorer: NatGateway-Bytes and DataTransfer-Regional-Bytes baselined
[ ] Flow logs enabled on every NAT ENI; top 25 destinations identified
[ ] S3 gateway endpoint attached to every private route table
[ ] DynamoDB gateway endpoint attached (if used)
[ ] Interface endpoints for AWS services above ~210 GB per AZ per month
[ ] Each private subnet routes to a NAT in its own AZ (or regional NAT in automatic mode)
[ ] Kubernetes Services with heavy east-west traffic use trafficDistribution: PreferClose
[ ] IPv6 egress goes through an egress-only internet gateway
[ ] No unattached Elastic IPs
[ ] NAT gateways and endpoints tagged; monthly showback per team

FAQ

Why is my AWS NAT gateway bill so high?

Usually because AWS-bound traffic (S3, ECR image layers, CloudWatch Logs) goes through the NAT and pays $0.045 per GB in processing. Container platforms with frequent node scaling pull large images many times a day. Enable flow logs on the NAT ENI to confirm where the bytes go.

Does a NAT gateway charge for traffic to S3?

Yes, if there is no S3 gateway endpoint. The NAT processing fee applies to all traffic it handles, regardless of destination. An S3 gateway endpoint is free and removes that traffic from the NAT completely.

Is a regional NAT gateway cheaper than zonal NAT gateways?

Not on price. Regional mode bills $0.045 per hour for each AZ it runs in, the same as one zonal NAT per AZ, and the same per-GB fee. It saves operational work (no public subnet per AZ, no route table edits) and helps avoid cross-AZ routing once it has expanded into every AZ you use.

Should I replace NAT gateways with NAT instances?

For small or non-production environments, a NAT instance on a small Graviton instance (for example with the open-source fck-nat AMI) avoids the per-GB processing fee. You take on patching, scaling, and failover yourself. For production, fix the traffic first with endpoints; the remaining NAT bill is often small enough that the managed gateway is worth it.

VPC endpoint vs NAT gateway: which is cheaper for AWS service traffic?

A gateway endpoint (S3, DynamoDB) is always cheaper because it is free. An interface endpoint costs $0.01 per GB plus about $7.30 per AZ per month, against $0.045 per GB through a NAT. It pays for itself above roughly 210 GB per month per AZ for that service.

How much does cross-AZ data transfer cost on AWS?

Traffic between Availability Zones in the same Region is billed at $0.01 per GB on each side, so $0.02 per GB in total. It appears as DataTransfer-Regional-Bytes in Cost Explorer. Same-AZ NAT routing and zone-aware Kubernetes Services reduce it.

How much does a NAT gateway cost per month?

About $32.85 per month per zonal gateway in hourly charges at US East list price, before data. Add $0.045 for every GB processed. A three-AZ setup starts at about $98.55 per month before any traffic.

Sources

Want a second pair of eyes on your AWS network bill? I run NAT and data transfer cost reviews for platform teams at DevOps Cloud Consult.

Migrating AI Agents to AWS: 15 Bedrock and AgentCore Checks

Evgeny Anikiev — Thu, 22 Oct 2026 14:04:14 +0000

A readiness assessment for AI teams moving agents from a prototype or another provider to Amazon Bedrock and AgentCore. Score yourself out of 30, with the evidence, AWS service, and command for each check.

By Evgeny Anikiev, AWS-certified DevOps engineer with 10+ years running build automation, CI/CD, and Kubernetes in production. AWS service details verified October 22, 2026.

TL;DR: Score 15 checks from 0 to 2. They cover cost per task, evaluations, model access, quotas, AgentCore Runtime, tools, identity, data, observability, and rollback. A total of 24 or more means you can move production traffic. From 15 to 23, fix the zeros and run a shadow or canary pilot. Below 15, keep the agent where it is and build the foundations first.

Three changes from the past year that older checklists miss:

Amazon Bedrock retired its Model Access page in October 2025. Serverless foundation models are now enabled by default in commercial Regions, so restricting models is your job, done with IAM and service control policies.
AgentCore Policy became generally available on March 3, 2026. It checks every tool call that passes through AgentCore Gateway against Cedar rules.
AgentCore Evaluations became generally available on March 31, 2026, with 13 built-in evaluators and online scoring of live traces.

What is an AI migration readiness assessment?

An AI migration readiness assessment is a review, done before production traffic moves, of whether an AI team can run its agents on a new platform safely and within budget. For AWS, that means checking cost per task, evaluation baselines, model governance, Bedrock quotas, AgentCore hosting, tool access, identity, data handling, monitoring, and rollback on Amazon Bedrock and Amazon Bedrock AgentCore.

It follows the six perspectives of the AWS Cloud Adoption Framework (Business, People, Governance, Platform, Security, Operations), applied to agents instead of servers. Typical starting points are an agent calling the OpenAI or Anthropic API directly, a LangGraph or CrewAI service in a container, or a notebook prototype that leadership now wants in front of customers.

How do you score it?

Give each check a score:

0: missing, or exists only in someone's head.
1: exists, but is incomplete, untested, or out of date.
2: written down, owned by a named person, and tested.

Add the scores. The maximum is 30.

24 to 30, ready: move production traffic in stages.
15 to 23, pilot: fix every 0, then run the agent in shadow mode or on a small share of traffic.
0 to 14, not ready: keep the current setup and build the foundations.

One rule overrides the total: a 0 on check 2 (evaluation baseline), check 11 (identity and tool policy), or check 15 (rollback) blocks production at any score. Without a baseline you can't tell whether the move made answers worse. Without tool policy an agent can call anything its credentials allow. Without rollback a bad model or prompt change stays live until someone fixes it by hand.

A copy-paste scoring sheet:

check,perspective,score,evidence,owner
01 cost per task,business,,,
02 evaluation baseline,business,,,
03 owners and on-call,people,,,
04 framework and AgentCore skills,people,,,
05 model access controls,governance,,,
06 cost attribution,governance,,,
07 quotas and inference routing,platform,,,
08 runtime hosting,platform,,,
09 tools behind Gateway,platform,,,
10 memory and RAG data,platform,,,
11 identity and tool policy,security,,,
12 data protection and network,security,,,
13 observability and logging,operations,,,
14 online evaluations,operations,,,
15 rollout and rollback,operations,,,

Business

1. Do you know the cost per task?

Agents bill per token, and one user request often makes several model calls. Measure input and output tokens per task on your current setup, then price them on Bedrock. Score 2 if finance has seen a cost per task and a monthly estimate at expected volume.

def cost_per_task(calls, in_tokens, out_tokens, in_price, out_price, cached=0, cache_discount=0.9):
    """Prices are USD per million tokens. cached = input tokens per call served from the prompt cache."""
    uncached = in_tokens - cached
    per_call = (uncached * in_price
                + cached * in_price * (1 - cache_discount)
                + out_tokens * out_price) / 1_000_000
    return calls * per_call

# Example prices, not a quote: $3 input and $15 output per million tokens.
print(round(cost_per_task(6, 8000, 1000, 3, 15), 3))               # 0.234
print(round(cost_per_task(6, 8000, 1000, 3, 15, cached=6000), 3))  # 0.137

The numbers that move this figure:

Prompt caching: AWS says it can cut costs by up to 90% on supported models. Cache-read discounts differ by model, and some models charge extra for cache writes, so test with your real prompts. It works only on on-demand inference.
Batch inference: 50% lower than on-demand for select models, for work that can wait.
Service tiers: Flex costs 50% less than Standard for non-urgent requests. Priority costs 75% more for the fastest responses.

2. Do you have an evaluation baseline from the current setup?

Build a golden set of real requests with expected answers or grading rules, and score your current agent on it before you change anything. Run the same set on Bedrock after the move. Score 2 if the set has at least a few hundred cases, covers your main task types, and has a pass threshold the product owner agreed to. A 0 here blocks production.

People

3. Are owners and on-call named?

Someone owns the prompts, someone owns the tools and their APIs, and someone gets paged when the agent fails at 2 a.m. Score 2 if all three are named and the on-call runbook covers model errors, throttling, and tool failures.

4. Can the team build and run on AgentCore?

AgentCore Runtime is framework-agnostic. AWS documents agents built with Strands Agents, LangGraph, and CrewAI running on it, so most teams keep their code. Score 2 if at least two engineers have deployed a test agent to AgentCore Runtime and called it with real credentials.

Governance

5. Who controls which models can be called?

Since October 2025, serverless Bedrock models are enabled by default. Anthropic models still need a one-time use-case form, which covers member accounts when submitted from the management account. Restrict models with a service control policy. Score 2 if an allow-list exists and is enforced at the organization level.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedBedrockModels",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "NotResource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.*",
        "arn:aws:bedrock:*::foundation-model/amazon.nova-*",
        "arn:aws:bedrock:*:*:inference-profile/us.anthropic.*",
        "arn:aws:bedrock:*:*:inference-profile/us.amazon.nova-*"
      ]
    }
  ]
}

Replace the model families with your approved list. The Converse API uses the same bedrock:InvokeModel permission, so this policy covers it too.

6. Can you split the Bedrock bill by team and agent?

Create an application inference profile per agent or team, tag it, and activate the tags as cost allocation tags. Calls made through the profile then show up per tag in Cost Explorer. Score 2 if every production agent calls models through a tagged profile.

Platform

7. Are quotas and inference routing sized?

Bedrock quotas are tokens per minute and requests per minute, set per model and per Region. Cross-Region inference spreads load across Regions in one geography (geo) or worldwide (global), and not every model supports global. Score 2 if you have compared peak tokens per minute against your quotas in Service Quotas, requested increases in advance, and chosen geo or global routing to match your data residency rules. AWS gives priority on increases to accounts that already use their current quota, so build up real traffic before asking.

8. Is the hosting model chosen?

AgentCore Runtime runs each session in its own microVM with separate compute, memory, and filesystem, and wipes it when the session ends. A session ends after 15 minutes of inactivity by default and lives up to 8 hours. For longer jobs, AgentCore Runtime instances run up to 14 days. Score 2 if your longest task fits these limits and you have load-tested cold starts at expected concurrency.

9. Are tools exposed through AgentCore Gateway?

Gateway turns existing APIs and Lambda functions into MCP tools that agents can discover and call. It is also where AgentCore Policy checks each call. Score 2 if every tool the agent can call goes through Gateway, and none are hard-coded HTTP calls inside the agent.

10. Are memory and RAG data planned?

Decide what goes into AgentCore Memory (conversation history and long-term facts per user) and what goes into a Bedrock Knowledge Base (documents for retrieval). For each, write down the data source, refresh schedule, retention period, and who may read it. Score 2 if the retrieval quality on your golden set matches or beats the current setup.

Security

11. Are identity and tool policy in place?

Use AgentCore Identity for inbound authentication (who may call the agent) and for outbound credentials to tools, so no API keys live in agent code or environment variables. Add AgentCore Policy rules on the Gateway, for example limiting a refund tool to amounts below a threshold. Score 0 if the agent holds long-lived keys or can call tools without a policy check. A 0 here blocks production.

12. Are data protection and network paths decided?

AWS states that Bedrock does not use your prompts and completions to train AWS models or share them with model providers. Your security team will still ask about three more things:

private connectivity through AWS PrivateLink endpoints for Bedrock and AgentCore
Amazon Bedrock Guardrails for content filters and PII redaction
whether cross-Region inference fits your data residency rules

Score 2 if security has signed off on all three in writing.

Operations

13. Can you see what the agent did?

AgentCore Observability records traces of each step: model calls, tool calls, and latency. Bedrock model invocation logging is disabled by default. Turn it on for the audit trail, and treat the logs as sensitive, because they contain full prompts and responses.

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/bedrock/model-invocations",
      "roleArn": "arn:aws:iam::111122223333:role/BedrockInvocationLogging"
    },
    "textDataDeliveryEnabled": true
  }'

Score 2 if traces, invocation logs, and alarms on errors, throttling, and latency exist in the production account.

14. Are evaluations running on live traffic?

AgentCore Evaluations samples live traces and scores them with built-in evaluators for response quality, safety, task completion, and tool use, or with your own. Score 2 if online evaluation runs on production traffic with an alarm when scores drop below the threshold from check 2.

15. Can you roll back a model, prompt, or agent change?

Pin model versions instead of relying on whatever is newest. Deploy agent changes as new AgentCore Runtime versions behind an endpoint, so you can move traffic back. Track Bedrock model end-of-life dates. Score 2 only if you rehearsed a rollback in a non-production account. A 0 here blocks production.

Worked example: a support agent leaving a direct API setup

This example is hypothetical, built to show the scoring. A team runs a LangGraph customer support agent in a container, calling a model provider's API directly with a key in an environment variable. It handles about 10,000 tasks a month. Its first scoring pass:

Business (checks 1–2): 1, 0. Token counts exist, but there is no golden set.
People (3–4): 1, 0. One engineer owns everything, and no one has used AgentCore.
Governance (5–6): 0, 0. No model allow-list, no cost tags.
Platform (7–10): 1, 1, 0, 1. Quotas not checked against peak, tools called directly from code.
Security (11–12): 0, 1. API keys in environment variables, no PrivateLink yet.
Operations (13–15): 1, 0, 0. Application logs only, no evaluations, no rollback path.

Total: 7 out of 30, with blockers on checks 2, 11, and 15. A sensible next four to six weeks:

Build a golden set from past tickets and score the current agent.
Deploy the same LangGraph code to AgentCore Runtime in a non-production account.
Move the agent's tools behind Gateway with Identity and a first Policy rule.
Add the model allow-list and a tagged application inference profile.
Run the golden set on both setups, then score all 15 checks again.

With the example prices from check 1, caching 6,000 of 8,000 input tokens per call would take the cost per task from about $0.23 to about $0.14, or from about $2,340 to about $1,370 a month at 10,000 tasks. Confirm with your model's real cache pricing.

FAQ

Do I need AgentCore to use Amazon Bedrock?

No. You can call Bedrock models from any application with the Converse or InvokeModel APIs. AgentCore adds hosting, memory, tool gateway, identity, policy, observability, and evaluations for agents, and works with models from Bedrock or other providers.

Can I run LangGraph or CrewAI agents on AgentCore?

Yes. AgentCore Runtime is framework-agnostic, and AWS documents agents built with Strands Agents, LangGraph, and CrewAI running on it.

Does Amazon Bedrock train on my prompts?

AWS states that Bedrock does not use your prompts and completions to train AWS models and does not share them with third-party model providers.

Do I still need to request model access in Bedrock?

Not for most models. Since October 2025, serverless models are enabled by default in commercial Regions. Anthropic models need a one-time use-case form. Some AWS Marketplace models need a subscription, which Bedrock tries to create on first use.

How long can an AgentCore Runtime session run?

Up to 8 hours per session on microVMs, with a default idle timeout of 15 minutes. AgentCore Runtime instances support work up to 14 days.

How do I get higher Bedrock quotas?

Request increases in Service Quotas per model and Region, and use cross-Region inference profiles to spread load. AWS gives priority to accounts that already use their existing quota.

What is the difference between AgentCore Policy and Bedrock Guardrails?

Policy controls which tool calls an agent may make, with Cedar rules checked at AgentCore Gateway. Guardrails filter model inputs and outputs, for example blocking topics or redacting PII.

Sources

Moving an agent to Bedrock and AgentCore? I run readiness assessments and build the AWS foundations for AI teams at DevOps Cloud Consult: landing zone, model access controls, observability, and cost tracking. If you scored under 24, that is the work I can help with.

DEV Community: Evgeny Anikiev

Bedrock Managed Agents vs AgentCore: Which Should Run Your Agents?

What is Amazon Bedrock Managed Agents?

What is Amazon Bedrock AgentCore?

Bedrock Managed Agents vs AgentCore: side by side

What can't Bedrock Managed Agents do yet?

How do I start a Bedrock Managed Agents session?

1. The session role

2. Client permissions

3. Create the session and send a message

How much do Bedrock Managed Agents and AgentCore cost?

Should I use Bedrock Managed Agents or AgentCore?

FAQ

Related reading

Sources

Track Amazon Bedrock Costs per Team: 3 Methods Compared

Why doesn't my Bedrock bill show which team spent the money?

Which Bedrock cost allocation method should I use?

Method 1: How do I allocate Bedrock costs by IAM role?

Method 2: How do I tag Bedrock usage with application inference profiles?

Method 3: How do I track Bedrock costs with Projects?

How do I set a Bedrock budget per team?

What can't Bedrock cost allocation tell you?

Worked example: three teams in one Bedrock account

FAQ

Related reading

Sources

Bedrock vs Self-Hosted LLMs on EKS: The Break-Even Math

Which costs less: Amazon Bedrock or self-hosting on EKS?

What does each option cost?

Bedrock: per token

Self-hosted: per GPU-hour

Where is the break-even point?

Worked example: the support agent from the readiness checklist

What costs does the per-hour price leave out?

When does self-hosting on EKS make sense?

How do I test self-hosting on EKS?

FAQ

Related reading

Sources

EKS 1.37 Upgrade Checklist: What Breaks and How to Test It

What is new in Kubernetes 1.37 on EKS?

The EKS 1.37 breaking-change checklist

1. SELinux mount labeling is on by default (SELinuxMount)

2. Static pods can no longer reference Secrets or ConfigMaps

3. Kubelet refuses to start with deprecated cAdvisor flags

4. eventRecordQPS: 0 now means "no limit"

5. EKS Auto Mode: default consolidation policy is now Balanced

6. HPA scale-to-zero is enabled by default

7. kube-proxy IPVS mode is deprecated

Also on the radar

How to test an EKS 1.37 upgrade safely

Step 1: Run EKS Upgrade Insights

Step 2: Scan manifests for deprecated APIs

Step 3: Check add-on compatibility

Step 4: Rehearse on a staging clone

Step 5: Upgrade production in the right order

Step 6: Post-upgrade verification

EKS 1.37 upgrade checklist (copy-paste)

FAQ

Related reading

Sources

Cut AWS NAT Gateway Costs: 7 Fixes for Platform Teams

What is an AWS NAT gateway?

How much does an AWS NAT gateway cost?

How do I find what is using my NAT gateway?

How to reduce NAT gateway costs: seven fixes

1. Add S3 and DynamoDB gateway endpoints (free)

2. Add interface endpoints for high-volume AWS APIs

3. Stop sending traffic across AZs to reach a NAT gateway

4. Keep Kubernetes service traffic in-zone

5. Send IPv6 egress through an egress-only internet gateway

6. Release idle public IPv4 addresses

7. Show each team its own network bill

Worked example: an EKS cluster across three AZs

NAT gateway cost checklist (copy-paste)

FAQ

Related reading

Sources

Migrating AI Agents to AWS: 15 Bedrock and AgentCore Checks

1. SELinux mount labeling is on by default (`SELinuxMount`)

4. `eventRecordQPS: 0` now means "no limit"

5. EKS Auto Mode: default consolidation policy is now `Balanced`