For awsplace, we built a multi-layered monitoring setup so we always know exactly what’s going on. We use CloudWatch dashboards to see things in real-time, alarms to alert us when things go wrong, health checks to keep our containers running smoothly, and centralized logging to help us figure out why something broke. We define all of this right in our CDK code, so there’s no need to click around the AWS console—and it’s all tested automatically before deployment.
Here’s a look at our monitoring setup:
| Sub-section | Description |
|---|---|
| 5.7.1 CloudWatch Dashboards | Visual panels for our Raft metrics, EFS storage, container CPU/RAM usage, and load balancer health |
| 5.7.2 CloudWatch Alarms | Alerts for high CPU/memory, data snapshot issues, deployment rollbacks, and failed health checks |
| 5.7.3 Container & Application Health Checks | Keeping containers healthy with ECS and ALB health probes, plus rules for how containers should start up |
| 5.7.4 Centralized Logging | Storing and organizing all our logs in CloudWatch so we can easily search them when debugging |
Our approach to monitoring is simple: we only monitor things that actually break our application. Instead of cluttering our dashboards with every metric AWS offers, we focus on what matters:
This keeps our dashboards clean and our alerts useful. When an alarm goes off, we know exactly what to fix.