Orchestrating multi-agent AI architectures with Amazon S3 Files

​​​​Organizations are moving beyond single-model AI toward multi-agent architectures. In these systems, agents offload intermediate results to files rather than carrying everything in the prompt, because a large prompt inflates cost and degrades quality. A model’s context window is finite, so files become working memory that persists after a session ends. In multi-agent systems, a shared file system becomes the handoff layer: one agent writes its output to a directory, the next reads it, with no custom integration code between steps. Consider a document processing pipeline at a financial services firm. Five agents handle classification, risk scoring, compliance validation, report assembly, and executive summarization, often running concurrently against the same documents. They need shared access to a common data layer with clear handoff boundaries between stages. Without a shared file system, every handoff turns into API calls, pagination, and retries that multiply with scale.

Amazon S3 Files provides exactly this: a shared file system over your S3 data with POSIX semantics, so agents get the common data layer and directory-convention handoffs the pipeline needs. Agents on Amazon EC2, AWS Lambda, Amazon EKS, Amazon ECS on AWS Fargate, and Amazon Bedrock AgentCore Runtime all mount the same file system using standard file operations like open(), os.listdir(), and write(). Access points let you scope each agent to a portion of the file system under its own POSIX identity, so you can enforce per-agent isolation via separate access points with non-overlapping directory scopes as your security requirements grow. In this walkthrough, agents share a single access point because they all operate on the same pipeline data and coordinate through shared directories, so a single POSIX identity is sufficient. Each agent reads from a designated input directory and writes to an output directory, skipping files it has already processed. Lambda, ECS on Fargate, and AgentCore Runtime mount through the access point. EC2 and EKS mount the file system directly. And because the data lives in S3, you retain S3’s event-driven capabilities. When a document lands in the bucket, an event notification routes to an Amazon SQS queue, triggering the first agent. Without S3 Files, each handoff would need s3.list_objects_v2() to discover files and s3.put_object() to write results. With S3 Files, agents read and write with open() and json.dump().​​​

You can run your agents fully managed on Amazon Bedrock AgentCore or on AWS compute you already operate. This post walks through the second path: a five-stage document intelligence pipeline with each agent on a different compute service. After the initial SQS trigger, agents hand off through shared directories using directory polling or Amazon EventBridge Scheduler, and every agent uses the Strands Agents SDK with Amazon Bedrock for inference. We deliberately place each stage on a different compute service to show the range of what can mount S3 Files. A real pipeline would choose compute per stage on its own merits, not spread it across five.

Solution overview

The following diagram shows the handoff flow: each agent reads from one shared directory and writes to the next, passing documents through intake/, analyzed/, validated/, reports/, and summaries/ without direct agent-to-agent communication.

Figure 1: Multi-agent document processing pipeline with five AI agents running on different AWS compute services, sharing a single S3 Files file system

The pipeline starts with an event-driven trigger: when a customer form is uploaded to S3, an S3 event notification delivers a message to an SQS queue, and the EC2 intake agent picks it up on its next poll. The intake agent receives the SQS message to learn a new document has landed, then reads it from the shared mount using the filename derived from the S3 key, and writes the structured output to the intake/ directory. From that point on, downstream handoffs happen through the file system. Downstream handoffs use directory polling or scheduled triggers. Long-running services (Amazon EKS, Amazon ECS) run a loop that calls os.listdir() every 10-15 seconds. Lambda and AgentCore Runtime are both invoked by EventBridge on a 1-minute schedule. A file is visible to other mounted agents immediately on close (close-to-open consistency). It appears as an object in the S3 bucket about a minute later, after the mount exports it. Downstream agents read from the mount, so they see it on close, not after the export. Downstream agents poll the mount directly. S3 Files provides close-to-open consistency, so a file written by one agent is visible to other agents immediately after close. The Strands agent is stateless per invocation. The surrounding application code handles polling and deduplication.

Agents follow the same code pattern. The following example shows how the risk analysis agent (Stage 2) reads from the shared file system, processes a document with the Strands SDK, and writes the result back:

import json
from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="<MODEL_ID>", region_name="<REGION>")
agent = Agent(model=model, system_prompt=SYSTEM_PROMPT)

# Read input from shared file system
with open('/mnt/s3files/intake/doc-abc.json') as f:
    doc = json.load(f)

# AI agent processes the document
result = agent(f"Analyze this document for risks: {json.dumps(doc['content'])}")

# Write output to shared file system
envelope = {
    'id': doc['id'],
    'stage': 'analyzed',
    'content': json.loads(result.message['content'][0]['text'])
}
with open('/mnt/s3files/analyzed/analysis-abc.json', 'w') as f:
    json.dump(envelope, f, indent=2)

The only difference between agents is the system prompt and which directory they read from and write to.

The shared file system

Agents in the pipeline read and write to the same S3 Files file system mounted at /mnt/s3files/. Each agent owns a specific directory prefix where it writes output. The next agent in the pipeline reads from that prefix as its input. This directory-based handoff replaces the need for message queues or event-driven coordination between downstream stages.

Because every agent lists its input directory on a fixed interval or per-trigger, each stage needs a way to skip files it has already processed. The pipeline uses two approaches: The EKS agent runs parallel replicas that coordinate with atomic claim markers so each document is processed by exactly one replica, and the ECS agent (a single task) persists deduplication state on the mount. The remaining agents (EC2, Lambda, AgentCore) skip any input whose expected output file already exists. Both patterns ensure that repeated directory listings don’t trigger duplicate work.

The following diagram shows the five-stage pipeline flow. A customer form is uploaded to S3, which triggers an event notification to an SQS queue. The EC2 intake agent receives the SQS message, reads the raw document from the mount, classifies it, and writes a structured JSON envelope to intake/. The Lambda risk agent reads from intake/ and writes risk assessments to analyzed/. The EKS compliance agent reads from analyzed/ and writes validation results to validated/. The ECS report agent reads from validated/ and assembles a JSON report and Word document into reports/ and documents/. The AgentCore summary agent reads from reports/ and writes a final executive summary to summaries/.

Figure 2: Five-stage pipeline flow showing how each agent reads from and writes to designated directories on the shared S3 Files mount at /mnt/s3files/

Two mount targets (one per Availability Zone (AZ)) provide high availability. The file system scales automatically with no capacity planning required. For more information about S3 Files performance thresholds, refer to Performance specifications. The workload in this post stays within these thresholds, so it runs without hitting performance bottlenecks.

Prerequisites

To follow along with this post, you need the following:

• • An AWS account

• • An S3 bucket with versioning enabled

• • A virtual private cloud (VPC) with subnets in at least two AZs. Mount targets must exist in the AZs where your compute runs

• • A compute role (instance profile, execution role, task role, or runtime role) with AWS IAM permissions and a file system policy configured for S3 Files access (including mount, write, and root access as needed), plus bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for model invocation through the Strands SDK

• • Python 3.10 or later with strands-agents installed (pip install strands-agents). Bedrock model support is included. Additional packages vary by stage (for example, python-docx for the report agent)

• • Basic understanding of NFS and POSIX file permissions

EC2 and EKS (using static provisioning), mount the file system directly without an access point and run as root. Lambda, ECS on Fargate, and AgentCore Runtime mount through a shared S3 Files access point configured with UID 1000 and GID 1000. File operations through the access point run as UID 1000. EC2 creates the pipeline directories with 777 permissions so that both root (UID 0) and the access point identity (UID 1000) can read and write.

Stage 1: Amazon EC2

A customer form is uploaded to the S3 bucket. An S3 event notification delivers a message to an SQS queue, and the EC2 intake agent receives the message to know a new document has landed. EC2 suits this stage because intake needs a long-lived poller that processes events continuously.

The following commands install the mount helper, create the mount point, and mount the S3 Files on EC2:

# amazon-efs-utils is pre-installed on Amazon Linux 2023; install on other distributions:
sudo yum install -y amazon-efs-utils
sudo mkdir -p /mnt/s3files
sudo mount -t s3files fs-0123456789abcdef0:/ /mnt/s3files

The instance profile handles authentication. You don’t need access keys or separate SDK configuration for file access. The amazon-efs-utils package is pre-installed on Amazon Linux 2023 AMIs but must be installed manually on other distributions. The S3 Files mount helper requires botocore on the mounting host. For details, see Mounting S3 file systems on Amazon EC2.

Sample agent code:

import os
import json
import boto3
import time 
import urllib.parse
from strands import Agent
from strands.models.bedrock import BedrockModel

sqs = boto3.client('sqs')
QUEUE_URL = os.environ['QUEUE_URL']
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-east-1")

agent = Agent(model=model, system_prompt="""
You are a document intake agent. Read customer forms and prepare structured
intake records. For each document, extract key metadata, classify priority
(high/medium/low), identify flags. Return valid JSON with: document_type,
title, priority, flags, key_entities, summary.
""")

while True:
    response = sqs.receive_message(QueueUrl=QUEUE_URL, MaxNumberOfMessages=10)
    messages = response.get('Messages', [])
    if not messages:
        time.sleep(5)
        continue

    for msg in messages:
        # Extract S3 key from the SQS event notification message
        body = json.loads(msg['Body']) 
        record = body['Records'][0]
        s3_key = urllib.parse.unquote_plus(record['s3']['object']['key'])
        filename = s3_key.split('/')[-1]
        if not filename.endswith('.json'):
            sqs.delete_message(QueueUrl=QUEUE_URL, ReceiptHandle=msg['ReceiptHandle'])
            continue
        doc_id = filename.replace('.json', '')
        output_path = f'/mnt/s3files/intake/doc-{doc_id}.json'
        if os.path.exists(output_path):
            sqs.delete_message(QueueUrl=QUEUE_URL, ReceiptHandle=msg['ReceiptHandle'])
            continue
        # Read the document from the shared mount (using the key from the SQS message)
        with open(f'/mnt/s3files/customer-forms/{filename}') as f:
            form = json.load(f)
        result = agent(f"Process this document for intake: {json.dumps(form['content'])}")
        envelope = {
            'id': doc_id,
            'stage': 'intake',
            'type': form.get('document_type', 'unknown'),
            'content': json.loads(result.message['content'][0]['text'])
        }
        with open(output_path, 'w') as f:
            json.dump(envelope, f, indent=2)
        sqs.delete_message(QueueUrl=QUEUE_URL, ReceiptHandle=msg['ReceiptHandle'])

Stage 2: AWS Lambda

Risk analysis is schedule-driven. Lambda is invoked by EventBridge on a 1-minute schedule, checks for new intake documents, and processes those it finds.

Lambda gets persistent shared storage that survives across invocations and is visible to other agents. The handler reads from intake/ and writes to analyzed/. The EKS agent picks up those files on its own mount within seconds.

Lambda can’t run mount commands, so it uses an S3 Files access point configured in the function’s FileSystemConfigs. The following configuration attaches the file system to the Lambda function:

FileSystemConfigs:
  - Arn: arn:aws:s3files:us-east-1:123456789012:file-system/fs-xxx/access-point/fsap-xxx
    LocalMountPath: /mnt/s3files

The mount happens before the handler runs. By the time your code runs, /mnt/s3files is ready.

The execution role additionally needs standard Lambda VPC execution permissions. We configured the function with 2048 MB memory and a 10-minute timeout because the Strands SDK at cold start and Bedrock inference calls require more time and memory than a typical Lambda function. For the full list of prerequisites, see Configuring Amazon S3 Files access.

The following is our sample agent code:

import os
import json
from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-east-1")

agent = Agent(model=model, system_prompt="""
You are a risk analysis agent. Analyze documents for risk factors. For each
document: assign a risk_score (1-10), list specific risk_factors, extract key
data points, set flags (HIGH_VALUE, LONG_TERM, OVERDUE), provide a
recommendation. Return valid JSON.
""")

def handler(event, context):
    for doc_file in os.listdir('/mnt/s3files/intake/'):
        if not doc_file.endswith('.json'):
            continue
        with open(f'/mnt/s3files/intake/{doc_file}') as f:
            doc = json.load(f)
        output_path = f'/mnt/s3files/analyzed/analysis-{doc["id"]}.json'
        if os.path.exists(output_path):
            continue
        result = agent(f"Analyze this {doc['type']} for risks: {json.dumps(doc['content'])}")
        envelope = {
            'id': doc['id'],
            'stage': 'analyzed',
            'type': doc['type'],
            'content': json.loads(result.message['content'][0]['text'])
        }
        with open(output_path, 'w') as f:
            json.dump(envelope, f, indent=2)

Stage 3: Amazon EKS

Compliance validation benefits from horizontal scaling. Two pod replicas process documents in parallel, both sharing the same file system mount. This example uses static provisioning for mounting S3 Files as a persistent volume in the EKS cluster, but you can also use dynamic provisioning.

EKS uses the Amazon Elastic File System (Amazon EFS) Container Storage Interface (CSI) driver to mount S3 Files as a PersistentVolume. This survives pod restarts, node replacements, and cluster upgrades.

The following YAML defines the StorageClass and PersistentVolume for S3 Files:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: s3files-sc
provisioner: efs.csi.aws.com
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: s3files-pv
spec:
  capacity:
    storage: 5Gi
  accessModes: [ReadWriteMany]
  storageClassName: s3files-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: "s3files:fs-0123456789abcdef0"

Application pods require a PersistentVolumeClaim (PVC) to mount the volume (refer to the EFS CSI driver static provisioning claim example). Pods mount the PersistentVolumeClaim at /mnt/s3files. Multiple replicas share the same mount point with ReadWriteMany access mode.

The EKS cluster needs the EFS CSI driver add-on installed, with an IRSA role for the CSI controller that includes the AmazonS3FilesCSIDriverPolicy (this handles provisioning only). The worker node role (or the efs-csi-node service account) additionally needs s3files:ClientMount and s3files:ClientWrite permissions (for example using AmazonS3FilesClientFullAccess), because the CSI node component performs the actual mount using the node identity, not the controller service account. Agent pods require a separate IRSA role for Bedrock access. StorageClass, PersistentVolume, and PersistentVolumeClaim resources must be configured. For details, see Mounting S3 file systems on Amazon EKS.

The following is our sample agent code:

import os
import json
import time
from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-east-1")

agent = Agent(model=model, system_prompt="""
You are a compliance validation agent. Validate analyzed documents against compliance rules.
Check value thresholds, term limits, required clauses.
Return compliance_status (PASS/FAIL/REVIEW_REQUIRED), checks_performed, violations, warnings,
compliance_score (0-100). Return valid JSON.
""")

CLAIMS = '/mnt/s3files/.claims-eks'   # shared claim directory on the mount
os.makedirs(CLAIMS, exist_ok=True)

def claim(name):
    # Exclusive create: only one replica can create the marker
    try:
        fd = os.open(os.path.join(CLAIMS, name), os.O_CREAT | os.O_EXCL | os.O_WRONLY)
        os.close(fd)
        return True
    except FileExistsError:
        return False

while True:
    for analysis_file in os.listdir('/mnt/s3files/analyzed/'):
        if not analysis_file.endswith('.json'):
            continue
        if not claim(analysis_file):     # another replica already took it
            continue
        with open(f'/mnt/s3files/analyzed/{analysis_file}') as f:
            doc = json.load(f)
        result = agent(f"Validate this {doc['type']} for compliance: {json.dumps(doc['content'])}")
        envelope = {
            'id': doc['id'],
            'stage': 'validated',
            'type': doc['type'],
            'content': json.loads(result.message['content'][0]['text'])
        }
        with open(f'/mnt/s3files/validated/compliance-{doc["id"]}.json', 'w') as f:
            json.dump(envelope, f, indent=2)
    time.sleep(10)

With two replicas sharing the same mount, both pods see the same analyzed/ directory. Before working on a document, a replica claims it by atomically creating a small marker file on the shared mount using an exclusive create. Only one replica can win that create, so the other skips the document and moves on. This means each document is validated exactly once, and the two pods coordinate purely through the file system with no message queue. Each validated document is written to a deterministic path such as compliance-a3f8b2c1.json, so if the same input is processed again the output is overwritten in place rather than duplicated.

Stage 4: Amazon ECS on AWS Fargate

Report assembly needs more memory and longer runtime than Lambda allows. ECS on Fargate provides container-level control without managing instances.

ECS on Fargate uses S3FilesVolumeConfiguration in the task definition. The following JSON shows the volume configuration:

{
  "volumes": [{
    "name": "s3files-vol",
    "s3filesVolumeConfiguration": {
      "fileSystemArn": "arn:aws:s3files:us-east-1:123456789012:file-system/fs-xxx",
      "accessPointArn": "arn:aws:s3files:us-east-1:123456789012:file-system/fs-xxx/access-point/fsap-xxx",
      "rootDirectory": "/"
    }
  }]
}

The task uses S3FilesVolumeConfiguration in the task definition with the same access point as Lambda. The task execution role requires AmazonECSTaskExecutionRolePolicy. The task role additionally needs s3files:ClientMount, s3files:ClientWrite, and s3:GetObject permissions on the file system resource, plus bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream for Strands SDK inference calls. Include Python 3.10 or later with python-docx in the container image for Word document generation. For details, see Mounting S3 file systems on Amazon ECS.

The following is our sample agent code:

import os
import json
import time
from strands import Agent
from strands.models.bedrock import BedrockModel
from docx import Document

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-east-1")

agent = Agent(model=model, system_prompt="""
You are a report assembly agent. Read validated compliance documents, aggregate
findings, and produce an executive report. Return JSON with: batch_summary,
high_risk_items, action_items, executive_narrative.
""")

PROCESSED_PATH = '/mnt/s3files/.processed-ecs.json'

def load_processed():
    if os.path.exists(PROCESSED_PATH):
        with open(PROCESSED_PATH) as f:
            return set(json.load(f))
    return set()

def save_processed(processed):
    with open(PROCESSED_PATH, 'w') as f:
        json.dump(list(processed), f)

processed = load_processed()

while True:
    files = [f for f in os.listdir('/mnt/s3files/validated/')
             if f.endswith('.json') and f not in processed]
    for validated_file in files:
        with open(f'/mnt/s3files/validated/{validated_file}') as f:
            doc = json.load(f)
        result = agent(f"Generate executive compliance report: {json.dumps(doc['content'])}")
        envelope = {
            'id': doc['id'],
            'stage': 'report',
            'type': doc['type'],
            'content': json.loads(result.message['content'][0]['text'])
        }
        with open(f'/mnt/s3files/reports/report-{doc["id"]}.json', 'w') as f:
            json.dump(envelope, f, indent=2)
        # Generate Word document
        report_doc = Document()
        report_doc.add_heading('Compliance Report', 0)
        report_doc.add_paragraph(envelope['content']['executive_narrative'])
        report_doc.save(f'/mnt/s3files/documents/report-{doc["id"]}.docx')
        processed.add(validated_file)
        save_processed(processed)
    time.sleep(15)

Writing a Word document is as simple as calling report_doc.save('/mnt/s3files/documents/report-{id}.docx'). These documents are for human stakeholders to download and review, they are not consumed by downstream agents. The .docx file is accessible to anyone who mounts the file system or accesses the bucket through the S3 API. This deduplication approach assumes a single ECS task; if you scale the service to multiple tasks, switch to the atomic claim pattern shown for EKS, because a shared read-modify-write state file loses updates under concurrency.

Stage 5: Amazon Bedrock AgentCore Runtime

AgentCore Runtime is fully managed, meaning you deploy agent code and AWS handles scaling, patching, and compute provisioning. Unlike the other compute services where you configure the NFS mount yourself, AgentCore mounts the S3 Files access point automatically inside its microVM before your agent code runs. You declare the mount in the runtime configuration and the file system is ready at your specified path from the first line of code.

The mount is declarative. You specify the access point Amazon Resource Name (ARN) and mount path when creating the runtime, and AgentCore handles the rest. The following command shows the runtime creation with file system configuration:

aws bedrock-agentcore-control create-agent-runtime \
  --agent-runtime-name "my-agent" \
  --network-configuration '{"networkMode": "VPC", "networkModeConfig": {"subnets": ["<SUBNET_IDS>"], "securityGroups": ["<SG_ID>"]}}' \
  --filesystem-configurations '[{"s3FilesAccessPoint": {"accessPointArn": "<ACCESS_POINT_ARN>", "mountPath": "/mnt/s3files"}}]' \
  --role-arn <ROLE_ARN>

AgentCore Runtime must use networkMode: VPC with subnets in AZs where AgentCore is supported and mount targets exist. The runtime’s security group must allow outbound TCP 2049 to the mount target; this NFS traffic stays in-VPC. Because AgentCore runs on private ENIs with no internet by default, its service-side calls need the VPC endpoints listed in the Considerations section. The runtime role needs S3 Files client permissions (s3files:ClientMount, s3files:ClientWrite), s3:GetObject, s3files:GetAccessPoint, and bedrock:InvokeModel with bedrock:InvokeModelWithResponseStream. Bundle strands-agents and bedrock-agentcore in the deployment artifact, because AgentCore doesn’t install packages at runtime. For details, see File system configurations for AgentCore Runtime.

To trigger the agent on a schedule, create an EventBridge rule that invokes the AgentCore runtime endpoint every 1 minute. This mirrors the Lambda scheduling pattern but targets the AgentCore runtime ARN as the EventBridge target.

The following is our sample agent code:

import os
import json
import hashlib
from strands import Agent
from strands.models.bedrock import BedrockModel
from bedrock_agentcore.runtime import BedrockAgentCoreApp

model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-6", region_name="us-east-1")
app = BedrockAgentCoreApp()

agent = Agent(model=model, system_prompt="""
You are an executive summary agent. Read all compliance reports and produce a
concise executive summary. Return JSON with: overall_status, total_documents,
high_risk_count, key_findings, recommendations, executive_narrative.
""")

@app.entrypoint
def handle_request(payload):
    # /mnt/s3files is mounted and ready before this function runs
    report_files = sorted(f for f in os.listdir('/mnt/s3files/reports/')
                          if f.endswith('.json'))
    if not report_files:
        return {'status': 'no_reports'}

    # batch_id changes when the set of reports changes — each summary
    # covers the full report set at that point in time
    batch_id = hashlib.md5(''.join(report_files).encode()).hexdigest()[:8]
    output_path = f'/mnt/s3files/summaries/summary-{batch_id}.json'
    if os.path.exists(output_path):
        return {'batch_id': batch_id, 'status': 'already_summarized'}

    reports = []
    for report_file in report_files:
        with open(f'/mnt/s3files/reports/{report_file}') as f:
            reports.append(json.load(f))

    result = agent(f"Generate executive summary: {json.dumps(reports)}")
    envelope = {
        'batch_id': batch_id,
        'stage': 'summary',
        'content': json.loads(result.message['content'][0]['text'])
    }
    with open(output_path, 'w') as f:
        json.dump(envelope, f, indent=2)
    return {'batch_id': batch_id, 'status': 'summarized'}

The agent code is identical in structure to other stages. It reads from one directory and writes to another using standard file operations. The only difference is the @app.entrypoint decorator and the BedrockAgentCoreApp wrapper, which are specific to the AgentCore Runtime SDK.

Benefits of S3 Files

What this architecture looks like in practice:

• One bucket serves as the single source of truth for all agents
• The pipeline state is observable by running ls /mnt/s3files/ on a mounted instance
• Intermediate files can be read directly for debugging

Considerations

Keep in mind the following:

• IAM permissions span two namespaces – Mounting the file system requires s3files:ClientMount and s3files:ClientWrite permissions. Reading the underlying data requires s3:GetObject. Both sets of permissions must be on the same IAM role. Missing either namespace results in access errors that can be difficult to diagnose.
• Strands SDK uses the Converse API – The Converse calls authorize against bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. Those two actions are sufficient across all five compute types. The bedrock:Converse and bedrock:ConverseStream aren’t required.
• Close-to-open consistency and out-of-band imports – S3 Files follows NFS close-to-open semantics: changes to a file become visible to other clients after the writer closes the file and a reader opens it. For out-of-band S3 PutObjects, the first directory listing imports the object’s metadata, so it appears in directory listings (os.listdir), while file data is loaded on demand on first read. Writes through the mount are exported back to S3 after 60 seconds of write inactivity, so a newly written file typically appears in the bucket about a minute after it’s closed. NFS writes don’t trigger S3 event notifications. Keep the default import behavior (metadata for all files in a directory is imported when any client first lists that directory) rather than switching to on-demand per-file imports. Set polling intervals to tolerate the import latency.
• Access point POSIX identity matters – The access point’s UID/GID determines the effective user for all file operations. AgentCore, Lambda, and ECS on Fargate adopt the access point’s identity (configure UID 1000 / GID 1000 to match AgentCore’s container user), while EC2 and EKS mount directly as root. Directories that these agents write to must have permissions that allow UID 1000 (for example, 777), or writes fail with Permission denied.
• Synchronization defaults may need tuning for larger files – Files smaller than the import-size threshold are cached locally on the high-performance storage layer when first listed, so subsequent reads are fast. Files above that threshold stream directly from S3 on each read, which adds latency. If your agents routinely read larger documents, raise the threshold so those files are also cached locally instead of streamed on every access. Infrequently accessed data expires from the cache automatically; the underlying S3 objects remain intact. For current defaults, see Performance specifications.
• VPC required for NFS – The compute services (EC2, Lambda, EKS, ECS, and AgentCore Runtime) must be in a VPC with security group rules allowing TCP 2049 to mount targets. AgentCore in VPC mode uses private ENIs with no internet by default; its service-side calls (container image pull, logging, Bedrock inference) require a NAT gateway or VPC endpoints for ecr.dkr, ecr.api, s3 (gateway), logs, and bedrock-runtime. S3 Files data traffic uses the in-VPC NFS path and doesn’t need NAT.
• Lambda cold start with Strands – For production, bundle strands-agents in a Lambda layer or container image to avoid cold-start latency. If you instead install the package at runtime (pip install into /tmp on first invocation), expect approximately 10 seconds of additional cold start per execution environment, and your VPC must have outbound internet access (NAT gateway) to reach PyPI.

Cleaning up

To avoid ongoing charges, delete the resources you created if you no longer need them:

1. Delete the S3 Files mount targets.
2. Delete the S3 Files access point.
3. Delete the S3 Files file system.
4. Terminate the EC2 instance.
5. Delete the Lambda function.
6. Delete the EKS pods and cluster resources.
7. Stop and delete the ECS on Fargate tasks.
8. Delete the AgentCore runtime.
9. Delete the SQS queue and EventBridge schedule.
10. Delete the S3 bucket (if no longer needed).

Conclusion

Agents reach for a file system because context windows are finite and files persist across sessions. In multi-agent systems, a shared file system becomes the handoff layer. S3 Files gives you that layer over your existing S3 data, with agents on any AWS compute, from fully managed AgentCore to self-hosted EC2, reading and writing through standard POSIX operations.

To get started, create an S3 Files file system from a versioned S3 bucket, deploy mount targets in your VPC, and mount it from your compute. Refer to Working with Amazon S3 Files for setup instructions, the Strands Agents SDK for building agents, and the Amazon Bedrock AgentCore Developer Guide for managed agent hosting.

Tell us in the comments how you’re using S3 Files with your agent pipelines, or what patterns you’d like us to cover next.