Amazon S3
IAM Role (Recommended)
Cross-account IAM roles let Avala access your bucket using temporary credentials — no long-lived keys to rotate or leak. Avala assumes a role in your AWS account using STS AssumeRole with an external ID for confused deputy protection.1. Get Your Setup Info
Go to Mission Control → Settings → Storage → Add Storage → Amazon S3. Select IAM Role as the authentication method. You will see two values:- Avala AWS Account ID — the account that will assume your role
- External ID — a unique identifier for your organization (used in the trust policy)
If your account belongs to multiple organizations, you must pass the
organization parameter (your organization’s slug) to all storage config API calls. Single-organization accounts can omit it.2. Create an IAM Role
In your AWS account, create an IAM role with the following trust policy. ReplaceAVALA_ACCOUNT_ID and EXTERNAL_ID with the values from Step 1.
3. Attach a Permissions Policy
Attach an inline or managed policy that grants Avala access to your bucket:s3:PutObject.
Replace your-bucket-name with your actual bucket name.
4. Connect in Mission Control
- Go to Mission Control → Settings → Storage.
- Click Add Storage and select Amazon S3.
- Select IAM Role as the authentication method.
- Enter the Role ARN (e.g.,
arn:aws:iam::123456789012:role/AvalaStorageAccess). - Enter your Bucket Name and Region.
- Click Test Connection to verify access.
- Save the configuration.
Access Key (Legacy)
You can also authenticate with long-lived AWS access keys. This method is still supported but not recommended — IAM roles are more secure because credentials are temporary and automatically rotated.- Create an IAM user with programmatic access.
- Attach the same permissions policy shown above.
- In Mission Control, select Access Key as the authentication method.
- Enter the Access Key ID and Secret Access Key.
- Click Test Connection and save.
CORS Configuration
The browser-based editor loads your objects directly from your bucket, so the bucket must allow cross-origin requests fromhttps://avala.ai. Add this CORS rule:
Why the extra
ExposeHeaders? Large files — MCAP recordings especially — are streamed with HTTP range requests rather than downloaded whole. The browser can only read a response header that is explicitly exposed, and the range machinery needs Content-Range, Content-Length and Accept-Ranges. Exposing only ETag is enough for images, but MCAP episodes will fail to open.Google Cloud Storage
Service Account
Create a service account that Avala can use to access your bucket:- In the Google Cloud Console, navigate to IAM & Admin > Service Accounts.
- Create a new service account (e.g.,
avala-storage-reader). - Grant the following roles on the bucket:
roles/storage.objectViewer— read access to objectsroles/storage.legacyBucketReader— list objects in the bucket
- If Avala should write exports to the bucket, also grant
roles/storage.objectCreator. - Download the JSON key file for the service account.
CORS Configuration
The browser-based editor loads your objects directly from your bucket, so the bucket must allow cross-origin requests fromhttps://avala.ai. Save the following as cors.json:
your-bucket-name with your actual bucket name. (The older gsutil cors set cors.json gs://your-bucket-name still works.)
Connect in Mission Control
- Go to Mission Control > Settings > Storage.
- Click Add Storage and select Google Cloud Storage.
- Enter your Bucket Name.
- Upload the Service Account JSON key file.
- Click Test Connection to verify access.
- Save the configuration.
Storage Configuration Options
Once a bucket is connected, you can configure it in Mission Control:Uploading Data from Connected Buckets
After connecting a bucket, you can create datasets from its contents:- Create a new dataset in Mission Control.
- Select Import from Cloud Storage as the data source.
- Browse or search the connected bucket for the files or folder you want.
- Select the assets and confirm the import.