Entra ID (Azure AD) <-> Amazon Cognito

Editierbares mxGraph-XML mit echten AWS/Azure-diagrams.net-Icons. Beste Kontrolle ueber Karten, Labels und Kanten.

Staerkster Kandidat fuer deine Workbench, weil Quelle und Ziel dasselbe Format sind.

Sehr angenehmes Textformat, gute Container und Kanten, aber ohne lokale AWS-Icon-Paritaet zu draw.io.

Gut fuer schnelle Systemskizzen und klare Struktur, weniger fuer exakte AWS-Icon-Diagramme.

Sehr leichtgewichtig und markdown-freundlich. Layout ist bequem, aber bei komplexen Kanten weniger kontrollierbar.

Ideal fuer Docs und Grimoire, aber kein Ersatz fuer saubere draw.io-Architekturtafeln.

Stabiles Textformat mit brauchbarer Semantik. Optisch eher technisch/klassisch als polished.

Gut, wenn Diagrammquelle im Repo wichtiger ist als pixelgenauer Look.

Sehr robust fuer Graphen. Container und Labels gehen, Architektur-Optik wirkt aber schnell generisch.

Stark fuer Abhaengigkeiten und automatische Layouts; weniger fuer Cloud-Referenzbilder.

Kann echte AWS/Azure-Icons nutzen und ist als Code reproduzierbar. Layout-Kontrolle bleibt Graphviz-limitiert.

Spannend fuer Infrastruktur-aus-Code-Visualisierungen, aber nicht so editierbar wie draw.io.

Zweiter Versuch mit kuerzeren Labels und einer klaren horizontalen Hauptachse.

Besser lesbar als die erste Variante, weil die Labels radikal gekuerzt sind.

Cognito als zentrales Broker-Element, Apps, Azure und Gruppenpruefung darum herum gruppiert.

Inhaltlich stark fuer Identity-Flows, optisch haengt viel am automatischen Graphviz-Routing.

Trust-Zones mit AWS- und Azure-Cluster, kuerzeren Kantenlabels und offiziellen Cloud-Icons.

Das ist der fairste Python-diagrams-Versuch fuer den draw.io-Vergleich.

Trust-Zones plus draw.io-Hausregeln: kompakte Spine, farbige AWS/Azure-Zonen, kurze Labels und gewichtete Hauptkante.

Bestmoegliche Uebersetzung der draw.io-Regeln in die Grenzen von Python diagrams.

Professionelles Azure-Architekturdiagramm fuer InvenTree auf Linux VM mit Docker Compose, PostgreSQL, Redis und persistentem Volume.

Test fuer einen neuen Use Case: Enterprise-Architektur mit Azure Trust Boundaries statt SAML-Federation.

Sehr stark fuer C4-Modellierung. Hier liegt die DSL bereit, aber ohne lokalen Structurizr-Renderer.

workspace "Entra ID (Azure AD) <-> Amazon Cognito" "SAML-Federation fuer die Capita Web-Tools · Shared Cognito Pool" {
  model {
    user = person "Mitarbeiter" "User / Browser"

    aws = softwareSystem "AWS Cloud · eu-central-1" {
      web = container "Web-Tools" "Apps Portal / CloudFront+S3" "CloudFront + S3"
      cognito = container "Amazon Cognito" "User Pool · Broker/SP" "SAML Service Provider / Identity Broker"
      lambda = container "Pre-Token Lambda" "App-Zugriff+Gruppen" "AWS Lambda"
      dynamodb = container "DynamoDB" "app-access · Gruppen" "Amazon DynamoDB"
    }

    azure = softwareSystem "Microsoft Azure · Entra ID Tenant" {
      entra = container "Microsoft Entra ID" "IdP · MFA · Cond. Access" "SAML Identity Provider"
    }

    user -> web "1 Aufruf (HTTPS)"
    web -> cognito "2 Login-Redirect · PKCE"
    cognito -> entra "3 SAML AuthnRequest"
    entra -> cognito "5 SAML-Assertion, emailaddress = UPN"
    cognito -> lambda "6 Pre-Token-Trigger"
    lambda -> dynamodb "7 prueft Gruppen"
    cognito -> web "8 Token (JWT) -> eingeloggt"
  }

  views {
    container aws "saml-federation" {
      include *
      autoLayout lr
      title "Entra ID (Azure AD) <-> Amazon Cognito"
      description "4 Anmeldung + MFA / Conditional Access findet am Entra-Knoten statt."
    }

    styles {
      element "Person" {
        background "#F5F5F5"
        color "#24292F"
        stroke "#666666"
      }
      element "Container" {
        shape RoundedBox
      }
      element "Software System" {
        background "#FFF6EE"
        color "#232F3E"
      }
      relationship "Relationship" {
        color "#4A5568"
        thickness 2
      }
    }
  }
}

Gut als Architekturmodell, weniger als schneller Diagramm-Export ohne extra Renderer.

SaaS-/Account-orientiert. Ohne API-/Kosten-/Credential-Freigabe hier bewusst nicht live generiert.

# Cloudcraft

Hier wurde absichtlich kein Cloudcraft-Diagramm automatisch erzeugt.

Grund: Cloudcraft ist ein SaaS-/Account-Workflow fuer echte Cloud-Layouts und Inventar-Importe.
Ohne API-Zugang, Workspace-Kontext und Kosten-/Credential-Freigabe waere ein automatisch
erzeugtes Ergebnis hier entweder nur ein unechter Screenshot oder wuerde echte externe
Ressourcen beruehren.

Fuer diesen Use Case waere Cloudcraft spannend, wenn das Ziel eher Inventar-nahe AWS-Ansichten
mit offiziellen Icons und Account-Kontext ist. Fuer editierbare Architektur-/Ablaufdiagramme
bleibt diagrams.net hier der bessere direkte Workflow.

Interessant fuer AWS-Inventar und offizielle Visuals, aber nicht fuer diesen lokalen Testlauf.