New — live in production across lending, industrial & clinical. See the customers →
Blog / Architecture
Architecture · field notes

Built for your cloud.

Every Aminobots deployment runs in your own tenancy — on AWS, Azure, or GCP — under your identity, with your keys. Cloud-native isn't a deployment option we offer. It's the only way we ship.

The most common question regulated enterprises ask us isn't about model quality or accuracy. It's "where does my data go?" The answer is the foundation of how we build: nowhere it isn't already. Aminobots deploys inside your cloud tenancy, on infrastructure you already own and audit. We don't run a multi-tenant SaaS that your data flows into. The system runs where your data already lives.

In your tenancy, not ours.

When we Deploy, the system stands up in your cloud account — your AWS, Azure, or GCP tenancy — under your identity and managed with your keys. There is no Aminobots-hosted endpoint your sensitive data has to traverse. Inference, orchestration, retrieval, and the audit store all sit inside the boundary your security team already controls.

That's a deliberate architectural choice, not a compliance afterthought. For a bank or a hospital, the difference between "we send your data to a vendor's API" and "the vendor's software runs in your account" is the difference between a project that clears risk review and one that dies in it.

The default stack on AWS.

Most deployments default to AWS in the Mumbai region (ap-south-1) for India residency. The reference stack uses Bedrock for managed LLM inference, KMS for customer-managed keys, S3 with WORM object lock for an immutable audit trail, and VPC private endpoints so traffic never crosses the public internet. Every external call, model invocation, and human decision is written to that audit store with retention enforced by data class.

your cloud account (aws ap-south-1) → vpc private endpoints — no public internet → managed inference (bedrock) · kms customer keys → s3 worm audit store — immutable, retention by class

A tiered model strategy, India-resident.

Not every step of an agent system needs a frontier model, and routing every call to the biggest model is how cost runs away from you. So the stack tiers its model use. The large majority of agent steps run on self-hosted open-weight models inside your region — fast, cost-efficient, and fully resident; no data leaves the tenancy. A further slice handles multilingual work, including Hindi and vernacular document processing and structured extraction from regional-language documents, again on self-hosted models. Only the highest-stakes steps — complex reasoning, long-context analysis, and human-in-the-loop explanation — reach for frontier models such as Claude via Bedrock, and those are a small fraction of total calls.

The result is a system that is cheap to run, fast where it can be, and resident where it must be — with the heavyweight reasoning reserved for the moments that actually need it.

Azure and GCP, same principle.

AWS is the default, not a requirement. For organizations standardized on Microsoft cloud, the same architecture deploys to Azure; for those on Google Cloud, to GCP. The cloud changes; the principle does not. The system runs in your tenancy, under your identity, with your keys, and your data stays inside the boundary you already trust.

"The system runs where your data already lives. Nothing leaves the boundary you already audit."

Cloud-native, in your tenancy, is what makes an AI system deployable in a regulated enterprise at all. It's why every deployment we ship is also a clean reference implementation of your own cloud, running real workloads against real compliance — without the data ever leaving home.

Book a demo.

We'll walk through how a deployment stands up inside your tenancy — AWS, Azure, or GCP — with your identity, your keys, and an audit trail your risk team can read.

Book a demo