Amazon CloudWatch Application Signals now supports infrastructure, logs, and traces context for faster troubleshooting

Amazon CloudWatch Application Signals introduces service health ranking on the application map and new infrastructure, logs, and traces tabs on the service overview page. These capabilities let operators triage unhealthy services and inspect the underlying compute environment, log snippets, and trace details in one place, making it easier to find root causes without switching tools. Customers use Application Signals to monitor the health of distributed applications, but identifying why a service was unhealthy often required leaving CloudWatch to correlate infrastructure data across separate tools. The application map now ranks services by health and shows runtime indicators on service nodes for Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, along with a new infrastructure tab that surfaces the compute and runtime environment, its components, and curated default metrics with deep links to the relevant monitoring tools. In addition, the service overview page provides the infrastructure, logs, and traces tab, helping operators spot issues in context of their application. With health-ranked services on the application map and new infrastructure, logs, and traces tabs, operators can instantly identify their most degraded services and drill into the compute environment, error-producing log snippets, and slow or failing transactions — all without leaving Application Signals. These capabilities span workloads running on Amazon EKS, Amazon ECS, AWS Lambda, and Amazon EC2, giving teams a single pane to move from symptom to root cause in minutes instead of hours. These capabilities are available in all AWS Regions where Amazon CloudWatch Application Signals is supported. To learn more about this feature, see the Amazon CloudWatch Application Signals documentation . For pricing details, see the Amazon CloudWatch pricing page
Quelle: aws.amazon.com

AWS announces AWS Workload Credentials Provider

AWS announces AWS Workload Credentials Provider, a lightweight client-side provider that automates deployment of exported certificates from AWS Certificate Manager (ACM) and local caching of secrets from AWS Secrets Manager across AWS and non-AWS workloads. Previously, customers exporting public or private certificates from ACM had to build custom automation using Amazon EventBridge to detect renewals and deploy the updated certificates. With public certificate lifetimes decreasing per the the Certification Authority Browser Forum (CA/B) mandate, this custom automation can become difficult to maintain at scale. AWS Workload Credentials Provider eliminates this complexity by providing a single provider that helps distribute and automate both secrets and certificates to your workloads. You configure it with your certificate ARN and specify options such as file paths and server reload behavior — the provider then handles certificate export and deployment automatically to prevent expiry related failures. It runs on Windows and Linux and supports Apache and NGINX web servers. For secrets caching, the provider maintains full backwards compatibility with the AWS Secrets Manager Agent, enabling you to securely cache application secrets locally across AWS and non-AWS workloads through the same unified provider. AWS Workload Credentials Provider is open source and available on GitHub. You can use it with exportable ACM certificates and Secrets Manager in all AWS Regions. To learn more, visit the AWS Certificate Manager documentation or the AWS Secrets Manager documentation.
Quelle: aws.amazon.com

Amazon Managed Service for Prometheus now supports out of order sample ingestion

Amazon Managed Service for Prometheus now supports out-of-order sample ingestion and a workspace-level rule query offset. All workspaces have a default out-of-order time window of 1 minute, allowing the workspace to accept metric samples arriving outside strict chronological order. You can adjust this window to match your ingestion patterns or set it to 0 to disable the feature and discard out-of-order samples. You can also configure a global rule query offset that introduces a delay before rule evaluation queries run, giving late-arriving samples time to be ingested before rules execute.
Together, these features reduce data loss and improve alerting accuracy for workloads with distributed collectors, batched exports, or variable network latency. Out-of-order sample support ensures late-arriving data points are ingested rather than discarded, preserving metric completeness. The rule query offset compensates for the expected ingestion delay. Without it, rules evaluate instantly and may miss samples that haven’t landed yet, producing results that differ from the same expression evaluated after all metrics arrive. Two new CloudWatch vended metrics, OutOfOrderIngestionRate and OutOfOrderSampleAge give you visibility into ingestion patterns, helping you tune both settings for your workload. 
Out-of-order sample ingestion and rule query offset are available in all AWS regions where Amazon Managed Service for Prometheus is generally available. To get started, configure the out-of-order time window and ruler query offset in your workspace settings via AWS console, API or CLI. For more information, see Amazon Managed Service for Prometheus user documentation.
Quelle: aws.amazon.com

AWS Elastic Beanstalk console now integrates CloudWatch Logs in the Logs tab

AWS Elastic Beanstalk now provides a CloudWatch Logs integration directly in the environment Logs tab of the Elastic Beanstalk console. Previously, customers had to navigate to the CloudWatch console to find the relevant log groups and log streams for their environments. With this launch, customers can view CloudWatch log events without leaving the Elastic Beanstalk console.  
The Logs tab displays log groups that an environment streams logs to, as well as log groups matching the aws/elasticbeanstalk/<env-name>/* prefix. Customers can select a log group to view its log streams, with the most recently active stream selected by default. A log stream dropdown allows switching between streams and filtering results. For deeper analysis, a View in CloudWatch dropdown provides direct links to the log group, log stream, or CloudWatch Logs Insights in the CloudWatch console.
This feature is available across all Elastic Beanstalk platform branches in all AWS Commercial Regions and AWS GovCloud (US) Regions where Elastic Beanstalk is available. For a complete list of supported Regions, see AWS Regions.
For more information about using Elastic Beanstalk with Amazon CloudWatch, see the AWS Elastic Beanstalk developer guide. To learn more, visit the AWS Elastic Beanstalk product page.
Quelle: aws.amazon.com

Amazon MWAA Serverless now supports Amazon EventBridge notifications/

Amazon Managed Workflows for Apache Airflow (MWAA) Serverless now supports workflow and task state change events to Amazon EventBridge, enabling data engineering and platform teams to build event-driven automation for their Apache Airflow workflows.
Previously, monitoring workflow execution required custom polling logic or manual observation. With this launch, MWAA Serverless can emit events when workflows transition between states, including started, running, succeeded, or failed, and when individual tasks change state, such as scheduled, succeeded, failed, or up for retry. With this feature, you can further automate your existing workflows – for example, using EventBridge notifications to trigger alerts when a production workflow fails, automatically restart dependent pipelines when an upstream workflow succeeds, or log state transitions to Amazon S3 for compliance and auditing.
This feature is available in all AWS Regions where Amazon MWAA Serverless is available. For the complete list of supported Regions, see Regions in the Amazon MWAA Serverless User Guide. For pricing details, see Amazon EventBridge pricing.
To learn more, see Monitoring Amazon MWAA Serverless in the Amazon MWAA Serverless User Guide and Amazon MWAA Serverless events in the Amazon EventBridge Events Reference.
Quelle: aws.amazon.com

Amazon ECS Managed Daemons now support inter-task visibility and communication

Amazon ECS Managed Daemons now support inter-task visibility and communication, enabling customers to deploy tracing, profiling, and security agents that require access to application processes and shared IPC resources on ECS Managed Instances. With this launch, you can configure two new settings in ECS daemon definitions: pidMode controls whether the daemon can see all processes on the instance, and ipcMode controls whether the daemon shares an IPC namespace with other containers on the instance. Setting either to “shared” grants the daemon access to the respective namespace; the default of “none” keeps daemons isolated from application containers and other tasks. These settings let you run process-aware and IPC-dependent agents as ECS daemons instead of embedding them as sidecars in application task definitions. ECS places exactly one daemon task per managed instance and starts daemons before application tasks, so platform teams can deploy and update agents independently with consistent coverage across all workloads. To get started, register a daemon task definition specifying pidMode or ipcMode set to “shared” using the AWS Console, CLI, CloudFormation, or AWS SDKs, then create or update a daemon with associated ECS Managed Instances capacity providers in your clusters. This feature is now available in all AWS Regions at no additional cost. For more details, refer to our documentation.
Quelle: aws.amazon.com

Amazon OpenSearch Service launches MCP Apps for agentic observability

Amazon OpenSearch Service now supports MCP Apps, bringing observability workflows directly into compatible agentic IDEs such as Claude Desktop and VS Code. With this capability, your AI agent in local environment can investigate incidents using logs, traces, metrics, and alerts stored in OpenSearch domains, collections and Amazon Managed Service for Prometheus. You can easily review and verify the results in interactive MCP App visualizations without leaving your local environment. Each MCP App tool call returns a dual response, a concise text summary for your agent to reason over and an interactive visualization rendered in the same conversation thread for you to review. You can work alongside your observability agent from firing an alert, perform root cause analysis, exploring distributed traces, service maps, PromQL metric charts, and cross-signal correlations all within a single conversation. Available MCP App tools cover log, metrics and trace investigation, service performance, topology, dynamic visualizations, agent health, cluster health, and instrumentation scoring.
The OpenSearch MCP app experience is available is available in all AWS Regions where Amazon OpenSearch UI is offered. To get started, follow the instructions in OpenSearch Agentic observability with MCP Apps. To learn more about OpenSearch, visit Amazon OpenSearch Service Developer Guide.
Quelle: aws.amazon.com

OpenAI GPT-5.4 and GPT-5.5 models now available in US East (N. Virginia) on Amazon Bedrock

Today, AWS announces the expanded availability of OpenAI’s GPT-5.4 and GPT-5.5 models, which are now available in the US East (N. Virginia) Region on Amazon Bedrock. With GPT-5.4 and GPT-5.5, you can build generative AI applications across reasoning, coding, computer use, document workflows, and long-running agentic tasks. GPT-5.5 is OpenAI’s most capable model, designed for advanced coding, research, analysis, software operation, document workflows, and long-running agentic tasks. It can understand open-ended goals, use tools, reason across longer workflows, navigate ambiguity, and carry complex tasks through to completion with less orchestration. GPT-5.4 brings frontier reasoning, coding, computer use, long-context workflows, and tool use to production applications that interpret context, interact with tools, operate software environments, and verify outputs across multiple steps. Both models support a 272K-token context window, accept text and image input, and are available through the Responses API with support for server-side and client-side tool calling, projects, and response streaming. With this launch, GPT-5.4 and GPT-5.5 are now available in additional AWS Regions. To get started, visit the GPT-5.5 and GPT-5.4 model cards in our documentation.
Quelle: aws.amazon.com

Amazon FSx for OpenZFS Intelligent-Tiering storage class is now available in 8 additional AWS Regions

You can now create Amazon FSx for OpenZFS file systems with the Intelligent-Tiering storage class in 8 additional AWS Regions across the US, Europe, Asia Pacific, and South America.
FSx Intelligent-Tiering is built for general-purpose file workloads such as file shares, archives, media libraries, and migrations from on-premises HDD storage. It automatically moves your data across three storage tiers (Frequent Access, Infrequent Access, and Archive) based on access patterns, and an optional SSD read cache keeps your active data fast. You get high performance for active workloads and low-cost storage for everything else, paying only for what you store with no capacity to manage. With FSx Intelligent-Tiering, you can save up to 85% compared to the FSx SSD storage class and up to 20% compared to on-premises HDD-based NAS.
With this expansion, the FSx Intelligent-Tiering storage class is now available for FSx for OpenZFS file systems in the following additional AWS Regions: US West (N. California), Europe (London, Stockholm, Spain, Zurich), Asia Pacific (Hyderabad, Seoul), and South America (São Paulo). To learn more, visit the FSx Intelligent-Tiering page and the Amazon FSx for OpenZFS product page, and see the FSx for OpenZFS Region Table for complete regional availability information.
Quelle: aws.amazon.com

AWS Cost and Usage Report 2.0 now supports table configurations update

AWS today announces that AWS Cost and Usage Report 2.0 (CUR 2.0) now supports updates to data table configurations via the AWS Management Console and SDK/CLI. This capability allows customers to modify their existing exports to take advantage of new CUR 2.0 features without having to delete and recreate their exports. Previously, customers configured CUR 2.0 exports with specific table settings — including export content, time granularity, column selection, export format, and destination settings. When AWS introduces new features, such as additional columns and finer row-level granularity, existing export settings intentionally remained unchanged to protect ETL jobs that depended on a stable schema. However, customers who wanted to adopt these new capabilities and were ready for the new schema couldn’t simply update their preference in existing export. They had to delete their existing export and create a new one with the new preference. With this launch, customers can update their table configuration directly through the AWS Management Console or SDK/CLI and begin receiving exports with their updated preferences starting from the next scheduled export delivery. To learn more about this feature, see AWS Data Exports and AWS Billing and Cost Management in the AWS Cost Management User Guide.
Quelle: aws.amazon.com