# Amazon RDS (PostgreSQL, MySQL and MariaDB)

## Outpost and PostgreSQL

For **In Host BYOK** on AWS, first complete [Outpost deployment](/docs/introduction-to-relyance-ai/how-outpost-works/). Credentials live in your AWS Secrets Manager; configure only the ARN on the connection using the [RDS secret examples](/docs/introduction-to-relyance-ai/outpost-connection-credentials/#rds-direct-connection-with-postgresql). Hosted credential examples later on this page require that adjustment for BYOK.

Use the existing private EKS-to-RDS path when approved. Confirm DNS, routing and security-group access from EKS to the actual database endpoint/port. The public-access and Relyance-hosted allow-list steps below apply to hosted connectivity; Outpost does not require making a privately reachable database public.

- **Direct Connection:** choose the actual engine (`postgres` for PostgreSQL) and a dedicated database user. The current PostgreSQL client initially connects to the `postgres` bootstrap database for authentication and catalog enumeration, before applying database-name filters. Arrange approved `CONNECT` access to `postgres`; this bootstrap step needs no application-table grants there. Also grant `CONNECT` on each intended application database, `USAGE` on approved schemas and `SELECT` on approved tables/views. Arrange grants for future tables only where intended. These database privileges are separate from IAM.
- **IAM-based Auth:** the assumed role needs `rds:DescribeDBInstances` for discovery and `rds-db:connect` scoped to the intended database user. The source role must trust the Outpost workload role with the configured external ID. Enable IAM database authentication and grant the PostgreSQL user `rds_iam`, following [AWS's database account setup](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html). Explicitly configure that user's name; discovery alone does not prove its SQL grants. `crawler_rules` allow/block lists match RDS instance identifiers (`DBInstanceIdentifier`) in this mode; for Direct Connection they match SQL database names. IAM instance filtering does not confine database/table access, so retain the separate SQL permission boundaries.
- **Validation:** for direct PostgreSQL, first verify the bootstrap connection to `postgres` from the EKS network path using the same dedicated user and TLS requirements, without adding table grants there. Then enumerate the intended databases/schemas/tables and verify a bounded read from an approved table using your organization's SQL tools and credential handling. Then verify the Outpost scan produces the expected classifications. A successful login or first-instance check does not validate every database.

If your policy forbids `CONNECT` to the `postgres` bootstrap database, have Relyance confirm a supported alternative before onboarding. The current Direct Connection authentication form has no initial-database field; do not add an undocumented secret key to bypass this prerequisite.

PostgreSQL connections use TLS with `sslmode=require` in the current client. This establishes encryption; do not assume hostname/CA verification equivalent to `verify-full`. Agree any stricter certificate requirement with Relyance before onboarding. For MySQL, MariaDB and SQL Server, use the engine-specific setup below and confirm the chosen authentication method is supported.

![Amazon_RDS_MySQL_MariaDb_logo.png|400](https://assets.relyanceuat.xyz/images/docs/6793782451597/6793332221837_white.png)

Amazon Relational Database Service (or Amazon RDS) is a cloud-based distributed relational database service designed to simplify the setup, operation, and scaling of a relational database for use in applications. It also helps with relational database management tasks, such as data migration, backup, recovery and patching.

The Amazon RDS integration has 2 options to connect:

- [A direct connection to the RDS database](/docs/data-stores/amazon-rds-mysql-mariadb/#option-2-standard-direct-connection-configuration-in-rds)
- [Direct connection via IAM-based authentication and RDS auto-discovery](/docs/data-stores/amazon-rds-mysql-mariadb/#aws-rds-via-iam-based-authentication)

*Note: The AWS Lambda connection option is now deprecated in favor of Relyance DirectConnect, which provides a more secure and reliable connection method. Please reach out to your Relyance support team to learn more about enabling DirectConnect for your environment.*

The **AWS Lambda** method is still offered in the connection drop-down for
existing setups. It takes **Account ID**, **Role Name**, **External ID**,
**Region**, **Lambda Function Name**, **Crawler Configuration** and the **Use
IAM-based Authentication** checkbox (**Database User** and **Secret Name** are
optional). Use **IAM-based Auth** or **Direct Connection** for anything new.

### Prerequisites Database User Setup

Before connecting via either method (Direct Connection or IAM-based Authentication), you must create a dedicated database user and grant appropriate permissions.

#### Step 1: Create the Relyance User

Create a user in every database you want Relyance to scan. The exact command depends on your authentication method.

MySQL / MariaDB

For Direct Connection (password-based):

CREATE USER 'relyance_user'@'%' IDENTIFIED BY 'your_password';

For IAM-based Authentication:

CREATE USER 'relyance_user' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

PostgreSQL

For Direct Connection (password-based):

CREATE USER relyance_user WITH PASSWORD 'your_password';

For IAM-based Authentication:

CREATE USER relyance_user;
GRANT rds_iam TO relyance_user;

#### Step 2: Grant Permissions

Provide the necessary read and metadata privileges for Relyance to perform data discovery and inspection.

MySQL and MariaDB:

GRANT SELECT,SHOW VIEW,EXECUTE ON *.* TO 'relyance_user'@'%';
FLUSH PRIVILEGES;

PostgreSQL:

GRANT CONNECT ON DATABASE {{ DB_NAME }} TO relyance_user;
GRANT USAGE ON SCHEMA {{ DB_SCHEMA }} TO relyance_user;
GRANT SELECT ON ALL TABLES IN SCHEMA {{ DB_SCHEMA }} TO relyance_user;

If you’re running PostgreSQL 14 or later, you can replace individual GRANT statements with the built-in role pg_read_all_data:

GRANT pg_read_all_data TO relyance_user;

This provides read access across all schemas and tables within the database.

You (or your administrator) will need to run these statements for each PostgreSQL database and schema you want to analyze.

Direct Connection

For Relyance-hosted scans, the following sections describe private VPN and public endpoint connectivity. For Outpost, use the existing EKS-to-RDS path described above; do not make the database public or add hosted egress IPs solely for Outpost.

| Option | Description |
| --- | --- |
| Option 1: Site-to-Site VPN via DirectConnect) | Establishes a private VPN between your environment and Relyance. No public exposure of RDS resources. |
| Option 2: Standard Direct Connection (Public Access) | Connects via the public internet using IP allow lists and standard security group configuration. |

#### Option 1: Secure Connection (Site-to-Site VPN via DirectConnect) Configuration in RDS

This is the recommended method for secure, private connectivity. Relyance DirectConnect establishes a site-to-site VPN between your environment and Relyance AI, eliminating the need for public database exposure.

To set this up, review the documentation to configure the site-to-site VPN [here](/docs/cloud-accounts/aws-x-directconnect-integration-guide/) and reach out to our support team for next steps. Once your VPN is configured, proceed with adding your Amazon RDS integration in Relyance.

#### Option 2: Standard Direct Connection Configuration in RDS

If a VPN setup isn’t available, you can connect using a standard direct connection. This method requires making your RDS instance publicly accessible and allowing Relyance IP addresses through security groups.

This next section ensures you can share your RDS database with the Relyance AI application.

- Log in to your AWS management console.
- In the search bar search for RDS and click on RDS.
- Click on Databases in the left-hand navigation.
- Select the database you want to process and click the Modify button.
- Scroll down to the Connectivity section and set Public Access to Publicly accessible.
- Save the changes.
- On the database dashboard select your database.
- Scroll down to the Connectivity & Security section and click on the security groups link under VPC security groups.
- On the bottom half of the page click on Inbound rules tab.
- Click the Edit inbound rules button.
- Click Add rule, select:
    - The port of the SQL engine in the Type dropdown:
        - 3306 MySQL/MariaDB
        - 5432 Postgres
        - 1433 MSSQL
    - Source type: Custom
    - Source: add all the IP Addresses from the article [Relyance AI IP Addresses for Allow Lists](/docs/integrations/relyance-ai-ip-addresses-for-allow-lists/)
- Click Save rules.

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611469965.png)

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611473037.png)

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611473165.png)

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611473549.png)

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175597395213.png)

#### In the Relyance AI application:

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175597396621.png)
- Login to your Relyance Admin account.
- Navigate to the Settings Menu in the bottom left-hand side.
- Select Integrations.
- Find the Amazon RDS integration card and click it to open its connections.
- On the **Authentication** step, choose **Direct Connection** under **Authentication Method**.
- Paste the **Endpoint**, **Port**, **Engine Type** (`mysql`, `mariadb`, `postgres` or `sqlserver`), **Database Username**, and **Password** into their respective fields.
- Fill in the **Crawler Configuration** field to scope which databases and tables are crawled (see [Relyance Crawler](#relyance-crawler) above).
- Additional Features:
    - Select the Enable Data Inspection checkbox if you wish Relyance also to inspect the data. Adjust the Sampling Percent and Min Likelihood as needed.
    - For more information on Relyance features, please refer to this help center article: [here](/docs/introduction-to-relyance-ai/integration-features/#h_01J01Z9X7W2ZN71X9XEB3JR8KZ).
- Click Connect.
- At this point, you should see the following result on the Vendor Integrations page:
- Congratulations, you are now connected to Amazon RDS.

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175597396237.png)

### AWS RDS via IAM-based Authentication

#### Details

In order to integrate Relyance with AWS Lambda, Relyance will need to assume a role on your behalf. Role assumption in AWS allows entities (like IAM users, services, or even external identities) to take on an IAM role, granting them temporary permissions to perform specific actions on specific resources without having to attach permissions directly to their identity. By assuming a role, one gets temporary security credentials to act with the permissions of the role, ensuring a flexible and secure way to delegate and segregate duties without distributing long-lived credentials. There are two necessary preconditions that must be met for Relyance AI to assume a role.

- It needs to have permission to use the sts:AssumeRole action for the specific role.
- The role must have a trust policy that allows Relyance AI to use it.

#### Relyance Crawler

Relyance RDS integrations utilize a crawler that will list all RDS instances in a specific region. We will require the same Database User to be available across all of them in order to connect.
You can control the behavior of the crawler via Crawler Configuration field.

If you have specific RDS instances that you want Relyance to scan, add them to `allow_list`; alternatively if you want to scan all RDS instances except a specific set, add them to `block_list`.

```json
{
  "allow_list": [
    ""
  ],
  "block_list": [
    ""
  ]
}
```

### In AWS Console:

When you connect your Amazon RDS to Relyance you will need your Role ARN, External ID, Region, Database User. Follow the below steps to create them.

- Log in to your AWS management console.
- Copy your Account ID from the top-right profile dropdown menu.
- We suggest that you utilize IAM-based authentication since it uses AWS IAM to generate a short lived password that can be used for establishing a SQL connection.
- Use IAM-based Authentication:
- Navigate to the IAM console and create a new policy.

Switch editor to JSON and enter:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RelyanceIamDbAccess",
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:*:{{ YOUR_AWS_ACCOUNT }}:dbuser:*/relyance_user"
    },
    {
      "Sid": "RelyanceRdsCrawler",
      "Effect": "Allow",
      "Action": "rds:DescribeDBInstances",
      "Resource": "*"
    }
  ]
}
```

- Name the policy (e.g. RelyanceRDSAccessPolicy) - and click Create Policy.
- Create a new Role for Relyance to list and access your AWS RDS resources:
- Navigate to IAM > Roles section to create a new role and click on “create role”.
- Select Trusted Entity **“AWS Account”** and choose **“Another AWS account”** and use Relyance account ID: **“580082088342”**
- Enable **“Require external ID”** and fill in an External ID. This is a secret you only use to integrate with Relyance.
- The external ID is a secret that you will use and enter in the Relyance platform for additional security. While it could be anything, we recommend using a secret generator such as [https://www.uuidgenerator.net/version4](https://www.uuidgenerator.net/version4) to generate.
- In the next page, select **RelyanceRDSAccessPolicy** which gives Relyance permission to list rds instances and use IAM-based authentication.
- Give the Role a meaningful name (eg: **RelyanceRdsRole** ) and a description and follow the wizard to create the role.
- Note the Role Name to be used in Relyance.
- Once the role is created, click on the Trust Relationships tab and update the trust policy to the following:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::580082088342:user/tenant-prod-access"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<< external ID >>"
        }
      }
    }
  ]
}
```

Ensure you replace '<< external ID >>' with the external ID you created previously.

#### In the Relyance AI application:

- Login to your Relyance account.
- Navigate to the Settings Menu in the bottom left-hand side.
- Select Integrations.
- Click on the Vendor Integration tab.
- Find the Amazon RDS integration card and click it to open its connections.
- On the **Authentication** step, choose **IAM-based Auth** under **Authentication Method**.
- Paste the **Role ARN**, **External ID**, **Region** and (optionally) **Database User** into their respective fields.
- Fill in the **Crawler Configuration** field to scope which databases and tables are crawled.
- Additional Features:
    - Select the Enable Data Inspection checkbox if you wish Relyance also to inspect the data.
    - Adjust the Sampling Percent and Min Likelihood as needed.
    - For more information on Relyance features, please refer to this help center article: [here](/docs/introduction-to-relyance-ai/integration-features/#h_01J01Z9X7W2ZN71X9XEB3JR8KZ).
- Click Connect
- At this point, you should see the following result on the Vendor Integrations page:
- Congratulations, you are now connected to Amazon RDS

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611475853.png)

![Screenshot](https://assets.relyanceuat.xyz/images/docs/6793782451597/40175611476365.png)

![The Authentication step for Amazon RDS](https://assets.relyanceuat.xyz/images/docs/ui/aws_rds/06-wizard-authentication.png)

### Choosing a method

| Method | Credential | Where the scan runs |
| --- | --- | --- |
| **IAM-based Auth** | IAM role + `rds-db:connect` — no database password to rotate | Outpost in EKS, or Relyance-hosted over the approved network path |
| AWS Lambda (legacy) | IAM role, invoking a function in your account | Inside your VPC; retained for existing configurations |
| Direct Connection | database username and **password** | Outpost in EKS, or Relyance-hosted over the approved network path |

Use **IAM-based Auth** when the database and dedicated user are configured for IAM authentication; RDS mints a short-lived token for each connection. Use **Direct Connection** for a dedicated password user. Either can use Outpost's approved private network path. The **AWS Lambda** method is deprecated for new connections; do not introduce it to reach a private database from Outpost.

### Verify the connection is really working

Two layers of authorisation apply, and they fail at different moments:

| Grant | Where | Used for |
| --- | --- | --- |
| `rds-db:connect` | IAM | opening an IAM-authenticated connection |
| `rds:DescribeDBInstances` | IAM | discovering instances (IAM-based Auth and Lambda) |
| `lambda:InvokeFunction` | IAM | invoking the function (AWS Lambda method only) |
| `SELECT`, `SHOW VIEW`, `EXECUTE` | **inside the database** | reading schemas, views and routines to classify them |

1. **Authentication succeeds and the scan finds nothing.** This is almost always
   the database-side grants. IAM gets Relyance *connected*; `SELECT` and
   `SHOW VIEW` are what let it read. A user with no grants can log in perfectly
   and see no tables.
2. **A connection timeout rather than a permission error** points at network
   reach, not credentials: the security group must admit the
   [Relyance egress IPs](/docs/integrations/relyance-ai-ip-addresses-for-allow-lists/)
   for the region hosting your tenant when using hosted public connectivity. For Outpost, check the EKS network path and its security-group source instead. Keep private databases private and use the approved Outpost or hosted VPN path.
3. **IAM-based Auth fails at Authenticate.** The database user has to exist *and*
   be created for IAM authentication — `AWSAuthenticationPlugin` on
   MySQL/MariaDB. An ordinary password user with the same name will not
   authenticate by token.
4. **Fewer schemas than expected.** The **Crawler Configuration** is the scope;
   deny entries win over allow entries.

### Terraform with an Outpost credential ARN

Use provider `Relyance/relyance` 1.1.1 or a later release verified with Relyance, configured as in [Outpost connection setup](/docs/introduction-to-relyance-ai/how-outpost-works/#step-4-add-connections). This example references an existing AWS Secrets Manager secret and leaves the connection unconnected while you verify the deployment. Keep credential values out of `auth.params`, `auth.secrets_wo` and Terraform state; use the [BYOK secret schema](/docs/introduction-to-relyance-ai/outpost-connection-credentials/#aws-inventory-rds-and-clickhouse-secret-examples).

```hcl
variable "rds_secret_arn" {
  type        = string
  description = "Full credential secret ARN in the Outpost deployment account"
}

resource "relyance_integration_connection" "rds" {
  vendor       = "aws_rds"
  name         = "PostgreSQL RDS (Outpost)"
  runtime_mode = "IN_HOST_BYOK"
  connect_on_apply = false
  secret_ref   = var.rds_secret_arn

  auth = {
    method = "username-password"
  }

  scans = {
    "data-inspection" = { enabled = false }
  }
}
```

The ARN is a reference, not a credential value. It must belong to the registered deployment account. Save the raw-sample storage policy and review the separate sanitized-context setting under [What Relyance receives](/docs/introduction-to-relyance-ai/how-outpost-works/#what-relyance-receives). Enable/connect only after the [deployment and source checks](/docs/introduction-to-relyance-ai/how-outpost-works/#step-5-check-the-deployment) pass. The generated examples below use hosted credential handling.

<!-- terraform-examples:begin (generated from the integration catalog; do not hand-edit) -->

## Manage this integration with Terraform

Connections for this integration can be managed as code with the [Relyance Terraform provider](https://registry.terraform.io/providers/Relyance/relyance/latest). Non-secret fields go in `auth.params`; secret fields go in `auth.secrets_wo`, which is write-only — never stored in Terraform state. Rotate secrets by bumping `auth.secrets_wo_version`.

### AWS IAM role — AWS Lambda

```hcl
resource "relyance_integration_connection" "aws_rds_0" {
  vendor = "aws_rds"
  name   = "<your connection name>"

  auth = {
    method = "iam-role-aws-lambda"
    params = {
      account_id = "<account_id>"
      role_name = "<role_name>"
      region = "<region>"
      lambda_function_name = "<lambda_function_name>"
      crawler_rules = jsonencode({
        allow_list = [
          ""
        ]
        block_list = [
          ""
        ]
      })
    }
    # Secret fields are write-only: sent to Relyance, never stored in state.
    secrets_wo = {
      external_id = var.aws_rds_external_id
      use_iam_based_auth = "true"
      secret_name = var.aws_rds_secret_name
    }
    secrets_wo_version = 1
  }

  scans = { "data-inspection" = { enabled = true } }
}
```

### Username & password

```hcl
resource "relyance_integration_connection" "aws_rds_1" {
  vendor = "aws_rds"
  name   = "<your connection name>"

  auth = {
    method = "username-password"
    params = {
      endpoint = "<endpoint>"
      port = "<port>"
      crawler_rules = jsonencode({
        allow_list = [
          ""
        ]
        block_list = [
          ""
        ]
      })
      engine = "<engine>"
      username = "<username>"
    }
    # Secret fields are write-only: sent to Relyance, never stored in state.
    secrets_wo = {
      password = var.aws_rds_password
    }
    secrets_wo_version = 1
  }

  scans = { "data-inspection" = { enabled = true } }
}
```

### AWS IAM role — IAM-based Auth

```hcl
resource "relyance_integration_connection" "aws_rds_2" {
  vendor = "aws_rds"
  name   = "<your connection name>"

  auth = {
    method = "iam-role-based"
    params = {
      role_arn = "<role_arn>"
      region = "<region>"
      crawler_rules = jsonencode({
        allow_list = [
          ""
        ]
        block_list = [
          ""
        ]
      })
    }
    # Secret fields are write-only: sent to Relyance, never stored in state.
    secrets_wo = {
      external_id = var.aws_rds_external_id
    }
    secrets_wo_version = 1
  }

  scans = { "data-inspection" = { enabled = true } }
}
```

<!-- terraform-examples:end -->