Infrastrukturunabhängige Entity Resolution: Tilores auf AWS, einer anderen Cloud oder eigener Hardware betreiben

Kurzfassung: Tilores ist Entity Resolution in Echtzeit, ausgeliefert als GraphQL-API. Die Engine läuft produktiv auf AWS, und AWS bleibt der schnellste und einfachste Weg, sie zu deployen. Sie ist zugleich infrastrukturunabhängig: Dieselbe Engine läuft in einer anderen Cloud, on-premise oder air-gapped, denn sie benötigt lediglich drei generische Fähigkeiten — einen Key-Value-Store, eine Queue und File Storage — und es ist ihr gleichgültig, welche Produkte diese bereitstellen.

Sie brauchen Entity Resolution, die innerhalb Ihres eigenen Perimeters läuft? Demo buchen oder Tilores Studio kostenlos testen.

Die meisten Anbieter von Entity Resolution beantworten die Frage „Wo läuft das?“ auf eine von zwei unbefriedigenden Arten. Entweder ist das Produkt ein gehosteter Dienst, und die Antwort lautet „in unserer Cloud, und nur dort“, oder das Produkt ist On-Premise-Software, und die Antwort lautet „in Ihrem Rechenzentrum, mit einem Deployment-Projekt, das in Quartalen gemessen wird“. Teams in regulierten Branchen müssen sich am Ende zwischen einer Architektur, die ihnen gefällt, und einer Position zur Datenresidenz, die sie verteidigen können, entscheiden.

Tilores wurde gebaut, um diesen Kompromiss zu vermeiden. Die Resolution-Engine ist bewusst von der darunterliegenden Infrastruktur getrennt. Wo sie läuft, ist damit eine Beschaffungs- und Compliance-Entscheidung und keine Produktbeschränkung. AWS ist der einfachste Weg, Tilores zu betreiben. Es ist nicht der einzige. Dieser Artikel erklärt, was „infrastrukturunabhängig“ auf Architekturebene tatsächlich bedeutet, welche drei Deployment-Modelle wir unterstützen, wodurch sich jeder AWS-Dienst ersetzen lässt und — der Teil, den Anbieter üblicherweise auslassen — was Sie sich operativ aufhalsen, wenn Sie die Engine selbst betreiben.

Was bedeutet „infrastrukturunabhängig“ für eine Entity-Resolution-Engine?

Es bedeutet, dass die Matching- und Resolution-Logik niemals direkt ein Anbieter-SDK aufruft. Tilores verlangt von seiner Umgebung drei Fähigkeiten und erreicht jede davon über eine generische Schnittstelle:

Einen Key-Value-Store für die Indizes, die Kandidatendatensätze finden. Entity Resolution im großen Maßstab ist überwiegend ein Problem der Kandidatengenerierung: Zu einem eingehenden Datensatz muss die kleine Menge existierender Datensätze abgerufen werden, die einen Vergleich lohnt — in einstelligen Millisekunden. Das ist ein Key-Value-Zugriffsmuster, kein relationales.
Eine Queue, um eingehende Arbeit und ausgehende Aktualisierungen zu verwalten. Ingestion, Resolution und nachgelagerte Benachrichtigung sind entkoppelt, sodass aus einem Schwall eingehender Datensätze kein Schwall fehlgeschlagener Requests wird.
File Storage, um die Datensätze selbst und den aufgelösten Entitätengraphen zu halten. Datensätze werden einmal geschrieben und über einen Identifier gelesen; Object Storage ist dafür die natürliche Wahl und der günstigste dauerhafte Ort für einen Graphen, der nur wächst.

Keine dieser drei Fähigkeiten ist an einen Anbieter gebunden. Jeder Key-Value-Store funktioniert. Jede Queue funktioniert. Jeder File- oder Object Storage funktioniert. Auf AWS übernehmen DynamoDB, SQS und S3 diese Rollen. Auf anderer Infrastruktur übernehmen sie die Entsprechungen, die Sie ohnehin schon betreiben.

Entscheidend ist die praktische Konsequenz: Das darunterliegende Produkt auszutauschen ist eine Integrationsaufgabe gegen eine definierte Schnittstelle, keine Neuentwicklung der Engine. Die Matching-Methoden, das Konfidenz-Scoring, die Struktur des Entitätengraphen und die GraphQL-API sind in jedem Deployment identisch. Nur die Adapter darunter ändern sich.

Genau deshalb ist die Engine portabel geblieben, statt mit der Zeit in Richtung AWS abzudriften. Über den ursprünglichen Wechsel zu einer serverlosen Architektur haben wir in unserer Entwicklung von der serverbasierten zur serverlosen Umgebung geschrieben — die Disziplin, Infrastruktur hinter schmalen Schnittstellen zu halten, stammt aus dieser Arbeit und nicht aus einer späteren Portierung.

Läuft Tilores nur auf AWS?

Nein. Auf AWS ist Tilores vollständig gemanagt, am schnellsten deployt und für die meisten Kunden die Empfehlung. Die Engine ist jedoch nicht an AWS gebunden. Derselbe Kern läuft auf Azure, auf Google Cloud, auf Ihren eigenen Servern oder vollständig offline.

Tilores Studio ist der alltägliche Beweis. Studio führt die komplette Resolution-Engine im lokalen Modus auf einem Desktop aus, ganz ohne Daten-Egress — die Daten verlassen die Maschine nie. Studio verbindet sich auf Wunsch auch mit der Tilores Cloud, aber der lokale Modus existiert gerade deshalb, weil die Engine keinen Hyperscaler unter sich braucht, um zu funktionieren. Wenn die Engine auf einem Laptop läuft, läuft sie auch in Ihrem Rechenzentrum. Sie können Studio herunterladen und sich selbst davon überzeugen, ohne mit jemandem sprechen zu müssen.

Wie lässt sich Tilores deployen?

Es gibt drei Modelle, die Komfort gegen Kontrolle abwägen.

Vollständig von Tilores gemanagt. Tilores läuft in unserem eigenen AWS-Konto und ist über den AWS Marketplace verfügbar. Sie verbinden sich mit der GraphQL-API, alles Weitere ist nicht Ihre Sache: keine Infrastruktur, keine Kapazitätsplanung, keine Upgrades. Das ist der schnellste Einstieg und für die meisten Kunden die richtige Wahl.

In Ihrem eigenen AWS-Konto. Dasselbe Produkt, deployt in Ihrer AWS-Umgebung, in jeder Region, die Sie ohnehin nutzen. Das Deployment erfolgt per Terraform und wird von Ihrem Team ausgeführt: Wir brauchen Ihre AWS-Kontonummer und sonst nichts. Tilores hat zu keinem Zeitpunkt Zugriff auf Ihr AWS-Konto — weder während des Deployments noch danach. Sie behalten den Komfort von AWS und das gemanagte Erlebnis, und Daten wie Infrastruktur bleiben in Ihrem Konto, unter Ihrem IAM, Ihrem Logging, Ihrem Key Management und Ihrem Audit.

Auf beliebiger Infrastruktur. Für Organisationen, die AWS nicht nutzen können oder wollen, läuft Tilores in einer anderen Cloud, on-premise oder air-gapped — auf Basis der oben genannten generischen Bausteine.

	Vollständig gemanagt	Ihr eigenes AWS-Konto	Beliebige Infrastruktur
Wo die Daten liegen	AWS-Konto von Tilores	Ihr AWS-Konto	Ihre Cloud, Ihr Rechenzentrum oder ein air-gapped Netz
Wer die Infrastruktur betreibt	Tilores	Sie, per Terraform — Tilores hat keinen Zugriff auf Ihr Konto	Sie, mit unserer Unterstützung
Zeit bis zur ersten aufgelösten Entität	Am schnellsten	Schnell	Definiertes Projekt
Kontrolle über Datenresidenz	Regionswahl	Vollständig, innerhalb Ihres Kontos	Vollständig, einschließlich offline
Skalierungsmodell	Serverless, automatisch	Serverless, automatisch	Was immer Ihre Plattform bietet
Passt am besten zu	Den meisten Kunden	Regulierten Teams, die bereits auf AWS sind	No-Cloud-Vorgaben, Souveränitätsregeln, bestehende On-Premise-Landschaft

Der Komfort ist oben in dieser Liste am größten, die Kontrolle unten. AWS ist der Standard, nicht die Grenze. Alle drei Modelle werden auf derselben Grundlage abgerechnet — Unified Customer Records, also die aufgelösten Entitäten, die Sie tatsächlich halten, und nicht die Rohdatensatzzahl —, wobei sich die kommerzielle Ausgestaltung danach richtet, wie viel Infrastruktur Sie selbst betreiben.

Wodurch lässt sich jeder AWS-Dienst ersetzen?

Was Tilores braucht	Wofür	Auf AWS	Überall sonst
Index für die Kandidatensuche	Die vergleichenswerten Datensätze in Millisekunden abrufen	DynamoDB	Jeder Key-Value-Store (zum Beispiel Aerospike, ScyllaDB, Redis)
Queue für eingehende Arbeit und ausgehende Aktualisierungen	Ingestion von Resolution und nachgelagerter Benachrichtigung entkoppeln	SQS	Jede Queue (Kafka, RabbitMQ, NATS)
Storage für Datensätze und den Entitätengraphen	Dauerhafte Heimat für Quelldatensätze und aufgelöste Entitäten	S3	Jeder File- oder Object Storage
Rechenleistung für die Resolution	Die Matching- und Resolution-Arbeit ausführen	Lambda	Jede Container-Laufzeitumgebung

Die Beispiele sind illustrativ. Gefordert ist die Fähigkeit, nicht die Marke. Wenn Sie bereits einen Key-Value-Store, eine Queue und File Storage betreiben — und die meisten großen Organisationen betreiben alle drei —, kann Tilores sie nutzen.

Was übernehmen Sie tatsächlich, wenn Sie selbst betreiben?

Diese Frage entscheidet, ob sich Infrastrukturunabhängigkeit für ein bestimmtes Team lohnt, und sie verdient eine klare Antwort statt eines Feature-Stichpunkts.

Im vollständig gemanagten Modell betreiben wir alles. In Ihrem eigenen AWS-Konto ist die Aufteilung schmal und die Übergabe sauber: Sie führen ein Terraform-Deployment in Ihr eigenes Konto aus, und das Einzige, was wir von Ihnen brauchen, ist Ihre AWS-Kontonummer. Es werden keine Zugangsdaten ausgetauscht, und Tilores erhält zu keinem Zeitpunkt Zugriff auf dieses Konto — Guardrails, Kosten und Audit-Trail gehören vollständig Ihnen. Der Aufwand bleibt gering, weil die Dienste darunter genau jene sind, für die das Produkt gebaut wurde.

Außerhalb von AWS wird die Aufteilung breiter. Sie stellen den Key-Value-Store, die Queue, den Object Storage und die Container-Plattform bereit und betreiben sie. Ihnen gehören deren Kapazität, Hochverfügbarkeit, Backups, Patching und Monitoring. Sie entscheiden, wie die Engine skaliert, denn es gibt keinen serverlosen Autoscaler, der das still im Hintergrund erledigt — das ist eine Eigenschaft von Lambda, nicht von Tilores. Und jede neue Version der Engine ist ein Deployment, das Sie einplanen, statt eines, das einfach erscheint.

Bei uns bleibt: die Engine, die Adapter, die Matching-Logik, der Upgrade-Pfad und der Support für die Integration selbst. Was sich wirklich von einem klassischen On-Premise-Produkt unterscheidet, ist die Art der Arbeit. Es gibt keinen maßgeschneiderten Fork der Software für Ihre Umgebung und keinen Anbieter-Techniker, der vor Ort sitzen muss, damit alles am Leben bleibt. Es ist dieselbe Engine, nur gegen andere Infrastruktur konfiguriert.

Das ist eine echte operative Verpflichtung, und was Sie dafür bekommen, sind Kontrolle und in der Regel niedrigere Latenz, als die gemanagte Cloud bieten kann — siehe den nächsten Abschnitt. Teams ohne Appetit auf Infrastruktur sollten den gemanagten Weg wählen und über all das gar nicht erst nachdenken. Teams, die die Bausteine ohnehin betreiben oder gar nicht anders deployen können, finden den Kompromiss meist gut. Wenn Sie das gegen den Bau einer eigenen Matching-Schicht abwägen, sind die Abwägungen in Entity Resolution selbst bauen oder kaufen dargelegt.

Verhält sich die Engine außerhalb von AWS anders?

Die Resolution-Logik nicht. Matching-Methoden, Konfidenz- und Hit-Scores, der Entitätengraph, der Audit-Trail und die GraphQL-API sind in jedem Deployment gleich. Das heißt: Eine Evaluierung, die Sie auf dem gemanagten Tilores durchführen, sagt Ihnen weiterhin, was Sie nach dem Umzug erwartet.

Die Performance verbessert sich meist. Das überrascht alle, die Self-Hosting für den langsameren Weg halten, aber Serverless ist ein Kompromiss zugunsten des Komforts, nicht zugunsten der Geschwindigkeit: Gemanagte, mandantenfähige Dienste nehmen Ihnen die gesamte operative Arbeit ab und lassen sich das in Latenz, Netzwerk-Hops und gelegentlichen Cold Starts bezahlen. Dedizierte Infrastruktur trifft die umgekehrte Wahl. Auf einem gut dimensionierten Key-Value-Store — Aerospike, ScyllaDB oder Redis auf Maschinen, die Sie kontrollieren, mit dem Working Set im Arbeitsspeicher und kurzem Netzwerkpfad — sind Kandidatenabfragen von rund 1 ms und Inserts von rund 2 ms realistisch, und das ist eher das wahrscheinliche Ergebnis als der Bestfall. Teams, die selbst hosten, sind meist jene mit den strengsten Latenzbudgets, und sie landen in der Regel schneller als die gemanagte Cloud, nicht langsamer.

Der Vorbehalt liegt auf der Hand: Diese Geschwindigkeit ist eine Eigenschaft der Infrastruktur, die Sie bereitstellen, und nichts, was die Engine von allein herbeizaubert. Ein unterdimensionierter Cluster wird langsamer sein als DynamoDB, und keine noch so gute Portabilität der Engine gleicht das aus. Auch Durchsatzgrenzen werden zu Ihrer Planungsaufgabe — auf AWS fangen Dienste, die automatisch skalieren, eine Lastspitze ab; auf Ihrer eigenen Plattform fängt sie die Kapazität ab, die Sie vorab dimensioniert haben.

Die richtige Erwartung lautet also: identische Ergebnisse und eine Performance, die der Infrastruktur folgt, die Sie ihr geben — was auf richtig dimensionierter dedizierter Hardware in der Regel schneller bedeutet als die gemanagte Cloud. Das ist es, was „infrastrukturunabhängig“ ehrlicherweise einbringt: dieselben Antworten, wo immer Sie sie berechnet brauchen.

Warum ist das für regulierte Unternehmen wichtig?

Weil Entity Resolution genau die Daten verarbeitet, die diese Organisationen am strengsten hüten: Namen, Adressen, nationale Kennnummern und die Verbindungen zwischen Konten. Viele werden diese Daten nicht in die Cloud eines Dritten geben, und in manchen Jurisdiktionen und unter manchen Vorgaben dürfen sie es nicht.

Vier Zwänge tauchen in Evaluierungen immer wieder auf:

Regeln zu Datenresidenz und Datenübermittlung. Personenbezogene Daten, die eine Grenze überschreiten, fallen unter Kapitel V der DSGVO und in mehreren Branchen zusätzlich unter nationale Aufsichtsvorgaben. Wenn die Resolution in Ihrem eigenen Konto oder Ihrem eigenen Rechenzentrum läuft, erübrigt sich die Übermittlungsfrage, statt beantwortet werden zu müssen.

Konzentrations- und Exit-Risiko. DORA verpflichtet EU-Finanzunternehmen, nachzuweisen, dass ein kritischer IKT-Dienstleister abgelöst oder ersetzt werden kann. Für eine Komponente, die nur auf einem einzigen Hyperscaler läuft, lässt sich schwer ein glaubwürdiger Exit-Plan schreiben. Für eine, die auf drei generischen Fähigkeiten läuft, schon.

Bestehende Infrastrukturinvestitionen. Organisationen, die eine Kafka-Landschaft und einen Key-Value-Store bereits eingekauft, personell besetzt und zertifiziert haben, fragen zu Recht, warum eine neue Komponente eine neue Plattform erfordern sollte.

Air-gapped und souveräne Umgebungen. Manche Workloads haben schlicht keinen Weg in eine Public Cloud. Entweder die Software läuft offline, oder sie wird nicht eingesetzt.

Im eigenen Konto oder auf eigener Infrastruktur betrieben, sitzt Tilores innerhalb Ihres Perimeters: Die Daten bleiben unter Ihren Kontrollen und Ihrem Audit, Residenzanforderungen lassen sich je Jurisdiktion erfüllen, und das Deployment ist Software, die Sie betreiben, statt eines Dienstes, der Ihre Daten hält. Unsere eigene Herkunft liegt in der Infrastruktur für Auskunfteien, in der Arbeit mit Unternehmen in Europa und den USA — und genau von dort stammen die meisten dieser Anforderungen. Für das größere Bild einer Evaluierung siehe Identity-Resolution-Anbieter für Banken bewerten und Echtzeit-Identity-Resolution unter der DSGVO.

Eine Klarstellung ist angebracht: Infrastrukturunabhängigkeit ist nicht dasselbe wie ein Compliance-Zertifikat. Tilores ist SOC 2 zertifiziert, und ein Deployment in Ihrer eigenen Umgebung erbt Ihre Kontrollen, nicht unsere. Die Wahl, wo die Engine läuft, beantwortet eine Residenz- und Souveränitätsfrage; eine Audit-Frage beantwortet sie damit noch nicht.

Was sollten Sie prüfen, bevor Sie sich für ein Deployment-Modell entscheiden?

Dürfen die Daten rechtlich und vertraglich im Cloud-Konto eines Dritten liegen? Wenn ja, ist das vollständig gemanagte Modell fast immer die richtige Antwort.
Gibt es eine Vorgabe, die eine bestimmte Cloud vorschreibt oder verbietet? Sie entscheidet über das Modell, bevor die technische Evaluierung überhaupt beginnt.
Betreiben Sie bereits einen Key-Value-Store, eine Queue und Object Storage produktiv, mit einem Team in Rufbereitschaft? Wenn nicht, bringt das Modell „beliebige Infrastruktur“ eine operative Verpflichtung mit sich und nicht bloß ein anderes Deployment-Ziel.
Wer verantwortet Skalierung und Kapazität? Serverless auf AWS macht das unsichtbar; außerhalb von AWS wird es zu einer Planungsaufgabe, die Ihnen gehört.
Gibt es eine Anforderung, Exit oder Ersetzbarkeit nachzuweisen? Dann ist Portabilität ein Beschaffungsargument und nicht nur eine architektonische Vorliebe.
Braucht irgendetwas nachgelagert die aufgelöste Identität in Echtzeit? Die Antwort ist in jedem Modell dieselbe, aber sie bestimmt, wie Sie die Infrastruktur dimensionieren. Siehe Echtzeit- vs. Batch-Entity-Resolution.

Ist AWS weiterhin der empfohlene Weg, Tilores zu betreiben?

Ja. Für die meisten Kunden ist AWS die richtige Wahl: Es deployt am schnellsten, skaliert automatisch und braucht keine eigene Infrastruktur. Dedizierte Hardware kann es bei der Latenz schlagen, aber nur, wenn Sie die Plattform und das Team dafür bereits haben — für alle anderen ist serverless AWS das bessere Geschäft, und Infrastrukturunabhängigkeit ist kein Grund, sich Arbeit aufzuhalsen, die man nicht will.

Das Designziel war nie, von AWS wegzukommen. Es war sicherzustellen, dass die Frage, wo Tilores läuft, Ihre Entscheidung ist und keine Beschränkung des Produkts.

In einem Satz

Tilores ist AWS-nativ von Haus aus und infrastrukturunabhängig by design: dieselbe Entity-Resolution-Engine, dieselben Ergebnisse, laufend dort, wo Sie sie brauchen, auf dem, was Sie ohnehin betreiben.

Bereit herauszufinden, welches Modell passt? Buchen Sie eine Demo, und wir schneiden es auf Ihre tatsächlichen Rahmenbedingungen zu, oder starten Sie mit dem Evaluation Build und lassen Sie die Engine zuerst auf Ihrem eigenen Rechner laufen.

FAQ

Ist Tilores ein reines AWS-Produkt?

Nein. Tilores läuft produktiv auf AWS, und AWS ist das empfohlene Deployment, aber die Engine benötigt lediglich einen Key-Value-Store, eine Queue und File Storage. Sie läuft ebenso auf Azure, Google Cloud, On-Premise-Hardware oder in einer air-gapped Umgebung — mit den Entsprechungen, die Sie ohnehin betreiben.

Welche Infrastruktur benötigt Tilores tatsächlich?

Drei generische Fähigkeiten plus einen Ort, an dem der Code läuft: einen Key-Value-Store für die Kandidatenindizierung, eine Queue für eingehende Arbeit und ausgehende Aktualisierungen, File- oder Object Storage für Datensätze und den aufgelösten Entitätengraphen sowie eine Container-Laufzeitumgebung für die Resolution-Berechnung. Auf AWS sind das DynamoDB, SQS, S3 und Lambda.

Lässt sich Tilores on-premise oder air-gapped deployen?

Ja. Tilores kann vollständig in Ihrem eigenen Rechenzentrum laufen, einschließlich air-gapped Netzen ohne ausgehende Verbindungen. Tilores Studio führt die vollständige Resolution-Engine bereits heute im lokalen Modus auf einem Desktop aus, ganz ohne Daten-Egress — dieselbe Engine, die ohne jede Cloud darunter läuft.

Kann Tilores in unserem eigenen AWS-Konto statt in Ihrem laufen?

Ja. Das ist eines der drei unterstützten Deployment-Modelle. Das Produkt ist identisch mit der vollständig gemanagten Variante und wird per Terraform in Ihr AWS-Konto und Ihre Region deployt — alles, was wir von Ihnen brauchen, ist Ihre AWS-Kontonummer. Tilores hat zu keinem Zeitpunkt Zugriff auf Ihr Konto, und Daten wie Infrastruktur bleiben unter Ihrem IAM, Logging, Key Management und Audit.

Bedeutet ein Wechsel weg von AWS eine andere Version des Produkts?

Nein. Es ist dieselbe Engine mit anderen Infrastruktur-Adaptern. Matching-Methoden, Konfidenz- und Hit-Scores, der Entitätengraph, der Audit-Trail und die GraphQL-API sind über alle Deployment-Modelle hinweg identisch. Eine Evaluierung auf dem gemanagten Tilores sagt also voraus, was Sie nach dem Umzug bekommen.

Ist die Performance außerhalb von AWS dieselbe?

Die Ergebnisse sind identisch, und selbst gehostete Deployments sind oft schneller. Serverless-Dienste tauschen Latenz gegen null operative Arbeit; auf dedizierter, gut dimensionierter Infrastruktur sind Kandidatenabfragen von rund 1 ms und Inserts von rund 2 ms realistisch. Der Kompromiss: Kapazität und Skalierung werden zu Ihrer Planungsaufgabe, weil kein Autoscaler Lastspitzen still abfängt, und ein unterdimensionierter Cluster wird langsamer sein als das gemanagte Äquivalent.

Was müssen wir bei einem selbst gehosteten Deployment selbst betreiben?

Den Key-Value-Store, die Queue, den Object Storage und die Container-Plattform, einschließlich Verfügbarkeit, Backups, Patching, Monitoring und Kapazität. Tilores stellt die Engine, die Adapter, den Upgrade-Pfad und den Support für die Integration.

Ändert das Deployment-Modell die Preisgestaltung von Tilores?

Die Grundlage bleibt über alle Modelle hinweg gleich: Der Preis richtet sich nach Unified Customer Records, also den aufgelösten Entitäten, die Sie halten, und nicht nach der Zahl der Rohdatensätze, die Sie einspeisen. Die kommerzielle Ausgestaltung unterscheidet sich danach, wie viel Infrastruktur Tilores betreibt und wie viel Sie selbst. Die aktuelle Aufschlüsselung finden Sie auf der Preisseite.

Macht uns der Betrieb von Tilores in unserer eigenen Umgebung compliant?

Er beseitigt die Fragen nach grenzüberschreitender Übermittlung und Verwahrung durch Dritte, was häufig der Blocker ist, aber er ist keine Zertifizierung. Tilores ist SOC 2 zertifiziert; ein Deployment in Ihrer Umgebung läuft unter Ihren Kontrollen und Ihrem Audit, Compliance bleibt also eine Eigenschaft davon, wie Sie es betreiben.