Create the AWS account and bucket

This is the first of three stages on the AWS side, and it all happens in the AWS Management Console rather than in Salesforce. By the end you will have a bucket and the region code it lives in.

Using a different provider? Backblaze B2, Wasabi, Cloudflare R2 and MinIO work the same way. See S3-compatible providers. The Salesforce side is identical regardless of provider.

1. Create an AWS account

Skip this if you already have one.

1. Go to https://aws.amazon.com/ and click Create an AWS Account.
2. Provide email, account name, billing info, and verify your phone number. AWS requires a credit card even for the free tier.
3. Choose the Basic Support - Free plan when prompted.
4. Sign in to the AWS Management Console as the root user.

Security note: don’t use the root user for day-to-day work. After first login, AWS will prompt you to enable MFA on the root account and create an IAM admin user

• do both. The rest of this guide assumes you have an admin IAM user (not root) signed in.

2. Pick a region

Every S3 bucket lives in a single AWS region. Pick the one closest to your Salesforce org and your users: it affects upload and download latency, and the speed of calls from Salesforce to S3. Common choices:

Region code	Location
us-east-1	N. Virginia (default)
us-east-2	Ohio
us-west-2	Oregon
eu-west-1	Ireland
eu-central-1	Frankfurt
ap-southeast-2	Sydney

Write down the exact region code. You will enter it as the Region in Sliick Settings, and it must match the bucket’s region or AWS will reject every signed request with SignatureDoesNotMatch.

In the top-right of the AWS console, click the region dropdown and select your chosen region. Stay in this region for the rest of the AWS setup.

3. Create the S3 bucket

1. In the AWS console search bar, type S3 and open the S3 service.
2. Click Create bucket.
3. Bucket name - must be globally unique across all of AWS. Use something like sliick-files-acme-prod (lowercase, hyphens, no underscores). Write the exact name down.
4. AWS Region - confirm it matches the region you picked above.
5. Object Ownership - leave at ACLs disabled (recommended).
6. Block Public Access settings - leave all four boxes checked. Sliick Files uses presigned URLs for browser access; the bucket should never be publicly readable.
7. Bucket Versioning - Enable. This is the safety net behind Sliick’s Restore: deleting a file in Salesforce places a delete marker, and the Deleted Files tab’s Restore removes it, un-deleting the object. With versioning off, deletes are immediate and permanent and Restore reports the file as gone. Sliick still manages its own user-facing version history separately, so this setting is only about recovering deleted files.
8. Default encryption - leave at SSE-S3 (Amazon S3 managed keys). SSE-KMS as the bucket default also works, because objects encrypt transparently.
9. Object Lock - leave Disabled.
10. Click Create bucket.

What is not supported: a bucket policy that denies s3:PutObject unless the request carries explicit x-amz-server-side-encryption headers, a common enterprise guardrail. Sliick Files does not send those headers, so every upload would fail with a 403 or 400. Enforce encryption through the bucket default instead.

4. Add two lifecycle rules

Both are recommended rather than required, and both stop storage cost accumulating invisibly. Add them under the bucket’s Management → Create lifecycle rule.

Rule	What it does
Delete incomplete multipart uploads after 2 days	Large-file transfers stream in parts. If a transfer is interrupted and the cleanup call also fails, the parts linger invisibly and accrue cost. Sliick logs the leak, but clearing it is the bucket’s job
Expire noncurrent versions after 100 days	With bucket versioning on, every deleted object leaves an older generation behind. 100 days matches Sliick’s own Deleted Files retention, after which the file is no longer recoverable through the UI anyway

Next: Configure CORS on the bucket.