rds-oss
Advises on Amazon RDS open-source engines (MySQL, MariaDB, PostgreSQL) for instance creation, upgrade planning, commitment pricing, proxy evaluation, and Blue/Green deployments. Handles any RDS MySQL, MariaDB, or PostgreSQL question, including create a production-ready RDS MySQL instance, provision
By aws · 3,432 installs
npx skills add aws/agent-toolkit-for-aws --skill rds-oss
Source repository · Upstream listing
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
User asks about… Go to
Create, provision, or set up a new RDS MySQL/MariaDB/PostgreSQL instance [Production Instance Creation]( production instance creation) below
Upgrade, target version, pre/post upgrade checklist, upgrade prechecks, Read Replica upgrade order [references/upgrade workflow.md](references/upgrade workflow.md)
Reserved Instance, RI, Database Savings Plan, DSP, 1yr vs 3yr, Multi AZ commitment, No/Partial/All Upfront [references/commitment pricing workflow.md](references/commitment pricing workflow.md)
RDS Proxy, connection pooling, too many connections, Lambda DB connections, proxy pinning, PgBouncer vs Proxy [references/proxy advisor workflow.md](references/proxy advisor workflow.md)
Blue/Green, zero downtime DDL, switchover, schema change with minimal downtime, type change on production [references/bluegreen advisor workflow.md](references/bluegreen advisor workflow.md)
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:
Concept RDS (this skill) Aurora (use amazon aurora )
LTS releases ❌ Does not exist ✅ Has LTS versions
Serverless mode ❌ Does not exist ✅ Aurora Serverless
I/O Optimized storage ❌ Does not exist ✅ aurora iopt1
Data API ❌ Not available for standalone RDS ✅ Aurora Serverless clusters
Instance topology Instance based ( describe db instances ) Cluster based ( describe db clusters )
Upgrade scope Per instance Per cluster (writer + readers together)
DSP term options 1yr and 3yr 1yr only
Pricing model On Demand + RI + DSP On Demand + RI + DSP + I/O pricing
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](https://aws.amazon.com/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):
After instance creation, run the following commands to configure TLS enforcement and log group encryption (these are user executed steps that the skill presents but does not invoke directly):
Constraints:
You MUST use manage master user password for production. NEVER use master user password with a plaintext password for production instances.
You MUST check the latest available engine version via describe db engine versions rather than hardcoding a version.
You MUST enable Multi AZ, encryption, Performance Insights (7 day), backup retention (7 days), and deletion protection unless the user explicitly says otherwise.
If the user says "production" or "production ready", apply ALL of the above without asking.
Resource tagging (always apply on resource creation)
When creating any RDS instance ( create db instance ), ALWAYS include these tags using the RDS list of records tags syntax:
tags Key=created by,Value=rds oss skill Key=generation model,Value={your model id}
Example: tags Key=created by,Value=rds oss skill Key=generation model,Value=claude sonnet 4 20250514
Include these tags even if the user does not mention tagging, so that they can identify the resources created via this skill. If the user provides additional tags, append these to their tags rather than replacing them. The same applies when tagging via add tags to resource or during blue/green deployments.
Common Tasks
1. Verify Dependencies
See [references/verify dependencies.md](references/verify dependencies.md) for tool and credential requirements before running workflows.
2. Classify and Route
Use the [Decision Guide]( decision guide) to choose a workflow reference, the catalog presentation (broad requests), or a general knowledge answer (out of scope).
Constraints:
You MUST name the workflow you're routing to
You MUST pass along instance ID, region, engine, or workload details the user already supplied — do not re ask
You MAY ask one clarifying question if a request straddles two workflows (e.g., "upgrade with minimal downtime" = upgrade + Blue/Green)
You MUST NOT route Aurora, Oracle, SQL Server, or Db2 questions here — those engines have different tooling
3. Execute the Workflow
Load the matching reference and follow its Tasks section.
Constraints:
You MUST explain what step is executing and which tool is being called before running it
You MUST NOT execute modify , switchover , purchase APIs, or create db proxy . Allowed: create db instance (for new instance provisioning), describe , list , get , send command for SSM prechecks.
You MUST NOT handle DB credentials directly. Use user supplied secret ARNs, pre configured SSM parameters, or ask the user to paste script output.
When a live call or bundled script cannot run, You MUST report the exact blocker and either execute the offline fallback or ask the user for inputs. You MUST NOT fabricate command output, analyzer results, pricing numbers, or version lists — a plausible looking answer with no factual basis is worse than refusing, because users act on it.
If multiple workflows ran, close with a 2–4 line synthesis linking to prior outputs.
Each workflow reference includes its own tool call examples.
Critical Facts to Always Surface
These RDS OSS specific facts are what distinguish this skill from vanilla MySQL/PostgreSQL/MariaDB knowledge. General answers typically conflate RDS with Aurora, omit the CLI command names, or stray into action taking when this is an advisory skill.
For "run the RDS upgrade advisor for my RDS MySQL instance", you MUST tell the user ALL of the following five facts:
1. Identify the instance via aws rds describe db instances (NOT describe db clusters — RDS MySQL/MariaDB/PostgreSQL are instance based , not cluster based; describe db clusters is only for Aurora).
2. Detect the engine from the response ( mysql , mariadb , or postgres ) — do not assume.
3. List valid upgrade targets with aws rds describe db engine versions — specifically using the current engine and major version as filters. This is how you enumerate the allowed upgrade paths.
4. Present the latest version recommendation explicitly (e.g., "8.0.40 is the latest 8.0 minor, 8.4.x is the next major").
5. Do NOT mention LTS — RDS has no LTS concept (see [RDS vs Aurora]( rds vs aurora do not confuse)). Offering LTS advice indicates routing confusion between RDS and Aurora. Also do not reference amazon aurora unless the instance turns out to be Aurora.
Critical workflow rule — when the named instance cannot be located: if describe db instances db instance identifier <id returns no results or a DBInstanceNotFoundFault , you MUST still walk through the full advisor workflow for the user — name each step ( describe db instances , then engine detection, then describe db engine versions , then version recommendation, then pre upgrade checklist) — and explain what the output would look lik