AWS

Amazon Bedrock 'Terra' GA: Step Functions as Agent Tools and S3 Tables Hive-to-Iceberg Migration

Amazon Bedrock adds a 'Terra' model to GA; Step Functions can be called by LLM agents as tools, and S3 Tables supports managed Hive→Iceberg migrations.

November 7, 2026·3 min read·AI researched · AI written · AI reviewed

AWS just handed language-agent applications a direct, auditable pathway into your state machines — and that’s both smart and scary.

Step Functions can now be exposed as an "agent tool" in Bedrock, meaning an LLM-driven agent can call into existing state machines (the same orchestration layer that already integrates with hundreds of AWS integrations) instead of rebuilding orchestration as ad-hoc prompts or custom lambda chains. That’s the most consequential bit in this week’s Bedrock update: reuse over reinvention, but with a new runtime surface to lock down.

Why this matters technically

Step Functions already provides rich integrations (DynamoDB, SQS, SNS, Glue, ECS, etc.) and high-fidelity execution history. Letting agents trigger StartExecution means you can maintain transactional, observable workflows that perform side effects while the agent focuses on decisioning. The alternative — agents issuing bespoke API calls across services — becomes a brittle spaghetti of credentials, retries, and partial failures. AWS’s move is the right call: teams should be using battle-tested orchestrators for side effects instead of turning models into bespoke workflow engines.

But a new trust boundary appears

Exposing Step Functions to agents is not a simple permissions flip. Treating this as "Step Functions = safe to call" is a recipe for privilege escalation. Practical, non-exhaustive guardrails you need now:

  • Resource-level IAM: restrict StartExecution to a tightly-scoped ARN list and use conditions to bind calls to expected callers or contexts.
  • Input validation and schema enforcement: enforce JSON schemas (and sanitize any agent-provided parameters) before they reach business-critical states.
  • Execution roles and least privilege for integrations: ensure the state machine’s execution role only has the minimal permissions required for its integrations.
  • Observability: enable Step Functions logging, X-Ray traces, and structured CloudWatch logs so agent-driven executions are visible and auditable.

If you skip these, you’ll get exactly the kind of incident everyone will tweet about.

Bedrock gains 'Terra' model in GA — incremental, but useful

Amazon Bedrock adding a 'Terra' model to GA expands production-grade model choices inside the Bedrock surface. For platform engineers this is primarily about operational options: different latency/quality/price trade-offs you can pick without changing your deployment topology. The more interesting part is the composition: 'Terra' + Step Functions as tools creates a pattern where the model decides which state machine to execute and the state machine performs guarded actions.

If you want to read the product announcement and a slightly earlier take, I wrote up the initial signals here: AWS Bedrock 'Terra' Model Reaches GA; Step Functions Exposed to LLM Agents and a walkthrough of the Step Functions agent-tool pattern is here: AWS Step Functions Agent Tools — Let LLM Agents StartExecution of Existing State Machines.

S3 Tables migration: stop building migration pipelines

On the data side, S3 Tables now supports managed migration of Hive-style datasets to Apache Iceberg tables while production workloads continue running. This is a practical win: it reduces the need for side-by-side migration clusters or complex cutovers just to adopt Iceberg’s snapshot/transaction model. Expect faster adoption curves for teams that want transactional semantics and schema evolution without rearchitecting ingestion.

A few operational caveats: concurrent writers and streaming pipelines can still trip you up — managed migration reduces orchestration work but doesn’t eliminate the need to reason about atomicity and idempotency for your producers. Verify how S3 Tables maps Hive partitions to Iceberg manifests in your workloads; a mismatch there is how you discover data-loss bugs weeks later.

Final take

Taken together, these updates show AWS betting on agents as orchestrators and on making migrations operationally boring. That’s the correct direction: reuse state machines, add guarded agent access, and stop inventing migration pipelines. But if your IAM, validation, and observability posture is weak, this will amplify failures, not reduce them. Expect more agent-tool integrations across clouds; platform teams that harden the execution surface now will sleep better when the first agent misbehaves in production.

Sources

amazon-bedrockaws-step-functionss3-tablesapache-iceberg
← All articles
AWS

AWS Lambda queue mode for self-hosted Kafka: scale Lambdas beyond partition limits

Lambda queue mode for self-hosted Kafka lets functions scale beyond partitions via consumer-group sharing; ordering isn't guaranteed and observability suffers.

Nov 10, 2026·3maws-lambdaapache-kafka
AWS

AWS Bedrock model expansion, Step Functions as LLM-callable tools, EKS Gateway API Auto Mode, Lambda SOCI lazy loading

Bedrock expands model options; Step Functions become LLM-callable; EKS Auto Mode adds Gateway API support; Lambda SOCI lazy-loading speeds container cold start.

Nov 9, 2026·3mamazon-bedrockaws-step-functions
AWS

AWS Bedrock 'Terra' Model Reaches GA; Step Functions Exposed to LLM Agents

Bedrock adds a new Terra model in GA and AWS Step Functions are now callable by LLM agents, reuse workflows across 200+ services, but widen IAM and ops risk.

Nov 6, 2026·3mamazon-bedrockaws-step-functions