← Back to Blog

Document Management with AWS S3: Bring Your Own Bucket

April 24, 2026 · 8 min read

Most Document Tools Force You to Hand Over Your Files

Every team that runs on AWS eventually asks the same question about their document management platform: "Why am I paying a SaaS vendor to re-host data that I already have infrastructure for?" Notion, Confluence, and Google Docs all store your files on their servers, in their regions, with their encryption keys, under their privacy policies. You pay them to hold your data, and you pay them again (in egress fees, export delays, or lock-in) if you ever want it back.

If you already have an AWS contract, an IAM setup, a compliance posture, and a region strategy, adding another vendor's storage layer on top is not just redundant — it is a step backward for security and control. Document management with AWS S3 inverts the model: your documents live in your bucket, in your region, governed by your policies. The software sits on top, but it does not hold the data.

DocsKing is built around this pattern. Every workspace can be pointed at an S3 bucket you own. Files are uploaded directly from the workspace to your bucket — DocsKing never stores the bytes. You keep the region, the IAM policies, the KMS keys, the lifecycle rules, and the backup schedule. This guide walks through why AWS customers choose BYOS, how DocsKing connects to S3, and what setup looks like in practice.

Why AWS Customers Choose Bring Your Own Storage

There are six reasons we hear repeatedly from teams moving documents into their own S3 buckets.

1. Region control for data residency

GDPR, Schrems II, the UK Data Protection Act, Germany's BDSG, Brazil's LGPD — they all care where your data physically lives. If you are a European legal firm, your documents need to stay in an EU region. If you are a Swiss bank, you may need Switzerland specifically. SaaS vendors typically pick one or two regions and call it a feature. With BYOS, you pick the exact region when you create the bucket, and the platform follows.

2. You already have a compliance program for AWS

If your organization is already SOC 2 Type II, HIPAA, or ISO 27001 certified on AWS, adding another vendor with its own compliance posture expands your audit surface. Keeping documents on S3 means they inherit your existing controls: your IAM policies, your CloudTrail logs, your GuardDuty alerts, your Macie scans. There is nothing new to audit.

3. You own your KMS keys

Customer-managed KMS keys are the gold standard for regulated industries. If you revoke the key, the data is cryptographically inaccessible to anyone — including us. That is a guarantee SaaS vendors cannot offer when they control the encryption. With an S3 bucket encrypted by your KMS key, revoking access is a single AWS CLI command, and it is enforceable.

4. Backup and DR policy stays yours

S3 Versioning, Cross-Region Replication, Object Lock, and Glacier tiering are all AWS-native features. Teams that have tuned these for years do not want a document vendor's "we back up your data" marketing page to replace them. With BYOS, your existing DR runbook applies unchanged.

5. Predictable storage costs at scale

SaaS document platforms often price per gigabyte of stored content, marked up 5–20x over S3 list prices. A team with a few hundred gigabytes of design files, RFPs, or contracts can pay thousands per year in storage markup alone. S3 Standard is about $0.023 per GB-month — Infrequent Access and Glacier are cheaper. With BYOS, you pay AWS list prices for the bytes and a flat subscription for the software.

6. Zero-friction exit

If you ever decide to leave DocsKing, there is nothing to export. Your files are already in your bucket. Revoke the IAM credentials, download the metadata, and you are done. No support tickets. No multi-week export jobs. No egress fees paid to your previous vendor.

How DocsKing Connects to Your S3 Bucket

The integration is deliberately simple. DocsKing uses a per-workspace storage configuration: each workspace can have its own named storage provider, so a marketing workspace might use Google Drive while a legal workspace uses S3. Configurations are stored encrypted in DocsKing's database, never shared between workspaces, and can be rotated independently.

When a user uploads a file, DocsKing's backend receives it, optionally encrypts it with AES-256-GCM at the application layer, and streams it directly to your S3 bucket at the DocsKing/{WorkspaceCode}/ prefix. The file never lands on DocsKing's disks. On download, the reverse happens: DocsKing fetches from your bucket, decrypts if needed, and streams to the user.

The credentials DocsKing holds are a single IAM access key/secret (or, for enterprise plans, an assumed-role ARN) with the minimum permissions required: s3:PutObject, s3:GetObject, s3:DeleteObject, and s3:ListBucket scoped to the specific bucket. You can tighten the bucket policy further with a prefix condition so the credentials can only touch DocsKing/*.

Setup in Five Steps

For a detailed walkthrough, see our secure workspace setup guide. At a high level, connecting an S3 bucket takes about ten minutes.

1. Create the bucket. In the AWS console, create a new S3 bucket in the region you need. Enable Versioning and (recommended) SSE-KMS with a customer-managed key. Block public access.
2. Create an IAM user for DocsKing. Programmatic access only. Attach an inline policy granting the four S3 actions above against the bucket ARN and <bucket>/DocsKing/* for object-level operations.
3. Generate an access key. Download the CSV. Do not commit it anywhere.
4. Add the storage config in DocsKing. Open your workspace settings → Storage → Add Configuration → AWS S3. Enter bucket name, region, access key, and secret. Click "Test connection."
5. Set it as default and (optionally) enable encryption at rest. New uploads now flow to your S3 bucket.

Once files have been uploaded, DocsKing locks the provider for that workspace to prevent accidental changes that would orphan files. You can still add additional storage configurations (for example, a Glacier-backed archive bucket) and let users pick per upload.

Frequently Asked Questions

Does DocsKing copy my documents to its own servers?

No. Files stream directly from the user's browser through DocsKing's backend into your S3 bucket. DocsKing stores only metadata (title, tags, author, timestamps) and a reference to the object key. The bytes stay in your AWS account.

What AWS permissions does DocsKing need?

An IAM user or role with s3:PutObject, s3:GetObject, s3:DeleteObject, and s3:ListBucket scoped to your bucket. You can further restrict with a prefix condition so the credentials only touch DocsKing/*.

Can I use KMS-encrypted S3 buckets?

Yes. SSE-KMS works transparently — DocsKing puts and gets objects, AWS handles the encryption. For an extra layer, DocsKing also offers per-workspace AES-256-GCM encryption at the application layer, so files are encrypted twice: once by DocsKing before upload, once by KMS on the bucket.

Which AWS regions are supported?

Any S3 region, including regulated ones like eu-central-1 (Frankfurt), eu-west-1 (Ireland), ap-south-1 (Mumbai), or us-gov-west-1 (GovCloud, with appropriate enterprise licensing).

What happens if I want to leave DocsKing?

The files are already in your bucket at a predictable prefix. Export the metadata from DocsKing (JSON via the API or SysAdmin export), revoke the IAM credentials, and you are done. No egress fees paid to DocsKing. No multi-week export job.

How do backups work with BYOS?

You own the backup policy. Turn on S3 Versioning for point-in-time recovery. Use S3 Cross-Region Replication for disaster recovery. Use Object Lock for WORM compliance (SEC 17a-4, FINRA). Configure lifecycle rules to tier cold files to Glacier. DocsKing does not interfere with any of this.

Does this work with the free plan?

BYOS is available on the Business plan and above. The Free and Team plans use DocsKing platform storage. You can start on Free, evaluate the product, and upgrade to Business when you are ready to point at your own bucket.