# Lambda adds S3 Files mounts for shared workspaces > Lambda functions can mount S3 buckets through S3 Files, opening a shared workspace option that still needs explicit ownership and concurrency rules. Canonical URL: https://www.devobs.io/news/news-aws-lambda-s3-files/ By: Arjun Shah Published: 2026-09-06T11:58:54.633Z Updated: 2026-09-06T11:58:54.633Z Event date: 2026-04-21 Section: Cloud AWS added S3 Files support to Lambda on April 21, allowing functions to work with an S3 bucket through a filesystem mount. The integration targets workloads that need persistent files or a workspace shared across multiple function invocations. ## Shared files become part of the design The [AWS announcement](https://aws.amazon.com/about-aws/whats-new/2026/04/aws-lambda-amazon-s3/) describes several functions connecting to the same S3 Files filesystem and highlights multi-step AI workflows. At launch, support excluded functions configured with a capacity provider and depended on availability of both Lambda and S3 Files in the chosen Region. For teams processing a repository or a large reference dataset, the attraction is a common file-oriented interface instead of repeating an application-managed download and upload sequence. Our analysis: sharing a directory is only the beginning of defining a shared workspace. The application still needs to decide which worker owns each output, how completion is signaled, and what another worker should do with incomplete results. ## Define the workspace lifecycle Start with a pipeline whose inputs and outputs are well understood. Give every run an explicit workspace identity and make cleanup a separate, observable operation. A cancelled run should not leave later work unable to distinguish abandoned files from current results. Test concurrent writers, retries, and workers that stop after creating only part of an output. Decide whether readers require an explicit completion marker before using a result. Avoid assuming that persistence itself makes a workflow retry-safe. Review access boundaries when unrelated customers or projects use the same processing system. A convenient mount path should not become an implicit permission boundary. The first rollout should prove that the workspace's ownership, retention, and completion rules remain understandable when one step fails. ## Source references -