Amazon RDS & Aurora
Back up an Amazon RDS or Aurora PostgreSQL database — send independent, restore-tested backups to storage you control. Public access, the security-group rule, SSL, and how restore tests handle RDS-managed extensions.
To back up an Amazon RDS or Aurora PostgreSQL database, Backup connects to its
endpoint like any other Postgres. RDS and Aurora both run real PostgreSQL, so
pg_dump works normally. The work is on the AWS side: making the instance
reachable from Backup's egress IP and using password auth on a read-only role.
Which connection string
Connect by the DNS endpoint, never a raw IP (the IP changes on failover):
<name>.<hash>.<region>.rds.amazonaws.comPort 5432, over IPv4 (RDS is IPv4 by default). For Aurora, a cluster has a
writer endpoint and a reader endpoint. Point Backup at the reader endpoint so
dumps run off a replica and don't load the writer.
RDS for PostgreSQL 15+ forces SSL by default (rds.force_ssl = 1), so a
plaintext connection is refused. Set SSL mode to require in Backup. That
encrypts the connection without needing the RDS CA bundle. (Only verify-ca /
verify-full need the CA file.)
Find the connection details
- In the RDS console, open Databases and select your instance or cluster.
- On the Connectivity & security tab, copy the Endpoint and note the Port and the master username (or a dedicated backup user).
- The database name is the "Initial database name" you set at creation (the
admin database is
postgresif none was set).
Use a dedicated read-only role rather than the master user:
CREATE ROLE norcube_backup LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE <your-db> TO norcube_backup;
GRANT USAGE ON SCHEMA public TO norcube_backup;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO norcube_backup;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO norcube_backup;Use password authentication, not IAM database authentication: IAM tokens expire after 15 minutes, which is impractical for a scheduled backup service. See read-only role snippets.
Network access
By default an RDS instance sits in a private subnet and isn't reachable from the
internet. To let Backup's egress IP 18.196.207.101 connect, all of these must
be true:
- Public access = Yes on the instance (Modify → Additional connectivity configuration → Public access). With No, there's no public IP and no security-group rule can help.
- The DB subnet group's subnets are public (route to an internet gateway), and the VPC has DNS hostnames and DNS resolution enabled.
- A security-group inbound rule allowing Backup's IP:
- On the Connectivity & security tab, open the attached VPC security group.
- Inbound rules → Edit inbound rules → Add rule: Type PostgreSQL
(TCP/5432), Source
18.196.207.101/32. Save.
The /32 restricts it to exactly Backup's egress IP. Don't use 0.0.0.0/0. See
network access.
Restore tests and managed extensions
Every backup can be restore-tested: Backup restores it into a throwaway, vanilla stock PostgreSQL engine and confirms your data comes back. RDS and Aurora preinstall AWS-only extensions that don't exist in community Postgres, so if your database uses any, they can't be recreated on a generic engine. These include:
aws_s3andaws_commons— S3 import/export.rds_tools— RDS utility functions.pg_transport— fast transportable-database migration.aws_lambda,apg_plan_mgmt, and the Aurora ML extensions (aws_ml,aws_sagemaker,aws_comprehend) — Aurora only.pg_tleand any Trusted Language Extensions built on it.
Those aren't your application data: AWS recreates them for you on any RDS or Aurora instance. A restore test treats their absence as expected, notes them in the log, and still records a clean Passed. What it proves is what matters: your schemas, tables, and rows all restore. Details: Provider-managed extensions.
Ordinary open-source extensions you may also use (postgis, pg_cron, pgvector,
pgaudit, and so on) restore normally wherever the same extension is installed.
From there, it's the standard flow
Backup runs a full pg_dump on your schedule and
writes the encrypted archive to
storage you control. You can
download any backup and restore it with standard Postgres tools,
independent of Norcube. For the general walkthrough, see
connect a database.
Supabase
Back up a Supabase database — send independent, restore-tested backups of your Supabase Postgres to storage you control. Which connection string to use, network access, and what restore tests do with Supabase's managed extensions.
Google Cloud SQL
Back up a Google Cloud SQL for PostgreSQL database — send independent, restore-tested backups to storage you control. Public IP, authorized networks, SSL mode, and how restore tests handle Cloud SQL-managed extensions.