risingwavelabs · Copilot · Mar 19, 2026 · Mar 23, 2026 · Mar 25, 2026 · Mar 25, 2026
diff --git a/cloud/cloud-metadata.mdx b/cloud/cloud-metadata.mdx
@@ -0,0 +1,62 @@
+---
+title: "Cloud metadata"
+sidebarTitle: "Cloud metadata"
+description: "View and use the cloud metadata values exposed in the RisingWave Cloud Console, including the IAM role ARN, PrivateLink Principal, and egress public IPs for your project."
+---
+
+RisingWave Cloud exposes a set of environment-specific metadata values for each project. These values are required when setting up cross-account access (IAM role assume) and PrivateLink connections. All values are read-only and are generated automatically when a project is created.
+
+## Where to find cloud metadata
+
+In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Then select the **Cloud Meta** tab.
+
+<Frame>
+<img src="/images/cloud/cloud-metadata/connection-cloud-meta.png" alt="Cloud Meta tab in the Connection page of the RisingWave Cloud Console"/>
+</Frame>
+
+<Note>
+Cloud metadata is only available for projects on the **Standard** plan or above.
+</Note>
+
+## Metadata fields
+
+### IAM role ARN
+
+| Field | Example value |
+|:------|:--------------|
+| **IAM role ARN** | `arn:aws:iam::123456789012:role/risingwave-cloud-project-abc123` |
+
+The AWS IAM role ARN that RisingWave Cloud uses to access AWS resources on behalf of this project. When you configure [IAM role assume](/cloud/iam-role-assume) (cross-account S3 access), you add this ARN as a trusted principal in your IAM role's trust policy.
+
+### PrivateLink Principal
+
+| Field | Example value |
+|:------|:--------------|
+| **PrivateLink Principal** | `arn:aws:iam::123456789012:root` |
+
+The AWS principal associated with the RisingWave Cloud deployment that hosts your project. When you create a PrivateLink endpoint service in your AWS account, add this principal to the list of **Allowed principals** so that RisingWave Cloud can connect to your service.
+
+### Egress public IPs
+
+| Field | Example value |
+|:------|:--------------|
+| **Egress public IPs** | `203.0.113.10, 203.0.113.11` |
+
+The public IP addresses from which outbound traffic from this project originates. Add these IPs to the allowlist of any firewall rules or security groups that restrict inbound access to your services (for example, a database or Kafka cluster that RisingWave connects to).
+
+## Cloud metadata by platform
+
+| Metadata field | AWS | GCP | Azure |
+|:---------------|:----|:----|:------|
+| IAM role ARN   | ✅  | ✅ (service account email) | ✅ (managed identity resource ID) |
+| PrivateLink Principal | ✅ (AWS account ARN) | ✅ (GCP project number) | ✅ (Azure subscription ID) |
+| Egress public IPs | ✅  | ✅  | ✅    |
+
+<Note>
+GCP and Azure metadata field names differ from the AWS equivalents. The Console labels each field for the platform of your project.
+</Note>
+
+## Next steps
+
+- [Set up IAM role assume](/cloud/iam-role-assume) — use the IAM role ARN to grant RisingWave Cloud cross-account S3 access.
+- [Configure PrivateLink](/cloud/create-a-connection) — use the PrivateLink Principal when setting up your endpoint service's allowed principals.
diff --git a/cloud/create-a-connection.mdx b/cloud/create-a-connection.mdx
@@ -30,8 +30,8 @@ You need to set up a PrivateLink service in your VPC and make sure it runs prope
 
 ## Create PrivateLink connection
 
-1. Go to the [**Project**](https://cloud.risingwave.com/project/home/) page and select the project you want to connect the VPC to.
-2. Select **PrivateLink** tab, and click **Create PrivateLink**.
+1. In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar.
+2. Select the **PrivateLink** tab, and click **Create PrivateLink**.
 3. For **Name**, enter a descriptive name for the connection.
 4. For **Endpoint service name** or **Service attachment** or **Private link service resource ID:**
 
@@ -85,5 +85,5 @@ For details on how to use the VPC endpoint to create a source with the PrivateLi
 
 When you no longer need a connection:
 
-1. Go to the [**Connection**](https://cloud.risingwave.com/connection/) page and click **Create PrivateLink**.
+1. In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Select the **PrivateLink** tab.
 2. Hover over the connection you want to drop and click the delete button, then confirm the deletion.
diff --git a/cloud/iam-role-assume.mdx b/cloud/iam-role-assume.mdx
@@ -0,0 +1,162 @@
+---
+title: "Set up IAM role assume"
+sidebarTitle: "IAM role assume"
+description: "Configure cross-account S3 access so that RisingWave Cloud can assume an IAM role in your AWS account without sharing long-term credentials."
+---
+
+IAM role assume (also called cross-account role delegation) lets RisingWave Cloud call `sts:AssumeRole` to obtain temporary credentials for your AWS IAM role. This avoids storing long-term access keys and follows AWS security best practices.
+
+Use this method when you want RisingWave Cloud to read from or write to an S3 bucket in **your** AWS account using a role you control.
+
+## How it works
+
+```
+RisingWave Cloud (AWS account: <rw-account-id>)
+  → calls sts:AssumeRole
+  → on: arn:aws:iam::<your-account-id>:role/<your-role>
+  → receives temporary credentials
+  → accesses your S3 bucket
+```
+
+1. You create an IAM role in your AWS account with the required S3 permissions.
+2. You configure the role's trust policy to allow RisingWave Cloud's IAM role ARN to assume it.
+3. You set `s3.assume_role` (or `s3.iam_role_arn`) in your RisingWave SQL statement to the ARN of your role.
+
+## Required cloud metadata values
+
+Before you begin, retrieve the following values from your project's [Cloud metadata](/cloud/cloud-metadata) page in the RisingWave Cloud Console (**Connection** → **Cloud Meta** tab):
+
+| Metadata field | Where it's used |
+|:---------------|:----------------|
+| **IAM role ARN** | The `Principal.AWS` value in your IAM trust policy |
+
+## Step-by-step setup
+
+### Step 1 — Create an IAM policy for S3 access
+
+Create a policy that grants RisingWave the necessary permissions on your S3 bucket. Replace `<bucket>` and `<prefix>` with your values.
+
+```json Example: S3 read/write policy
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": [
+                "s3:PutObject",
+                "s3:GetObject",
+                "s3:GetObjectVersion",
+                "s3:DeleteObject",
+                "s3:DeleteObjectVersion"
+            ],
+            "Resource": "arn:aws:s3:::<bucket>/<prefix>/*"
+        },
+        {
+            "Effect": "Allow",
+            "Action": [
+                "s3:ListBucket",
+                "s3:GetBucketLocation"
+            ],
+            "Resource": "arn:aws:s3:::<bucket>",
+            "Condition": {
+                "StringLike": {
+                    "s3:prefix": ["<prefix>/*"]
+                }
+            }
+        }
+    ]
+}
+```
+
+### Step 2 — Create an IAM role with the policy attached
+
+1. In the [AWS IAM console](https://console.aws.amazon.com/iam/), create a new role.
+2. Select **Another AWS account** as the trusted entity type and enter the AWS account ID extracted from the **IAM role ARN** (the 12-digit number after `iam::`).
+3. Attach the S3 policy created in Step 1.
+
+### Step 3 — Configure the trust policy
+
+After the role is created, update its trust policy to allow the specific RisingWave Cloud IAM role to assume it.
+
+Replace `<iam-role-arn>` with the **IAM role ARN** from Cloud metadata.
+
+```json Example: Trust policy
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Principal": {
+                "AWS": "<iam-role-arn>"
+            },
+            "Action": "sts:AssumeRole"
+        }
+    ]
+}
+```
+
+### Step 4 — Use the role in RisingWave
+
+Set `s3.assume_role` to the ARN of the role you created in Step 2 and set `enable_config_load = 'true'` (RisingWave Cloud only).
+
+```sql Example: Sink using IAM role assume
+CREATE SINK my_sink FROM my_source WITH (
+    connector = 'redshift',             -- or 'snowflake_v2', 'iceberg', etc.
+
+    -- S3 staging
+    s3.bucket_name    = '<your-bucket>',
+    s3.region_name    = '<your-region>',
+    s3.path           = '<your-prefix>',
+
+    -- IAM role assume (no long-term credentials needed)
+    s3.assume_role    = 'arn:aws:iam::<your-account-id>:role/<your-role>',
+    enable_config_load = 'true',
+
+    -- other connector-specific parameters...
+);
+```
+
+For connectors that use `s3.iam_role_arn` instead of `s3.assume_role` (for example, the Iceberg connector), use:
+
+```sql Example: Iceberg connector with IAM role assume
+CREATE SINK my_iceberg_sink FROM my_mv WITH (
+    connector = 'iceberg',
+    type      = 'append-only',
+    -- ...
+    s3.iam_role_arn    = 'arn:aws:iam::<your-account-id>:role/<your-role>',
+    enable_config_load = 'true',
+);
+```
+
+## Verify the setup
+
+After creating the sink or source, run a quick sanity check:
+
+1. **Check that the role is assumable** — in the AWS console, use **IAM → Roles → \<your-role\> → Trust relationships** to confirm the correct principal and condition are present.
+2. **Check S3 permissions** — run an `aws s3 ls s3://<bucket>/<prefix>/` command using the role (via `aws sts assume-role`) to verify read access.
+3. **Check RisingWave logs** — if the sink or source fails, look for `AccessDenied` or `InvalidClientTokenId` errors. These indicate a misconfigured trust policy or incorrect ARN.
+
+## Common errors
+
+| Error | Likely cause | Fix |
+|:------|:-------------|:----|
+| `AccessDenied` when calling `AssumeRole` | The trust policy principal doesn't match the RisingWave Cloud IAM role ARN | Copy the exact IAM role ARN from Cloud metadata and update the trust policy |
+| `AccessDenied` on S3 operations after assuming | The attached S3 policy is missing required actions | Add the missing S3 actions (see Step 1) |
+| `InvalidClientTokenId` | Incorrect IAM role ARN in the trust policy | Use the IAM role ARN from Cloud metadata |
+
+## Managing allowed principals in RisingWave Cloud
+
+To view and manage the IAM role ARNs that are authorized to access your project's resources via IAM Assume Role, go to your project in the [RisingWave Cloud Console](https://cloud.risingwave.com), click **Connection** in the left sidebar, and select the **Allowed Principals** tab.
+
+<Frame>
+<img src="/images/cloud/iam-role-assume/connection-allowed-principals.png" alt="Allowed Principals tab in the Connection page of the RisingWave Cloud Console"/>
+</Frame>
+
+Click **+ Add Principal** to add an IAM Role ARN that is allowed to access this project's resources.
+
+## Related pages
+
+- [Cloud metadata](/cloud/cloud-metadata) — retrieve the IAM role ARN for your project
+- [PrivateLink connection configuration](/cloud/create-a-connection) — set up private network connectivity
+- [Sink to Amazon Redshift](/integrations/destinations/redshift) — end-to-end example with S3 staging
+- [Sink to Snowflake](/integrations/destinations/snowflake-v2) — end-to-end example with S3 staging
diff --git a/cloud/privatelink-overview.mdx b/cloud/privatelink-overview.mdx
@@ -29,4 +29,12 @@ All data transmitted through PrivateLink connections is automatically encrypted
 
 On the **RisingWave Cloud** side, RisingWave Cloud will create an endpoint (specifically an AWS VPC endpoint, GCP Private Service Connect endpoint, or Azure private endpoint) and bind it with one running RisingWave project.
 
-On the **Customer** side, you need to set up a PrivateLink service (specifically an AWS endpoint service, GCP published service, or Azure Private Link service) in your VPC network first.
+On the **Customer** side, you need to set up a PrivateLink service (specifically an AWS endpoint service, GCP published service, or Azure Private Link service) in your VPC network first.
+
+## Accessing PrivateLink in the Console
+
+In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Then select the **PrivateLink** tab to create and manage PrivateLink connections.
+
+<Tip>
+When setting up an AWS endpoint service, add the **PrivateLink Principal** from your project's **Cloud Meta** tab ([Cloud metadata](/cloud/cloud-metadata)) to the service's allowed principals list so that RisingWave Cloud can connect.
+</Tip>
diff --git a/docs.json b/docs.json
@@ -525,6 +525,8 @@
                       "cloud/manage-resources",
                       "cloud/manage-database-users",
                       "cloud/manage-backups",
+                      "cloud/cloud-metadata",
+                      "cloud/iam-role-assume",
                       {
                         "group": "PrivateLink",
                         "pages": [

diff --git a/iceberg/object-storage.mdx b/iceberg/object-storage.mdx
@@ -24,7 +24,7 @@ These parameters configure the connection to an S3-compatible storage system, su
 <Note>
 In RisingWave Cloud, you have two options:
 - Provide `s3.access.key` and `s3.secret.key`, or
-- Use IAM role delegation: grant S3 permissions to your own IAM role, allow the RisingWave Cloud tenant role to assume it, then set `s3.iam_role_arn = '<your_role_arn>'` and `enable_config_load = true`. The setup is the same as in the Snowflake sink guide: [Set up S3 IAM and role](/integrations/destinations/snowflake-v2#set-up-s3-iam-and-role).
+- Use IAM role delegation: grant S3 permissions to your own IAM role, allow the RisingWave Cloud tenant role to assume it, then set `s3.iam_role_arn = '<your_role_arn>'` and `enable_config_load = true`. See [Set up IAM role assume](/cloud/iam-role-assume) for a step-by-step guide, including how to retrieve the required IAM role ARN and external ID from the [Cloud metadata](/cloud/cloud-metadata) page.
 
 If you use a REST catalog with **vended credentials** (`vended_credentials = true`), you can omit S3 credentials here because the catalog server provides temporary credentials.
 

diff --git a/images/cloud/cloud-metadata/connection-cloud-meta.png b/images/cloud/cloud-metadata/connection-cloud-meta.png
diff --git a/images/cloud/iam-role-assume/connection-allowed-principals.png b/images/cloud/iam-role-assume/connection-allowed-principals.png
diff --git a/integrations/destinations/redshift.mdx b/integrations/destinations/redshift.mdx
@@ -95,10 +95,12 @@ enable_config_load = 'true',
 ```
 
 To use this method, you need to configure an IAM Role in AWS that RisingWave can assume. This involves:
-1. Obtaining the RisingWave service ARN from our [support team](mailto:cloud-support@risingwave-labs.com).
+1. Obtaining the RisingWave Cloud IAM role ARN and external ID from the [Cloud metadata](/cloud/cloud-metadata) page in the Console (**Settings** → **Cloud metadata**).
 2. Creating an IAM policy with the necessary S3 read/write permissions for your bucket and prefix.
 3. Configuring the IAM Role's trust policy to allow the RisingWave service ARN to assume it.
 
+For a complete step-by-step walkthrough, see [Set up IAM role assume](/cloud/iam-role-assume).
+
 ## Append-only and upsert modes
 
 Amazon Redshift sink connector supports both `append-only` and `upsert` modes for flexible data handling.

diff --git a/integrations/destinations/snowflake-v2.mdx b/integrations/destinations/snowflake-v2.mdx
@@ -167,10 +167,12 @@ enable_config_load = 'true',
 ```
 
 To use this method, you need to configure an IAM Role in AWS that RisingWave can assume. This involves:
-1. Obtaining the RisingWave service ARN from our [support team](mailto:cloud-support@risingwave-labs.com).
+1. Obtaining the RisingWave Cloud IAM role ARN and external ID from the [Cloud metadata](/cloud/cloud-metadata) page in the Console (**Settings** → **Cloud metadata**).
 2. Creating an IAM policy with the necessary S3 read/write permissions for your bucket and prefix.
 3. Configuring the IAM Role's trust policy to allow the RisingWave service ARN to assume it.
 
+For a complete step-by-step walkthrough, see [Set up IAM role assume](/cloud/iam-role-assume).
+
 ## Append-only and upsert modes
 
 Snowflake v2 sink connector supports both modes for flexible data handling.
@@ -443,7 +445,7 @@ RisingWave supports direct access to S3 using Access Key / Secret Key (AK/SK) by
 }
 ```
 
-2. Configure the following additional trusted entities for your IAM Role to allow RisingWave arn to assume the role. Contact our [support team](mailto:cloud-support@risingwave-labs.com) to obtain the correct role to use. Please don’t click required external id to trust RisingWave arn here.
+2. Configure the following additional trusted entities for your IAM Role to allow RisingWave to assume the role. Obtain the IAM role ARN and external ID from the [Cloud metadata](/cloud/cloud-metadata) page (**Settings** → **Cloud metadata**). See [Set up IAM role assume](/cloud/iam-role-assume) for a complete walkthrough.
 
 ```json Example
 {