aurora-dsql

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Amazon Aurora DSQL

Amazon Aurora DSQL

Overview

概述

Aurora DSQL is a serverless, PostgreSQL-compatible distributed SQL database. This skill provides direct database interaction via
psql
scripts and PostgreSQL drivers, schema management, migration support, multi-tenant patterns, and query-plan explainability.
Key capabilities:
  • Direct query execution via
    psql
    with generated IAM auth tokens (see
    scripts/psql-connect.sh
    )
  • Schema management with DSQL constraints (one DDL per transaction, async indexes)
  • Safe data migration (column-level, constraint-level, MySQL→DSQL)
  • Multi-tenant isolation via
    tenant_id
    + parameterized SQL
  • IAM-based authentication with a 15-minute token expiry
  • Query-plan diagnosis for slow queries (EXPLAIN ANALYZE + GUC experiments)
The recommended runtime is
psql
with
aws dsql generate-db-connect-auth-token
for IAM-authenticated sessions. Application code SHOULD use the language-specific DSQL Connectors and SDKs. For AWS knowledge lookups (service docs, AWS API calls), the AWS MCP Server is the preferred MCP integration.

Aurora DSQL是一款兼容PostgreSQL的无服务器分布式SQL数据库。本技能支持通过
psql
脚本和PostgreSQL驱动直接与数据库交互,提供架构管理、迁移支持、多租户模式以及查询计划可解释性等功能。
核心功能:
  • 通过生成的IAM认证令牌,使用
    psql
    直接执行查询(参见
    scripts/psql-connect.sh
  • 基于DSQL约束的架构管理(每个事务仅执行一条DDL语句,异步索引)
  • 安全数据迁移(列级、约束级、MySQL→DSQL)
  • 通过
    tenant_id
    +参数化SQL实现多租户隔离
  • 基于IAM的认证,令牌有效期为15分钟
  • 慢查询的查询计划诊断(EXPLAIN ANALYZE + GUC实验)
推荐运行时为搭配
aws dsql generate-db-connect-auth-token
psql
,用于IAM认证会话。应用代码应使用语言专属的DSQL Connectors和SDK。如需查询AWS相关知识(服务文档、AWS API调用),首选集成AWS MCP Server

Reference Files

参考文件

Load these files as needed for detailed guidance:
根据需要加载以下文件获取详细指导:

development-guide.md

development-guide.md

When: ALWAYS load before implementing schema changes or database operations Contains: Best Practices, DDL rules, connection patterns, transaction limits, data type serialization patterns, application-layer referential integrity instructions, security best practices
适用场景: 在实施架构变更或数据库操作前必须加载 包含内容: 最佳实践、DDL规则、连接模式、事务限制、数据类型序列化模式、应用层参照完整性说明、安全最佳实践

Query Execution:

查询执行:

database-tools.md

database-tools.md

When: Load when you need detailed syntax and examples for ad-hoc query execution against DSQL. PREFER
psql
(via
scripts/psql-connect.sh
) for ad-hoc queries — execute directly rather than writing one-off scripts. Contains:
psql
-based read-only and write patterns, transaction semantics, input validation
适用场景: 当需要针对DSQL执行临时查询的详细语法和示例时加载。优先使用
psql
(通过
scripts/psql-connect.sh
)执行临时查询——直接执行而非编写一次性脚本。 包含内容: 基于
psql
的只读和写入模式、事务语义、输入验证

MCP (AWS knowledge / API):

MCP(AWS知识/API):

mcp-setup.md

mcp-setup.md

When: Load when configuring or recommending the AWS MCP Server for AWS knowledge lookups, AWS API access, or per-assistant install. Contains: When to use
psql
vs the AWS MCP Server, pointer to the canonical AWS setup docs, credential reminders.
适用场景: 配置或推荐AWS MCP Server用于AWS知识查询、AWS API访问或按助手安装时加载。 包含内容:
psql
与AWS MCP Server的使用场景对比、AWS官方设置文档链接、凭证提醒

mcp-tools.md

mcp-tools.md

When: Load when invoking AWS MCP Server tools to verify DSQL service limits, fetch docs, or drive AWS API calls. Contains: Tool surface — knowledge (
aws___search_documentation
,
aws___read_documentation
,
aws___recommend
,
aws___retrieve_skill
,
aws___list_regions
,
aws___get_regional_availability
) and API (
aws___call_aws
,
aws___run_script
,
aws___get_tasks
,
aws___get_presigned_url
); pointers to documentation-tools.md.
适用场景: 调用AWS MCP Server工具验证DSQL服务限制、获取文档或触发AWS API调用时加载。 包含内容: 工具集——知识类(
aws___search_documentation
aws___read_documentation
aws___recommend
aws___retrieve_skill
aws___list_regions
aws___get_regional_availability
)和API类(
aws___call_aws
aws___run_script
aws___get_tasks
aws___get_presigned_url
);指向documentation-tools.md的链接

documentation-tools.md

documentation-tools.md

When: Load when looking up DSQL service limits, fetching a specific AWS docs page, or polling long-running AWS API calls launched via the AWS MCP Server. Contains: Detailed parameters and example calls for the AWS knowledge tools.
适用场景: 查询DSQL服务限制、获取特定AWS文档页面或轮询通过AWS MCP Server发起的长时间运行AWS API调用时加载。 包含内容: AWS知识工具的详细参数和调用示例

platforms/ — per-assistant install notes

platforms/ — 按助手安装说明

When: Load when installing the AWS MCP Server inside a specific coding assistant. Contains: Per-assistant entry-point details — claude-code.md, codex.md, gemini.md, kiro.md.
适用场景: 在特定编码助手中安装AWS MCP Server时加载。 包含内容: 各助手的入口点详情——claude-code.mdcodex.mdgemini.mdkiro.md

language.md

language.md

When: MUST load before writing DSQL connection code. Mirror the linked
example_preferred.<ext>
for the chosen driver — memory-authored connections drift from the canonical IAM-token-refresh pattern. Canonical entry-point examples (load
language.md
for the full driver list + pool/TLS/token-refresh details):
  • Python:
    import aurora_dsql_psycopg as dsql
    dsql.connect(host, region, user)
  • JS (node-postgres):
    import { AuroraDSQLPool } from "@aws/aurora-dsql-node-postgres-connector"
    new AuroraDSQLPool({ host, user })
  • JS (postgres.js):
    import { auroraDSQLPostgres } from "@aws/aurora-dsql-postgresjs-connector"
    auroraDSQLPostgres({ host, user })
  • Go (pgx):
    import "github.com/awslabs/aurora-dsql-connectors/go/pgx/dsql"
  • Java (JDBC):
    software.amazon.dsql:aurora-dsql-jdbc-connector:1.4.0
    jdbc:aws-dsql:postgresql://...
Contains: Canonical DSQL connector packages per language, driver selection, framework patterns, IAM auth token rotation and TLS configuration, and connection code examples for Python / JavaScript / TypeScript / Go / Java / Rust.
适用场景: 编写DSQL连接代码前必须加载。参照所选驱动对应的
example_preferred.<ext>
示例——手动编写的连接代码会偏离标准IAM令牌刷新模式。标准入口示例(加载
language.md
获取完整驱动列表及连接池/TLS/令牌刷新详情):
  • Python:
    import aurora_dsql_psycopg as dsql
    dsql.connect(host, region, user)
  • JS (node-postgres):
    import { AuroraDSQLPool } from "@aws/aurora-dsql-node-postgres-connector"
    new AuroraDSQLPool({ host, user })
  • JS (postgres.js):
    import { auroraDSQLPostgres } from "@aws/aurora-dsql-postgresjs-connector"
    auroraDSQLPostgres({ host, user })
  • Go (pgx):
    import "github.com/awslabs/aurora-dsql-connectors/go/pgx/dsql"
  • Java (JDBC):
    software.amazon.dsql:aurora-dsql-jdbc-connector:1.4.0
    jdbc:aws-dsql:postgresql://...
包含内容: 各语言对应的标准DSQL连接器包、驱动选择、框架模式、IAM认证令牌轮换和TLS配置,以及Python/JavaScript/TypeScript/Go/Java/Rust的连接代码示例

troubleshooting.md

troubleshooting.md

When: Load when debugging errors or unexpected behavior. SHOULD always consult for OCC errors, connection failures, or unexpected query results. Contains: Common pitfalls, error messages, solutions
适用场景: 调试错误或异常行为时加载。遇到OCC错误、连接失败或异常查询结果时应始终查阅。 包含内容: 常见陷阱、错误信息、解决方案

onboarding.md

onboarding.md

When: User explicitly requests to "Get started with DSQL" or similar phrase Contains: Interactive step-by-step guide for new users
适用场景: 用户明确请求“开始使用DSQL”或类似表述时加载 包含内容: 面向新用户的交互式分步指南

access-control.md

access-control.md

When: MUST load when creating database roles, granting permissions, setting up schemas for applications, or handling sensitive data. ALWAYS use scoped roles for applications — create database roles with
dsql:DbConnect
. Contains: Scoped role setup, IAM-to-database role mapping, schema separation for sensitive data, role design patterns
适用场景: 创建数据库角色、授予权限、为应用设置架构或处理敏感数据时必须加载。始终为应用使用限定范围的角色——创建带有
dsql:DbConnect
权限的数据库角色。 包含内容: 限定范围角色设置、IAM到数据库角色的映射、敏感数据的架构隔离、角色设计模式

Authentication & Operations:

认证与操作:

auth/authentication-guide.md

auth/authentication-guide.md

When: MUST load when handling IAM auth tokens, secrets, SSL/TLS, connection pooling, or audit logging. Contains: Token lifecycle, secret storage patterns, SSL/TLS settings, connection-pool guidance, audit-log integration.
适用场景: 处理IAM认证令牌、密钥、SSL/TLS、连接池或审计日志时必须加载。 包含内容: 令牌生命周期、密钥存储模式、SSL/TLS设置、连接池指南、审计日志集成

auth/connectivity-tools.md

auth/connectivity-tools.md

When: Load when picking a driver/ORM/adapter or planning bulk-data loading. Contains: Pointer to the canonical AWS DSQL connectivity tools page (drivers, ORMs, adapters) and the bulk-loading docs page.
适用场景: 选择驱动/ORM/适配器或规划批量数据加载时加载。 包含内容: 指向AWS官方DSQL连接工具页面(驱动、ORM、适配器)和批量加载文档页面的链接

auth/scaling-guide.md

auth/scaling-guide.md

When: Load when designing for scale — connection pooling, batch optimization, hot-key avoidance, identifier choice. Contains: Horizontal scaling strategy, pool sizing, batch-size guidance, IDENTITY/UUID trade-offs, sequence cache rules.
适用场景: 设计可扩展架构时加载——连接池、批量优化、热键避免、标识符选择。 包含内容: 水平扩展策略、连接池大小、批量大小指南、IDENTITY/UUID权衡、序列缓存规则

Implementation Examples:

实现示例:

workflow-patterns.md

workflow-patterns.md

When: Load when looking for a worked example of a common multi-step DSQL workflow (schema explore, CREATE+INDEX, safe migration, batch insert, application-layer FK check). Contains: Five canonical patterns with
psql
/ driver code.
适用场景: 查找常见多步骤DSQL工作流(架构探索、CREATE+INDEX、安全迁移、批量插入、应用层外键检查)的完整示例时加载。 包含内容: 5种标准模式及对应的
psql
/驱动代码

dsql-examples.md

dsql-examples.md

When: Load when looking for specific implementation examples. Contains: Index of
examples/*.md
(connection, schema, data-operations, migrations, patterns).
适用场景: 查找特定实现示例时加载。 包含内容:
examples/*.md
索引(连接、架构、数据操作、迁移、模式)

DDL Migrations (modular):

DDL迁移(模块化):

ddl-migrations/overview.md

ddl-migrations/overview.md

When: MUST load when performing DROP COLUMN, RENAME COLUMN, ALTER COLUMN TYPE, or DROP CONSTRAINT Contains: Table recreation pattern overview, transaction rules, common verify & swap pattern
适用场景: 执行DROP COLUMN、RENAME COLUMN、ALTER COLUMN TYPE或DROP CONSTRAINT时必须加载 包含内容: 表重建模式概述、事务规则、常见验证与替换模式

ddl-migrations/column-operations.md

ddl-migrations/column-operations.md

When: Load for DROP COLUMN, ALTER COLUMN TYPE, SET/DROP NOT NULL, SET/DROP DEFAULT migrations Contains: Step-by-step migration patterns for column-level changes
适用场景: 进行DROP COLUMN、ALTER COLUMN TYPE、SET/DROP NOT NULL、SET/DROP DEFAULT迁移时加载 包含内容: 列级变更的分步迁移模式

ddl-migrations/constraint-operations.md

ddl-migrations/constraint-operations.md

When: Load for ADD/DROP CONSTRAINT, MODIFY PRIMARY KEY, column split/merge migrations Contains: Step-by-step migration patterns for constraint and structural changes
适用场景: 进行ADD/DROP CONSTRAINT、MODIFY PRIMARY KEY、列拆分/合并迁移时加载 包含内容: 约束和结构变更的分步迁移模式

ddl-migrations/batched-migration.md

ddl-migrations/batched-migration.md

When: Load when migrating tables exceeding 3,000 rows Contains: OFFSET-based and cursor-based batching patterns, progress tracking, error handling
适用场景: 迁移超过3000行的表时加载 包含内容: 基于OFFSET和游标批处理模式、进度跟踪、错误处理

MySQL Migrations (modular):

MySQL迁移(模块化):

mysql-migrations/type-mapping.md

mysql-migrations/type-mapping.md

When: MUST load when migrating MySQL schemas to DSQL Contains: MySQL data type mappings, feature alternatives, DDL operation mapping
适用场景: 将MySQL架构迁移到DSQL时必须加载 包含内容: MySQL数据类型映射、功能替代方案、DDL操作映射

mysql-migrations/ddl-operations.md

mysql-migrations/ddl-operations.md

When: Load when translating MySQL DDL operations to DSQL equivalents Contains: ALTER COLUMN, DROP COLUMN, AUTO_INCREMENT, ENUM, SET, FOREIGN KEY migration patterns
适用场景: 将MySQL DDL操作转换为DSQL等效操作时加载 包含内容: ALTER COLUMN、DROP COLUMN、AUTO_INCREMENT、ENUM、SET、FOREIGN KEY迁移模式

mysql-migrations/full-example.md

mysql-migrations/full-example.md

When: Load when migrating a complete MySQL table to DSQL Contains: End-to-end MySQL CREATE TABLE migration example with decision summary
适用场景: 将完整MySQL表迁移到DSQL时加载 包含内容: 端到端MySQL CREATE TABLE迁移示例及决策总结

Query Plan Explainability (modular):

查询计划可解释性(模块化):

When: MUST load all four at Workflow 8 Phase 0 — query-plan/plan-interpretation.md, query-plan/catalog-queries.md, query-plan/guc-experiments.md, query-plan/report-format.md Contains: DSQL node types + Node Duration math + estimation-error bands, pg_class/pg_stats/pg_indexes SQL + correlated-predicate verification, GUC experiment procedures + 30-second skip protocol, required report structure + element checklist + support request template

适用场景: 在工作流8阶段0必须加载全部四个文件——query-plan/plan-interpretation.mdquery-plan/catalog-queries.mdquery-plan/guc-experiments.mdquery-plan/report-format.md 包含内容: DSQL节点类型+节点时长计算+估计误差范围、pg_class/pg_stats/pg_indexes SQL+关联谓词验证、GUC实验流程+30秒跳过规则、必填报告结构+元素清单+支持请求模板

Query Execution

查询执行

Run ad-hoc DSQL queries with
psql
and a freshly-generated IAM auth token. The bundled
scripts/psql-connect.sh
wraps token generation, TLS configuration, and single-statement guards — PREFER it over hand-rolled
psql
invocations.
Read-only:
bash
./scripts/psql-connect.sh --cluster <cluster-id> --command "SELECT * FROM entities LIMIT 10"
Write/DDL (IAM admin auth token required):
bash
./scripts/psql-connect.sh --cluster <cluster-id> --admin --command "CREATE INDEX ASYNC ..."
Schema discovery: there is no special
list_tables
helper — use information_schema:
sql
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
See database-tools.md for detailed usage and examples.
使用
psql
和新生成的IAM认证令牌执行临时DSQL查询。附带的
scripts/psql-connect.sh
封装了令牌生成、TLS配置和单语句保护——优先使用该脚本而非手动编写
psql
调用。
只读操作:
bash
./scripts/psql-connect.sh --cluster <cluster-id> --command "SELECT * FROM entities LIMIT 10"
写入/DDL操作(需IAM管理员认证令牌):
bash
./scripts/psql-connect.sh --cluster <cluster-id> --admin --command "CREATE INDEX ASYNC ..."
架构发现: 没有专门的
list_tables
工具——使用information_schema:
sql
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
详细用法和示例请参见database-tools.md

AWS Knowledge via the AWS MCP Server (optional)

通过AWS MCP Server获取AWS知识(可选)

When connected to the AWS MCP Server, its
aws___search_documentation
and
aws___read_documentation
tools can verify DSQL service limits before advising users. The numeric limits below are defaults that may change — when a user's decision depends on an exact limit, verify it first:
LimitDefaultVerify query
Max rows mutated per transaction3,000
aurora dsql transaction limits
Max data modified per write transaction10 MiB
aurora dsql transaction limits
Max transaction duration5 minutes
aurora dsql transaction limits
Max connections per cluster10,000
aurora dsql connection limits
IAM auth token expiry15 minutes
aurora dsql authentication token
Max connection duration60 minutes
aurora dsql connection limits
Max indexes per table24
aurora dsql index limits
Max columns per index8
aurora dsql index limits
IDENTITY/SEQUENCE CACHE values1 or >= 65536
aurora dsql sequence cache
When to verify: Before recommending batch sizes, connection pool settings, or schema designs where hitting a limit would cause failures. No need to verify for general guidance or when the exact number doesn't affect the user's decision.
Fallback: If the AWS MCP Server is unavailable, use the defaults above and note to the user that limits should be verified against DSQL documentation.
连接到AWS MCP Server后,其
aws___search_documentation
aws___read_documentation
工具可在为用户提供建议前验证DSQL服务限制。以下是默认数值限制,可能会发生变化——当用户的决策依赖精确限制时,需先验证:
限制项默认值验证查询语句
每个事务可修改的最大行数3,000
aurora dsql transaction limits
每个写入事务可修改的最大数据量10 MiB
aurora dsql transaction limits
最长事务时长5分钟
aurora dsql transaction limits
每个集群的最大连接数10,000
aurora dsql connection limits
IAM认证令牌有效期15分钟
aurora dsql authentication token
最长连接时长60分钟
aurora dsql connection limits
每个表的最大索引数24
aurora dsql index limits
每个索引的最大列数8
aurora dsql index limits
IDENTITY/SEQUENCE缓存值1或≥65536
aurora dsql sequence cache
验证时机: 在推荐批量大小、连接池设置或架构设计之前,如果达到限制会导致失败,则需验证。提供通用指导或精确数值不影响用户决策时,无需验证。
** fallback方案:** 如果AWS MCP Server不可用,使用上述默认值,并告知用户需参照DSQL文档验证限制。

CLI Scripts Available

可用CLI脚本

Bash scripts in scripts/ for cluster management (create, delete, list, cluster info) and
psql
connection. See references/scripts-guide.md for usage. For bulk data loading, see Loading data into Aurora DSQL.
ALWAYS prefer
scripts/create-cluster.sh
. The script issues a single atomic
CreateCluster
call with tags embedded — matching the AWS DSQL API shape with interpretable output.
TaskScriptExample
Create cluster with tags
scripts/create-cluster.sh
./scripts/create-cluster.sh --created-by <model-id> --tags Environment=eval,Project=dsql-skill-eval
List clusters
scripts/list-clusters.sh
./scripts/list-clusters.sh --region us-east-1
Inspect cluster
scripts/cluster-info.sh
./scripts/cluster-info.sh <cluster-id>
Connect via psql
scripts/psql-connect.sh
./scripts/psql-connect.sh --cluster <id> --command "SELECT 1"

scripts/目录下的Bash脚本用于集群管理(创建、删除、列出、集群信息)和
psql
连接。使用方法请参见references/scripts-guide.md。批量数据加载请参见将数据加载到Aurora DSQL
始终优先使用
scripts/create-cluster.sh
。该脚本会发起一个原子性
CreateCluster
调用并嵌入标签——与AWS DSQL API格式匹配,输出易于解读。
任务脚本示例
创建带标签的集群
scripts/create-cluster.sh
./scripts/create-cluster.sh --created-by <model-id> --tags Environment=eval,Project=dsql-skill-eval
列出集群
scripts/list-clusters.sh
./scripts/list-clusters.sh --region us-east-1
查看集群信息
scripts/cluster-info.sh
./scripts/cluster-info.sh <cluster-id>
通过psql连接
scripts/psql-connect.sh
./scripts/psql-connect.sh --cluster <id> --command "SELECT 1"

Quick Start

快速入门

1. List tables and explore schema

1. 列出表并探索架构

./scripts/psql-connect.sh --cluster <id> --command "SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'"
./scripts/psql-connect.sh --cluster <id> --command "SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_schema = 'public' AND table_name = '<table>' ORDER BY ordinal_position"
./scripts/psql-connect.sh --cluster <id> --command "SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'"
./scripts/psql-connect.sh --cluster <id> --command "SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_schema = 'public' AND table_name = '<table>' ORDER BY ordinal_position"

2. Query data

2. 查询数据

Use psql-connect.sh (or the language connector in app code) for SELECT queries
Always include tenant_id in WHERE clause for multi-tenant apps
MUST build SQL with safe_query.build() — see references/input-validation.md
使用psql-connect.sh(或应用代码中的语言连接器)执行SELECT查询
多租户应用必须在WHERE子句中包含tenant_id
必须使用safe_query.build()构建SQL——参见references/input-validation.md

3. Execute schema changes

3. 执行架构变更

Use ./scripts/psql-connect.sh --admin (or the language connector with the IAM admin auth token) for DDL
Follow one-DDL-per-transaction rule
Always use CREATE INDEX ASYNC in a separate statement
ALTER COLUMN TYPE, DROP COLUMN, DROP CONSTRAINT → Table Recreation Pattern (Workflow 6)

使用./scripts/psql-connect.sh --admin(或带IAM管理员认证令牌的语言连接器)执行DDL
遵循每个事务一条DDL的规则
始终在单独语句中使用CREATE INDEX ASYNC
ALTER COLUMN TYPE、DROP COLUMN、DROP CONSTRAINT → 使用表重建模式(工作流6)

Common Tasks

常见任务

Workflow 0: Verify Dependencies

工作流0:验证依赖项

Check for required tools and warn the user if any are missing.
Constraints:
  • You MUST verify the following tools are available before proceeding:
    psql
    (>=14 for SNI support) and the AWS CLI v2 with
    aws dsql generate-db-connect-auth-token
    (and
    generate-db-connect-admin-auth-token
    for DDL/role setup)
  • You SHOULD also confirm the AWS MCP Server is available when the user's decision depends on a precise service limit; if absent, use the defaults in the table above and note that limits should be verified against DSQL documentation
  • You MUST inform the user about any missing tools with a clear message
  • You MUST ask if the user wants to proceed despite missing tools
  • You MUST use the scoped (non-admin) IAM auth token for read-only diagnostics whenever the user has a scoped role configured; reserve the IAM admin auth token for cluster setup, role grants, and DDL
  • For cluster lifecycle (create / inspect / delete), see Workflow 0a
  • Before writing application code, ALSO verify the language-specific DSQL Connector per Workflow 0b
检查所需工具是否可用,若有缺失则向用户发出警告。
约束条件:
  • 必须先验证以下工具是否可用:
    psql
    (版本≥14以支持SNI)、支持
    aws dsql generate-db-connect-auth-token
    (以及用于DDL/角色设置的
    generate-db-connect-admin-auth-token
    )的AWS CLI v2
  • 当用户的决策依赖精确服务限制时,还应确认AWS MCP Server是否可用;若不可用,使用上表中的默认值,并告知用户需参照DSQL文档验证限制
  • 必须清晰告知用户任何缺失的工具
  • 必须询问用户是否要在工具缺失的情况下继续操作
  • 当用户配置了限定范围的角色时,必须使用限定范围(非管理员)的IAM认证令牌进行只读诊断;仅在集群设置、角色授权和DDL操作时使用IAM管理员认证令牌
  • 集群生命周期(创建/查看/删除)请参见工作流0a
  • 编写应用代码前,还需根据工作流0b验证语言专属DSQL连接器

Workflow 0a: Cluster Lifecycle

工作流0a:集群生命周期

SHOULD use the bundled scripts for cluster create and delete — they issue atomic
aws dsql
CLI calls and process outputs.
Create a cluster with tags and deletion protection:
bash
./scripts/create-cluster.sh --created-by <model-id> --tags Environment=eval,Project=dsql-skill-eval
Inspect a cluster (status, tags, endpoint, deletion protection):
bash
./scripts/cluster-info.sh <cluster-id>
Delete a cluster:
bash
./scripts/delete-cluster.sh <cluster-id> [--force]   # --force skips the confirmation prompt in non-TTY
In MCP-only environments (no shell access), the equivalent calls go through the AWS MCP Server's
aws___call_aws
tool. The tool takes a JSON payload — invoke it with arguments matching the AWS API operation:
json
{"service": "dsql", "operation": "CreateCluster",
 "parameters": {"tags": {"created_by": "<model-id>", "Environment": "eval", "Project": "dsql-skill-eval"}, "deletionProtectionEnabled": true}}
json
{"service": "dsql", "operation": "GetCluster", "parameters": {"identifier": "<cluster-id>"}}
json
{"service": "dsql", "operation": "DeleteCluster", "parameters": {"identifier": "<cluster-id>"}}
CreateCluster
and
DeleteCluster
are asynchronous on the DSQL side — the API returns immediately with the cluster's current
status
(
CREATING
/
DELETING
). Poll readiness by re-invoking
aws___call_aws
with
dsql:GetCluster
until
.status == "ACTIVE"
(create) or the call returns a 404 (delete).
aws___get_tasks
is for polling MCP-side long-running tool invocations — not the DSQL API.
See AWS CLI
aws dsql
reference
for full parameter details and call context.
使用附带脚本创建和删除集群——这些脚本会发起原子性
aws dsql
CLI调用并处理输出。
创建带标签和删除保护的集群:
bash
./scripts/create-cluster.sh --created-by <model-id> --tags Environment=eval,Project=dsql-skill-eval
查看集群信息(状态、标签、端点、删除保护):
bash
./scripts/cluster-info.sh <cluster-id>
删除集群:
bash
./scripts/delete-cluster.sh <cluster-id> [--force]   # --force在非TTY环境下跳过确认提示
在仅支持MCP的环境(无shell访问权限)中,等效调用需通过AWS MCP Server的
aws___call_aws
工具完成。该工具接受JSON负载——使用与AWS API操作匹配的参数调用:
json
{"service": "dsql", "operation": "CreateCluster",
 "parameters": {"tags": {"created_by": "<model-id>", "Environment": "eval", "Project": "dsql-skill-eval"}, "deletionProtectionEnabled": true}}
json
{"service": "dsql", "operation": "GetCluster", "parameters": {"identifier": "<cluster-id>"}}
json
{"service": "dsql", "operation": "DeleteCluster", "parameters": {"identifier": "<cluster-id>"}}
CreateCluster
DeleteCluster
在DSQL端是异步操作——API会立即返回集群当前的
status
CREATING
/
DELETING
)。通过重新调用
aws___call_aws
并传入
dsql:GetCluster
,轮询直至
.status == "ACTIVE"
(创建)或调用返回404(删除)。
aws___get_tasks
用于轮询MCP端长时间运行的工具调用——而非DSQL API。
完整参数详情和调用上下文请参见AWS CLI
aws dsql
参考文档

Workflow 0b: Verify Language Connector

工作流0b:验证语言连接器

Before writing application code, MUST verify the language-specific DSQL Connector is installed per language.md. The Connectors are the canonical IAM-token-refresh path; bare drivers (
pg
,
psycopg
,
pgx
,
tokio-postgres
) work until the first 15-minute token expiry and then start returning auth errors on every new connection — DSQL users who try the bare form report this as a DSQL bug. MUST install:
  • Python:
    aurora-dsql-python-connector
    + the chosen driver wheel
  • Node.js:
    @aws/aurora-dsql-node-postgres-connector
    or
    @aws/aurora-dsql-postgresjs-connector
  • Go:
    github.com/awslabs/aurora-dsql-connectors/go/pgx
  • Java:
    software.amazon.dsql:aurora-dsql-jdbc-connector
  • Rust:
    aurora-dsql-sqlx-connector
If a Connector is unavailable for the chosen runtime, document the manual token-refresh strategy and schedule with the user before writing code.

编写应用代码前,必须根据language.md验证语言专属DSQL连接器是否已安装。连接器是标准IAM令牌刷新路径;裸驱动(
pg
psycopg
pgx
tokio-postgres
)在第一个15分钟令牌过期后会开始在每次新连接时返回认证错误——使用裸驱动的DSQL用户会将此视为DSQL漏洞。必须安装:
  • Python:
    aurora-dsql-python-connector
    + 所选驱动包
  • Node.js:
    @aws/aurora-dsql-node-postgres-connector
    @aws/aurora-dsql-postgresjs-connector
  • Go:
    github.com/awslabs/aurora-dsql-connectors/go/pgx
  • Java:
    software.amazon.dsql:aurora-dsql-jdbc-connector
  • Rust:
    aurora-dsql-sqlx-connector
如果所选运行时没有可用的连接器,需在编写代码前向用户说明手动令牌刷新策略和计划。

Workflow 1: Create Multi-Tenant Schema

工作流1:创建多租户架构

MUST load workflow-patterns.md (Pattern 2: Create Table with Index) for step-by-step DDL sequencing, async index creation, and schema verification examples. Key rules:
tenant_id
in all tables,
CREATE INDEX ASYNC
only, one DDL per transaction, arrays/JSON stored as TEXT.
必须加载workflow-patterns.md(模式2:创建带索引的表)获取分步DDL排序、异步索引创建和架构验证示例。核心规则:所有表包含
tenant_id
、仅使用
CREATE INDEX ASYNC
、每个事务一条DDL、数组/JSON存储为TEXT类型。

Workflow 2: Safe Data Migration

工作流2:安全数据迁移

MUST load workflow-patterns.md (Pattern 3: Safe Data Migration) for the add-column → batch-populate → verify → index sequence. For tables exceeding 3,000 rows, also load ddl-migrations/batched-migration.md. Key rules: add column first, apply DEFAULT via separate UPDATE, batch under 3,000 rows per transaction.
必须加载workflow-patterns.md(模式3:安全数据迁移)获取添加列→批量填充→验证→索引的流程。对于超过3000行的表,还需加载ddl-migrations/batched-migration.md。核心规则:先添加列,通过单独UPDATE设置默认值,每个事务处理不超过3000行。

Workflow 3: Application-Layer Referential Integrity

工作流3:应用层参照完整性

MUST load workflow-patterns.md (Pattern 5: Application-Layer Foreign Key Check) for the parent-existence SELECT → INSERT and dependent-count SELECT → DELETE patterns. Build all SQL with
safe_query.build()
— see Workflow 4a.
必须加载workflow-patterns.md(模式5:应用层外键检查)获取父行存在性检查SELECT→INSERT和依赖计数检查SELECT→DELETE模式。所有SQL必须使用
safe_query.build()
构建——参见工作流4a。

Workflow 4: Query with Tenant Isolation

工作流4:带租户隔离的查询

  1. MUST authorize the caller against the tenant — format validation does not establish authorization
  2. MUST build SQL with
    safe_query.build()
    — use
    allow()
    /
    regex()
    for values (emits
    'v'
    ),
    ident()
    for table/column names (emits
    "v"
    ). See input-validation.md
  3. MUST include
    tenant_id
    in the WHERE clause; reject cross-tenant access at the application layer
  1. 必须根据租户对调用方进行授权——格式验证不代表授权
  2. 必须使用
    safe_query.build()
    构建SQL——对值使用
    allow()
    /
    regex()
    (生成
    'v'
    ),对表/列名使用
    ident()
    (生成
    "v"
    )。详情请参见input-validation.md
  3. 必须在WHERE子句中包含
    tenant_id
    ;在应用层拒绝跨租户访问

Workflow 4a: Rubric-Critical — Building SQL with User Input

工作流4a:关键规范——使用用户输入构建SQL

Whenever constructing SQL for
psql -c "..."
(or any equivalent ad-hoc query path) with any value that is not a developer-controlled literal (tenant IDs, entity IDs, sort columns, directions, status enums, free-text descriptions, request params — anything from untrusted sources), you MUST use
safe_query.build()
. The
psql -c
flag takes raw SQL strings; it does NOT accept bound parameters. When using a Postgres driver (psycopg, pgx, etc.) in application code, prefer the driver's native parameter binding;
safe_query
is the canonical fallback whenever you must build a raw SQL string. Validation via
safe_query
is the primary defense for raw-SQL paths.
Validator selection table (canonical — mirrors input-validation.md):
Value kindValidatorEmits
Known set (tenant ID, status enum)
allow(v, SET)
'value'
Known set used as SQL keyword (ASC/DESC)
keyword(v, SET)
value
(unquoted)
Strict format (UUID, slug, ISO date)
regex(v, PATTERN)
'value'
Table or column name
ident(name)
"value"
Integer
integer(v)
value
Free text (description, comment, user name)
literal(v)
$dq_xxx$value$dq_xxx$
Built-in patterns from
safe_query.py
:
TENANT_SLUG
(
[a-z0-9-]{1,64}
),
UUID
,
INT
,
ISO_DATE
.
Required imports at the top of every file that builds DSQL SQL:
python
from safe_query import build, allow, regex, ident, keyword, integer, literal, UnsafeSQLError
from safe_query import TENANT_SLUG, UUID, ISO_DATE
Rubric-Critical Scenario 1 — tenant_id from untrusted input. Validate with
regex(req.tenant, TENANT_SLUG)
or
allow(req.tenant, ALLOWED_TENANTS)
. Build with
safe_query.build()
, then execute. Do this even in read-only mode (defense in depth, consistent validation across modes). Do NOT use f-strings,
.format()
, or bare concatenation.
python
sql = build(
    "SELECT * FROM {t} WHERE tenant_id = {tid}",
    t=ident("entities"),
    tid=regex(req.tenant, TENANT_SLUG),
)
无论何时使用非开发者控制的字面量(租户ID、实体ID、排序列、方向、状态枚举、自由文本描述、请求参数——任何来自不可信源的值)构建
psql -c "..."
(或任何等效临时查询路径)的SQL,必须使用
safe_query.build()
psql -c
标志接受原始SQL字符串;不支持绑定参数。在应用代码中使用Postgres驱动(psycopg、pgx等)时,优先使用驱动的原生参数绑定;当必须构建原始SQL字符串时,
safe_query
是标准备选方案。
safe_query
验证是原始SQL路径的主要防护手段。
验证器选择表(标准规范——与input-validation.md一致):
值类型验证器输出格式
已知集合(租户ID、状态枚举)
allow(v, SET)
'value'
用作SQL关键字的已知集合(ASC/DESC)
keyword(v, SET)
value
(无引号)
严格格式(UUID、短标识、ISO日期)
regex(v, PATTERN)
'value'
表或列名
ident(name)
"value"
整数
integer(v)
value
自由文本(描述、评论、用户名)
literal(v)
$dq_xxx$value$dq_xxx$
safe_query.py
内置模式:
TENANT_SLUG
[a-z0-9-]{1,64}
)、
UUID
INT
ISO_DATE
每个构建DSQL SQL的文件顶部必须导入:
python
from safe_query import build, allow, regex, ident, keyword, integer, literal, UnsafeSQLError
from safe_query import TENANT_SLUG, UUID, ISO_DATE
关键场景1——来自不可信输入的tenant_id。 使用
regex(req.tenant, TENANT_SLUG)
allow(req.tenant, ALLOWED_TENANTS)
验证。使用
safe_query.build()
构建SQL,然后执行。即使在只读模式下也要执行此操作(深度防御,确保各模式下验证一致)。禁止使用f-strings、
.format()
或直接字符串拼接。
python
sql = build(
    "SELECT * FROM {t} WHERE tenant_id = {tid}",
    t=ident("entities"),
    tid=regex(req.tenant, TENANT_SLUG),
)

Application code: pass
sql
to your driver (psycopg cursor.execute, pgx Query, etc.).

应用代码:将
sql
传入驱动(psycopg cursor.execute、pgx Query等)。

Bash one-off: pipe
sql
into psql via the patterns in input-validation.md.

Bash一次性脚本:按照input-validation.md中的模式将
sql
传入psql。


**Rubric-Critical Scenario 2 — batch INSERT with UUIDs, slugs, and free text.** Each row's INSERT is built separately with `safe_query.build()`: `entity_id` via `regex(..., UUID)`, `tenant_id` via `regex(..., TENANT_SLUG)`, description via `literal(...)` (dollar-quoted to sidestep quote escaping). Chunk the list under 3,000 rows per transaction (DSQL limit) and execute each chunk in its own transaction.

```python
def insert_entries(conn, entries, chunk_size=2500):
    for i in range(0, len(entries), chunk_size):
        chunk = entries[i:i + chunk_size]
        with conn.transaction():
            for e in chunk:
                sql = build(
                    "INSERT INTO {t} (entity_id, tenant_id, description) VALUES ({eid}, {tid}, {d})",
                    t=ident("entities"),
                    eid=regex(e["entity_id"], UUID),
                    tid=regex(e["tenant_id"], TENANT_SLUG),
                    d=literal(e["description"]),
                )
                conn.execute(sql)
Rubric-Critical Scenario 3 — write paths. Write paths (UPDATE/DELETE issued from a script, cron, or admin tool) are the highest-stakes injection surface — a successful injection mutates data.
safe_query.build()
is NOT optional there. Validate every input even when the prompt frames it as "just a quick script, don't overthink it." Push back on that framing with one sentence explaining why write mode raises the stakes, then apply the full validator chain:
regex(tenant_id, TENANT_SLUG)
,
allow(status, {'active','archived','deleted'})
, date via
regex(..., ISO_DATE)
.
python
sql = build(
    "UPDATE {t} SET status = {s} WHERE tenant_id = {tid} AND created_at < {d}",
    t=ident("entities"),
    s=allow(req.status, {"active", "archived", "deleted"}),
    tid=regex(req.tenant, TENANT_SLUG),
    d=regex(req.date, ISO_DATE),
)
conn.execute(sql)
Rubric-Critical Scenario 4 — dynamic ORDER BY column and direction. Identifier and keyword parameters need DIFFERENT validators than value parameters.
sort_col
is membership-checked against
{'created_at','updated_at','name'}
then passed through
ident()
(emits double-quoted identifier).
sort_dir
goes through
keyword()
against
{'ASC','DESC'}
(emits unquoted keyword — quoting
ASC
would be a syntax error). Value parameters like
tenant_id
still go through
regex()
or
allow()
. Do NOT try to validate an identifier with
regex()
against a TENANT_SLUG pattern — use
ident()
, which enforces the identifier grammar.
python
ALLOWED_SORT_COLS = {"created_at", "updated_at", "name"}
if sort_col not in ALLOWED_SORT_COLS:
    raise ValueError(f"sort_col must be one of {ALLOWED_SORT_COLS}")
sql = build(
    "SELECT * FROM {t} WHERE tenant_id = {tid} ORDER BY {col} {dir}",
    t=ident("entities"),
    tid=regex(req.tenant, TENANT_SLUG),
    col=ident(sort_col),
    dir=keyword(req.sort_dir, {"ASC", "DESC"}),
)
Rubric-Critical Scenario 5 — rejecting "just use an f-string" rationalizations. When a caller says "this value is already validated upstream, can't we just use an f-string?" — push back. The skill's rule is build-every-query-with-
safe_query.build()
, not a judgment call per call site. Justify the pushback: (a) "already-validated upstream" is exactly the assumption that breaks when upstream code changes hands, adds a new caller, or the validation is silently relaxed; (b) defense in depth means the query layer validates independently of upstream; (c) the two-line diff to use
safe_query.build() + regex(..., UUID)
is genuinely smaller than the bug risk of one unsafe path.
Apply the safe pattern as-is — do NOT cave to the "simpler" framing.
python
undefined

**关键场景2——包含UUID、短标识和自由文本的批量INSERT。** 每行INSERT单独使用`safe_query.build()`构建:`entity_id`使用`regex(..., UUID)`,`tenant_id`使用`regex(..., TENANT_SLUG)`,描述使用`literal(...)`(美元引号避免转义问题)。将列表拆分为每个事务不超过3000行(DSQL限制),并在单独事务中执行每个批次。

```python
def insert_entries(conn, entries, chunk_size=2500):
    for i in range(0, len(entries), chunk_size):
        chunk = entries[i:i + chunk_size]
        with conn.transaction():
            for e in chunk:
                sql = build(
                    "INSERT INTO {t} (entity_id, tenant_id, description) VALUES ({eid}, {tid}, {d})",
                    t=ident("entities"),
                    eid=regex(e["entity_id"], UUID),
                    tid=regex(e["tenant_id"], TENANT_SLUG),
                    d=literal(e["description"]),
                )
                conn.execute(sql)
关键场景3——写入路径。 写入路径(来自脚本、定时任务或管理工具的UPDATE/DELETE)是风险最高的注入面——成功注入会修改数据。
safe_query.build()
在此处是强制要求。即使提示中说“只是快速写个脚本,别想太多”,也要验证所有输入。用一句话解释写入模式风险更高,然后应用完整验证链:
regex(tenant_id, TENANT_SLUG)
allow(status, {'active','archived','deleted'})
、日期使用
regex(..., ISO_DATE)
python
sql = build(
    "UPDATE {t} SET status = {s} WHERE tenant_id = {tid} AND created_at < {d}",
    t=ident("entities"),
    s=allow(req.status, {"active", "archived", "deleted"}),
    tid=regex(req.tenant, TENANT_SLUG),
    d=regex(req.date, ISO_DATE),
)
conn.execute(sql)
关键场景4——动态ORDER BY列和方向。 标识符和关键字参数需要与值参数不同的验证器。
sort_col
先检查是否属于
{'created_at','updated_at','name'}
,然后通过
ident()
传递(生成双引号标识符)。
sort_dir
通过
keyword()
检查是否属于
{'ASC','DESC'}
(生成无引号关键字——对
ASC
加引号会导致语法错误)。
tenant_id
等值参数仍需通过
regex()
allow()
验证。禁止尝试使用
regex()
并匹配TENANT_SLUG模式验证标识符——使用
ident()
,它会强制遵循标识符语法。
python
ALLOWED_SORT_COLS = {"created_at", "updated_at", "name"}
if sort_col not in ALLOWED_SORT_COLS:
    raise ValueError(f"sort_col必须是{ALLOWED_SORT_COLS}之一")
sql = build(
    "SELECT * FROM {t} WHERE tenant_id = {tid} ORDER BY {col} {dir}",
    t=ident("entities"),
    tid=regex(req.tenant, TENANT_SLUG),
    col=ident(sort_col),
    dir=keyword(req.sort_dir, {"ASC", "DESC"}),
)
关键场景5——拒绝“直接用f-string就行”的合理化请求。 当调用方说“这个值已经在上游验证过了,我们能不能直接用f-string?”——必须拒绝。本技能的规则是所有查询都必须用
safe_query.build()
构建,而非逐调用点判断。拒绝理由:(a)“已在上游验证”的假设会在上游代码易主、新增调用方或验证被悄悄放宽时失效;(b)深度防御意味着查询层独立于上游进行验证;(c)使用
safe_query.build() + regex(..., UUID)
只需两行代码,远小于一条不安全路径带来的漏洞风险。
严格应用安全模式——不要屈服于“更简单”的说法。
python
undefined

No — even for "already-validated upstream" values:

错误示例——即使是“已在上游验证”的值也不行:

sql = f"SELECT * FROM entities WHERE entity_id = '{req.entity_id}'" # BAD
sql = f"SELECT * FROM entities WHERE entity_id = '{req.entity_id}'" # 不安全

Yes — uniform pattern at every call site:

正确示例——每个调用点使用统一模式:

sql = build( "SELECT * FROM {t} WHERE entity_id = {eid}", t=ident("entities"), eid=regex(req.entity_id, UUID), )

**Anti-patterns (the rubric fails these):**

- Using f-strings, `.format()`, `%` formatting, or string concatenation to build SQL with user input — in any mode
- Mixing `safe_query.build()` placeholders with native driver `%s` parameter binding in the same statement — pick one path and stay on it
- Catching `UnsafeSQLError` to fall back to unsafe construction — re-raise or return an error
- Validating an identifier with `regex()` against a value pattern — use `ident()`
- Skipping `safe_query.build()` in read-only mode under "the value is already validated upstream" — defense in depth means the SQL builder validates independently of upstream
sql = build( "SELECT * FROM {t} WHERE entity_id = {eid}", t=ident("entities"), eid=regex(req.entity_id, UUID), )

**反模式(不符合规范):**

- 使用f-strings、`.format()`、`%`格式化或字符串拼接构建包含用户输入的SQL——任何模式下都禁止
- 在同一条语句中混合使用`safe_query.build()`占位符和驱动原生`%s`参数绑定——选择一种方式并坚持使用
- 捕获`UnsafeSQLError`后回退到不安全构建方式——应重新抛出或返回错误
- 使用`regex()`并匹配值模式验证标识符——使用`ident()`
- 在只读模式下以“值已在上游验证”为由跳过`safe_query.build()`——深度防御要求SQL构建器独立于上游进行验证

Workflow 5: Set Up Scoped Database Roles

工作流5:设置限定范围数据库角色

MUST load access-control.md for role setup, IAM mapping, and schema permissions.
必须加载access-control.md获取角色设置、IAM映射和架构权限相关内容。

Workflow 6: Table Recreation DDL Migration

工作流6:表重建DDL迁移

DSQL does NOT support direct
ALTER COLUMN TYPE
,
DROP COLUMN
,
DROP CONSTRAINT
, or
MODIFY PRIMARY KEY
. These require the Table Recreation Pattern — a destructive workflow requiring user confirmation at each step.
MUST load ddl-migrations/overview.md first, then the relevant sub-file:
  • Column changes (type, nullability, default): ddl-migrations/column-operations.md
  • Constraint/PK changes, column splits/merges: ddl-migrations/constraint-operations.md
  • Tables exceeding 3,000 rows: also load ddl-migrations/batched-migration.md
DSQL不支持直接执行
ALTER COLUMN TYPE
DROP COLUMN
DROP CONSTRAINT
MODIFY PRIMARY KEY
。这些操作需要使用表重建模式——这是一种破坏性工作流,每一步都需要用户确认。
必须先加载ddl-migrations/overview.md,然后加载相关子文件:
  • 列变更(类型、可空性、默认值):ddl-migrations/column-operations.md
  • 约束/主键变更、列拆分/合并:ddl-migrations/constraint-operations.md
  • 超过3000行的表:还需加载ddl-migrations/batched-migration.md

Workflow 7: MySQL to DSQL Schema Migration

工作流7:MySQL到DSQL架构迁移

MUST load mysql-migrations/type-mapping.md for type mappings and feature alternatives. For DDL translation details load mysql-migrations/ddl-operations.md. For an end-to-end example load mysql-migrations/full-example.md.
必须加载mysql-migrations/type-mapping.md获取类型映射和功能替代方案。DDL转换详情请加载mysql-migrations/ddl-operations.md。端到端示例请加载mysql-migrations/full-example.md

Workflow 8: Query Plan Explainability

工作流8:查询计划可解释性

Triggered by slow queries, high DPU, unexpected Full Scans, or plans the user doesn't understand. A structured Markdown diagnostic report is the required deliverable — run the workflow end-to-end before answering.
MUST load all four reference files before starting:
  1. query-plan/plan-interpretation.md — node types, duration math, anomalous values
  2. query-plan/catalog-queries.md — pg_class / pg_stats / pg_indexes SQL
  3. query-plan/guc-experiments.md — GUC procedures and
    >30s
    skip protocol
  4. query-plan/report-format.md — required report structure and elements checklist
Phase 1 — Capture the plan. ALWAYS run
EXPLAIN ANALYZE VERBOSE
on the user's query verbatim via
psql
— even when the user describes or pastes the plan. SELECT runs as-is. UPDATE/DELETE: rewrite to the equivalent SELECT before running. INSERT, pl/pgsql, DO blocks, and functions MUST be rejected. MUST NOT run mutating DML during plan capture. When EXPLAIN errors, report verbatim — do not invent DSQL-specific semantics. Extract Query ID, Planning Time, Execution Time, and DPU Estimate.
Phase 2 — Gather evidence. Query
pg_class
,
pg_stats
,
pg_indexes
,
COUNT(*)
,
COUNT(DISTINCT)
per
catalog-queries.md
. Classify estimation errors per
plan-interpretation.md
.
Phase 3 — Experiment (conditional). ≤30s: run GUC experiments per
guc-experiments.md
plus redundant-predicate test. >30s: skip, include manual GUC SQL verbatim in the report. Anomalous row counts: confirm results are correct, flag as potential DSQL bug, produce Support Request Template.
Phase 4 — Report and invite reassessment. Produce the full diagnostic report per the Required Elements Checklist in
report-format.md
. End with the "Next Steps" block. When user says "reassess", re-run Phases 1–2 and append an "Addendum: After-Change Performance" to the original report.
psql invocation:
bash
./scripts/psql-connect.sh --cluster <id> --command "EXPLAIN ANALYZE VERBOSE <sql>"
./scripts/psql-connect.sh --cluster <id> --script ./experiment-2.sql   # GUC multi-statement

触发场景:慢查询、高DPU、意外全表扫描或用户无法理解的计划。结构化Markdown诊断报告是必填交付物——在回答前需完整执行此工作流。
开始前必须加载全部四个参考文件:
  1. query-plan/plan-interpretation.md——节点类型、时长计算、异常值
  2. query-plan/catalog-queries.md——pg_class/pg_stats/pg_indexes SQL
  3. query-plan/guc-experiments.md——GUC流程和
    >30s
    跳过规则
  4. query-plan/report-format.md——必填报告结构和元素清单
阶段1——捕获计划。 始终通过
psql
对用户的原始查询执行
EXPLAIN ANALYZE VERBOSE
——即使用户描述或粘贴了计划。SELECT查询直接执行。UPDATE/DELETE:重写为等效SELECT后执行。必须拒绝INSERT、pl/pgsql、DO块和函数。捕获计划期间禁止执行修改数据的DML。当EXPLAIN报错时,原样报告——不要编造DSQL专属语义。提取Query ID、规划时间、执行时间和DPU估计值。
阶段2——收集证据。 根据
catalog-queries.md
查询
pg_class
pg_stats
pg_indexes
COUNT(*)
COUNT(DISTINCT)
。根据
plan-interpretation.md
分类估计误差。
阶段3——实验(可选)。 ≤30秒:根据
guc-experiments.md
运行GUC实验及冗余谓词测试。>30秒:跳过,在报告中原样包含手动GUC SQL。异常行数:确认结果正确,标记为潜在DSQL漏洞,生成支持请求模板。
阶段4——报告并邀请重新评估。 根据
report-format.md
中的必填元素清单生成完整诊断报告。结尾添加“下一步”模块。当用户要求“重新评估”时,重新运行阶段1-2,并在原报告后添加“补充:变更后性能”部分。
psql调用示例:
bash
./scripts/psql-connect.sh --cluster <id> --command "EXPLAIN ANALYZE VERBOSE <sql>"
./scripts/psql-connect.sh --cluster <id> --script ./experiment-2.sql   # GUC多语句

Security Considerations

安全注意事项

This section consolidates key security controls. For detailed guidance, see the linked reference files.
  1. IAM auth token expiry: IAM auth tokens expire after 15 minutes. Always generate fresh tokens per connection or implement periodic refresh. Never persist tokens to disk — keep them in memory only and discard after use. See authentication-guide.md.
  2. Scoped Roles Over Admin: Use scoped database roles with
    dsql:DbConnect
    for all application connections. Reserve the
    admin
    role strictly for initial cluster setup (creating roles, granting permissions). Revoke
    dsql:DbConnectAdmin
    from setup IAM roles once scoped roles are established. See access-control.md.
  3. Encryption in Transit: SSL/TLS is enforced server-side. Use
    sslmode=verify-full
    (default in DSQL connectors and
    psql-connect.sh
    ) to validate the server certificate against DSQL's CA, preventing MITM attacks. Only downgrade to
    require
    when the client lacks access to a trusted CA bundle.
  4. Encryption at Rest: Aurora DSQL encrypts all data at rest using AWS-managed keys by default. No additional configuration is required; verify encryption status in cluster properties when compliance frameworks require attestation.
  5. Audit Logging via CloudTrail: Enable CloudTrail logging for DSQL API calls to monitor token generation patterns, cluster configuration changes, and failed authentication attempts. Configure CloudWatch alarms for suspicious activity. Enable encryption on CloudWatch Log Groups used for DSQL monitoring using a KMS key to protect potentially sensitive query metadata. See authentication-guide.md.
  6. Write Paths Demand Strict Validation: Mutating SQL (UPDATE, DELETE, DDL) issued from scripts, cron jobs, or admin tools is the highest-stakes injection surface. Every write path MUST route through
    safe_query.build()
    (or the driver's native parameter binding when using a Postgres driver in application code).
  7. Input Validation Is the Primary Defense:
    safe_query.build()
    is the primary defense against SQL injection on raw-SQL paths. Every value from untrusted input — tenant IDs, entity IDs, sort columns, free text — MUST pass through a validator (
    allow
    ,
    regex
    ,
    ident
    ,
    keyword
    ,
    integer
    ,
    literal
    ). Do not use f-strings,
    .format()
    , or concatenation. See input-validation.md.
  8. Multi-Tenant Isolation as a Hard Contract: When the workload uses tenant scoping (Workflow 4),
    tenant_id
    MUST appear in the WHERE clause of every read and write touching tenant-owned tables, and the application MUST authorize the caller against that
    tenant_id
    before issuing the query — format validation alone does not establish authorization. Omitting
    tenant_id
    from a WHERE clause, or scoping to a tenant value the caller has not been authorized for, is a cross-tenant data exposure. This boundary is enforced by the skill, not by DSQL — verify every data-access path scopes to the authenticated tenant before deployment. See access-control.md and Workflow 4.

本节汇总关键安全控制措施。详细指导请参见链接的参考文件。
  1. IAM认证令牌过期: IAM认证令牌15分钟后过期。每次连接时生成新令牌,或实现定期刷新。切勿将令牌持久化到磁盘——仅在内存中保存,使用后立即丢弃。详情请参见authentication-guide.md
  2. 优先使用限定范围角色而非管理员: 所有应用连接使用带有
    dsql:DbConnect
    权限的限定范围数据库角色。仅在初始集群设置(创建角色、授予权限)时严格保留
    admin
    角色。限定范围角色建立后,从设置IAM角色中撤销
    dsql:DbConnectAdmin
    权限。详情请参见access-control.md
  3. 传输中加密: 服务器端强制启用SSL/TLS。使用
    sslmode=verify-full
    (DSQL连接器和
    psql-connect.sh
    的默认值)验证服务器证书与DSQL的CA是否匹配,防止MITM攻击。仅当客户端无法访问可信CA包时才降级为
    require
  4. 静态加密: Aurora DSQL默认使用AWS管理的密钥对所有静态数据进行加密。无需额外配置;当合规框架需要证明时,在集群属性中验证加密状态。
  5. 通过CloudTrail进行审计日志: 为DSQL API调用启用CloudTrail日志,以监控令牌生成模式、集群配置变更和失败的认证尝试。为可疑活动配置CloudWatch告警。使用KMS密钥为DSQL监控所用的CloudWatch日志组启用加密,保护潜在敏感的查询元数据。详情请参见authentication-guide.md
  6. 写入路径需要严格验证: 来自脚本、定时任务或管理工具的修改SQL(UPDATE、DELETE、DDL)是风险最高的注入面。每个写入路径必须通过
    safe_query.build()
    (或应用代码中使用Postgres驱动时的驱动原生参数绑定)处理。
  7. 输入验证是主要防护手段:
    safe_query.build()
    是原始SQL路径防止SQL注入的主要防护手段。来自不可信输入的每个值——租户ID、实体ID、排序列、自由文本——必须通过验证器(
    allow
    regex
    ident
    keyword
    integer
    literal
    )。禁止使用f-strings、
    .format()
    或字符串拼接。详情请参见input-validation.md
  8. 多租户隔离是硬性要求: 当工作负载使用租户范围划分(工作流4)时,
    tenant_id
    必须出现在每个访问租户所有表的读写操作的WHERE子句中,且应用必须在发出查询前根据
    tenant_id
    对调用方进行授权——仅格式验证不代表授权。WHERE子句中省略
    tenant_id
    ,或限定到调用方未被授权的租户值,会导致跨租户数据泄露。此边界由本技能强制实施,而非DSQL——部署前需验证每个数据访问路径都限定到已认证租户。详情请参见access-control.md和工作流4。

Troubleshooting

故障排除

  • AWS MCP Server returns no results: Use the default limits in the table above and note that limits should be verified against DSQL documentation.
  • OCC serialization error: Retry the transaction. If persistent, check for hot-key contention — see troubleshooting.md.
  • Transaction exceeds limits: Split into batches under 3,000 rows — see batched-migration.md.
  • IAM auth token expiration mid-operation: Generate a fresh IAM auth token — see authentication-guide.md. See troubleshooting.md for other issues.

  • AWS MCP Server无结果返回: 使用上表中的默认限制值,并告知用户需参照DSQL文档验证限制。
  • OCC序列化错误: 重试事务。若持续出现,检查是否存在热键冲突——参见troubleshooting.md
  • 事务超出限制: 拆分为每个批次不超过3000行——参见batched-migration.md
  • 操作过程中IAM认证令牌过期: 生成新的IAM认证令牌——参见authentication-guide.md。其他问题请参见troubleshooting.md

Additional Resources

附加资源

Handoff from aws-database-selection

从aws-database-selection移交

This skill can be invoked directly, or it can be entered from the
aws-database-selection
parent skill after that skill has run a requirements interview and produced a
requirements.json
artifact. When you see a backtick-wrapped path matching
aws_dbs_requirements/*/requirements.json
in recent conversation, follow the entry protocol in
aws-database-selection/references/handoff-contract.md
:
  1. Read the artifact using
    file_read
    .
  2. Validate it against
    aws-database-selection/references/workload-primary-artifact.schema.json
    . If malformed or unreadable, tell the user and proceed without it.
  3. Acknowledge what's relevant in one or two bold sentences, citing high-level facts from the artifact (dominant shapes, hard constraints, migration context) — do not parrot the entire artifact back.
  4. Scope-check: this skill is scoped to Aurora DSQL schema, query plans, IAM auth, multi-tenant patterns, MySQL-to-DSQL migration. If the artifact's
    workload_primaries.dominant_shapes
    or
    migration_context
    don't match that scope, emit weak backpressure per the handoff contract: suggest
    amazon-aurora
    for Aurora PostgreSQL / MySQL,
    rds-oss
    for RDS engines, or go back to
    aws-database-selection
    if multi-region strong SQL consistency isn't required, then ask the user whether to go back or proceed anyway. Do not silently misuse the artifact.
  5. Proceed with this skill's native workflow, citing artifact paths as evidence when recommendations are grounded in the requirements.
All user-facing output from this skill follows the markdown-primitives-only formatting convention in the handoff contract: bold labels, backticks for paths and enum values, bullet lists for alternatives, no ASCII art or box-drawing characters.
本技能可直接调用,也可在
aws-database-selection
父技能完成需求调研并生成
requirements.json
工件后进入。如果在近期对话中看到反引号包裹的路径匹配
aws_dbs_requirements/*/requirements.json
,请遵循
aws-database-selection/references/handoff-contract.md
中的进入协议:
  1. 使用
    file_read
    读取工件。
  2. 根据
    aws-database-selection/references/workload-primary-artifact.schema.json
    验证工件。若格式错误或无法读取,告知用户并在无工件的情况下继续。
  3. 用一两句加粗句子确认相关内容,引用工件中的高级事实(主要形态、硬性约束、迁移上下文)——不要复述整个工件。
  4. 范围检查:本技能的范围涵盖Aurora DSQL架构、查询计划、IAM认证、多租户模式、MySQL到DSQL迁移。如果工件的
    workload_primaries.dominant_shapes
    migration_context
    与该范围不匹配,根据移交协议发出弱回压:建议使用
    amazon-aurora
    处理Aurora PostgreSQL/MySQL,使用
    rds-oss
    处理RDS引擎,或如果不需要多区域强SQL一致性则返回
    aws-database-selection
    ,然后询问用户是返回还是继续。切勿滥用工件。
  5. 继续执行本技能的原生工作流,当建议基于需求时引用工件路径作为证据。
本技能的所有用户输出遵循移交协议中的仅Markdown原语格式约定:加粗标签、反引号包裹路径和枚举值、项目符号列表展示替代方案,禁止使用ASCII艺术或框式绘图字符。