OpenAI auf AWS hat dein letztes Aufschub-Argument zerstört

OpenAI-Modelle, Codex und Managed Agents sind jetzt direkt auf AWS verfügbar. Für die Mehrheit der Engineering-Teams zwischen 50 und 500 FTE, die ihre Datenstruktur rund um AWS aufgebaut und OpenAI still und leise aufgeschoben haben, ist der Wartungsgrund verschwunden. Die eigentliche Frage lautet nicht mehr, ob du OpenAI in deiner AWS-Umgebung nutzen kannst — sondern ob die Routing-Entscheidungen der letzten 18 Monate noch die richtigen sind.

Was sich geändert hat

Seit Ende April 2026 sind OpenAI GPT-Modelle, Codex und Managed Agents auf AWS verfügbar. Unternehmen können OpenAI-Funktionen direkt innerhalb ihrer bestehenden AWS-Umgebungen betreiben. Teams können OpenAI-Modelle aufrufen, ohne dass Daten die AWS-Grenze verlassen — mit Integration in die IAM-Policies, VPC-Konfigurationen, Logging-Pipelines und Compliance-Controls, die bereits im Einsatz sind.

Codex — OpenAIs System für Code-Generierung und Software-Agents — ist im Launch enthalten, nicht nur die Chat-Modelle. Managed Agents, OpenAIs gehostete Orchestrierungsschicht für mehrstufige agentische Workflows, landet ebenfalls gleichzeitig auf AWS. Das sind drei verschiedene Capability-Tiers auf einmal: Foundation Models, ein Coding-Spezialsystem und eine Orchestrierungs-Runtime.

Das folgt auf OpenAIs frühere Verfügbarkeit auf Azure und über die direkte API — was AWS-native Teams vor eine echte architektonische Zwickmühle stellte: Daten in eine andere Cloud verschieben, um das Modell zu nutzen, Cross-Cloud-Egress-Kosten akzeptieren oder Bedrocks native Modelle verwenden und OpenAI ganz auslassen. Dieser dreifache Kompromiss ist auf der Infrastrukturseite jetzt gelöst.

Warum dein Bedrock-Vertrag jetzt eine Routing-Frage ist und kein Standard

Die meisten AWS-nativen Teams zwischen 50 und 500 FTE haben Bedrocks Claude-, Titan- oder Llama-Endpoints nicht aktiv gewählt. Sie haben sie als Standard genutzt, weil sie bereits in AWS waren und OpenAI es nicht war. Diese passive Wahl ist jetzt eine Entscheidung, die du bewusst verantworten musst — denn die Einschränkung, die sie passiv gemacht hat, existiert nicht mehr.

Das hat drei konkrete architektonische Konsequenzen. Erstens: Wenn du committed Spend auf Bedrock hast — Reserved Capacity, Enterprise Agreements oder Throughput-Tiers — musst du jetzt quantifizieren, ob das Hinzufügen von OpenAI-Endpoints über AWS redundanten Spend erzeugt oder komplementäre Abdeckung schafft. Zweitens: Wenn du Agent-Workflows auf Bedrocks nativem Agent-Framework aufgebaut hast, ist Managed Agents von OpenAI eine konkurrierende Orchestrierungs-Runtime innerhalb derselben Cloud. Zwei Orchestrierungsschichten zu betreiben ist nicht grundsätzlich falsch — aber es muss bewusst geschehen. Drittens: Codex verändert die Kalkulation speziell für Teams, die Software-Development-Automatisierung betreiben. Bedrock hat kein erstklassiges Code-Agent-Äquivalent auf demselben Capability-Tier — was bedeutet, dass Teams, die KI-gestützte Entwicklungs-Pipelines aus Datenschutzgründen aufgeschoben haben, diese Woche ein konkretes Unblocking-Event haben.

Das subtilere Risiko ist Multi-Cloud-Posture-Drift. Teams, die AWS-nativ sind, aber Azure OpenAI Service-Endpoints für bestimmte Use Cases betreiben — oft von einzelnen Teams ohne zentrale Architektur-Review hinzugefügt — haben jetzt eine Konsolidierungsmöglichkeit, die es vorher nicht gab. Wer jetzt kein Inventar erstellt, hat bald drei OpenAI-Zugangspfade (direkte API, Azure OpenAI Service, OpenAI auf AWS) parallel am Laufen — mit unterschiedlichen Auth-Modellen, unterschiedlichen Logging-Konfigurationen und unterschiedlichen Cost-Centern. Audit-Schulden wachsen schnell.

Der Schritt für den Montagmorgen

Die Aktion dieser Woche ist ein Inventar und eine Routing-Entscheidung — keine Migration. Fang nicht an, Workloads zu verschieben, bevor du weißt, wovon du weg willst und warum.

• Auditiere deine aktuelle OpenAI-Oberfläche. Liste jede Applikation, Pipeline und jeden Prototypen auf, der OpenAIs API berührt. Notiere, ob der Zugriff direkt, über Azure oder gar nicht über OpenAI läuft. Diese Liste sollte einen Engineer einen halben Tag kosten.
• Mappe deine Bedrock-Commitments. Ziehe deine aktive Bedrock-Modellnutzung und alle Enterprise Agreements. Identifiziere, welche Modellfamilien tragende Funktion haben und welche explorativ sind.
• Markiere Codex-relevante Workloads. Wenn du Software-Development-Automatisierungs-Use-Cases hast — PR-Review, Test-Generierung, Refactoring-Pipelines — die aus Datenschutzgründen blockiert waren, sind das sofortige Kandidaten für eine Evaluierung unter der neuen Verfügbarkeit.
• Lege eine Routing-Policy fest, bevor Teams selbst routen. Der schnellste Weg, Governance-Schulden aufzubauen, ist es, einzelnen Teams zu erlauben, OpenAI auf AWS eigenständig zu entdecken und ad hoc zu verkabeln. Eine einseitige interne Routing-Policy — welche Modellfamilie wohin geht, unter welchen Bedingungen — verhindert drei Monate Aufräumarbeit.
• Entscheide bewusst über Managed Agents. Wenn du bereits eine Orchestrierungsschicht betreibst — LangGraph, Bedrock Agents, ein eigenes Framework — ist das Hinzufügen von Managed Agents eine zweite Runtime. Bewerte, ob die Capability-Lücke die operative Komplexität rechtfertigt, bevor ein Team dagegen shipped.

Das Ziel bis Ende der Woche ist eine schriftliche Routing-Strategie — auch wenn es nur eine Seite ist. Kein Migrationsplan. Ein Decision Record.

Was es kostet und was es spart

Die Kostenseite ist real. OpenAI-Modelle über AWS zu betreiben kostet AWS's Infrastruktur-Margin on top von OpenAIs Modellpreisen — dasselbe Muster wie bei Azure OpenAI Service. Wer hochvolumiges Inference betreibt und rein auf Token-Kosten optimiert, fährt mit der direkten API günstiger. Der Kompromiss: Direkter API-Zugriff erbt nicht dein AWS IAM, dein CloudTrail-Logging, deine bestehenden Datenverarbeitungsvereinbarungen oder deine Bedrock-Throughput-Controls. Für Teams, bei denen die Compliance-Posture — nicht die Unit Economics — der Adoptionsblocker war, löst der AWS-Kanal das richtige Problem, auch bei einem moderaten Preisaufschlag.

Der Savings-Case liegt in architektonischer Einfachheit. OpenAI-Zugriff auf einen einzigen cloud-nativen Kanal zu konsolidieren reduziert die Anzahl der Credential-Stores, Logging-Sinks und Network-Egress-Pfade, die du für KI-Workloads betreibst. Für ein Engineering-Team zwischen 50 und 200 FTE ist diese operative Vereinfachung mehr wert als der Per-Token-Spread. Für Teams über 300 FTE mit etablierten FinOps-Praktiken lohnt das Unit-Economics-Gespräch, bevor man Volumen committet — aber das ist eine 30-Tage-Analyse, kein Grund, die Routing-Strategie-Entscheidung diese Woche aufzuschieben.