Rds Oss

RDS OSS Advisor (MySQL, MariaDB, PostgreSQL)

Overview

Advisor for Amazon RDS on the open-source engines — MySQL, MariaDB, and PostgreSQL. Five decision areas:

1. Instance creation — provision production-ready instances with best-practice defaults (latest version, Multi-AZ, encryption, Performance Insights, Secrets Manager password management)
2. Upgrade planning — identify instance, enumerate targets, run live prechecks, flag plan regressions, surface pre/post checklists
3. Commitment pricing — estimate RI and Database Savings Plan savings for steady workloads
4. RDS Proxy evaluation — decide whether proxy is worth it, based on connection utilization and pinning risks
5. Blue/Green deployments — plan low-downtime DDL or major upgrades, with DDL compatibility analysis

Produces cost estimates, precheck findings, and CLI commands. For instance creation, executes the create-db-instance call with production best practices. For upgrades, purchases, and switchovers — advisory only, never executes without explicit user confirmation.

Scoped to RDS open-source engines. For Aurora, use amazon-aurora. For Oracle, SQL Server, Db2, use the engine-specific skills.

The AWS MCP server is recommended for executing commands but is not required; all operations can also be performed via the AWS CLI.

Decision Guide

Broad request ("help me with RDS")? Present the five options as one line each. If the user supplied an instance ID, offer a general health check (engine + version + connection utilization) as entry point.

Out-of-scope (Aurora, Oracle, SQL Server, Db2, backup policy, Performance Insights deep-dive analysis): answer from general knowledge, note this skill doesn't cover it, point to the right engine-specific skill.

RDS vs Aurora — Do Not Confuse

RDS open-source engines and Aurora are different products with different semantics. You MUST NOT apply Aurora concepts to RDS:

If a user asks about any Aurora-specific concept, route to amazon-aurora. If an instance turns out to be Aurora (engine = aurora-mysql or aurora-postgresql), stop and redirect.

Production Instance Creation

When a user asks to create or provision a new RDS MySQL, MariaDB, or PostgreSQL instance for production use, you MUST apply the following best practices by default:

1. Use the latest stable major version — run aws rds describe-db-engine-versions --engine <engine> --query "DBEngineVersions[].EngineVersion" to find the latest. For MySQL, prefer 8.4.x over 8.0 (8.0 has an earlier end-of-standard-support date than 8.4 — see RDS Extended Support for dates). For PostgreSQL, use the latest major. For MariaDB, use the latest major.
2. Enable Multi-AZ — set --multi-az for automatic failover.
3. Enable storage encryption using a customer-managed KMS key — set --storage-encrypted --kms-key-id <key-arn>. A customer-managed key gives full control over key rotation, access policies, and cross-account sharing.
4. Disable public access — set --no-publicly-accessible to ensure the instance is not accessible from the internet.
5. Set backup retention to 7 days — set --backup-retention-period 7.
6. Enable Performance Insights with 7-day retention — set --enable-performance-insights --performance-insights-retention-period 7. If Performance Insights captures queries containing sensitive data (e.g., literal values in WHERE clauses), specify --performance-insights-kms-key-id <key-arn> to encrypt at rest with a customer-managed KMS key.
7. Enable deletion protection — set --deletion-protection.
8. Avoid default master usernames — do NOT use well-known names like admin, root, postgres, or master, which make credential-guessing attacks easier. Choose a custom --master-username (e.g., an application- or team-specific name).
9. Manage master password via Secrets Manager — set --manage-master-user-password instead of providing a plaintext --master-user-password. This creates and rotates the password automatically in Secrets Manager. Do NOT accept or use a plaintext password for production instances.
10. Use gp3 storage — set --storage-type gp3. It's cheaper and faster than gp2 with no minimum IOPS purchase.
11. Tag the instance so customers can identify resources created via this skill — set --tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value={your-model-id} (see Resource tagging below).
12. Enforce TLS for connections in transit — create or modify the DB parameter group to require encrypted connections: require_secure_transport=ON for MySQL/MariaDB, rds.force_ssl=1 for PostgreSQL.
13. Export database logs to CloudWatch Logs and encrypt with KMS — set --enable-cloudwatch-logs-exports so database-level security events (failed logins, suspicious queries) are centrally visible. Use ["error","slowquery","audit"] for MySQL/MariaDB (note: the audit stream requires audit logging to be enabled first, otherwise it is empty — on RDS MySQL via the MARIADB_AUDIT_PLUGIN in an Option Group, on RDS MariaDB via the built-in server audit parameters such as server_audit_logging=1 in a parameter group) and ["postgresql"] for PostgreSQL. Database logs can contain SQL with literal values and usernames, so you MUST configure a KMS key on the resulting /aws/rds/instance/<name>/* log groups to protect sensitive data at rest.

Example CLI (MySQL 8.4, production-ready):

aws rds create-db-instance \
  --db-instance-identifier <name> \
  --engine mysql \
  --engine-version 8.4 \
  --db-instance-class <class> \
  --allocated-storage 100 \
  --storage-type gp3 \
  --storage-encrypted \
  --kms-key-id <kms-key-arn> \
  --no-publicly-accessible \
  --multi-az \
  --manage-master-user-password \
  --master-username <custom-non-default-username> \
  --backup-retention-period 7 \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --performance-insights-kms-key-id <kms-key-arn> \
  --deletion-protection \
  --enable-cloudwatch-logs-exports '["error","slowquery","audit"]' \
  --tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value=<your-model-id> \
  --region us-east-1