da Agency

Amazon Bedrock AgentCore Runtime now supports managed session storage for persistent agent filesystem state (preview)

Amazon Bedrock AgentCore Runtime now offers managed session storage in public preview, enabling agents to persist their filesystem state across stop and resume cycles. Modern agents write code, install packages, generate artifacts, and manage state through the filesystem. Until now, that work was lost when a session stopped. With managed session storage, everything your agent writes to a configured mount path persists automatically, even after the compute environment terminates.
When you configure session storage, each session gets a persistent directory at the mount path you specify. Your agent reads and writes files as normal, and AgentCore Runtime transparently replicates data to durable storage. When the session stops, data is flushed during graceful shutdown. When you resume with the same session ID, a new microVM mounts the same storage and the agent continues from where it left off — source files, installed packages, build artifacts, and git history all intact. No checkpoint logic, no save and restore code, and no changes to your agent application required. Session storage supports standard Linux filesystem operations including regular files, directories, and symlinks, with up to 1 GB per session and data retained for 14 days of idle time. Storage communication is confined to a single session’s data and cannot access other sessions or AgentCore Runtime environments.
Session storage is available in public preview across fourteen AWS Regions: US (N. Virginia, Ohio, Oregon), Canada (Central), Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Paris, Stockholm).
To learn more, see persist files across stop/resume in the Amazon Bedrock AgentCore documentation.
Quelle: aws.amazon.com

da Agency

Amazon SageMaker HyperPod now supports continuous provisioning for Slurm-orchestrated clusters

Amazon SageMaker HyperPod now extends continuous provisioning support to clusters using the Slurm orchestrator, enabling greater flexibility and efficiency for enterprise customers running large-scale AI/ML training workloads. AI/ML customers running Slurm-based clusters need to start training quickly, scale seamlessly, perform maintenance without disrupting operations, and have granular visibility into cluster operations. Previously, if any instance group could not be fully provisioned, the entire cluster creation or scaling operation failed and rolled back, causing delays and requiring manual intervention. With continuous provisioning for Slurm, SageMaker HyperPod automatically provisions remaining capacity in the background while training jobs can begin immediately on available instances. The system uses priority-based provisioning to bring up the Slurm controller node first, followed by login and worker nodes in parallel, so your cluster reaches an operational state as quickly as possible. HyperPod retries failed node launches asynchronously and adds nodes to the Slurm cluster automatically as they become available, ensuring clusters reliably reach their desired scale without requiring manual intervention. You can now perform concurrent, non-blocking scaling operations across multiple instance groups simultaneously — a capacity shortage in one instance group no longer blocks scaling in others. These capabilities help customers reduce time-to-training, maximize resource utilization, and focus on innovation rather than infrastructure management. This feature is available for new SageMaker HyperPod clusters using the Slurm orchestrator. You can enable continuous provisioning by setting the NodeProvisioningMode parameter to “Continuous” when creating new HyperPod clusters using the CreateCluster API. Continuous provisioning can also be enabled when creating new clusters through the AWS CLI and the SageMaker AI console. This feature is available in all AWS Regions where Amazon SageMaker HyperPod is supported. To learn more about continuous provisioning for Slurm clusters, see the Amazon SageMaker HyperPod User Guide.
Quelle: aws.amazon.com

da Agency

AWS Backup expands support for Amazon DocumentDB to 12 Regions

AWS Backup now supports Amazon DocumentDB in 12 additional AWS Regions: Asia Pacific (Malaysia, Thailand, Osaka, Hong Kong, Jakarta, Melbourne), Europe (Stockholm, Spain, Zurich), Africa (Cape Town), Israel (Tel Aviv), and Mexico (Central).
This expansion brings policy-based data protection and recovery to your Amazon DocumentDB clusters in these newly supported Regions.
To start protecting your DocumentDB clusters with AWS Backup, add your DocumentDB clusters to your existing backup plans, or create a new backup plan and attach your DocumentDB clusters to it. To learn more about AWS Backup for Amazon DocumentDB, visit the product page, pricing page, and documentation. To get started, visit the AWS Backup console, AWS Command Line Interface (CLI), or AWS SDKs.
Quelle: aws.amazon.com

da Agency

Amazon EC2 I7ie instances now available in additional AWS regions

AWS is announcing starting today, Amazon EC2 I7ie instances are now available in AWS Asia Pacific (Hong Kong), Asia Pacific (Seoul), Asia Pacific (Melbourne), Asia Pacific (Thailand), Europe (Zurich), Europe (Milan) and Mexico (Central) regions. Designed for large storage I/O intensive workloads, I7ie instances are powered by 5th Gen Intel Xeon Processors with an all-core turbo frequency of 3.2 GHz, offering up to 40% better compute performance and 20% better price performance versus I3en instances.
I7ie instances offer up to 120TB local NVMe storage density for storage optimized instances and offer up to twice as many vCPUs and memory compared to prior generation instances. Powered by 3rd generation AWS Nitro SSDs, I7ie instances deliver up to 65% better real-time storage performance, up to 50% lower storage I/O latency, and 65% lower storage I/O latency variability compared to I3en instances.
I7ie are high density storage optimized instances, ideal for workloads requiring fast local storage with high random read/write performance at very low latency consistency to access large data sets. These instances are available in 9 virtual sizes and deliver up to 100Gbps of network bandwidth and 60Gbps of bandwidth for Amazon Elastic Block Store (EBS).
To learn more, visit the I7ie instances page.
Quelle: aws.amazon.com

da Agency

AWS Batch now supports quota management and preemption for SageMaker Training jobs

AWS Batch now supports quota management with job preemption for SageMaker Training jobs, enabling you to efficiently allocate and share compute resources across your teams and projects. If you’re using GPU capacity in SageMaker Training jobs, you can now intelligently allocate compute resources, prioritize your business-critical training jobs, and automatically preempt lower-priority workloads when your urgent experiments arrive. With quota management, you can create up to 20 quota shares per job queue that function as virtual queues with dedicated capacity limits and configurable resource sharing strategies. The service automatically uses cross-share preemption to restore borrowed capacity when the original owner submits jobs, and supports in-share preemption to allow high-priority jobs to preempt lower-priority jobs within the same quota share. You can monitor capacity utilization at the queue, quota share, and job-level granularity, update job priorities after submission to influence preemption decisions, and configure preemption retry limits to control behavior. The feature integrates directly with the SageMaker Python SDK via the aws_batch module. Quota management with job preemption for SageMaker Training jobs is available today in all AWS Regions where AWS Batch is available. For more information, see our Quota Management example notebook on GitHub and the AWS Batch User Guide.
Quelle: aws.amazon.com