da Agency

AWS Step Functions adds AgentCore-powered agentic reasoning step

AWS Step Functions now enables you to add AI agent reasoning steps to your workflow through an optimized integration with the managed harness (currently in preview) in Amazon Bedrock AgentCore. AWS Step Functions is a visual workflow service that orchestrates AWS services with built-in error handling, parallel execution, and human approval steps. The AgentCore harness lets you declare an agent through configuration where you specify the model, tools, and behavior. AgentCore provides the managed environment that runs the agent loop end-to-end.
 
With this integration, you can automate reasoning tasks in your workflow such as classifying a document or extracting elements from an unstructured form. You can run multiple agents in parallel or in sequence at different decision points in a single workflow and add human approval before critical actions. The workflow execution history shows agent input, output, token usage, and duration with links to agent turn details in Amazon CloudWatch, so you can trace and audit every agent decision. You can reuse an existing harness or create a new one directly from the Workflow Studio, the Step Functions visual builder. With per-invocation overrides such as the model, system prompt, and tools, you can adapt the agent to each workflow context without duplicating configurations. Agent context can be persisted across invocations using a session ID that works within or across workflow executions.
 
The harness integration is available in the following AWS Regions where the AgentCore harness preview is available: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Sydney). Standard Step Functions pricing applies for workflow execution with no additional integration charges, and standard Amazon Bedrock and AgentCore pricing applies for model inference and associated AgentCore resources.
 
To learn more about adding agentic reasoning to your workflows, visit AWS Step Functions documentation. 
Quelle: aws.amazon.com

da Agency

AWS Config now supports internal service linked rules

AWS Config now supports internal service linked rules, enabling AWS services to evaluate AWS resource configurations using AWS Config managed rules. Internal service linked rules extend the existing service linked recorder capability by allowing AWS services such as AWS Security Hub CSPM to deploy and manage rule evaluations for service specific functionality. With internal service linked rules, AWS services can use AWS Config managed rules to provide integrated security and compliance capabilities. Evaluation results are delivered directly to the AWS service that deployed the rule at no charge from AWS Config to customers. Internal service linked rules operate independently of existing customer managed AWS Config recorders and rules. This allows customers to continue using AWS Config for inventory, governance, compliance, and auditing use cases while AWS services independently manage service specific evaluations. AWS Security Hub CSPM internal service-linked rules are now available in all commercial, GovCloud, and China Regions. To learn more, see the AWS Config documentation.
Quelle: aws.amazon.com

da Agency

Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36

Kubernetes version 1.36 introduced several new features and bug fixes, and AWS is excited to announce that you can now use Amazon Elastic Kubernetes Service (EKS) and Amazon EKS Distro to run Kubernetes version 1.36. Starting today, you can create new EKS clusters using version 1.36 and upgrade existing clusters to version 1.36 using the EKS console, the eksctl command line interface, or through an infrastructure-as-code tool. Kubernetes version 1.36 introduces several key improvements, promoting User Namespaces to general availability for mapping container root to an unprivileged host user so that a breakout grants no node-level privileges, alongside Mutating Admission Policies for CEL-based resource mutations in the API server without webhook infrastructure. The release also brings In-Place Pod-Level Resources Vertical Scaling allowing Pods to resize their shared CPU and memory budget without restart, and Resource Health Status reporting device health in Pod status to help identify hardware-caused crash loops. To learn more about the changes in Kubernetes version 1.36, see our documentation and the Kubernetes project release notes. EKS now supports Kubernetes version 1.36 in all the AWS Regions where EKS is available, including the AWS GovCloud (US) Regions. You can learn more about the Kubernetes versions available on EKS and instructions to update your cluster to version 1.36 by visiting EKS documentation. You can use EKS cluster insights to check if there are any issues that can impact your Kubernetes cluster upgrades. EKS Distro builds of Kubernetes version 1.36 are available through ECR Public Gallery and GitHub. Learn more about the EKS version lifecycle policies in the documentation.
Quelle: aws.amazon.com