What "no dedicated SRE" actually means for AWS monitoring
"No dedicated SRE" doesn't mean less monitoring is acceptable — it means the on-call rotation is the engineering team, and nobody's full-time job is building or maintaining observability tooling. That's a real constraint on how monitoring gets designed, not an excuse to skip it. Here's what adequate AWS monitoring looks like under that constraint, as a checklist rather than a headcount problem.
- What does "no dedicated SRE" actually change?
- 1. Infrastructure alarm baseline
- 2. Security baseline
- 3. Cost baseline
- 4. Multi-account coverage
- 5. One place investigations happen
- What "good enough" looks like without a dedicated SRE
What does "no dedicated SRE" actually change?
It changes the design constraint, not the goal. A dedicated SRE team can build custom tooling, tune alarms continuously, and staff a real on-call rotation with clear escalation. A team without one needs monitoring that defaults correctly, doesn't require daily maintenance, and pages a specific person instead of creating a triage queue nobody owns. The checklist below is ordered by how much damage the gap does if it's missing, not by how interesting each piece is to build.
1. Infrastructure alarm baseline
CPU, memory, error rate, and disk alarms for every production service — ECS, EC2, RDS, Lambda, ALB, whatever you actually run. This is the most well-trodden ground in AWS monitoring content, and for good reason: it's the layer that catches the incidents that happen most often.
Related reading
2. Security baseline
GuardDuty enabled in every account and region, routed through EventBridge to somewhere your team actually watches, plus CIS AWS Foundations Benchmark CloudTrail alarms for root account usage, unauthorized API calls, and security group changes. This layer is usually the most neglected precisely because it doesn't fire during normal operation the way an infrastructure alarm does — there's nothing reminding you it's missing until an incident does.
3. Cost baseline
Two tools cover this, and both are effectively free to run. AWS Cost Anomaly Detection uses machine learning to flag deviations from your normal spend pattern at no additional service charge (you only pay standard Cost Explorer API costs, and the first 1,000,000 requests/month are free) — it needs roughly two to four weeks of historical data to build an accurate baseline, so turn it on before you need it, not after a surprise bill. AWS Budgets covers the static-threshold case — a hard dollar limit you define — and includes 62,500 free email notifications per month before any charge applies.
Set both before you spend the first meaningful dollar on a new project, not after. Cost Anomaly Detection catches drift you didn't anticipate; Budgets catches the threshold you already know matters.
4. Multi-account coverage
If you're running AWS Organizations — production, staging, security, sandbox, or per-customer accounts — coverage isn't one number, it's one number per account. The account that gets attention is usually the oldest one; new accounts silently start from zero unless baseline alarm setup is part of how they're provisioned, not an afterthought someone means to get to.
Related reading
5. One place investigations happen
CloudWatch's metrics, Logs Insights, and traces each use a different query language and console tab — that's a fixed cost of the platform, not something a small team fixes by building better tooling. What's fixable: a shared library of saved Logs Insights queries per service, so nobody re-derives the query syntax under time pressure, and a runbook that gets updated after every incident instead of written once and forgotten.
Related reading
What "good enough" looks like without a dedicated SRE
| Layer | You have adequate coverage if... | You have a real gap if... |
|---|---|---|
| Infrastructure | Every production service has CPU/memory/error alarms tied to a channel someone watches | Alarms exist only on the services someone happened to build them for |
| Security | GuardDuty is on everywhere, findings route somewhere real, CIS CloudTrail alarms exist for root usage and IAM changes | GuardDuty was never enabled, or findings sit in a console tab nobody opens |
| Cost | Cost Anomaly Detection is on and has weeks of baseline data; Budgets has a hard threshold set | The first anyone hears about a cost spike is the invoice |
| Multi-account | New accounts inherit baseline alarms as part of provisioning | Coverage exists only in the oldest, most-attended-to account |
| Investigation | A shared query library and a runbook exist and get updated after incidents | Every incident starts from zero, re-deriving the same queries |
None of the five layers above require a dedicated SRE to build or maintain — they require deciding, once, that each layer gets a baseline instead of getting skipped because nobody's specific job is to own it.
Frequently asked questions
What does monitoring without a dedicated SRE actually require?
Five baseline layers: infrastructure alarms (CPU, memory, errors) on every production service, a security baseline (GuardDuty plus CIS CloudTrail alarms), cost alerting (AWS Cost Anomaly Detection and Budgets), consistent alarm coverage across every AWS account, and a shared investigation setup (saved queries, an updated runbook) so incidents don't start from zero each time.
Is AWS Cost Anomaly Detection free?
Yes — AWS Cost Anomaly Detection itself has no additional service charge. You only pay standard AWS Cost Explorer API costs, and the first 1,000,000 API requests per month are free. The anomaly detection model needs roughly two to four weeks of historical spend data to build an accurate baseline.
What's the difference between AWS Budgets and AWS Cost Anomaly Detection?
AWS Budgets alerts on a static, manually defined dollar threshold. AWS Cost Anomaly Detection uses machine learning to dynamically learn your normal spend pattern and alerts only on genuine deviations, which produces fewer false positives than a fixed threshold. Budgets includes 62,500 free email notifications per month before charges apply.
Why is the security monitoring layer usually the most neglected for small teams?
Because unlike infrastructure alarms, security gaps don't fire during normal operation to remind you they exist — GuardDuty being disabled or CIS CloudTrail alarms never being set up is silent until an actual security incident happens, at which point the absence is discovered the hard way.
How do I know if my AWS monitoring coverage is actually good enough?
Check five things: infrastructure alarms exist on every production service (not just the ones someone happened to build them for), GuardDuty is enabled everywhere with findings routed somewhere real, cost anomaly detection and budgets are both configured, new AWS accounts inherit baseline alarms automatically, and your team has a shared query library and a runbook that gets updated after incidents.
Related reading
Not sure your alarm coverage is actually solid?
Run a free Nuberio Audit — hygiene score, missing alarms, and security findings in about 5 minutes.