/amazon-aurora-postgresql

name: amazon-aurora-postgresql
description: >-
  Amazon Aurora PostgreSQL — creates, modifies, and advises on Aurora PostgreSQL clusters
  specifically (PostgreSQL-compatible engine, Aurora serverless, express configuration,
  pgvector, Babelfish). Trigger for Aurora PostgreSQL cluster operations, express-configuration
  quick-start, ACU sizing, I/O-Optimized storage, commitment pricing, or PostgreSQL
  upgrade planning. For Aurora MySQL, use amazon-aurora-mysql instead. Contains safety
  guardrails, express-first routing, and response templates that override defaults.
version: 1

Amazon Aurora PostgreSQL

A modular toolkit for **Aurora PostgreSQL** organized as a registry of sub-skills. Each sub-skill handles one domain of Aurora PostgreSQL work. The router matches user intent to the right sub-skill, then loads only the references needed. (For Aurora MySQL, use the `amazon-aurora-mysql` 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 PostgreSQL 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 PostgreSQL cluster creation requests. Express configuration (single API call, no VPC) is the default — routes to `express-create`. Routes to full configuration when VPC, custom KMS, custom params, or a specific engine version is required. | create a cluster, new database, set up Aurora PostgreSQL, get started, need a PostgreSQL database, provision | — | `express-create`, `serverless-advisory`, `io-optimized` | | `express-create` | Express Configuration | Provisions Aurora PostgreSQL serverless via the single-API-call express flow. AWS-managed connectivity (no customer VPC). **IAM-only authentication via Internet Access Gateway — no master password.** Post-creation connection is via IAM auth token (`aws rds generate-db-auth-token`). Use when no VPC, custom KMS, or custom parameter group is required. Routes back to `create` for full configuration needs. | express configuration, express create, internet access gateway, single API call, Aurora PostgreSQL serverless quick start, no VPC, IAM auth token, how to connect to express cluster | `create` | — | | `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 PostgreSQL. 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 | — | — |

Express vs Full configuration — decision matrix

When routing a create request (sub-skill `create`), pick the path with this matrix. **Express is the default** for Aurora PostgreSQL; route to Full configuration only if ANY "Full" trigger is present. Don't present the choice to the user — decide, then state which path and why.

| Requirement / signal | Express | Full config | |---|---|---| | Default PostgreSQL create, no special networking | ✅ default | — | | Quick start / "no VPC setup" / "ready in seconds" | ✅ | — | | Customer VPC, subnet group, or specific security group | — | ✅ required | | Customer-managed KMS key (CMK) | — | ✅ required | | Custom DB cluster parameter group **at creation** | — | ✅ required | | Specific engine version pinned by the user | — | ✅ required (intent to pin = not express) | |