AWS just handed platform teams a new attack surface and called it a feature.
Step Functions can now be exposed to LLM agents as callable tools. Practically that means an agent running in Bedrock (or any LLM-based orchestration) can call Step Functions' StartExecution on an existing state machine and trigger workflows that touch 220+ AWS integrations — without you rewriting orchestration into the agent. This is extremely useful, and also exactly the kind of shift that blows past the assumptions most IAM and runtime-validation models were designed around.
The new trust boundary
Treating Step Functions as an agent-callable tool preserves decades of operational work: you keep your durable, audited state machines and service integrations; you don't need to re-implement long-running workflows inside ephemeral agents. That's the right call. The hard truth: most teams haven't hardened state machines for arbitrary natural-language-driven inputs.
Concrete consequences you'll feel immediately:
- Agents can call StartExecution with arbitrary input payloads. If your state machine assumes well-formed input or caller identity, that's a liability.
- Audit logs will be richer (Step Functions history), but incident blast radius increases: a misbehaving agent can kick off expensive, cross-account, or destructive workflows.
- Standard IAM needs tightening: StartExecution permissions are broad unless scoped to ARNs and conditions.
Do not assume "it works" equals "it is safe." Lock down Step Functions with resource-level ARNs, use IAM condition keys (aws:RequestTag, aws:PrincipalTag), and validate inputs inside the state machine with explicit validation steps — for example, a small validation Lambda or Choice states that enforce required fields and types before critical tasks run. Require signed or pre-authorized parameters when workflows touch sensitive resources. If you run agents in a managed Bedrock runtime, treat them like untrusted callers and instrument aggressively.
EKS Auto Mode: Gateway API finally lands where it matters
EKS Auto Mode now supports the Kubernetes Gateway API resources (Gateway and HTTPRoute) and can provision and manage the underlying AWS load-balancing infrastructure automatically. That means teams can declare Gateway/HTTPRoute CRs and let AWS wire up the LB plumbing — no Service/Annotation gymnastics.
This is overdue, and it matters because Gateway API maps far better to modern routing concerns (TLS delegation, path/host matching, weighted routes) than Service + Ingress. If you're still mapping everything through Service annotations, move a subset of traffic to Gateway API in a controlled way and validate traffic policies and sane default limits on backend weights.
Lambda Managed Instances: SOCI seekable-OCI lazy loading
Lambda Managed Instances added support for Seekable OCI (SOCI) lazy loading for container images. Rather than pulling a full image blob at cold-start, SOCI lets the runtime fetch files on demand; AWS reports meaningful reductions in startup time for large images in some workloads. This is an operational win: smaller cold-start windows for large images and faster testing feedback loops.
If you care about predictable cold-starts, use SOCI-indexed images when building Lambda containers. Combine SOCI with provisioned concurrency or managed instance pools for the most stable latency profile. For serverful container platforms (SageMaker, ECS), SOCI patterns are already proving useful — expect more first-party support.
Other notable bits
- Bedrock expanded its model set and updated runtimes, making more vendor models available through the Bedrock inference plane.
- AWS KMS added features to better support modern key-wrapping and ML artifact workflows.
- Amazon ECS introduced improved GPU-sharing features (for example, NVIDIA MPS on supported instances) to boost GPU utilization in multi-tenant workloads.
- IAM Identity Center added capabilities to simplify cross-Region identity propagation and global identity setups.
- Amazon S3 and related services now offer tooling to help migrate Hive metadata to Iceberg in managed flows.
Final take: this wave of releases is pragmatic and connective. AWS didn't invent flashy new primitives — it glued agents, orchestration, and faster startup paths together. That's the point: platform teams now must treat agents as first-class, untrusted callers, and shipping that mental model into your IAM, validation, and observability is the real work. If you don't, the next incident won't be subtle.