Infrastructure-Agnostic Entity Resolution: Running Tilores on AWS, Another Cloud, or Your Own Hardware
TL;DR: Tilores is real-time entity resolution delivered as a GraphQL API. It runs in production on AWS, and AWS remains the fastest and simplest way to deploy it. It is also infrastructure-agnostic: the same engine runs on another cloud, on-premise, or air-gapped, because it depends on only three generic capabilities — a key-value store, a queue, and file storage — and it does not care which products provide them.
Need entity resolution that runs inside your own perimeter? Book a Demo or Try Tilores Studio (Free).
Most entity resolution vendors answer the “where does it run?” question in one of two unsatisfying ways. Either the product is a hosted service and the answer is “our cloud, and only our cloud,” or the product is on-premise software and the answer is “your data centre, with a deployment project measured in quarters.” Teams in regulated industries end up choosing between an architecture they like and a data residency position they can defend.
Tilores was built to avoid that trade. The resolution engine is deliberately separated from the infrastructure underneath it, so where it runs is a procurement and compliance decision rather than a product constraint. AWS is the easiest way to run Tilores. It is not the only way. This article covers what “infrastructure-agnostic” actually means at the architecture level, the three deployment models we support, what each AWS service can be replaced with, and — the part vendors usually skip — what you take on operationally when you run it yourself.
What does “infrastructure-agnostic” mean for an entity resolution engine?
It means the matching and resolution logic never calls a vendor SDK directly. Tilores asks its environment for three capabilities, and reaches each one through a generic interface:
- A key-value store for the indexes that find candidate records. Entity resolution at scale is mostly a candidate-generation problem: given an incoming record, retrieve the small set of existing records worth comparing it to, in single-digit milliseconds. That is a key-value lookup pattern, not a relational one.
- A queue to manage incoming work and outgoing updates. Ingestion, resolution, and downstream notification are decoupled, so a burst of inbound records does not become a burst of failed requests.
- File storage to hold the records themselves and the resolved entity graph. Records are written once and read by identifier; object storage is the natural fit, and it is the cheapest durable place to keep a graph that only grows.
None of the three is tied to a vendor. Any key-value store works. Any queue works. Any file or object storage works. On AWS those roles are filled by DynamoDB, SQS, and S3. On other infrastructure they are filled by whatever equivalents you already run.
The practical consequence is the important bit: swapping the underlying product is an integration task against a defined interface, not a rewrite of the engine. The matching methods, the confidence scoring, the entity graph structure, and the GraphQL API are identical in every deployment. Only the adapters underneath change.
This is also why the engine stayed portable rather than drifting toward AWS over time. We wrote about the original move to a serverless architecture in our evolution from a server-based to a serverless environment — the discipline of keeping infrastructure behind narrow interfaces came out of that work, not out of a later porting exercise.
Does Tilores only run on AWS?
No. AWS is where Tilores is fully managed, quickest to deploy, and recommended for most customers. But the engine is not locked to AWS. The same core runs on Azure, on Google Cloud, on your own servers, or fully offline.
Tilores Studio is the everyday proof. Studio runs the entire resolution engine locally on a desktop in local mode, with zero data egress — the data never leaves the machine. Studio also connects to Tilores Cloud when you want it to, but the local mode exists precisely because the engine does not need a hyperscaler underneath it to work. If the engine can run on a laptop, it can run in your data centre. You can download Studio and see that for yourself without talking to anyone.
How can Tilores be deployed?
There are three models, trading convenience for control.
Fully managed by Tilores. Tilores runs in our own AWS account, available through the AWS Marketplace. You connect to the GraphQL API and nothing else is your concern: no infrastructure, no capacity planning, no upgrades. This is the fastest way to start and the right choice for most customers.
In your own AWS account. The same product, deployed inside your AWS environment, in any region you already use. Deployment is handled by Terraform, run by your team: we need your AWS account number and nothing else. Tilores has no access to your AWS account at any point — not during deployment, not afterwards. You keep the AWS convenience and the managed experience, and the data and the infrastructure stay in your account, under your IAM, your logging, your key management, and your audit.
On any infrastructure. For organisations that cannot or will not use AWS, Tilores runs on another cloud, on-premise, or air-gapped, using the generic building blocks above.
| Fully managed | Your own AWS account | Any infrastructure | |
|---|---|---|---|
| Where the data sits | Tilores AWS account | Your AWS account | Your cloud, data centre, or air-gapped network |
| Who operates the infrastructure | Tilores | You, via Terraform — Tilores has no access to your account | You, with our support |
| Time to first resolved entity | Fastest | Fast | Scoped project |
| Data residency control | Region choice | Full, inside your account | Full, including offline |
| Scaling model | Serverless, automatic | Serverless, automatic | Whatever your platform provides |
| Best fit | Most customers | Regulated teams already on AWS | No-cloud mandates, sovereignty rules, existing on-premise estate |
Convenience is highest at the top of that list; control is highest at the bottom. AWS is the default, not the boundary. All three models are priced on the same basis — Unified Customer Records, the resolved entities you actually hold, rather than raw record counts — with the commercial shape differing by how much infrastructure you operate.
What can replace each AWS service?
| What Tilores needs | Why it needs it | On AWS | Anywhere else |
|---|---|---|---|
| Index for candidate lookup | Retrieve the records worth comparing, in milliseconds | DynamoDB | Any key-value store (for example Aerospike, ScyllaDB, Redis) |
| Queue for incoming work and outgoing updates | Decouple ingestion from resolution and from downstream notification | SQS | Any queue (Kafka, RabbitMQ, NATS) |
| Storage for records and the entity graph | Durable home for source records and resolved entities | S3 | Any file or object storage |
| Resolution compute | Run the matching and resolution work | Lambda | Any container runtime |
The examples are illustrative. The requirement is the capability, not the brand. If you already run a key-value store, a queue, and file storage — and most large organisations run all three — Tilores can use them.
What do you actually take on when you run it yourself?
This is the question that decides whether infrastructure independence is worth it for a given team, and it deserves a straight answer rather than a feature bullet.
In the fully managed model, we run everything. In your own AWS account, the split is narrow and the handover is clean: you run a Terraform deployment into your own account, and the only thing we need from you is your AWS account number. No credentials change hands and Tilores never holds access to that account, so the guardrails, the spend, and the audit trail are entirely yours. It stays a light lift because the services underneath are the ones the product was built on.
Off AWS, the split widens. You provide and operate the key-value store, the queue, the object storage, and the container platform. You own their capacity, their high availability, their backups, their patching, and their monitoring. You decide how the engine scales, because there is no serverless autoscaler doing it silently — that is a Lambda property, not a Tilores one. And each new version of the engine is a deployment you schedule rather than one that simply appears.
What stays with us: the engine, the adapters, the matching logic, the upgrade path, and support for the integration itself. What is genuinely different from a classic on-premise product is the shape of the work. There is no bespoke fork of the software for your environment, and no vendor engineer required on site to keep it alive. It is the same engine, configured against different infrastructure.
That is a real operational commitment, and what you get in exchange is control and, usually, lower latency than the managed cloud can offer — see the next section. Teams with no infrastructure appetite should take the managed route and not think about any of this. Teams that already run the building blocks, or that cannot deploy any other way, tend to find the trade a good one. If you are weighing this against writing your own matching layer instead, the trade-offs are laid out in build versus buy for entity resolution.
Does the engine behave differently off AWS?
The resolution logic does not. Matching methods, confidence and hit scores, the entity graph, the audit trail, and the GraphQL API are the same in every deployment, which means an evaluation you run on managed Tilores still tells you what to expect after you move it.
Performance usually improves. That surprises people who assume self-hosting is the slower path, but serverless is a convenience trade, not a speed one: managed, multi-tenant services remove all the operational work and charge for it in latency, network hops, and the occasional cold start. Dedicated infrastructure makes the opposite trade. On a well-provisioned key-value store — Aerospike, ScyllaDB, or Redis running on machines you control, with the working set in memory and a short network path — candidate lookups of around 1 ms and inserts of around 2 ms are realistic, and that is the likely outcome rather than the best case. Teams that self-host tend to be the ones with the strictest latency budgets, and they generally end up faster than the managed cloud, not slower.
The caveat is the obvious one: that speed is a property of the infrastructure you provide, not something the engine conjures on its own. An under-provisioned cluster will be slower than DynamoDB, and no amount of engine portability compensates for that. Throughput ceilings become yours to plan, too — on AWS a spike is absorbed by services that scale automatically, and on your own platform it is absorbed by capacity you sized in advance.
So the correct expectation is: identical results, and performance that tracks the infrastructure you give it — which, on dedicated hardware sized properly, usually means faster than the managed cloud. That is what “infrastructure-agnostic” honestly buys: the same answers, wherever you need them computed.
Why does this matter for regulated enterprises?
Because entity resolution processes the data these organisations guard most closely: names, addresses, national identifiers, and the links between accounts. Many will not send that data to a third party’s cloud, and in some jurisdictions and under some mandates they cannot.
Four pressures show up repeatedly in evaluations:
Data residency and transfer rules. Personal data crossing a border invokes Chapter V of the GDPR and, in several sectors, national supervisory guidance on top of it. Running resolution inside your own account or your own data centre removes the transfer question rather than answering it.
Concentration and exit risk. DORA pushed EU financial entities to demonstrate that a critical ICT provider can be exited or substituted. A component that only runs on one hyperscaler is difficult to write a credible exit plan for. One that runs on three generic capabilities is not.
Existing infrastructure investment. Organisations that have already bought, staffed, and certified a Kafka estate and a key-value store reasonably ask why a new component should require a new platform.
Air-gapped and sovereign environments. Some workloads simply have no route to a public cloud. Either the software runs offline or it is not used.
Run in your own account or your own infrastructure, Tilores sits inside your perimeter: the data stays under your controls and your audit, residency can be satisfied per jurisdiction, and the deployment is software you operate rather than a service that holds your data. Our own heritage is in credit bureau infrastructure, working with enterprises across Europe and the US, which is where most of these requirements came from in the first place. For the wider evaluation picture, see how to evaluate identity resolution vendors in banking and running real-time identity resolution under GDPR.
One clarification worth making: infrastructure independence is not the same as a compliance certificate. Tilores is SOC 2 certified, and a deployment into your own environment inherits your controls, not ours. Choosing where the engine runs answers a residency and sovereignty question; it does not by itself answer an audit question.
What should you check before choosing a deployment model?
- Can the data legally and contractually sit in a third party’s cloud account? If yes, fully managed is almost always the right answer.
- Is there a mandate that names a specific cloud, or forbids one? That decides the model before any technical evaluation starts.
- Do you already run a key-value store, a queue, and object storage in production, with a team on call for them? If not, the “any infrastructure” model adds an operational commitment, not just a deployment target.
- Who is accountable for scaling and capacity? Serverless on AWS makes this invisible; off AWS it becomes a planning exercise you own.
- Is there an exit or substitutability requirement to evidence? If so, portability is a procurement asset, not just an architectural preference.
- Does anything downstream need the resolved identity in real time? The answer is the same in every model, but it shapes how you size the infrastructure. See real-time versus batch entity resolution.
Is AWS still the recommended way to run Tilores?
Yes. For most customers AWS is the right choice: it deploys fastest, it scales automatically, and it needs no infrastructure of your own. Dedicated hardware can beat it on latency, but only if you already have the platform and the team to run it — for everyone else, serverless AWS is the better bargain, and infrastructure independence is not a reason to take on work you do not want.
The design goal was never to move away from AWS. It was to make sure that where Tilores runs is your decision, not a constraint of the product.
In one line
Tilores is AWS-native by default and infrastructure-agnostic by design: the same entity resolution engine, the same results, running wherever you need it, on whatever you already run.
Ready to work out which model fits? Book a demo and we will scope it against your actual constraints, or start with the evaluation build and run the engine on your own machine first.
FAQ
Is Tilores an AWS-only product?
No. Tilores runs in production on AWS and AWS is the recommended deployment, but the engine depends only on a key-value store, a queue, and file storage. It also runs on Azure, Google Cloud, on-premise hardware, or in an air-gapped environment using whichever equivalents you already operate.
What infrastructure does Tilores actually require?
Three generic capabilities plus somewhere to run the code: a key-value store for candidate indexing, a queue for incoming work and outgoing updates, file or object storage for records and the resolved entity graph, and a container runtime for resolution compute. On AWS these are DynamoDB, SQS, S3, and Lambda.
Can Tilores be deployed on-premise or air-gapped?
Yes. Tilores can run entirely inside your own data centre, including air-gapped networks with no outbound connectivity. Tilores Studio already runs the full resolution engine locally on a desktop in local mode with zero data egress, which is the same engine running without any cloud underneath it.
Can Tilores run in our own AWS account instead of yours?
Yes. This is one of the three supported deployment models. The product is identical to the fully managed version, deployed by Terraform into your AWS account and region — all we need from you is your AWS account number. Tilores has no access to your account at any point, and the data and infrastructure stay under your IAM, logging, key management, and audit.
Does moving off AWS mean a different version of the product?
No. It is the same engine with different infrastructure adapters. Matching methods, confidence and hit scores, the entity graph, the audit trail, and the GraphQL API are identical across all deployment models, so an evaluation run on managed Tilores predicts what you get after you move it.
Will performance be the same outside AWS?
Results will be identical, and self-hosted deployments are often faster. Serverless services trade latency for zero operational work; on dedicated, well-provisioned infrastructure, candidate lookups of around 1 ms and inserts of around 2 ms are realistic. The trade-off is that capacity and scaling become yours to plan, because no autoscaler is absorbing spikes silently, and an under-provisioned cluster will be slower than the managed equivalent.
What do we have to operate ourselves in a self-hosted deployment?
The key-value store, the queue, the object storage, and the container platform, including their availability, backups, patching, monitoring, and capacity. Tilores provides the engine, the adapters, the upgrade path, and support for the integration.
Does the deployment model change how Tilores is priced?
The basis stays the same across models: pricing is driven by Unified Customer Records, the resolved entities you hold, rather than the raw record count you feed in. The commercial shape differs according to how much infrastructure Tilores operates versus how much you operate. See the pricing page for the current breakdown.
Does running Tilores in our own environment make us compliant?
It removes the cross-border transfer and third-party custody questions, which is often the blocker, but it is not a certification. Tilores is SOC 2 certified; a deployment inside your environment runs under your controls and your audit, so compliance remains a property of how you operate it.
See what resolved entity data does for your business — and your AI.