A deep dive into RDS Event Notifications …so everyone fully understands what they are, how they work, and how to make the most out of them.
1. The Concept: RDS
Event Notifications.
AWS RDS Event
Notifications are a way the Amazon RDS
(and Aurora) informs twtech, near real-time, when something happens to its database
environment.
They can be sent to twtech via Amazon SNS (email, SMS, Lambda trigger, HTTP endpoint, etc.).
This is not
the same as CloudWatch Alarms:
- Event Notifications
→ push info about discrete occurrences (e.g., DB instance
restarted, failover started).
- CloudWatch Alarms
→ monitor metrics over time (e.g., CPU > 80% for 5 minutes).
2. The Event Flow
Here’s the logical path:
- Event Triggered
RDS detects an event (e.g., a DB parameter group was modified, backup completed, failover initiated). - RDS Event Published
The event belongs to a source category and event category (more on this below). - Subscription Match
If twtech has an Event Subscription that matches the: - Source type (DB
instance, cluster, snapshot, security group, etc.)
- Event categories (availability,
backup, configuration change, failover, etc.)
- Specific resource(s) or “all”
- SNS Topic Publish
The matching event is pushed to the SNS topic linked in the subscription. - SNS Delivery
SNS sends the notification to the endpoints you subscribed (email, Lambda, webhook, etc.).
3. Event Source Types
RDS events are tied to source
types ("what object did
this happen to…likely source"):
- db-instance
- db-cluster
(Aurora)
- db-parameter-group
- db-security-group
- db-snapshot
- db-cluster-snapshot
- db-cluster-parameter-group
4. Event Categories
Each source type has categories
of events.
Common examples:
|
Category |
Examples |
|
Availability. |
Failover started, instance
rebooted, cluster failover completed |
|
Backup. |
Backup started, snapshot completed |
|
Configuration change. |
Parameter group modified, instance
class changed |
|
Creation. |
New DB instance created |
|
Deletion. |
DB snapshot deleted |
|
Failure. |
Backup failed, instance creation
failed |
|
Recovery. |
Instance recovered after failure |
|
Restoration. |
Restored from snapshot completed |
5. Creating an RDS Event Subscription
twtech can do this via AWS
Console, CLI, or Terraform/CloudFormation.
Example AWS CLI:
# bash
aws rds
create-event-subscription \
--subscription-name twtech-rds-events \
--sns-topic-arn arn:aws:sns:us-east-2:123456xxxxx:twtech-rds-topic
\
--source-type db-instance \
--event-categories availability backup
configuration change \
--source-ids twtech-dbinstance1 twtech-dbinstance2
\
--enabled
Key notes:
- If twtech don’t specify source-ids, it applies
to all DB instances of that type in the region.
- twtech must have an existing SNS topic and grant
RDS permissions to publish to it.
- SNS topic subscribers need to confirm subscription if
using email.
6. Security Considerations
- SNS topic access policy must allow rds.amazonaws.com to Publish.
- Restrict SNS topic so only RDS can send events.
- If delivering to a Lambda, ensure least-privilege
execution role.
7. Common Use Cases
- Operational awareness:
get notified when backups or restores complete.
- High availability monitoring: detect failovers instantly.
- Security auditing:
detect changes to security groups or parameter groups.
- DevOps workflows:
trigger Lambda automation on specific DB events (e.g., auto-tagging
snapshots, initiating DR sync).
8. Example: Event → Lambda Automation
If twtech wire an SNS topic to a
Lambda, it can do things like:
Flow:
# vbnet
RDS
Event → SNS Topic → Lambda Function → Custom Action
Example:
- Event category: availability → “DB instance failover started”
- Lambda receives event JSON → posts to Slack, triggers
failover drill metrics, or logs to SIEM.
Event JSON looks like:
# json
{
"Event Source":
"db-instance",
"Event Time": "2025-08-11
15:25:35.123",
"Identifier Link":
"https://console.aws.amazon.com/rds/home?region=us-east-2#dbinstance:id=twtech-db",
"Source ID": "twtech-db",
"Message": "DB instance
failover started",
"Event ID":
"RDS-EVENT-0001"
}
9. Diagram – How It All Fits Together
Here’s a simplified visual
representation::
# pgsql
┌────────────────────┐
│ RDS DB Instance │
└─────┬──────────────┘
│ Event occurs
▼
┌────────────────────┐
│ RDS Event System │
└─────┬──────────────┘
│ Matches subscription filter
▼
┌────────────────────┐
│ SNS Topic │
└─────┬──────────────┘
│ Delivers to
▼
┌──────────────┬──────────────┬──────────────┐
│ Email Alert │ Lambda Func │ Webhook/API │
└──────────────┴──────────────┴──────────────┘
Here’s a deep dive visual representation:
+ ------------------------ +
| Amazon RDS / Aurora |
| (DB Instance / Cluster |
| Snapshots / Events) |
+ -----------+------------ +
|
| Event (backup, failover,
| config change ...)
v
+ -------- + --------- +
| RDS Event System |
+ ------- + --------- +
|
Matches subscriptions? (source type, categories,
| specific resource IDs)
v
+ ------------------+------------------ +
| |
+------+-----+ +------+------+
| Match | | No Match |
+------+-----+ +------+------+
| |
v v
+------+-----------------+ (ignored)
| SNS Topic (RDS -> SNS) |
+ ------ +----------------- +
|
v
+ ----- + ----- + ----- + ----- + ----- +
v v v v v v
Email , SMS, Lambda, Webhook, Other SNS Subscriptions
10.
Gotchas(watch out for) & Limitations
- Some Aurora-only events don’t
apply to standard RDS, and vice versa.
- RDS events are regional —
subscriptions are tied to one region.
- Not all categories exist for all source
types.
- SNS delivery latency is usually seconds,
but not guaranteed to be sub-second.
- twtech can’t filter by event message text — only by category/source.
Reference table for RDS and
Aurora event categories mapped to their exact event codes, covering all supported source types.
This guides twtech
to subscribe precisely to every possible trigger
in its environment.
Event
Categories → Event ID Codes
All information is sourced from the
AWS documentation
Source: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html?utm_source=chatgpt.com
1. DB Cluster Events (Aurora
& RDS)
|
Category |
Event
IDs & Description |
|
Configuration change. |
RDS-EVENT-0016: Reset master
credentials |
|
Creation / Deletion. |
RDS-EVENT-0170: DB cluster created /
RDS-EVENT-0171: DB cluster deleted (Aurora) |
|
Failover. |
RDS-EVENT-0069 to RDS-EVENT-0073:
Various failover states (failed, promoting, completed, same-AZ, cross-AZ) |
|
Failure. |
RDS-EVENT-0083: S3 access failure
(Aurora) |
|
Low storage. |
RDS-EVENT-0007 / RDS-EVENT-0089 /
RDS-EVENT-0227: Storage exhausted or dangerously low (Aurora) |
2. DB
Cluster Snapshot Events
|
Category |
Event
IDs |
|
backup |
RDS-EVENT-0074 / RDS-EVENT-0075:
Manual snapshot in progress/completed |
|
notification |
RDS-EVENT-0162/0163/0164: Cluster
snapshot export (failed/canceled/completed). |
3. DB
Instance Events (RDS & Aurora)
Comprehensive set of categories:
- availability, backup, configuration change,
failover, failure, low storage, maintenance, notification,
read replica, recovery, restoration, security,
security patching.
Each includes numerous event
codes like:
- Availability: RDS-EVENT-0004 (shutdown), 0006 (restarted), 0221/0222 (storage full/low), 0330/0331 (transaction log volume low), 0396 (scheduled reboot), 0419 (KMS
access failure)
- Backup: RDS-EVENT-0001 (backup start), 0002 (backup
completed), 0086 (option group
association failed)
- Configuration change: RDS-EVENT-0011, 0012, 0014, 0016, 0017,
0018, 0024–0033, 0067, 0078
- Failover: RDS-EVENT-0013 (failover started), 0015 (failover
complete), 0034 (invalid
parameters)
- Restoration: RDS-EVENT-0019 (restoration from snapshot)
- ...and many more across:
failure, maintenance, notification, recovery, security, patching
categories
4. DB
Parameter Group Events
- Configuration change: RDS-EVENT-0037: Parameter updated.
5. DB
Security Group Events (EC2-Classic legacy)
- configuration change: RDS-EVENT-0038: Security group applied
- failure: RDS-EVENT-0039: Revoking authorization—group doesn’t exist.
6. DB
Snapshot Events
- Creation: RDS-EVENT-0040, 0042 (manual);
0090, 0091 (automated)
- Deletion: RDS-EVENT-0041
- Notification: cross-region copies (0059–0061),
snapshot exports (0159–0161), local copies (0190–0197)
- Restoration: RDS-EVENT-0043.
7. RDS
Proxy Events
- Configuration change: RDS-EVENT-0204, 0207, 0213–0215
- Creation: RDS-EVENT-0203 (proxy), 0206 (endpoint)
- Deletion: RDS-EVENT-0205 (proxy), 0208 (endpoint)
- Failure: RDS-EVENT-0243 (IP exhaustion), 0275 (throttling).
8.
Blue/Green Deployment Events
- Creation: RDS-EVENT-0244
- Failure: RDS-EVENT-0245
- Deletion: RDS-EVENT-0246
- Notification: switchover started/completed
(0247–0248), canceled (0249), sequence sync (0307–0308), volumes init
(0405–0406), generic message (0409)
- Failure: RDS-EVENT-0310 sync canceled.
9.
Custom Engine Version Events
- Creation: RDS-EVENT-0316 to 0320 (preparing, creating, validating, created, creation error)
- Failure: RDS-EVENT-0198 (creation failed), 0277 (deletion failed)
- Restoring: RDS-EVENT-0352: Max DB count for PITR
changed.
Summary of Use Cases: Benefits
- Automate filtering via CLI using --event-categories,
specifying relevant categories or specific event IDs.
- Subscribe strategically—e.g., only to critical categories like failover,
failure, or low storage, or fine-tune to particular event codes.
- Visual mapping for audits—this empowers twtech to create precise
triggers, dashboards, or workflow automation (e.g., Lambda actions on
specific codes).
No comments:
Post a Comment