GLASSMKR VS AWS CLOUDWATCH
Glassmkr vs AWS CloudWatch: bare-metal hardware monitoring vs AWS-native observability.
Different scopes, different deployments. The comparison is more "different tool" than "alternative tool."
Last verified: 2026-08-25. Glassmkr is not affiliated with Amazon Web Services.
Amazon CloudWatch is AWS’s native observability service. Per-metric pricing ($0.30/custom metric/month for the first 10,000, scaling down to $0.05 above 250,000) 1. Always-free tier covers 10 custom metrics + 10 alarms + 5 GB logs 1. The CloudWatch Agent is MIT-licensed and open source 3.
Glassmkr is open-source bare-metal hardware monitoring, free in both deployment forms: self-hosted (AGPL-3.0-only, no node limits) or hosted at app.glassmkr.com (10-node per-account cap) G. 70 alert rules tuned for hardware failure modes.
The two tools have less overlap than they first appear. CloudWatch is the right answer when you’re fully on AWS. Glassmkr is the right answer when you run physical infrastructure (colo, on-prem, owned racks) and need hardware-level signals CloudWatch doesn’t expose.
What’s the same
Both have agents that collect OS-level metrics (CPU, memory, disk, network). Both support alerting, dashboards, and log/metric retention. Both have free tiers. Both have programmatic APIs.
What’s different
| Dimension | AWS CloudWatch | Glassmkr |
|---|---|---|
| Optimized for | AWS workloads (EC2, RDS, Lambda, ECS, EKS, ALB, S3, ...) | Bare-metal Linux servers (any host) |
| Pricing: custom metrics | $0.30/metric/mo first 10k; $0.10 (10k-250k); $0.05 (250k+) 1 | Included; Glassmkr is free G |
| Pricing: alarms | $0.10 per standard-resolution alarm/mo 1 | Included; nothing is metered |
| Pricing: logs | $0.50/GB ingest, $0.03/GB/mo storage; Logs Insights queries billed per GB scanned 1 | N/A (Glassmkr doesn’t ingest logs) |
| Free tier | 10 custom metrics, 10 alarms, 5 GB logs 1 | Everything: all 70 rules + all channels; self-hosted has no node limits, hosted is capped at 10 nodes |
| Self-hostable | No; CloudWatch is an AWS service, the backend cannot leave AWS | Yes; AGPL-3.0-only end to end, one docker-compose file |
| Agent license | MIT 3 | MIT (Crucible) |
| Agent platform support | Linux/Windows/macOS; collects OS metrics + logs + (v1.300025.0+) OpenTelemetry/X-Ray traces 2 | Linux server |
| SMART / IPMI / RAID / ECC | NOT collected: outside the agent’s data model 2 | Built-in via Crucible agent |
| AWS-service-native metrics | Deep: EC2, RDS, Lambda, etc. publish natively without an agent | None: Glassmkr observes only what its agent collects on the server |
| Outside AWS | Agent runs on-prem; data flows to AWS; architecture assumes AWS control plane | Independent of any cloud provider |
The agent question
The CloudWatch Agent is open source (MIT) and collects OS-level metrics: CPU times/usage, memory (/proc/meminfo-derived), disk, network, processes, swap, ethtool counters 2. It also collects logs, StatsD/collectd, and (v1.300025.0+) OpenTelemetry/X-Ray traces. Metrics ship as custom metrics under the CWAgent namespace and bill accordingly 1.
Verified absent from the agent’s metric list 2: SMART attributes, IPMI sensors, RAID array state, ECC corrected/uncorrectable counters, PSU/fan/thermal hardware sensors. Hardware-level visibility is not part of CloudWatch’s data model: even on EC2 bare-metal (.metal) instances 4 where the guest has direct hardware access.
Bare-metal EC2
EC2 .metal instances (Nitro System) give the guest OS direct hardware access with no hypervisor 4. However, the CloudWatch Agent installed on those guests still collects only the OS-level metrics enumerated above. No SMART/IPMI/RAID/ECC metrics are surfaced by CloudWatch’s data model regardless of host. If you run EC2 .metal and want hardware-level visibility, Glassmkr fills the gap.
When CloudWatch is the right choice
You’re fully on AWS.
One console spanning EC2 + RDS + Lambda + Logs + X-Ray traces. Native service metrics without an agent. IAM-tied access. If your stack is AWS, CloudWatch is the path of least resistance.
You want unified logs + metrics + traces.
CloudWatch Logs Insights, ServiceLens, Container Insights, X-Ray. Glassmkr doesn’t do logs or traces.
You have low custom-metric volume.
For ≤10 custom metrics + alarms per host, the always-free tier covers most of it 1. If everything you monitor fits that free tier and lives on AWS, adding a second tool is overhead you don’t need.
You’re an AWS-shop, not a physical-infrastructure-shop.
If you don’t run any servers you can physically touch, CloudWatch’s scope matches your reality.
When Glassmkr is the right choice
You run physical infrastructure.
Colo, on-prem, owned racks, bare-metal in datacenters. CloudWatch can monitor these hosts via the agent but doesn’t expose hardware-level signals.
You need SMART, IPMI, RAID, ECC visibility.
Hardware-level signals CloudWatch’s data model doesn’t cover, even on EC2 .metal instances 2. Glassmkr exposes them natively.
You’re explicitly diversifying away from AWS-coupled tooling.
If "not AWS-locked" is a posture (multi-cloud, on-prem migration, vendor risk), Glassmkr is cloud-agnostic.
You don’t want a metered bill at all.
CloudWatch’s metric/alarm/log billing is granular and can surprise. Glassmkr has no metering: free self-hosted with no node limits, free hosted up to 10 nodes.
Self-hosting
CloudWatch cannot be self-hosted; it exists only as an AWS service, and your telemetry lives in your AWS account by definition. Glassmkr is self-hostable end to end: the dashboard is AGPL-3.0-only, the Crucible agent is MIT, and the whole stack runs from a single docker-compose file, on any infrastructure, with no data leaving it unless you choose the hosted instance.
Migration: switching from CloudWatch to Glassmkr
CloudWatch custom metrics → Glassmkr per-node metrics. Same kind of OS-level visibility; Glassmkr adds the hardware-level signals CloudWatch doesn’t expose.
CloudWatch Alarms → Glassmkr alert rules. Glassmkr’s 70 rules cover bare-metal failure modes that CloudWatch alarms wouldn’t typically target (because CloudWatch can’t see the signals). Many CloudWatch alarms on EC2 hosts have no Glassmkr equivalent because they were monitoring AWS-service-native metrics (RDS IOPS, ALB target health, Lambda errors) that Glassmkr doesn’t observe.
CloudWatch Logs → not migrated. Glassmkr doesn’t ingest application logs. If your CloudWatch usage is dominated by logs + Logs Insights queries, Glassmkr doesn’t cover that workload.
X-Ray traces → not migrated. No equivalent. Glassmkr doesn’t do APM/tracing.
Realistic migration scenario: keep CloudWatch for AWS-service-native metrics (RDS, Lambda, ALB) and logs/traces. Add Glassmkr for hardware-level visibility on EC2 .metal hosts or on-prem servers where CloudWatch’s agent misses the bare-metal signals.
- Amazon CloudWatch Pricing, aws.amazon.com/cloudwatch/pricing (verified 2026-08-25). All prices reference us-east-1 pay-as-you-go.
- CloudWatch Agent: metrics collected, docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html (verified 2026-08-25). Verified absent: SMART, IPMI, RAID, ECC, PSU/fan/thermal hardware sensors.
- amazon-cloudwatch-agent GitHub repository (MIT licensed), github.com/aws/amazon-cloudwatch-agent (verified 2026-08-25).
- EC2 Bare Metal Instances announcement ("Direct Access to Hardware"), aws.amazon.com/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware (verified 2026-08-25). AWS Nitro System (bare metal instances let customers "bring their own hypervisor or have no hypervisor"), aws.amazon.com/ec2/nitro (verified 2026-08-25).
- Glassmkr pricing page, glassmkr.com/pricing (verified 2026-08-23). Free self-hosted (AGPL-3.0-only, no node limits); hosted free with a 10-node per-account cap.