更新：これについてAWSフォーラムに投稿しました。チャイムに行って、そこに尋ねてください。
執筆時点では、Amazon RDSはRDS外部の物理レプリケーションをサポートしていません。あなたのことができGRANT、ユーザーREPLICATION使用権rds_superuserログインをしていますが、設定することができないreplicationで外のIPアドレスのエントリpg_hba.conf。
さらに、RDSでDBパラメーターグループを作成すると、いくつかのキーパラメーターが表示されますが、ロックされます（例：archive_commandにロックされ/etc/rds/dbbin/pgscripts/rds_wal_archive %pます）。AWS RDS for PostgreSQLは、外部PITRにWAL-shippingレプリケーションを使用する場合に必要となるため、これらのWALを外部アクセス（たとえばS3経由）に公開するようには見えません。
したがって、この時点で、wal-shippingが必要な場合は、RDSを使用しないでください。それは缶詰の使いやすいデータベースですが、使いやすいということは、多くの場合、それも制限されていることを意味し、それは確かにここに当てはまります。Joe Loveがコメントで指摘しているように、RDS内で WAL配送とPITRを提供しますが、RDSの外部からWALにアクセスすることはできません。
そのため、RDSの独自のバックアップ機能（ダンプ、スナップショット、独自のWALベースのPITR）を使用する必要があります。
RDSによってレプリケーション接続（pg_basebackupまたはレプリケーションのストリーミング）が可能になり、アーカイブされたWALにアクセスできるようになったとしても、そのWALを実際に消費できない場合があります。RDSはパッチが適用されたPostgreSQLを実行しますが、パッチがどれほど大きく適用されているか、またはディスク上の形式が大幅に変更されているかどうかは誰にもわかりません。また、Amazonが選択したアーキテクチャ（おそらくx64 Linux）で実行されますが、簡単には判別できません。PostgreSQLのディスク形式とレプリケーションはアーキテクチャに依存するため、PostgreSQLビルドがそれらと互換性がある場合にのみ、Amazon RDSで使用されるものと同じアーキテクチャのホストにのみレプリケートできます。
これは、RDSから移行する簡単な方法がないことを意味します。データベースへのすべての書き込みを停止してから、データベースをpg_dump復元し、新しいDBを実行する必要があります。DBホストに直接アクセスできないため、レプリケーションとフェールオーバー、rsyncなどを使用した通常のトリックは機能しません。
RDSがパッチ未適用のPostgreSQLを実行したとしても、Amazonはおそらくpg_basebackupセキュリティ上の理由でRDSへのWALストリーミングまたはRDSへのインポートを許可したくないでしょう。PostgreSQLは、データディレクトリを信頼できるコンテンツとして扱います。内部機能をフックする巧妙な「LANGUAGE c」関数を作成した場合、または他のトリッキーな操作を行った場合は、サーバーを悪用して想定以上のアクセスを取得できる可能性があります。そのため、AmazonはすぐにインバウンドWALを許可しません。
アウトバウンドWAL送信をサポートできますが、フォーマットの互換性、変更の自由などに関する上記の問題は依然として当てはまります。
代わりに、LondisteやBucardoなどのツールを使用する必要があります。