This Month in AWS Observability: August – September 2026

Introduction

August and September brought the general availability of Amazon CloudWatch Omni, an AI-first, app-centric observability experience that brings together telemetry across AWS accounts, Regions, and Azure workloads in a single space. Alarms gained warm-up periods and wall clock evaluation windows, cutting the noise that comes from startup gaps and rolling-window edge cases. Database observability expanded to cover self-managed PostgreSQL and Aurora DSQL, so teams can monitor their entire database fleet in one console regardless of deployment model. AI-powered investigation arrived for AWS CloudTrail, letting you ask Amazon Q Console plain-language questions about who did what in your account. Log collection broadened with native journald support, new pipeline processors for GeoIP, RDS, and XML, and tag propagation for centralized logs. And across the portfolio, services from HealthOmics to WorkSpaces to MSK started publishing richer telemetry to CloudWatch, much of it built on OpenTelemetry.

Here’s what’s new across Amazon CloudWatch and AWS DevOps Agent.

To see these launches demonstrated live, register for the next “I didn’t know Amazon CloudWatch could do that!” on October 13, 2026, 11 am to 12 pm ET. Catching up on earlier editions? Read This Month in Observability ICYMI: Jan-May 2026, June 2026, and July 2026.

Introducing Amazon CloudWatch Omni: AI-first observability for agents and applications

The headline launch this period is Amazon CloudWatch Omni, now generally available. Omni is an evolution of Amazon CloudWatch into an AI-powered observability experience organized around your teams and the applications they run. You create spaces in your central accounts to see telemetry across AWS accounts and Regions as well as other clouds, including Azure workloads. Omni automatically discovers services, maps dependencies, and surfaces golden metrics to streamline your operational workflows.

Figure 1: Your applications and AI agents finally share one view. CloudWatch Omni converges infrastructure and agent observability into a single experience, delivered in your IDE or Omni web UI with enterprise SSO.

What makes Omni different is how you interact with telemetry. You can chat in natural language and Omni finds the relevant signals, builds dynamic views, and helps you get to root cause powered by AWS DevOps Agent. Prefer to drive yourself? Point and click through the signals that matter most, whether you’re investigating a degrading application or diving deep into a trace or evaluation.

The clearest theme across alarm launches is making alarms more intelligent about when and how they evaluate.

Amazon CloudWatch now lets you configure a warm-up period for metric alarms and log alarms, delaying evaluation for a set time after the alarm is created. This reduces noise from missing data while a new resource or service starts up and begins publishing metrics. A team that provisions a new microservice and its alarms together through a CI/CD pipeline can attach a warm-up period so alarms do not page the on-call engineer while the service is still starting up. You get two modes: wait a fixed duration you set, or let CloudWatch start evaluating automatically as soon as the metric has enough data to fill the evaluation window. Warm-up periods range from 1 to 2,880 minutes and are available at no additional charge beyond standard CloudWatch alarm pricing.

CloudWatch Alarms also now supports wall clock evaluation windows, enabling you to align alarm evaluations to fixed calendar boundaries such as the top of the hour, midnight, or the start of the week. This complements the existing sliding window behavior and is designed for scheduled or business-aligned workloads. A daily backup alarm using a sliding window can trigger incorrectly if consecutive backups are slightly more than 24 hours apart, even though each calendar day had a successful backup. A wall clock window evaluates each calendar day independently, eliminating this issue. You can specify a time zone so that daily alarms align to your local business day, with daylight saving time transitions handled automatically.

Expand database observability: broader engine and deployment coverage

Database Insights continues to expand the engines it covers, and these two months it reached two important milestones.

Amazon CloudWatch Database Insights now supports self-managed PostgreSQL databases running on Amazon EC2. You use the CloudWatch agent to collect health and performance data from your self-managed instances, and they appear in the Database Insights fleet view with live performance data including database load, wait event analysis, query-level statistics, and host metrics. You monitor and troubleshoot them using the same familiar console and workflows you already use for your AWS-managed databases, so you can monitor your entire PostgreSQL fleet in one place.

Amazon Aurora DSQL now features a new Database Insights metric that delivers per-statement, cluster-level performance monitoring. It captures sampled wait states and normalized SQL statements for all active cluster sessions, so you can diagnose performance issues and identify the queries consuming the most resources. The metric is queryable with Database Insights, PromQL, and the Aurora DSQL system diagnostics AI skill, and it is available by default at no additional cost.

Investigate with AI-powered natural language

AWS CloudTrail 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.

The integration lets you check whether your trails are properly configured, identify gaps in 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 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. Q Console queries your trails, associated CloudWatch log groups, and event data stores on your behalf, providing answers grounded in your actual account activity rather than generic documentation.

Collect and enrich logs at scale

Several launches expand what you can collect and how you can enrich it before it reaches your queries and dashboards.

The Amazon CloudWatch agent now supports collecting systemd journal (journald) logs natively on Linux instances, without first writing those logs to files on disk. Many modern Linux distributions, including Amazon Linux 2023, use systemd journal as the primary logging system and no longer write traditional text log files by default. The agent reads journald entries natively, preserving the structured metadata that journald captures such as the systemd unit, priority, and process information. You can filter log entries using systemd units, journal priority levels, and journal field matches, and apply regular expression filters before logs are published, helping you reduce noise and control log volume and costs.

Amazon CloudWatch pipelines now includes three new processors that parse and enrich log data as it is ingested. The Amazon RDS processor parses Aurora audit and error logs into structured fields for compliance reporting. The XML parser converts a field containing an XML string into JSON. The GeoIP processor enriches any IP address field with geographic context such as city, country, and coordinates for security analysis. You can use these processors independently or combine them in one pipeline, and they are available at no additional cost.

CloudWatch Centralization now copies log group tags from source accounts to the destination log groups created by centralization rules and keeps them in sync. A platform team can preserve Application and CostCenter tags on centralized log groups, then use those tags to scope access with IAM conditions and report centralized log spend by team in AWS Cost Explorer.

Monitor network health across Transit Gateway peering

CloudWatch Network Monitoring extended the network health indicator to paths that cross AWS Transit Gateway inter-Region peering connections. Previously, synthetic monitors covered only paths connecting through AWS Direct Connect. Now, for paths that reach a destination in a peered Region over Transit Gateway inter-Region peering, the indicator reflects the health of the AWS network path up to the peering connection. This helps network operators and application developers cut the time spent isolating the source of degradation on these paths.

Deepen AWS service observability integrations

Across the portfolio, AWS services deepened their CloudWatch integrations over the past two months.

AWS HealthOmics now publishes 14 real-time run metrics to CloudWatch spanning CPU and GPU usage, memory usage, file system usage and I/O, network throughput, and ephemeral storage. The metrics are emitted using the CloudWatch OpenTelemetry standard, so you can integrate them with third-party observability tools in addition to native CloudWatch dashboards and alarms. By comparing actual usage against allocated resources, you can right-size the compute and storage configurations for your bioinformatics workflows.

Amazon WorkSpaces and Amazon WorkSpaces Applications both now publish additional performance and session health metrics to CloudWatch, covering network performance (TCP retransmission rate, congestion window), compute resource utilization (GPU usage, CPU queue length), storage metrics (disk I/O queue lengths, memory page hard faults), and session lifecycle events.

Amazon ECS now supports fractional GPU scheduling with Amazon EC2 G6f instances, enabling workloads on GPU partitions as small as one-eighth of an NVIDIA L4 Tensor Core GPU. GPU metrics are available through CloudWatch Container Insights, and automatic health monitoring detects GPU hardware failures and replaces unhealthy instances to minimize workload disruption.

Related blog posts from AWS Cloud Operations Blog (August-September 2026)

Introducing Amazon CloudWatch Omni: Observability for the AI era – Mukul Karnik

Root cause analysis with Amazon Managed Service for Prometheus and AWS DevOps Agent – Mohamed Sherif

Investigate your AWS account activity in plain language with Amazon Q – Rizwan Mohammed, Parijat Protim Bezbaruah, Samir Behara

Reduce MTTR with AI-Driven RCA Using AWS DevOps Agent and Splunk – Amandeep Singh and Aakash Tanwani

Analyze Application Load Balancer Logs with Amazon CloudWatch Logs – Raviteja Sunkavalli and Siva Guruvareddiar

Multi-cloud observability with Amazon CloudWatch using bearer token auth and OpenTelemetry – Imaya Kumar Jagannathan and Stephen McCurry

Use CloudWatch syslog and log alarms to give AWS DevOps Agent on-premises visibility – Salman Ahmed.

Conclusion

The highlight of August and September’s launches is CloudWatch Omni, the AI-first, app-centric observability solution for AI workloads and agents. Alarms get smarter with warm-up periods and wall clock windows that cut noise and align to real-world schedules. Database observability covers the full fleet from Aurora DSQL to self-managed PostgreSQL. AI-powered investigation makes CloudTrail queryable in plain English. Log collection expands to journald, larger API Gateway execution logs, and new pipeline processors. And AWS services across the portfolio publish richer telemetry to CloudWatch, all continuing the OpenTelemetry-first direction.

A few key places to get started:

Create your CloudWatch Omni space and configure SSO for your team, then install the CloudWatch Omni extension for VS Code, Cursor, or Kiro to instrument and evaluate agents locally.

Configure warm-up periods on new alarms to eliminate startup noise, and add wall clock evaluation windows for scheduled or business-aligned workloads.

Enable Database Insights for self-managed PostgreSQL instances running on EC2.

Ask Amazon Q Console about your CloudTrail configuration and account activity.

Add a journald section to your CloudWatch agent configuration, and add GeoIP, RDS, or XML processors to your CloudWatch pipelines.

For the full list of recent launches, visit the AWS What’s New page filtered to Amazon CloudWatch.

Want to see these features in action? Join the next “I Didn’t Know Amazon CloudWatch Could Do That!” webinar on October 13, 2026, 11:00 AM–12:00 PM ET to watch live demos and put these launches to work in your own troubleshooting: Register here.

Authors