Kiro User Activity Dashboard

Introduction

The Kiro User Activity Dashboard provides enterprise visibility into Kiro AI coding assistant usage across your AWS accounts. It tracks per-user credit consumption, model usage, overage risk, and the cost of licences nobody is using. Cloud financial management (FinOps) and engineering leaders can use this data to manage Kiro adoption at scale.

The dashboard answers two different questions from two different data sources. How is Kiro being used? comes from the Kiro user activity report: messages, credits, models, and client types, per user per day. What are we paying for, and is it being used? comes from your AWS Cost and Usage Report (CUR): which licences appear on each month’s bill, which of them consumed credits, and what the ones that did not have cost you. Because Kiro allocates and resets plan credits per calendar month, both halves are scoped by a single Billing period control.

Key capabilities include:

The following screenshot shows the Executive Summary tab of the Kiro User Activity Dashboard:

Demo Dashboard

Get more familiar with the Dashboard using the live, interactive demo dashboard following this link.

The dashboard has five tabs:

All tabs include shared filter controls for Billing period, AWS Account, User, Model, and Client Type.

Architecture

The Kiro User Activity module uses a pull-based architecture. A central AWS Lambda function in the Data Collection account reads CSV reports from customer Kiro source buckets on a daily schedule. Customers only need to apply a bucket policy, because no AWS CloudFormation stack is deployed in their accounts.

The following diagram shows the pull-based data collection flow:

The dashboard uses a second dataset, built from your existing AWS Cost and Usage Report rather than from the Kiro activity report. The activity report only contains users who did something, so it has no way to represent a subscribed-but-idle user. Subscription counts, the active and idle split, and all cost figures therefore come from CUR:

Prerequisites

Deployment

Deployment consists of three steps: enabling the data collection module in the Data Collection Stack, granting read access from each source account, and deploying the Quick Suite dashboard.

Step 1: Enable the Kiro User Activity Module in the Data Collection Stack

The Kiro User Activity module is part of the Data Collection Stack. Enable it when you deploy or update the stack in your Data Collection account.

Step 2: Grant Read Access

Apply the following in each source account that produces Kiro user activity reports. Each account must apply a bucket policy granting read access to the collection Lambda role from Step 1. No CloudFormation stack is deployed in the source accounts — a bucket policy is all that is required.

Add the following two statements to the S3 bucket policy on each Kiro source bucket. Access is scoped to the kiro/* prefix so the collection Lambda can read only the Kiro user activity reports, not the rest of the bucket:

{
  "Sid": "AllowCIDKiroDataCollectionRead",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<LambdaRoleArn from Step 1 Outputs>"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::<kiro-source-bucket-name>/kiro/*"
},
{
  "Sid": "AllowCIDKiroDataCollectionList",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<LambdaRoleArn from Step 1 Outputs>"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::<kiro-source-bucket-name>",
  "Condition": {
    "StringLike": {
      "s3:prefix": "kiro/*"
    }
  }
}

Step 3: Test the Lambda Collector

Invoke the Lambda manually to verify data flows correctly:

aws lambda invoke \
  --region <region> \
  --function-name CID-DC-kiro-user-activity-Lambda \
  /tmp/kiro-output.json && cat /tmp/kiro-output.json

Expected response (a successful run returns statusCode: 200; total_files_copied, total_rows_written, and partitions_registered reflect how many reports were missing and therefore imported on this run — a run where everything is already collected returns zeros, which is normal):

{
  "statusCode": 200,
  "total_files_copied": 3,
  "total_rows_written": 45,
  "partitions_registered": 3,
  "errors": []
}

Step 4: Verify Data in Athena

Run a test query to confirm data is accessible:

SELECT * FROM optimization_data.kiro_user_activity LIMIT 10;

Step 5: Deploy the Quick Suite Dashboard

Step 6: Trigger Initial SPICE Refresh

After deploying the dashboard, trigger a SPICE ingestion to load data:

cid-cmd refresh --dashboard-id kiro-user-activity

Adding New Source Accounts

To start collecting data from additional Kiro-enabled accounts:

You do not need to redeploy the dashboard. New accounts automatically appear as filter values after the next SPICE refresh.

Usage Guide

A typical review runs left to right. Set the Billing period to the month you are reviewing, read the Executive Summary to see whether the licence pool is the right size, use User Engagement to decide what to do about individual licences, and use Credit & Overage Tracking to spot people on the wrong tier. Model & Client Breakdown answers a separate question about which models and clients your developers actually work in.

How licences are counted

One licence is one subscriber within one AWS account, identified by the IAM Identity Center user ID in the CUR line item resource ID, paired with the account that is billed for it.

This matters when the same person is subscribed in more than one account, which happens in organizations that run separate AWS accounts per team or per environment. That person holds two licences, is billed twice, and either licence can go idle and be reclaimed independently of the other. Counting distinct subscribers instead would collapse the two into one and hide the wasted spend, so the subscription KPIs count the pair and a single person can legitimately appear twice in the Idle Kiro Licences table under different accounts.

Grouping only by subscriber has the same effect inside the idle table: if a person works in one account and lets the licence in a second account sit unused, the active account’s last-activity date would mask the abandoned licence. All of the idle calculations are therefore evaluated per account and subscriber together.

Calculated Fields Reference

Activity dataset

Fields derived from the Kiro user activity report, which is one row per user per day per model:

Subscription dataset

Fields derived from CUR, evaluated per account and subscriber together. Except where noted, all of them are scoped to the selected Billing period:

Update

When a new version of the dashboard template is released, update your dashboard by running the following command:

cid-cmd update --dashboard-id kiro-user-activity

Teardown

To remove the Kiro User Activity module:

Authors

Contributors

Feedback & Support

For feedback and support, see the Feedback and Support guide.