fix(infra): increase curated-corpus-api Aurora backup retention to 7 days (HNT-2677)

[mmiermans]

Goal

The prod curated-corpus-api Aurora cluster had no backupRetentionPeriod set, so it used the AWS default of 1 day, resulting in a single automated backup. This PR raises it to 7 days such that we have more time to recover data, in case data corruption is not immediately apparent. Dev stays at 1 day.

Deployment steps

This can simply be merged in, without any service interruption.

Important
An outage occurs if you change the backup retention period of a DB instance from 0 to a nonzero value or from a nonzero value to 0.

Source: Backup retention period — Amazon RDS User Guide

References

JIRA ticket:

• https://mozilla-hub.atlassian.net/browse/HNT-2677

[claude]

Claude finished @mmiermans's task in 1m 13s —— View job

---

Code Review: Aurora backup retention

• Read PR diff and changed files
• Verify config wiring into the RDS cluster
• Check for prop validity / repo conventions
• Post review

---

Reviewed the diff against origin/main. The change is small, correctly wired, and safe to deploy. One discrepancy is worth resolving before merge.

🟡 Title/description say "4 days" but the code sets 7

The PR title and body describe raising prod retention to 4 days, but the implementation uses 7:

// infrastructure/curated-corpus-api/src/config/index.ts:25-29
// ... 7 days gives more time to recover ...
backupRetentionPeriod: isDev ? 1 : 7,

The commit message (...to 7 days) and the inline comment agree on 7, so the code is internally consistent — only the PR title/description still say 4. Please reconcile so the merge commit/PR record is accurate. If 7 is the intended value, just update the PR title/description; if 4 is intended, update the code.

Fix this →

✅ Looks good

• Wiring is correct. backupRetentionPeriod is read from config.rds and passed into the rdsConfig of ApplicationRDSCluster (main.ts:164), consistent with how minCapacity/maxCapacity are handled.
• Dev unchanged at 1 day, matching the AWS default — so the dev cluster avoids the no-op apply and the stated goal of "Dev stays at 1 day" holds.
• No 0↔nonzero transition. The PR body correctly notes that prod was previously unset (AWS default of 1, a nonzero value), so this is a 1→7 change. That avoids the outage that AWS warns about for 0↔nonzero transitions. 👍
• Good inline comment explaining the rationale and referencing the ticket.

Minor notes (non-blocking)

• I couldn't verify locally that the pocket-tools rdsConfig type accepts backupRetentionPeriod (node_modules isn't installed in this CI checkout). It maps to the standard aws_rds_cluster.backup_retention_period argument, so it should be valid — but rely on the tsc/build step in CI to confirm the prop is accepted by ApplicationRDSCluster's config type.
• Consider whether the longer PITR window has any cost implications worth a one-line note, though for a 1→7 day change on a single cluster this is negligible.

Overall: ✅ approve once the 4-vs-7 wording is reconciled.
· HNT-2677-increase-corpus-aurora-backup-retention

[github-actions]

Plan Result (curated-corpus-api-cdk-production)

CI link

Plan: 0 to add, 1 to change, 0 to destroy.

• Update
  • aws_rds_cluster.rds_rds_cluster_1A0399FD

Change Result (Click me)

  # aws_rds_cluster.rds_rds_cluster_1A0399FD will be updated in-place
  ~ resource "aws_rds_cluster" "rds_rds_cluster_1A0399FD" {
      ~ backup_retention_period               = 1 -> 7
        id                                    = "curatedcorpusapi-prod20210927235441510200000001"
        tags                                  = {
            "app_code"       = "pocket-content-shared"
            "component_code" = "content-curatedcorpusapi"
            "env_code"       = "prod"
            "environment"    = "Prod"
            "service"        = "CuratedCorpusAPI"
        }
        # (43 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.