RDS Restore
Restore an RDS instance from a snapshot into your selected VPC and network configuration
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.
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
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.
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.
Release Builds
CI — build release or snapshot AMIs (Fraud=Jenkins cut-release, Symphony=CodePipeline). This builds artifacts; use the Deploy tab to ship them.
Releases 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: —
Deploy
Deploy Fraud & Clarity apps to an environment via opsControl (Blue-Green start)
Runs
opsControl_new.sh --operation=start on the Jenkins box (build account). Blank version = keep the previous version. Blank server size = keep current. Dry-run is on by default — run dry first, read the log, then run for real. Fraud and Clarity can be deployed independently or together.▶
Deploy Apps
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