restore_db_cluster_to_point_in_time fails when trying point in time restore from source Aurora PostgreSQL cluster with advanced Database Insights mode

[AgasiAm]

Describe the bug

When performing a point-in-time restore of an Aurora PostgreSQL cluster using restore_db_cluster_to_point_in_time, if source cluster Database insights mode is advanced or/and performance Insights configured in cluster level, the operation fails with error botocore.exceptions.ClientError: An error occurred (InvalidParameterCombination) when calling the RestoreDBClusterToPointInTime operation: You can enable Performance Insights or set the Enhanced Monitoring interval only when restoring from a source Aurora Limitless DB cluster

For now, I’m able to successfully perform a point-in-time restore or clone only by removing all of the following parameters from the request payload:

• MonitoringRoleArn
• MonitoringInterval
• EnablePerformanceInsights
• PerformanceInsightsRetentionPeriod

Including any of these parameters—regardless of their values—causes the operation to fail with an InvalidParameterCombination error. This behavior seems inconsistent with the expected API logic

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

The operation should successfully create a new Aurora PostgreSQL cluster with monitoring features configured according to the values provided in the request payload. If parameters like MonitoringRoleArn, MonitoringInterval, EnablePerformanceInsights, or PerformanceInsightsRetentionPeriod are included, they should be applied as specified—without causing an InvalidParameterCombination error

Current Behavior

The restore_db_cluster_to_point_in_time operation fails with an InvalidParameterCombination error whenever any of the following parameters are included in the request payload, regardless of their values:

• MonitoringRoleArn
• MonitoringInterval
• EnablePerformanceInsights
• PerformanceInsightsRetentionPeriod

The only way to successfully perform the point-in-time restore or clone is to completely omit these parameters from the request.

Reproduction Steps

N/A

Possible Solution

No response

Additional Information/Context

No response

SDK version used

1.40.47

Environment details (OS name and version, etc.)

Ubuntu 20.04

[RyanFitzSimmonsAK]

Hi @AgasiAm, thanks for reaching out. I did some testing, and I was able to reproduce this behavior. However, after searching internal tickets, the error message appears to be correct and this restriction is expected behavior. I've reached out to the RDS team about adding this restriction to documentation. Please let me know if you have any other questions.

Ticket # for internal use : P317302391