Amazon RDS and Aurora take automated backups and snapshots for you, and they’re good. But they share one property worth thinking about before you need them: they live in the same AWS account as the database they protect. If that account is compromised, closed for billing, or fat-fingered, your database and its backups can go together. And RDS snapshots tell you the backup exists, not that it restores.
Norcube Backup gives you the other half: an independent copy in storage you control, and a restore test that proves it recovers.
What it does
You point Norcube at your RDS instance or Aurora reader endpoint. On your schedule it runs a full pg_dump, encrypts it, and writes it to a bucket you own, in an account separate from the one running the database. You can pull any backup down and restore it with standard Postgres tools, with or without us. That’s the point of an off-site copy: no lock-in, including to us.
Connecting RDS
RDS is real Postgres, so the connection is ordinary. The work is on the AWS side: an RDS instance is private by default, so you make it publicly accessible and add one security-group inbound rule for Backup’s static egress IP (18.196.207.101/32) on port 5432. Connect with sslmode=require and password auth on a dedicated read-only role. For Aurora, point at the reader endpoint so dumps run off a replica. The full walkthrough, including the exact security-group steps, is in the Amazon RDS backup guide.
Prove it restores
Every backup can be restore-tested: Norcube restores it into a throwaway database, confirms the data comes back, and tears the copy down. RDS and Aurora preinstall AWS-only extensions (aws_s3, rds_tools, and the rest). Those aren’t your data. AWS recreates them for you, so a restore test recognizes their absence as expected and still records a clean pass. What it proves is what matters: your schemas, tables, and rows all restore.
Backups are only real once you’ve restored one
An independent, restore-tested copy of your RDS or Aurora database in your own storage is cheap insurance against the day the AWS account itself is the problem. Try it on your database, or read the Amazon RDS backup guide first.