Skip to main content
AWS is a provider: connect it once and investigations reach the accounts and regions behind your credentials. Today they query CloudWatch metrics and logs; inspecting the Kubernetes workloads on your EKS clusters is coming soon.

​
What it provides

Connecting AWS lets investigations discover and query the data sources behind it:
Data sourceCapability
CloudWatchMetrics and logs
KubernetesCluster state (coming soon)
Each has its own page covering what it supports and how it’s queried. CloudWatch is region-scoped, so investigations see one CloudWatch data source per region you enable. Support for discovering your EKS clusters is coming soon.

​
Setup

Setting up AWS has two parts: give incident.io credentials that can read your telemetry, then choose the accounts and regions investigations may query.

​
Credentials and permissions

Choose one of two ways for incident.io to authenticate to your account.
  • IAM role (recommended). Create a role in your account that incident.io assumes through STS, identified by its role ARN and an external ID. The trust policy names incident.io’s AWS account as the principal and pins the external ID, so only incident.io can assume the role, and only with the ID we generate for you. Sessions are short-lived, so there are no long-lived keys to store or rotate.
  • Static access keys. Create an IAM user with the same permissions and paste in its access key ID and secret access key. This works, but the keys are long-lived and you own rotating them, so prefer the role.
We recommend read-only access either way. Investigations only ever read telemetry from AWS — they never change anything. Grant only the actions for the services you want investigations to use. The setup instructions give you an IAM policy with one block per service, so you can keep a block to allow that service or drop it to hold it back:
  • CloudWatch — cloudwatch:ListMetrics, cloudwatch:GetMetricData, and the CloudWatch Logs Insights actions logs:DescribeLogGroups, logs:StartQuery, logs:GetQueryResults, and logs:StopQuery. logs:StopQuery lets a running query be canceled rather than left to finish.
  • EKS (coming soon) — eks:ListClusters and eks:DescribeCluster, which will be used to discover your clusters once EKS support lands. Access to workloads inside each cluster is granted separately, on the cluster.
The blocks in the IAM policy match the service toggles in the connect form. Whatever you choose during connection, the permissions you grant and the services investigations use stay in step.

​
Connecting

  1. From the Investigations settings, add a telemetry data source and choose AWS.
  2. Follow the instructions to create the IAM role or access keys with the permissions above. Provide the role ARN and external ID, or the access keys, along with a default region.
  3. Optionally set a region allowlist — the regions investigations may query. Leave it empty to use the default region only.
  4. Test the connection. Before connecting, incident.io makes read-only calls to each service you selected and reports back exactly which permissions are missing, per service, so you can fix the policy before finishing.
Once connected, investigations discover the account behind your credentials and a CloudWatch data source for each region you enabled.
Discovered accounts and regions are disabled by default, so you opt in deliberately. Review what’s found and enable the regions your team relies on during incidents.

CloudWatch

Metrics and logs behind AWS.

Kubernetes

Workloads on your EKS clusters (coming soon).

Telemetry overview

How providers and data sources fit together.

How telemetry works

Routing, query planning, guidance, and memory.