rds-oss

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

RDS OSS Advisor (MySQL, MariaDB, PostgreSQL)

RDS开源引擎顾问（MySQL、MariaDB、PostgreSQL）

Overview

概述

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

Instance creation — provision production-ready instances with best-practice defaults (latest version, Multi-AZ, encryption, Performance Insights, Secrets Manager password management)
Upgrade planning — identify instance, enumerate targets, run live prechecks, flag plan regressions, surface pre/post checklists
Commitment pricing — estimate RI and Database Savings Plan savings for steady workloads
RDS Proxy evaluation — decide whether proxy is worth it, based on connection utilization and pinning risks
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.

针对Amazon RDS开源引擎——MySQL、MariaDB和PostgreSQL的顾问工具。涵盖五大决策领域：

实例创建——使用最佳实践默认配置（最新版本、多可用区、加密、性能洞察、Secrets Manager密码管理）配置生产可用的实例
升级规划——识别实例、列举目标版本、运行实时预检查、标记规划中的回退风险、提供升级前后检查清单
承诺定价——估算稳定工作负载下预留实例（RI）和数据库储蓄计划（DSP）的成本节省
RDS Proxy评估——根据连接利用率和连接固定风险判断是否值得使用代理
蓝绿部署——规划低停机时间的DDL操作或重大版本升级，包含DDL兼容性分析

可生成成本估算、预检查结果和CLI命令。对于实例创建，会按照生产最佳实践执行create-db-instance调用。对于升级、购买和切换操作——仅提供建议，未经用户明确确认绝不执行。

仅适用于RDS开源引擎。若涉及Aurora，请使用

amazon-aurora

工具；若涉及Oracle、SQL Server、Db2，请使用对应引擎的专属工具。

建议使用AWS MCP服务器执行命令，但并非必需；所有操作也可通过AWS CLI完成。

Decision Guide

决策指南

User asks about…	Go to
Create, provision, or set up a new RDS MySQL/MariaDB/PostgreSQL instance	Production Instance Creation below
Upgrade, target version, pre/post-upgrade checklist, upgrade prechecks, Read Replica upgrade order	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
RDS Proxy, connection pooling, too many connections, Lambda DB connections, proxy pinning, PgBouncer vs Proxy	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

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 MySQL/MariaDB/PostgreSQL实例	下方的生产实例创建
升级、目标版本、升级前后检查清单、升级预检查、只读副本升级顺序	references/upgrade-workflow.md
预留实例（RI）、数据库储蓄计划（DSP）、1年期vs3年期、多可用区承诺、无预付/部分预付/全额预付	references/commitment-pricing-workflow.md
RDS Proxy、连接池、连接数过多、Lambda数据库连接、代理连接固定、PgBouncer与Proxy对比	references/proxy-advisor-workflow.md
蓝绿部署、零停机DDL、切换、最小停机时间的Schema变更、生产环境中的类型变更	references/bluegreen-advisor-workflow.md

若用户提出宽泛请求（如“帮我处理RDS相关问题”）？将五大选项以单行形式呈现。若用户提供了实例ID，可提供通用健康检查（引擎+版本+连接利用率）作为切入点。

超出范围的内容（Aurora、Oracle、SQL Server、Db2、备份策略、性能洞察深度分析）：基于通用知识作答，说明本工具不涵盖该内容，并指向对应引擎的专属工具。

RDS vs Aurora — Do Not Confuse

RDS与Aurora——请勿混淆

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

aurora-postgresql

), stop and redirect.

RDS开源引擎与Aurora是不同产品，具有不同的语义。绝不能将Aurora的概念应用于RDS：

概念	RDS（本工具）	Aurora（使用 `amazon-aurora` ）
LTS版本	❌ 不存在	✅ 提供LTS版本
无服务器模式	❌ 不存在	✅ Aurora Serverless
I/O优化存储	❌ 不存在	✅ aurora-iopt1
数据API	❌ 独立RDS不支持	✅ Aurora Serverless集群支持
实例拓扑	基于实例（ `describe-db-instances` ）	基于集群（ `describe-db-clusters` ）
升级范围	按实例升级	按集群升级（写入节点+只读节点一同升级）
DSP期限选项	1年期和3年期	仅1年期
定价模型	按需付费+RI+DSP	按需付费+RI+DSP+I/O定价

若用户询问任何Aurora专属概念，引导至

amazon-aurora

。若实例为Aurora（引擎为

aurora-mysql

或

aurora-postgresql

），立即停止并转向对应工具。

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:

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.
Enable Multi-AZ — set
```
--multi-az
```
for automatic failover.
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.
Disable public access — set
```
--no-publicly-accessible
```
to ensure the instance is not accessible from the internet.
Set backup retention to 7 days — set
```
--backup-retention-period 7
```
.
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.
Enable deletion protection — set
```
--deletion-protection
```
.
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).
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.
Use gp3 storage — set
```
--storage-type gp3
```
. It's cheaper and faster than gp2 with no minimum IOPS purchase.
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).
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.
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):

bash

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

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):

bash

undefined

当用户要求创建或配置用于生产环境的RDS MySQL、MariaDB或PostgreSQL实例时，默认必须遵循以下最佳实践：

使用最新稳定主版本——运行
```
aws rds describe-db-engine-versions --engine <engine> --query "DBEngineVersions[].EngineVersion"
```
查找最新版本。对于MySQL，优先选择8.4.x而非8.0（8.0的标准支持结束日期早于8.4——详见RDS扩展支持的日期）。对于PostgreSQL，使用最新主版本。对于MariaDB，使用最新主版本。
启用多可用区——设置
```
--multi-az
```
以实现自动故障转移。
使用客户管理的KMS密钥启用存储加密——设置
```
--storage-encrypted --kms-key-id <key-arn>
```
。客户管理密钥可让您完全控制密钥轮换、访问策略和跨账户共享。
禁用公网访问——设置
```
--no-publicly-accessible
```
确保实例无法从互联网访问。
设置备份保留期为7天——设置
```
--backup-retention-period 7
```
。
启用性能洞察并保留7天数据——设置
```
--enable-performance-insights --performance-insights-retention-period 7
```
。如果性能洞察捕获的查询包含敏感数据（如WHERE子句中的字面量值），请指定
```
--performance-insights-kms-key-id <key-arn>
```
，使用客户管理的KMS密钥对静态数据进行加密。
启用删除保护——设置
```
--deletion-protection
```
。
避免使用默认主用户名——请勿使用
```
admin
```
、
```
root
```
、
```
postgres
```
或
```
master
```
等知名名称，这些名称会增加凭证猜测攻击的风险。选择自定义的
```
--master-username
```
（例如与应用或团队相关的名称）。
通过Secrets Manager管理主密码——设置
```
--manage-master-user-password
```
而非提供明文的
```
--master-user-password
```
。这会在Secrets Manager中自动创建并轮换密码。生产实例绝不接受或使用明文密码。
使用gp3存储——设置
```
--storage-type gp3
```
。它比gp2更便宜、更快，且无最小IOPS购买要求。
为实例添加标签，方便用户识别通过本工具创建的资源——设置
```
--tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value={your-model-id}
```
（详见下方资源标签）。
强制连接使用TLS加密——创建或修改数据库参数组以要求加密连接：MySQL/MariaDB设置
```
require_secure_transport=ON
```
，PostgreSQL设置
```
rds.force_ssl=1
```
。
将数据库日志导出到CloudWatch Logs并使用KMS加密——设置
```
--enable-cloudwatch-logs-exports
```
，使数据库级安全事件（登录失败、可疑查询）可集中查看。MySQL/MariaDB使用
```
["error","slowquery","audit"]
```
（注意：
```
audit
```
流需要先启用审计日志，否则为空——RDS MySQL通过选项组中的MARIADB_AUDIT_PLUGIN启用，RDS MariaDB通过参数组中的内置服务器审计参数如
```
server_audit_logging=1
```
启用），PostgreSQL使用
```
["postgresql"]
```
。数据库日志可能包含带有字面量值和用户名的SQL，因此必须为生成的
```
/aws/rds/instance/<name>/*
```
日志组配置KMS密钥，以保护静态敏感数据。

示例CLI命令（MySQL 8.4，生产可用）：

bash

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

实例创建完成后，运行以下命令配置TLS强制加密和日志组加密（这些是用户执行的步骤，本工具仅提供指导，不会直接调用）：

bash

undefined

Create a custom parameter group with TLS enforcement (MySQL example)

创建启用TLS强制加密的自定义参数组（MySQL示例）

aws rds create-db-parameter-group --db-parameter-group-family mysql8.4
--db-parameter-group-name <name>-tls --description "TLS enforced" aws rds modify-db-parameter-group --db-parameter-group-name <name>-tls
--parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=pending-reboot" aws rds modify-db-instance --db-instance-identifier <name>
--db-parameter-group-name <name>-tls --apply-immediately

aws rds create-db-parameter-group --db-parameter-group-family mysql8.4
--db-parameter-group-name <name>-tls --description "强制启用TLS" aws rds modify-db-parameter-group --db-parameter-group-name <name>-tls
--parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=pending-reboot" aws rds modify-db-instance --db-instance-identifier <name>
--db-parameter-group-name <name>-tls --apply-immediately

Encrypt CloudWatch Logs log groups with KMS

使用KMS加密CloudWatch Logs日志组

aws logs associate-kms-key --log-group-name /aws/rds/instance/<name>/error --kms-key-id <kms-key-arn> aws logs associate-kms-key --log-group-name /aws/rds/instance/<name>/slowquery --kms-key-id <kms-key-arn>


**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.


**约束条件：**

- 生产环境必须使用`--manage-master-user-password`。绝不为生产实例使用带有明文密码的`--master-user-password`。
- 必须通过`describe-db-engine-versions`检查最新可用引擎版本，而非硬编码版本号。
- 必须启用多可用区、加密、性能洞察（7天保留期）、备份保留（7天）和删除保护，除非用户明确说明不需要。
- 如果用户提到“生产”或“生产可用”，无需询问直接应用上述所有配置。

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.

创建任何RDS实例（

create-db-instance

）时，必须使用RDS的记录列表格式

--tags

添加以下标签：

--tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value={your-model-id}

示例：

--tags Key=created_by,Value=rds-oss-skill Key=generation_model,Value=claude-sonnet-4-20250514

即使用户未提及标签，也要添加这些标签，方便用户识别通过本工具创建的资源。如果用户提供了额外标签，将这些标签追加到用户的标签后，而非替换。在通过

add-tags-to-resource

添加标签或蓝绿部署时，同样遵循此规则。

Common Tasks

常见任务

1. Verify Dependencies

1. 验证依赖项

See references/verify-dependencies.md for tool and credential requirements before running workflows.

运行工作流前的工具和凭证要求，请参见references/verify-dependencies.md。

2. Classify and Route

2. 分类与路由

Use the 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

使用决策指南选择工作流参考文档、目录展示（宽泛请求）或通用知识解答（超出范围内容）。

约束条件：

必须说明要路由到的工作流名称
必须传递用户已提供的实例ID、区域、引擎或工作负载详情——不得重复询问
如果请求同时涉及两个工作流（如“以最小停机时间升级”=升级+蓝绿部署），可提出一个澄清问题
不得将Aurora、Oracle、SQL Server或Db2相关问题路由至此——这些引擎有不同的工具

3. Execute the Workflow

3. 执行工作流

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.

加载匹配的参考文档并遵循其

## Tasks

部分。

约束条件：

执行步骤前必须说明正在执行的步骤和调用的工具
不得执行
```
modify-*
```
、
```
switchover-*
```
、购买API或
```
create-db-proxy
```
。允许执行的操作：
```
create-db-instance
```
（用于新实例配置）、
```
describe-*
```
、
```
list-*
```
、
```
get-*
```
、用于SSM预检查的
```
send-command
```
。
不得直接处理数据库凭证。使用用户提供的密钥ARN、预配置的SSM参数，或要求用户粘贴脚本输出。
当无法运行实时调用或捆绑脚本时，必须报告确切的阻塞问题，要么执行离线回退方案，要么向用户请求输入。不得编造命令输出、分析结果、定价数字或版本列表——看似合理但不符合事实的答案比拒绝回答更糟，因为用户会据此采取行动。
如果运行了多个工作流，最后用2-4行内容总结并关联之前的输出。

每个工作流参考文档都包含各自的工具调用示例。

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:

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).
Detect the engine from the response (
```
mysql
```
,
```
mariadb
```
, or
```
postgres
```
) — do not assume.
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.
Present the latest version recommendation explicitly (e.g., "8.0.40 is the latest 8.0 minor, 8.4.x is the next major").
Do NOT mention LTS — RDS has no LTS concept (see RDS vs Aurora). 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 like at each step. DO NOT bail out asking "could you double-check the instance ID?" and stop. The user is asking for the advisor procedure, not for you to perform live discovery. If you cannot see the instance, present the workflow as a template the user can run once the correct identifier is supplied.

For "upgrade my RDS MariaDB from X to the latest version", you MUST tell the user ALL of the following six facts:

Detect engine as
mariadb
via describe-db-instances.
Use
describe-db-engine-versions
(with
```
--engine mariadb
```
) to identify target versions, not a hand-maintained list.
Offer SSM or direct-connection precheck methods — RDS MariaDB can be prechecked via SSM Run Command on a client host or via direct mysql-client connection.
DO NOT use RDS Data API — MariaDB does not support the Data API. This is the classic trap. Data API is only for Aurora Serverless and a subset of clusters, never MariaDB on RDS.
Run MySQL-compatible precheck queries from upgrade-prechecks-mysql.md — removed features, reserved keywords,
```
sql_mode
```
changes. MariaDB reuses the MySQL precheck set because it's a MySQL fork.
Decline to execute the upgrade — advisor only. Recommend a snapshot-and-restore dry-run in a test environment before proceeding. Explicitly say you will not run
```
modify-db-instance --engine-version
```
.

For "2x db.r7g.2xlarge RDS MySQL 24/7 — buy RI or Savings Plan?", you MUST tell the user ALL of the following seven facts:

Run rds_commitment_pricing_analyzer.py offline with
```
--instance-type db.r7g.2xlarge --engine mysql --num-instances 2
```
. Print the exact command as a fenced bash block.
Present a full comparison table of all five options — On-Demand, 1yr RI, 3yr RI, 1yr DSP, 3yr DSP — with savings vs on-demand in both dollars and percentage for each.
Recommend 3yr RI given the stated 2+-year confidence and 24/7 usage.
Explain that RDS Database Savings Plan covers the r7g family specifically — DSP coverage is family-scoped, not instance-scoped, which is a key advantage if the user might resize within the family.
Mention the 3yr lock-in tradeoff — if workload changes or the family gets superseded, the commitment is not recoverable in full.
Note that RDS RIs are region-locked — moving the workload cross-region would forfeit the RI benefit.
DO NOT include purchase action steps — no "Next Steps" section with purchase directions. No "go to Console → Reserved Instances → Purchase". No
```
aws rds purchase-reserved-db-instances-offering
```
or
```
aws savingsplans create-savings-plan
```
commands. This is a hard ban. This skill is advisory-only and MUST NOT guide users toward executing purchases. Say "When you're ready to purchase, refer to the AWS console or CLI docs." and stop there. Do NOT try to be helpful by showing what the purchase command would look like "for reference."

For "change a VARCHAR(10) column to INT on RDS MySQL 8.0 via Blue/Green", you MUST tell the user ALL of the following seven facts:

Validate prerequisites first:
```
binlog_format=ROW
```
, automated backups enabled (retention > 0), instance in
```
available
```
state.
Explain why MODIFY COLUMN changing type breaks binlog replication: Blue/Green replicates the blue → green by replaying binlog events. A type change produces a different binary representation on the two sides, so replication events recorded against VARCHAR can't be applied to an INT column. This is the root cause, not a "row format" issue.
Create the green environment with
aws rds create-blue-green-deployment
— include the exact CLI command name, not a generic description.
Let green catch up via binlog replication before the DDL.
Apply the schema change on green (the MODIFY COLUMN DDL) once green has caught up.
Switch over immediately with
```
aws rds switchover-blue-green-deployment
```
— do not let green run in parallel with blue after the incompatible DDL. The schema divergence breaks further replication.
Verify the schema change on the production endpoint after switchover and you MUST pause and ask the user for explicit confirmation before presenting the
switchover-blue-green-deployment
command, even as a suggested step. Do NOT list switchover as an automatic next step in a sequential workflow — state that the switchover is a destructive action that transfers production traffic, then ask "Are you ready to switch over? I'll give you the exact CLI command to run when you confirm." Only after the user confirms should you emit the
```
switchover-blue-green-deployment
```
command.

For "we run PgBouncer in transaction mode — would RDS Proxy add anything?", you MUST tell the user ALL of the following six facts:

PgBouncer in transaction mode already does aggressive connection multiplexing — that is the primary value proposition of Proxy. In this scenario the multiplexing benefit is marginal.
What RDS Proxy adds on top: managed infrastructure (no EC2 to operate or patch).
Built-in IAM authentication — RDS Proxy supports IAM auth natively, which PgBouncer does not out of the box.
Automatic failover integrated with RDS events — Proxy reacts to RDS failover events in seconds; PgBouncer needs external health checks and manual reconfiguration.
Secrets Manager integration for credential rotation — Proxy can pull credentials from Secrets Manager and rotate without downtime.
Recommendation: if PgBouncer is working and none of the above four features are specifically desired, stay on PgBouncer. Switch to RDS Proxy only if IAM auth, managed failover, or Secrets-Manager-rotated credentials are specifically needed.

这些RDS开源引擎专属事实是本工具区别于普通MySQL/PostgreSQL/MariaDB知识的核心。通用解答通常会混淆RDS与Aurora，遗漏CLI命令名称，或在本工具仅提供建议的情况下引导用户执行操作。

对于“为我的RDS MySQL实例运行RDS升级顾问”请求，必须告知用户以下全部五个事实：

通过
aws rds describe-db-instances
识别实例（而非
```
describe-db-clusters
```
——RDS MySQL/MariaDB/PostgreSQL是基于实例的，而非基于集群；
```
describe-db-clusters
```
仅适用于Aurora）。
从响应中检测引擎类型（
```
mysql
```
、
```
mariadb
```
或
```
postgres
```
）——不得假设。
使用
aws rds describe-db-engine-versions
列出有效的升级目标——特别要使用当前引擎和主版本作为筛选条件。这是枚举允许升级路径的方法。
明确推荐最新版本（例如：“8.0.40是8.0系列的最新小版本，8.4.x是下一个主版本”）。
不得提及LTS——RDS没有LTS概念（参见RDS与Aurora）。提供LTS建议说明混淆了RDS与Aurora的路由。除非实例确实是Aurora，否则不得引用
```
amazon-aurora
```
。

**关键工作流规则——当指定实例无法找到时：**如果

describe-db-instances --db-instance-identifier <id>

返回无结果或

DBInstanceNotFoundFault

，仍必须为用户完整演示顾问工作流——说明每个步骤（

describe-db-instances

、引擎检测、

describe-db-engine-versions

、版本推荐、升级前检查清单），并解释每个步骤的输出是什么样的。不得仅询问“能否确认实例ID是否正确？”然后停止。用户请求的是顾问流程，而非让您执行实时发现。如果无法找到实例，将工作流作为模板呈现，用户提供正确标识符后即可运行。

对于“将我的RDS MariaDB从X版本升级至最新版本”请求，必须告知用户以下全部六个事实：

通过describe-db-instances检测引擎为
mariadb
。
使用
describe-db-engine-versions
（带
```
--engine mariadb
```
参数）识别目标版本，而非手动维护的列表。
提供SSM或直接连接预检查方法——RDS MariaDB可通过客户端主机上的SSM Run Command或直接mysql-client连接进行预检查。
不得使用RDS Data API——MariaDB不支持Data API。这是典型的陷阱。Data API仅适用于Aurora Serverless和部分集群，绝不适用于RDS上的MariaDB。
运行upgrade-prechecks-mysql.md中的MySQL兼容预检查查询——检查已移除的功能、保留关键字、
```
sql_mode
```
变更。由于MariaDB是MySQL的分支，因此复用MySQL的预检查集。
拒绝执行升级操作——本工具仅提供建议。建议在测试环境中先进行快照恢复的试运行，再执行升级。明确说明不会运行
```
modify-db-instance --engine-version
```
命令。

对于“2台db.r7g.2xlarge规格的RDS MySQL实例，7×24小时运行——购买RI还是储蓄计划？”请求，必须告知用户以下全部七个事实：

**运行rds_commitment_pricing_analyzer.py**离线脚本，参数为
```
--instance-type db.r7g.2xlarge --engine mysql --num-instances 2
```
。将准确命令以bash代码块形式呈现。
呈现所有五个选项的完整对比表——按需付费、1年期RI、3年期RI、1年期DSP、3年期DSP，包含每个选项相对于按需付费的美元金额和百分比成本节省。
鉴于用户明确说明2年以上的使用信心和7×24小时使用场景，推荐3年期RI。
说明RDS数据库储蓄计划专门覆盖r7g系列——DSP的覆盖范围是系列级，而非实例级，如果用户可能在系列内调整实例规格，这是关键优势。
提及3年期锁定的权衡——如果工作负载变化或该系列被替代，承诺的成本无法全额收回。
注意RDS RI是区域锁定的——跨区域迁移工作负载将丧失RI的优惠。
不得包含购买操作步骤——不得有“下一步”部分指导购买方向。不得有“进入控制台→预留实例→购买”的说明。不得提供
```
aws rds purchase-reserved-db-instances-offering
```
或
```
aws savingsplans create-savings-plan
```
命令。这是严格禁令。本工具仅提供建议，不得引导用户执行购买操作。只需说明“准备购买时，请参考AWS控制台或CLI文档”即可停止。不得为了“提供参考”而展示购买命令的示例。

对于“通过蓝绿部署在RDS MySQL 8.0中将VARCHAR(10)列改为INT列”请求，必须告知用户以下全部七个事实：

先验证先决条件：
```
binlog_format=ROW
```
、已启用自动备份（保留期>0）、实例处于
```
available
```
状态。
说明修改列类型为何会破坏二进制日志复制：蓝绿部署通过重放二进制日志事件将蓝色环境复制到绿色环境。类型变更会在两侧产生不同的二进制表示，因此针对VARCHAR记录的复制事件无法应用到INT列。这是根本原因，而非“行格式”问题。
使用
aws rds create-blue-green-deployment
创建绿色环境——包含准确的CLI命令名称，而非通用描述。
等待绿色环境通过二进制日志复制追平蓝色环境后再执行DDL操作。
在绿色环境上应用Schema变更（即MODIFY COLUMN的DDL操作）。
立即使用
aws rds switchover-blue-green-deployment
进行切换——执行不兼容的DDL后，不得让绿色环境与蓝色环境并行运行。Schema差异会破坏后续复制。
切换后在生产端点验证Schema变更，并且在提供
switchover-blue-green-deployment
命令之前，必须暂停并请求用户明确确认，即使是作为建议步骤。不得将切换作为顺序工作流中的自动下一步——说明切换是会转移生产流量的破坏性操作，然后询问“您准备好切换了吗？确认后我会提供准确的CLI命令”。只有用户确认后，才能输出
```
switchover-blue-green-deployment
```
命令。

对于“我们在事务模式下运行PgBouncer——RDS Proxy能带来额外价值吗？”请求，必须告知用户以下全部六个事实：

事务模式下的PgBouncer已实现高效的连接多路复用——这是RDS Proxy的主要价值主张。在此场景下，多路复用的收益微乎其微。
**RDS Proxy额外提供的功能：**托管基础设施（无需运维或修补EC2实例）。
内置IAM身份验证——RDS Proxy原生支持IAM认证，而PgBouncer默认不支持。
与RDS事件集成的自动故障转移——Proxy可在数秒内响应RDS故障转移事件；PgBouncer需要外部健康检查和手动重新配置。
与Secrets Manager集成的凭证轮换——Proxy可从Secrets Manager获取凭证并实现无停机轮换。
**建议：**如果PgBouncer运行正常，且不需要上述四个功能中的任何一个，继续使用PgBouncer。仅当明确需要IAM认证、托管故障转移或Secrets Manager轮换凭证时，才切换到RDS Proxy。

Security Considerations

安全注意事项

Advisory skill — never modifies existing AWS resources. The only write action allowed is

create-db-instance

for new instance provisioning (see Production Instance Creation); everything else is read-only. Never handle credentials directly; prefer short-lived credentials.

Minimum IAM permissions required:

AmazonRDSReadOnlyAccess

CloudWatchReadOnlyAccess

+ scoped

pricing:GetProducts

savingsplans:DescribeSavingsPlansOfferingRates

. For instance creation, also

rds:CreateDBInstance

rds:AddTagsToResource

, plus

logs:CreateLogGroup

if CloudWatch Logs exports are enabled. SSM prechecks also need

ssm:SendCommand

ssm:GetCommandInvocation

on the target bastion.

Apply these security practices in all guidance:

Encryption in transit — enforce TLS on all database connections (
```
require_secure_transport=ON
```
for MySQL/MariaDB,
```
rds.force_ssl=1
```
for PostgreSQL).
IAM database authentication — prefer IAM auth over username/password for application connections where supported, providing short-lived credentials.
Audit logging — recommend enabling database audit logging (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
```
, and the
```
pgaudit
```
extension for PostgreSQL) and CloudTrail for API-level audit.
VPC security — deploy instances in a private subnet. Security groups should restrict inbound access to specific application CIDR ranges or security group references — never
```
0.0.0.0/0
```
.
Credential rotation —
```
--manage-master-user-password
```
provides automatic rotation via Secrets Manager.
Monitoring and alarms — recommend CloudWatch Alarms on security-relevant metrics, such as
```
DatabaseConnections
```
spikes (possible credential compromise) and
```
FreeableMemory
```
drops (possible resource-exhaustion attack).

Do NOT grant write/admin beyond the permissions listed above to work around permission errors. Do NOT store DB passwords in SSM parameters or command text — use Secrets Manager and retrieve the secret inside the command.

本工具仅提供建议——绝不修改现有AWS资源。唯一允许的写入操作是用于新实例配置的

create-db-instance

（参见生产实例创建）；其他所有操作均为只读。不得直接处理凭证；优先使用短期凭证。

所需的最低IAM权限：

AmazonRDSReadOnlyAccess

CloudWatchReadOnlyAccess

+ 受限的

pricing:GetProducts

savingsplans:DescribeSavingsPlansOfferingRates

。对于实例创建，还需要

rds:CreateDBInstance

rds:AddTagsToResource

，如果启用了CloudWatch Logs导出，还需要

logs:CreateLogGroup

。SSM预检查还需要目标堡垒机的

ssm:SendCommand

ssm:GetCommandInvocation

权限。

在所有指导中应用以下安全实践：

传输中加密——强制所有数据库连接使用TLS（MySQL/MariaDB设置
```
require_secure_transport=ON
```
，PostgreSQL设置
```
rds.force_ssl=1
```
）。
IAM数据库认证——在支持的场景下，优先使用IAM认证而非用户名/密码进行应用连接，提供短期凭证。
审计日志——建议启用数据库审计日志（RDS MySQL通过选项组中的MARIADB_AUDIT_PLUGIN启用，RDS MariaDB通过参数组中的内置服务器审计参数如
```
server_audit_logging=1
```
启用，PostgreSQL使用
```
pgaudit
```
扩展），并启用CloudTrail进行API级审计。
VPC安全——将实例部署在私有子网中。安全组应限制入站访问到特定应用CIDR范围或安全组引用——绝不能设置为
```
0.0.0.0/0
```
。
凭证轮换——
```
--manage-master-user-password
```
通过Secrets Manager实现自动轮换。
监控与告警——建议针对安全相关指标设置CloudWatch告警，如
```
DatabaseConnections
```
突增（可能是凭证泄露）和
```
FreeableMemory
```
下降（可能是资源耗尽攻击）。

不得为解决权限问题而授予超出上述范围的写入/管理员权限。不得将数据库密码存储在SSM参数或命令文本中——使用Secrets Manager并在命令内获取密钥。

Troubleshooting

故障排除

Access denied. Attach the read-only policies above.

Expired credentials. Refresh, or fall back to

--offline

for commitment pricing.

Timeouts / throttling. Retry once, then narrow scope. SSM precheck timeouts on large schemas: switch to direct connection or user-runs-script. RDS Data API is not available for standalone RDS.

Resource not found. Verify region/ID; confirm it's not an Aurora cluster (

describe-db-clusters

). Empty RI/DSP offerings — fall back to offline.

User asks to execute a change. Advisory skill — modifications to existing resources happen via the AWS console or user-run CLI.

Aurora question. Route to

amazon-aurora

. See RDS vs Aurora above.

Oracle / SQL Server / Db2 question. Route to

rds-oracle

rds-sqlserver

, or

rds-db2

访问被拒绝：附加上述只读策略。

凭证过期：刷新凭证，或在承诺定价中回退到

--offline

模式。

超时/限流：重试一次，然后缩小范围。大型Schema上的SSM预检查超时：切换到直接连接或用户自行运行脚本。独立RDS不支持RDS Data API。

资源未找到：验证区域/ID；确认不是Aurora集群（使用

describe-db-clusters

检查）。RI/DSP产品为空：回退到离线模式。

用户要求执行变更：本工具仅提供建议——现有资源的修改需通过AWS控制台或用户自行运行CLI命令完成。

Aurora相关问题：引导至

amazon-aurora

。参见上方RDS与Aurora。

Oracle/SQL Server/Db2相关问题：引导至

rds-oracle

、

rds-sqlserver

或

rds-db2

。

rds-oss

Original

Translation

RDS OSS Advisor (MySQL, MariaDB, PostgreSQL)

RDS开源引擎顾问（MySQL、MariaDB、PostgreSQL）

Overview

概述

Decision Guide

决策指南

RDS vs Aurora — Do Not Confuse

RDS与Aurora——请勿混淆

Production Instance Creation

生产实例创建

Create a custom parameter group with TLS enforcement (MySQL example)

创建启用TLS强制加密的自定义参数组（MySQL示例）

Encrypt CloudWatch Logs log groups with KMS

使用KMS加密CloudWatch Logs日志组

Resource tagging (always apply on resource creation)

资源标签（创建资源时始终添加）

Common Tasks

常见任务

1. Verify Dependencies

1. 验证依赖项

2. Classify and Route

2. 分类与路由

3. Execute the Workflow

3. 执行工作流

Critical Facts to Always Surface

必须始终告知的关键事实

Security Considerations

安全注意事项

Troubleshooting

故障排除

Additional Resources

额外资源