Closed jacobwinch closed 10 months ago
mobile-n10n:eventconsumer
to CODEmobile-n10n:schedule
to CODEmobile-n10n:football
to CODEmobile-n10n:reportextractor
to CODEmobile-n10n:fakebreakingnewslambda
to CODEmobile-n10n:report
to CODEmobile-n10n:notification
to CODEmobile-n10n:slomonitor
to CODEmobile-n10n:registration
to CODEmobile-n10n:notificationworkerlambda
to CODEAfter the PR is merged the dynamo.yaml template (which contains the mobile-notifications-reports-
table) needs to be applied manually.
This is working in PROD
:
What does this change?
This PR allows us to start backing up the
mobile-notifications-reports-<stage>
andmobile-notifications-football-notifications-<stage>
DynamoDB tables using https://github.com/guardian/aws-backup.For more details on this project see this doc and this audit that @guardian/devx-reliability have been working on with Heads of Engineering & EMs.
How to test
mobile-notifications-football-notifications-<stage>
is deployed via Riff-Raff, so I have tested this by deploying toCODE
:mobile-notifications-reports-<stage>
seems to be deployed manually (i.e. not via Riff-Raff) so I have tested this one by applying the update (inCODE
) via the AWS console:How can we measure success?
We will be able to recover (most) of the data stored in these tables in the unlikely event that they are ever deleted.
Have we considered potential risks?
Yes, a number of risks related to performance, cost and privacy were considered. See this doc for more details.
The doc mentions that the Mobile account might have greater costs than others, but this is primarily due to one very large table (which is not affected by this PR!) - more details on this can be found here.
Deployment
Merging the PR should be sufficient to update
mobile-notifications-football-notifications-<stage>
.After the PR is merged the
dynamo.yaml
template (which contains themobile-notifications-reports-<stage>
table) needs to be applied manually.