Setting the file. One moment.
Skill 62 · Amazon Aurora PostgreSQL
Subchapter 62.12
references/express-create-feature-overview.mdMarkdown7 KBView on GitHub
When explaining what express configuration IS, you MUST include ALL of:
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.
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.
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.
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.
shared_preload_libraries or tuned max_connections), that is a signal Full Configuration is the better starting point.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 (opens in a new tab) User Guide page for the current list.