Configure event notifications and subscriptions

Almost every control in this group costs nothing in AWS spend to satisfy. Creating an RDS event subscription or enabling S3 event notifications has no per-resource fee, and the downstream destinations cost a fraction of a cent per thousand messages. The only spend is the one-time engineering time to wire it up. What is not free is the cost of the absence: when a failover, a low-storage event or an unexpected object change goes unseen, the first signal is typically a customer complaint or a full outage, both far more expensive than the notification that would have arrived minutes earlier.

Frame these as audit-readiness and incident-cost items rather than savings items, because there is no meaningful dollar lever to pull. The relevant numbers are the count of accounts and buckets with no notifications, whether that count is trending down, and the history of incidents that were discovered late. Even one database outage this year that was found from a customer ticket usually pays for the entire remediation.

These are mostly Low or Medium severity, which is the right framing for the budget conversation: not an emergency, but cheap insurance against an expensive surprise. The subtle point is that a subscription existing is not the same as a subscription being useful. RDS.19 through RDS.22 exist precisely because teams set one up, check the box, and never confirm it covers the failure events, so the finance question is not "do we have monitoring?" but "is it wired to the right events and has anyone tested that the page actually arrives?"

Priya is the finance partner reviewing the security pack at the same fintech. Security Hub shows a cluster of notification findings: several production accounts with no RDS event subscription at all (RDS.27), one account with an instance subscription missing the failure categories (RDS.20), and a customer-uploads bucket with no S3 notifications (S3.11). She knows the dollar lever here is near zero, because creating a subscription is free and the downstream messages cost a fraction of a cent per thousand, so she does not treat this as a savings line.

Instead she sizes it as cheap insurance against an expensive surprise. She asks the team for one number: how many incidents this year were first discovered from a customer ticket rather than from the systems themselves. The on-call lead admits they have been learning about failovers from support tickets for months. That single fact reframes the conversation: even one database outage found late, with its on-call hours, SLA credits and post-mortem, dwarfs the near-zero cost of wiring the events. Her output for the pack is two lines: the count of accounts and buckets with no notifications, and a note that a configured subscription is not the same as a tested one, so she will ask whether anyone has confirmed the page actually arrives.

The financial impact of running without notifications accumulates through incidents, not through AWS charges. The notifications themselves cost essentially nothing. What missing them costs is measurable: each problem that would have been caught early instead becomes a customer-visible outage with the full incident-cost stack of on-call hours, SLA credits, post-mortems and potential churn.

The way to size it is a simple expected-value sketch: estimate the cost of an outage that runs an hour or two longer because nobody was alerted, and multiply by how often that is plausible over a year. Even a low probability against a high-cost outcome dwarfs the near-zero cost of the fix. This is the textbook profile of cheap insurance, and the right finance move is to make sure these Low-and-Medium-severity but high-leverage controls do not get starved when triage runs purely on the severity label.

There is also an audit-and-deal dimension. Open monitoring findings feed the compliance score that surfaces in security questionnaires, vendor risk assessments and SOC 2 / ISO audits. "Can you detect when a database fails or when data in your storage changes?" is a question that gets asked, and an open finding is an awkward answer that can delay a deal or a renewal. Track these as audit-readiness lines with an owner and an audit-anchored deadline, not as savings items, and require that a subscription be tested end-to-end rather than just configured, because a subscription that SNS silently drops is no better than none.

AWS sends real-time signals when something important happens to a database or a storage bucket: a failover begins, disk space runs low, a production instance is deleted, an object changes. Without an event subscription or notification configuration, those signals go unread until a customer or a broken application surfaces the problem. With one, the right team is paged within seconds.

Security Hub flags the accounts and buckets where this is not configured. The cost to set it up is negligible; the cost of not having it is higher mean-time-to-recovery, more customer-visible incidents, and a weaker compliance posture against the continuous-monitoring controls auditors test. The leadership question is simple: do we find out about our own problems before or after our customers do?

None of this is a cost decision. Wiring events is close to free in AWS terms. It is a governance decision about whether the organisation is the first to know when its critical systems are in trouble, or the last.

After an incident review where a Multi-AZ failover had been surfaced by a customer complaint rather than by the on-call page, the CTO asked the question that frames this whole capability: do we find out about our own problems before or after our customers do? The honest answer was after, because AWS was emitting the signals (failover, low storage, deletion) but nobody had wired them to a destination anyone was listening to.

The leadership response was to set a standard rather than chase findings: every production account and every sensitive bucket has active, tested notifications, baked into the account landing-zone template and the bucket module so new accounts and buckets are covered from day one. Crucially they required the routes to be tested end-to-end, not just configured, because a team had previously set up a subscription, checked the box, and never confirmed it covered the failure categories. Six months on, the answer to the CTO's question had flipped to before, and the four RDS event controls staying green and tested became a standing confidence signal that the team maintains its monitoring rather than setting it and forgetting it.

Running without these notifications means the organisation is systematically blind to its own problems until they surface externally, via customer complaints, application outages, or a deleted production database nobody noticed. AWS is emitting the signals; the question Security Hub is measuring is whether anyone is listening. The reason a low-dollar finding earns a line on the report is leverage: the fix is among the cheapest available, and the thing it protects against is one of the more expensive incidents a platform team can have.

These findings are also a tell about operating discipline. A failing notification control usually means someone set up monitoring once and never verified it covered the events that matter, the same pattern that hides in bigger, less-visible systems. A team that keeps these green, tested and maintained is a team that maintains its monitoring rather than setting it and forgetting it. The leadership move is to set the standard (every production account and sensitive bucket subscribed, tested end-to-end, and maintained) and bake it into account and bucket provisioning, so the gap is closed at creation rather than discovered during an outage or an audit.