Eine Legacy-Anwendung verwendet mehrere .NET Framework-Komponenten, die sich eine Microsoft SQL Server-Datenbank teilen und asynchron über Microsoft Message Queueing (MSMQ) kommunizieren. Das Unternehmen migriert zu containerisierten .NET Core-Komponenten und möchte die Anwendung für den Betrieb auf AWS refaktorieren. Die .NET Core-Container benötigen eine komplexe Orchestrierung, volle Kontrolle über die Netzwerk- und Hostkonfiguration, und das Datenbankmodell ist stark relational. Welche Architektur erfüllt diese Anforderungen?

Die korrekte Option erfüllt alle Anforderungen. Amazon ECS mit dem EC2 Launch Type bietet die notwendige Kontrolle über Netzwerk- und Hostkonfigurationen für komplexe Container-Orchestrierung. Amazon Aurora MySQL Serverless v2 ist eine hochverfügbare, skalierbare relationale Datenbanklösung, die mit dem bestehenden relationalen Datenbankmodell kompatibel ist. Amazon SQS ist ein vollständig verwalteter Warteschlangendienst, der sich ideal für die asynchrone Nachrichtenübermittlung eignet und MSMQ ersetzt. Die anderen Optionen sind ungeeignet, da: AWS App Runner bietet nicht die erforderliche Kontrolle auf Host-Ebene. EventBridge ist für ereignisgesteuerte Architekturen, nicht primär für Warteschlangen. DynamoDB ist eine NoSQL-Datenbank und nicht für stark relationale Modelle geeignet. SNS ist ein Publish/Subscribe-Dienst, kein Warteschlangendienst für asynchrone Nachrichten wie MSMQ. Elastic Beanstalk bietet weniger Kontrolle als ECS EC2. Aurora PostgreSQL Serverless v2 ist zwar relational, aber die Migration von SQL Server zu PostgreSQL kann komplex sein. MSK ist ein Streaming-Dienst, kein einfacher Warteschlangendienst.