Can we keep our existing bucket and container structure?
Yes. AODocs does not impose a storage hierarchy. Document sets, properties and permissions live in the platform layer, which means you can reorganise one without touching the other.
Object storage is the foundation, not the platform
S3 and Azure Blob Storage do one thing extremely well. They keep your files durable, available and cheap, at any scale. But the moment your application needs to find a document, control who reads it, prove what happened to it or decide how long to keep it, you are no longer dealing with storage. You are building a document platform. AODocs is that platform, and it runs on the storage you already chose.
When storage alone is the right answer
There are cases where adding anything on top of S3 or Azure Blob Storage would be a waste of money and engineering time
If your requirement is archival, if documents are written once and retrieved occasionally, if each resource is addressed by a stable link held somewhere else in your information system, then object storage already does the job. It is durable, it is inexpensive, it survives entire generations of applications, and it asks nothing of your team beyond a lifecycle rule.
Most storage decisions are correct. The question this page asks is different. It is about what you put on top, and whether your team should build it.
Where the line is
Both platforms offer a mature set of storage primitives, and they offer them very well. What neither offers is a document platform, and that is a design decision rather than an omission. Object storage was never meant to know what a document means.
Above the line, where documents start to mean something
- Document sets whose properties, permissions and lifecycle are inherited by everything inside them
- Retention driven by business events rather than by the age of an object
- A business-level audit trail, recording who read which document and when
- Review and approval paths that determine which version is in force
- An interface for the people who will actually use the documents
Below the line, both platforms are excellent
Below the line, both platforms are excellent, and the table names the native service in each column.
The table names the native service in each column, so you can check it against your own architecture.
| Capability | Amazon S3 | Azure Blob Storage |
|---|---|---|
| Durable, redundant file storage | Native | Native |
| File versioning | S3 Versioning | Blob versioning |
| Write-once immutability | Object Lock, Governance and Compliance modes | Immutability policies, time-based retention and legal holds |
| Storage tiering and expiry | S3 Lifecycle, Standard to Glacier Deep Archive | Lifecycle management, Hot to Archive tiers |
| Infrastructure-level audit | CloudTrail, server access logging | Azure Monitor, activity and diagnostic logs |
| Access control on buckets and containers | IAM, bucket policies | Azure RBAC, shared access signatures |
| Simple tag-based filtering | Object tags, up to 10 per object | Blob index tags, up to 10 per blob |
| Full-text search across document contents | Requires Amazon OpenSearch or Kendra | Requires Azure AI Search |
| Queryable business metadata | Requires an external index and a datastore | Requires an external index and a datastore |
Durable, redundant file storage
Amazon S3
Native
Azure Blob Storage
Native
File versioning
Amazon S3
S3 Versioning
Azure Blob Storage
Blob versioning
Write-once immutability
Amazon S3
Object Lock, Governance and Compliance modes
Azure Blob Storage
Immutability policies, time-based retention and legal holds
Storage tiering and expiry
Amazon S3
S3 Lifecycle, Standard to Glacier Deep Archive
Azure Blob Storage
Lifecycle management, Hot to Archive tiers
Infrastructure-level audit
Amazon S3
CloudTrail, server access logging
Azure Blob Storage
Azure Monitor, activity and diagnostic logs
Access control on buckets and containers
Amazon S3
IAM, bucket policies
Azure Blob Storage
Azure RBAC, shared access signatures
Simple tag-based filtering
Amazon S3
Object tags, up to 10 per object
Azure Blob Storage
Blob index tags, up to 10 per blob
Full-text search across document contents
Amazon S3
Requires Amazon OpenSearch or Kendra
Azure Blob Storage
Requires Azure AI Search
Queryable business metadata
Amazon S3
Requires an external index and a datastore
Azure Blob Storage
Requires an external index and a datastore
What building it yourself actually involves
Teams rarely decide to build a document platform. They decide to add search. Then metadata. Then permissions that reflect how the business actually works. Each step is reasonable. The sum is a product.
And, every hour spent on that stack is an hour not spent on what makes your application worth building.
The build you did not plan
Here is what sits between a bucket and a working document platform.
A search index
OpenSearch or Azure AI Search, to size, secure, fund and keep in sync with the storage layer
A metadata store
And the transactional consistency between that store and the objects it describes
A permission engine
Able to translate business rules into effective access, including inheritance and exceptions
A workflow engine
For review, approval and assignment
A well design UX/UI
An interface for the people who are not developers, which is most of the people who will use it
A business audit trail
Distinct from infrastructure logs, answering who did what to which document
And the ten years that follow
Shipping the first version is the easy part. What follows is an internal product that nobody outside your company supports, and that has to survive everything your business throws at it.
Dependencies age and their upgrades are never optional. Security patches arrive on someone else's schedule. The two or three engineers who understood the permission model move on, and the next team inherits code nobody documented because it was never meant to become a product.
Meanwhile the requirements keep coming. A new regulation changes the retention rules. A new department needs a different approval path. An acquisition brings in a second set of document types.
Every hour spent there is an hour not spent on what makes your application worth building. That is the real cost, and it does not appear in any project estimate.
What AODocs adds
Search
Full-text and metadata search across every document in scope, with results filtered by what each user is entitled to see.
When it matters: when finding a document takes longer than recreating it.
Document sets
Folders and sets that carry their own properties, permissions and lifecycle, inherited by everything inside them.
When it matters: when a case, a project or a contract is made of dozens of documents that must behave consistently.
Retention
Retention schedules driven by business events and metadata, not by object age, with holds and defensible disposal.
When it matters: when a regulator or a court asks why a document was kept, or why it was not.
Audit log
A business-level record of who created, read, modified, approved or deleted each document.
When it matters: when infrastructure logs tell you an API call happened but not what it meant.
Permissions
Access derived from document content, metadata and business rules, evaluated at query time.
When it matters: when access depends on the document itself rather than on where it was stored.
Workflow
Review, approval and assignment paths that fit how decisions are actually made in your organisation.
When it matters: when the version in force has to be unambiguous.
API first, by design
AODocs was built as a platform, not as an application that happens to expose an API. Every capability on this page is reachable programmatically, which gives you three ways to use it.
Use it, or build on it
Use the AODocs interface as it stands, and give your business teams a working document platform on day one.
Or build your own application on top of the AODocs API, and let it handle search, metadata, permissions, retention and audit while your developers build what differentiates your business. The storage stays yours. The platform layer is ours. Your team works on the part that only your team can write.
Give your agents something to trust
Expose document capabilities to your AI agents through MCP and A2A, so an agent retrieves the version in force rather than whatever it finds, within the permissions of the user it acts for.
An agent connected directly to a bucket reads files. An agent connected to AODocs reads documents, with their status, their metadata and their access rules, which is the difference between a plausible answer and a defensible one.
Deploy anywhere
Title Your storage, your cloud, your rules
AODocs runs on the object storage you already operate, in the region you already chose, under the encryption keys you already manage. Files stay in your bucket or your container. AODocs holds the metadata, the index and the audit trail that make them a document platform.
The same applies to where AODocs itself runs. Deployment options cover public cloud, private cloud and sovereign requirements, which matters when the regulator cares as much about the location of the metadata as about the location of the files.
Before you build, four questions worth settling
Do we need to move our data out of S3 or Azure?
No. AODocs reads from and writes to your existing buckets and containers. Your storage architecture, your region and your encryption keys stay as they are.
How is AODocs retention different from Object Lock or immutability policies?
Object Lock and Azure immutability policies compute retention from the age of the object. AODocs computes it from business events held in metadata, such as the end of a contract or the closure of a case, and applies holds, reviews and defensible disposal on that basis. The two work together, AODocs can drive the native immutability features rather than replace them.
What does AODocs API expose?
Document and folder operations, metadata read and write, search, permission evaluation, workflow actions and audit queries. The same API serves the AODocs interface, your own applications and MCP-connected agents.
Keep your storage. Skip the build.
Tell us what your application needs to do with documents, and we will tell you honestly whether you need us.