Support Aurora PostgreSQL Express configuration / RDS IAM authentication for SQL data sources

[fossamagna]

Describe the feature you'd like to request

Amplify Data currently supports SQL data sources through generated SQL schemas and AppSync/SQL Lambda runtime infrastructure. This works well for password-based PostgreSQL/MySQL connections, including RDS databases with VPC configuration.

However, Aurora PostgreSQL Express configuration introduces a different setup:

• the database is still an Aurora PostgreSQL / RDS database;
• it not use user-managed VPC networking;
• database access relies on RDS IAM database authentication rather than a static database password.

For this setup, the current runtime assumptions are not sufficient. The SQL Lambda needs to connect using an RDS IAM auth token, and the generated infrastructure needs to support a SQL database without VPC configuration.

This is related to a companion metadata/API change in @aws-amplify/data-schema (aws-amplify/amplify-data#727) , where generated SQL schemas could express the database authentication strategy, for example:

configure({
  database: {
    identifier: "...",
    engine: "postgresql",
    connectionUri: secret("SQL_CONNECTION_STRING"),
    authentication: {
      strategy: "rdsIam"
    }
  }
})

This issue focuses on the amplify-category-api side: consuming that metadata and configuring the SQL runtime accordingly.

Describe the solution you'd like

I would like amplify-category-api to support SQL data sources that use RDS IAM authentication and do not require VPC configuration.

When the SQL database metadata indicates RDS IAM authentication, for example:

authentication: {
  strategy: "rdsIam"
}

the generated runtime should:

• allow PostgreSQL connection URIs without a static password;
• create the SQL Lambda without VPC configuration when no vpcConfig is provided;
• generate an RDS IAM auth token at runtime, for example using @aws-sdk/rds-signer;
• use the generated IAM auth token as the PostgreSQL password;
• grant the SQL Lambda execution role the required rds-db:connect permission;
• refresh or regenerate the IAM auth token when needed, especially after authentication failures caused by token expiration;
• preserve the existing password-based behavior when no RDS IAM authentication metadata is provided.

For example, a passwordless connection URI should be valid when RDS IAM auth is configured:

postgres://postgres@my-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com:5432/postgres

At runtime, the SQL Lambda should parse the host, port, database name, and username from the URI, generate an IAM auth token, and use that token to connect to PostgreSQL.

The IAM permission should include rds-db:connect for the configured database user. For Aurora PostgreSQL clusters, this likely needs to use the RDS DB resource ID, for example:

arn:aws:rds-db:<region>:<account-id>:dbuser:<db-resource-id>/<db-user>

This should be implemented in a backward-compatible way. Existing password-based SQL data sources should continue to work unchanged.

Describe alternatives you've considered

One alternative is to treat Aurora PostgreSQL Express configuration as an external PostgreSQL database.

However, that does not solve the authentication problem. The SQL Lambda still needs to generate and refresh RDS IAM auth tokens, and a static password-based connection URI is not sufficient.

Another alternative is to require users to manually patch the generated Lambda, IAM policy, or CloudFormation/CDK resources.

However, this would not provide a stable Amplify workflow and would be overwritten or broken by future generated backend updates.

Another alternative is to encode IAM authentication into the connection URI, for example:

postgres+iam://postgres@hostname:5432/database

However, runtime behavior should ideally be driven by explicit database metadata from the generated schema, such as:

authentication: {
  strategy: "rdsIam"
}

This is clearer, easier to validate, and easier to keep backward-compatible.

Additional context

This feature is motivated by supporting Aurora PostgreSQL Express configuration with Amplify Data.

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request

Would this feature include a breaking change?

• ⚠️ This feature might incur a breaking change