Rds Operation Review

RDS / Aurora Operational Review

Conduct a comprehensive operational review of Amazon RDS instances and Amazon Aurora clusters aligned with the AWS Well-Architected Framework and the Amazon RDS and Aurora best-practices guides.

This skill uses the AWS RDS, Aurora, CloudWatch, CloudWatch Logs, EC2, and Cost Explorer APIs only — no Kubernetes (k8s) or eks MCP tools. All data is collected through native AWS APIs available to the DevOps Agent's primary cloud source role.

When to Use

Activate this skill when the user asks to:

• Review, audit, or assess RDS instances or Aurora clusters
• Check RDS / Aurora best-practices compliance
• Evaluate database security, cost, reliability, performance, or backups
• Perform an RDS / Aurora operational readiness review (ORR)
• Investigate database health or configuration drift

Step 1: Identify Target Resources

Ask the user which databases to review. Accept:

• Specific instance / cluster identifiers and regions
• "all instances" / "all clusters" in specific regions
• "all RDS in all regions"

If no scope is given, default to all configured account regions.

Step 2: Discover RDS / Aurora Resources

Per region (skip empty regions):

rds.DescribeDBInstances           # RDS instances + Aurora cluster member instances
rds.DescribeDBClusters            # Aurora clusters (skip if user said "Provisioned only")
rds.DescribeDBClusterEndpoints    # Aurora reader/writer endpoints
rds.DescribeGlobalClusters        # Aurora Global Database (cross-region)
rds.DescribeDBProxies             # RDS Proxy

Capture per resource:

• Engine, engineVersion, dbInstanceClass / serverlessV2 capacity
• Multi-AZ, AvailabilityZones, subnetGroup, VpcId
• AllocatedStorage, MaxAllocatedStorage, StorageType, Iops, StorageThroughput, StorageEncrypted, KmsKeyId
• BackupRetentionPeriod, PreferredBackupWindow, PreferredMaintenanceWindow, AutoMinorVersionUpgrade
• DeletionProtection, PubliclyAccessible, IAMDatabaseAuthenticationEnabled
• PerformanceInsightsEnabled, PerformanceInsightsRetentionPeriod, MonitoringInterval (Enhanced Monitoring), MonitoringRoleArn
• EnabledCloudwatchLogsExports, AssociatedRoles
• ReadReplicaSourceDBInstanceIdentifier / ReadReplicaDBInstanceIdentifiers
• Tags (rds.ListTagsForResource — param name is ResourceName and value is the resource ARN)

Step 3: Discover Configuration Dependencies

For each database, collect:

rds.DescribeDBParameterGroups           # custom vs default
rds.DescribeDBClusterParameterGroups    # Aurora
rds.DescribeOptionGroups                # RDS option groups
rds.DescribeDBSubnetGroups              # subnet AZ spread
ec2.DescribeSecurityGroups              # vpcSecurityGroupIds → ingress rules
kms.DescribeKey                         # for KmsKeyId (encryption at rest)

Step 4: Collect Backups, Snapshots, Maintenance

rds.DescribeDBSnapshots                            # manual + automated, per instance
rds.DescribeDBClusterSnapshots                     # Aurora
rds.DescribeDBInstanceAutomatedBackups
rds.DescribeDBClusterAutomatedBackups
rds.DescribeDBEngineVersions                       # current vs latest minor/major
rds.DescribePendingMaintenanceActions
rds.DescribeEvents                                 # last 14 days; duration in MINUTES (20160)
rds.DescribeEventSubscriptions

For each instance/cluster, also fetch:

• rds.DescribeDBLogFiles — list of logs available locally on the DB
• logs.DescribeLogGroups with prefix:
• Instances: /aws/rds/instance/<dbInstanceIdentifier>/
• Aurora: /aws/rds/cluster/<dbClusterIdentifier>/

Step 5: Collect CloudWatch Metrics (7-Day Historical)

One cloudwatch.GetMetricData call per resource. Period: 21600 (6 hours). StartTime: 7 days ago. EndTime: now.

5.1 RDS Instances (dimension DBInstanceIdentifier)

5.2 Aurora Clusters (dimension DBClusterIdentifier)

5.3 Per-Instance Aurora Members

Same instance metrics as 5.1, dimensioned by DBInstanceIdentifier of each cluster member.

Fetch cloudwatch.DescribeAlarmsForMetric for the key metrics (CPUUtilization, FreeStorageSpace, DatabaseConnections, ReadLatency, WriteLatency, ReplicaLag / AuroraReplicaLag) per resource so the report can flag missing alarms.

Step 6: Collect Logs (7-Day)

Per database log group, scan with logs.FilterLogEvents for:

Record occurrence counts per pattern over the 7-day window.

Step 7: Collect CloudTrail-Visible RDS Events

Use rds.DescribeEvents (last 14 days) per resource — covers the same operational signal as CloudTrail for RDS without an extra API permission. Look for: failover, restart, parameter group apply, out-of-memory, storage-full, low-storage, automated-backup-failed, maintenance-related events, read replica error, instance stopped.

Step 8: Cost Data

Once per review (not per resource):

costexplorer.GetCostAndUsage     # 3 months, by USAGE_TYPE,
                                 # filter Service = "Amazon Relational Database Service"
rds.DescribeReservedDBInstances  # RI inventory

Estimate per-database monthly cost as a proportional split of the latest month total (Cost Explorer doesn't break down per DB):

1. Get the most recent full month total RDS spend. 2. Per resource, weight by vCPUs(instance class) × (Multi-AZ ? 2 : 1) + allocatedStorageGB. 3. For Aurora clusters, sum across cluster member instances; storage is cluster-shared. 4. Note the estimate in the report with an "estimated" badge.

Step 9: Analyze Against Best Practices

Evaluate ALL collected data across the five Well-Architected pillars and assign a severity to every finding: CRITICAL, HIGH, MEDIUM, LOW, or INFO.

9.1 Security

Ref: Security in Amazon RDS

• Network exposure: PubliclyAccessible=true → CRITICAL for production. Security groups with 0.0.0.0/0 ingress on the DB port → CRITICAL.
• Encryption at rest: StorageEncrypted=false → HIGH (or CRITICAL for regulated workloads). Customer-managed KMS key preferred over AWS-managed.
• Encryption in transit: parameter rds.force_ssl=1 (Postgres) / require_secure_transport=ON (MySQL/MariaDB) → MEDIUM if not set.
• IAM auth: IAMDatabaseAuthenticationEnabled=false → MEDIUM. Master password in app code instead of Secrets Manager → HIGH.
• Secrets Manager rotation: not enabled → MEDIUM.
• Audit logging: engine audit logs not in EnabledCloudwatchLogsExports → MEDIUM (HIGH for PCI/HIPAA scope).
• CMK rotation: KMS key without automatic rotation → LOW.

9.2 Reliability

Ref: High Availability for Amazon RDS

• Multi-AZ: production single-AZ → HIGH (Aurora: ≥1 reader in a different AZ).
• Subnet group AZ spread: subnets span <2 AZs → HIGH.
• Backups: BackupRetentionPeriod=0 → CRITICAL. <7 days for production → HIGH.
• Deletion protection: production with DeletionProtection=false → HIGH.
• Auto minor version upgrade: AutoMinorVersionUpgrade=false for non-prod → MEDIUM.
• Custom parameter group: instance using default.<engine> parameter group → MEDIUM (can't tune).
• Pending maintenance: required actions not applied within window → MEDIUM, escalating with age.
• Replication health (read replicas): ReplicaLag 7-day max > 30s → HIGH; > 300s → CRITICAL.
• Aurora replicas: clusters with no reader → MEDIUM; single-AZ readers → MEDIUM.
• DR: cross-region read replica or Aurora Global Database absent for tier-1 workloads → MEDIUM.

9.3 Performance

Ref: DB Instance Performance

7-day metric thresholds (full table in references/metrics-thresholds.md):

• CPUUtilization avg > 70% → MEDIUM, > 90% → HIGH.
• FreeStorageSpace < 20% allocated → HIGH, < 10% → CRITICAL.
• FreeableMemory < 10% instance class memory → HIGH; sustained SwapUsage > 0 → MEDIUM.
• DatabaseConnections max > 80% of max_connections parameter → HIGH.
• ReadLatency / WriteLatency avg > 20ms (10ms for io1/io2) → MEDIUM.
• BufferCacheHitRatio (Aurora) < 95% → MEDIUM, < 90% → HIGH.
• BinLogDiskUsage growth without retention bounds → MEDIUM.
• Performance Insights disabled → MEDIUM (free 7-day tier should always be on).
• Enhanced Monitoring disabled or interval > 60s for production → MEDIUM.
• Connection pooling: high connection churn / no RDS Proxy → MEDIUM for serverless / many-client workloads.

9.4 Cost Optimization

Ref: Cost-Optimized Architectures

• Stopped instances: DBInstanceStatus=stopped (still pays storage) → HIGH.
• Previous-generation classes: db.m4 / db.r4 / db.t2 → MEDIUM.
• gp2 → gp3: any StorageType=gp2 → MEDIUM (≈20% cheaper, equal/better performance).
• Over-provisioned IOPS: io1/io2 with avg IOPS used / IOPS provisioned < 50% → MEDIUM.
• Reserved Instance coverage: production On-Demand without RIs → MEDIUM, with estimated savings.
• Storage autoscaling: MaxAllocatedStorage not set → LOW, increases stockout risk.
• Idle databases: DatabaseConnections 7-day max < 5 + CPUUtilization 7-day avg < 5% → MEDIUM (candidate to stop / delete).
• Manual snapshots: many > 90 days old → LOW (review retention).
• Cost-allocation tags: missing Environment, Owner, CostCenter → LOW.
• Graviton migration: x86 (db.r5, db.m5, db.t3) where Graviton is supported → MEDIUM (~20% saving).

9.5 Operational Excellence

Ref: Monitoring Amazon RDS

• CloudWatch alarms: missing alarms on CPUUtilization, FreeStorageSpace, DatabaseConnections, FreeableMemory, ReplicaLag → MEDIUM each.
• Event subscriptions: no rds.DescribeEventSubscriptions covering this resource → MEDIUM.
• Engine version currency: minor version not latest available → LOW; major version EOL/within 6 months → HIGH.
• Log exports: engine error / slow / audit logs not exported to CloudWatch → MEDIUM.
• Maintenance window: not configured / overlaps business hours → LOW.
• Tagging: missing operational tags (Environment, Owner, Runbook, OnCall) → LOW.
• Drift: parameters changed in default parameter group (impossible by design — use as a flag for non-default usage check).

Step 10: Generate Report

Generate a separate shareable report artifact for each resource reviewed.

Artifact naming: rds-review-<resource-name>-<YYYY-MM-DD>.md Example: rds-review-prod-aurora-2026-04-29.md

For each resource, create the artifact as a Markdown document with:

Report Header

# RDS / Aurora Operational Review — <resource-name>
Account: <account-id> | Region: <region> | Date: <YYYY-MM-DD>
Engine: <engine> <engineVersion> | Class: <dbInstanceClass / serverlessV2 ACU> | Multi-AZ: <yes/no>

Executive Summary

• Health: ✅ HEALTHY / ⚠️ WARNINGS / ❌ CRITICAL
• Finding counts by severity
• Top 3 critical/high items

Configuration Snapshot

| Item | Value | | Engine / version | … | | Storage | type, allocated, max, IOPS, throughput, encrypted (KMS) | | Network | VPC, subnet group, AZs, public access, security groups | | Backup | retention, window, automated, deletion protection | | HA / DR | Multi-AZ, replicas, Global DB | | Auth | IAM auth, Secrets Manager, master user | | Observability | Performance Insights, Enhanced Monitoring, log exports |

Findings by Pillar

For each of Security, Reliability, Performance, Cost, Operational Excellence:

| # | Finding | Severity | Current State | Recommendation |

CloudWatch Metrics (7-Day)

| Metric | Stat | 7-Day Avg | 7-Day Max / Min | Status | Finding |

Log Pattern Analysis (7-Day)

| Pattern | Occurrences | Severity | Finding |

RDS Events (14-Day)

Notable events (failovers, restarts, low-storage, OOM, maintenance) with timestamps.

Pending Maintenance

List from rds.DescribePendingMaintenanceActions with action type, target window, age.

Engine Version

Current vs latest minor / latest major. Flag EOL.

Cost Summary

• Latest-month estimated cost for this resource (proportional split, with "estimated" badge)
• RI coverage status
• Top 3 cost-optimization opportunities (linked to findings)

Priority Matrix

| # | Finding | Severity | Pillar | Effort | Impact |

Next Steps

• Immediate (CRITICAL/HIGH — 7 days)
• Short-term (MEDIUM — 30 days)
• Long-term (LOW — 90 days)

Appendix — Reference Links

• Amazon RDS Best Practices
• Amazon Aurora Best Practices
• Monitoring RDS
• Performance Insights
• Encrypting RDS Resources
• Multi-AZ DB Instance Deployments
• Aurora Global Database
• RDS Proxy
• Well-Architected Framework

Severity Definitions

Engine-Specific Considerations

• MySQL / MariaDB — innodb_buffer_pool_size, max_connections, slow query log,

binlog retention, deprecated query_cache_type on 8.0+.

• PostgreSQL — shared_buffers, work_mem, autovacuum, pg_stat_statements,

log_min_duration_statement, replication slots.

• Oracle — BYOL tracking, SGA/PGA sizing, AWR, tablespace autoextend.
• SQL Server — tempdb file count (1 per vCPU up to 8), MAXDOP, cost threshold for

parallelism, Always On AGs vs Multi-AZ.

• Aurora — Serverless v2 ACU floor/ceiling, Global Database for DR, fast clones,

Backtrack (MySQL only), cluster cache management.

Known API Quirks (recorded so the agent doesn't trip on them)

• rds.ListTagsForResource — parameter is ResourceName, value is the resource ARN.
• rds.DescribeEvents — Duration is in minutes (20160 = 14 days).
• applicationautoscaling.DescribeScalableTargets — ServiceNamespace="rds" covers Aurora replica autoscaling.
• logs.DescribeLogGroups prefix differs:
• Instances: /aws/rds/instance/<id>/
• Aurora clusters: /aws/rds/cluster/<id>/
• Some Aurora metrics are cluster-only (AuroraReplicaLag, BufferCacheHitRatio,

VolumeReadIOPs), others are instance-only (FreeableMemory, CPUUtilization per member). Query the right dimension or both.

• rds.DescribeDBSnapshots requires pagination for accounts with many snapshots —

use MaxRecords and Marker.

Data Source Boundaries

This skill explicitly does not call:

• Kubernetes API / k8s MCP — RDS is fully managed; no cluster API exists.
• eks MCP — outside scope.
• Dante or any non-AWS scripts — keep the skill self-contained on the AWS DevOps Agent's primary cloud-source IAM role.

If a customer needs deeper SQL-level analysis (e.g. Performance Insights db.load breakdowns, top SQL by wait event), call pi.GetResourceMetrics and pi.DescribeDimensionKeys directly — both are in the same rds permission family when Performance Insights is enabled.

RDS Operation Review — AWS DevOps Agent Skill

A comprehensive Amazon RDS and Aurora operational review skill for AWS DevOps Agent. Conducts best-practices assessments aligned with the Amazon RDS Best Practices Guide, the Aurora Best Practices Guide, and the AWS Well-Architected Framework. Generates a shareable report artifact per resource.

What It Does

When activated via Chat, this skill instructs the DevOps Agent to:

1. Discover RDS instances and Aurora clusters in the configured account/regions. 2. Collect database configuration, parameter groups, security groups, subnet groups, snapshots, and events. 3. Collect 7-day historical CloudWatch metrics, RDS log group entries, and 14-day RDS events. 4. Pull 3-month Cost Explorer data and proportionally estimate per-database monthly cost. 5. Analyze against five Well-Architected pillars (Security, Reliability, Performance, Cost Optimization, Operational Excellence) plus engine-specific guidance. 6. Generate a shareable report artifact per resource, named rds-review-<resource>-<YYYY-MM-DD>.md.

All data is gathered through native AWS APIs (rds, cloudwatch, logs, ec2, kms, costexplorer, applicationautoscaling, pi). The skill does not require Kubernetes (k8s), EKS, or Dante MCP servers.

Agent Types

This skill is intended for the following agent types (selected in the Operator Web App at upload time):

• On-demand — conversational invocation in Chat ("review my Aurora cluster", "RDS health check").
• Evaluation — proactive operational improvement recommendations.

Select Generic instead if you want the skill available to all agent types.

Prerequisites

1. An AWS DevOps Agent Space with the target AWS account

You need an existing Agent Space with the target AWS account configured as a cloud source.

2. IAM permissions for the DevOps Agent's primary cloud-source role

The Agent Space's IAM role must have read access to RDS, Aurora, CloudWatch, Logs, EC2, KMS, and Cost Explorer APIs. The AWS managed policy AWSDevOpsAgent...ReadOnlyAccess (or your custom equivalent) typically covers all of the following — verify in your account before running the review:

• rds:Describe*, rds:ListTagsForResource, rds:DownloadDBLogFilePortion
• pi:DescribeDimensionKeys, pi:GetResourceMetrics (Performance Insights — only if PI is enabled on the target databases)
• cloudwatch:GetMetricData, cloudwatch:GetMetricStatistics, cloudwatch:DescribeAlarms, cloudwatch:DescribeAlarmsForMetric
• logs:DescribeLogGroups, logs:DescribeLogStreams, logs:FilterLogEvents, logs:GetLogEvents
• ec2:DescribeSecurityGroups, ec2:DescribeSubnets, ec2:DescribeVpcs
• kms:DescribeKey, kms:ListAliases
• application-autoscaling:DescribeScalableTargets, application-autoscaling:DescribeScalingPolicies
• ce:GetCostAndUsage, ce:GetReservationCoverage, ce:GetReservationUtilization
• tag:GetResources (optional — for cross-service tag reporting)

The skill operates entirely in read-only mode: it never calls Modify*, Reboot*, Restore*, Create*, or Delete* RDS APIs.

3. Performance Insights (recommended)

For richer query-level analysis, enable Performance Insights on databases you want to review:

• RDS console → Modify the instance → Performance Insights → enable (free 7-day retention by default).
• Or aws rds modify-db-instance --db-instance-identifier <id> --enable-performance-insights --apply-immediately.

Without Performance Insights, the skill still produces a complete report from CloudWatch metrics, logs, and configuration data — it just won't include db.load.avg and top-SQL breakdowns.

4. CloudWatch Logs export (recommended)

For log-pattern analysis in Step 6, enable CloudWatch Logs export for the engine logs you care about:

• MySQL/MariaDB: audit, error, general, slowquery
• PostgreSQL: postgresql, upgrade
• Oracle: alert, audit, listener, trace
• SQL Server: agent, error

RDS console → Modify the instance → Log exports → select log types. The skill reports "log exports disabled" as a finding when this is missing, but cannot retrieve historical log events without it.

5. (Conditional) Network reachability for databases in private VPCs

The rds, cloudwatch, logs, and other AWS APIs the skill calls are regional control-plane APIs — they're reached over the public AWS API endpoints regardless of whether the database itself sits in a private VPC. There is no need for a private connection to run the operational review against a database with a private endpoint, because the skill only reads metadata via control-plane APIs (it never connects to the database engine on port 3306 / 5432 / 1521 / 1433).

If your account requires all AWS API traffic to traverse VPC endpoints (org-level guardrail), ensure the following interface VPC endpoints are reachable from the agent's source path: com.amazonaws.<region>.rds, com.amazonaws.<region>.monitoring (CloudWatch), com.amazonaws.<region>.logs, com.amazonaws.<region>.ec2, com.amazonaws.<region>.kms. Cost Explorer is global (ce.us-east-1.amazonaws.com) and does not have a VPC endpoint.

If you separately want the agent to execute SQL inside a private database (out of scope for this skill — but a related capability), use the DevOps Agent private connection mechanism with an MCP server that fronts the database.

Uploading to AWS DevOps Agent

Reference: Uploading a skill

1. Package the skill

From the skills/ directory in this repo:

cd skills
zip -r rds-operation-review.zip rds-operation-review/ -x 'rds-operation-review/evals/*'

The resulting rds-operation-review.zip contains:

rds-operation-review/
├── SKILL.md          # frontmatter + skill instructions (required)
└── references/
    ├── best-practices-checklist.md
    └── metrics-thresholds.md

evals/ is excluded from the upload to keep the zip small (it's only used for offline evaluation).

Constraints (enforced at upload time):

• Total zip size ≤ 6 MB.
• SKILL.md is required and must include name and description frontmatter.
• A scripts/ directory is not allowed — uploads containing scripts are rejected.

2. Upload via the Operator Web App

1. Navigate to the Skills page in your Agent Space Operator Web App. 2. Click Add skill → Upload skill. 3. Drag and drop rds-operation-review.zip (or browse to it). 4. Select agent types: On-demand and Evaluation (or leave Generic to make it available to all agent types). 5. Review the validation results. 6. Click Upload.

3. (Optional) Connect additional observability sources

For richer analysis, connect your observability tools to the Agent Space:

Usage

In the DevOps Agent Chat, use natural language:

• "Run an RDS operational review for all databases."
• "Review my Aurora cluster `prod-aurora` in `us-east-1` for best practices."
• "Audit RDS security and cost optimization across all regions."
• "Generate an RDS best-practices report for instance `analytics-pg`."
• "ORR for our production databases."

The agent will:

• Collect all data automatically (no prompts for confirmation).
• Use only AWS APIs — no Kubernetes or external scripts.
• Generate a report artifact per resource, named rds-review-<resource-name>-<YYYY-MM-DD>.md.

Skill Contents

rds-operation-review/
├── SKILL.md                           # main skill instructions (with frontmatter)
├── README.md                          # this file
├── references/
│   ├── best-practices-checklist.md    # checklist mapped to RDS / Aurora best practices
│   └── metrics-thresholds.md          # CloudWatch metric thresholds & severity rules
└── evals/                             # evaluation data (not included in upload zip)

Best-Practices Sections Covered

Severity Definitions

License

Internal use.

RDS / Aurora Best Practices Checklist

Organized by AWS Well-Architected pillar. Maps directly to the checks in SKILL.md Step 9.

Security

• [ ] Database not publicly accessible (PubliclyAccessible=false)
• [ ] Database security group ingress scoped to application SGs (no 0.0.0.0/0 on the DB port)
• [ ] Encryption at rest enabled (StorageEncrypted=true); customer-managed KMS key preferred
• [ ] KMS key rotation enabled
• [ ] Encryption in transit enforced (rds.force_ssl=1 for Postgres, require_secure_transport=ON for MySQL/MariaDB)
• [ ] IAM database authentication enabled where supported
• [ ] Master credentials stored in AWS Secrets Manager with automatic rotation (not hard-coded)
• [ ] Engine audit logs exported to CloudWatch (PCI/HIPAA: required)
• [ ] CloudTrail enabled for RDS API activity
• [ ] No use of the default master username for runtime access (per-app users)
• [ ] VPC endpoint for RDS API used in restricted-egress accounts

Reliability

• [ ] Multi-AZ enabled for all production databases (Aurora: ≥1 reader in a different AZ)
• [ ] DB subnet group spans ≥2 AZs (≥3 for tier-1)
• [ ] Automated backups enabled with retention ≥7 days (35 days for production)
• [ ] Deletion protection enabled for production
• [ ] Final snapshot policy set on deletion
• [ ] Custom parameter group (not default.<engine>) — required to tune anything
• [ ] Pending maintenance actions applied within window
• [ ] Read-replica ReplicaLag 7-day max < 30s
• [ ] Cross-region read replica or Aurora Global Database for tier-1 DR
• [ ] Failover tested at least quarterly
• [ ] RTO / RPO documented for each database tier

Performance

• [ ] Performance Insights enabled (free 7-day tier)
• [ ] Enhanced Monitoring enabled, interval ≤60s for production
• [ ] CPU 7-day average < 70%
• [ ] FreeStorageSpace ≥20% of allocated
• [ ] FreeableMemory ≥10% of instance class memory; SwapUsage near 0
• [ ] DatabaseConnections 7-day max < 80% of max_connections
• [ ] ReadLatency / WriteLatency < 20ms (< 10ms for io1/io2)
• [ ] Aurora BufferCacheHitRatio > 95%
• [ ] RDS Proxy / connection pooling in place for serverless or many-client workloads
• [ ] Storage type sized correctly (gp3 default; io1/io2 only for >16k sustained IOPS)
• [ ] Slow query log enabled and reviewed (long_query_time=1, log_min_duration_statement=1000)
• [ ] Indexes reviewed; N+1 query patterns eliminated

Cost Optimization

• [ ] No stopped instances still incurring storage cost (delete or convert to final snapshot)
• [ ] No previous-gen instance classes (db.m4, db.r4, db.t2) in production
• [ ] gp2 → gp3 migration for general-purpose storage
• [ ] Provisioned IOPS (io1/io2) actually utilized > 50% — otherwise downsize or move to gp3
• [ ] Reserved Instances for steady-state production (1-year No Upfront baseline)
• [ ] Storage autoscaling enabled with sensible MaxAllocatedStorage
• [ ] Idle databases identified (low connections + low CPU) and stopped/deleted
• [ ] Manual snapshots cleaned up (delete those >90 days old unless retention policy says otherwise)
• [ ] Graviton (db.r6g, db.m6g, db.t4g) used where the engine supports it
• [ ] Cost-allocation tags applied: Environment, Owner, CostCenter, Application
• [ ] Cost Anomaly Detection enabled for RDS

Operational Excellence

• [ ] CloudWatch alarms on: CPUUtilization, FreeStorageSpace, DatabaseConnections, FreeableMemory, ReplicaLag / AuroraReplicaLag, WriteLatency, ReadLatency
• [ ] RDS event subscription in place, routing to SNS / chat / ticketing
• [ ] CloudWatch Logs export enabled for engine logs (error, slow query, audit, general)
• [ ] AutoMinorVersionUpgrade=true for non-production
• [ ] Maintenance window configured outside business hours
• [ ] Engine version is the latest minor within current major; major version not within 6 months of EOL
• [ ] Operational tags present: Environment, Owner, Runbook, OnCall
• [ ] AWS Config rules detect parameter / configuration drift
• [ ] DR / failover runbooks documented and linked from tags

Engine-Specific (spot checks)

MySQL / MariaDB

• [ ] innodb_buffer_pool_size ≈ 75% of memory
• [ ] max_connections sized to instance class
• [ ] query_cache_type=OFF on MySQL 8+
• [ ] Slow query log: long_query_time=1, slow_query_log=1
• [ ] Binlog retention bounded (binlog_expire_logs_seconds)

PostgreSQL

• [ ] shared_buffers ≈ 25% of memory
• [ ] effective_cache_size ≈ 75% of memory
• [ ] work_mem 4–64 MB
• [ ] Autovacuum tuned for write-heavy tables (per-table thresholds)
• [ ] pg_stat_statements enabled
• [ ] log_min_duration_statement ≥ 1000 ms

Oracle

• [ ] BYOL vs. License Included clear in tags
• [ ] SGA/PGA sized for workload
• [ ] AWR snapshots retained
• [ ] Tablespace autoextend on with sane MAXSIZE

SQL Server

• [ ] Tempdb: 1 file per vCPU, up to 8
• [ ] MAXDOP set to vCPU count
• [ ] Cost threshold for parallelism = 50
• [ ] Always On AG vs. Multi-AZ choice documented
• [ ] Index maintenance jobs scheduled

Aurora

• [ ] Cluster has ≥1 reader (≥2 for tier-1)
• [ ] Reader auto-scaling policy in place where read traffic varies
• [ ] Aurora Global Database for cross-region DR (tier-1)
• [ ] Backtrack window sized appropriately (Aurora MySQL only)
• [ ] Serverless v2: ACU floor set high enough to avoid cold-start; ceiling caps spend
• [ ] Cluster cache management enabled for failover-sensitive workloads (Aurora PG)

RDS / Aurora CloudWatch Metrics Thresholds Reference

All metrics retrieved via a single cloudwatch.GetMetricData call per resource over a 7-day window with Period=21600 (6h). Severity reflects sustained values, not single spikes.

RDS Instance Metrics (Namespace: AWS/RDS, Dimension: DBInstanceIdentifier)

Aurora Cluster Metrics (Namespace: AWS/RDS, Dimension: DBClusterIdentifier)

Aurora Global Database

Performance Insights (when enabled)

Log Pattern Severity (CloudWatch Logs FilterLogEvents over 7 days)

Alarm Coverage Expectations

The skill flags any of these as MEDIUM when missing (cloudwatch.DescribeAlarmsForMetric returns nothing for the resource + metric):

RDS Events of Interest (rds.DescribeEvents, last 14 days)