CloudWatch.

Where CloudWatch fits on a long engagement.

Being native is CloudWatch's strongest property. Every AWS service emits metrics into it without configuration, IAM controls access, and alarms can drive AWS actions directly. For an estate that is entirely on AWS, that integration is hard to match with a third-party tool.

Cost is the thing that surprises people. Log ingestion is billed per gigabyte, custom metrics per metric per month, and both scale with how chatty the application is rather than with how useful the data proves. An application logging every request at debug level generates a bill out of all proportion to the value.

What an assigned team does with CloudWatch.

Log retention is the easiest saving nobody makes. Default retention is indefinite, and most logs have no value after a few weeks — retention policies set per log group typically cut the bill substantially with no operational loss.

Reviewing that periodically is part of cost discipline, agreed as part of a committed monthly capacity for platform work.

What we use CloudWatch for.

• Metrics with no agent to deploy Every AWS service observable immediately, with IAM controlling who sees what.
• Log costs brought under control Retention and log-level policy, which is usually the single largest saving available.
• Alarms that drive action Alarms wired to scaling and remediation rather than only to a notification.

How CloudWatch capacity is assigned.

CloudWatch work is assigned under devops managed services, with ingestion cost treated as a design constraint from the start.