> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coverbase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Amazon S3
> Share your third-party risk tables into your own S3 bucket on a schedule as CSV, JSON Lines or Parquet, written by a role in your account that Coverbase assumes with an external ID.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
An Amazon S3 destination is part of [warehouse data share](/products/warehouse-data-share). Coverbase stores no secret for it. It assumes an IAM role in your account, using an external ID generated for that one destination, and writes files under the prefix you choose.
## How access works
```mermaid theme={null}
sequenceDiagram
participant CB as Coverbase share role
participant STS as AWS STS
participant Role as Your IAM role
participant S3 as Your bucket
CB->>STS: AssumeRole(your role, external ID)
STS->>Role: Trust policy: principal and external ID match?
STS-->>CB: Short-lived credentials
CB->>S3: PutObject under your prefix
```
* **One principal.** Your role trusts a single, dedicated Coverbase role that exists only to assume customer share roles. The destination card shows it under **AWS principals your role must trust**. Coverbase's services reach your role only through it.
* **One external ID per destination.** It is generated when you save the destination, starts with `coverbase-`, and is shown on the card. Coverbase's share role may only assume a role that demands a `coverbase-` external ID and sits outside Coverbase's own AWS account, and yours demands this destination's, so your role cannot be used for another customer's destination. A role ARN in Coverbase's own account is refused when you save.
## Prepare the bucket and role
1. Choose a bucket and a prefix for Coverbase's files.
2. Create an IAM role with a policy that allows `s3:PutObject` under that prefix, for example:
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket/coverbase/*"
}
]
}
```
You finish the role's trust policy after saving the destination in Coverbase, when the external ID exists.
## Add the destination in Coverbase
1. Open **Configuration → Data Share** and click **Add destination**.
2. Choose **Amazon S3**, give it a **Name**, and choose **Hourly** or **Daily**.
3. Enter the **Bucket**, **Prefix**, **Region** and **IAM Role ARN**, and choose the **File Format**: **CSV (gzip)**, **JSON Lines (gzip)** or **Parquet (snappy)**.
4. Click **Add destination**.
5. On the destination card, click **Copy trust policy** and set it as your role's trust policy. It has this shape, with the principal and external ID filled in:
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "coverbase-" } }
}
]
}
```
6. Click **Test connection**, then **Sync now**.
## What lands in the bucket
* Files at `//synced_date=YYYY-MM-DD/-.`, in the format you chose.
* Each table's contract at `/_contract/.json`.
* Each sync appends the rows that changed, stamped with `_cb_synced_at`. Deduplicate on `id`, keeping the latest `_cb_synced_at`. The `services` table is a full snapshot on every run.
## Related
Run logs, pausing and the table contract.
Why the external ID matters.
The Snowflake destination.
The BigQuery destination.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.