Amazon Aurora Postgresql

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.

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.

Notes: any single Full trigger disqualifies express — name every trigger you matched in the routing statement. Express clusters are still customizable after creation (e.g. a custom parameter group can be applied post-create), so a future need isn't itself a reason to start with Full. Full depth on the flow lives in references/express-create-instructions.md and references/create-instructions.md — load those for the actual steps.

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.

2. 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").

3. 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.

4. Safety guardrails.

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

• create-db-cluster, create-db-cluster --with-express-configuration
• 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.)
• 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. Express clusters use IAM-only auth via the Internet Access Gateway and have no master password — these flags do not apply on express clusters and must NOT be used as a workaround for connection issues. For full-config clusters, use AWS Secrets Manager rotation or the AWS Console.
• modify-db-cluster --vpc-security-group-ids — network security posture change
• modify-db-cluster --db-cluster-parameter-group-name — can break applications
• create-db-instance --publicly-accessible, modify-db-instance --publicly-accessible — NEVER make Aurora instances publicly accessible. This exposes the database directly to the internet and is never the correct solution for connectivity. See secure connection alternatives below.
• purchase-reserved-db-instances-offering, create-savings-plan — financial commitment
• reboot-db-instance, reboot-db-cluster — production impact

When blocking, you MUST refuse immediately. Do NOT call any AWS API. Your response MUST have exactly two paragraphs:

Paragraph 1 — refuse: "I can't perform [action] because [reason]. This should go through your team's change-control process or the AWS Console."

Paragraph 2 — alternative (from the table below, always included):

• purchase-reserved-db-instances-offering, create-savings-plan → "I can run a commitment pricing assessment (RI vs DSP comparison) so you have the numbers to bring to procurement."
• delete-db-cluster, delete-db-instance → "I can help with snapshot creation or final-snapshot validation before deletion."
• modify-db-cluster --engine-version (major version) → "I can run an upgrade assessment — target version recommendation, prechecks, and pre/post checklists."
• failover-db-cluster, switchover-blue-green-deployment → "I can validate the cluster's state and review the failover/switchover plan with you."
• reboot-db-instance, reboot-db-cluster → "I can check for pending modifications and recommend a maintenance window."
• modify-db-cluster --master-user-password / --manage-master-user-password → "If this is an express cluster, there's no master password — express uses IAM-only auth via the Internet Access Gateway. I can walk you through generating an IAM auth token to connect. If this is a full-config cluster, rotate the password via AWS Secrets Manager or the AWS Console; both are safer than a direct API call."
• --publicly-accessible → "Making the instance publicly accessible exposes the database directly to the internet — this is a security anti-pattern even for prototypes. Instead: (1) Use express configuration — internet-accessible via IAM auth with no VPC; (2) Enable RDS Data API — query over HTTPS with IAM auth; (3) EC2 bastion with SSH tunnel. I can help you set up any of these."
• modify-db-cluster --vpc-security-group-ids → "I can describe the cluster's current security-group configuration and help you draft the intended change so you can apply it through your team's change-control process or the AWS Console."
• modify-db-cluster --db-cluster-parameter-group-name → "I can review the current parameter group and compare it against the target group (highlighting reboot-required parameters) so you can prepare the change for your team's change-control process or the AWS Console."

Never omit paragraph 2. A refusal without an alternative is incomplete.

5. Reference loading. Before responding to any matched sub-skill request, you MUST read references/{id}-instructions.md using your file-read tool (file_read if available, otherwise whatever your runtime exposes). Do not answer a matched sub-skill from the registry summary alone. Announce the path in your reply.

6. Express is a single CLI call. When using express configuration: create-db-cluster --with-express-configuration. Do NOT separately specify --engine-mode, --serverless-v2-scaling-configuration, --master-username, or --manage-master-user-password. The express flag sets all of these automatically.

7. Stay in scope. Once this skill is active, recommend the best Aurora configuration for the workload. Do not suggest non-AWS alternatives. For light workloads, recommend express with scale-to-zero.

8. Never fabricate. Do NOT invent AWS API results, pricing numbers, version lists, or instance metadata. If a live call fails, report the blocker and offer offline mode with user-supplied numbers.

9. Carry context forward. Pass along cluster ID, region, and workload details the user already supplied. They SHOULD NOT have to re-type information already in the conversation.

10. Broad requests. If the user says "help me with Aurora" or "analyze my cluster" without specifying a domain (create, sizing, I/O, commitment, upgrade), present the sub-skill domains as one line each and ask which they want to focus on. Do NOT silently pick a sub-skill and run it. Acknowledge any cluster ID and region so the user doesn't need to repeat them.

11. Out-of-scope topics. If the user asks about an Aurora feature not covered by a sub-skill (e.g., Global Database, Blue/Green Deployments, RDS Proxy), note that it is not covered by a specific sub-skill, answer from general Aurora knowledge, and link to the relevant AWS documentation page.

12. Credential safety. Do not create, store, or display long-lived credentials or DB passwords. However, aws rds generate-db-auth-token is approved — it produces a short-lived (15-minute) IAM token. This is the required connection method for express clusters. For non-express clusters, use user-supplied secret ARNs or pre-configured tunnels.

13. Present results clearly. Use tables with dollar figures, ACU numbers, and recommendation labels. Do NOT show derivation or arithmetic steps. Exception: when consolidating across multiple analyses ("summarize", "what should I do"), respond in 2-4 lines of plain prose — no headers, no bullets, no tables.

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.)

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

• Aurora User Guide
• Aurora pricing
• Aurora serverless
• Aurora PostgreSQL upgrades

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:

1. 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). 2. Acknowledge relevant facts in 1-2 bold sentences. 3. 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. 4. Continue with this skill's sub-skill routing.

Aurora Commitment Pricing — Mechanics Deep Dive

Reserved Instances (RI)

RIs are a per-instance commitment for provisioned Aurora. You commit to a specific instance class in a specific region for 1 or 3 years and get a discount on its on-demand rate.

Payment Options

These are AWS-published ceilings (the up-to maxima). The per-scenario estimates in mechanics.md are deliberately conservative and sit below these ceilings — use the script's live-fetched rates for an actual quote.

No Upfront is available only as a 1-year term; AWS does not offer a 3-year No Upfront RI.

Effective hourly rate: (upfront / term_hours) + recurring_hourly where term_hours = years × 365 × 24.

Size Flexibility

An RI for one instance size in a family covers equivalent normalized units of other sizes. Example:

• 1× db.r7g.2xlarge RI can cover 2× db.r7g.xlarge OR 4× db.r7g.large
• Normalization units: large=1, xlarge=2, 2xlarge=4, 4xlarge=8, 8xlarge=16, ...

Size flexibility does NOT apply across families or generations. An r7g RI doesn't cover r8g, r6g, or m7g.

What RI Doesn't Cover

• Aurora serverless (ACU pricing)
• Storage or I/O requests (no RI for storage in Aurora)

RIs do cover Aurora I/O-Optimized compute, but each I/O-Optimized instance consumes 1.3x the normalized RI units of the equivalent Aurora Standard instance. To fully cover an I/O-Optimized fleet, purchase ~30% additional RIs (use size flexibility for fractional amounts). Existing Aurora Standard RIs apply to I/O-Optimized instances proportional to the 1.3x consumption.

Database Savings Plans (DSP)

DSP is a $/hour account-wide commitment. You commit to spending $X per hour on Aurora compute for 1 year; in return you get a discounted rate on any Aurora instance-hour (or ACU-hour).

Key Properties

• Only 1-year term — no 3-year DSP
• Covers ALL Aurora compute: provisioned + Aurora serverless + I/O-Optimized premium
• Family-agnostic: one DSP covers r7g, r8g, c7g, etc. as long as they're Aurora
• Account-wide: applies to the consolidated billing family
• Payment: No Upfront only — DSP offers a single payment option (no Partial/All Upfront, unlike RIs). If you want to pay ahead, use the AWS Billing "advance pay" feature; it is not a DSP payment option and carries no extra discount.

Coverage Limits

DSP only covers latest-gen instance families: r7g, r7i, r8g, r8gd, m7g, c7g, and similar. Older families (r6g, r5, r4) are NOT covered — the Savings Plan discount will not apply to those hours.

If your fleet runs on r6g, you have two choices:

1. Migrate to r7g or newer before buying DSP (recommended — same $/GiB memory, better price/performance) 2. Buy RIs for the r6g instances instead

Typical Discount

1yr DSP discount vs on-demand depends on deployment type: up to ~20% for provisioned instances and up to ~35% for serverless (the 35% headline is the serverless ceiling). For the provisioned r7g/r8g families this section covers, expect up to ~20% — typically less than a comparable 3yr RI, but more flexible.

Mutual Exclusion

Only one discount applies per instance-hour. Priority:

1. RI coverage is applied first (to matching instances within that family) 2. DSP then applies to any remaining Aurora usage (if hourly commitment not yet consumed) 3. Anything above your DSP commitment bills at on-demand

You can mix RI + DSP strategically — e.g., RI for the steady baseline on one family, DSP to cover variable or cross-family usage. But the analyzer in this skill shows them as alternatives for clarity.

Break-Even Considerations

RIs save money when the instance runs more than ~40-60% of the term. Below that utilization, on-demand is cheaper because you're paying for hours you don't use.

• 1yr No-Upfront: break-even around 50% utilization
• 3yr All-Upfront: break-even around 40% utilization (but you front the cash)

If you're planning to migrate, upgrade, or shut down the cluster within the term, the commitment often costs more than on-demand.

I/O-Optimized Interaction

On I/O-Optimized clusters, compute is charged at 1.30× the standard rate. RI coverage applies to I/O-Optimized compute, but I/O-Optimized draws down RI normalized units 1.3x faster than Aurora Standard. To fully cover an I/O-Optimized cluster, buy ~30% more RIs (e.g., 10 db.r6g.large RIs → 13 needed → buy 3 more).

DSP also covers both Standard and I/O-Optimized compute at the DSP rate, so DSP is another good fit for I/O-Optimized fleets.

Multi-AZ and Failover

RI/DSP cover the writer and reader instances. Aurora's cluster volume is separate and not covered by compute commitments. Readers in Aurora are billed per instance-hour and benefit from RI/DSP identically to writers.

Aurora serverless Pricing

• RIs: not applicable
• DSP: covers ACU-hours for Aurora serverless
• DSP discount on ACU-hours is up to ~35% — typically LARGER than the up-to-20% discount on provisioned instances, making DSP especially valuable for serverless fleets

If a workload is truly variable (auto-pausing, scale-to-zero), DSP may not save money because you're committing to hourly $/hr even when the cluster is paused.

Aurora Commitment Pricing Workflow

Estimate monthly cost savings from Aurora Reserved Instances (RI) and Database Savings Plans (DSP) for one cluster, a fleet, or user-supplied workloads (including Aurora serverless). Three edge cases govern the math — DSP family coverage, I/O-Optimized handling, and serverless being DSP-only — all stated fully in Step 4 and mechanics.md. Purchases are blocked — see SKILL.md Safety guidance. Execute commands via the AWS MCP server when connected (sandboxed, audited); else use the AWS CLI or shell.

When This Applies

User mentions: Reserved Instance, RI, Savings Plan, DSP, commitment pricing, No/Partial/All Upfront, 1-year vs 3-year, or whether a commitment is worth buying.

Critical edge case: cluster has no DB instances (skipped: true)

Before running ANY analysis on a specific cluster, check whether it has DB instances attached. If aws rds describe-db-clusters --db-cluster-identifier <id> returns an empty DBClusterMembers: [] array, OR the analyzer returns skipped: true, the cluster EXISTS but has no compute — you CANNOT run a commitment-pricing analysis on it.

See [skipped-cluster.md](commitment-pricing-skipped-cluster.md) for the cluster-name heuristic (treat empty / no-instances / limitless identifiers as skipped), the causes (paused, mid-migration, Aurora Limitless), the required response template, and the MUST NOT guardrails.

Tasks

1. Acquire Workload Parameters

Modes:

• Live single-cluster: cluster identifier, region.
• Live fleet: region.
• Offline — provisioned: instance type, number of instances, region, optional --io-optimized flag.
• Offline — Aurora serverless: average ACU (steady baseline), region, optional --io-optimized flag.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST detect Aurora serverless clusters in live mode and warn the user — only DSP applies; RIs do not
• You MUST warn that Database Savings Plans bill the committed hourly rate continuously, including during auto-pause periods — the user pays the committed rate even when the cluster is scaled to zero ACU
• You MUST recommend sizing the DSP commitment at or below average ACU usage to avoid overpaying during low-usage or auto-pause periods
• You MUST confirm captured parameters before running the analyzer
• You SHOULD ask about the user's confidence horizon (1 vs 3 years) — it shapes the recommendation

2. Run the Analyzer

Constraints:

• You MUST use the script; RI and DSP math (including I/O-Optimized premium allocation) is non-trivial and must be handled consistently
• You MUST pass --region matching the workload's region
• You SHOULD prefer --format json when post-processing and --format table for direct user display

# Live single cluster
python scripts/commitment_pricing_analyzer.py --cluster my-cluster --region us-east-1

# Fleet
python scripts/commitment_pricing_analyzer.py --all --region us-east-1

# Offline provisioned
python scripts/commitment_pricing_analyzer.py offline \
  --instance db.r7g.2xlarge --num-instances 2 --region us-east-1

# Offline Aurora serverless (DSP only)
python scripts/commitment_pricing_analyzer.py offline \
  --serverless --avg-acu 8 --region us-east-1

3. Handle Skipped Clusters

The analyzer returns skipped: true for clusters with no DB instances (last writer/reader deleted, or Aurora Limitless) — no compute to commit to. An auto-paused scale-to-zero serverless instance still appears in the cluster and is analyzable; it is not an empty cluster.

Constraints:

• You MUST surface skipped clusters to the user with the script's reason string
• You MUST NOT attempt to force a commitment comparison on a skipped cluster
• You SHOULD direct Aurora Limitless users to its CU-based pricing model (outside RI/DSP scope)

4. Interpret Coverage Limits

Constraints:

• You MUST surface the script's notes array to the user — these are the most common misconceptions
• You MUST NOT claim DSP savings for an instance family the analyzer marks as ineligible (r6g, r5, and older) because DSP only covers latest-gen families
• You MUST explain the I/O-Optimized RI vs DSP math honestly — both RI and DSP cover the full I/O-Optimized instance-hour price (base + 30% premium). With RIs, an I/O-Optimized instance consumes ~1.3x the normalized RI units of the equivalent Standard instance, so you buy ~30% more RI units (size flexibility rounds fractions) to fully cover it — no portion is forced to on-demand. DSP covers I/O-Optimized automatically and is family-agnostic, so it needs no extra-unit calculation. That operational simplicity — not a coverage gap in RIs — is why DSP is often the easier commitment vehicle for I/O-Optimized fleets.

5. Present Results

Every comparison MUST include:

1. A row-by-row table: On-Demand, 1yr RI (best payment option), 3yr RI, 1yr DSP 2. Each row's monthly cost, savings vs On-Demand in both dollars AND percentage, upfront payment, and term length 3. A clear recommendation with the winning option and reasoning 4. Tradeoffs relevant to the decision (family lock-in, cash flow, upgrade plans) 5. The script's notes when present (DSP ineligibility, I/O-Optimized interaction)

Constraints:

• You MUST cite both dollar and percentage savings for each option
• You MUST show upfront payment when non-zero — it is a material cash-flow consideration
• You MUST NOT run any purchase API because this workflow estimates, not commits
• You MAY reference the AWS console path for users who want to proceed (RDS → Reserved Instances, or Billing → Savings Plans)

6. Scenario Guidance

For workload-pattern questions (steady vs variable, fleet mix, migration horizon), pull guidance from scenarios.md.

Constraints:

• You SHOULD match the user's workload to a scenario in the reference and explain why
• You MUST NOT recommend 3yr terms for workloads the user indicates may be retired or migrated within the term

Troubleshooting

See worked-examples.md §Troubleshooting for common failure modes: cluster-not-found, empty offerings, 3-year DSP requests, DSP-ineligible families, over-baseline commits, and max-capacity=0 auto-pause warnings.

Deep-Dive References

Run the analyzer when shell is available; otherwise compute inline using the references below.

• skipped-cluster.md — no-compute heuristic, required response template, MUST NOT guardrails.
• mechanics.md — DSP-vs-RI family coverage table, Aurora us-east-1 discount-rate table, savings formula, serverless + DSP gotchas. Offline rates: ../serverless-advisory/formulas-and-examples.md §Provisioned compute pricing.
• worked-examples.md — three agent response patterns plus Troubleshooting.
• basics.md — RI vs DSP mechanics, size flexibility, payment options, coverage limits.
• scenarios.md — workload-pattern scenarios plus a decision tree.

Inline Formulas and Coverage Tables (when you can't run the script)

Back to instructions.md. See also basics.md and worked-examples.md.

Run python3 scripts/commitment_pricing_analyzer.py ... if shell is available; otherwise compute inline using the tables and rules below.

DSP instance-family coverage

Critical fact: Database Savings Plans do NOT cover every Aurora instance family. RIs cover everything; DSP is restricted.

When a user has an ineligible family (r6g, r6i, r5, r4, r3, or burstable), you MUST definitively state that DSP does not cover it — don't hedge with "may not be available." And you MUST recommend migration to r7g or r8g specifically as a way to unlock DSP flexibility, because size-flex within a DSP commitment is one of its biggest value props.

Commitment discount rates (Aurora, us-east-1, approximate)

These are conservative scenario estimates and sit below AWS's published maxima (RDS/Aurora RIs reach up to ~45% on 1-year and up to ~66% on 3-year terms — see Aurora pricing). Use live-fetched rates from the script when available.

DSP has exactly one payment option — No Upfront, 1-year term. There is no Partial/All Upfront DSP. Customers wanting to prepay can use the separate AWS Billing "advance pay" feature, which does not change the DSP discount rate. No Upfront RIs are also 1-year only; only Partial Upfront and All Upfront are purchasable for the 3-year term.

DSP size-flex advantage: a DSP commit at (say) $100/hr covers any mix of DSP-eligible Aurora instance sizes/regions totalling ≤ $100/hr of effective on-demand spend. An RI is pinned to a specific family-size-region — you can re-sell but not reassign freely. For fleet-scale or uncertain-mix workloads, DSP flexibility is worth ~5–10% even when per-unit discount is lower than RI.

Commitment savings formula

committed_monthly_cost = on_demand_monthly_cost × (1 − discount_pct)

Then absolute_savings_per_month = on_demand_monthly − committed_monthly, and savings_pct = discount_pct × 100.

For offline mode, use the on-demand rate from ../serverless-advisory/formulas-and-examples.md §Provisioned compute pricing or the DSP for Aurora serverless section below. For live mode, the script pulls rates from the AWS Savings Plans + RI Offerings APIs.

Aurora serverless + DSP: mechanics and gotchas

Aurora serverless is DSP-only (no RI). DSP for Aurora serverless has specific behavior the user needs to understand before committing:

1. DSP bills the committed `$/hr` continuously, 24/7 — including when the cluster is auto-paused at 0 ACU. If you commit $1/hr and the cluster scale-to-zeros at night, you are still billed $1/hr during that idle window. The commit is use-it-or-lose-it. 2. Therefore, size the commitment to the steady baseline ACU, NOT peak. If ACU ranges from 2 (overnight) to 20 (business hours), commit to something near the overnight baseline (2 ACU = ~$0.24/hr at us-east-1), and let the peaks run on-demand. Over-committing is a net loss. 3. Both RI and DSP cover the full I/O-Optimized instance-hour price (base + 30% premium). The difference is operational, not coverage. With RIs, an I/O-Optimized instance consumes ~1.3x the normalized RI units of the equivalent Standard instance, so to fully cover an I/O-Optimized fleet you buy ~30% more RI units of the same family (size flexibility rounds fractions to whole units) — e.g., 10 db.r6g.large Standard RIs → 13 needed → buy 3 more. No portion is left at on-demand. With DSP, coverage is automatic and family-agnostic, so there is no extra-unit step. For an I/O-Optimized fleet, DSP is often the simpler commitment because you don't have to size the +30% RI top-up — but both vehicles can fully discount the premium. 4. DSP is 1-year only for Aurora — 3-year DSP does not exist in this product. 5. RDS Proxy, logical replication, Global Database primary, Zero-ETL, and Babelfish all disable scale-to-zero, so if any of these are in play you don't need to worry about the auto-pause DSP waste — but the commit should still be sized to steady baseline, not peak, for the same waste-avoidance reason.

Commitment Pricing Decision Scenarios

Match the user's workload to one of these patterns, then recommend accordingly.

Scenario A: Steady 24/7 Production on a Fixed Family

Example: e-commerce backend on db.r7g.2xlarge, two readers + one writer, running 24/7 for the last 2 years, no plan to migrate.

Recommendation: 3yr All-Upfront RI for the writer and baseline readers. Highest savings (~55-60% off on-demand).

Watch out: If you might migrate to r8g before the term ends, the RI doesn't transfer — you'd be paying for unused r7g capacity. In that case, 1yr RI or DSP is safer.

Scenario B: Steady Production but Want Flexibility

Example: Stable workload, but the team is actively evaluating newer instance generations and may switch within 12-18 months.

Recommendation: 1yr DSP. Covers Gen-7 and newer Aurora instance families (does NOT cover r6g/r5 or older — use RIs for those). Up to ~20% discount on provisioned instances (up to ~35% on serverless). Family-agnostic within the Gen-7+ set; you keep the freedom to switch generations or move to serverless mid-term.

Scenario C: Highly Variable Workload (Provisioned)

Example: Batch processing jobs that run 8 hours/day, 5 days a week. Effective utilization ~24%.

Recommendation: Stay on-demand, or consider switching to Aurora serverless. RI break-even is ~40-50% utilization — below that, commitments cost more than on-demand. If a migration to serverless is viable, the auto-scale-to-zero benefit often beats any commitment.

Scenario D: Aurora serverless

Example: Aurora serverless cluster, min 2 ACU / max 32 ACU, averaging 6 ACU over the month.

Recommendation: RIs don't apply. Compare 1yr DSP (on the average ACU commitment) vs on-demand. DSP typically saves 20-30% on ACU-hours. Only commit to the baseline ACU level you're confident will be consumed 24/7 — the hourly $/hr commitment bills whether you use it or not.

Scenario E: Mixed Fleet Across Families

Example: 10 clusters, mix of r6g (legacy), r7g (new), and serverless.

Recommendation: Hybrid.

• RI on the r6g instances (DSP doesn't cover r6g)
• DSP covers the r7g clusters AND the serverless ACU usage
• Migrate r6g → r7g over time, shift more commitment to DSP

Model each segment separately in the analyzer. A single account-wide DSP can span the new-gen provisioned + serverless portions, while RIs cover the legacy fleet.

Scenario F: I/O-Optimized Cluster

Example: Production cluster on db.r7g.4xlarge using Aurora I/O-Optimized (30% compute premium).

Recommendation: Both RI and DSP can discount I/O-Optimized compute. RIs apply to the full I/O-Optimized rate, but I/O-Optimized consumes ~30% more normalized units per hour than Aurora Standard, so to fully cover an I/O-Optimized cluster with RIs you must purchase ~30% more reserved units (or rely on RI size flexibility). DSP covers I/O-Optimized ACU/compute usage automatically without that extra step and stays family-agnostic, which is often simpler for I/O-Optimized fleets — run the numbers; the analyzer accounts for the 1.3x factor when you pass --io-optimized.

Scenario G: Workload Planned for Retirement / Migration

Example: App being migrated off Aurora to DynamoDB / Redshift within 6-12 months.

Recommendation: No commitment. RI and DSP are use-it-or-lose-it for the full term. The break-even point on a 1yr commitment assumes full-term usage; shutting down at month 8 wastes 4 months of commitment.

Quick Decision Tree

Is the cluster Aurora serverless?
├── YES → Only DSP. Compare DSP 1yr vs on-demand.
└── NO
    ├── Is utilization < 40%? → Stay on-demand (or move to serverless)
    ├── Is the instance family r6g / older?
    │   ├── YES → RI only (DSP doesn't cover). 1yr vs 3yr based on confidence.
    │   └── NO → Compare RI vs DSP. DSP if flexibility matters, 3yr RI if locked in.
    └── Is the cluster I/O-Optimized? → Lean DSP for simplicity; if using RI, buy ~30% more reserved units (or use size flexibility) since I/O-Optimized consumes 1.3x normalized units.

Sizing the Commitment

Never commit to more than your steady baseline. A cluster that runs at 10 ACU most of the time but spikes to 40 should commit only to 10 ACU worth of DSP — the spikes can stay on-demand.

For RIs, commit to instances that run 24/7 (the writer always, long-lived readers). Do not RI a reader that's torn down during off-hours.

Skipped Cluster (no DB instances, skipped: true)

Back to instructions.md.

Critical edge case: cluster has no DB instances (skipped: true)

Before running ANY analysis on a specific cluster, check whether it has DB instances attached. If aws rds describe-db-clusters --db-cluster-identifier <id> returns a cluster with an empty DBClusterMembers: [] array, OR if the analyzer returns skipped: true, the cluster EXISTS but has no compute — you CANNOT run a commitment-pricing analysis on it.

Cluster-name heuristic: when the user's cluster name implies a skipped case

If the user's prompt signals a cluster with no DB instances — substrings like `empty`, `no-instances`, or `limitless` in the identifier, or prose saying the cluster's instances were deleted, it's an Aurora Limitless cluster, or it otherwise has no compute — treat the prompt as a `skipped: true` scenario and produce the response template below even if a live-mode lookup would not have found the cluster. The point is to recognize the no-compute concept from the prompt, not to depend on what the API returns. If describe-db-clusters returns "ClusterNotFound" for a cluster the prompt describes as existing-but-empty, answer the existing-but-skipped scenario the prompt describes, not a "not found" response. (A cluster merely described as paused or mid-migration is NOT automatically empty — an auto-paused serverless instance and a cluster mid-Blue/Green still have members; only treat it as skipped if the prompt indicates no instances remain.)

Common causes of the skipped result

• Paused Aurora cluster: the last reader/writer was deleted (manually or by cleanup automation). Storage remains. Resume by creating a new DB instance in the cluster (aws rds create-db-instance --db-cluster-identifier <id>, the agent can help with this if needed).
• Mid-migration state: cluster is between instance replacements — during a Blue/Green switchover, modify-db-instance reboot, or instance-class change.
• Aurora Limitless cluster: billed in Aurora Capacity Units (ACUs, ~2 GiB each, billed per second), not instance classes. RI and DSP do not apply in the same way; Limitless has its own ACU-based pricing model (and is locked to I/O-Optimized storage). Detect by EngineVersion containing -limitless.

Required response template

You MUST respond using this template (specific wording matters):

"I ran the analyzer against your cluster <cluster_id> in region <region>. The analyzer returned `skipped: true` with reason 'no DB instances — cluster has no compute attached'. This is different from 'cluster not found' — the cluster exists, but it has no DB instances attached, which usually means one of:

>

- Paused cluster — no reader/writer provisioned. Storage exists, but nothing to price. Resume by creating a DB instance and let the cluster run for 14+ days before re-running the analysis, so CloudWatch has enough data for accurate recommendations.

- Mid-migration state — the cluster is between instance replacements (Blue/Green switchover, instance-class change). Wait for the migration to complete, then re-run.

- Aurora Limitless — Limitless is billed in Aurora Capacity Units (ACUs, per second), which doesn't use the provisioned-instance RI/DSP model. The standard commitment-pricing workflow doesn't apply; see the Aurora Limitless pricing documentation instead.

>

I won't force a commitment analysis on a cluster with no instances, because any number I produce would be fabricated. Let me know which of the above applies and I can guide the next step. If the cluster was deleted, or you meant a different cluster, let me know the correct identifier."

You MUST NOT:

• Claim the cluster doesn't exist (the API returned it — skipped: true is not ClusterNotFound).
• Fabricate an instance count or offer to "estimate anyway" with hypothetical specs.
• Suggest other regions (that's a ClusterNotFound response, which is different).
• Silently drop the cluster from fleet totals without flagging it.

Worked Examples

Back to instructions.md. Pricing rules and tables are in mechanics.md.

Worked example — DSP for Aurora serverless

User: Aurora serverless, ~6 ACU average. Would an RI or savings plan save money?

Agent response pattern:

1. Announce reference: "Loading references/commitment-pricing-instructions.md for the commitment-pricing workflow." 2. Critical fact first: Reserved Instances do NOT apply to Aurora serverless. Only DSP applies, and only 1-year DSP (no 3-year DSP for Aurora). 3. Print the script command:

    python3 scripts/commitment_pricing_analyzer.py offline \
      --serverless --avg-acu 6 --region us-east-1

4. Compute inline:

• On-demand: 6 × $0.12 × 730 = $526/mo compute.
• 1-year DSP No Upfront — DSP's only payment option (serverless reaches up to ~35% off; actual rate varies by usage type per the DSP pricing page): at the ~35% serverless ceiling, $526 × 0.65 ≈ $342/mo, saving ~$184/mo, ~35%. There is no Partial/All Upfront DSP.

5. Size-warning: DSP charges the committed $/hr continuously, including during auto-pause. Your "6 ACU average" should be interpreted as steady baseline — if actual usage drops to 0 ACU for long stretches (overnight, weekends), the commitment is wasted on paused hours. Consider committing to the steady-baseline ACU (probably closer to 2–3 if your workload auto-pauses), and let peaks run on-demand. 6. Recommendation: 1-year DSP No Upfront at 2 ACU baseline if the cluster auto-pauses, or 1-year DSP No Upfront at 6 ACU if it runs steady 24/7 (No Upfront is DSP's only payment option). Don't over-commit.

Worked example — DSP-ineligible family

User: "4 Aurora clusters on db.r6g.xlarge. What commitments make sense?"

Agent response pattern:

1. Announce reference: "Loading references/commitment-pricing-instructions.md." 2. Print the script command even though we'll compute inline:

    python3 scripts/commitment_pricing_analyzer.py offline \
      --instance db.r6g.xlarge --num-instances 4 --region us-east-1

3. Critical fact first: DSP does NOT cover db.r6g. Per the coverage table above, r6g is DSP-ineligible. RI is the only commitment option for this family today. 4. Compute inline — on-demand: 4 × $0.58 × 730 = $1,694/mo.

• 1-year RI All Upfront (~30%): $1,694 × 0.70 = $1,186/mo. Upfront ≈ $14,222. Saves $508/mo, ~30%.
• 3-year RI All Upfront (~55%): $1,694 × 0.45 = $762/mo. Upfront ≈ $27,432. Saves $932/mo, ~55%.

5. Migration recommendation: if you're willing to migrate to db.r7g.xlarge (roughly 10% more expensive on-demand — ~$467/mo each vs $423 — but ~15% more performant, and DSP-eligible), DSP unlocks size-flex so you could reshape without losing the commit. That flexibility is typically worth ~5–10% on a 1–3 year horizon for fleets that change over time. 6. Recommendation: if the fleet is stable and will stay on r6g, 3-year RI All Upfront for the largest savings (55%). If the fleet composition might change within 1-3 years, migrate to r7g first and then take a 1-year DSP. Do not wait for DSP on r6g — it is not on the roadmap.

Worked example — commitment on a single cluster

User: "Should I buy reserved instances for my Aurora cluster analytics-cluster in us-west-2? 2× db.r7g.2xlarge running 24/7."

Agent response pattern:

1. Announce reference: "Loading `references/commitment-pricing-instructions.md` — this is the commitment-pricing workflow." Naming the path makes the routing decision explicit to the user. 2. Print the script command:

    python3 scripts/commitment_pricing_analyzer.py offline \
      --instance db.r7g.2xlarge --num-instances 2 --region us-west-2

3. Compute inline (us-west-2 ≈ 1.15× us-east-1):

• On-demand: 2 × $1.28 × 1.15 × 730 = $2,149/mo.
• 1-year RI All Upfront (~30%): $1,504/mo — saves $645/mo, ~30%.
• 3-year RI All Upfront (~55%): $967/mo — saves $1,182/mo, ~55%.
• 1-year DSP No Upfront — DSP's only payment option (provisioned ceiling up to ~20%): $2,149 × 0.80 ≈ $1,719/mo — saves ~$430/mo, ~20%; smaller per-unit discount than the RI options here, but with size-flex (can reshape between r7g/r8g/serverless within commit).

4. Because the user said "running 24/7" on db.r7g.2xlarge (a DSP-eligible family), both RI and DSP apply. Recommend 1-year DSP No Upfront if the fleet may reshape (size-flex is worth the lower discount), or 3-year RI All Upfront if the fleet is stable and a 3-year lock is acceptable.

Troubleshooting

"Cluster not found". Wrong cluster ID or region. Verify with aws rds describe-db-clusters --region <region>.

Live RI/DSP fetch returns empty offerings. Instance types without published offerings, or non-standard regions. Offer offline mode, or direct the user to the AWS Savings Plans console.

User asks about 3-year DSP. A 3-year Database Savings Plan does not exist for Aurora — only 1-year. Steer them to 3yr RI if they want a longer commitment. Aurora serverless caveat: if the cluster is Aurora serverless, RIs do not apply either — 1yr DSP is the only commitment option available.

"DSP not available for this family". Instance family is older than the DSP coverage set. Explain that RI is the only commitment option for that family, and mention migration to a newer family (r7g, r8g, etc.) as a way to unlock DSP flexibility.

User wants to commit beyond their steady baseline. Push back — both RI and DSP are use-it-or-lose-it. Recommend committing to the 24/7 baseline and leaving peaks on-demand.

Aurora serverless with max-capacity=0 planned. DSP still bills the committed $/hr even during auto-pause. Warn the user before they commit.

Create Cluster

Overview

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.

Routing: Express vs Full

Express (default for PostgreSQL):

• User asks for PostgreSQL without mentioning VPC, KMS, custom params, or specific version
• Single call: create-db-cluster --with-express-configuration
• Do NOT separately specify --engine-mode, --serverless-v2-scaling-configuration, --master-username, or --manage-master-user-password

Full configuration (use when):

• User explicitly requires VPC connectivity
• User asks for Aurora MySQL (express does not support MySQL)
• User needs customer-managed KMS keys
• User needs custom parameter groups
• User needs a specific engine version
• Two calls: create-db-cluster + create-db-instance

Workflow

1. MUST load [../express-create/instructions.md](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.

2. Identify ALL incompatibility triggers in the user's request. Every match disqualifies express:

• VPC (any mention of "my VPC", VPC ID, subnet, security group, network isolation)
• Aurora MySQL (express is PostgreSQL-only)
• Customer-managed KMS (any mention of CMK, customer-managed key, custom KMS, specific KMS key ARN/ID)
• Custom parameter group (any mention of custom params, custom parameter group, named parameter group)
• Specific engine version (e.g., "version 15.4", "PostgreSQL 14.9", "PostgreSQL 16.x")

3. 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.

4. Then proceed with the chosen path:

• Express: follow the response requirements in express-create/instructions.md (state Aurora serverless, mention internet access gateway, cite AWS docs URL, state "ready in seconds")
• Full configuration: look up resources in the user's account (VPCs, KMS keys, parameter groups, security groups), present options, ask for selections

5. Confirm cluster name and region. 6. 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. 7. Execute after user confirms.

Constraints

• MUST confirm before executing
• MUST include resource tags (see Global Rules in SKILL.md)
• MUST use --with-express-configuration as a single flag (not manual construction)
• MUST NOT present express vs full as a choice to the user — pick the right one based on requirements and propose it
• MUST open the response with an explicit routing statement that names the chosen path (express or full) AND, when routing to full, names every incompatibility trigger detected. Do NOT skip the routing statement and jump straight to resource discovery.
• The routing statement is required even when the answer seems "obvious" — implicit routing (running the right workflow without saying so) leaves the user unsure which path was chosen and why
• MUST NEVER use `--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.

Connectivity: "I can't connect from my machine"

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:

1. Re-evaluate the VPC need. If none (prototype, no compliance requirement), suggest recreating with express configuration — internet-accessible via IAM auth, zero network setup. 2. Enable RDS Data API (--enable-http-endpoint) — query over HTTPS with IAM auth; no network path needed. 3. EC2 bastion with SSH tunnel — a small instance in the same VPC/subnet, port-forwarded: ssh -L 5432:<cluster-endpoint>:5432 ec2-user@<bastion-ip>, then connect to localhost:5432.

Reference files

Always load (workflow step 1):

• ../express-create/instructions.md — Express entry point: response requirements, routing, constraints

Load on demand:

• ../express-create/constraints.md — constraint catalog
• ../express-create/feature-overview.md — connectivity, multi-AZ, defaults
• ../express-create/comparison.md — express vs full comparison
• ../express-create/use-cases.md — scenarios that fit (or don't)
• ../express-create/migration.md — express ↔ full migration
• ../express-create/documentation-links.md — AWS doc links

Express vs Full Configuration — Extended Comparison

This extends the SKILL.md five-dimension table (engines, networking, capacity mode, time-to-first-query, use cases) to operational capabilities: backup and PITR, monitoring, encryption, IAM, parameter groups, lifecycle, and advanced-feature eligibility.

Cells reflect the Express configuration settings table and Limitations section. Express configuration capabilities may expand over time; where a behavior is not yet enumerated by AWS, the cell reads "Default — verify in the AWS User Guide" rather than inventing a value.

Extended comparison table

Notes and caveats

• Encryption-key control is the clearest break — Express clusters use an AWS owned key (SSE-RDS), an AWS-controlled key customers cannot view, manage, or change. This is distinct from the AWS managed key for Amazon Aurora (the account-visible aws/rds key, now legacy). Workloads needing a customer-managed KMS key (BYOK/regulated) require Full Configuration. See Encrypting Amazon Aurora resources.
• Performance Insights and Enhanced Monitoring are disabled by default in the express flow and can be enabled after creation, per the settings table. See Performance Insights, Enhanced Monitoring.
• Parameter groups are the second-biggest operational break — A workload needing a non-default shared_preload_libraries, tuned max_connections, or other custom cluster tuning signals Full Configuration is the right start. Express clusters use the Aurora default DB cluster parameter group, changeable after the create operation completes. See Aurora PostgreSQL parameters.
• Advanced features needing a VPC are unsupported — Aurora Global Database, Zero-ETL integrations, and Blue/Green deployments are explicitly excluded by the express Limitations (no VPC association). Read Replicas (local Aurora Replicas) are supported and addable after creation. Workloads needing the excluded features must use Full Configuration.
• VPC-layer observability is a non-starter by construction. No customer VPC means VPC Flow Logs, VPC security group telemetry, and NACL logs do not apply; such workloads need Full Configuration. Standard Aurora CloudWatch metrics (CPU, connections, buffer cache, latency) still work via normal channels regardless of creation flow.

Source documentation

Links not already cited inline:

• Create with express configuration: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html
• Aurora serverless: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
• IAM database authentication: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html
• Aurora Global Database: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
• Aurora Blue/Green deployments: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html
• Aurora backups: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithAutomatedBackups.html

Connecting to an Express Cluster (IAM authentication)

Express clusters use IAM-only authentication via the Internet Access Gateway. There is no master password. When the user asks how to connect or run SQL, walk them through the IAM auth token flow — do NOT offer to run SQL yourself, do NOT suggest enabling the Data API as a workaround, and do NOT try to set a master password.

Data API cannot be enabled at create time on express clusters. The create-time --enable-http-endpoint flag is incompatible with --with-express-configuration (express forces IAM-only authentication at creation). However, Data API CAN be enabled AFTER creation via ModifyDBCluster (aws rds modify-db-cluster --enable-http-endpoint). Note it does not support master username/password authentication; you must create separate database user credentials to use Data API. The recommended/primary connection method for express is a direct connection with a short-lived IAM auth token.

1. Wait for the cluster to be available. The Endpoint field is populated only when status is available:

   aws rds describe-db-clusters --db-cluster-identifier <cluster-id> --region <region> \
     --query "DBClusters[0].{Status:Status,Endpoint:Endpoint}"

Poll until Status is "available" and Endpoint is non-null.

2. Connect with an IAM auth token (recommended/primary method). The master user is postgres (configured for IAM auth automatically):

   RDSHOST="<endpoint from describe-db-clusters>"
   TOKEN=$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region <region> --username postgres)
   PGPASSWORD=$TOKEN psql "host=$RDSHOST port=5432 dbname=postgres user=postgres sslmode=require" -c "SELECT 1;"

Or in Python:

   import boto3, psycopg2
   rds = boto3.client("rds", region_name="<region>")
   token = rds.generate_db_auth_token(DBHostname=endpoint, Port=5432, DBUsername="postgres")
   conn = psycopg2.connect(host=endpoint, port=5432, database="postgres", user="postgres", password=token, sslmode="require")

3. Tokens expire in 15 minutes — the user generates a fresh token before each session or query batch. generate-db-auth-token produces a short-lived IAM token; it is not a stored credential but the secure, approved connection method. The call is the user's responsibility, not the skill's.

4. Adding additional database users: the user creates them in the database directly and configures each for IAM auth. Source: IAM database authentication for Aurora.

The skill creates the cluster and provides the connection workflow above. The skill does NOT execute SQL against the cluster — the user runs queries themselves via psql, the RDS Data API (with separately created credentials), or their application.

Aurora Express Configuration — Constraints and Limitations

Constraints below are documented in the AWS Aurora User Guide; verify current constraints before acting. Each bullet cites its source; those subject to change are marked.

Engine constraints

• Aurora PostgreSQL only — Aurora MySQL is not supported. The express path in console and CLI is PostgreSQL-only. Source: Create with express configuration (primary reference).
• Engine version is the AWS default for this flow — The express flow does not expose the full engine-version picker; verify the current default in the Aurora PostgreSQL User Guide. Versions can be upgraded later via modify. Subject to change.
• Extensions and engine features follow the selected version — Any extension or feature unavailable in the version AWS picks is unavailable in the cluster. Source: extensions. Subject to change.

Networking constraints

• No customer VPC — Express clusters are not placed in a customer VPC, subnet group, or security group. Connectivity comes from an AWS-managed layer. Source: Create with express configuration.
• AWS-managed connectivity only — The routing layer terminating PostgreSQL connections is AWS-managed and not customer-configurable; customers cannot attach, peer, or modify it. Source: same page above.
• No VPC endpoints or PrivateLink routing — VPC-dependent and unavailable here. Source: Aurora and VPC endpoints. Subject to change.
• No customer security groups — A VPC-only construct; the express flow surfaces no security-group attachment step. Source: Aurora security groups.
• No customer subnet selection — AZ placement is AWS-managed; the user does not pick subnets or AZs. Source: Aurora DB subnet groups.
• No customer route tables, NACLs, or Transit Gateway attachments — All customer-side network policy controls are VPC-dependent and do not apply. Source: Create with express configuration. Subject to change.

Capacity constraints

• Aurora serverless only during create — Express clusters are created with a serverless instance only; change it later via modify instance. Provisioned instance classes (for example, r7g.xlarge) are not selectable during create. Source: Aurora serverless User Guide.
• Default min/max ACU range — The express flow applies the AWS default serverless capacity range (verify current values); you can modify min/max during create.
• Scale-to-zero / auto-pause — Follows standard Aurora serverless pause/resume behavior; verify in the Aurora serverless auto-pause documentation. Subject to change.

Storage and backup constraints

• Aurora Standard storage at create; switchable after — At create time express clusters can only use Aurora Standard storage; Aurora I/O-Optimized is not selectable during express create. Change the storage type after creation. Source: Create with express configuration (Limitations and Express configuration settings table — "Cluster storage configuration: Aurora standard by default. Can be changed after the create operation completes.").
• Backup retention defaults — The retention window applied at creation is the Aurora default for this flow; verify in the Aurora backups User Guide. Subject to change.

Security and identity constraints

• AWS owned key for encryption at rest — Express clusters are encrypted at rest with an AWS owned key (SSE-RDS), an AWS-controlled key customers cannot view or manage; this is distinct from the AWS managed key (aws/rds). Customer-managed KMS keys (CMKs) belong to the Full Configuration flow, where the user selects a KMS key at creation. Source: Encrypting Amazon Aurora resources. Subject to change.
• IAM database authentication (REQUIRED for express) — Express clusters only support IAM authentication through the internet access gateway. The master user (postgres) is automatically configured for IAM authentication during create, and subsequent database users must be too. There is no password-based auth on the master user. See IAM database authentication for Aurora.
• No Secrets Manager / managed master user password — Express clusters do NOT support Secrets-Manager-backed master passwords. The internet access gateway only supports IAM authentication, so no password is created or stored for the master user. Do NOT use --manage-master-user-password or set a password manually on an express cluster — see Password management with AWS Secrets Manager for the full-configuration alternative.

Feature incompatibilities

• Features depending on VPC-only connectivity are unavailable — VPC endpoints, customer VPC peering, PrivateLink-only routing, and any integration requiring the cluster to be reachable from inside a customer VPC. Source: express configuration.
• Custom parameter groups — The default cluster parameter group applies at creation; apply a custom parameter group after the cluster is created. See Aurora PostgreSQL parameters.
• Customer security groups — Not applicable in the express flow (see Networking constraints).
• Aurora Global Database — NOT supported. AWS lists it among unsupported features (express clusters are not associated with a VPC). Source: Limitations.
• Aurora Zero-ETL integrations — NOT supported. A documented hard limitation (no VPC association). Source: Limitations.
• Blue/Green deployments — NOT supported. The AWS Limitations list explicitly names Blue/Green Deployments (along with Aurora Limitless, Aurora Global Database, RDS Proxy, Aurora Zero-ETL, RDS Query Editor, Database Activity Streams, Zero Downtime Patching, and Babelfish) as unsupported, since express clusters are not associated with a VPC. Source: Limitations.
• RDS Data API — Can be enabled after creation using ModifyDBCluster. However, Data API on an express cluster does NOT support master username/password authentication — you must create new user credentials in the database for Data API access. See RDS Data API User Guide.

Parity note

Express Configuration does not offer full feature parity with Full Configuration. Where the AWS documentation identifies a gap, assume the capability is unavailable in the express flow until AWS documents otherwise. Source: Create with express configuration.

Subject-to-change

The following may evolve; re-verify against the AWS User Guide before any production decision:

• Engine support (PostgreSQL only — Aurora MySQL is not supported in express)
• Engine-version default
• Default min/max ACU values
• Backup retention default
• Customer-managed KMS key availability
• Regional availability

Always verify current behavior in the AWS User Guide before relying on a specific limit.

Source documentation

All source pages are linked inline above. Additional feature pages: Aurora Global Database, Aurora Blue/Green deployments.

Aurora Express Configuration Documentation Links

Aurora Express Configuration

• Create with express configuration (primary reference): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html

Aurora serverless

• Aurora serverless User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
• Aurora serverless capacity (ACU) reference: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html
• Aurora serverless auto-pause: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html

Aurora PostgreSQL

• Aurora PostgreSQL User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html
• Aurora PostgreSQL Release Notes: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html
• Aurora PostgreSQL parameters: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Reference.ParameterGroups.html
• Aurora PostgreSQL extensions: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html

Networking, storage, and encryption

• Aurora and VPC: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.html
• Aurora storage configuration (Standard vs I/O-Optimized): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html#aurora-storage-type
• Encrypting Amazon Aurora resources: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html
• IAM database authentication: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html
• Aurora security groups: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.RDSSecurityGroups.html

Backups, monitoring, and advanced features

• Aurora backups: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/BackupRestoreAurora.html
• Creating a DB cluster snapshot: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CreateSnapshotCluster.html
• Restoring from a DB cluster snapshot: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_RestoreFromSnapshot.html
• Copying a snapshot: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CopySnapshot.html
• Performance Insights: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html
• Enhanced Monitoring: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Monitoring.OS.html
• Aurora Global Database: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
• Aurora Blue/Green deployments: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html
• Aurora zero-ETL integrations: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.html
• Aurora Data API: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html

Migration

• Aurora PostgreSQL logical replication: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html
• PostgreSQL community — logical replication: https://www.postgresql.org/docs/current/logical-replication.html
• PostgreSQL community — pg_dump: https://www.postgresql.org/docs/current/app-pgdump.html
• PostgreSQL community — pg_restore: https://www.postgresql.org/docs/current/app-pgrestore.html

AWS Database Blog

• AWS Database Blog — Aurora tag: https://aws.amazon.com/blogs/database/tag/amazon-aurora/

Subject-to-change note

Verify every URL in this directory before citing it in customer-facing material — page slugs, availability, and content can change as the feature evolves and AWS documentation is updated.

Aurora Express Configuration — Feature Overview

Response requirements

When explaining what express configuration IS, you MUST include ALL of:

1. You MUST state that it provisions an Aurora serverless cluster (not just "Aurora" or "Aurora PostgreSQL") 2. You MUST mention the internet access gateway as the connectivity mechanism (no customer VPC) 3. You MUST cite a docs.aws.amazon.com URL (e.g. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html) 4. You MUST NOT claim Aurora MySQL is supported in express configuration

---

This file expands on what SKILL.md summarizes about Aurora PostgreSQL express configuration. It is pulled into context on demand when the user digs into how the AWS-managed connectivity layer works, how multi-AZ routing is delivered without a customer VPC, or which defaults the express flow applies. Verify current behavior, defaults, and regional availability in the AWS User Guide.

Internet access gateway

Express configuration clusters replace the customary customer-VPC plumbing (VPC, subnet group, route tables, security groups, VPC endpoints) with an AWS-managed routing layer that terminates PostgreSQL wire-protocol connections on the cluster's behalf. The user picks a cluster name; AWS returns an endpoint hostname. Nothing is peered, attached, or configured at the network layer.

Functionally, this layer is a public connectivity front-end: it accepts TLS-wrapped PostgreSQL connections, routes them to the underlying Aurora serverless cluster, and handles AZ placement and failover transparently. Because it is AWS-managed, the user has no control over listen ports, cipher policy, network-layer IP allow lists, or protocol-level tuning. Authentication uses IAM database authentication only — express clusters do not support password-based authentication on the master user or Secrets Manager integration. The master user is automatically configured for IAM auth, and subsequent database users must be too.

The exact AWS documentation term for this component — "internet access gateway", "managed connectivity layer", or another name — should be confirmed in the AWS User Guide before citing it verbatim in customer-facing material. Whatever the published term, the functional model is the same: AWS-managed, multi-AZ, distributed, no customer-side config.

Because connectivity is public-internet-facing, workloads that require the cluster to be reachable only from inside a customer VPC (VPC endpoints, PrivateLink-only routing, on-prem peering via Transit Gateway, or strict egress controls) are not a fit. They belong on Full Configuration, where the cluster is placed in a customer-owned VPC and standard Aurora networking applies.

Multi-AZ routing

The managed connectivity layer is distributed across multiple Availability Zones by default. Users get AZ-level resiliency for the connection path without configuring a subnet group or selecting AZs — failover and AZ placement are handled entirely by AWS. From the application's perspective this matches the HA posture of a standard Aurora serverless cluster: clients connect to an endpoint, and the underlying topology is AWS-managed.

Because the user does not select subnets, there is nothing to tune around AZ selection, subnet CIDR ranges, or route priorities. If a workload requires precise control over AZ placement (for example, co-locating the database with application compute in a specific AZ), Full Configuration with a customer VPC and a customer-selected subnet group is the appropriate choice. Subject to change — verify current AZ-selection behavior in the User Guide.

Preconfigured defaults

Express configuration applies the following defaults. Values marked "verify in the AWS User Guide" are subject to change; check current documentation before relying on a specific value.

• Engine: Aurora PostgreSQL. The major/minor version offered is the AWS default — verify in the Aurora PostgreSQL User Guide page.
• Capacity mode: Aurora serverless with ACU-based auto-scaling. Provisioned instance classes are not selectable.
• Min / max ACU: the AWS default Aurora serverless capacity range — verify in the AWS User Guide. Applied when the user does not customize capacity; whether the express flow lets the user override them is subject to change.
• Networking: AWS-managed connectivity layer (internet access gateway). No customer VPC, subnet group, or security group is used or attachable.
• Parameter group: the default Aurora PostgreSQL cluster parameter group for the selected engine version. Changeable after creation — but swapping a cluster's parameter group is a Tier 3 / Block operation for this skill (it can break running applications), so the skill will not execute it; apply a customer-managed parameter group via the AWS Console or change-control (static parameters take effect after a reboot). See the Aurora PostgreSQL parameters User Guide page. If a workload needs non-default parameters from the outset (e.g. a custom shared_preload_libraries or tuned max_connections), that is a signal Full Configuration is the better starting point.
• Storage type: Aurora Standard at create — Aurora I/O-Optimized is not selectable during express create; it can be switched on after creation. Verify in the Aurora storage configuration User Guide page.
• Backup retention: the Aurora default for an express serverless cluster — verify in the AWS User Guide.
• Encryption at rest: enabled using an AWS-owned key (SSE-RDS), which is AWS-controlled, not viewable or manageable in your account, and cannot be modified for express clusters. This is a distinct key type from the account-visible AWS managed key (aws/rds), now a legacy option. Customer-managed KMS keys are a Full Configuration concern — verify availability in the AWS User Guide.
• Deletion protection / final snapshot: follow the Aurora defaults — verify in the AWS User Guide.

Regional availability

Express configuration is available in a subset of AWS regions that can expand over time. Do not enumerate regions inline — point users to the Create with express configuration User Guide page for the current list.

Source documentation

• Create with express configuration (primary reference): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html
• Aurora serverless: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
• Aurora PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html
• Aurora storage type (Standard vs I/O-Optimized): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-storage-type.html
• Aurora PostgreSQL parameters: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html
• AWS What's New — Aurora PostgreSQL express configuration: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-aurora-postgresql-database/

Aurora Express Configuration

Overview

Express configuration is a single-API-call provisioning path for Aurora PostgreSQL. It creates an Aurora serverless cluster fronted by an AWS-managed connectivity layer (no customer VPC).

Use this sub-skill when the user asks about creating Aurora with express configuration, evaluating fit, or comparing express vs full. The create sub-skill routes here when express is the right default; route back to create for any workload needing a customer VPC, custom KMS, custom parameters, or Aurora MySQL.

Execute commands via the AWS MCP server when connected (sandboxed, audit-logged). Fall back to the AWS CLI or shell otherwise.

Workflow

1. Determine fit

Express is the right default for Aurora PostgreSQL when ALL of these are true:

• Engine is PostgreSQL (not MySQL)
• The application can use AWS-managed connectivity (no customer VPC required)
• AWS owned key (SSE-RDS) for encryption at rest is acceptable (no customer-managed KMS)
• Default cluster parameter group is acceptable
• Default min/max ACU range is acceptable

If any fail, route to full configuration. Load use-cases.md for canonical scenarios on either side of the boundary.

2. Acquire parameters

Required: cluster identifier, region. Optional: anything else the user supplies (most defaults cannot be overridden in express).

3. Confirm before creating

State the configuration explicitly for confirmation. MUST surface:

• Aurora serverless (not provisioned)
• AWS-managed connectivity (internet access gateway, no customer VPC)
• AWS owned key (SSE-RDS) for encryption at rest
• Default ACU range (verify in AWS User Guide for current value)

Wait for explicit confirmation ("yes", "proceed", "confirmed").

4. Execute via single API call

Express is one API call. Use the AWS CLI as the primary path (the --with-express-configuration flag requires AWS CLI v2.33+); fall back to the boto3 SDK only if the environment has an older CLI.

AWS CLI (primary — requires v2.33+):

aws rds create-db-cluster \
  --db-cluster-identifier <cluster-id> \
  --engine aurora-postgresql \
  --with-express-configuration \
  --region <region> \
  --tags Key=created_by,Value=aurora-skill Key=generation_model,Value=<your-model-id>

boto3 (alternative — for environments with AWS CLI older than v2.33):

import boto3
client = boto3.client("rds", region_name="<region>")
client.create_db_cluster(
    DBClusterIdentifier="<cluster-id>",
    Engine="aurora-postgresql",
    WithExpressConfiguration=True,
    Tags=[
        {"Key": "created_by", "Value": "aurora-skill"},
        {"Key": "generation_model", "Value": "<your-model-id>"},
    ],
)

If the CLI returns Unknown options: --with-express-configuration, the installed version is too old — update the CLI (aws --version should show 2.33+) or use the boto3 fallback above.

Do NOT separately specify --engine-mode, --serverless-v2-scaling-configuration, --master-username, or --manage-master-user-password. The express flag sets all of these automatically.

5. Post-creation: enable CloudWatch log exports

After the cluster is available, enable PostgreSQL log export to CloudWatch for operational visibility:

aws rds modify-db-cluster --db-cluster-identifier <cluster-id> --region <region> \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql"]}'

These logs can contain sensitive data (query text, table/column names), so ensure the CloudWatch log group is encrypted (KMS) and access-restricted, and treat the logs as sensitive when sharing.

6. Connect using IAM authentication

Express clusters use IAM-only authentication via the Internet Access Gateway. There is no master password. When the user asks how to connect or run SQL, walk them through the IAM auth token flow — do NOT offer to run SQL yourself, suggest the Data API as a workaround, or try to set a master password. The skill creates the cluster and provides the connection workflow; it does NOT execute SQL.

Full workflow (wait-for-available, IAM token generation, Data API caveats, adding users): see connect-iam.md.

Response requirements

When explaining what express IS or proposing it for a new cluster, you MUST include ALL of:

1. State that it provisions an Aurora serverless cluster (not just "Aurora" or "Aurora PostgreSQL") 2. Mention the internet access gateway as the connectivity mechanism (no customer VPC) 3. State that the cluster will be ready in seconds 4. Cite the AWS User Guide page (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html) 5. MUST NOT claim Aurora MySQL is supported in express configuration 6. State that authentication is IAM-only — no master password. 7. Name the connection command explicitly. When you mention how the user connects after creation, you MUST name the literal command aws rds generate-db-auth-token — required even on a create/propose turn. "Connect using a short-lived IAM auth token" alone is INCOMPLETE; it must be paired with the aws rds generate-db-auth-token command name.

Constraints

• MUST NOT use express for Aurora MySQL — it is PostgreSQL-only
• MUST NOT use express when the user requires a customer VPC, customer-managed KMS, or custom parameter group
• MUST NOT enumerate AWS regions inline — point users to the AWS User Guide for regional availability and for verifying current behavior before production decisions
• MUST execute with --with-express-configuration flag, not by composing individual --engine-mode / --serverless-v2-scaling-configuration flags
• MUST NOT promise to execute SQL against the cluster — the skill provisions and walks through the IAM connection flow; the user runs SQL themselves
• MUST NOT suggest setting a master password / --manage-master-user-password, or recommend the Data API as a workaround for connection issues — express is IAM-only (see section 6). Data API is out of scope for the connect flow; only mention it if the user explicitly asks.

Routing back to full configuration

When any of these appear, route to the create sub-skill (full configuration):

• VPC, subnet group, security group, or any customer networking
• Customer-managed KMS key
• Custom cluster parameter group
• Specific engine version (express uses the AWS default)
• Aurora MySQL
• Provisioned instance class (express is Aurora serverless only)

Load comparison.md for a side-by-side feature matrix.

Reference files

• connect-iam.md — Full IAM-auth connection workflow (token generation, Data API caveats, adding users)
• feature-overview.md — AWS-managed connectivity, multi-AZ routing, preconfigured defaults
• constraints.md — Full constraint catalog with AWS doc citations (engine, networking, capacity, storage, security, feature incompatibilities)
• comparison.md — Express vs full side-by-side
• use-cases.md — Canonical scenarios that fit (or don't) express
• migration.md — Migrating between express and full configuration
• documentation-links.md — Curated AWS doc links

Source documentation

• Create with express configuration — primary reference
• Aurora serverless
• Aurora PostgreSQL

Migration Path 3: pg_dump / pg_restore

Part of Migrating off Aurora Express Configuration. Best for small datasets where a maintenance window is acceptable: dev/demo-scale migrations and one-time copies into a new cluster.

For the user to run — the skill does not execute these commands.

1. From a machine with PostgreSQL client tooling and network access to both clusters, dump the Express cluster:

   pg_dump \
     --host <express-cluster-endpoint> \
     --port 5432 \
     --username <master-user> \
     --dbname <database> \
     --format=custom \
     --file <database>.dump

2. Restore into the Full Configuration cluster:

   pg_restore \
     --host <full-config-cluster-endpoint> \
     --port 5432 \
     --username <master-user> \
     --dbname <database> \
     <database>.dump

Illustrative only. Adjust flags: --no-owner, --no-privileges, --clean, --create, --jobs N for parallel restore.

Credentials: retrieve the password from AWS Secrets Manager at run time and pass it to the client via a temporary ~/.pgpass file (chmod 600, deleted after) referenced by PGPASSFILE — do NOT use export PGPASSWORD (visible in the process environment via /proc/<pid>/environ) or inline --password. Better still, if the source cluster has IAM database authentication enabled, generate a short-lived token with aws rds generate-db-auth-token and use that instead of a long-lived password. Source: PostgreSQL pg_dump and pg_restore docs.

Considerations:

• The dump is a logical export; extensions, roles, and ownership metadata may need special handling. Use --no-owner and --no-privileges if the target has different role names.
• Large objects and sequences may need explicit handling.
• Downtime is dump + restore time, scaling roughly linearly with data size. For anything larger than a dev dataset, Path 1 or Path 2 is usually better.

Migrating off Aurora Express Configuration

This file covers moving an Aurora Express Configuration cluster to Full Configuration — for example, when the workload outgrows the public-endpoint connectivity model, or when VPC isolation, customer-managed KMS keys, or customer-owned parameter groups become requirements. There is no in-place modify operation to move an express cluster into a VPC, so migration is a data-movement story. AWS documents snapshot/PITR restore from an express cluster to a full-configuration cluster (see "Restoring a cluster created through express configuration").

Express Configuration mechanics may evolve. Verify in the AWS User Guide before migrating, especially for production-adjacent clusters.

In-place conversion

AWS provides no modify-db-cluster operation that flips an express cluster into a customer VPC — no "convert to VPC-attached Full Configuration" button or call. What AWS does document is restoring out of the express flow: a snapshot or point-in-time restore lands in a full-configuration VPC cluster by default. If AWS later publishes in-place conversion (a modify flag or wizard), update this file.

Pick the path that matches your cluster size, downtime tolerance, and connectivity:

• Snapshot-and-restore — simplest, widest applicability.
• Logical replication — lowest downtime; suitable when both clusters reach the same replication orchestrator.
• pg_dump / pg_restore — quickest for small datasets where a maintenance window is acceptable.

Path 1: Snapshot and restore

Best for most migrations, especially with a short maintenance window.

1. Snapshot the Express cluster. Source: Creating a DB cluster snapshot. 2. Stop application writes (writes after the snapshot are lost unless you add a logical-replication catch-up pass). 3. Restore the snapshot to a new Aurora PostgreSQL cluster in Full Configuration mode, in the target VPC and subnet group, with customer security groups, customer-managed KMS key, and customer parameter group as needed. Source: Restoring from a DB cluster snapshot. 4. Validate the restored cluster — connectivity, extensions, roles, data integrity. 5. Update the application's connection string to the new endpoint. 6. Decommission the Express cluster once the new cluster is stable.

KMS: an Express cluster is encrypted at rest with an AWS owned key (SSE-RDS), which customers cannot view or manage. If the target must use a customer-managed KMS key, snapshot-and-restore with a key change is the standard Aurora pattern. Source: Copying an encrypted snapshot to a different KMS key. Verify in the AWS User Guide.

Engine version: restore must target a version supported for restore from the source snapshot. The express flow applies the AWS default engine version; if the target needs a different major version, route the user to aurora-upgrade-advisor for post-restore upgrade planning.

Downtime scales with cluster size; the application is unavailable from when writes stop until cutover.

Path 2: Logical replication

Best for migrations with strict downtime targets, typically production-adjacent workloads.

1. Create the target Full Configuration cluster in your VPC, with the desired engine version, parameter group, and KMS key. 2. Set up logical replication from the Express source to the target. Two mechanisms are common with Aurora PostgreSQL:

• PostgreSQL built-in logical replication (PUBLICATION / SUBSCRIPTION, PostgreSQL 10+). Source: PostgreSQL Logical Replication documentation.
• pglogical extension. Source: Using the pglogical extension on Aurora PostgreSQL. Verify availability in the AWS User Guide.

3. Let the target catch up. Validate row counts, sequences, and non-replicated objects (DDL, large objects, certain extensions). 4. Cut over: stop source writes, wait for the target to reach the final LSN, then point the application at the target. 5. Decommission the Express cluster.

Prerequisites:

• Connectivity: the target must reach the Express cluster over its public endpoint (or vice versa), and your replication orchestrator must reach both. Because Express clusters sit behind the AWS-managed connectivity layer (not a customer VPC), network planning differs from VPC-to-VPC replication — verify in the AWS User Guide.
• Version compatibility: both clusters must run a PostgreSQL version that supports the chosen mechanism.
• Parameters: logical replication requires wal_level = logical, max_replication_slots, and max_wal_senders on the source. Whether the Express flow permits these changes is subject to change — verify in the AWS User Guide.

Downtime shrinks to the cutover moment (seconds to a few minutes), not the full data copy time.

Path 3: pg_dump / pg_restore

Best for small datasets where a maintenance window is acceptable. Full steps, commands, and considerations: migration-pgdump.md. Downtime is dump + restore time, scaling roughly linearly with data size; for anything larger than a dev dataset, Path 1 or Path 2 is usually better.

Choosing a path

When in doubt, start with Path 1: most broadly documented and fastest for most Express clusters (which tend to be small and dev-shaped).

Verify before migrating

Before executing any path, verify in the AWS Aurora User Guide:

• Whether AWS has published an in-place conversion path, new migration tooling, or wizards since this file was written.
• AWS documents this explicitly — a default restore (restore-db-cluster-from-snapshot or restore-db-cluster-to-point-in-time without EnableVPCNetworking/EnableInternetAccessGateway) lands in a full-configuration VPC cluster; restoring back to express requires VPCNetworkingEnabled=false and InternetAccessGatewayEnabled=true. Verify the restore-target constraints (engine version, KMS, storage type).
• Whether the Express cluster's parameter group can be adjusted to enable logical replication (wal_level = logical, max_replication_slots, max_wal_senders).

Do not skip verification for production-adjacent clusters. The AWS User Guide is authoritative; this file is a planning aid.

Source documentation

Links for each step appear inline above. Additional references:

• Create with express configuration: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html
• Aurora serverless: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html

Aurora Express Configuration — Worked Use Cases

This file reasons from a user's requirements to an Express-vs-Full recommendation. Each example identifies the decisive constraint or use-case fit — the single documented fact that tips the recommendation — and cites it.

Every example is grounded in the AWS Aurora User Guide and the Express Configuration announcement. Express configuration capabilities may evolve; verify the specific constraint in the AWS User Guide before making a production call.

Example 1: Dev sandbox for a PostgreSQL app

A single developer spins up a PostgreSQL database to back a service they are prototyping. No production traffic, no compliance regime, no VPC isolation required, no colleagues connecting from on-prem.

Recommendation: Express Configuration.

This matches the documented good-fit profile in the Create with express configuration User Guide page: a development sandbox where the user wants PostgreSQL in seconds without managing a VPC, subnet group, or security groups. The AWS-managed connectivity layer meets the developer's needs (public endpoint with TLS), Aurora serverless auto-scales within the default ACU range so idle cost stays low, and the cluster is reachable without any network-layer setup.

The decisive fit signal is "no VPC isolation needed" — when that changes, the recommendation flips.

Example 2: Production workload with VPC isolation

A production PostgreSQL workload for a small SaaS product. The application tier runs in a customer VPC; the database must sit in the same VPC, reachable only from the application's subnets. The team has existing security groups, a documented security posture, and VPC Flow Logs enabled.

Recommendation: Full Configuration, not Express Configuration.

Express configuration does not support customer VPC placement — clusters are not placed in a customer VPC, subnet group, or security group. Source: Create with express configuration. Any workload requiring the cluster to be reachable only from within a customer VPC, depending on security-group-based network policy, or participating in VPC Flow Logs for audit is disqualified by construction. Direct the user to Full Configuration with Aurora PostgreSQL and an appropriate subnet group / security group setup in their VPC.

The decisive fit signal is "must run inside my VPC" — one sentence on the user side, one constraint on the AWS side, and the call is clear.

Example 3: Hackathon or weekend project

Two developers start a weekend project on Friday evening. They want a PostgreSQL database up before they finish the first migration, and will throw the project away if it does not work out.

Recommendation: Express Configuration.

The documented "in seconds" provisioning model and "no infrastructure setup" property make this workload a fit. Source: Create with express configuration. No VPC to configure, no subnet group to plan, no parameter tuning — the developers focus on the project. If it grows into something production-shaped with VPC requirements, the migration paths in migration.md apply.

The decisive fit signal is "time to first query matters more than network control" — the opposite of Example 2.

Example 4: Aurora MySQL migration

A team is consolidating a MySQL 5.7 workload onto Aurora and wants the fastest path to a running cluster.

Recommendation: Not supported in Express Configuration; use Full Configuration with Aurora MySQL.

Express configuration is Aurora PostgreSQL only. Source: Create with express configuration. The engine is fixed to PostgreSQL; the user cannot pick Aurora MySQL in this flow. Direct the user to Full Configuration with the Aurora MySQL engine; for major-version upgrade planning or v2→v3 specifics, route to aurora-upgrade-advisor.

The decisive fit signal is "engine: MySQL" — a hard incompatibility with the express flow.

Example 5: Internal dev tool with SSO / IAM database authentication

An internal tool that lets employees browse data for debugging. The team wants to avoid managing passwords; SSO-backed IAM database authentication is a hard requirement.

Recommendation: Strong fit — express configuration requires IAM authentication.

Express clusters use IAM database authentication exclusively (no password auth) — the only supported method via the internet access gateway. The workload's requirement for IAM/SSO-backed auth aligns with express configuration's constraints, assuming no other VPC-isolation or engine-compatibility requirements disqualify it.

Example 6: Compliance-regulated workload (HIPAA, PCI, internal policy)

A workload processing regulated data (for example, PHI under HIPAA, cardholder data under PCI DSS, or data under an internal policy mandating customer-controlled network placement and customer-managed KMS keys).

Recommendation: Full Configuration, not Express Configuration.

Such regimes typically require customer-controlled network placement (customer VPC, security groups, VPC Flow Logs for audit) and encryption-at-rest under a customer-managed KMS key. Express configuration does not support customer VPC placement and is encrypted at rest with an AWS owned key (SSE-RDS, an AWS-controlled key customers cannot view or manage) — not a customer-managed KMS key. Sources: Create with express configuration, Encrypting Amazon Aurora resources. Both are subject to change — verify in the AWS User Guide — but as documented, the express flow's compliance posture is not a fit for this workload class.

The decisive fit signal is "customer-managed KMS key required" or "customer-controlled network placement required" — either one disqualifies the express flow.

How to apply these examples to your workload

When a user describes a workload, produce a freeform narrative recommendation and cite at least one documented constraint or use-case fit as justification. The examples above show the shape of that reasoning: identify the decisive constraint, cite the AWS source, and make the call.

When the description is ambiguous (for example, "a new app" with no mention of VPC or engine), ask one clarifying question — typically whether the workload requires VPC isolation and whether it requires Aurora MySQL. Those two questions resolve most Express-vs-Full decisions. Once clear, give the recommendation in plain prose, cite the constraint, and — if "not a fit for Express" — direct the user to Full Configuration with the specific engine or networking requirement that disqualified Express.

Source documentation

• Create with express configuration: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.html
• Aurora serverless: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
• Aurora PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html
• IAM database authentication: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html
• Encrypting Aurora resources: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html

Data Collection for I/O-Optimized Assessment

CloudWatch Metrics Used

The analyzer pulls these from the AWS/RDS namespace at cluster level:

Dimension: DBClusterIdentifier. Metrics are pulled at 1-hour granularity and summed over the lookback window.

Note on naming: Despite the name "IOPs", VolumeReadIOPs and VolumeWriteIOPs report I/O request counts per 5-minute period, not per-second rates. The script normalizes them accordingly.

Cluster Metadata from RDS API

describe-db-clusters and describe-db-instances provide:

• Current storage type (storage_type: aurora = Standard, aurora-iopt1 = I/O-Optimized)
• Instance types in the cluster (to price compute correctly)
• Engine and version (for context, does not affect pricing math)
• Allocated storage (as a validation check against CloudWatch VolumeBytesUsed)

Extrapolation for Short Windows

The analyzer extrapolates observed I/O to a 30-day (730-hour) month:

monthly_io = (observed_io / observed_hours) × 730

Minimum viable window: 7 days. Below this, Aurora workloads often miss a full weekly cycle (weekdays vs weekends can differ 3-5×), producing misleading extrapolations.

The script sets data_quality accordingly:

• < 3 days: insufficient — do not recommend a switch on this data
• 3-7 days: short — recommendation flagged as tentative
• 7-14 days: adequate — recommendation reliable
• 14+ days: good — recommendation high-confidence

Switch Cooldown: Another Reason to Wait for More Data

The 30-day limit on changing a cluster's storage type (via modify-db-cluster --storage-type) is one-directional: switching Standard (aurora) → I/O-Optimized (aurora-iopt1) is limited to once every 30 days per cluster, while reverting I/O-Optimized → Standard can be done at any time (no cooldown). So a premature switch into I/O-Optimized is not a 30-day cost lock-in — you can revert to Standard immediately. The real cost of churning is that, once you revert, you cannot re-enable I/O-Optimized again for another 30 days.

When the data_quality tag is insufficient or short, the cost of a bad decision is the one-way commitment in the Standard → I/O-Optimized direction: if you switch in on thin data and then want to switch in again after a better read of the workload, you are gated by the 30-day cooldown on that direction. Surface this cooldown to the user as part of the reasoning to wait. Do not describe the Standard → I/O-Optimized direction as freely repeatable; that direction is a meaningful commitment (reverting to Standard, by contrast, is always available).

Handling Multi-Instance Clusters

Aurora I/O-Optimized pricing applies at the cluster level. Compute cost is the sum of all instance-hours in the cluster:

compute_monthly = Σ (instance_price_per_hour × 730) for each instance in cluster

The 30% premium multiplies the full compute cost. A cluster with one writer + two readers multiplies the premium by 3× the base instance cost.

Reader-Only vs Writer-Heavy Clusters

I/O billing counts all reads and writes across all instances in the cluster — readers are billed for their reads. The analyzer sums CloudWatch volume I/O across the cluster, which already reflects this.

Aurora serverless Clusters

For Aurora serverless, the analyzer uses observed ACU-hours from ServerlessDatabaseCapacity to compute compute cost. The 30% I/O-Optimized premium applies to the ACU-hour rate, same as provisioned.

Offline Mode Inputs

When AWS credentials aren't available, the user provides:

• --instance <type> — e.g., db.r6g.2xlarge
• --num-instances <N> — total instances in the cluster
• --storage-gib <N> — cluster volume size
• --monthly-io-millions <N> — estimated monthly I/O requests in millions

The user can get monthly I/O from the Cost Explorer (filter on "Amazon Relational Database Service" + usage type containing StorageIOUsage) or from the AWS billing console line items.

Aurora I/O-Optimized Workflow

Assess whether Aurora I/O-Optimized storage is cheaper than Aurora Standard for a cluster or a region's fleet, using the AWS-documented 25% breakeven rule (I/O ≥ 25% of total cluster cost → I/O-Optimized wins). Can execute the storage switch after user confirms.

Execute commands via the AWS MCP server when connected (sandboxed, audit-logged). Fall back to the AWS CLI or shell otherwise.

When This Applies

User mentions: I/O-Optimized, aurora-iopt1, "should I switch storage type", "is I/O-Optimized worth it", "how much would I/O-Optimized save", or storage-configuration cost comparison.

Tasks

1. Acquire Target Parameters

Three modes: live single-cluster (cluster id, region, optional --days; default 14, min viable 7); live fleet (region, optional --days); offline (instance type, num instances, storage GiB, monthly I/O in millions).

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST NOT guess a cluster identifier — ask the user explicitly
• You MUST confirm the captured parameters before running the analyzer
• You SHOULD default to live mode when AWS credentials are available

2. Run the Analyzer

Constraints:

• You MUST use the script rather than hand-computing; the script fetches live CloudWatch I/O data and Pricing API rates, applies extrapolation, and handles data-quality flags
• You MUST pass --region matching the cluster's region
• You SHOULD prefer --format json when post-processing and --format table for direct user display

python scripts/io_optimized_analyzer.py --cluster my-cluster-id --region us-east-1   # single cluster
python scripts/io_optimized_analyzer.py --all --region us-east-1                      # whole fleet
python scripts/io_optimized_analyzer.py offline \
  --instance db.r6g.2xlarge --num-instances 2 \
  --storage-gib 800 --monthly-io-millions 1200                                        # offline

Add --days 30 to change the lookback window (default 14).

3. Handle Skipped Clusters

The analyzer returns skipped: true for clusters with no DB instances (Aurora Limitless, or a cluster whose last writer/reader was deleted) — no compute to price.

Constraints:

• You MUST surface skipped clusters to the user with the script's reason string
• You MUST NOT include skipped clusters in fleet dollar totals (the script already excludes them)
• You MUST NOT attempt to force a comparison on a skipped cluster

4. Interpret Data Quality

The script tags results by lookback-window coverage: insufficient (<3d, no switch), short (3–7d, tentative), adequate (7–14d, reliable), good (14+d, high-confidence). Full table and reasoning in pricing-tables.md.

Constraints:

• You MUST surface the data_quality tag when presenting a recommendation
• You MUST NOT give a confident switch recommendation when the tag is short or insufficient because weekly patterns (weekday vs weekend) can shift the result
• When the tag is short or insufficient, You MUST explicitly mention the 30-day switch cooldown as an additional reason to wait — switching Standard → I/O-Optimized is limited to once every 30 days, so acting on thin data is a 30-day commitment in that direction (reverting to Standard is allowed at any time)
• You MUST NOT describe a Standard → I/O-Optimized switch as freely reversible when the data_quality is short — that direction carries a 30-day commitment, making it a meaningful one-way door on thin data (the reverse, I/O-Optimized → Standard, can be done at any time)
• You SHOULD offer to rerun with a longer window once more data is available

5. Present Results

Every assessment MUST include: (1) side-by-side monthly cost table (Standard vs I/O-Optimized) with compute, storage, I/O line items; (2) I/O cost as a percentage of Standard total — the deciding factor; (3) recommendation: standard or io_optimized; (4) one-sentence reason tied to the 25% threshold and the dollar delta; (5) fleet runs: per-cluster table plus total "optimal mix" savings; (6) skipped clusters: explanation.

Constraints:

• You MUST cite the 25% breakeven rule in your reasoning so the user understands it
• You MUST show the dollar delta, not just the percentage
• Storage-type switch is online (no downtime) for most instance classes; clusters using NVMe/Optimized Reads instances (r6gd, r6id, r8gd) require a restart with brief unavailability — check instance classes before advising on impact. Switching Standard → I/O-Optimized is limited to once every 30 days; switching back to Standard can be done at any time.
• You MUST warn the user about the 30-day cooldown on the Standard → I/O-Optimized direction and confirm instance class before executing. If NVMe instances are present, warn about restart.
• After user confirms, execute aws rds modify-db-cluster --storage-type aurora-iopt1 via MCP tools. Alternatively, provide the full CLI command for the user to run.

Troubleshooting

See pricing-tables.md §Troubleshooting for the full list (cluster-not-found, zero I/O data, pricing-fetch failures, skipped/Limitless, near-25%-threshold cases).

Deep-Dive References

• pricing-tables.md — pricing-constant & data-quality detail tables, monthly cost formulas, skipped: true handling. Use for inline computation when you can't run the script.
• worked-examples.md — three worked examples (offline with the $1.038/hr db.r6g.2xlarge math, insufficient-data, empty-cluster).
• pricing.md — breakeven math derivation, switch mechanics, commitment-pricing interaction
• data-collection.md — CloudWatch metrics, extrapolation methodology, short-window handling

25% breakeven rule (the single most important fact)

Aurora I/O-Optimized trades a 30% compute premium for zero I/O charges and a ~125% higher storage rate ($0.225 vs $0.10 per GiB-month). It wins when I/O cost ≥ 25% of the Standard total (compute + Standard storage + Standard I/O). Tiers: < 20% → stay Standard (confident); 20–25% → stay Standard (marginal, monitor); 25–30% → borderline, re-check monthly (could flip with growth); > 30% → switch to I/O-Optimized (confident).

Run python3 scripts/io_optimized_analyzer.py ... if shell is available; otherwise compute inline using pricing-tables.md (constants + formulas) and worked-examples.md.

One-directional cooldown (canonical guidance is in the verbatim Task 4 and Task 5 MUST/MUST-NOT constraints above): the 30-day cooldown applies to the Standard → I/O-Optimized direction only; reverting to Standard is allowed at any time. Lookback-window detail is in pricing-tables.md.