Zum Hauptinhalt springen
DocumentMS
Demo anfragenKostenlos testen
Deutsch

Integration

Amazon S3 document storage backend

DocumentMS can use an S3 bucket in your own AWS account as its storage backend, configurable at runtime rather than at deployment. Document bytes then sit in a region you chose, under your own bucket policy, lifecycle rules and CloudTrail logging.

Demo anfragenPreise ansehen

What this connection does

DocumentMS writes document bytes to an S3 bucket in your own AWS account, configured at runtime rather than fixed at deployment. The application still runs as a managed service; what changes is where the documents physically sit.

For organisations with data residency or key custody obligations this is usually the deciding capability, because it converts a vendor commitment into something you can verify yourself: your region, your bucket policy, your KMS keys, your lifecycle rules, your CloudTrail logging.

What you need on your side

Have these ready before you start; the configuration itself takes minutes.
  • An AWS account and an S3 bucket in the region you require
  • An IAM policy scoped to that bucket — DocumentMS needs object read, write and delete on it and nothing else
  • A decision on encryption: SSE-S3, or SSE-KMS with a customer-managed key
  • Enterprise tier, where customer-provided storage backends are available

Setting it up

Test with one user and one document before rolling out. Connection events and permission changes appear in the audit trail.

  1. Step 1: Create the bucket

    Create the bucket in your chosen region with versioning and default encryption enabled.

  2. Step 2: Scope an IAM policy

    Grant only the object operations needed on that one bucket. Avoid wildcard resources.

  3. Step 3: Connect

    Enter the bucket, region and credentials in DocumentMS; they are stored encrypted.

  4. Step 4: Verify

    Upload a test document and confirm the object appears in your bucket with the expected encryption applied.

Limits worth knowing before you rely on it

Stated up front rather than discovered later. Every integration has boundaries, and a directory that hides them just moves the discovery to a support ticket.
  • Only document bytes move to your bucket. Metadata, the search index and audit records are held by the platform — if your residency requirement covers those, say so during evaluation because it changes the answer
  • S3 Object Lock in compliance mode can prevent DocumentMS deleting objects when a retention period expires; align the lock configuration with your retention schedule or disposal will fail
  • You own the storage cost and the bucket lifecycle configuration, which is the point, but it means an unmanaged lifecycle rule can delete documents the application still expects to find

Zuletzt geprüft: 2026-09-01

Want to see this working?

We can set the connection up against a sandbox tenant on a demo call so you can see the behaviour rather than read about it.
Demo anfragenKostenlos testen