AWS Step Functions adds 28 new service integrations, including Amazon Bedrock AgentCore

AWS Step Functions expands its AWS SDK integrations with 28 additional services and over 1,100 new API actions across new and existing AWS services, including Amazon Bedrock AgentCore and Amazon S3 Vectors. This expansion enables you to orchestrate a broader set of AWS services directly from your workflows without writing integration code. AWS Step Functions is a visual workflow service capable of orchestrating over 220 AWS services to help customers build distributed applications at scale. With the Amazon Bedrock AgentCore service integration, you can invoke AI agent runtimes with built-in retries, run multiple agents in parallel using Map states, and automate agent provisioning workflows that create, update, and tear down agent infrastructure as workflow steps. This expansion also includes Amazon S3 Vectors for automating document ingestion pipelines that populate knowledge bases for AI applications. It also adds support for AWS Lambda durable execution APIs, allowing you to pass an execution name for idempotent invocations of Lambda durable functions and manage durable executions directly from your workflows. These enhancements are now generally available in all AWS Regions where AWS Step Functions is available. Specific services and API actions are subject to the availability of the target service in the AWS Region. To learn more about AWS Step Functions SDK integrations, visit the Developer Guide, or see the full list of supported services at AWS SDK service integrations.
Quelle: aws.amazon.com

AWS HealthImaging announces study-level fine-grained access control

AWS HealthImaging now supports fine-grained access control, enabling organizations to securely manage access to medical imaging data at the DICOM study and series levels. Medical imaging workflows are typically organized around DICOM studies, which are stored in AWS HealthImaging as one or more image set resources. Now customers can easily grant users access to all image sets for a set of DICOM Studies or Series with easy-to-maintain IAM policies.
Customers can now grant permissions for DICOMweb APIs using DICOM Study Instance UIDs and Series Instance UIDs directly in their IAM policies, eliminating the need to list individual image set ARNs. Customers can now create dynamic, temporary access grants using AWS Security Token Service (STS) session policies with low-latency authentication. This capability provides enhanced protection for Protected Health Information (PHI) by scoping access grants to specific Studies or Series rather than entire data stores. This launch better supports use cases such as pathologist case-level access, radiology study sharing with external partners, and controlled research data distribution. To learn more, see the AWS HealthImaging Developer Guide.
AWS HealthImaging is a HIPAA-eligible service that empowers healthcare providers, life sciences organizations, and their software partners to store, analyze, and share medical images. AWS HealthImaging is generally available in the following AWS Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Europe (Ireland), and Europe (London). 
Quelle: aws.amazon.com

AWS Management Console now supports settings to control service and Region visibility

Today, AWS announces the general availability of Visible services and Visible Regions account settings in the AWS Management Console. These settings allow you to customize which services and regions appear in the Management Console for authorized users in your account, helping your users easily identify what is available to them and simplifying navigation. You can configure these settings in the AWS Management Console under Unified Settings in the Account Settings tab. You can also configure these setting programmatically via User Experience Customization (UXC) in AWS Command Line Interface (CLI), AWS Software Development Kits (SDKs), AWS Cloud Development Kit (CDK), or AWS CloudFormation. The Visible services and Visible Regions settings are available in AWS Commercial Regions at no additional cost. Visit the AWS User Experience Customization documentation page and API guide to learn more.
Quelle: aws.amazon.com

AWS Lambda supports up to 32 GB of memory and 16 vCPUs for Lambda Managed Instances

AWS Lambda now supports up to 32 GB of memory and 16 vCPUs for functions running on Lambda Managed Instances, enabling customers to run compute-intensive workloads such as large-scale data processing, media transcoding, and scientific simulations without managing any infrastructure. Customers can also configure the memory-to-vCPU ratio — 2:1, 4:1, or 8:1 — to match the resource profile of their workload. Lambda Managed Instances lets you run Lambda functions on managed Amazon EC2 instances with built-in routing, load balancing, and auto-scaling, giving you access to specialized compute configurations including the latest-generation processors and high-bandwidth networking, with no operational overhead. Customers building compute-intensive applications such as data processing pipelines, high-throughput API backends, and batch computation workloads require substantial memory and CPU resources to process large datasets, serve low-latency responses at scale, and run complex computations efficiently. Previously, function execution environments on Lambda were limited to 10 GB of memory and approximately 6 vCPUs, with no option to customize the memory-to-vCPU ratio. Functions on Lambda Managed Instances can now be configured with up to 32 GB of memory, and a choice of memory-to-vCPU ratio — 2:1, 4:1, or 8:1 — allowing customers to select the right balance of memory and compute for their workload. For example, at 32 GB of memory, customers can configure 16 vCPUs (2:1), 8 vCPUs (4:1), or 4 vCPUs (8:1) depending on whether their workload is CPU-intensive or memory-intensive. This feature is available in all AWS Regions where Lambda Managed Instances is generally available. You can configure these settings using the AWS Console, AWS CLI, AWS CloudFormation, AWS CDK, or AWS SAM. To learn more, visit the AWS Lambda Managed Instances product page and documentation.
Quelle: aws.amazon.com

AWS Lambda increases the file descriptor limit to 4,096 for functions running on Lambda Managed Instances

AWS Lambda increases the file descriptor limit from 1,024 to 4,096, a 4x increase, for functions running on Lambda Managed Instances (LMI). This capability enables customers to run I/O intensive workloads such as high-concurrency web services, and file-heavy data processing pipelines, without running into file descriptor limits. LMI enables you to run Lambda functions on managed Amazon EC2 instances with built-in routing, load-balancing, and auto-scaling, giving you access to specialized compute configurations including the latest-generation processors and high-bandwidth networking, with no operational overhead. Customers use Lambda functions to build a wide range of serverless applications such as event-driven workloads, web applications, and AI-driven workflows. These applications rely on file descriptors for operations such as opening files, establishing network socket connections to external services and databases, and managing concurrent I/O streams for data processing. Each open file, network socket, or internal resource consumes one file descriptor. Today, Lambda supports a maximum of 1,024 file descriptors. However, LMI allows multiple requests to be processed simultaneously, which often requires higher number of file descriptors. With this launch, AWS Lambda is increasing the file descriptor limit to 4,096, allowing customers to run I/O intensive workloads, maintain larger connection pools, and effectively utilize multi-concurrency for functions running on LMI. This feature is available in all AWS Regions where AWS Lambda Managed Instances is generally available. To get started, visit the AWS Lambda Managed Instances documentation.
Quelle: aws.amazon.com