Amazon Aurora Mysql

Amazon Aurora MySQL

A modular toolkit for Aurora MySQL organized as a registry of sub-skills. Each sub-skill handles one domain of Aurora MySQL work. The router matches user intent to the right sub-skill, then loads only the references needed. (For Aurora PostgreSQL — and its express-configuration quick-start — use the amazon-aurora-postgresql skill.)

Operating procedure (follow in order)

1. Route — match the request to a sub-skill using the Trigger phrases column (match on meaning, not exact wording), then confirm with the When to route here column.
2. Load — file_read the matched sub-skill's references/{id}-instructions.md and announce the path. Do not answer a matched sub-skill from general knowledge alone.
3. Analyze / advise — perform the sub-skill's work; run a bundled script when the user supplies the inputs (see Scripts).
4. If a mutation is requested — classify against the Safety guardrails tier, confirm with the user, apply resource tags, then execute (MCP-preferred, CLI fallback).
5. Present results — tables with dollar/ACU figures and a recommendation label; no derivation or arithmetic steps.

Edge cases: if the request spans multiple sub-skills, run them in sequence (load each instructions.md in turn). If no sub-skill matches, answer directly from Aurora MySQL knowledge. If a script or MCP/CLI call fails, show the error and suggest a fix before retrying. The numbered Global rules below are details that hang off these steps.

Sub-skill registry

Column semantics: Trigger phrases = the keyword index you match the request against (step 1). When to route here = the decision logic confirming the match. Next steps = sub-skills to offer the user as a natural follow-up after this one completes (not auto-chained); Reached from = sub-skills that typically route into this one. Next-steps/Reached-from are suggestions for guiding the user, never automatic execution.

Global rules (apply to every sub-skill)

1. Execute, don't just suggest. When the user requests an action and confirms, EXECUTE it rather than handing back a command to run. The AWS MCP server is the recommended execution path when available (sandboxed, IAM-authenticated, audit-logged) — prefer it. When MCP tools are not available (e.g. Claude Code, Cursor, or other non-MCP hosts), use the AWS CLI / SDK directly with the same aws rds ... operation. Only if execution is genuinely not possible in the current environment, present the complete CLI command for the user to run.

1. Confirmation before mutation. MUST confirm with the user before any create or modify operation. Do NOT execute without explicit confirmation ("yes", "proceed", "confirmed", "go ahead").

1. Resource tagging (always apply on resource creation). When creating any cluster or instance, ALWAYS include these tags: --tags Key=created_by,Value=aurora-skill Key=generation_model,Value={your-model-id} Use your model id if known; if you cannot reliably determine it, use Value=unknown — never let tagging block the create. Include these tags even if the user does not mention tagging. If the user provides additional tags, append these to their tags.

1. Safety guardrails.

Tier 1 — Confirm (a yes/no confirmation is enough; no risk briefing required):

• create-db-cluster (full/VPC configuration — Aurora MySQL does not support express)
• create-db-instance
• modify-db-cluster --serverless-v2-scaling-configuration (ACU scaling)
• modify-db-cluster --backup-retention-period
• modify-db-cluster --deletion-protection / --no-deletion-protection
• modify-db-cluster --enable-cloudwatch-logs-exports
• modify-db-cluster --preferred-backup-window
• modify-db-cluster --enable-http-endpoint (Data API)
• add-tags-to-resource, remove-tags-from-resource

Tier 2 — High-impact: state the specific risk, THEN confirm (spell out the impact before asking; do not call any API until the user confirms with that risk in front of them):

• modify-db-cluster --storage-type — no downtime for most instance classes; requires restart for NVMe/Optimized Reads instances (r6gd, r6id, r8gd). Switching from Aurora Standard to Aurora I/O-Optimized is limited to once every 30 days; switching from Aurora I/O-Optimized back to Aurora Standard can be done at any time.
• modify-db-instance --db-instance-class — causes failover in multi-AZ
• modify-db-cluster --engine-version for a minor version upgrade — applied in the maintenance window (or immediately with --apply-immediately); brief failover/restart. State the target version and the restart impact, then confirm. (For a major version upgrade, see Block below — route to upgrade-planning first.)
• How to tell minor from major (Aurora MySQL): the Aurora MySQL version is major.minor.patch (e.g. 3.06, 3.08). The major digit (2 = MySQL 5.7-compatible, 3 = MySQL 8.0-compatible, 8.4+) is the major version; the second number is the minor version. So 3.06 → 3.08 is a MINOR upgrade (major 3 unchanged) → handle here in Tier 2. A change in the leading major (e.g. 2.x → 3.x, or 5.7 → 8.0 compatibility) is a major upgrade → Block. When unsure, treat it as major and route to upgrade-planning.
• Any modify with --apply-immediately — bypasses maintenance window

Tier 3 — Block (refuse, explain why, redirect to console/change-control):

• delete-db-cluster, delete-db-instance — irreversible
• failover-db-cluster, switchover-blue-green-deployment — production impact
• modify-db-cluster --engine-version across major versions — requires prechecks and rollback plan
• modify-db-cluster --master-user-password, --manage-master-user-password — credential management must be performed by the customer directly. Use AWS Secrets Manager rotation or the AWS Console.