Skip to main content
Amazon CloudWatch is an application monitoring service that collects and visualizes logs, metrics, and event data. This guide demonstrates how to set up Cube Cloud to export logs to Amazon CloudWatch.

Configuration

First, enable monitoring integrations in Cube Cloud.

Exporting logs

To export logs to Amazon CloudWatch, start by creating a log group and a log stream for Cube Cloud logs. Then, configure the aws_cloudwatch_logs sink in your vector.toml configuration file. Example configuration:
Commit the configuration for Vector, it should take effect in a minute. Then, navigate to Amazon CloudWatch and watch the logs coming.

Keyless authentication

Instead of the access key pair above, Vector can authenticate to CloudWatch with the deployment’s OIDC identity — no static credentials stored in Cube, and nothing to rotate. The credentials apply to the whole Vector agent, not just this sink, so the same role also covers the S3 and Query History export sinks if you use them.
Requires OIDC enabled for your tenant with an AWS token config.
1

Create the IAM role

Register Cube as an OIDC provider in your AWS account — a one-time step per account — then follow Monitoring integrations to create a role that trusts your deployment and can write to the log group.Two things to carry over from that section: the sub claim needs the non-default :component: Subject Claim Format, and logs:DescribeLogGroups must be scoped to "*" or Vector’s healthcheck fails at startup.
2

Set the deployment environment variables

Under Settings → Environment variables:
The role ARN is the only required variable — setting it is what turns keyless authentication on.The credential exchange also needs a region, which Cube takes from your sink’s region. Set CUBE_CLOUD_MONITORING_AWS_REGION only to override that, for example when the STS region should differ from the sink’s.
3

Drop the auth block from vector.toml

Omit [sinks.*.auth] entirely so Vector falls back to the AWS SDK’s default credential chain, which picks up the OIDC token Cube mounts for it:
Leaving an auth block in place keeps the static keys in use — the two are mutually exclusive.
Keyless authentication does not cover the warmup-job input. The pre-aggregation warm-up runs as a Kubernetes Job that does not receive the OIDC token, so its logs will not reach CloudWatch on this path while the other inputs succeed. If you need warm-up logs in CloudWatch, keep using the access key pair.