Providers

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.

Not verified yet

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.com

Port 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

  1. In the RDS console, open Databases and select your instance or cluster.
  2. On the Connectivity & security tab, copy the Endpoint and note the Port and the master username (or a dedicated backup user).
  3. The database name is the "Initial database name" you set at creation (the admin database is postgres if 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:

  1. 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.
  2. The DB subnet group's subnets are public (route to an internet gateway), and the VPC has DNS hostnames and DNS resolution enabled.
  3. 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_s3 and aws_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_tle and 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.

On this page