AWS RDS

HealOps uses AWS RDS to investigate database instance health and surface recent operational events — failovers, maintenance windows, parameter changes, and backup activity — when an alert fires against a managed RDS database. All RDS API calls are read-only and routed through the shared aws_sdk_client allowlist, so the integration cannot mutate your RDS resources.

Prerequisites

AWS credentials configured per the AWS integration (role ARN recommended)
An RDS DB instance you want HealOps to investigate
IAM permissions for the two RDS describe actions listed below

Setup

Environment variables

RDS_DB_INSTANCE_IDENTIFIER=prod-orders-db
AWS_REGION=us-east-1

Variable	Default	Description
`RDS_DB_INSTANCE_IDENTIFIER`	—	Required. The DB instance identifier HealOps should investigate.
`AWS_REGION`	`us-east-1`	AWS region the instance lives in. Used by both the integration config and per-tool param extraction.
`RDS_REGION`	`us-east-1`	Fallback used only when `AWS_REGION` is not set.

Region resolution order (highest priority first):

region field on the source dict (when configured via the integrations store)
AWS_REGION environment variable
RDS_REGION environment variable
us-east-1 (default)

IAM permissions

The integration only needs two read-only RDS actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeEvents"
      ],
      "Resource": "*"
    }
  ]
}

Attach this policy to the same IAM role or user already configured for the AWS integration. If you are already using the AWS managed ReadOnlyAccess policy, both actions are already covered.

Tools

Tool	AWS API call	What it returns
`describe_rds_instance`	`rds:DescribeDBInstances`	Instance status, engine + version, instance class, Multi-AZ flag, endpoint address/port, storage type and size, availability zone, and backup window.
`describe_rds_events`	`rds:DescribeEvents`	Recent events for the DB instance — failovers, maintenance, parameter group changes, and backup activity. Defaults to the last 60 minutes; bounded to 20160 minutes (14 days, the AWS limit).

Both tools become available to the planner whenever rds.db_instance_identifier is present in the resolved sources.

Use cases

Verifying RDS instance status (available, modifying, failed) when an alert fires
Detecting Multi-AZ failover events around an incident timestamp
Tracing recent maintenance, parameter group changes, or backup activity that may correlate with the incident

Troubleshooting

Symptom	Fix
AccessDenied on `rds:DescribeDBInstances`	Add the IAM policy above to the role or user used by the AWS integration.
DBInstanceNotFound	Confirm `RDS_DB_INSTANCE_IDENTIFIER` matches an instance in `AWS_REGION`.
Tool reports the wrong region	Either `AWS_REGION` is set to a different region, or the source dict has a stale `region` field. Check the resolution order above.

Upstream correlation validation

HealOps also includes a deterministic upstream-correlation smoke validation path for no-trace-ID RDS CPU spike investigations. This allows validating correlation output locally without requiring live Datadog credentials or full LLM investigation setup.

Local smoke validation

Run:

healops tests upstream-correlation-smoke

Expected output includes separate sections for:

correlated signals
most likely causal driver(s)

Example:

Upstream Correlation Smoke Validation

Correlated signals:
- upstream-correlation (source=runtime, score=0.9)

Most likely causal driver(s):
- system.cpu.user{service:orders-web} (confidence=0.9)
  rationale=time_window=1.0, topology=1.0, periodicity=1.0, operator_hint=0.0

For machine-readable output:

healops tests upstream-correlation-smoke --json

Live investigation validation

For live validation, configure Datadog and trigger an investigation against an RDS CPU spike alert. The upstream correlation runtime automatically scopes RDS metrics to the alerting DB instance using the dbinstanceidentifier tag to avoid cross-instance aggregation in multi-RDS environments. Recommended alert fields:

{
  "service": "orders",
  "resource": "orders-rds-prod",
  "upstream_services": ["orders-web"]
}

Then run a live investigation:

healops investigate

When runtime evidence is available, the final report includes:

correlated signals
most likely causal driver(s)

This validation flow is intended as a lightweight smoke/integration path and does not require synthetic benchmark execution.

Overview

LLM providers

Observability and incidents

Cloud, code, and collaboration

Messaging

Data and workflow systems

Prerequisites

Setup

Environment variables

IAM permissions

Tools

Use cases

Troubleshooting

Upstream correlation validation

Local smoke validation

Live investigation validation

​Prerequisites

​Setup

​Environment variables

​IAM permissions

​Tools

​Use cases

​Troubleshooting

​Upstream correlation validation

​Local smoke validation

​Live investigation validation

Prerequisites

Setup

Environment variables

IAM permissions

Tools

Use cases

Troubleshooting

Upstream correlation validation

Local smoke validation

Live investigation validation