CloudWatch Application Insights: Setup and What It Actually Monitors

CloudWatch Application Insights automates the monitoring setup for enterprise applications running on AWS, but most teams discover its limits only after onboarding their first workload. It sets up relevant metrics, logs, and alarms automatically across EC2 instances, EBS volumes, ELB load balancers, and RDS databases. What catches teams off guard is what it does not monitor out of the box: container workloads, Lambda functions outside specific patterns, and anything running outside the resource groups it recognizes.

This guide walks through the complete setup process, covers exactly what Application Insights monitors across different AWS services, and documents the common configuration problems teams hit during deployment. By the end, you will know how to onboard an application, what telemetry appears automatically, and where you need to fill gaps with custom CloudWatch configurations or alternative tools.

Prerequisites

Before starting CloudWatch Application Insights setup, verify these requirements:

• AWS account with permissions to create CloudWatch resources, IAM roles, and Systems Manager resources
• Target application resources organized into a resource group or tagged consistently
• CloudWatch agent installed on EC2 instances if monitoring Windows or custom application metrics
• Systems Manager agent (SSM agent) running on EC2 instances for automated configuration
• Application resources deployed in a single AWS region (Application Insights operates per region)
• For SQL Server workloads: Windows Server 2012 R2 or later with SQL Server 2012 or later installed

Step 1: Create or Identify Your Application Resource Group

Application Insights organizes monitoring around AWS resource groups. Every application you want to monitor needs a resource group containing all its components.

Navigate to AWS Resource Groups in the AWS console. Create a new resource group or select an existing one. The resource group can be tag based or CloudFormation stack based.

For a tag based group, define tags that identify all components of your application. For example, if your application uses Application:WebApp and Environment:Production tags across EC2 instances, RDS databases, and load balancers, create a resource group query matching those tags.

aws resource-groups create-group \
  --name MyAppResourceGroup \
  --resource-query '{"Type":"TAG_FILTERS_1_0","Query":"{\"ResourceTypeFilters\":[\"AWS::AllSupported\"],\"TagFilters\":[{\"Key\":\"Application\",\"Values\":[\"WebApp\"]},{\"Key\":\"Environment\",\"Values\":[\"Production\"]}]}"}'

For CloudFormation based groups, select the stack that deployed your application infrastructure. This automatically includes all resources created by that stack.

Verify the resource group contains all components you want to monitor by reviewing the Resources tab in the resource group console. Common missing components: EBS volumes not explicitly tagged, security groups, or resources in different regions.

Step 2: Enable Application Insights for Your Resource Group

Navigate to CloudWatch in the AWS console, then select Application Insights under Insights in the left navigation.

Click Add an application. Select the resource group you created in Step 1 from the dropdown list.

Application Insights scans the resource group and detects supported components automatically. It identifies application tiers based on resource types: web tier (ELB, Application Load Balancer), application tier (EC2 instances), database tier (RDS instances), and supporting infrastructure (EBS volumes, SQS queues).

The detection process takes 30 to 60 seconds. Once complete, Application Insights displays the detected components organized by tier. Review each tier to confirm all expected resources appear.

For SQL Server workloads deployed via AWS Launch Wizard, Application Insights automatically configures SQL Server specific metrics including failover events, Always On availability group health, and transaction log performance. For other workloads, it applies default monitoring templates based on detected technologies.

Click Enable monitoring. Application Insights creates the following resources automatically:

• CloudWatch alarms for each monitored metric with dynamic thresholds based on historical patterns
• CloudWatch Logs log groups for application logs, system logs, and Windows Event Logs
• Systems Manager Parameter Store parameters containing CloudWatch agent configurations
• IAM roles granting CloudWatch agent permissions to publish metrics and logs

This process takes 5 to 10 minutes. Application Insights deploys the CloudWatch agent to EC2 instances via Systems Manager Run Command if not already installed.

Step 3: Configure Component Monitoring Settings

After enabling Application Insights, configure monitoring for each application component. Click the application name in Application Insights, then select the Components tab.

Each component displays its monitoring status and configuration template. Application Insights applies templates automatically based on detected workload types:

For EC2 instances running IIS, it monitors IIS worker process metrics, ASP.NET request queue length, and IIS log errors.

For EC2 instances running SQL Server, it monitors SQL Server buffer cache hit ratio, batch requests per second, user connections, deadlocks per second, and SQL Server error logs.

For RDS databases, it monitors CPU utilization, database connections, read and write latency, and storage metrics.

For load balancers, it monitors target health, request count, HTTP 4xx and 5xx error rates, and target response time.

To customize monitoring for a specific component, select the component and click Edit monitoring. Application Insights displays the active monitoring template with configurable sections:

The Logs section lists log files collected by the CloudWatch agent. Default logs for Windows EC2 instances include Application Event Log, System Event Log, and Security Event Log. For IIS, it includes IIS access logs and error logs. Add custom log paths here if your application writes logs to non standard locations.

{
  "logs": {
    "logs_collected": {
      "windows_events": {
        "collect_list": [
          {"event_name": "Application", "event_levels": ["ERROR", "WARNING"]},
          {"event_name": "System", "event_levels": ["ERROR", "WARNING"]}
        ]
      },
      "files": {
        "collect_list": [
          {
            "file_path": "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\*.log",
            "log_group_name": "/aws/application-insights/MyApp/IIS",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

The Metrics section lists performance counters collected by the CloudWatch agent. Default metrics for Windows EC2 instances include CPU utilization, memory committed bytes, disk read and write operations, and network bytes sent and received. For SQL Server, it includes SQL Server specific counters like buffer manager page life expectancy and general statistics processes blocked.

Add custom metrics by specifying the Windows performance counter path or Linux metric source. Each custom metric incurs additional CloudWatch custom metric charges at $0.30 per metric per month.

The Alarms section shows CloudWatch alarms created for this component. Application Insights creates alarms with dynamic thresholds that adapt based on the previous two weeks of metric behavior. You can adjust alarm thresholds here or disable specific alarms that generate noise.

Click Save after making changes. Application Insights updates the CloudWatch agent configuration via Systems Manager within 2 to 5 minutes.

Step 4: Set Up CloudWatch Application Insights Notifications

Application Insights generates CloudWatch Events when it detects problems with your application. Configure notifications to receive alerts via SNS, Lambda, or other AWS services.

Navigate to Amazon EventBridge (formerly CloudWatch Events) in the AWS console. Click Create rule.

For Event pattern, select Custom pattern and paste this pattern to match Application Insights problem detection events:

{
  "source": ["aws.applicationinsights"],
  "detail-type": ["Application Insights Problem Detected"]
}

This pattern captures all problem detection events across all applications monitored by Application Insights. To limit notifications to a specific application, add a filter on the detail.applicationArn field.

For Select targets, choose SNS topic and select an existing topic or create a new one. Alternatively, choose Lambda function to trigger custom automation when problems are detected.

Click Create rule. Application Insights now sends notifications whenever it detects metric anomalies, log errors, or correlated problems across multiple components.

To reduce alert noise, Application Insights groups related observations into a single problem. For example, if an EC2 instance experiences high CPU, memory pressure, and increased error log entries simultaneously, Application Insights creates one problem containing all three observations rather than three separate alerts.

Step 5: View Application Insights Dashboards and Detected Problems

Application Insights creates automatic dashboards showing application health, detected problems, and correlated observations.

Navigate to CloudWatch Application Insights in the AWS console and click your application name. The Overview tab displays application health status and a timeline of detected problems.

The Problems tab lists all detected problems with severity, start time, and affected components. Click a problem to view the automatically generated dashboard showing correlated metric anomalies and log errors.

Each problem dashboard includes:

• Timeline showing when each observation occurred
• Metric graphs highlighting anomalies compared to baseline behavior
• Log excerpts showing error messages from the time period
• Potential root cause analysis generated by Application Insights

For SQL Server workloads, Application Insights provides additional insights for failover events, showing metrics from primary and secondary replicas before and after the failover.

The Insights tab shows longer term trends and patterns Application Insights has identified across your application, such as recurring performance degradation at specific times or correlations between deployment changes and increased error rates.

To investigate a specific component outside a detected problem, go to the Components tab, select the component, and click View CloudWatch metrics. This opens the standard CloudWatch metrics console filtered to that component.

What CloudWatch Application Insights Actually Monitors

Application Insights automatically monitors these AWS resource types when they appear in your resource group:

EC2 instances: CPU utilization, status checks, memory committed bytes, memory available MB, disk percent disk time, network interface bytes total per second, paging file percent usage. For instances running IIS, it adds IIS worker process metrics, ASP.NET application queue length, and request execution time. For instances running SQL Server, it adds SQL Server buffer manager cache hit ratio, buffer manager page life expectancy, SQL statistics batch requests per second, general statistics user connections, locks number of deadlocks per second, and access methods full scans per second.

EBS volumes: Volume read bytes, volume write bytes, volume read ops, volume write ops, volume total read time, volume total write time, volume idle time, volume queue length, volume throughput percentage, volume consumed read write ops, and burst balance.

ELB (Classic Load Balancer): Healthy host count, unhealthy host count, request count, latency, HTTP 4xx count, HTTP 5xx count, and backend connection errors.

Application Load Balancer and Network Load Balancer: Active connection count, target response time, HTTP 4xx and 5xx counts, healthy and unhealthy target counts, processed bytes, and request count per target.

RDS database instances: CPU utilization, database connections, freeable memory, read latency, write latency, read throughput, write throughput, read IOPS, write IOPS, and free storage space. For SQL Server on RDS, it adds failed agent jobs count and oldest replication transaction age.

Amazon SQS queues: Approximate number of messages visible, approximate number of messages delayed, approximate age of oldest message, number of messages sent, and number of messages received.

Auto Scaling groups: Group desired capacity, group in service instances, group minimum size, group maximum size, and group total instances.

AWS Lambda functions (limited support): Invocations, errors, throttles, duration, and concurrent executions. Application Insights does not monitor Lambda logs automatically or provide function level insights. For comprehensive Lambda observability, teams typically need additional tooling.

Step Functions state machines: Executions started, executions succeeded, executions failed, executions timed out, and execution time.

What Application Insights does not monitor without additional configuration:

• Container workloads running on ECS, EKS, or Fargate require custom CloudWatch Container Insights setup
• Application code level traces require AWS X-Ray integration configured separately
• Custom application metrics require explicit CloudWatch agent configuration with application specific collection rules
• Third party services or external APIs called by your application require synthetic monitoring via CloudWatch Synthetics
• Database query performance deeper than top level RDS metrics requires Performance Insights enabled separately

For observability needs beyond what Application Insights provides automatically, teams often supplement with OpenTelemetry instrumentation for distributed tracing or use infrastructure monitoring platforms that provide deeper visibility across hybrid and multi cloud environments.

Monitoring SQL Server High Availability Workloads with Application Insights

Application Insights provides specialized monitoring for SQL Server Always On availability groups and failover cluster instances deployed on AWS.

When you deploy SQL Server high availability via AWS Launch Wizard and enable Application Insights integration during deployment, it automatically configures monitoring for these SQL Server specific metrics:

• Mirrored write transactions per second indicating replication throughput
• Recovery queue length showing pending transactions on secondary replicas
• Transaction delay measuring replication lag between primary and secondary
• Log send queue KB indicating volume of transaction log waiting to replicate
• Redo queue KB showing uncommitted transaction log on secondary replicas

Application Insights also monitors Windows failover cluster resources including cluster service status, node membership changes, and quorum status.

When a failover occurs, Application Insights detects the event and creates an automated insight showing metrics from both primary and secondary replicas before, during, and after the failover. This includes CPU and memory utilization on both nodes, SQL Server connection counts, batch request rates, and lock statistics.

Teams report this failover visibility as one of Application Insights’ most valuable features for SQL Server workloads. Failover events often happen during off hours or in response to infrastructure issues that are hard to reproduce, making automated capture of surrounding telemetry essential for root cause analysis.

Troubleshooting Common Issues

Problem: Application Insights shows “No data available” for EC2 metrics

This usually indicates the CloudWatch agent is not running or cannot publish metrics. Check these items in order:

Verify the EC2 instance has the CloudWatch agent installed. SSH to the instance and run sudo systemctl status amazon-cloudwatch-agent (Linux) or check Services for “Amazon CloudWatch Agent” (Windows).

If the agent is not installed, Application Insights installs it via Systems Manager Run Command. Verify the instance has Systems Manager agent running and is showing as managed in the Fleet Manager console.

Check the IAM role attached to the instance includes the CloudWatchAgentServerPolicy managed policy. Without this policy, the agent cannot publish metrics to CloudWatch.

Review CloudWatch agent logs at /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log (Linux) or C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log (Windows) for error messages indicating configuration problems or permission issues.

Problem: Custom application logs are not appearing in CloudWatch Logs

Application Insights configures the CloudWatch agent to collect common log files automatically, but custom application logs require explicit configuration.

Edit the component monitoring configuration in Application Insights and add your custom log file paths to the Logs section. Specify the full path including wildcards if needed, the target log group name, and the log stream name pattern.

After saving the configuration, Application Insights updates the agent configuration file stored in Systems Manager Parameter Store and restarts the CloudWatch agent. This process takes 2 to 5 minutes.

If logs still do not appear, verify the CloudWatch agent process has read permissions on the log files and write permissions on the log directory. On Linux, the agent runs as the cwagent user by default.

Problem: CloudWatch alarms are triggering too frequently or not at all

Application Insights creates alarms with dynamic thresholds based on historical metric behavior. During the first two weeks after enabling monitoring, alarm thresholds may not accurately reflect normal application behavior because there is insufficient historical data.

Wait at least two weeks after enabling Application Insights before adjusting alarm configurations. The dynamic thresholds improve as more data accumulates.

For alarms that consistently trigger during known high traffic periods, adjust the alarm threshold manually or change the evaluation period to smooth out short term spikes.

For alarms that never trigger despite visible problems, verify the metric is actually being collected. Some metrics depend on specific CloudWatch agent configuration or require features like detailed monitoring enabled.

Problem: Application Insights cannot detect components in my resource group

Application Insights detects components based on resource types. Verify the resource group contains supported resource types listed earlier in this guide.

Resources in different AWS regions will not be detected. Application Insights operates within a single region. If your application spans multiple regions, create separate Application Insights applications in each region.

For EC2 instances to be fully monitored, they must have Systems Manager agent installed and the instance must appear as managed in Fleet Manager. Instances without SSM agent will be detected but Application Insights cannot deploy CloudWatch agent configuration automatically.

Problem: Data ingest costs are higher than expected

Application Insights creates CloudWatch custom metrics and ingests log data, both of which incur charges. Review the CloudWatch pricing page for current rates.

For a single EC2 instance running SQL Server, Application Insights typically creates 13 custom metrics at $0.30 per metric per month totaling $3.90 monthly. It also creates 26 CloudWatch alarms at $0.10 per alarm per month totaling $2.60 monthly.

Log ingestion costs depend on log volume. Each GB ingested costs $0.50, and storage costs $0.03 per GB per month. For a typical SQL Server instance generating 10 GB of logs monthly, expect $5.30 in log related charges.

To reduce costs, edit component monitoring configurations and remove metrics or logs you do not need. Disable alarms that generate noise without providing value.

Monitoring Applications with CubeAPM as an Alternative

Teams that need observability beyond what CloudWatch Application Insights provides, particularly for containerized workloads, multi cloud environments, or deeper application code visibility, often evaluate platforms that offer unified monitoring across infrastructure and application layers.

CubeAPM provides OpenTelemetry native monitoring for applications running on AWS, Azure, GCP, or on premises infrastructure. It collects distributed traces, metrics, logs, and infrastructure data in a single platform that runs inside your own VPC or data center.

For AWS workloads, CubeAPM monitors EC2 instances, ECS containers, EKS clusters, Lambda functions, RDS databases, and other AWS services through native integrations and OpenTelemetry receivers. Unlike CloudWatch Application Insights which requires resource groups and operates within a single region, CubeAPM provides a unified view across all environments and regions.

CubeAPM’s deployment model keeps all telemetry data within your infrastructure, eliminating CloudWatch data transfer costs that can reach $0.10 per GB when sending logs and metrics to AWS managed services. For teams ingesting 10 TB of observability data monthly, this represents $1,000 in monthly savings on data transfer alone before considering CloudWatch ingestion charges.

The platform uses predictable pricing at $0.15 per GB ingested with unlimited data retention and no per user seat charges. Monitoring the same 10 TB monthly workload costs $1,500 on CubeAPM compared to $3,500 on CloudWatch ingestion charges plus alarm costs plus custom metric charges.

For teams already using OpenTelemetry instrumentation or planning to adopt it, CubeAPM accepts OpenTelemetry data natively without requiring proprietary agents or SDKs. This avoids vendor lock in and makes it possible to change observability backends without re-instrumenting applications.

Application Insights fills a specific need for teams running traditional EC2 based applications on AWS who want basic monitoring without managing infrastructure. For teams with more complex requirements including containers, serverless, multi cloud, or deeper code level observability, evaluating platforms designed for full stack visibility often provides better long term value.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions