# Replication with Amazon Aurora PostgreSQL
Following, you can find information about replication with Amazon Aurora PostgreSQL, including how to monitor and use logical replication.
**Topics**
+ [Using Aurora Replicas](#AuroraPostgreSQL.Replication.Replicas)
+ [Improving the read availability of Aurora Replicas](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Monitoring Aurora PostgreSQL replication](#AuroraPostgreSQL.Replication.Monitoring)
+ [Overview of PostgreSQL logical replication with Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Turning off logical replication](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Monitoring the write-through cache and logical slots for Aurora PostgreSQL logical replication](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Example: Logical replication using Aurora PostgreSQL and AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configuring IAM authentication for logical replication connections](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Using Aurora Replicas
An *Aurora Replica* is an independent endpoint in an Aurora DB cluster, best used for scaling read operations and increasing availability. An Aurora DB cluster can include up to 15 Aurora Replicas located throughout the Availability Zones of the Aurora DB cluster's AWS Region.
The DB cluster volume is made up of multiple copies of the data for the DB cluster. However, the data in the cluster volume is represented as a single, logical volume to the primary writer DB instance and to Aurora Replicas in the DB cluster. For more information about Aurora Replicas, see [Aurora Replicas](Aurora.Replication.md#Aurora.Replication.Replicas).
Aurora Replicas work well for read scaling because they're fully dedicated to read operations on your cluster volume. The writer DB instance manages write operations. The cluster volume is shared among all instances in your Aurora PostgreSQL DB cluster. Thus, no extra work is needed to replicate a copy of the data for each Aurora Replica.
With Aurora PostgreSQL, when an Aurora Replica is deleted, its instance endpoint is removed immediately, and the Aurora Replica is removed from the reader endpoint. If there are statements running on the Aurora Replica that is being deleted, there is a three minute grace period. Existing statements can finish gracefully during the grace period. When the grace period ends, the Aurora Replica is shut down and deleted.
Aurora PostgreSQL DB clusters support Aurora Replicas in different AWS Regions, using Aurora global database. For more information, see [Using Amazon Aurora Global Database](aurora-global-database.md).
**Note**
With the read availability feature, if you want to reboot the Aurora Replicas in the DB cluster, you have to perform it manually. For the DB clusters created prior to this feature rebooting the writer DB instance automatically reboots the Aurora Replicas. The automatic reboot re-establishes an entry point that guarantees read/write consistency across the DB cluster.
## Improving the read availability of Aurora Replicas
Aurora PostgreSQL improves the read availability in the DB cluster by continuously serving the read requests when the writer DB instance restarts or when the Aurora Replica is unable to keep up with the write traffic.
The read availability feature is available by default on the following versions of Aurora PostgreSQL:
+ 16.1 and all higher versions
+ 15.2 and higher 15 versions
+ 14.7 and higher 14 versions
+ 13.10 and higher 13 versions
+ 12.14 and higher 12 versions
The read availability feature is supported by Aurora global database in the following versions:
+ 16.1 and all higher versions
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
+ 13.12 and higher 13 versions
+ 12.16 and higher 12 versions
To use the read availability feature for a DB cluster created on one of these versions prior to this launch, restart the writer instance of the DB cluster.
When you modify static parameters of your Aurora PostgreSQL DB cluster, you must restart the writer instance so that the parameter changes take effect. For example, you must restart the writer instance when you set the value of `shared_buffers`. With the read availability feature of Aurora Replicas, the DB cluster maintains improved availability, reducing the impact on it when the writer instance restarts. The reader instances don't restart and continue to respond to the read requests. To apply static parameter changes, reboot each individual reader instance.
An Aurora PostgreSQL DB cluster's Aurora Replica can recover from replication errors such as writer restarts, failover, slow replication, and network issues by quickly recovering to in-memory database state after it reconnects with the writer. This approach allows Aurora Replica instances to reach consistency with the latest storage updates while the client database is still available.
The in-progress transactions that conflict with replication recovery might receive an error but the client can retry these transactions, after the readers catch up with the writer.
### Monitoring Aurora Replicas
You can monitor the Aurora Replicas when recovering from a writer disconnect. Use the metrics below to check for the latest information about the reader instance and to track in-process read-only transactions.
+ The `aurora_replica_status` function is updated to return the most up-to-date information for the reader instance when it is still connected. The last update time stamp in `aurora_replica_status` is always empty for the row corresponding to the DB instance that the query is executed on. This indicates that the reader instance has the latest data.
+ When the Aurora replica disconnects from the writer instance and reconnects back, the following database event is emitted:
`Read replica has been disconnected from the writer instance and reconnected.`
+ When a read-only query is canceled due to a recovery conflict, you might see one or more of the following error messages in the database error log:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitations
The following limitations apply to Aurora Replicas with the read availability feature:
+ Aurora Replicas of secondary DB cluster can restart if the data can't be streamed from the writer instance during replication recovery.
+ Aurora Replicas don't support online replication recovery if one is already in progress and will restart.
+ Aurora Replicas will restart when your DB instance is nearing the transaction ID wraparound. For more information on transaction ID wraparound, see [Preventing Transaction ID Wraparound Failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ Aurora Replicas can restart when the replication process is blocked under certain circumstances.
## Monitoring Aurora PostgreSQL replication
Read scaling and high availability depend on minimal lag time. You can monitor how far an Aurora Replica is lagging behind the writer DB instance of your Aurora PostgreSQL DB cluster by monitoring the Amazon CloudWatch `ReplicaLag` metric. Because Aurora Replicas read from the same cluster volume as the writer DB instance, the `ReplicaLag` metric has a different meaning for an Aurora PostgreSQL DB cluster. The `ReplicaLag` metric for an Aurora Replica indicates the lag for the page cache of the Aurora Replica compared to that of the writer DB instance.
For more information on monitoring RDS instances and CloudWatch metrics, see [Monitoring metrics in an Amazon Aurora cluster](MonitoringAurora.md).
# Overview of PostgreSQL logical replication with Aurora
By using PostgreSQL's logical replication feature with your Aurora PostgreSQL DB cluster, you can replicate and synchronize individual tables rather than the entire database instance. Logical replication uses a publish and subscribe model to replicate changes from a source to one or more recipients. It works by using change records from the PostgreSQL write-ahead log (WAL). The source, or *publisher*, sends WAL data for the specified tables to one or more recipients (*subscriber*), thus replicating the changes and keeping a subscriber's table synchronized with the publisher's table. The set of changes from the publisher are identified using a *publication*. Subscribers get the changes by creating a *subscription* that defines the connection to the publisher's database and its publications. A *replication slot* is the mechanism used in this scheme to track progress of a subscription.
For Aurora PostgreSQL DB clusters, the WAL records are saved on Aurora storage. The Aurora PostgreSQL DB cluster that's acting as the publisher in a logical replication scenario reads the WAL data from Aurora storage, decodes it, and sends it to the subscriber so that the changes can be applied to the table on that instance. The publisher uses a *logical decoder* to decode the data for use by subscribers. By default, Aurora PostgreSQL DB clusters use the native PostgreSQL `pgoutput` plugin when sending data. Other logical decoders are available. For example, Aurora PostgreSQL also supports the `[wal2json](https://github.com/eulerto/wal2json)` plugin that converts WAL data to JSON.
As of Aurora PostgreSQL version 14.5, 13.8, 12.12, and 11.17, Aurora PostgreSQL augments the PostgreSQL logical replication process with a *write-through cache* to improve performance. The WAL transaction logs are cached locally, in a buffer, to reduce the amount of disk I/O, that is, reading from Aurora storage during logical decoding. The write-through cache is used by default whenever you use logical replication for your Aurora PostgreSQL DB cluster. Aurora provides several functions that you can use to manage the cache. For more information, see [Monitoring the Aurora PostgreSQL logical replication write-through cache](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
Logical replication is supported by all currently available Aurora PostgreSQL versions. For more information, [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in the *Release Notes for Aurora PostgreSQL*.
Logical replication is supported by Babelfish for Aurora PostgreSQL from the following versions:
+ 15.7 and higher versions
+ 16.3 and higher versions
**Note**
In addition to the native PostgreSQL logical replication feature introduced in PostgreSQL 10, Aurora PostgreSQL also supports the `pglogical` extension. For more information, see [Using pglogical to synchronize data across instances](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
For more information about PostgreSQL logical replication, see [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) and [Logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) in the PostgreSQL documentation.
**Note**
PostgreSQL 16 added support for logical decoding from read replicas. This feature isn't supported on Aurora PostgreSQL.
# Setting up logical replication for your Aurora PostgreSQL DB cluster
Setting up logical replication requires `rds_superuser` privileges. Your Aurora PostgreSQL DB cluster must be configured to use a custom DB cluster parameter group so that you can set the necessary parameters as detailed in the procedure following. For more information, see [DB cluster parameter groups for Amazon Aurora DB clusters](USER_WorkingWithDBClusterParamGroups.md).
**To set up PostgreSQL logical replication for an Aurora PostgreSQL DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose your Aurora PostgreSQL DB cluster.
1. Open the **Configuration** tab. Among the Instance details, find the **Parameter group** link with **DB cluster parameter group** for **Type**.
1. Choose the link to open the custom parameters associated with your Aurora PostgreSQL DB cluster.
1. In the **Parameters** search field, type `rds` to find the `rds.logical_replication` parameter. The default value for this parameter is `0`, meaning that it's turned off by default.
1. Choose **Edit parameters** to access the property values, and then choose `1` from the selector to turn on the feature. Depending on your expected usage, you might also need to change the settings for the following parameters. However, in many cases, the default values are sufficient.
+ `max_replication_slots` – Set this parameter to a value that's at least equal to your planned total number of logical replication publications and subscriptions. If you are using AWS DMS, this parameter should equal at least your planned change data capture tasks from the cluster, plus logical replication publications and subscriptions.
+ `max_wal_senders` and `max_logical_replication_workers` – Set these parameters to a value that's at least equal to the number of logical replication slots that you intend to be active, or the number of active AWS DMS tasks for change data capture. Leaving a logical replication slot inactive prevents the vacuum from removing obsolete tuples from tables, so we recommend that you monitor replication slots and remove inactive slots as needed.
+ `max_worker_processes` – Set this parameter to a value that's at least equal to the total of the `max_logical_replication_workers`, `autovacuum_max_workers`, and `max_parallel_workers` values. On small DB instance classes, background worker processes can affect application workloads, so monitor the performance of your database if you set `max_worker_processes` higher than the default value. (The default value is the result of `GREATEST(${DBInstanceVCPU*2},8}`, which means that, by default, this is either 8 or twice the CPU equivalent of the DB instance class, whichever is greater).
**Note**
You can modify parameter values in a customer-created DB parameter group. you can't change the parameter values in a default DB parameter group.
1. Choose **Save changes**.
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster so that your changes takes effect. In the Amazon RDS console, choose the primary DB instance of the cluster and choose **Reboot** from the **Actions** menu.
1. When the instance is available, you can verify that logical replication is turned on, as follows.
1. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Verify that logical replication has been enabled by using the following command.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. Verify that the `wal_level` is set to `logical`.
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
For an example of using logical replication to keep a database table synchronized with changes from a source Aurora PostgreSQL DB cluster, see [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# Turning off logical replication
After completing your replication tasks, you should stop the replication process, drop replication slots, and turn off logical replication. Before dropping slots, make sure that they're no longer needed. Active replication slots can't be dropped.
**To turn off logical replication**
1. Drop all replication slots.
To drop all of the replication slots, connect to the publisher and run the following SQL command.
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
The replication slots can't be active when you run this command.
1. Modify the custom DB cluster parameter group associated with the publisher as detailed in [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md), but set the `rds.logical_replication` parameter to 0.
For more information about custom parameter groups, see [Modifying parameters in a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Restart the publisher Aurora PostgreSQL DB cluster for the change to the `rds.logical_replication` parameter to take effect.
# Monitoring the write-through cache and logical slots for Aurora PostgreSQL logical replication
Monitor the logical replication write-through cache and manage logical slots to improve performance for your Aurora PostgreSQL DB cluster. Following, find more information about the write-through cache and logical slots.
**Topics**
+ [Monitoring the Aurora PostgreSQL logical replication write-through cache](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Managing logical slots for Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Monitoring the Aurora PostgreSQL logical replication write-through cache
By default, Aurora PostgreSQL versions 14.5, 13.8, 12.12, and 11.17 and higher use a write-through cache to improve the performance for logical replication. Without the write-through cache, Aurora PostgreSQL uses the Aurora storage layer in its implementation of the native PostgreSQL logical replication process. It does so by writing WAL data to storage and then reading the data back from storage to decode it and send (replicate) to its targets (subscribers). This can result in bottlenecks during logical replication for Aurora PostgreSQL DB clusters.
The write-through cache minimizes reliance on the Aurora storage layer. Instead of consistently writing to and reading from this layer, Aurora PostgreSQL uses a buffer to cache the logical WAL stream for use during the replication process, reducing the need to access disk. This buffer is the native PostgreSQL cache used in logical replication and is identified in Aurora PostgreSQL DB cluster parameters as `rds.logical_wal_cache`.
When you use logical replication with your Aurora PostgreSQL DB cluster (for the versions that support the write-through cache), you can monitor the cache hit ratio to see how well it's working for your use case. To do so, connect to your Aurora PostgreSQL DB cluster's write instance using `psql` and then use the Aurora function, `aurora_stat_logical_wal_cache`, as shown in the following example.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
The function returns output such as the following.
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
The `last_reset_timestamp` values have been shortened for readability. For more information about this function, see [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL provides the following two functions for monitoring the write-through cache.
+ The `aurora_stat_logical_wal_cache` function – For reference documentation, see [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ The `aurora_stat_reset_wal_cache` function – For reference documentation, see [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
If you find that the automatically adjusted WAL cache size isn't sufficient for your workloads, you can change the the value of the `rds.logical_wal_cache` manually. Consider the following:
+ When the `rds.logical_replication` parameter is disabled, `rds.logical_wal_cache` is set to zero (0).
+ When the `rds.logical_replication` parameter is enabled, `rds.logical_wal_cache` has a default value of 16 MB.
+ The `rds.logical_wal_cache` parameter is static and requires a database instance reboot for changes to take effect. This parameter is defined in terms of 8 Kb blocks. Note that any positive value less than 32 Kb is treated as 32 Kb. For more information about `wal_buffers` see [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) in the PostgreSQL documentation.
## Managing logical slots for Aurora PostgreSQL
Streaming activity is captured in the `pg_replication_origin_status` view. To see the contents of this view, you can use the `pg_show_replication_origin_status()` function, as shown following:
```
SELECT * FROM pg_show_replication_origin_status();
```
You can get a list of your logical slots by using the following SQL query.
```
SELECT * FROM pg_replication_slots;
```
To drop a logical slot, use the `pg_drop_replication_slot` with the name of the slot, as shown in the following command.
```
SELECT pg_drop_replication_slot('test_slot');
```
# Example: Using logical replication with Aurora PostgreSQL DB clusters
The following procedure shows you how to start logical replication between two Aurora PostgreSQL DB clusters. Both the publisher and the subscriber must be configured for logical replication as detailed in [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md).
The Aurora PostgreSQL DB cluster that's the designated publisher must also allow access to the replication slot. To do so, modify the security group associated with the Aurora PostgreSQL DB cluster 's virtual public cloud (VPC) based on the Amazon VPC service. Allow inbound access by adding the security group associated with the subscriber's VPC to the publisher's security group. For more information, see [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.
With these preliminary steps complete, you can use PostgreSQL commands `CREATE PUBLICATION` on the publisher and the `CREATE SUBSCRIPTION` on the subscriber, as detailed in the following procedure.
**To start the logical replication process between two Aurora PostgreSQL DB clusters**
These steps assume that your Aurora PostgreSQL DB clusters have a writer instance with a database in which to create the example tables.
1. **On the publisher Aurora PostgreSQL DB cluster**
1. Create a table using the following SQL statement.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Insert data into the publisher database by using the following SQL statement.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Verify that data exists in the table by using the following SQL statement.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Create a publication for this table by using the `CREATE PUBLICATION` statement, as follows.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **On the subscriber Aurora PostgreSQL DB cluster**
1. Create the same `LogicalReplicationTest` table on the subscriber that you created on the publisher, as follows.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Verify that this table is empty.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Create a subscription to get the changes from the publisher. You need to use the following details about the publisher Aurora PostgreSQL DB cluster.
+ **host** – The publisher Aurora PostgreSQL DB cluster's writer DB instance.
+ **port** – The port on which the writer DB instance is listening. The default for PostgreSQL is 5432.
+ **dbname** – The name of the database.
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**Note**
Specify a password other than the prompt shown here as a security best practice.
After the subscription is created, a logical replication slot is created at the publisher.
1. To verify for this example that the initial data is replicated on the subscriber, use the following SQL statement on the subscriber database.
```
SELECT count(*) FROM LogicalReplicationTest;
```
Any further changes on the publisher are replicated to the subscriber.
Logical replication affects performance. We recommend that you turn off logical replication after your replication tasks are complete.
# Example: Logical replication using Aurora PostgreSQL and AWS Database Migration Service
You can use the AWS Database Migration Service (AWS DMS) to replicate a database or a portion of a database. Use AWS DMS to migrate your data from an Aurora PostgreSQL database to another open source or commercial database. For more information about AWS DMS, see the [AWS Database Migration Service User Guide](https://docs.aws.amazon.com/dms/latest/userguide/).
The following example shows how to set up logical replication from an Aurora PostgreSQL database as the publisher and then use AWS DMS for migration. This example uses the same publisher and subscriber that were created in [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
To set up logical replication with AWS DMS, you need details about your publisher and subscriber from Amazon RDS. In particular, you need details about the publisher's writer DB instance and the subscriber's DB instance.
Get the following information for the publisher's writer DB instance:
+ The virtual private cloud (VPC) identifier
+ The subnet group
+ The Availability Zone (AZ)
+ The VPC security group
+ The DB instance ID
Get the following information for the subscriber's DB instance:
+ The DB instance ID
+ The source engine
**To use AWS DMS for logical replication with Aurora PostgreSQL**
1. Prepare the publisher database to work with AWS DMS.
To do this, PostgreSQL 10.x and later databases require that you apply AWS DMS wrapper functions to the publisher database. For details on this and later steps, see the instructions in [Using PostgreSQL version 10.x and later as a source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) in the *AWS Database Migration Service User Guide.*
1. Sign in to the AWS Management Console and open the AWS DMS console at [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2). At top right, choose the same AWS Region in which the publisher and subscriber are located.
1. Create an AWS DMS replication instance.
Choose values that are the same as for your publisher's writer DB instance. These include the following settings:
+ For **VPC**, choose the same VPC as for the writer DB instance.
+ For **Replication Subnet Group**, choose a subnet group with the same values as the writer DB instance. Create a new one if necessary.
+ For **Availability zone**, choose the same zone as for the writer DB instance.
+ For **VPC Security Group**, choose the same group as for the writer DB instance.
1. Create an AWS DMS endpoint for the source.
Specify the publisher as the source endpoint by using the following settings:
+ For **Endpoint type**, choose **Source endpoint**.
+ Choose **Select RDS DB Instance**.
+ For **RDS Instance**, choose the DB identifier of the publisher's writer DB instance.
+ For **Source engine**, choose **postgres**.
1. Create an AWS DMS endpoint for the target.
Specify the subscriber as the target endpoint by using the following settings:
+ For **Endpoint type**, choose **Target endpoint**.
+ Choose **Select RDS DB Instance**.
+ For **RDS Instance**, choose the DB identifier of the subscriber DB instance.
+ Choose a value for **Source engine**. For example, if the subscriber is an RDS PostgreSQL database, choose **postgres**. If the subscriber is an Aurora PostgreSQL database, choose **aurora-postgresql**.
1. Create an AWS DMS database migration task.
You use a database migration task to specify what database tables to migrate, to map data using the target schema, and to create new tables on the target database. At a minimum, use the following settings for **Task configuration**:
+ For **Replication instance**, choose the replication instance that you created in an earlier step.
+ For **Source database endpoint**, choose the publisher source that you created in an earlier step.
+ For **Target database endpoint**, choose the subscriber target that you created in an earlier step.
The rest of the task details depend on your migration project. For more information about specifying all the details for DMS tasks, see [Working with AWS DMS tasks](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) in the *AWS Database Migration Service User Guide.*
After AWS DMS creates the task, it begins migrating data from the publisher to the subscriber.
# Configuring IAM authentication for logical replication connections
Starting with Aurora PostgreSQL versions 11 and higher, you can use AWS Identity and Access Management (IAM) authentication for replication connections. This feature enhances security by allowing you to manage database access using IAM roles instead of passwords. It works at the cluster level and follows the same security model as standard IAM authentication.
IAM authentication for replication connections is an opt-in feature. To enable it, set the `rds.iam_auth_for_replication` parameter to `1` in your DB cluster parameter group. As this is a dynamic parameter, your DB cluster doesn't need to restart, enabling you to leverage IAM authentication with existing workloads without downtime. Before enabling this feature, you must meet the [Prerequisites](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) listed below.
## Prerequisites
To use IAM authentication for replication connections, you need to meet all of the following requirements:
+ Your Aurora PostgreSQL DB cluster must be version 11 or later.
+ On your publisher Aurora PostgreSQL DB cluster:
+ Enable IAM database authentication.
For more information, see [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Enable logical replication by setting the `rds.logical_replication` parameter to `1`.
For more information, see [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md).
In logical replication, the publisher is the source Aurora PostgreSQL DB cluster that sends data to subscriber clusters. For more information, see [Overview of PostgreSQL logical replication with Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**Note**
Both IAM authentication and logical replication must be enabled on your publisher Aurora PostgreSQL DB cluster. If either one isn't enabled, you can't use IAM authentication for replication connections.
## Enabling IAM authentication for replication connections
Complete the following steps to enable IAM authentication for replication connection.
1. Verify that your Aurora PostgreSQL DB cluster meets all prerequisites for IAM authentication with replication connections. For details, see [Prerequisites](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configure the `rds.iam_auth_for_replication` parameter by modifying your DB cluster parameter group:
+ Set the `rds.iam_auth_for_replication` parameter to `1`. This dynamic parameter doesn't require a reboot.
1. Connect to your database and grant the necessary roles to your replication user:
The following SQL commands grant the necessary roles to enable IAM authentication for replication connections:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
After you complete these steps, the specified user must use IAM authentication for replication connections.
**Important**
When you enable the feature, users with both `rds_iam` and `rds_replication` roles must use IAM authentication for replication connections. This applies whether the roles are assigned directly to the user or inherited through other roles.
## Disabling IAM authentication for replication connections
You can disable IAM authentication for replication connections by using any of the following methods:
+ Set the `rds.iam_auth_for_replication` parameter to `0` in your DB cluster parameter group
+ Alternatively, you can disable either of these features on your Aurora PostgreSQL DB cluster:
+ Disable logical replication by setting the `rds.logical_replication` parameter to `0`
+ Disable IAM authentication
When you disable the feature, replication connections can use database passwords for authentication if configured.
**Note**
Replication connections for users without the `rds_iam` role can use password authentication even when the feature is enabled.
## Limitations and considerations
The following limitations and considerations apply when using IAM authentication for replication connections.
+ IAM authentication for replication connections is only available for Aurora PostgreSQL versions 11 and higher.
+ The publisher must support IAM authentication for replication connections.
+ The IAM authentication token expires after 15 minutes by default. You might need to refresh long-running replication connections before the token expires.