There are two very different jobs that get filed under the same word, "monitoring," and conflating them is how people end up feeling covered while being exposed. One job is to tell you when something has already broken so you can go fix it. The other is to stop a certain class of mistake from happening at all, even by someone with the authority to make it. The first is alerting. The second is guardrails. They are not substitutes, and I have one of them in a much better state than the other. This part is about being honest about which is which.
The wake-me tier
The alerting tier has an honest label, and the label is "wake me if it is down." Not analytics, not security intelligence, not anomaly detection. It answers one question: is something on fire right now that I would want to know about before a customer tells me.
For the fleet I run, this is a self-hosted stack, and I run it self-hosted on purpose. Prometheus scrapes metrics, Loki aggregates logs, Grafana puts a face on both, and Alertmanager handles routing when a threshold trips. It lives on a small instance, roughly thirty to thirty-five dollars a month, sitting behind a VPN with the security groups restricting access to the VPN range only, basic auth on top, TLS in front, and encrypted volumes underneath. Node exporters run on each host, a log shipper forwards into Loki, and Alertmanager decides what is worth interrupting me for.
The discipline that matters here is not the tooling, it is restraint. An alert that fires on noise gets muted, and a muted alert is strictly worse than no alert, because it costs you the false confidence of thinking something is watching. So the wake-me tier is kept small and kept true. It watches for the handful of conditions that genuinely mean something is wrong: a host down, resource exhaustion, a service not responding. Everything else is a dashboard, not a page.
For the serverless side of the world, the audit trail from the previous two parts is the raw material for the equivalent. You do not watch metrics there, you watch events. The right design is not to alert on everything the trail records, that is just the noisy haystack again, but to alert on the small set of events that should essentially never happen in normal operation. The audit trail being disabled. An identity policy changing outside a deploy. The account root being used at all. A sign-in without a second factor. These are events where the correct number is close to zero, so any occurrence is worth a notification wired to a topic that reaches me. Alert on the things that should never happen, not on the things that happen all the time.
Alerting is still after the fact
Here is the limit of everything above, and it is a hard limit. Every alert I just described fires after the event has already occurred. The audit trail records the policy change, then the alert tells me about it, then I go react. That is genuinely valuable and it is also, fundamentally, cleanup. By the time the page arrives, the thing already happened. Alerting shortens the time between a mistake and my knowing about it. It does nothing to prevent the mistake.
That is what guardrails are for, and it is where I have to be honest about a real gap.
Guardrails, and the gap I actually have
A guardrail is policy that cannot be casually switched off by the next hasty change, including a change made by someone with admin rights. On AWS the mechanism for this is organization-level service control policies: rules that sit above every account and that no member account can override, no matter how privileged the actor inside it is. The kind of rule you want as a guardrail is exactly the kind that protects the controls this whole series built. Deny disabling the audit trail. Deny making a bucket public. Deny operating outside the approved regions. Deny deleting the log bucket. These are not suggestions the account can talk itself out of. They are walls.
I do not have those. And the reason is structural and worth stating plainly: I run a single account today. Service control policies require an organization with a management account sitting above member accounts, and with one account there is no "above" to put them. So the strongest form of guardrail, the one that says "even an administrator cannot turn off the audit trail," is exactly the thing I have not built. Naming that honestly is more useful than pretending a pile of alerts adds up to prevention. It does not.
What I do have in its place is discipline, and it is worth being precise about the difference. Everything is defined in Terraform. Destructive or risky changes show up in a plan and get reviewed before they apply. Drift is visible when I run the plan. That is real and it catches a lot. But it is a habit, not a wall. A habit protects you exactly until the moment someone is in a hurry. A console click at 2am, made directly against the account to fix something urgent, bypasses the entire review path and leaves no plan to catch it. The audit trail would record that click, and an alert might even tell me about it, but nothing stopped it. That is the exact line between a guardrail and a good intention: the guardrail holds when the person is careless or rushed or wrong, which is precisely when you need it and precisely when discipline fails.
The next real step
So the honest state is this. The wake-me tier is real, it is the pattern I run, and it knows its own scope. Alerting on the never-happen audit events is a clean, cheap extension of the trail I already built. And the guardrail layer, the enforced kind that survives a mistake, is a named gap rather than a solved problem.
The next real step is not more alerts. It is structural. Create an organization, move the workload into a dedicated member account, keep root and billing up in a management account that does almost nothing day to day, and apply service control policies from above. That is the move I would make on day 0 if I were starting the account again today, with the organization in place before the first real resource, so the guardrails predate anything worth protecting. Retrofitting it onto a running single account is more work than doing it first, which is the recurring lesson of this entire series: the cheap moment to set a default is before you have anything that depends on it.
That gap, and a couple of others I have not built, is exactly what the final part adds up. Time to score the whole thing honestly.
Previous: An Audit Trail You Cannot Question Is a Receipt You Never Read Next: The Honest Scorecard
The same decision, the other cloud: Know When It Breaks, and Guardrails on GCP