Skip to content

feat(docdb): support per-instance maintenance window on DatabaseCluster#38315

Open
gudipati wants to merge 1 commit into
mainfrom
fix/issue-30391-docdb-instance-maintenance-window
Open

feat(docdb): support per-instance maintenance window on DatabaseCluster#38315
gudipati wants to merge 1 commit into
mainfrom
fix/issue-30391-docdb-instance-maintenance-window

Conversation

@gudipati

Copy link
Copy Markdown
Contributor

Issue # (if applicable)

Closes #30391.

Reason for this change

Docdb DatabaseCluster only forwards preferredMaintenanceWindow to the underlying cluster resource. The auto-created instance resources never receive a maintenance window, so by default a random 30-minute window is selected per instance, causing surprise maintenance events outside the user's chosen window. Adding support for users to provide specific maintenance window for instances created in the cluster.

Description of changes

Adds a new optional instanceMaintenanceWindow property to DatabaseCluster. When set, every auto-created instance is assigned that value as its PreferredMaintenanceWindow. The cluster-level preferredMaintenanceWindow is unchanged and continues to apply only to the cluster.

Describe any new or updated permissions being added

N/A — no IAM or other permission changes.

Description of how you validated changes

Unit tests and Integration tests succeeded

Checklist

@github-actions github-actions Bot added effort/small Small work item – less than a day of effort feature-request A feature should be added or improved. p2 valued-contributor [Pilot] contributed between 6-12 PRs to the CDK labels Jul 15, 2026
@aws-cdk-automation
aws-cdk-automation requested a review from a team July 15, 2026 12:49
@mergify mergify Bot added the contribution/core This is a PR that came from AWS. label Jul 15, 2026
@mergify
mergify Bot temporarily deployed to automation July 15, 2026 12:50 Inactive
@mergify
mergify Bot temporarily deployed to automation July 15, 2026 12:50 Inactive
@aws-cdk-automation aws-cdk-automation added the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Jul 15, 2026
* occurring on a random day of the week.
* @see https://docs.aws.amazon.com/documentdb/latest/developerguide/db-instance-maintain.html#maintenance-window
*/
readonly instanceMaintenanceWindow?: string;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this more ergonomic, along the lines of the various Schedules we have across the codebase? So the user can declare a window like MaintenanceWindow.startingAt('tue:04:17') or something like that?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although something like MaintenanceWindow might be more ergonomic, I think it might be better to keep it consistent with preferredMaintenanceWindow (cluster maintenance window) in docdb and maintenance window implemented in RDS. What are your thoughts ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yes, it would be inconsistent, unless we deprecated preferredMaintenanceWindow and created a more type safe one. But that's a bigger lift, and probably not worth it. But can we at least validate that the string matches the expected pattern?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contribution/core This is a PR that came from AWS. effort/small Small work item – less than a day of effort feature-request A feature should be added or improved. p2 pr/needs-maintainer-review This PR needs a review from a Core Team Member valued-contributor [Pilot] contributed between 6-12 PRs to the CDK

Projects

None yet

Development

Successfully merging this pull request may close these issues.

(aws_docdb): (Propogate maintenace window settings to cluster's instances)

3 participants