AI/ML-powered Anomaly Detection
for AWS Metrics

Yes. AI Monitor deploys as a guest on a running Log Processor stack — it uses the same VPC, subnets, and OpenSearch domain. The Log Processor owns the cluster; AI Monitor writes to its own OpenSearch index pattern (metrics-*) and reads other metric baselines for correlation. We provision example metric dashboards, feel free to create your own (View list).

Yes in the enterprise plan. Add your SAML or OIDC identity provider to the Cognito User Pool using the sso helper script. Users will see a “Sign in with [Provider]” button on the login page. After first login, assign groups with the groups script for role-based access. See the helper scripts README for details.

Each metric subscription gets its own Random Cut Forest model that maintains a sliding window of recent values. After the baseline period, the detector computes a z-score based anomaly score (0-10) for each new datapoint. Scores above the configurable threshold (default 3.0) trigger alerts. The model continuously adapts — daily patterns, gradual drift, and weekly cycles are learned automatically via per-day-of-week baselines.

Anomaly detection learns what's normal for your metric and alerts when behavior deviates unexpectedly. It catches patterns you didn't anticipate — sudden spikes, unusual drops, weekend vs weekday differences. "Alert if below/above" is a static safety net — a hard floor or ceiling that fires immediately regardless of learned behavior. Use it for absolute limits where any breach is critical (e.g., free disk below 10GB, CPU above 95%). You can use both together on the same subscription. Anomaly detection handles the subtle/unknown, static thresholds handle the "must never cross this line" scenarios.

When an anomaly is detected (compact tier and above), the correlation engine checks which other logs that also showed unusual behavior in the same time window (z-score > 2.0). The alert may include these correlated logs — helping you determine if an anomaly is isolated or part of a broader incident.

Create recurring schedules (e.g. "Wednesdays 02:00-04:00 UTC") or one-time windows in the editor. Anomalies detected during these periods are recorded but suppressed — no alerts fire. Apply windows globally or to specific subscriptions.

No. Everything runs inside your VPC. Metric Streams → Firehose → S3 → Lambda → OpenSearch — all within your account. The only external call is a periodic Marketplace entitlement check.

On advanced/enterprise tiers, provide the organization id and/or remote account IDs during deployment. The stack allows remote accounts to forward metrics into the central account. Remote accounts deploy their own CloudWatch Metric Stream. Data lands in S3 partitioned by source account ID — all metrics queryable from a single OpenSearch instance.

The editor immediately updates the CloudWatch Metric Stream's IncludeFilters to only stream namespaces with active subscriptions. Adding the first subscription in a namespace starts streaming; removing the last stops it. Zero subscriptions = stream paused entirely — no Firehose/S3 costs when idle.

Yes. Each AI Monitor stack is fully independent — deploy multiple stacks with different names, each paired to a specific Log Processor instance. For example, deploy AIMonProd targeting LogProcProd and AIMonDev targeting LogProcDev. Each gets its own metric stream, Firehose, S3 buckets, DynamoDB, editor, ALB, and Cognito. No resource collisions, no shared state. Useful for separate environments (dev/staging/prod), different teams, or different AWS accounts with their own Log Processor deployments.

Yes. The alert topic is a standard SNS topic — add your own subscriptions for any protocol SNS supports: HTTPS (webhooks), Lambda, SQS, SMS, etc. For Slack/Teams, use AWS Chatbot or subscribe an HTTPS endpoint to the topic with your webhook URL. For PagerDuty/OpsGenie, subscribe their SNS integration endpoint. You can have email and webhook subscribers active simultaneously.

Every alert includes SNS message attributes: severity (high/medium/low), score (0-10), namespace, metricName, subscriptionId, description, and accountId. Use SNS subscription filter policies to route by any combination — for example, only page on-call for {"severity": ["high"]} (score ≥ 7), route a specific subscription to a dedicated Slack channel, or escalate only production account anomalies.

Yes. Subscribe a Lambda function, SQS queue, or HTTPS webhook to the SNS alert topic. Use SNS filter policies on message attributes (severity, score, namespace, metricName) to trigger specific automations — for example, auto-scale an ECS service only when {"severity": ["high"], "namespace": ["AWS/ECS"]}, create a Jira ticket for all anomalies, or invoke a Step Functions workflow for multi-step remediation. Any tool that accepts SNS or webhooks works: Zapier, n8n, EventBridge, custom APIs.

Yes. Update the CloudFormation stack with a new tier parameter. Subscription limits, detection intervals, and feature gates update immediately. Baselines and anomaly history are preserved in DynamoDB.

The detector maintains separate baselines per day of week (Monday through Sunday). Each day builds its own sliding window of normal values over time. After approximately one week, the system knows that "Monday morning traffic" is different from "Sunday night quiet" and scores accordingly. Until per-day data is sufficient, it falls back to an overall baseline. This eliminates the most common source of false positives — weekly traffic cycles.

Likely. The detector begins alerting after just 15 data points (~75 minutes), even though full training requires 288 points per day-of-week (~24 hours of data per weekday). During early training:

• Alerts are marked "⚠ Low confidence" in the email subject when training is below 50%
• The alert body shows training percentage (e.g. "Fri baseline: 35% trained")
• The anomaly detail in the editor displays training status

This is by design — a genuine spike from 200ms to 5000ms should alert immediately even with a thin baseline. To suppress all alerts during initial learning, set the baselineDays field on the subscription (e.g. 7). The detector will score but not alert until that period passes. After one full week, day-of-week baselines stabilize and false positives drop significantly.

Yes. Use regex wildcards in dimension values. For example, setting dimensions to {"DeliveryStreamName: ".*"} monitors every entity independently — each gets its own baseline. One subscription (current & future), unlimited resources.

Metrics that emit fewer than ~15 datapoints per day (e.g. daily billing, Trusted Advisor checks) use an aggregate baseline across all days rather than per-day-of-week patterns. The detector still scores these metrics normally — it just doesn't have enough data to distinguish Monday behavior from Friday behavior.

Yes. Each subscription has an "Email" toggle (on/off) and an "Email threshold" (0-10). Set Email to No for fully silent recording — anomalies are stored in DynamoDB and visible in the editor but no notifications are sent. Or set Email threshold to 5.0 to only receive emails for significant anomalies while low-severity ones are recorded silently.

The subscription list shows arrows indicating anomaly frequency trends: ▲ red (worsening — more anomalies this week than last), ▼ green (improving — fewer this week), ▶ grey (stable), ★ blue (new — no prior week data), and off (metric disabled). A persistently worsening trend suggests a systemic issue beyond individual alert triage.

Typical costs for a compact tier deployment with 20 active metrics: Metric Streams ~$3/mo, Firehose ~$1/mo, S3 ~$0.50/mo, Lambda (collector, detector, billing, discovery) ~$2/mo, DynamoDB ~$0.50/mo. Total infrastructure ~$7-12/mo on top of the software fee. OpenSearch is shared with Log Processor — no additional cluster cost. On advanced+ tiers, the Bedrock VPC endpoint adds ~$7/mo and AI suggestions cost ~$0.001 per query. Cross-account adds a Metric Stream per remote account (~$3/mo each).

A daily billing processor queries AWS/Billing EstimatedCharges data from OpenSearch, computes the day-over-day spend delta per service, and writes derived DailySpend metrics back. The detector then scores these like any other metric using day-of-week baselines. This means it learns that "Tuesdays cost more than Sundays" and only alerts on genuine cost spikes — not normal weekly patterns. Subscribe to AIMonitor/Billing / DailySpend with {"ServiceName": ".*"} to monitor all services independently.

A scheduled Lambda calls CloudWatch ListMetrics every 6 hours and caches all available namespaces, metrics, and dimension values. The editor merges this with a comprehensive AWS metrics catalog (40+ services) to show you everything you could monitor. Active metrics are highlighted; inactive ones can be shown via a toggle. Click "+ Subscribe" to pre-fill the form with smart defaults including wildcard dimensions and suggested thresholds. Click the ↻ refresh icon to update the cache on demand (~30 seconds) when you've added new resources.

Each report is a self-contained HTML page covering a configurable lookback window (default 7 days). It includes: total anomalies with severity breakdown (high/medium/low), anomaly trend direction per subscription, top anomalous metrics ranked by count, day-of-week distribution, top dimensions (resources), per-account breakdown, cost analysis (daily spend vs 7-day average with % change), maintenance window details (type/schedule/duration/suppressed count), baseline training status, and full system health checks across all Lambda functions. View a sample report

On advanced and enterprise tiers, DynamoDB point-in-time recovery (PITR) is automatically enabled. This provides continuous backups with restore capability to any second within the last 35 days. Baselines, anomaly history, and maintenance state are all protected. On lower tiers, baselines rebuild automatically from incoming data within 1-2 weeks if lost.

AI features require Amazon Bedrock access to Anthropic Claude models. Use the provided check-quota script to verify access and sufficient resources, submit requests as recommended. AI features are available on advanced and enterprise tiers only.

AI Monitor uses Amazon Bedrock (Claude) to generate metric suggestions, tuning recommendations, and anomaly explanations. These are provided as guidance only. AI recommendations may be inaccurate, incomplete, or inappropriate for your specific environment. Always review and validate suggestions before applying them. You are responsible for your monitoring configuration and alert thresholds. Costs are neglible @ ~$0.001-0.002 per call.

On advanced and enterprise tiers, the discovery wizard includes a natural language prompt. Type something like "monitor my Lambda errors" or "alert me if S3 costs spike" and Bedrock (Claude) returns a fully configured subscription suggestion based on your available metrics. For ambiguous requests, click Next to get additional suggestions from Bedrock, then navigate through them with Prev/Next and apply the ones you want. In all tiers you can also browse metrics manually or use the clickable chips, which pre-fill the form using built-in smart mappings — no AI call needed.

On advanced and enterprise tiers, each anomaly alert includes an AI-generated analysis section. Bedrock (Claude) receives the anomaly context — metric name, current value, baseline mean, score, and any correlated metrics — and produces a 2-3 sentence explanation: likely cause, what to investigate first, and whether it's probably a real issue or noise. Labeled "AI Analysis (experimental)" in the email.

On advanced and enterprise tiers, in Recent Anomalies, click on the subscription link to view its details, click the "Tune" button and Bedrock (Claude) leverages recurring anomaly history and suggests changes which you can apply, costs ~$0.0003 per tune.

Language models are great at explaining things but unreliable at picking numbers. A model might suggest a 7-day queue ceiling because it saw a large max value and multiplied confidently. Our rules-based engine uses your actual anomaly frequency, metric type, and observed percentiles to compute thresholds — then Bedrock writes the explanation. You get consistent, repeatable recommendations grounded in your data, not creative math from a language model.

Yes. AI Monitor detects anomalies in Trusted Advisor these include RedFlagChecks — Critical findings: exposed S3 buckets, IAM keys without MFA, security groups with unrestricted access, root account usage, idle load balancers costing money. A spike means new vulnerabilities appeared. YellowFlagChecks — Warnings: underutilized EC2 instances, EBS volumes without snapshots, aging access keys, RDS instances without Multi-AZ. Rising count means infrastructure hygiene is slipping. ServiceLimitUsage — Quota consumption: VPCs, EIPs, Lambda concurrent executions, RDS instances, CloudFormation stacks approaching hard limits. Anomaly here means you're growing toward a service limit that will cause hard failures with no graceful degradation. Traditional monitoring misses these because they're not operational metrics — they're audit findings that change infrequently. AI Monitor's baseline detects when "normal = 2 red flags" becomes "5 red flags overnight" and alerts you before the next security review finds them first.

When an anomaly fires, AI Monitor searches OpenSearch logs for entries matching a pattern within the correlation window. By default it looks for ERROR, Exception, and FATAL entries. If your Log Processor has custom pattern rules configured, you can select one or more patterns instead (e.g. secrets, slow queries, connection errors). Results appear in the anomaly detail view under "Correlated Log Entries." This feature requires the advanced tier or above.

Yes. If cross-account metric streams include AWS/Billing from linked accounts, the billing processor computes per-account per-service deltas. Alerts include the account ID so you know exactly which account is spending more. Note: AWS/Billing metrics only exist in the payer (management) account unless billing access is delegated to member accounts.