Files.com integrates with Amazon S3 in several different ways.

Files.com's Remote Server Mount feature connects a specific folder on Files.com to an S3 bucket in real time. That folder becomes a window into the files stored in your remote server or cloud.

Once you configure a Mount, any operation you perform on or inside that folder acts directly on the remote in real time. Dropping a file into the folder, deleting a file, creating a subfolder, or any other file or folder operation your Files.com user has permission for will pass through to the remote in real time.

Use cases include accessing files on a counterparty's cloud (client or vendor) without provisioning individual user access, reducing storage costs by using on-premise or bulk storage, and enabling applications to access third-party clouds through Files.com's API, FTP, SFTP, or Apps.

Alternatively, Files.com's Sync feature pushes or pulls files to or from S3 buckets, so the files exist in both places at the end of the sync. You can send files from your Files.com site to the S3 bucket or pull files from the S3 bucket into your Files.com site.

Add Amazon S3 as a Remote Server

Add a new Remote Server to your site, and select Amazon S3 as the server type.

You must provide an Internal name for this connection. If you're managing multiple remote servers, make the name clear enough to easily identify this particular connection.

The Region and Bucket are required because they define which bucket Files.com will connect to, and the Authentication Information contains the credentials Files.com will use for connecting to AWS.

Region and Bucket

Files.com supports connecting to S3 buckets in many regions, including regions where Files.com itself doesn't have an AWS presence. This includes Govcloud. Contact us if you need to access a region you don't see listed and we will work to add it.

Files.com requires access to the bucket being used, so we recommend creating a bucket for the exclusive use of Files.com.

AWS Region

The AWS Region Code of your S3 bucket name can be found by using the get-bucket-location command of the AWS CLI tool. You can cross-reference the region code and region name using Amazon's online documentation.

Bucket Name

Your Amazon S3 bucket name can be found in the Amazon AWS Console, within the Amazon S3 section, under the Buckets list.

Authentication Information

Files.com supports two authentication methods for connecting to Amazon S3: Access Key with Secret Access Key and AWS STS with IAM Role Assumption.

Choose the method that fits your organization's security and credential management policies. Both methods are secure, and STS Role Assumption is considered more secure.

The authentication information can be placed in the Remote Server Credential Manager and selected when configuring the Remote Server.

Access Key with Secret Access Key

Provide an AWS Access Key ID and Secret Access Key associated with an IAM user that has permission to access the target S3 bucket.

The IAM user must have appropriate permissions for the operations you intend to perform. Scope permissions to the specific bucket and paths required, for least-privilege access.

This method stores long-lived credentials in Files.com.

AWS STS with IAM Role Assumption

Files.com supports authentication using AWS Security Token Service (STS) by assuming an IAM role in your AWS account. This method uses temporary credentials instead of long-lived access keys.

To configure role assumption:

Create an IAM role in your AWS account.
Configure a trust policy that allows the Files.com AWS account to assume that role. A sample policy is provided.
Grant the role the necessary permissions to access the target S3 bucket.
Provide the Role ARN when configuring the STS credential in Files.com.

This method reduces long-term credential exposure and follows AWS best practices for cross-account access.

When using STS, Files.com requests temporary credentials from AWS by assuming the specified role. AWS issues time-limited credentials that Files.com uses for S3 operations.

The Assume Role Session Duration setting, which defaults to 3600 seconds (1 hour), specifies the duration for the STS credential. This default matches the default for an IAM role. If the IAM role has a custom value for its Maximum session duration setting in AWS, configure the Files.com setting to a value equal to or lower than the IAM role's maximum session duration.

Files.com automatically renews temporary credentials before they expire to maintain uninterrupted access to S3.

Choosing an Authentication Method

Use Access Key with Secret Access Key when your environment relies on static credentials and key rotation policies. Use AWS STS with IAM role assumption when you prefer temporary credentials and centralized role-based access control.

For most production environments, role assumption via STS provides stronger security controls and easier credential management.

Access Permissions

Regardless of authentication method, the IAM user or role must have permissions appropriate to the intended use of the Remote Server.

Restrict permissions to the specific bucket and object prefix required for your integration.

Minimal Permissions for Full Access

You will need to apply a policy to the IAM user to grant it full permissions to the bucket being used.

These permissions represent the minimum required for Files.com to function correctly with your S3 bucket.

To use the below example, replace <Your IAM User ID> with the 12 digit IAM ID of the user, replace <Your IAM User Name> with the IAM user name of the user, and replace <bucketname> with your bucket name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Your IAM User ID>:user/<Your IAM User Name>"
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<bucketname>",
        "arn:aws:s3:::<bucketname>/*"
      ]
    }
  ]
}

Read-Only Permission

Access to the S3 bucket is determined by the policies and permissions in Amazon S3.

If your S3 bucket is read-only, or you wish Files.com to be restricted to read-only permissions, then configure the S3 user policy (replace <bucketname> with your bucket name) as below:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:ListBucket",
           "s3:GetBucketLocation"
         ],
         "Resource": [
           "arn:aws:s3:::<bucketname>",
           "arn:aws:s3:::<bucketname>/path/to/subfolder/*"
         ]
      }
   ]
}

The bucket policy permissions are completely separate from Files.com permissions.

When you set the bucket policy to read-only, also set any Files.com users with permission to access this bucket to read-only user permissions.

Configuring Lifecycle Rules for Multipart Uploads

Files.com uses the Amazon S3 Multipart Upload API when transferring large files to your bucket. Multipart Upload improves performance and reliability by uploading file parts in parallel, but unfinished uploads can accumulate if they're never completed or aborted.

By default, S3 does not automatically delete incomplete multipart uploads. Any unfinished parts remain stored indefinitely and continue to incur storage costs.

To prevent unnecessary storage usage, we strongly recommend setting up an AbortIncompleteMultipartUpload lifecycle rule in your S3 bucket configuration. This rule automatically cleans up uncompleted uploads after a set period.

Here is an example rule:

{
  "Rules": [
    {
      "ID": "Abort incomplete uploads after 7 days",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

This rule tells Amazon S3: if a multipart upload was initiated more than seven days ago and hasn't been completed or aborted, automatically abort it and delete all uploaded parts. Adjust the DaysAfterInitiation value as needed for your storage policies.

Configuring this rule helps you avoid hidden storage charges from incomplete uploads, keep your bucket clean, and maintain predictable storage costs.

Supported S3 Storage Classes

Files.com supports reading and writing objects in the following S3 storage classes: Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, and Glacier Instant Retrieval.

Objects in Glacier Flexible Retrieval and Glacier Deep Archive are not accessible through Files.com. These tiers are designed for long-term archiving and data retention, where files may be inaccessible for hours after a retrieval request. Remote Servers are intended for active file operations, and files stored in cold-archive tiers are not immediately available in the way needed by an active Remote Server. When a Sync or Remote Server Mount encounters one of these objects, it produces this error:

Unable to download file from Amazon S3: InvalidObjectState - The operation is not valid for the object's storage class

This error means that you are trying to use Files.com with an unsupported storage class. To resolve it, configure the S3 Remote Server to use a supported storage class.

Add Remote Server Mount

Remote Server Mounts are created by mounting them onto an empty folder in Files.com. We recommend that this folder not be the Root of your site, although that is supported if you need it.

Add Sync

After creating the Amazon S3 Remote Server, you can use it to perform Syncs between your bucket and Files.com.

Automations

Folders that have been configured with Remote Server Mount to Amazon S3 can also be used with Automations, allowing you to include S3 buckets as source locations or destinations for your Automations.

Folder Representation Using Slash Files

Amazon S3 Storage does not natively support hierarchical folders and instead stores data in a flat namespace. Files.com represents folder structures in S3 Storage using slash files, a convention that simulates directories while remaining compatible with Amazon's underlying storage model.