Skip to main content
Danube has six AWS connectors. Each one is its own service in the catalog with its own connection, so you can grant exactly the access each needs: For application logs outside AWS, the Datadog connector covers the same questions.

​
How the connection works

Every AWS connection stores a region and one of two ways to authenticate:
  • Cross-account role (recommended). You create an IAM role in your account that trusts Danube’s AWS account and requires an external id. Danube calls sts:AssumeRole for every connection, gets credentials that last 15 minutes, and never holds a long-lived key of yours. The external id is generated by Danube for your Danube account and shown on the connection form; it is what stops another Danube customer from pointing their connection at your role.
  • Access keys. An IAM user’s access key id and secret access key (and a session token for temporary keys). This works, but a key that never expires is a bigger risk than a role. Test Connection warns when the keys belong to the account root user.
Each connection is for one region. To reach resources in two regions, store two connections. Endpoint URL is optional. Leave it empty for AWS itself. Set it to a VPC interface endpoint when the traffic must stay on your network (run the data-plane agent inside that VPC), or to LocalStack for testing. Danube only calls public addresses directly, so a private endpoint needs the data-plane agent.

​
Create the role

1

Open the connection form

In the dashboard, open the AWS connector you want and click Connect. Keep Authentication on Cross-account role and copy the Danube AWS account id and the External ID the form shows.
2

Create the role in IAM

In the IAM console choose Roles, Create role, Custom trust policy, and paste this trust policy, replacing DANUBE_AWS_ACCOUNT_ID and YOUR_EXTERNAL_ID with the values from the form:
3

Attach a permission policy

Attach one of the policies below (or several, if one role serves several connectors). Name the role, for example danube-readonly, and create it.
4

Save the connection

Paste the role ARN (arn:aws:iam::123456789012:role/danube-readonly) and the region into the form and save. Run Test Connection: it shows the account and role Danube assumed and lists any IAM action the role is missing.
If Test Connection says Danube could not assume the role, check the trust policy: the principal must be Danube’s account and the external id must match the form exactly.

​
Minimal IAM policies

Each policy grants only what the connector’s tools call. Narrow Resource further to the log groups, tables, functions, queues and buckets agents should see.

​
CloudWatch

​
DynamoDB

Read and write are separate statements. Leave out the second one for a read-only role; then even a connection stored as read_write cannot change data.

​
Lambda

Recent Invocations and Errors reads the function’s CloudWatch log group and metrics, so the read statement includes those. Invoke is its own statement; leave it out unless agents should run functions.

​
SQS

No sqs:ReceiveMessage: reading a message would hide it from your consumers.

​
S3

Scope s3:GetObject to the buckets and prefixes agents may read.
A bucket encrypted with a customer-managed KMS key also needs kms:Decrypt on that key.

​
Redshift

The Redshift Data API needs its own actions plus one way to log in to the database: temporary credentials for a database user on a provisioned cluster, or a Secrets Manager secret.
With a secret instead, replace the second statement with secretsmanager:GetSecretValue on that one secret’s ARN. Serverless workgroups use redshift-serverless:GetCredentials on the workgroup. The database user itself should hold SELECT grants only; see Redshift.

​
Safety

  • Read-only by default. A connection’s mode is read_only unless you store it as read_write. The write tools (DynamoDB Put, Update and Delete Item, Lambda Invoke) are refused on a read-only connection before anything reaches AWS, and every call on a read_write connection needs a confirmation. The IAM policy is the second layer: leave out the write statements and AWS refuses them too.
  • Limits on every call. Calls time out after 15 s by default (up to 55 s). Lists stop at 500 items and 1 MB; a cut result says truncated: true and carries a token to continue.
  • No secrets in results. Secret keys, session tokens and the temporary credentials Danube assumes are removed from every error. Lambda environment variable values are never returned, only their names.
  • Every call is audited with the tool, the caller, the row count and the outcome.