CDK Monitoring Constructs attaches alarms and a dashboard to everything you deploy

Monitoring as constructs, next to the resources it watches

CDK Monitoring Constructs is described as easy to use CDK constructs for monitoring your AWS infrastructure with Amazon CloudWatch, and the repository description says the same in fewer words.

The framing matters. In the AWS CDK, a construct is a class that represents infrastructure and composes into a stack, and the point of this library is that monitoring stops being a separate project you bolt on afterwards. You attach a monitor method to the resource you just created, and the alarms, the metrics and the dashboard come with it.

The README lists four capabilities. You can easily add commonly used alarms using predefined properties. You can generate concise CloudWatch dashboards that indicate your alarms. You can extend the library with your own extensions or custom metrics. And you can consume the library in multiple supported languages.

That last one is the most distinctive. This is a jsii project, and the repository has a rosetta/ directory at the top level, which is the jsii tool for exposing a TypeScript construct to Java, Python and C#. The build scripts make it explicit, with separate package tasks for dotnet, java, js and python, and a rosetta:extract task to generate the bindings.

The result is that a team whose CDK code is in Python can use the same constructs as a team whose CDK code is in TypeScript, from the same source of truth. That is the thing a hand written monitoring module cannot easily give you.

Installing it: four ecosystems, one set of constructs

The installation section is organised by language, and the TypeScript entry gives the full detail including the peer dependencies.

{
  "dependencies": {
    "cdk-monitoring-constructs": "^9.0.0",

    // peer dependencies of cdk-monitoring-constructs
    "aws-cdk-lib": "^2.160.0",
    "constructs": "^10.0.5"

    // ...your other dependencies...
  }
}

Two things to note. The peer dependencies are aws-cdk-lib and constructs, and they are declared as peers rather than bundled, so your stack's CDK version and the constructs version are yours to choose. And the JSON in the README carries comments, which is fine in package.json but is not valid JSON, so you take the dependency lines and drop the comments.

The other three languages are listed with their registries. Java is at io.github.cdklabs/cdkmonitoringconstructs on Maven Central. Python is cdk-monitoring-constructs on PyPI. C# is Cdklabs.CdkMonitoringConstructs on NuGet.

So the install differs only in which registry you pull from, which is the direct consequence of the jsii approach. The constructs themselves are the same objects in every language, and the badges at the top of the README confirm all four distributions are published.

One detail worth noticing: the version in the README's TypeScript snippet is ^9.0.0, while the recent releases listed in the project metadata are v10.3.2, v10.3.1 and v10.3.0. The documentation example is a major version behind the current release, so read the registry page for the version you are actually going to pin rather than copying the snippet.

The service table, and the Advanced Monitoring caveat

The features section links to the documentation on constructs.dev, and the README carries a table of what can be monitored. Each row names a resource, the method that attaches monitoring to it, the metrics that get collected, the alarms that get created, and a notes column.

The rows that are visible show the shape of the library. AWS API Gateway, a REST API, with the method monitorApiGateway(), collects TPS, latency and errors, and creates alarms for latency, error count and rate, and low and high TPS. API Gateway V2, the HTTP API flavour, is monitorApiGatewayV2HttpApi() with the same metric and alarm set. AppSync, the GraphQL API, is monitorAppSyncApi(). Amazon Aurora is monitorAuroraCluster(), collecting query duration, connections, latency, CPU usage and Serverless Database Capacity, with alarms on connections, Serverless Database Capacity and CPU usage. AWS Billing is monitorBilling(), collecting account cost with a total cost anomaly alarm.

The notes column is where the operational detail lives, and the API Gateway rows both say that to see the metrics you have to enable Advanced Monitoring, and for the HTTP API that to see route level metrics you have to enable it too. That is a genuine trap. The construct attaches the alarm and the metric filter, but the underlying metric is not emitted until you change a setting on the API, and if you skip that step you get a dashboard with empty panels and an alarm that never fires.

So the rule for a first adoption is to read the Notes column for every service you plan to monitor, not just the metric names.

Alarms with properties, not alarm definitions you write by hand

The headline feature is that you add commonly used alarms using predefined properties, and the table shows what that looks like in practice. For API Gateway, the alarms are latency, error count and rate, and low and high TPS. For Aurora, connections, Serverless Database Capacity and CPU usage. For billing, a total cost anomaly alarm.

These are the alarms that platform teams write over and over, and the ones where a sensible threshold is not obvious enough to be worth re-deriving per service. Putting them behind a property means the threshold logic is written once, in the library, and you can override it where your environment differs.

The second feature, generating concise CloudWatch dashboards that indicate your alarms, is the one that changes how a team works. A dashboard per service that shows the alarms relevant to that service, rather than one sprawling operations dashboard, is a different artefact to hand to a service owner. The word in the README is concise, which suggests the intent is a small number of widgets per dashboard rather than every metric the construct collects.

The third feature is that the library is extensible, so you can add your own extensions or custom metrics, which is what stops the library from becoming a ceiling. A team whose service needs a business metric that no construct knows about can add it rather than dropping back to hand written alarms.

The README does not document a threshold configuration format or a dashboard layout configuration, and the API reference lives on the constructs.dev documentation site. That site is the real API reference, and the README is the entry point to it.

A projen project, which tells you how it is maintained

The repository layout is worth reading because it shows how the project is built and released.

There is a .projen/ directory and a .projenrc.ts file, and every single script in package.json is a projen task. Build is npx projen build, compile is npx projen compile, test is npx projen test, release is npx projen release, and there are tasks for bump, unbump, upgrade and upgrade-cdklabs-projen-project-types. The word cdklabs in one of those task names tells you this project uses a shared projen project type from the CDK Labs organisation rather than a bespoke configuration.

The consequence for a contributor is that the build files are generated. You edit .projenrc.ts and run projen, and the task definitions, the eslint configuration, the tsconfig files and the GitHub workflows are rewritten. The .eslintrc.json, tsconfig.dev.json, the .prettierrc.json and the .github/ directory are all in the tree for that reason.

There is also an API.md at the repository root, generated by the docgen task, and a rosetta/ directory for the cross language bindings, plus a test/ directory and an assets/ directory. The presence of a docgen task alongside a checked in API.md is the standard jsii pattern, and it is how the language bindings stay in step with the TypeScript source.

The maintenance cadence follows from the release list. v10.3.2 on 2026-10-13, v10.3.1 on 2026-09-23 and v10.3.0 on 2026-09-03, so patch releases roughly every two to three weeks with a minor version every few months. The repository is not archived and the last push was on 2026-10-19, so the constructs are still being extended with new services.

Where CDK Monitoring Constructs is the wrong choice

Three cases, and the first one is a hard boundary.

It is CloudWatch only. The README says the constructs are for monitoring your AWS infrastructure with Amazon CloudWatch, and every metric and alarm in the table is a CloudWatch metric. If your organisation has standardised on a different metrics backend, or you are ingesting with the OpenTelemetry Collector and storing in something else, this library does nothing for you, because the constructs generate CloudWatch alarms and CloudWatch dashboards.

The second is the coverage gap, and the table is the evidence. The rows visible in the README cover API Gateway, API Gateway V2, AppSync, Aurora and Billing, and the documentation site lists more. But a monitoring library is only as good as the resources it covers, and for the long tail of services it does not, you are back to hand written alarms for those. The honest way to evaluate it is to take your own list of deployed services and check the table for each one, because a library that covers nine of your twelve services is a partial answer.

The third is the tension between generated monitoring and bespoke monitoring. A construct gives you consistent, sane defaults, and consistency is exactly what you want for a platform team. But it also means the alarm set is the library's opinion, expressed through properties, and if your organisation has a documented alerting standard with specific thresholds per service, you are overriding rather than adopting.

One more practical note. The constructs attach to resources at deploy time, so the alarms live in the same stack as the workload. That is a benefit for cleanup, since deleting the stack removes the alarms, and a cost if your monitoring is supposed to outlive the resource it watches, which is a common requirement for post incident analysis.

Editorial conclusion

Adopt CDK Monitoring Constructs if you deploy with the AWS CDK and you keep writing the same CloudWatch alarms and dashboards by hand for every service, because the point is that the alarm definitions live next to the resources they watch. Do not adopt it if you already generate your dashboards from OpenTelemetry or a different metrics pipeline, since the constructs are tied to CloudWatch. Before you start, check the service coverage table for the resources you actually run, and read the Notes column, because some metrics only appear when you enable Advanced Monitoring.

Frequently asked questions

Official sources

1. cdklabs/cdk-monitoring-constructs on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases