4C Cadence

Checking authentication...

CD
4C Cadence
/ RDS Restore

RDS Restore

Restore an RDS instance from a snapshot into your selected VPC and network configuration

Production Environment — All restores are live operations. Proceed with caution.
1

Select Snapshot

2

Instance Configuration

Letters, numbers, hyphens. Must start with a letter.
Enable Multi-AZ
Standby replica in a second AZ — recommended for production
3

Network

Select a VPC first
4

Engine & Encryption

Leave blank to use the engine default.
Leave blank to use the engine default.
Select your CMK here before using Copy to Manual Snapshot. The restore operation inherits encryption from the snapshot directly.
Fill in all required fields above, then click Restore.

Zero-ETL Integration

Guided runbook for re-creating the Aurora → Redshift Zero-ETL integration (Production account)

Redshift Connection
Configure once — used for all direct SQL execution steps
Redshift Cluster
DB User
Admin Database (base DB, not frauddb)
Configure cluster above to enable direct execution
1
Delete
2
Cleanup
3
Create
4
Open DB
5
Grants
6
Notify
1
Step 1 — Delete existing integration
In Aurora and RDS → Zero-ETL-Integration page → delete the integration. All actions in the Production account.
Navigate to the RDS Zero-ETL Integrations page in the AWS Console, find the existing integration, and delete it before proceeding.
2a
Step 2a — Check active connections
Run in Redshift Query Editor to find active connections to frauddb.
SELECT procpid, usename, datname, query_start FROM pg_stat_activity WHERE datname = 'frauddb' AND usename <> 'rdsadmin' AND procpid <> pg_backend_pid();
Returns the procpid of every active session on frauddb except the rdsadmin system user and this session. Those procpids auto-populate Step 2b for termination.
2b
Step 2b — Terminate connections
Enter the procpid values found above to generate terminate statements.
Enter the procpid values from Step 2a, comma-separated (e.g. 12345, 67890). If there were no results, skip directly to Mark Complete.
2c
Step 2c — Drop database
Drop frauddb in Redshift. Must succeed before recreating from integration.
DROP DATABASE frauddb;
This must succeed before you can create the database from the new integration. If it fails, revisit Step 2b to ensure all connections are terminated.
3
Step 3 — Create Integration
Create the Zero-ETL integration with custom filtering directly from this portal.
3c
Step 3c — Wait for integration creation
Integration will be created and begin syncing. Typical duration: 3–4 hours.
The integration has been submitted. Wait for it to reach Active status in the RDS console before proceeding. This typically takes 3–4 hours.
0h 0m
elapsed
Estimated: 3–4 hours
4a
Step 4a — Open integration in Redshift
Go to Redshift → Zero-ETL-Integration and select the integration.
The integration should show as Active in Redshift, but the database does not exist yet — that is expected at this stage.
Open Redshift Console
4b
Step 4b — Create DB from integration
Click Create DB from integration and enter frauddb.
When prompted to connect, choose any DB other than frauddb. Then click Create DB from integration and enter frauddb as the database name. If frauddb was not successfully dropped in Step 2c, this step will fail.
4c
Step 4c — Wait for DB creation
Watch progress in the Zero-ETL Integration view in Redshift. Typical duration: 2–3 hours.
Monitor the sync progress in the Redshift Zero-ETL integration view. The database will populate as data syncs from Aurora.
0h 0m
elapsed
Estimated: 2–3 hours
5a
Step 5a — Grant schema usage
Grant USAGE on all three schemas to readonly_group.
GRANT USAGE ON SCHEMA frauddb TO GROUP readonly_group; GRANT USAGE ON SCHEMA npi TO GROUP readonly_group; GRANT USAGE ON SCHEMA codes TO GROUP readonly_group;
5b
Step 5b — Grant table access
Grant SELECT on all tables in each schema to readonly_group.
GRANT SELECT ON ALL TABLES IN SCHEMA frauddb TO GROUP readonly_group; GRANT SELECT ON ALL TABLES IN SCHEMA codes TO GROUP readonly_group; GRANT SELECT ON ALL TABLES IN SCHEMA npi TO GROUP readonly_group;
5c
Step 5c — Default privileges
Set default privileges so future tables are automatically accessible.
ALTER DEFAULT PRIVILEGES IN SCHEMA frauddb GRANT SELECT ON TABLES TO GROUP readonly_group; ALTER DEFAULT PRIVILEGES IN SCHEMA codes GRANT SELECT ON TABLES TO GROUP readonly_group; ALTER DEFAULT PRIVILEGES IN SCHEMA npi GRANT SELECT ON TABLES TO GROUP readonly_group;
5d
Step 5d — Language usage grant
Grant USAGE on exfunc language to individual users.
GRANT USAGE ON LANGUAGE exfunc TO bmccurdy; GRANT USAGE ON LANGUAGE exfunc TO hcp;
6
Step 6 — Communicate completion
Post an update in the Redshift group.
Copy the message below and post it in the Redshift Slack channel.
✅ Zero-ETL Integration runbook complete. frauddb is now syncing to Redshift from Aurora. Schemas: frauddb, codes, npi — all accessible to readonly_group.

Build · Fraud

CI — build Fraud release or snapshot AMIs via the Jenkins cut-release job. This builds artifacts; use Deploy to ship them.

Builds always run against the build account (dev). Dry-run is on by default — run once dry, read the log, then run for real.
1

Cut Release Line

Cuts branch CORE-X.Y, bumps master, tags X.Y.0, copies the CI job, and builds AMIs.

2

Point Release

Tags the next patch on the existing branch (no branch cut, no master bump). Version auto-incremented from the latest tag.

Latest: —

Build · Clarity

CI — build Clarity AMIs via the symphony-pipeline (CodePipeline). Runs for real (no dry-run); use Deploy to ship them.

▶

Build Clarity

Starts the symphony-pipeline on the master branch: Source → Test → Build → Bake-AMI. No dry-run — CodePipeline executes for real. The patch counter auto-increments from the sprint version in CodeCommit.

Dev build — SPRINT_VERSION=snapshot

Sprint version (e.g. 2.83); patch auto-increments.

Deploy · Clarity

Deploy Clarity via CloudFormation/ASG instance refresh (Step Functions) — no ops-war

⚡

Clarity ASG Deploy (new — no ops-war)

Deploys Clarity via Step Functions + ASG instance refresh — zero ops-war. Bumps the launch template to the version's AMI and rolls the ASG (zero-downtime). Blank version = latest snapshot. Start/Stop env scales the ASG (1/0) for scheduled-off envs.
Current: —

Strapi Promote

Promote code/schema (and optionally content data) between Strapi environments (dev / staging / prod). Always uses the prod account Strapi EC2.

↑

Promote Environment

Code / schema (always): copies the Strapi src/ folder (content-type models, components, API code) from source to target, then restarts the target pm2 app. The database and media are not touched. Data & uploads (only if checked): also dumps the source MySQL content tables (skipping admin/auth/system tables), rewrites environment URLs, imports into the target DB, and syncs the uploads/ media folder. All directions supported; any direction into prod requires typed confirmation.

Release Runbook

End-to-end release checklist — track every step from branch cut to post-release

Release Configuration
RELEASE LINE
FRAUD DEPLOY VERSION
PREV RELEASE (for AMI cleanup)
0 / 0 done
AI
Pip · Cadence assistant
4C DevOps AI
Hi! I'm Pip, your Cadence DevOps assistant. I can help you inspect snapshots, DB instances, Zero-ETL integrations, release pipelines, and more — or take actions with your approval.

Try asking: "How many manual snapshots are there?" or "What's the status of the Clarity pipeline?"