AWS RDS failover alerts, expiring certificates and other events you never see

Your production Aurora cluster fails over at 07:04. AWS promotes the reader, recovers the old writer, and twenty minutes later you fail back by hand. Then you try to find out why. Memory was fine, CPU peaked around 65%, connections were low, disk queues were empty. Every CloudWatch metric says nothing was wrong. On the basic support plan you can’t open a technical case, so you’re left guessing.

The answer usually isn’t in the metrics. It may have been a host replacement or a hardware problem on AWS’s side, and the place AWS tells you about that is the AWS Health dashboard, as an event affecting your account. No metric of yours will show it.

That is the general shape of the problem. A failover isn’t in your logs, and it isn’t in CloudWatch Logs either. AWS reports it as an event, on EventBridge, alongside a lot of other things a small team would want to know: scheduled maintenance and host issues, certificates about to expire, security findings, backups that failed, console sign-ins. Unless something is listening, those events go nowhere you’ll see them, and you end up piecing together what happened from metrics that were never going to tell you.

What lives on EventBridge

Every AWS service publishes events to the default event bus in each region. A few that matter to almost everyone:

What happened	source	detail-type
RDS or Aurora failover, reboot, maintenance, low storage	aws.rds	RDS DB Instance Event
GuardDuty security finding	aws.guardduty	GuardDuty Finding
Certificate approaching expiry	aws.acm	ACM Certificate Approaching Expiration
Certificate needs action to renew	aws.acm	ACM Certificate Renewal Action Required
Scheduled maintenance, service issues affecting you	aws.health	AWS Health Event
Backup job finished or failed	aws.backup	Backup Job State Change
Someone signed in to the console	aws.signin	AWS Console Sign In via CloudTrail

Some details worth knowing:

• RDS puts the human-readable description in the event’s Message. A completed Multi-AZ failover is event RDS-EVENT-0049.
• Certificate Manager sends expiry events every day, starting 30 days before a public certificate expires, or 45 days for private and imported ones. Imported certificates don’t renew themselves, which is exactly why you want to hear about them.
• GuardDuty sends a finding when it’s created and then rolls repeats up into one event every six hours by default.
• AWS Health events can take up to an hour to start arriving after you create a rule, and only cover your own account unless you use the organization view.
• Console sign-ins only reach EventBridge if the account has a CloudTrail trail turned on. Without one, they show in CloudTrail’s event history but never reach the event bus. A minimal trail for management events costs nothing beyond the S3 storage.

Why these get missed

You don’t go looking for things you don’t know exist. CloudWatch Logs gets set up because applications need somewhere to write; EventBridge rules only exist if someone sets them up on purpose. The default for most small teams is that AWS emails the account’s root address about some of these, and that address belongs to whoever opened the account five years ago.

The second reason is that even when the events are captured, they land somewhere separate from the logs. The failover is in one place, the burst of connection errors it caused is in another, and putting them side by side is a manual job.

Sending them somewhere you’ll see them

EventBridge can deliver events straight to an HTTPS endpoint with an API destination, with no code to deploy. Three pieces:

1. A connection holding the credentials for the endpoint.
2. An API destination with the endpoint’s URL.
3. A rule saying which events to send.

A rule that sends every AWS service event in the region, but leaves out the high-volume record of every API call, looks like this:

{
  "source": [{ "prefix": "aws." }],
  "detail-type": [{ "anything-but": "AWS API Call via CloudTrail" }]
}

This catches event types AWS adds later, without you editing anything. Leaving out API calls matters: with a trail turned on, every change your applications make in the account generates one, and they grow with your traffic, not with anything that needs your attention.

Rules are per region. Events from services AWS runs globally, such as certificates used by CloudFront, are reported in us-east-1, so repeat the setup there if your workloads run somewhere else.

Seeing them next to your logs

With SaneLog, the events arrive as log lines in their own source, with the AWS service as the program and a level that matches how serious the event is:

• An RDS failover arrives as a warning, an RDS failure as an error.
• A GuardDuty finding is error, warning or notice depending on its severity.
• A certificate approaching expiry is a warning; one that has expired is an error.
• A failed console sign-in is a warning.
• A CloudWatch alarm going into ALARM is an error.

The whole event is kept as fields, so you can filter on any part of it. That turns a failover into something you can see in context: open the warning from rds, choose Show surrounding events, and the connection errors from your application servers in the same minute are right there, along with any AWS Health event published for your account at the time. Two sources, one stream, and the question “why did this happen?” usually answers itself.

From there it’s an ordinary alert: a filter on program is guardduty and level is error notifies you of serious security findings; a filter on program is acm tells you a certificate needs attention long before it expires; a filter on program is signin covers the root account.

And your CloudWatch logs too

EventBridge carries what AWS reports about your account. Your Lambda output, container logs and RDS error logs are in CloudWatch Logs, and they can be forwarded too, with a small function subscribed to the log groups. Many teams reach for this after their first CloudWatch bill: ingestion is charged per gigabyte, and a noisy function can cost more than the thing it logs.

SaneLog’s AWS guide has both setups step by step, in the console or the AWS CLI, with the forwarding function ready to paste.

In short

• RDS failovers, certificate expiry, GuardDuty findings, maintenance and sign-ins are EventBridge events, not log lines.
• One rule and an API destination send all of them somewhere useful, with no code.
• Turn on a CloudTrail trail if you want console sign-ins.
• Put them beside your logs, and the next unexplained failover explains itself.