AWS News Feed on 🦋

@awsrecentnews.bsky.social

1 day ago

Amazon CloudWatch introduces PromQL querying with Query Studio Preview Amazon CloudWatch announces Query Studio in public preview, a unified query and visualization experience that brings native PromQL querying to CloudWatch for the first time. Query Studio combines PromQL and CloudWatch Metric Insights in a single interface, enabling you to query AWS vended metrics and OpenTelemetry metrics using the language you prefer without switching between consoles. Query Studio provides a visual form builder with autocomplete and a code editor with syntax highlighting, making it accessible to both new and experienced users. For example, a team running applications on Amazon EC2 can correlate their custom OpenTelemetry application metrics with EC2 vended metrics side by side, quickly spot issues across their stack, and create alarms or add charts to dashboards directly from their query results. Amazon CloudWatch Query Studio is available in public preview in US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Singapore), and Europe (Ireland). Standard CloudWatch dashboard pricing applies, see pricing page for details. To get started, open Query Studio from the Metrics console or dashboard edit mode in the Amazon CloudWatch console. Learn more on the Amazon CloudWatch documentation page.

🆕 Amazon CloudWatch's Query Studio preview lets you query and visualize with PromQL in one interface, combining it with Metric Insights for a visual form builder and code editor. Available in select regions with standard pricing.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

1 day ago

Amazon CloudWatch introduces PromQL querying with Query Studio Preview

Amazon CloudWatch announces Query Studio in public preview, a unified query and visualization experience that brings native PromQL querying to CloudWatch for the first time. Query Studio combines Pro...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

2 days ago

Amazon CloudWatch launches OTel Container Insights for Amazon EKS (Preview) Amazon CloudWatch introduces Container Insights with OpenTelemetry metrics for Amazon EKS, available in public preview. Building on the existing Container Insights experience, this capability provides deeper visibility into EKS clusters by collecting more metrics from widely adopted open source and AWS collectors and sending them to CloudWatch using the OpenTelemetry Protocol (OTLP). Each metric is automatically enriched with up to 150 descriptive labels, including Kubernetes metadata and customer-defined labels such as team, application, or business unit. Curated dashboards in the Container Insights console present cluster, node, and pod health with the ability to aggregate and filter metrics by instance type, availability zone, node group, or any custom label. For deeper analysis, customers can write queries using the Prometheus Query Language (PromQL) in CloudWatch Query Studio. The CloudWatch Observability EKS add-on provides one-click installation through the Amazon EKS console, or can be deployed through CloudFormation, CDK, or Terraform. The add-on automatically detects accelerated compute hardware including NVIDIA GPUs, Elastic Fabric Adapters, and AWS Trainium and Inferentia accelerators. For existing customers of the add-on, CloudWatch supports publishing both OpenTelemetry and existing Container Insights metrics at the same time. Container Insights with OpenTelemetry metrics is available in public preview in US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Singapore), and Europe (Ireland). There is no charge for OpenTelemetry metrics from Container Insights during preview. To get started, see the Container Insights with OpenTelemetry metrics for Amazon EKS.

🆕 Amazon CloudWatch previews Container Insights with OpenTelemetry for Amazon EKS, providing enhanced visibility via enriched metrics, Prometheus queries, and easy EKS add-on setup. Available in select regions at no cost.

#AWS #AmazonEks #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

2 days ago

Amazon CloudWatch launches OTel Container Insights for Amazon EKS (Preview)

Amazon CloudWatch introduces Container Insights with OpenTelemetry metrics for Amazon EKS, available in public preview. Building on the existing Container Insights experience, this ca...

#AWS #AmazonEks #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

2 days ago

Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs and 3 additional resource types Amazon CloudWatch now supports automatic enablement of Amazon CloudFront Standard access logs, AWS Security Hub CSPM finding logs, and Amazon Bedrock AgentCore memory and gateway logs and traces to CloudWatch Logs. Customers can set up enablement rules that automatically configure telemetry for both existing and newly created resources, ensuring consistent monitoring coverage without manual setup. Enablement rules can be scoped to the organization, specific accounts, or specific resources based on resource tags to standardize telemetry collection. For example, a central security team can create a single rule to automatically send CloudFront access logs and Security Hub findings for all resources across their organization to CloudWatch Logs. CloudWatch's auto-enablement capability is available in all AWS commercial regions. Log ingestion will be billed according to CloudWatch Pricing. Amazon CloudFront access logs and AWS Security Hub CSPM findings support organization-wide enablement rules. Bedrock AgentCore memory and gateway telemetry support account-level enablement rules. To learn more about enablement rules in Amazon CloudWatch, visit the Amazon CloudWatch documentation.

🆕 Amazon CloudWatch now auto-enables CloudFront logs, Security Hub CSPM findings, and Bedrock AgentCore telemetry to CloudWatch Logs, simplifying monitoring setup across accounts and resources. Available in all commercial regions, log billing follows CloudWatch pricing.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

2 days ago

Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs and 3 additional resource types

Amazon CloudWatch now supports automatic enablement of Amazon CloudFront Standard access logs, AWS Security Hub CSPM finding logs, and Amazon Bedrock AgentCore memory and...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

4 days ago

Amazon CloudWatch now supports ingesting Security Hub CSPM findings with organization-wide enablement Amazon CloudWatch now supports ingesting AWS Security Hub CSPM findings, enabling customers to centrally analyze and monitor security findings directly in CloudWatch Logs. Security Hub CSPM findings are supported in AWS Security Finding Format (ASFF) and Open Cybersecurity Schema Framework (OCSF) format using CloudWatch Pipelines, providing standardized security data ingestion. Customers can now use CloudWatch Logs Insights to query findings, create metric filters for monitoring, and leverage Amazon S3 Tables integration for advanced analytics, helping security teams identify and respond to threats faster across their AWS environment. With today's launch, customers can automatically enable Security Hub findings delivery to CloudWatch Logs using CloudWatch enablement rules that apply to the entire organization or specific accounts, to standardize security monitoring coverage. For example, a security team can create an enablement rule to automatically send Security Hub findings to CloudWatch Logs for all production accounts, ensuring consistent visibility into security posture. Security Hub findings to CloudWatch logs are available in all AWS commercial regions. Security Hub findings are charged as tiered pricing when delivered to CloudWatch Logs. For pricing information, see the CloudWatch pricing page. To learn more about Security Hub findings in CloudWatch Logs and organization-level enablement, visit the Amazon CloudWatch documentation..

🆕 Amazon CloudWatch now ingests Security Hub CSPM findings for centralized monitoring in CloudWatch Logs. This organization-wide enablement enhances security visibility across all accounts in all commercial regions. Pricing details are on the CloudWatch pricing page.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

4 days ago

Amazon CloudWatch now supports ingesting Security Hub CSPM findings with organization-wide enablement

Amazon CloudWatch now supports ingesting AWS Security Hub CSPM findings, enabling customers to centrally analyze and monitor security findings directly in CloudWatch L...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

5 days ago

Amazon CloudWatch now supports multi-account and region log centralization based on data source Amazon CloudWatch centralization now supports centralizing logs based on data source name and type. CloudWatch allows customers to copy log data from multiple AWS accounts and regions into a single destination account using centralization rules. With today's launch, customers can now define rules that target data sources by name and type, such as VPC Flow Logs, EKS Audit Logs, and CloudTrail Logs, in addition to the existing log group name-based selection. Data source name and type are discovered automatically by CloudWatch for AWS service logs and are based on log group tags for application logs.  Now, customers can specifically target which logs they want to centralize using these parameters. For example, a central security team can create a rule that centralizes all logs from CloudTrail and VPC data sources across their entire organization without needing to know or maintain a list of individual log group names. To get started, create or modify a centralization rule in the Amazon CloudWatch console or through the AWS CLI and AWS SDKs, and specify your data source selection criteria in the centralization rule configuration. Data source selection criteria is available in all AWS commercial regions where CloudWatch log centralization is available. Standard CloudWatch Logs pricing applies for log ingestion, storage, and data transfer. For more information, see the CloudWatch Logs Centralization documentation.

🆕 Amazon CloudWatch centralizes logs from various accounts and regions by data source, enabling focused collection for VPC Flow, EKS Audit, and CloudTrail logs. Manage rules in the console or CLI/SDKs. Available globally; standard pricing.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

5 days ago

Amazon CloudWatch now supports multi-account and region log centralization based on data source

Amazon CloudWatch centralization now supports centralizing logs based on docs.aws.amazon.com/AmazonCloudWatch/latest/... Cloud...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

5 days ago

AWS Direct Connect adds CloudWatch metrics for BGP monitoring AWS Direct Connect now publishes three new Amazon CloudWatch metrics for virtual interfaces (VIFs) that provide visibility into Border Gateway Protocol (BGP) session health and route counts. Network engineers and operations teams managing hybrid cloud connectivity can now monitor BGP sessions natively through CloudWatch without building custom solutions or polling APIs. These metrics solve critical monitoring gaps that previously required custom Lambda functions or on-premises network management tools. VirtualInterfaceBgpStatus reports BGP session state, enabling detection when sessions fail. VirtualInterfaceBgpPrefixesAccepted tracks prefixes from your on-premises network, allowing proactive alarms before reaching prefix limits that would cause BGP sessions to enter idle state. VirtualInterfaceBgpPrefixesAdvertised monitors routes AWS advertises to your network, helping validate configuration changes and detect silent route withdrawals that impact traffic even when BGP sessions remain up. These metrics are available for private, public, and transit virtual interfaces in all commercial AWS Regions. You can integrate them with CloudWatch alarms, dashboards, and Amazon SNS for comprehensive BGP monitoring, reducing mean time to detect network issues and simplifying operations for multi-region and disaster recovery architectures. To learn more about AWS Direct Connect, visit https://aws.amazon.com/directconnect/.

🆕 AWS Direct Connect adds three CloudWatch metrics for BGP monitoring on virtual interfaces, improving session health and route visibility, simplifying network management. Metrics cover session state, prefix tracking, and route advertising. Available globa…

#AWS #AwsDirectConnect #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

5 days ago

AWS Direct Connect adds CloudWatch metrics for BGP monitoring

AWS Direct Connect now publishes three new Amazon CloudWatch metrics for virtual interfaces (VIFs) that provide visibility into Border Gateway Protocol (BGP) session health and route counts....

#AWS #AwsDirectConnect #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

1 week ago

AWS Weekly Roundup: NVIDIA Nemotron 3 Super on Amazon Bedrock, Nova Forge SDK, Amazon Corretto 26, and more (March 23, 2026)

Hello! I’m Daniel Abib,...

#AWS #AmazonBedrockAgentcore #AmazonCloudwatch #AmazonConnect #AmazonCorretto #AmazonNova #AmazonRedshift #AwsLambda #Kiro #News #WeekInReview

AWS News Feed on 🦋

@awsrecentnews.bsky.social

2 weeks ago

Amazon CloudWatch introduces organization-wide EC2 detailed monitoring enablement Amazon CloudWatch now allows customers to automatically enable Amazon Elastic Compute Cloud (EC2) detailed monitoring across their AWS Organization. Customers can create enablement rules in CloudWatch Ingestion that automatically enable detailed monitoring for both existing and newly launched EC2 instances matching the rule scope, ensuring consistent metrics collection at 1-minute intervals across their EC2 instances. EC2 detailed monitoring enablement rules can be scoped to the whole organization, specific accounts, or specific resources based on resource tags to standardize the configuration across EC2 instances. For example, the central DevOps team can create an enablement rule to automatically turn on detailed monitoring for EC2 instances with specific tags, e.g., env:production, and ensure Auto Scaling policies respond quickly to changes in instance utilization. CloudWatch's auto-enablement capability is available in all AWS commercial regions. Detailed monitoring metrics will be billed according to CloudWatch Pricing. To learn more about org-wide EC2 detailed monitoring enablement, visit the Amazon CloudWatch documentation.

🆕 Amazon CloudWatch now enables organization-wide EC2 detailed monitoring across AWS Orgs, automatically applying it to existing and new instances based on rules, ensuring consistent 1-min metrics collection. Available in all commercial regions; pricing per CloudWatch.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

2 weeks ago

Amazon CloudWatch introduces organization-wide EC2 detailed monitoring enablement

Amazon CloudWatch now allows customers to automatically enable Amazon Elastic Compute Cloud (EC2) detailed monitoring across their AWS Organization. Customers can create enablement rules i...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

3 weeks ago

Amazon CloudWatch Application Signals adds new SLO capabilities Amazon CloudWatch Application Signals now offers three new console based capabilities for Service Level Objectives (SLOs): SLO Recommendations, Service-Level SLOs, and SLO Performance Report. CloudWatch Application Signals helps customers monitor and improve application performance on AWS. It automatically collects data from applications running on services like Amazon EC2, Amazon ECS, and Lambda. Previously, customers had to manually set SLO thresholds without data-driven guidance, often leading to misconfigured targets and alert fatigue. They also lacked visibility into overall service health across operations and had no way to track reliability trends over time or generate calendar periods performance reports. These new capabilities address each of those gaps, making it easier to set data-driven reliability targets, monitor overall service health, and identify reliability trends before they become incidents. SLO Recommendations analyzes 30 days of service metrics (P99 latency and error rates) to suggest appropriate reliability targets. Customers can validate proposed targets before implementation to help reduce the cognitive and operational effort needed for new SLO deployments. Service-Level SLOs provide a holistic view of service reliability across all operations, simplifying alignment between technical monitoring and business objectives. SLO Performance Report provides historical analysis aligned with calendar periods, supporting daily, weekly, and monthly intervals. These capabilities support key use cases including proactive reliability management, SLO threshold optimization, and business reporting aligned with calendar periods. These features are available in all AWS Regions where Amazon CloudWatch Application Signals is available. Pricing is based on the number of inbound and outbound requests to and from applications, plus Service Level Objectives charges, with each SLO generating 2 application signals per service level indicator metric period.

🆕 Amazon CloudWatch Application Signals now offers SLO Recommendations, Service-Level SLOs, and SLO Performance Reports to help set reliable targets, monitor service health, and track trends, simplifying proactive reliability management and SLO optimization across AWS regio…

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

3 weeks ago

Amazon CloudWatch Application Signals adds new SLO capabilities

Amazon CloudWatch Application Signals now offers three new console based capabilities for Service Level Objectives (SLOs): SLO Recommendations, Service-Level SLOs, and SLO Performance Report. CloudWatch App...

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

3 weeks ago

Amazon CloudWatch Logs announces increased query concurrency and API limits

Amazon CloudWatch Logs customers can now run up to 100 concurrent queries per account and execute 10 StartQuery and GetQueryResults API calls per second per account/per-reg...

#AWS #AmazonCloudwatch #AmazonCloudwatchLogs

AWS News Feed on 🦋

@awsrecentnews.bsky.social

3 weeks ago

Amazon CloudWatch Logs announces increased query concurrency and API limits Amazon CloudWatch Logs customers can now run up to 100 concurrent queries per account and execute 10 StartQuery and GetQueryResults API calls per second per account/per-region, using the Logs Insights Query Language (Logs Insights QL). These limit increases enable customers to support more users and execute more concurrent queries. With concurrency increasing from 30 to 100, more users can simultaneously run queries and leverage dashboards using Logs Insights QL. Customers using StartQuery and GetQueryResults APIs for Logs Insights QL benefit from higher limits without being throttled, enabling them to execute more queries and view results faster. The limit increases for Logs Insights queries is available in US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), Canada (Calgary), South America (São Paulo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Europe (Milan), Europe (Zurich), Europe (Spain), Africa (Cape Town), Middle East(Tel Aviv), Asia Pacific (Mumbai), Asia Pacific (Hyderabad), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Melbourne), Asia Pacific (Tokyo), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Hong Kong), Asia Pacific (Jakarta), Asia Pacific (Bangkok), Asia Pacific (Malaysia), Asia Pacific (Auckland), Asia Pacific (Taipei), and Mexico (Querétaro). For more information, visit the  Amazon CloudWatch Logs documentation.

🆕 Amazon CloudWatch Logs boosts query concurrency to 100 per account and API calls to 10/sec, enabling more users to run queries and view results faster across 26 regions. For details, see Amazon CloudWatch Logs documentation.

#AWS #AmazonCloudwatch #AmazonCloudwatchLogs

AWS News Feed on 🦋

@awsrecentnews.bsky.social

1 month ago

Application Performance Monitoring Enabled by Default in CloudWatch Observability EKS Add-on Today, Amazon CloudWatch Observability EKS add-on version 5.0.0 automatically enables CloudWatch Application Signals — Amazon's application performance monitoring (APM) capability — for all new installations and upgrades, eliminating the previous manual opt-in step. Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that simplifies running containerized applications at scale. The CloudWatch Observability add-on for EKS extends native Kubernetes observability by integrating Enhanced Container Insights, Container Logs, and now Application Signals directly into your clusters. The Observability add-on automatically instruments your services to collect traces, metrics, and logs for a unified, application-centric view. For DevOps engineers, platform teams, and developers who needed application-level visibility into their EKS-hosted services — such as service latency, error rates, and request traces — this change closes that gap by making those capabilities available out of the box, so teams can focus on building and operating applications rather than configuring observability tooling.azon EKS. With Application Signals now enabled by default, customers immediately benefit from automatic service instrumentation — no manual configuration or Kubernetes workload annotations required — along with pre-built dashboards that surface application performance metrics and a rich troubleshooting experience that goes beyond infrastructure-level data to help teams quickly identify and resolve issues. For example, a platform team managing a microservices application on EKS can now detect latency spikes or error rate increases at the service level without any additional setup, accelerating root cause analysis during incidents. This feature is available in all commercial AWS regions where Amazon CloudWatch Application Signals is available; to get started, you can refer to the Amazon CloudWatch Application Signals documentation and upgrade to version 5.0.0 of the add-on.

🆕 Amazon CloudWatch EKS add-on v5.0.0 now defaults to Application Signals, offering automatic performance monitoring for new EKS setups, pre-built dashboards, and quick issue resolution in all commercial AWS regions.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

Application Performance Monitoring Enabled by Default in CloudWatch Observability EKS Add-on

Today, Amazon CloudWatch Observability EKS add-on version 5.0.0 automatically enables CloudWatch Application Signals — Amazon's application performance monitoring (APM) capabi...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

1 month ago

Amazon CloudWatch logs centralization rules now support customizable destination log group structure Amazon CloudWatch now supports customizing destination log group names when creating CloudWatch log centralization rules. Organizations managing logs across multiple accounts can now use attributes to organize centralized logs into meaningful hierarchies — by account ID, region, organizational unit, or other AWS Organizations metadata — that match how their organization operates and what their compliance requirements demand. You can define a destination log group name structure using attributes that CloudWatch Logs automatically replaces with actual values when logs are copied. For example, using the pattern ${source.accountId}/${source.region}/${source.logGroup} creates destination log groups like 123456789012/us-east-1/cloudtrail/managementevent, making it easy to identify which account and region logs originated from. You can use attributes, including source account ID, region, log group name, organization ID, organizational unit ID, root ID, and the full organizational path. Customizable destination log group names are available in all centralization rules supported regions. Customers can use centralization rules to centralize one copy of logs for free (ingestion). Additional copies are charged at $0.05/GB of logs centralized (the backup region feature is considered an additional copy). Storage charges apply. To learn more, visit the CloudWatch Logs Centralization documentation.

🆕 Amazon CloudWatch lets you name log groups for better organization, aiding compliance and management. Available everywhere, free for one copy, $0.05/GB for more.

#AWS #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

Amazon CloudWatch logs centralization rules now support customizable destination log group structure

Amazon CloudWatch now supports customizing destination log group names when creating CloudWatch log centralization rules. Organizations managing logs across multiple acc...

#AWS #AmazonCloudwatch

AWS News Feed on 🦋

@awsrecentnews.bsky.social

1 month ago

AWS Outposts racks now support additional Amazon CloudWatch metrics in AWS GovCloud (US) Regions AWS Outposts racks now support VifConnectionStatus and VifBgpSessionState Amazon CloudWatch metrics in AWS GovCloud (US) Regions. These metrics provide visibility into the connectivity status of your Outposts racks' Local Gateway (LGW) and Service Link Virtual Interfaces (VIFs) with your on-premises devices. These metrics provide you with the ability to monitor Outposts VIF connectivity status directly within the CloudWatch console, without having to rely on external networking tools or coordination with other teams. You can use these metrics to set alarms, troubleshoot connectivity issues, and ensure your Outposts racks are properly integrated with your on-premises infrastructure. The VifConnectionStatus metric indicates whether an Outposts VIF is successfully connected, configured, and ready to forward traffic. A value of "1" means that the VIF is operational, while "0" means that it is not ready. The VifBgpSessionState metric shows the current state of the BGP session between the Outposts VIF and the on-premises device, with values ranging from 1 (IDLE) to 6 (ESTABLISHED). The VifConnectionStatus and VifBgpSessionState metrics are now available for all Outposts VIFs in AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions where Outposts racks are available. To get started, read this blog post and access the metrics in the CloudWatch console. To learn more, check out the CloudWatch metrics for Outposts documentation for first-generation Outposts racks.

🆕 AWS Outposts racks now support VifConnectionStatus and VifBgpSessionState metrics in AWS GovCloud (US), providing better visibility for Local Gateway and Service Link Virtual Interfaces, allowing direct monitoring in CloudWatch.

#AWS #AmazonCloudwatch #AwsOutposts

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

AWS Outposts racks now support additional Amazon CloudWatch metrics in AWS GovCloud (US) Regions

AWS Outposts racks now support VifConnectionStatus and VifBgpSessionState Amazon CloudWatch metrics in AWS GovCloud (US) Regions. These metrics provide visibili...

#AWS #AmazonCloudwatch #AwsOutposts

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

AWS Weekly Roundup: Amazon EC2 G7e instances, Amazon Corretto updates, and more (January 26, 2026)

Hey! It’s my first post for 2026, and I’m writing to you while watching o...

#AWS #AmazonCloudwatch #AmazonConnect #AmazonCorretto #AmazonEc2 #AmazonElasticContainerRegistry #News #WeekInReview

AWS News Feed on 🦋

@awsrecentnews.bsky.social

1 month ago

AWS Observability now available as a Kiro power Today, AWS announces AWS Observability as a Kiro power, enabling developers and operators to investigate infrastructure and application health issues faster with AI agent-assisted workflows in Kiro. Kiro Powers is a repository of curated and pre-packaged Model Context Protocol (MCP) servers, steering files, and hooks validated by Kiro partners to accelerate specialized software development and deployment use cases. The AWS Observability power packages four specialized MCP servers with targeted observability guidance: the CloudWatch MCP server for observability data; the Application Signals MCP server for application performance monitoring; the CloudTrail MCP server for security analysis and compliance; and the AWS Documentation MCP server for contextual reference access. This unified platform gives Kiro agents instant context for comprehensive workflows including alarm response, anomaly detection, distributed tracing, SLO compliance monitoring, and security investigation. Additionally, the power includes automated gap analysis that helps you identify and fix missing instrumentation. With the AWS Observability power, developers can now accelerate troubleshooting their distributed applications and infrastructure in minutes, directly in their IDE. The power addresses two critical needs: reducing mean time to resolution (MTTR) for active incidents and proactively improving your observability stack. For faster incident response, when investigating an active alarm, the power dynamically loads relevant guidance and operational signals so AI agents receive only the context needed for the specific troubleshooting task at hand. For stack improvement, the automated gap analysis examines your code to identify missing instrumentation patterns—such as unlogged errors, missing correlation IDs, or absent distributed tracing—and provides actionable recommendations. The power includes eight comprehensive steering guides covering incident response, alerting, performance monitoring, security auditing, and gap analysis. The AWS Observability power is available for one-click installation within Kiro IDE and Kiro powers webpage in all AWS Regions, with each underlying MCP server functional based on regional support of the corresponding AWS service. To learn more about AWS observability MCP servers, visit our documentation.

🆕 AWS Observability is a Kiro power for quicker issue investigation via AI workflows. It has four MCP servers for observability, performance, security, and docs. Easily installable in Kiro IDE, it cuts MTTR and boosts observability.

#AWS #AwsCloudtrail #AmazonCloudwatch

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

AWS Observability now available as a Kiro power

Today, AWS announces AWS Observability as a Kiro power, enabling developers and operators to investigate infrastructure and application health issues faster with AI agent-assisted workflows in Kiro. Kiro Pow...

#AWS #AwsCloudtrail #AmazonCloudwatch

AWS Community Builder Blog Posts

@awscmblogposts.bsky.social

1 month ago

Deep Dive on Loop Filter as Metric Filter in Amazon CloudWatch “ I have checked the documents of AWS for deep dive on loop filter as metric filter in amazon...

✍️ New blog post by GargeeBhatnagar

Deep Dive on Loop Filter as Metric Filter in Amazon CloudWatch

#aws #amazoncloudwatch #cloudtrail #s3bucket

AWS News(Unofficial)

@awsnews.bsky.social

1 month ago

AWS CloudWatch Alarm Mute Rules eliminate alert fatigue

Amazon CloudWatch now supports Alarm Mute Rules, enabling customers to temporarily mute alarm notifications during planned deployments, maintenance windows, and off-hours without compromising monitoring visibility....

#AWS #AmazonCloudwatch