Amazon's SDK for Relational Database Service (part of which Aurora DB is) is only useful for programmatically managing database clusters and instances (creating and deleting databases, changing instance state, managing users, creating dumps to S3, etc). From client perspective, all you need to work with Aurora DB is JDBC driver.
There are two ways to connect to AuroraDB - using JDBC and using RDS Data API client. According to documentation, Data API client 'provides Http Endpoint to query RDS databases'. This means that in this case data will be accessed via REST API backed by the same JDBC calls. Thus there will be not only network delay but also additional time should be spent serializing/deserializing classes from SDK. Also, using HTTP doesn't seem to be any good for database batch operations. Another reason to stick with JDBC is the fact, that most of the CPU time in database plugins is spent on datatypes mapping and conversion (as discovered during performance testing), not on IO operations.
JDBC
RDS API
+ Drivers are designed to connect
to remote databases
+ Database-agnostic, same calls seem to work
with cluster of any type (Postgres, MySQL)
+ Database connections are reused,
connection pooling is available
- Serialization/deserialization overhead
- Requires driver to be provided
- Sending big batches of data as a text via
relatively slow HTTP protocol
- Still uses JDBC somewhere in AWS infrastructure
Taking into account above arguments it looks like connecting to AuroraDB cluster using JDBC driver would be the most rational choice, so it might also be a good idea to reuse existing database source and sink functionality from database-plugins project.
Design
For better user experience it is suggested to create separate plugins for AuroraDB MySQL and PostgreSQL.