Amazon CloudWatch consulting so alarms mean something

Amazon CloudWatch collects metrics and logs from AWS services, your applications and your servers, shows them on dashboards and raises alarms when a value crosses a threshold you set. Alarms can notify people through SNS or take action, such as scaling out, recovering an EC2 instance or running a Lambda function. We set it up so each alarm points at a real customer problem.

Default metrics from AWS services are free. In US East (N. Virginia), custom metrics are $0.30 per metric a month for the first 10,000, standard alarms are $0.10 per alarm metric a month, dashboards are $3.00 each a month, and logs are $0.50 per GB ingested in the Standard class plus $0.03 per GB a month to store. The free tier covers 10 metrics, 10 alarm metrics, 3 dashboards and 5 GB of log data each month.

CloudWatch tells you how your systems are performing: CPU, latency, errors and application logs. CloudTrail records who did what in your AWS account, meaning every API call, sign-in and configuration change. You want both. A common pattern sends CloudTrail events into CloudWatch Logs so an alarm can fire on something like a root user sign-in.

CloudWatch is built in, needs no extra vendor and is usually the cheaper start for teams that run mostly on AWS. Datadog and similar tools shine when you run across several clouds, want polished tracing across many services, or have a team that already knows them. Plenty of teams use CloudWatch for alarms and AWS metrics and add another tool only where it earns its cost.

EC2 reports CPU, network and disk operations from outside the instance, but memory lives inside the operating system, so AWS cannot see it by default. Installing the CloudWatch agent on the instance publishes memory and disk space metrics. Those count as custom metrics, so we choose which ones to send.

Metrics are kept for 15 months, rolled up over time: one-minute data for 15 days, five-minute data for 63 days and one-hour data for 455 days. Log groups never expire by default, which is why logs bills creep up. We set a retention period on every log group and export anything that must be kept for years to S3.

It means the alarm has just been created, the metric is not reporting, or there are not enough data points to decide. For metrics that only report when something happens, like error counts, we set the alarm to treat missing data as not breaching so it stays OK on quiet nights.

The alarm notifies an SNS topic, and a small Lambda function subscribed to that topic calls the Zoho Cliq or Zoho Desk API. It posts the alarm name, value and dashboard link to a channel, or opens a ticket, and handles the OK message when the alarm clears.

Usually one of three things: debug logging left on in production, log groups set to never expire, or verbose service logs that nobody queries. We find the top log groups by volume, set retention, move rarely searched logs to the Infrequent Access class at $0.25 per GB ingested in US East, and trim what applications write.

The first call is free. After that, the monitoring plan for your workloads, alarms, dashboards and any Zoho alert routes is written into a BRD with one fixed price, signed before we start. Bigger multi-account estates may need a paid discovery phase first, which we quote up front. CloudWatch usage itself is billed by AWS.