AWS

AWS STS now enforces a single 4,096-byte limit for session tokens, removing previous separate constraints on inline policies and tags. The service provides visibility into token size and utilization percentage via CloudTrail logs and CloudWatch metrics. A new optional API parameter allows generating tokens up to the limit for application testing purposes.

• Unified 4096-byte limit replaces separate token and parameter size caps.
• Monitor usage via CloudTrail logs and CloudWatch metrics.
• Use new API parameter to test infrastructure with larger tokens.
• Allows larger combinations of policies and session tags.

Amazon ECS now allows tasks on EC2 instances to mount Amazon S3 as a shared file system using standard file semantics. This update brings EC2 launch type parity with Fargate and Managed Instances for S3 Files access. Applications can read and write S3 data directly without code changes or intermediate staging steps.

• EC2-based ECS tasks can now mount S3 as a file system directly.
• Eliminates need to stage or duplicate data before processing.
• Provides consistent S3 Files behavior across all three ECS launch types.
• Enables standard file semantics for AI agents and data workloads on EC2.

AWS now routes root user sign-in traffic across US East (N. Virginia), US East (Ohio), and US West (Oregon) to reduce dependency on a single region. This automatic distribution improves availability during regional service disruptions without requiring changes to the sign-in process. ConsoleLogin events are recorded in the specific region that handled the request, shifting where audit logs originate.

• Root sign-in is now distributed across US East (N. Virginia), US East (Ohio), and US West (Oregon).
• No user action is required; traffic routing is handled automatically by AWS.
• CloudTrail ConsoleLogin events now appear in the region processing the sign-in request.
• Update monitoring and alerting rules to cover all three regions for complete visibility.

Amazon SageMaker AI now allows users to submit prioritized lists of acceptable instance types for training and processing jobs, replacing the previous single-instance constraint. This feature automates the selection of available compute capacity, addressing unpredictable wait times for high-demand GPUs during peak periods. Engineers can eliminate complex retry logic or concurrent job submissions by defining acceptable alternatives upfront.

• Submit prioritized lists of instance types instead of a single fixed option
• Automatically selects the first available instance from your preferred list
• Reduces job wait times during peak GPU demand periods significantly
• Eliminates the need for custom retry logic or concurrent job submissions