Freigeben über


Grundlegendes zu Plattformunterschieden bei einer Workload eines ereignisgesteuerten Workflows (EDW)

Bevor Sie die EDW-Workload (Event-Driven Workflow) in Azure replizieren, sollten Sie die funktionalen Unterschiede zwischen den AWS- und Azure-Plattformen genau kennen.

In diesem Artikel werden einige der wichtigsten Konzepte für diese Workload erläutert und Links zu Ressourcen mit weiteren Informationen bereitgestellt.

Identitäts- und Zugriffsverwaltung

Die AWS EDW-Workload verwendet eine AWS Identity and Access Management (IAM)-Rolle, die vom EKS-Dienst übernommen wird. Diese Rolle wird EKS-Pods zugewiesen, um den Zugriff auf AWS-Ressourcen wie Warteschlangen oder Datenbanken zu ermöglichen, ohne dass Anmeldeinformationen gespeichert werden müssen.

Azure implementiert die rollenbasierte Zugriffssteuerung (RBAC) anders als AWS. In Azure sind Rollenzuweisungen einem Sicherheitsprinzipal (Benutzer:in, Gruppe, verwaltete Identität oder Dienstprinzipal) zugeordnet, und dieser Sicherheitsprinzipal ist einer Ressource zugeordnet.

Authentifizierung zwischen Diensten

Die AWS EDW-Workload verwendet die Dienstkommunikation, um eine Verbindung mit einer Warteschlange und einer Datenbank herzustellen. AWS EKS verwendet AssumeRole, ein Feature von IAM, um temporäre Sicherheitsanmeldeinformationen für den Zugriff auf AWS-Benutzer, -Anwendungen oder -Dienste zu erwerben. Diese Implementierung ermöglicht Diensten, eine IAM-Rolle zu übernehmen, die bestimmte Zugriffsrechte gewährt, um sichere und eingeschränkte Berechtigungen zwischen Diensten bereitzustellen.

Für Amazon SQS- (Simple Queue Service) und Amazon DynamoDB-Datenbankzugriff mithilfe der Dienstkommunikation verwendet der AWS-Workflow AssumeRole mit EKS. Dabei handelt es sich um eine Implementierung der Volumenprojektion von Kubernetes-Dienstkontotoken. In der EKS EDW-Workload ermöglicht eine Konfiguration einem Kubernetes-Dienstkonto die Übernahme einer AWS Identity and Access Management (IAM)-Rolle. Pods, die für die Verwendung des Dienstkontos konfiguriert sind, können dann auf jeden AWS-Dienst zugreifen, für den die Rolle über Zugriffsberechtigungen verfügt. In der EDW-Workload werden zwei IAM-Richtlinien definiert, um Berechtigungen für den Zugriff auf Amazon IdentityDB und Amazon SQS zu gewähren.

Mit AKS können Sie verwaltete Microsoft Entra-Identitäten mit Microsoft Entra Workload ID verwenden.

Es wird eine benutzerseitig zugewiesene verwaltete Identität erstellt, die Zugriff auf eine Azure Storage-Tabelle gewährt, indem ihr die Rolle Mitwirkender an Speichertabellendaten zugewiesen wird. Der verwalteten Identität wird auch Zugriff auf eine Azure Storage-Warteschlange gewährt, indem ihr die Rolle Mitwirkender an Storage-Warteschlangendaten zugewiesen wird. Diese Rollenzuweisungen sind auf bestimmte Ressourcen beschränkt, sodass die verwaltete Identität Nachrichten in einer bestimmten Azure Storage-Warteschlange lesen und in eine bestimmte Azure Storage-Tabelle schreiben kann. Die verwaltete Identität wird dann einer Kubernetes-Workloadidentität zugeordnet, die der Identität der Pods zugeordnet wird, in denen die App-Container bereitgestellt werden. Weitere Informationen finden Sie unter Verwenden von Microsoft Entra Workload ID mit AKS.

Auf Clientseite unterstützen die Python-SDKs von Azure die transparente Nutzung des Kontexts einer Workloadidentität, sodass Entwickler:innen keine explizite Authentifizierung durchführen müssen. Code, der in einem Namespace/Pod in AKS mit einer bekannten Workloadidentität ausgeführt wird, kann sich mithilfe der zugeordneten verwalteten Identität bei externen Diensten authentifizieren.

Ressourcen

Die folgenden Ressourcen können Ihnen helfen, mehr über die Unterschiede zwischen AWS und Azure in Bezug auf die bei der EDW-Workload verwendeten Technologien zu erfahren:

Thema AWS zu Azure-Ressource
Dienste Vergleich von AWS mit Azure -Diensten
Identität Zuordnen von AWS IAM-Konzepten zu ähnlichen Konzepten in Azure
Konten Konten und Abonnements von Azure und AWS
Ressourcenverwaltung Ressourcencontainer
Messaging Amazon SQS zu Azure Queue Storage
Kubernetes AKS für Amazon EKS-Experten

Nächste Schritte

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Ken Kilty | Principal TPM
  • Russell de Pina | Principal TPM
  • Jenny Hayes | Senior Content Developer
  • Carol Smith | Senior Content Developer
  • Erin Schaffer | Content Developer 2