This article is for AWS administrators and AODocs super administrators. It covers the setup you perform for each Amazon S3 bucket linked to AODocs: creating and configuring the bucket, wiring it to the account+region notification queue, extending the IAM role, and registering the bucket with AODocs.

This assumes the one-time, per-AWS-account-and-region setup — adding Google as an OIDC identity provider, creating the IAM role AODocs assumes, and creating the SQS notification queue — is already done. See Set up AWS account trust for Amazon S3 storage in AODocs if it has not; you need the Role ARN it produces for the last step below, and the queue it produces for the event-notification step.

Note: To use Amazon S3 as your AODocs storage platform, the AMAZON_S3 storage service must be activated on your AODocs domain. Contact your AODocs sales representative or send an email to sales@aodocs.com.

Automatically generated table of contents

Step 1: Open the S3 dashboard

Log in to the AWS Management Console, type S3 in the search bar at the top, and select it to open the Amazon S3 console dashboard.

screen: The Amazon S3 console dashboard with the Create bucket action available.

Step 2: Set general configuration

1. Choose Create bucket.
2. Bucket name: enter a clean, unique name using only lowercase letters, numbers, and hyphens. Do not create a directory bucket (S3 Express One Zone) — only General Purpose buckets are supported. A directory bucket’s name ends in --x-s3 and AODocs rejects it at registration.
3. AWS Region: select the region where this bucket should live. The exact region string you select here is what you must use in the registration value later. A mismatch between the bucket’s actual region and the registered value causes registration to fail.

screen: The Create bucket general configuration with General Purpose selected and the AWS Region chosen.

Step 3: Enforce Block Public Access

Leave Block all public access checked so public viewing access remains locked down.

Step 4: Enable bucket versioning — required

Select Enable for bucket versioning. This is not optional: AODocs verification rejects the bucket if versioning is not enabled, because write and delete attribution depends on every version being independently addressable once its S3 event is processed.

screen: The bucket versioning setting with Enable selected.

Step 5: Finalize and create the bucket

Scroll to the bottom, leave the advanced defaults (encryption with Amazon-managed keys is fine), and choose Create bucket.

Step 6: Add a noncurrent-version expiration lifecycle rule — required

After the bucket exists, open it → Management → Lifecycle rules → Create lifecycle rule, and add a rule that:

• applies to the whole bucket — no prefix, tag, or object-size filter (a scoped rule does not satisfy the check, because it may not cover attachment keys)
• is Enabled
• includes a Noncurrent version expiration action — we recommend setting the retention period to 1 day to minimize storage costs. The exact number of days is configurable; any positive value satisfies the requirement

Important: This rule is required. It is the mechanism that physically removes content after a permanent delete in AODocs. Without an enabled, unfiltered noncurrent-version expiration rule covering the whole bucket, AODocs verification rejects the bucket.

screen: The Create lifecycle rule page with a Noncurrent version expiration action enabled for the whole bucket.

Step 7: Configure S3 event notifications — required

AODocs derives write attribution and change tracking from S3 event notifications delivered to a customer-owned SQS queue. The queue itself is created once per AWS account and region in Set up AWS account trust for Amazon S3 storage in AODocs (Step 5). This step wires each new bucket to that queue, and must be done before the bucket is registered with AODocs.

Which queue to use

AODocs stores exactly one SQS queue per AWS account and region, not per bucket:

• First bucket in this account + region: create the queue as part of the account-trust setup and point this bucket’s event notification at it. AODocs discovers the queue from the bucket’s notification configuration the first time you link a bucket, and stores it against this account+region.
• Any additional bucket in an account + region you already onboarded: point this bucket’s event notification at the same SQS queue already used by the previously linked bucket(s) — do not create a new queue. If this bucket notifies a different queue, or has no queue configured, AODocs verification fails. Configuring both the already-known queue and an extra queue is fine — the known one is used.

If you do not already know the queue in use for this account+region, check the first bucket that was linked, or ask your AODocs contact before creating a new queue.

Point the bucket’s event notifications at the queue

1. In the S3 console, open the bucket → Properties → Event notifications → Create event notification.
2. Event types:
   • Under Object creation, select All object create events.
   • Under Object removal, select only Delete marker created — leave All object removal events and Permanently deleted unchecked. Permanently deleted events also fire on every noncurrent-version purge from the lifecycle rule in Step 6, which is S3 housekeeping rather than a customer delete.
3. Destination: SQS queue → select the queue created (or already in use) during the account-trust setup.
4. Save.

screen: The Create event notification page with All object create events and Delete marker created selected, destination set to the account+region SQS queue.

Then add this bucket to the queue’s access policy: open the queue in the SQS console → Access policy → Edit, and add its ARN to the aws:SourceArn condition of the AllowS3EventDelivery statement (or add a whole new statement naming it). Without that, S3 accepts the notification configuration above but every delivery attempt fails silently. There is no per-bucket SQS permission to re-grant beyond that: AllowConnectorRolePolling was granted once on the queue and already covers every bucket notifying it.

Repeat this step for every bucket you register in this account and region.

Step 8: Grant the IAM role access to this bucket — required

Add this bucket’s ARN (and its /* object prefix) to the BucketLevelRead and ObjectLevelReadWrite Resource entries of the IAM policy created in the account-trust guide — either by extending the existing Resource list or by duplicating the statement for this bucket. If you use the optional s3:PutBucketCors statement, extend that Resource as well. Every required action in that policy must apply to this bucket for verification and normal object operations to succeed.

Do not repeat identity-provider or role creation for a bucket added to an already-registered AWS account and region. See the permission reference table in the account-trust article for the full list of actions.

Register the bucket with AODocs

Copy the Role ARN obtained from the account-trust setup.

The AODocs library setup page does not take the Role ARN alone — it takes a single value combining the Role ARN, the bucket’s AWS region, and the bucket name, joined by colons:

{roleArn}:{region}:{bucketName}

For example, with role ARN arn:aws:iam::123456789012:role/AODocsStorageConnectorRole, region us-east-1, and bucket customer-aodocs-bucket:

arn:aws:iam::123456789012:role/AODocsStorageConnectorRole:us-east-1:customer-aodocs-bucket

1. In AODocs, create a Document Management library.
2. Select Amazon Simple Storage Service as the storage type (shown only if AMAZON_S3 is activated on your domain).
3. Paste the registration value.

screen: The library creation dialog with Amazon Simple Storage Service selected and the registration value field filled in.

Paste the Role ARN exactly as copied (it already contains colons of its own — do not strip or re-encode them), then append : + the bucket’s region + : + the bucket name. The region must be the bucket’s actual region (see Step 2) — a mismatch is rejected at registration time.

What is accepted:

• the standard aws partition — aws-cn and aws-us-gov ARNs are rejected
• a numeric account ID
• a role ARN of the form role/<name>, where <name> may contain slashes (for roles created under an IAM path) but no colons
• exactly three parts overall (role ARN, region, bucket name) — no leading, trailing, or extra segments

Anything else is refused at registration. A directory bucket (S3 Express One Zone, name ending in --x-s3) is well-formed but rejected separately as an unsupported bucket type.

Note: You only see storage platforms that have been activated on your AODocs tenant and that are available to you. You can't change the storage platform of a library after you create it, except by using the Library Switcher when that target platform is supported. The Library Switcher does not support Amazon S3 yet.

Good to know and limitations

• AODocs does not create Amazon S3 buckets for you. There is no AODocs-managed Amazon S3 storage type.
• Only General Purpose buckets are supported. Directory buckets (S3 Express One Zone) are rejected.
• Bucket versioning and an enabled, unfiltered noncurrent-version expiration lifecycle rule are required.
• AODocs does not create the SQS queue or attach notifications for you, but a customer-owned SQS notification on the bucket — pointing at the account+region queue — is required.
• Object Lock / retention management is not offered as a customer-facing AODocs feature for Amazon S3 storage yet. Do not enable Object Lock expecting AODocs retention features to use it.
• The Library Switcher does not support Amazon S3 yet (supported switcher targets today: Google Cloud Storage, Azure Blob Storage, and SharePoint Embedded).

Related articles

• Set up AWS account trust for Amazon S3 storage in AODocs
• Set up Google Cloud Storage for AODocs
• Set up Azure Blob Storage for AODocs
• Understand and set up Microsoft SharePoint Embedded storage in AODocs
• What are the differences between the various storage platforms for AODocs?
• Create a library from scratch
• Welcome to AODocs! (section “Where is my content stored?”)