When a business connects an Amazon S3 bucket to BucketDesk, it does not need to migrate its source files into storage owned by BucketDesk. The original objects remain in the customer’s AWS account.
How can a business-friendly workspace browse, preview, and operate on those files without owning the customer’s AWS environment? The answer combines customer-controlled CloudFormation stacks, scoped IAM roles, and temporary AWS credentials.
There is an important distinction: customer-owned storage does not mean file contents never leave AWS. Microsoft Office previews use temporary SharePoint copies, and other enabled processing features can read file contents. S3 remains the source of truth; each feature’s processing boundary still matters.
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 prefixCloudFormation 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.
- 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.
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.
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, but Microsoft 365 Office preview uses a temporary copy in the configured SharePoint library. Read-only preview does not modify the S3 original.
BucketDesk schedules preview-copy cleanup after expiration. Application cleanup is not a promise of immediate permanent erasure from every Microsoft retention layer; recycle-bin, retention, and compliance settings can affect how long deleted data remains recoverable.
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.
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.
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.
Keep your original files in your AWS account. Grant only the access you approve, review infrastructure changes, and understand the processing boundary of each feature you enable.