Setting the file. One moment.
Skill 62 · Amazon Aurora PostgreSQL
Subchapter 62.7
references/create-instructions.mdMarkdown7 KBView on GitHub
Provisions Aurora clusters. Express configuration is the default for PostgreSQL (single API call, no VPC setup). Route to full configuration only when the user requires VPC connectivity, Aurora MySQL, customer-managed KMS, custom parameter groups, or a specific engine version.
Execute commands via the AWS MCP server when connected (sandboxed, audit-logged). Fall back to the AWS CLI or shell otherwise.
Express (default for PostgreSQL):
create-db-cluster --with-express-configuration--engine-mode, --serverless-v2-scaling-configuration, --master-username, or --manage-master-user-passwordFull configuration (use when):
create-db-cluster + create-db-instanceMUST load ../express-create/instructions.md first before any routing decision or API call. It contains the response requirements, routing rules, and full constraint list. Do NOT skip it and go straight to deeper express-create files.
Identify ALL incompatibility triggers in the user’s request. Every match disqualifies express:
State the routing decision FIRST in your response, before any AWS API call, version lookup, resource discovery, or follow-up question. This MUST be the literal opening sentence(s) of your reply. Use this template:
For express: “Routing to express configuration — your request is compatible with the single-API-call flow. [proceed with express response requirements]”
For full configuration: “Routing to full configuration because your request includes [list ALL matched triggers — e.g., ‘VPC connectivity, customer-managed KMS, and a custom parameter group’, or ‘a specific engine version (15.4)’, or ‘Aurora MySQL’]. Express configuration doesn’t support these, so I’ll use the standard creation flow.”
The trigger list MUST name every incompatibility detected. If the user mentioned VPC + KMS + custom params, all three must appear. A specific engine version is itself a sufficient trigger — even if the version turns out to be unavailable or invalid in Aurora, the user’s intent to specify a version means they don’t want express, so route to full first, then handle version availability second.
Do NOT skip the routing statement for any reason, including: the version doesn’t exist, the cluster name conflicts with a constraint, the user might have misspoken, or the request seems ambiguous. State the routing decision based on what the user asked for, then handle complications afterward.
Engine version validation: If you need describe-db-engine-versions to verify the requested version, do it AFTER printing the routing statement. Flow: (1) state “Routing to full configuration because you specified version X.Y”, (2) “Let me verify that version is available”, (3) call the AWS API. The routing statement must be issued first even if the version turns out invalid — separate concerns.
Then proceed with the chosen path:
express-create/instructions.md (state Aurora serverless, mention internet access gateway, cite AWS docs URL, state “ready in seconds”)Confirm cluster name and region.
Production secure default — deletion protection. If the cluster is production or production-adjacent (user says “prod”, names it so, or describes a customer-facing/critical workload), recommend deletion protection at creation and include --deletion-protection in the proposed command, surfacing it in the confirmation — e.g. “I’ll enable deletion protection since this is production; disable later with --no-deletion-protection if needed.” Don’t force it on throwaway clusters; offer and let the user decide.
Execute after user confirms.
--with-express-configuration as a single flag (not manual construction)--publicly-accessible on any Aurora instance. If the user needs to connect from outside the VPC, offer secure alternatives (see SKILL.md safety guardrails). If the workload doesn’t actually require a VPC, route to express instead — express clusters are internet-accessible via IAM auth without exposing the database publicly.If the user creates a full-config cluster and then cannot connect from their local machine, do NOT solve this by making the instance publicly accessible. Instead:
--enable-http-endpoint) — query over HTTPS with IAM auth; no network path needed.ssh -L 5432:<cluster-endpoint>:5432 ec2-user@<bastion-ip>, then connect to localhost:5432.Always load (workflow step 1):
Load on demand: