AWS Identity Center: Multi-Region sitzt jetzt im Setup
Neue Organisations-Instanzen können Multi-Region direkt im Setup setzen. AWS legt den Schlüssel an und kopiert die Instanz.
Seit dem 7. August 2026 fragt AWS beim Anlegen einer neuen Organisations-Instanz von IAM Identity Center nach der Regionslage: eine Region, mehrere Regionen oder eine eigene Konfiguration. Der Multi-Region-Weg legt den nötigen KMS-Schlüssel selbst an und kopiert die Instanz in eine zweite Region.
Das Wichtigste in Kürze
- Der Klick sitzt im Setup. Neue Organisations-Instanzen können Multi-Region direkt wählen. Früher waren Schlüssel, Richtlinien und Regionen getrennte Schritte.
- Die zweite Region trägt den Zugang. Fällt IAM Identity Center in der Hauptregion aus, sollen Mitarbeiter weiter in ihre AWS-Konten kommen – mit Rechten, die schon vorher lagen.
- Der Klick hat Voraussetzungen. Er gilt für Organisations-Instanzen. Active Directory als Quelle und Account-Instanzen bleiben außen vor. Für den automatisch angelegten KMS-Schlüssel fallen die üblichen Gebühren an.
Verwandt:AWS Cognito: Skill setzt den Client zurück / NHI-Sprawl: Lifecycle schlägt Login-MFA
Was sich am 7. August ändert
Was ist IAM Identity Center? IAM Identity Center ist der AWS-Dienst für die zentrale Anmeldung der Belegschaft in AWS-Konten und in verwaltete Anwendungen. Die Instanz liegt in einer gewählten Hauptregion und steuert Identitäten, Berechtigungssätze und das Mitarbeiterportal. Fällt genau diese Steuerungsebene aus, öffnet sich das Portal nicht.
AWS hat Multi-Region für Organisations-Instanzen schon länger dokumentiert. Neu ist der Weg dorthin. Am 7. August 2026 hat AWS den Schritt in die Instanz-Erstellung gezogen. Wer eine neue Organisations-Instanz anlegt, sieht drei Konfigurationen und kann Multi-Region mit einem Klick setzen.
Bisher lagen dazwischen mehrere Handgriffe. Teams mussten einen kundenverwalteten KMS-Schlüssel anlegen, die Schlüsselrichtlinien setzen und Regionen manuell ergänzen. Genau diese Kette ist der Grund, warum viele Instanzen in einer Region stehen geblieben sind.
Drei Optionen im Setup
Die Single-Region-Option bleibt der schmale Weg. Die Instanz liegt in einer Region. Das ist schnell und billig. Es lässt die Steuerungsebene aber an einem Ort.
Die Multi-Region-Option legt automatisch einen kundenverwalteten Multi-Region-KMS-Schlüssel im selben Konto an. Gleichzeitig repliziert AWS die Instanz in eine weitere Region. Identitäten, Gruppen, Berechtigungssätze, Zuweisungen und weitere Metadaten wandern mit. IAM Identity Center selbst bleibt ohne Aufpreis. Für den Schlüssel gelten die normalen KMS-Gebühren.
Die Custom-Option lässt Regionen einzeln setzen. Hier lässt sich ein vorhandener kundenverwalteter Schlüssel weiterverwenden. Wer Schlüsselrichtlinien, Replica-Lage oder bestehende KMS-Landschaft selbst führen will, nimmt diesen Weg.
| Option im Setup | Was AWS anlegt | Wofür der Weg taugt |
|---|---|---|
| Eine Region | Instanz nur in der gewählten Hauptregion | Schlanker Start, eine Steuerungsebene |
| Mehrere Regionen | Kundenverwalteter Multi-Region-KMS-Schlüssel plus Kopie der Instanz in eine weitere Region | Zugang zu Konten, wenn die Hauptregion der Identity-Ebene ausfällt |
| Eigene Konfiguration | Regionen einzeln, vorhandener kundenverwalteter KMS-Schlüssel möglich | Wenn Schlüssel und Regionen schon festliegen |
AWS nennt die Optionen für Organisations-Instanzen in 17 standardmäßig aktivierten kommerziellen Regionen. Die Ankündigung listet diese 17 nicht auf. Vor dem Klick gehört die Konsole geprüft. Eine erhoffte Region reicht als Beleg nicht.
Was die zweite Region wirklich trägt
AWS beschreibt zwei Gewinne. Erstens: Mitarbeiter sollen ihre AWS-Konten weiter erreichen, wenn IAM Identity Center in der Hauptregion gestört ist. Zweitens: Verwaltete AWS-Anwendungen lassen sich in der bevorzugten Region betreiben. Die Anwendung liest die replizierten Identitäten lokal.
Der erste Gewinn hat eine harte Kante. Die Dokumentation begrenzt den Kontenzugang auf Berechtigungen, die vor der Störung schon provisioniert waren. Neue Zuweisungen in der ausgefallenen Hauptregion entstehen in diesem Moment nicht. Multi-Region hält den vorhandenen Stand erreichbar. Ein frisches Provisioning über die gestörte Hauptregion bleibt aus.
Für die Replica-Region nennt AWS klare Kriterien. Liegt ein Datensatz aus Compliance-Gründen in einer Region, folgt die Anwendung dorthin. Zählt die Nähe zu den Nutzern, rückt die Replica näher. Soll der Kontenzugang eine regionale Störung überstehen, liegt die zweite Region geografisch weiter weg. Das sind Zielkonflikte. Eine Checkliste mit einem richtigen Kreuz gibt es dafür nicht.
Voraussetzungen, die den Klick teuer machen
Multi-Region läuft nur auf einer Organisations-Instanz. Account-Instanzen, die an ein einzelnes Konto gebunden sind, fallen raus. Für den produktiven Zugang zu AWS-Konten ist die Organisations-Instanz ohnehin der vorgesehene Weg.
Die Identitätsquelle muss ein externer Anbieter sein oder das Verzeichnis von IAM Identity Center. Active Directory als Quelle sperrt Multi-Region. Wer noch über AD anbindet, kauft sich mit dem neuen Klick nichts.
Der Schlüssel muss ein kundenverwalteter Multi-Region-KMS-Schlüssel im selben Konto sein. Die One-Click-Option erzeugt ihn. Custom kann einen vorhandenen nutzen. Opt-in-Regionen unterstützt AWS dafür derzeit nicht.
Externe Identitätsanbieter brauchen mehrere ACS-Adressen, also mehrere Ziele für die SAML-Antwort, wenn der volle Nutzen gelten soll. AWS nennt Okta, Microsoft Entra ID, PingFederate, PingOne und JumpCloud als Beispiele. Google Workspace gehört in der Dokumentation zu den Anbietern ohne diese Fähigkeit. Dann bleibt ein Teil der regionalen Anmeldung auf der Strecke.
Dazu kommt die Anwendungslandschaft. Jede genutzte AWS-Managed-Anwendung muss einen kundenverwalteten Schlüssel vertragen. Anwendungen, die in der zweiten Region laufen sollen, müssen diese Lage unterstützen. Der Klick im Setup prüft das nicht stellvertretend für das Team.
Was bestehende Instanzen tun
Der One-Click sitzt in der Erstellung. Bestehende Organisations-Instanzen bekommen ihn nicht nachträglich als magischen Schalter. Die Dokumentation erlaubt weiter, eine Instanz später in eine zusätzliche Region zu replizieren, wenn die Voraussetzungen erfüllt sind. Dann bleibt der alte Weg: Schlüssel, Richtlinien, Region ergänzen.
Für laufende Landschaften lohnt die Inventur vor dem Umbau. Identitätsquelle, Schlüsseltyp, unterstützte Anwendungen und ACS-Fähigkeit des IdP entscheiden, ob eine Replica überhaupt trägt. Wer Active Directory nutzt oder nur eine Account-Instanz hat, plant zuerst den Instanztyp. Die zweite Region kommt danach.
Neue Organisationen und frische Management-Konten haben den einfacheren Fall. Dort gehört Multi-Region in die erste Entscheidung, solange Quelle und Anwendungen mitspielen. Nachträglich ist derselbe Endzustand erreichbar, nur mit mehr Handarbeit und mehr Raum für eine vergessene Richtlinie.
Für DACH-Teams zählt die Replica-Wahl
Viele DACH-Landschaften legen IAM Identity Center in Frankfurt oder Irland an. Die Ankündigung listet die 17 Regionen nicht. Die IAM-Identity-Center-Dokumentation führt Frankfurt und Irland unter den standardmäßig aktivierten Regionen, in denen sich der Dienst einschalten lässt. Ob der neue One-Click in genau dieser Region angeboten wird, zeigt die Konsole beim Anlegen.
Die Replica kopiert Identitäten und Zuweisungen. Der automatisch erzeugte Schlüssel ist ein Multi-Region-KMS-Schlüssel. Damit wandert auch Schlüsselmaterial in die zweite Region. Wer Datenresidenz eng führt, muss diese Kopie bewusst wählen. Custom gibt mehr Kontrolle über Lage und vorhandenen Schlüssel. One-Click gibt Tempo.
Für den Kontenzugang bei einer Störung zählt Distanz. Für Anwendungen mit Residenzpflicht zählt Nähe zum Datensatz. Beides gleichzeitig zu wollen, zwingt zu einer Priorität. Diese Priorität gehört ins Setup. Im Incident kommt sie zu spät.
Quelle: AWS-Ankündigung vom 7. August 2026 und das Benutzerhandbuch zu IAM Identity Center über mehrere Regionen.
Häufige Fragen
Für wen gilt der One-Click?
Für neue Organisations-Instanzen von IAM Identity Center in unterstützten kommerziellen Regionen. Account-Instanzen und Instanzen mit Active Directory als Quelle sind draußen.
Was legt AWS bei Multi-Region automatisch an?
Einen kundenverwalteten Multi-Region-KMS-Schlüssel im selben Konto und eine Replikation der Instanz in eine weitere Region. Identitäten, Berechtigungssätze und Zuweisungen laufen mit.
Bleibt der Zugang bei einem Regionsausfall vollständig?
Nein. AWS begrenzt den Kontenzugang auf Rechte, die vor der Störung schon provisioniert waren. Neue Zuweisungen über die ausgefallene Hauptregion entstehen in diesem Moment nicht.
Was kostet Multi-Region?
IAM Identity Center selbst bleibt ohne Aufpreis. Für den automatisch angelegten kundenverwalteten KMS-Schlüssel gelten die Standardgebühren von AWS KMS. Einen Euro-Betrag nennt AWS in der Ankündigung nicht.
Können bestehende Instanzen nachrüsten?
Ja, über den dokumentierten Replikationsweg, wenn Schlüssel, Instanztyp und Identitätsquelle passen. Der neue One-Click sitzt in der Erstellung. Auf einer laufenden Instanz erscheint er nicht als Nachzügler.
Lesetipps der Redaktion
cloudmagazinAWS Sovereign Cloud: was wirklich getrennt istcloudmagazinResilienz jenseits der Security-ToolchaincloudmagazinCloud-Knappheit: Was Q2 für Einkäufer bedeutetMehr aus dem MBF Media Netzwerk
MyBusinessFutureIhre Cyberversicherung zahlt nicht – warum das kein Einzelfall istDigital ChiefsVerwaiste Zugänge: die stille Cyber-LückeSecurityTodayPhishing-resistente MFA: CISA, FIDO und USDABildquelle: KI-generiert (August 2026)
