feat(backups)!: Remove stack-level support for configuring DevX Backups

[jacobwinch]

What does this change?

BREAKING CHANGE: DevX Backups can no longer be enabled via the withBackup prop, which has been removed.

Users should now opt-in/out of DevX Backups at the construct level (i.e. when defining an RDS instance, cluster or DynamoDB table).

We recommend using the GuDatabaseInstance or GuDynamoTable to help with this. If these constructs cannot be used, resources can also be tagged like this: Tags.of(myDatabase).add("devx-backup-enabled", "true").

---

Originally we thought that opting-in/out of DevX Backups at the stack-level would be convenient (#2098).

However, the process for opting-in/out of RDS instance backups is more complex than expected (it relies on several properties being configured correctly, not just the tagging), so we have decided to manage this feature at the construct-level rather than the stack-level. Although the stack-level setting works quite well for DynamoDB, we think that it's confusing to manage this feature at two different levels, so have decided to favour consistency and use construct-level opt-in/out for all resource types.

I think managing backups at the construct level also slightly helps in the (admittedly rare) case where different tables or instances in the same stack have different backup requirements.

How to test

N/A - PR only contains deletions.

How can we measure success?

We will have a standardised way to opt-in/out of DevX Backups (at the construct level) and there is less code to maintain.

Have we considered potential risks?

There is a risk that users who already rely on the withBackup prop will not add the tag correctly (via other approaches described in the release notes) when upgrading GuCDK.

This is mitigated by:

a) Snapshot tests (which will show the tag being removed)
b) DevX Backup Monitoring (which will notify users if backups stop)

Checklist

• I have listed any breaking changes, along with a migration path ¹
• I have updated the documentation as required for the described changes ²

Footnotes

1. Consider whether this is something that will mean changes to projects that have already been migrated, or to the CDK CLI tool. If changes are required, consider adding a checklist here and/or linking to related PRs. ↩

2. If you are adding a new construct or pattern, has new documentation been added? If you are amending defaults or changing behaviour, are the existing docs still valid? ↩

[changeset-bot]

🦋 Changeset detected

Latest commit: 6fa0d16

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@guardian/cdk	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[michaelwmcnamara]

Great work!