Amazon Bedrock Cross-Region Inference gibt euch höheren effektiven Durchsatz und weniger regionale Throttling-Fehler ohne Routing-Aufschlag, was fast kostenloser Resilienz gleichkommt. Die Falle ist, dass ein globales Inference-Profil euren Prompt an jede Region schicken kann, die gerade Kapazität hat, und wenn dieser Prompt regulierte Daten trägt, ist "wo auch immer Kapazität ist" keine Antwort, die euer Compliance-Team akzeptiert. Das Feature ist wirklich nützlich. Ob es ein Gewinn oder ein Verstoß ist, hängt vollständig davon ab, welche Art von Inference-Profil man wählt, und diese Wahl lässt sich leicht treffen, ohne zu lesen, was sie bedeutet.

Der Reiz ist real. Ein Modellaufruf in einer einzigen Region ist durch deren Kapazität und ihre regionalen Throttling-Limits gedeckelt. Cross-Region Inference lässt Bedrock Anfragen über Regionen verteilen, sodass ein Spike, der in einer Region Throttling-Fehler geworfen hätte, abgefangen wird. Man bekommt bessere Tail-Latenz und weniger 429er, ohne für das Routing selbst einen Aufpreis zu zahlen. Die Frage ist nicht, ob das hilft. Sie ist, wohin die eigenen Daten gehen dürfen, während es hilft.

Zwei Profile, zwei sehr unterschiedliche Versprechen

Bedrock bietet zwei Varianten von Cross-Region Inference, und die Lücke zwischen ihnen ist der ganze Artikel:

  • Geografisches Profil. Routing ist auf eine benannte Geografie beschränkt, etwa USA oder EU. Bedrock wählt die beste Region innerhalb dieser Grenze, sodass ein EU-geografisches Profil die Verarbeitung innerhalb der EU-Regionen hält. Das ist die Wahl, wenn man Data-Residency-Anforderungen hat.
  • Globales Profil. Routing ist für maximalen Durchsatz und Kosteneffizienz unbeschränkt. Bedrock schickt die Anfrage an die beste verfügbare kommerzielle Region überall. Das ist die Wahl, die den Prompt eines europäischen Nutzers in eine Region außerhalb Europas verschieben kann.

Beide verbessern die Resilienz. Nur eine respektiert eine geografische Grenze. Das globale Profil zu wählen, weil es den besten Durchsatz verspricht, ohne zu prüfen, welche Daten hindurchfließen, ist der Weg, wie aus einer Durchsatzoptimierung ein Residency-Vorfall wird.

Residency betrifft den Prompt, nicht nur den Speicher

Teams, die ihre Datenbank sorgfältig in der EU halten, vergessen manchmal, dass auch ein Inference-Aufruf Daten verschickt. Der Prompt ist Daten. Enthält er personenbezogene Daten, Kundendatensätze oder irgendetwas, das eine Regulierung an eine Geografie bindet, dann fällt die Region, die diesen Prompt verarbeitet, genau wie die Region, die ihn speichert, unter Residency. Ein globales Profil, das diesen Prompt zur Verarbeitung auf einen anderen Kontinent weiterleitet, hat regulierte Daten über eine Grenze bewegt, auch wenn nichts "gespeichert" wurde. Die Residency-Frage folgt den Daten durch die Inferenz, nicht nur in die Datenbank.

Wie man pro Workload entscheidet

Das ist keine einzelne Einstellung für den ganzen Account. Es ist eine Entscheidung pro Workload, und die entscheidende Frage ist, was der Prompt trägt:

Does the prompt contain data bound to a geography?
  yes -> geographic profile, matched to the required region
         (accept the capacity ceiling of that geography)
  no  -> global profile is fine
         (take the throughput and resilience, no residency risk)

Ein Workload, der regulierte europäische Daten verarbeitet, nutzt ein EU-geografisches Profil und lebt damit, auf EU-Kapazität gedeckelt zu sein, weil die Alternative nicht konform ist, egal wie schnell sie ist. Ein Workload mit nicht-sensiblen Daten, interne Tools, öffentliche Inhalte, synthetische Prompts, kann das globale Profil nehmen und die Resilienz genießen, ohne etwas zu riskieren. Die Preisgestaltung wird in beiden Fällen aus der Region berechnet, von der aus man aufruft, das ist also eine Compliance-Entscheidung, keine Kostenentscheidung.

Das Fazit

Cross-Region Inference ist günstige Resilienz, wenn man das Profil zu den Daten passend wählt. Ein geografisches Profil hält die Verarbeitung innerhalb einer Grenze und ist die richtige Standardwahl für alles, was regulierte Daten berührt, um den Preis der Kapazitätsobergrenze dieser Geografie. Ein globales Profil gibt den besten Durchsatz und ist für Daten ohne Residency-Beschränkung in Ordnung. Die Falle ist nicht das Feature, es ist, das globale Profil aus Reflex zu wählen, weil es schneller klingt, und später zu entdecken, dass "beste verfügbare Region" still regulierte Prompts über eine Grenze weitergeleitet hat. Man entscheidet pro Workload und lässt das, was der Prompt trägt, das Profil bestimmen.

Weiterlesen

Für das Multi-Region-Architektur- und Data-Residency-Playbook über AWS hinweg gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.