Your S3 Files Stay in Your AWS Account: How BucketDesk Uses CloudFormation for Secure Access

The customer stays in control

BucketDesk provides a CloudFormation template that the customer deploys into their own AWS account. Its parameters identify the approved bucket and prefix, the trusted BucketDesk role, and the connection’s External ID.

The resulting roles and policies define the AWS resources and actions BucketDesk can access. They do not transfer ownership of the bucket or give BucketDesk unrestricted administration of the account.

Authorized BucketDesk operation
  → AWS STS assumes the customer-approved role
  → Temporary credentials
  → Approved S3 bucket and prefix

CloudFormation makes access reviewable

CloudFormation describes infrastructure as code. Administrators can inspect the template and selected parameters before deploying a stack, rather than relying on an unexplained list of console clicks.

BucketDesk’s customer-role template includes separate options for uploads, archived-object restoration, archive extraction, and document chat. These optional settings default to disabled. Enabling an option can add permissions or resources; customers should review that change and its operating costs.

The storage scope matters as much as the feature toggle. Approve only the bucket and prefix needed for the connection. Encrypted objects can also require appropriate KMS permissions and key policies.

AWS: reviewing CloudFormation changes ↗

• Browsing and previewing require scoped read access.
• Uploads require explicit write permissions for the destination.
• Restoration requires permission to request retrieval of archived objects.
• Archive extraction needs a write-enabled destination and processing infrastructure.
• Document chat uses a separate role for the approved Bedrock model.

No long-lived customer access keys

Customers do not need to create a permanent IAM user access key and paste it into BucketDesk. BucketDesk calls AWS Security Token Service to assume the customer-approved role and obtain temporary credentials.

The role’s trust policy identifies the trusted principal and checks the External ID. Its permissions policies define the actions and resources available to the session. Other applicable AWS policies and explicit denies still affect effective access.

Temporary credentials expire. The customer retains control of the role, but stopping new role assumptions is not the same as instantly invalidating every already-issued session or signed URL. Revocation procedures need to account for active access as well as future requests.

AWS: third-party role access and External IDs ↗More on BucketDesk’s IAM and External ID model

Subscription access and AWS permission are separate

A plan entitlement determines whether BucketDesk permits a feature. An AWS policy determines whether the underlying operation is authorized in the customer’s account. Both must allow the operation.

An upgrade does not, by itself, grant S3 write access. A connection that can browse and preview may still require a customer-approved stack update before uploading or extracting files.

Likewise, a downgrade should not be treated as proof that AWS permissions or chargeable resources have been removed. Customers must review and apply the relevant infrastructure changes. BucketDesk’s plan-change infrastructure guidance is an area of ongoing development, not a guarantee of automatic permission cleanup.

Optional archive processing has its own footprint

The customer template includes an optional customer-account archive-processing configuration with AWS Batch on Fargate, job roles, networking, logs, and scratch storage. This is a larger change than adding a read policy.

Customer-side processing can keep archive execution close to the source data. It does not remove AWS compute, storage, request, or transfer charges, and the presence of infrastructure definitions is not proof that every processing workflow is generally available. To keep the storage side of the bill down, see the three settings that cut most S3 bills.

Archive process management continues to evolve. Before enabling it, review the available workflow, destination permissions, extraction retention, scratch storage, and cleanup behavior.

Be precise about temporary copies

The original S3 object remains in the customer’s account. Word, Excel and PowerPoint previews run on a document server BucketDesk operates in its own AWS account: it fetches the file with a short-lived signed link and holds a working copy only while the document is open. Read-only preview does not modify the S3 original.

Edits made in the browser are written back to the bucket: over the original when nobody else changed it, or to a clearly named copy beside it when someone did.

Document chat also requires processing document contents. Customers should evaluate enabled providers and data flows, rather than interpreting customer-owned S3 as a blanket promise that no content is transmitted for preview or analysis. For how document chat works on Bedrock, see asking Claude questions about S3 documents.

BucketDesk privacy information

A clearer setup-status experience is the direction

As capabilities evolve, it is useful to think of the customer stack as a versioned infrastructure contract. A future readiness view could distinguish working capabilities from those that need an AWS setup update.

For example, it could show browsing as ready while marking extraction as requiring a reviewed stack update. Installed and required setup versions would make that distinction easier to understand.

These are design goals, not a claim that a complete version-comparison dashboard or automatic compatibility check is live today. A template version alone would also be insufficient: actual permissions, configuration drift, encryption, and service availability still need validation.

Review changes before applying them

For a new capability, inspect the proposed template and parameters, review a CloudFormation change set, then apply the approved change in the customer account. Check additions, replacements, deletions, and any custom-resource behavior—not just the new feature’s name.

After deployment, validate the connection and intended operation. When removing a capability, review retained resources and active workloads before deleting infrastructure or data. Teams that manage AWS changes through CloudFormation change sets and CI/CD pipelines often bring in DevOps consulting services to standardize how access roles and infrastructure updates are reviewed and rolled out.

This keeps the responsibilities clear: BucketDesk maintains the setup definition; the customer approves its deployment; AWS enforces the resulting permissions. Infrastructure usage is billed by the customer’s providers separately from BucketDesk’s software subscription.

Keep S3 as the source of truth

BucketDesk starts with the files a business already stores in S3. It provides a workspace for browsing, previewing, sharing, and authorized operations without making the AWS Console the everyday interface.

Customer-owned storage, explicit permissions, and reviewable infrastructure are the foundation. Being equally clear about optional processing, temporary copies, and unfinished capabilities is part of that model.

How BucketDesk monitors each layer