CloudWatch

What you’ll get: ewake can query your CloudWatch logs, metrics, and alarms to investigate AWS workload issues, correlating log events with alerts and deployments without requiring you to switch between dashboards.

Prerequisites

An AWS account with CloudWatch logs, metrics, or alarms
IAM permissions to create a role and policy in that account
The AWS regions your CloudWatch data lives in

How it works

The integration uses cross-account IAM role assumption with an External ID, the standard AWS pattern for granting a third party read access without sharing credentials. You create a read-only role in your account, and ewake assumes it on demand for one-hour sessions. ewake never receives long-lived access keys, and the role grants only the read-only actions shown below.

Running ewake in your own AWS account? Two things differ. Read Self-hosted deployments at the bottom of this page before you start — the trust policy below names ewake’s account, and yours should not.

Configuration

Generate your External ID

Pick a unique External ID, a shared secret you will use in both the IAM role and the ewake connection screen.

macOS / Linux: openssl rand -hex 16 or uuidgen
Online: uuidgenerator.net

Keep this value secret. It ties ewake’s role-assumption calls to your role, preventing the “confused deputy” security issue.

Create the read-only IAM role

Create an IAM role that ewake’s AWS account (058264427976) can assume with your External ID. The role name must start with EwakeCloudWatchReadOnly, ewake’s task role is only permitted to assume roles named this way.

If the role name does not start with EwakeCloudWatchReadOnly, ewake cannot assume it.

Option A, CloudFormation (recommended)Creates the correctly named role, trust policy, and permissions in one step. Save this template as ewake-cloudwatch-readonly.yaml:

AWSTemplateFormatVersion: '2010-09-09'
Description: >-
  Read-only IAM role that lets ewake's AI SRE query this account's Amazon
  CloudWatch metrics, logs, and alarms via cross-account AssumeRole.

Parameters:
  EwakeAccountId:
    Type: String
    Default: '058264427976'
    Description: ewake's AWS account ID (the principal allowed to assume this role). Leave as default unless ewake tells you otherwise.
    AllowedPattern: '^[0-9]{12}$'
  ExternalId:
    Type: String
    Description: Shared secret from Step 1. Use the exact value you enter in the ewake CloudWatch integration screen.
    MinLength: 8
  RoleName:
    Type: String
    Default: EwakeCloudWatchReadOnly
    Description: Keep the EwakeCloudWatchReadOnly prefix; ewake's task role is only permitted to assume roles named this way.
    AllowedPattern: '^EwakeCloudWatchReadOnly.*$'

Resources:
  EwakeCloudWatchReadOnlyRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref RoleName
      MaxSessionDuration: 3600
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub 'arn:aws:iam::${EwakeAccountId}:root'
            Action: 'sts:AssumeRole'
            Condition:
              StringEquals:
                'sts:ExternalId': !Ref ExternalId
      Policies:
        - PolicyName: EwakeCloudWatchReadOnly
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: CloudWatchRead
                Effect: Allow
                Resource: '*'
                Action:
                  - 'cloudwatch:DescribeAlarms'
                  - 'cloudwatch:DescribeAlarmHistory'
                  - 'cloudwatch:GetMetricData'
                  - 'cloudwatch:ListMetrics'
                  - 'logs:DescribeLogGroups'
                  - 'logs:DescribeQueryDefinitions'
                  - 'logs:ListLogAnomalyDetectors'
                  - 'logs:ListAnomalies'
                  - 'logs:StartQuery'
                  - 'logs:GetQueryResults'
                  - 'logs:StopQuery'

Outputs:
  RoleArn:
    Description: Paste this into the ewake CloudWatch integration as "Role ARN".
    Value: !GetAtt EwakeCloudWatchReadOnlyRole.Arn

Deploy it, replacing the External ID with the one from Step 1:

aws cloudformation deploy \
  --template-file ewake-cloudwatch-readonly.yaml \
  --stack-name ewake-cloudwatch-readonly \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides ExternalId="YOUR-UNIQUE-EXTERNAL-ID"

Read the Role ARN from the stack output, that is what you paste into ewake:

aws cloudformation describe-stacks \
  --stack-name ewake-cloudwatch-readonly \
  --query "Stacks[0].Outputs[?OutputKey=='RoleArn'].OutputValue" --output text

Prefer the console? Go to CloudFormation → Create stack → upload a template file, upload the same YAML, set ExternalId, and read RoleArn from the stack Outputs tab.Option B, Manual (IAM console)In the AWS IAM Console, go to Roles → Create role → Custom trust policy and paste the following, replacing YOUR-UNIQUE-EXTERNAL-ID with the ID from Step 1:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::058264427976:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "YOUR-UNIQUE-EXTERNAL-ID" }
      }
    }
  ]
}

On the next screen, create and attach this read-only permissions policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchRead",
      "Effect": "Allow",
      "Resource": "*",
      "Action": [
        "cloudwatch:DescribeAlarms",
        "cloudwatch:DescribeAlarmHistory",
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics",
        "logs:DescribeLogGroups",
        "logs:DescribeQueryDefinitions",
        "logs:ListLogAnomalyDetectors",
        "logs:ListAnomalies",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "logs:StopQuery"
      ]
    }
  ]
}

Name the role starting with EwakeCloudWatchReadOnly, create it, then copy the Role ARN from the summary page. It looks like arn:aws:iam::123456789012:role/EwakeCloudWatchReadOnly.

Connect in ewake

In your ewake dashboard, go to Integrations → CloudWatch → Configure.

Field	Value
IAM Role ARN	The role ARN from Step 2
External ID	The ID generated in Step 1
AWS Region	The region where your CloudWatch data lives. To add more regions, see Connect more than one region.

Click Test connection to verify, then Save.

CloudWatch is connected. Ewake can now query your AWS logs, metrics, and alarms.

PromQL and Application Signals tools require additional permissions and are out of scope for now.

Connect more than one region

Each connection reads one AWS region, and ewake sees only the regions that you connect. Add a connection for each region that your workloads send logs, metrics, or alarms to.

Open the CloudWatch integration

In your ewake dashboard, go to Integrations → CloudWatch. The regions that you already connected are listed under Connected regions.

Add the region

Under Add regions, enter the same IAM Role ARN and External ID as before, and select the new AWS Region. IAM roles are global, so the role from Step 2 works in every region.Click Test connection, then Add regions.

The new region appears under Connected regions. ewake can query it within a few minutes, with no redeployment.

During an investigation, ewake queries each connected region separately.

You can connect each region once. To change the role or External ID of a region, disconnect that region and connect it again. Different regions can use different roles, also roles in different AWS accounts, but each region reads from one account.If the test fails with an access error in one region while other regions work, check whether a service control policy (SCP) in your AWS organization denies that region.

Lambda@Edge logs are spread across regions. A Lambda@Edge function writes its logs to the region that ran each request, in a log group named /aws/lambda/us-east-1.<function-name>. Connect each region where that log group exists, not only us-east-1.

Self-hosted deployments

Everything above applies, with two differences.

Turn the sidecar on, after connecting

CloudWatch is read through a sidecar container that runs alongside the dashboard. On the hosted service it is always there. In your own account it is off by default, because it runs permanently whether or not you read CloudWatch. Finish Steps 1 to 3 above first — create the role, and connect the integration in the dashboard. Then enable the sidecar in terraform.tfvars and apply:

company = {
  # ...
  features = {
    cloudwatchMcpSidecar = true
  }
}

The order matters. The sidecar asks the dashboard which roles to assume when it starts, and gives up if the answer is that none are connected. Enabled first, it stops within a second and is not restarted — and connecting an integration afterwards does not bring it back.Nothing else breaks if you get this wrong: the container is not essential, so the dashboard and the rest of the task are unaffected. Connect the integration, then force a new deployment of the reactive service:

aws ecs update-service \
  --cluster <tenant_name> --service <company_name> \
  --force-new-deployment

Trust your own deployment, not ewake’s account

The trust policy in Step 2 names ewake’s AWS account, because on the hosted service that is what assumes the role. Your deployment assumes it with its own task role, so that is the principal to trust:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<your-account-id>:role/<tenant_name>-<company_name>-task"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "YOUR-UNIQUE-EXTERNAL-ID" }
      }
    }
  ]
}

tenant_name and company.name are the values in your terraform.tfvars. Using the CloudFormation template instead? Pass that same role ARN as EwakeAccountId. Everything else is unchanged: the role name must still start with EwakeCloudWatchReadOnly, the External ID is still yours to generate, and the read-only permissions policy is the same.

The role does not have to live in the account the deployment runs in. This is still cross-account role assumption; it just happens to be the same account when the logs you want are the ones next to the deployment.

If you hit an issue, contact support@ewake.ai with your AWS Account ID, Role ARN, and the exact error message.

Introduction

Get Started

Integrations

Working With Ewake

Interfaces

Trust & Security

Resources

FAQ

Prerequisites

How it works

Configuration

Connect more than one region

Self-hosted deployments

Turn the sidecar on, after connecting

Trust your own deployment, not ewake’s account

​Prerequisites

​How it works

​Configuration

​Connect more than one region

​Self-hosted deployments

​Turn the sidecar on, after connecting

​Trust your own deployment, not ewake’s account

Prerequisites

How it works

Configuration

Connect more than one region

Self-hosted deployments

Turn the sidecar on, after connecting

Trust your own deployment, not ewake’s account