AWS improves regional resiliency for root user sign-in

AWS root user sign-in is now served across US East (N. Virginia), US East (Ohio), and US West (Oregon), with sign-in traffic distributed across all three Regions. This change reduces reliance on US East (N. Virginia) and improves resiliency during service disruptions. AWS automatically routes your root user sign-in to a supported Region without requiring you to select a Region or change how you sign in. This improvement is available now for all AWS accounts.
In AWS CloudTrail, ConsoleLogin events for root user sign-ins are recorded in the Region that processed the sign-in request. To maintain full visibility into root user sign-in activity, update your monitoring and alerting to cover US East (N. Virginia), US East (Ohio), and US West (Oregon).
To learn more, see the AWS Sign-In documentation and the CloudTrail ConsoleLogin event reference.
Quelle: aws.amazon.com

Amazon Connect Customer now enables agents to bid on preferred shifts

Amazon Connect Customer now enables agents to bid on preferred shifts, giving them more control over their work schedules. Schedulers first establish agent ranking either by uploading a CSV file or generating a randomized ranking. Connect Customer then uses forecasted demand and shift profiles to generate available shifts and presents them to agents to rank. For example, in a Monday–Friday 6AM–10PM shift profile with 9-hour shifts, required shifts are 6AM–3PM (500 agents), 9AM–6PM (800 agents), and 1PM–10PM (600 agents). Once the bidding window closes, Connect Customer automatically assigns each agent to their highest-ranked available shift while using agent ranking as a tiebreaker. Shift bidding gives agents a structured way to influence their own schedules, while reducing the time schedulers spend on manual shift assignments, improving both agent satisfaction and scheduling efficiency.
This feature is available in all AWS Regions where Amazon Connect Customer agent scheduling is available. To learn more about Amazon Connect Customer agent scheduling, click here.
Quelle: aws.amazon.com

Analyze your CloudTrail events using natural language in Amazon Q Console

AWS CloudTrail, a service that records API activity across your AWS account for security auditing, compliance, and operational troubleshooting, now integrates with Amazon Q Console to help you investigate your AWS account activity using natural language. You can ask Amazon Q Console questions about your CloudTrail configuration, query your logged events for security investigations, and troubleshoot operational issues without writing queries or manually parsing log files.
With this integration, you can ask Amazon Q Console to check whether your CloudTrail trails are properly configured, identify gaps in your logging coverage, and confirm which data event sources you are tracking. You can investigate security concerns by asking who accessed a specific IAM role, what changes were made to your VPC configuration, or whether there were unauthorized access attempts in the past week. For operational troubleshooting, you can ask Amazon Q Console to find who created or deleted specific resources, identify which API calls are generating errors, trace activity from a specific IP address, or determine why your bill spiked. Amazon Q Console can query your CloudTrail trails, associated CloudWatch log groups, and event data stores on your behalf, providing answers grounded in your actual account activity rather than generic documentation. 
This integration is available in all AWS commercial regions where Amazon Q Console is supported. To get started, open Amazon Q in AWS Management Console and ask questions about your CloudTrail configuration or account activity. For more information, visit the AWS CloudTrail documentation.
Quelle: aws.amazon.com

Amazon SageMaker AI now supports instance preference lists for training and processing jobs

Today, Amazon SageMaker AI announces instance preference lists for training and processing jobs, making it easier and faster to find compute capacity for your workloads. Many AI training, fine-tuning, and data processing workloads run comparably well on any of several instance types or sizes. However, before now, you had to name only one instance type at the time of job submission and wait for SageMaker to find that specific instance for your job. For high-demand GPUs during peak periods, where wait times can be unpredictable, customers sometimes had to build complex retry logic or concurrently submit multiple jobs with different instance types to find the first available option. Now you can simply provide a prioritized list of the instance types your workload accepts, and SageMaker automatically runs your job on the first available configuration from your preferences. With this solution, your training or processing job will likely start sooner.
To use this feature, you specify your instance type and count preferences in priority order when submitting the training or processing job. For example, your list might contain a preference of two instances of ml.g6.48xlarge or four instances of ml.g5.48xlarge. SageMaker works through the list and launches your job on the first configuration where capacity is available. You can also configure the capacity sourcing from on-demand sources or from your reserved SageMaker Flexible Training Plans within the same job submission. This feature simplifies the process of getting compute for your jobs during high-demand periods and reduces the undifferentiated manual retrying you would otherwise do, all within the SageMaker training and processing job APIs you already use.
Instance preference lists for SageMaker training and processing jobs is available today in all AWS Regions where SageMaker is available through the SageMaker CLIs, APIs, SDKs and Console UI. To learn more, see our documentation or our launch blog.
Quelle: aws.amazon.com

AWS Glue zero-ETL adds target table property ownership and conflict detection

AWS Glue zero-ETL integrations now detect table property conflicts and track integration ownership. When you configure a source table and target catalog, Glue associates the resulting table properties with the owning integration, so two integrations can no longer be pointed at the same target table without your knowledge. This works across Amazon S3 Tables and SageMaker Lakehouse catalogs.
Data teams running multiple zero-ETL integrations gain predictable control over where each source table lands. If you attempt to create or modify an integration whose table properties are owned by another integration, Glue identifies the owning integration and guides you to choose a different target or update the existing one, so your pipelines stay isolated and your data lands exactly where you intend.
This feature is available in all AWS Commercial and AWS GovCloud (US) Regions where AWS Glue zero-ETL integrations are supported.
To learn more, refer to the AWS Glue Developer Guide and get started in the AWS Glue console.
Quelle: aws.amazon.com