Find the gaps in your AWS monitoring before an outage does
Many AWS accounts have resources with no alarms on them at all. We audit what is and is not covered, deploy the alarms as code and run the endpoint checks AWS does not.
Alarm coverage you can see, resource by resource
You cannot alarm on what you forgot you were running. Most teams cover the obvious resources and miss the rest, so the first an on-call engineer hears of a problem is a customer reporting it. Cloud Monitoring finds the resources with no alarms and closes the gaps as code.
Ask what is firing and where your gaps are through the Infrastructure Lens MCP →
Find the gaps, then close them with alarms as code
The audit, the alarms and the checks all run in your AWS accounts.
Audit your coverage
We scan your AWS accounts read-only for 27 types of resource worth alarming on, and mark each one as having an alarm or not.
Get the coverage report
The gaps come back as a report, and the same scan writes the first draft of the alarm configuration.
Deploy alarms as code
We tune the draft and commit it to the config repository. A pipeline runs cfn-guardian, and CloudFormation creates the alarms with defaults already set for 50 resource groups.
Add the checks AWS does not run
Lightweight Lambda checks cover HTTP, WebSocket, TLS, certificate and domain expiry, and emit straight to CloudWatch, without the cost of heavy canaries.
Route alerts by severity
Alarms route through SNS by severity, so a Critical alarm pages an engineer while Warning, Task and Informational alarms wait for review.
Keep the alarms working
Every night a check confirms each alarm still has its actions and subscriptions, and drift detection shows any manual change to the alarms.
See which resources have no alarms
A dashboard tells you about the resources you already alarm on. It says nothing about the ones you forgot. We audit your AWS accounts for CloudWatch alarm coverage and report the gaps, so you know which alarms to create instead of guessing.
- Scans 27 resource types read-only, from EC2 and RDS to ECS, Lambda and SQS
- Reports covered against uncovered for every resource it finds
- Writes the first draft of the alarm configuration
- Endpoint checks and services the scan cannot see, such as EKS and Kafka, are added by hand
Alarms as code, with defaults that make sense
Alarms are defined in YAML, kept in a code repository and deployed through CloudFormation, with defaults already set for 50 resource groups and four levels of severity. The alarms deploy as their own CloudFormation stack in your AWS accounts, so they sit alongside your existing Terraform or CDK rather than replacing it. Monitoring is versioned and repeatable, not clicked together in the console and forgotten.
- Default alarms across EC2, RDS, ECS, Lambda, API Gateway, CloudFront, EKS, Kafka and more
- When base2 runs it, Critical pages an engineer around the clock once thresholds are tuned, Warning is reviewed daily, Task becomes a ticket and Informational goes to Slack
- Log metric filter alarms for the patterns that matter in your logs
- Anomaly detection alarms where a fixed threshold does not fit
The checks AWS does not run for you
AWS has no native WebSocket check, and CloudWatch Synthetics canaries are heavy and expensive for what most teams actually need. Our checks run as small Lambdas and emit straight to CloudWatch, so you monitor the things AWS leaves to you without the canary bill.
- HTTP availability, status code and response body checks
- Certificate and domain expiry before either lapses, plus TLS version checks
- WebSocket endpoint checks, which AWS has no native equivalent for
- TCP port, SFTP and SQL query checks, including endpoints inside your VPC
Built by base2Services
The monitoring we run on every AWS environment we manage, so a problem reaches us before it reaches your customers.
base2Services is an AWS Advanced Consulting Partner specialising in platform engineering and managed AWS operations. Cloud Monitoring is part of how we run AWS for people, not a side project. If you would rather not run it yourself, the team that built it runs it across your accounts and owns the response.
