Cloud Intelligence Dashboards deploys AWS cost dashboards from a command line tool

What the framework is for

The Cloud Intelligence Dashboards framework is described as an open source framework, cultivated and maintained by a group of AWS staff, that gives customers high level and granular insight into their cost and usage data. Supported by the Well-Architected framework, the dashboards can be deployed by any customer with a CloudFormation template or with a command line tool, and the project claims it can be done in under 30 minutes.

The claim to check is not the deployment time but the scope. What you get is more than twenty dashboards, split into three tiers with different data requirements. Foundational Dashboards need only the Cost and Usage Report. Advanced Dashboards need the CID Data Collection component as well as the report. Additional Dashboards need various custom data sources or were created for specific use cases, and that tier is the one where you will be reading the individual dashboard documentation rather than following a pattern.

The stated purpose is behavioural rather than decorative: drive financial accountability, optimise cost, track usage goals, implement governance practices and reach operational excellence across the organisation. The audience for that is a FinOps or platform team that has been asked where the money went, and the projects that use this framework typically have an executive sponsor who wants a view rather than a spreadsheet.

The ordering matters, and the project is explicit about it. Start with the Foundational Dashboards, which include CUDOS, CID and KPI. Then deploy the data collection tier and the Advanced Dashboards. Then look at the Additional ones. That sequence is not a preference, it reflects the dependency chain described next.

The foundational data path, step by step

The foundational architecture is five services and it is worth walking through because every later tier inherits it. First, AWS Data Exports delivers the Cost and Usage Report, in its CUR2 form, daily to an Amazon S3 bucket in the management account. Second, an Amazon S3 replication rule copies that export data to a dedicated Data Collection Account bucket, automatically. Third, Amazon Athena queries that bucket directly using an AWS Glue table schema definition. Fourth, Amazon QuickSight creates datasets from Athena, refreshes them daily, and caches them in SPICE, the Super-fast Parallel In-memory Calculation Engine. Fifth, user teams of executives, FinOps staff and engineers access the dashboards in QuickSight, with access secured through AWS IAM, IAM Identity Center, formerly SSO, and optional row level security.

Two details carry most of the operational weight. The replication rule means the data leaves the management account, which is where CUR data naturally lands, and lands in a separate account so that the dashboards and the query workload are not sitting next to your billing data. And SPICE is what makes the dashboards usable, because it is a cached in-memory engine rather than a query running every time a filter is clicked, but a SPICE cache has to be refreshed and it holds data in QuickSight's own storage.

The Glue table schema is the piece most teams will have to adjust. Athena querying S3 directly works only if the schema definition matches the layout of the exported files, and the CUR2 export format has changed over time. The frameworks dashboard documentation is where the per-dashboard queries live, so expect to read it before your first Athena query runs.

What the advanced tier adds, and why it costs more

The advanced architecture keeps the same first five steps and then adds an optional collection layer that reaches beyond the Cost and Usage Report. The trigger is an Amazon EventBridge rule that starts an AWS Step Functions workflow for the data collection modules on a configurable schedule. Inside that workflow, an Account Collector Lambda function retrieves linked account details using the AWS Organizations API. A second Data Collection Lambda function then assumes a role in each linked account to pull account-specific data through the AWS SDK, and the retrieved data is written to a centralised S3 bucket. The advanced dashboards then sit on top of Athena and QuickSight as before.

This is the part that turns a cost dashboard into an inventory and posture tool, and it is where the operational weight lands. The Account Collector needs Organizations access. The Data Collection function assumes a role in every linked account, which means a role and a trust policy in each one, and a permissions model that decides what a central collector is allowed to read. In an organisation with hundreds of accounts, that rollout is the actual project.

The advanced dashboards are described as leveraging Trusted Advisor data, AWS Health events and other sources, and the Trusted Advisor example in the documentation shows what that produces: findings and recommendations per account rather than just per service line. The dashboard family list also mentions Trusted Advisor. For an organisation that already owns a Trusted Advisor subscription, the marginal cost of turning that data into a per account view is mostly the collection layer, not a new licence.

The cid-cmd tool and what it drives

This repository is the tool side of the framework rather than the dashboard definitions themselves. The description calls it a command line interface tool for Cloud Intelligence Dashboards deployment, and it is published on PyPI as cid-cmd. The repository layout shows a Python package directory named cid, a cfn-templates directory holding the CloudFormation templates that stand up the stack, a dashboards directory, a terraform directory with a legacy-terraform sibling, scripts, docs, and a CID-CMD.md file that is evidently the tool's own documentation, separate from the main readme.

The dependency list is short and tells you what the tool does. boto3 at 1.43.10 or newer is the AWS API client, Click at 8.0 or newer provides the command line interface, PyYAML reads the configuration, requests handles HTTP calls, six and tqdm handle compatibility and progress output, tzlocal resolves time zones, InquirerPy provides the interactive prompts, and filelock at 3.20.3 or newer serialises concurrent runs so two invocations do not fight over the same deployment.

Installing it means working with the requirements file, which is the list of packages the tool imports:

boto3>=1.43.10
Click>=8.0
PyYAML
requests
six>=1.15
tqdm
tzlocal>=4.0
InquirerPy
filelock>=3.20.3

Install those into a dedicated environment rather than a shared one, since boto3 and Click are common enough to conflict with other tooling. The interactive prompts from InquirerPy are a signal about the shape of the tool: it is designed to walk a user through a sequence of questions rather than take a single fully specified command line, which is reasonable for a one-off deployment and less so in a pipeline.

The repository also carries development tooling that says how the project is worked on. There is a .pylintrc, a .bandit file for Python security linting, a .pre-commit style set of directories including .ai, .claude and .kiro for assistant configuration, a bump-release.py script, a changes directory for changelog fragments, and a .gitattributes file.

Where this approach is the wrong one

The first limitation is that you are adopting QuickSight along with the dashboards. QuickSight is the delivery layer, and it brings its own subscription model, its own IAM Identity Center integration, its own SPICE capacity considerations and its own licence terms. A team that has standardised on another BI tool, or that has already built cost reporting on a data warehouse, is now paying for a second reporting stack to get a set of standard views. The dashboards are good, and they are also a commitment.

The second limitation is that the cost and usage report has to be flowing before anything works. Every foundational dashboard reads from the CUR2 export delivered by AWS Data Exports, and if that export does not already exist in your management account, enabling it and waiting for the first delivery is step zero and is outside the tool. The same applies to the Data Collection Account bucket and the replication rule: the architecture assumes a specific account layout, and an organisation with a different structure will be adapting the templates rather than running them.

The third is that a dashboard is not a process. These views tell you where cost went and what the usage goals look like. Turning that into decisions is the work the framework cannot do for you, and the Additional Dashboards tier, which the project describes as created for very specific use cases, is where you will hit that boundary fastest.

There is a fourth point about the lifecycle. The repository is a sample within the AWS Solutions Library, and it carries both a terraform directory and a legacy-terraform directory. The duplication tells you the deployment paths have changed, and choosing the wrong one is a real risk. The quick answer is to use the CloudFormation templates in cfn-templates, since that is the path the framework documentation leads with, and to treat the terraform directories as secondary unless you have a specific reason.

Cost, licences and how the project changes

The cost question is not the deployment itself, since CloudFormation and the tool are free, it is the services the dashboards sit on. Athena charges per query scanned, S3 stores the exported report and the collected account data, and QuickSight charges per user or per session depending on the edition you pick. A CUR2 export in a large organisation is a substantial object in S3, replicated to a second bucket, and the SPICE cache holds a copy again. None of that is free, and the framework has no mechanism to tell you what it will cost before you run it, so budget for Athena queries against a full report as the line that surprises people.

On licensing, the project is released under MIT-0, which is stated in the LICENSE file. MIT-0 is close to public domain, with the warranty disclaimer retained but no attribution requirement, so using, modifying and redistributing the templates carries practically no obligation. That is worth noting against a contrast with many cloud vendor samples, which often ship under licences with a use restriction.

The change cadence is the last practical fact. The repository is not archived, the last push was on 2026-10-21, and the release history shows version 4.4.18 on 2026-10-09 after 4.4.17 in August. The version numbers are worth reading as a signal: a 4.x line means the tool's interface has been through several rounds of change, and the changes directory in the repository is where those notes live before they reach the readme. When you deploy, note which version you deployed from, because a later release may change a CloudFormation parameter name or a configuration key, and a dashboard deployment that worked last quarter may need a different command now.

Editorial conclusion

Adopt the Cloud Intelligence Dashboards framework if you want AWS's own cost and usage dashboards deployed with a repeatable command instead of hand built QuickSight definitions, and you are comfortable operating QuickSight, Athena and Glue in the target account. Do not adopt it if you only need one bespoke cost report, since the deployment machinery is heavy for a single view, and note that the advanced dashboards need the data collection tier, which assumes an AWS Organizations setup with linked accounts. Before you deploy, confirm the Cost and Usage Report is already being exported daily to S3, since every foundational dashboard depends on it, and read the deployment section of the documentation for the exact command sequence for your account layout.

Frequently asked questions

Official sources

1. aws-solutions-library-samples/cloud-intelligence-dashboards-framework on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases