| name | amazon-aurora-mysql |
| description | Amazon Aurora MySQL — creates, modifies, and advises on Aurora MySQL clusters specifically (MySQL-compatible engine, Aurora serverless, parallel query). Trigger for Aurora MySQL cluster operations, ACU sizing, I/O-Optimized storage, commitment pricing, or MySQL upgrade planning. Aurora MySQL uses full (VPC-based) configuration — express configuration is PostgreSQL-only. For Aurora PostgreSQL, use amazon-aurora-postgresql instead. Contains safety guardrails and response templates that override defaults. |
| version | 1 |
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)
- 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.
- 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.
- Analyze / advise — perform the sub-skill's work; run a bundled script when the user supplies the inputs (see Scripts).
- If a mutation is requested — classify against the Safety guardrails tier, confirm with the user, apply resource tags, then execute (MCP-preferred, CLI fallback).
- 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.
| ID | Name | When to route here | Trigger phrases | Reached from | Next steps |
|---|
create | Create Cluster | Routes Aurora MySQL cluster creation requests. Aurora MySQL uses full (VPC-based) configuration — collect VPC/subnet group, security group, KMS, parameter group, and engine version, present options, then create. (Express configuration is PostgreSQL-only and does not apply to Aurora MySQL.) | create a cluster, new database, set up Aurora MySQL, get started, need a MySQL database, provision | — | serverless-advisory, io-optimized |
serverless-advisory | Aurora serverless Advisory | All Aurora serverless questions: ACU sizing, scale-to-zero behavior and compatibility, provisioned→serverless migration, capacity planning, and feature constraints. | ACU sizing, Aurora serverless, scale-to-zero, provisioned to serverless, how many ACUs, capacity, auto-scaling, RDS Proxy compatibility, scale-to-zero incompatibility, serverless limitations | create (optional) | commitment-pricing |
io-optimized | I/O-Optimized Storage | Evaluates whether to switch from Aurora Standard to I/O-Optimized (aurora-iopt1). Uses the 25% I/O cost threshold rule. | I/O-Optimized, aurora-iopt1, storage type switch, 25% threshold, I/O costs too high, storage comparison | — | — |
commitment-pricing | Commitment Pricing | Compares Reserved Instances vs Database Savings Plans for provisioned clusters, and DSP-only for Aurora serverless. 1yr vs 3yr analysis. | Reserved Instance, RI, Savings Plan, DSP, 1yr vs 3yr, commitment, cost optimization, overpaying | serverless-advisory (optional) | — |
upgrade-planning | Upgrade Planning | Major and minor version upgrade planning for Aurora MySQL. LTS version guidance, pre/post-upgrade checklists, blue/green deployment recommendations. | upgrade, version, LTS, pre-upgrade checklist, post-upgrade, major version, minor version, end of life, deprecation | — | — |
Global rules (apply to every sub-skill)
-
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.
-
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").
-
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.
-
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-instancemodify-db-cluster --serverless-v2-scaling-configuration (ACU scaling)modify-db-cluster --backup-retention-periodmodify-db-cluster --deletion-protection / --no-deletion-protectionmodify-db-cluster --enable-cloudwatch-logs-exportsmodify-db-cluster --preferred-backup-windowmodify-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.
Scripts
Bundled scripts in scripts/ for offline analysis. MUST use these when the user provides the required inputs — do NOT hand-calculate. Each script documents its full flags/usage in its own --help and header docstring; read those on demand rather than relying only on the one-line usage below.
Script execution model: If a shell is available, execute the script directly and present the output. If no shell is available, print the exact command as a fenced bash code block with all flags resolved to user-supplied values, then present results computed inline from the reference file's pricing tables. (Result-presentation format is governed by the Operating procedure / Global rules — no derivation steps.)
| Script | Purpose | Usage |
|---|
acu_calculator.py | Aurora serverless ACU sizing | python3 scripts/acu_calculator.py estimate --instance <type> --cpu-p95 <val> --cpu-max <val> --storage <val> |
io_optimized_analyzer.py | I/O-Optimized breakeven | python3 scripts/io_optimized_analyzer.py offline --instance <type> --num-instances <n> --storage-gib <val> --monthly-io-millions <val> |
commitment_pricing_analyzer.py | RI vs DSP cost comparison | python3 scripts/commitment_pricing_analyzer.py offline --instance <type> --num-instances <n> --region <region> (provisioned) or --serverless --avg-acu <val> (Aurora serverless) |
Troubleshooting
- AccessDenied: Attach
AmazonRDSReadOnlyAccess + CloudWatchReadOnlyAccess for reads. For creates/modifies, use a custom policy scoped to rds:CreateDBCluster, rds:CreateDBInstance, rds:ModifyDBCluster, rds:ModifyDBInstance, rds:AddTagsToResource, and rds:Describe*. See Identity and access management for Amazon Aurora.
- ExpiredToken / credentials: Refresh your AWS credentials using whatever mechanism you use (e.g. re-run your SSO/
aws sso login, ada credentials update, assume-role, or refresh the profile), then retry. Do not assume a specific credential tool.
- DBClusterNotFoundFault: Verify region and cluster ID.
- Throttling: Retry once, then narrow scope.
Additional Resources
Handoff from aws-database-selection
This skill can be entered from aws-database-selection after it produces a requirements.json. When you see a path matching aws_dbs_requirements/*/requirements.json in conversation:
- Read the artifact. Sanity-check it has the fields you'll use — at minimum
engine (or workload type), region, and the workload signals you route on (capacity/ACU hints, storage size, connectivity/VPC needs, version). If those are present and parseable, use them; if it's missing them or won't parse, proceed without it (don't block on a formal schema).
- Acknowledge relevant facts in 1-2 bold sentences.
- Scope-check: if the artifact doesn't match Aurora (e.g., key-access → DynamoDB, graph → Neptune, multi-region strong SQL → DSQL), suggest the right skill and ask whether to proceed anyway.
- Continue with this skill's sub-skill routing.
