Amazon Bedrock AgentCore runtime instances GA: IAM cost allocation, temporal policies, and rate limiting

AWS just handed platform teams a persistent tenant: Bedrock AgentCore runtime instances are GA and they behave like first‑class compute. These are not ephemeral serverless invocations — AgentCore RIs are backed by persistent compute (not short‑lived function invocations), can be configured with GPUs, support multi‑agent sessions that persist for days, and now surface IAM cost allocation, temporal authorization policies, and rate limiting for Bedrock runtime traffic. That combination is useful and dangerous in equal measure.

The useful part is obvious: predictable latency, GPU options, and long sessions make Bedrock agents viable for orchestration, multimodal pipelines, and stateful agent workflows that previously required ad‑hoc infra. The dangerous part is less talked about: persistent agent runtimes introduce a new trust boundary. Interactive shells, session lifetimes measured in days, and multi‑agent collaboration are features platform teams did not design their IAM or cost controls around.

The IAM problem nobody planned for

Bedrock's extension of IAM‑based cost allocation to runtime traffic is the right call from an accountability perspective. Teams finally get per‑principal cost signals for inference and AgentCore activity, which reduces the incentive to hide budgets in shared service accounts. But cost attribution without strong runtime controls and observability is just noisy telemetry. Temporal policies and rate limiting help — they let you say "this agent can run between 09:00–17:00 and make at most X requests per minute" — yet they don't remove the need for runtime isolation, credential hygiene, and audit hooks into interactive or remote shell features.

If your security model still treats Bedrock like a stateless API, update it. Treat AgentCore RIs like a tenant: network policies, egress controls, dedicated VPC endpoints, enforced session idle timeouts, and tooling to revoke or rotate the principal quickly. This is not optional. Long‑running sessions + GPU access + multi‑agent collaboration = too many opportunities for lateral movement if left unchecked.

What changed — the concrete bits

AgentCore runtime instances: GA; backed by persistent compute (not ephemeral serverless); GPU options; sessions that can persist for days; multi‑agent collaboration and persistent state.
Cost controls: IAM principal‑based cost allocation for Bedrock runtime usage enabling per‑user and per‑role chargeback and downstream analytics.
Policy controls: temporal authorization policies and per‑agent rate limiting to cap activity windows and request rates.
Web retrieval and model updates: Bedrock added web retrieval integrations and model updates to broaden agent information sources (no specific third‑party model versions claimed here).

EKS: control plane knobs and forensic checkpointing

If you run Kubernetes, AWS didn't forget you. Amazon EKS now exposes more control‑plane configuration via APIs so operators can tune kube‑apiserver, kube‑scheduler, and kube‑controller‑manager flags without hacking AMIs or waiting on cloud provider defaults. That's overdue and the right move: control‑plane tuning belongs in the control‑plane API.

Complementing that, EKS surfaces kubelet checkpointing features intended to help forensic captures of container state. In practice this can aid incident response and production debugging, but using it often requires privileged host configuration and may rely on CRIU or container pause semantics; it isn't a magical, no‑impact snapshot of a fully running container. Expect more forensic artifacts, larger captures stored in S3, and a demand for immutable capture chains and access controls to those artifacts.

Lambda bandwidth finally matches the workload

AWS also increased Lambda network bandwidth for high‑memory functions: bandwidth now scales with memory and can reach roughly 3 Gbps for large memory configurations (around 10 GB). For data‑intensive Lambdas that talk to external services or perform streaming/ETL workloads, that reduces network‑bound tail latency and makes serverless more attractive for heavy I/O tasks. If you missed the prior coverage, I wrote about the same trend when non‑VPC bandwidth scaled to ~3 Gbps; treat this as the natural follow‑through to make serverless less network‑constrained. AWS Lambda non‑VPC bandwidth now scales with memory, reaching ~3 Gbps at 10 GB.

What platform teams should do today

First, treat AgentCore RIs as tenants: add network egress controls, monitor Bedrock runtime usage per principal, and bake temporal policies into agent onboarding. Second, expose EKS control‑plane flags through your platform API so SREs can codify tweaks and roll them out with GitOps. Third, expect new artifact volumes from checkpointing — bake lifecycle and access policies into your cost and retention models. If you want patterns for Bedrock cost tracking, AWS published inference‑profile architectures that are worth implementing now.

Final thought

AWS is formalizing long‑running agent compute and giving you billing and rate controls at the same time — which means platform teams must stop treating LLM‑based agents as toy APIs and start treating them as first‑class, billable tenants. Ignore that shift and you'll get surprised bills, shadow agents, and a security incident that could have been prevented by a few simple platform controls. This is the moment to put agent governance into your platform roadmap.

Amazon Bedrock AgentCore runtime instances GA: IAM cost allocation, temporal policies, and rate limiting

Sources

Amazon Bedrock AgentCore: managed EC2 runtimes, Web Search filters, S3 File API multi-agent pattern, and Lambda bandwidth

Amazon Bedrock agent runtimes and payments: persistent instances, spend controls, and operational guidance

Amazon Bedrock AgentCore runtime instances and temporal session policies