AWS oder Azure für Schweizer IT-Teams: Entscheiden Sie mit einem Pilot von 2 bis 4 Wochen

Azure gewinnt meistens dann, wenn Ihre Organisation auf Microsoft-Lizenzen, Active Directory sowie Workloads mit .NET oder SQL Server läuft. AWS gewinnt meistens bei Linux-nativen, cloud-nativen Teams, die den breitesten Servicekatalog und das reifste Ökosystem brauchen. Bei der KI-Strategie verläuft die Trennlinie gleich: Azure OpenAI für die Integration mit Microsoft 365, AWS Bedrock für Flexibilität über mehrere Modelle hinweg. Keine dieser Regeln hält stand, solange Sie Ihren tatsächlichen Workload nicht in den Kalkulatoren beider Anbieter durchgerechnet haben.

---

Kurz gefasst:

• Azure spielt seine Stärken bei Organisationen mit bestehenden Microsoft-Lizenzen, Active Directory und Windows-basierten Workloads aus, besonders wenn eine Integration mit Microsoft 365 gefragt ist.

• AWS bietet mehr Dienste, mehr Verfügbarkeitszonen und die besseren Möglichkeiten für Linux-native, technisch geprägte und cloud-native Teams, die feine Kontrolle wollen.

• Preisunterschiede bei Containern und Speicher, etwa Gebühren für die EKS-Steuerungsebene oder Kosten für Speicherklassen, können die Gesamtkosten deutlich verändern. Vor einem Migrationsentscheid braucht es deshalb eine detaillierte Rechnung.

• Der Entscheid für eine Hybrid-Cloud hängt von Latenz, Datenstandort und der Vielfalt der bestehenden Infrastruktur ab: Azure Arc verwaltet bestehende Rechenzentren, AWS Outposts liefert AWS-Hardware ins eigene Haus.

• Die Wahl der KI-Plattform richtet sich nach dem bestehenden Ökosystem: Bedrock bietet herstellerneutrale Modellvielfalt, Azure OpenAI eine tiefe Verzahnung mit den Produktivitätswerkzeugen von Microsoft.

---

AWS und Azure: Die Grundlagen, auf die es wirklich ankommt

AWS startete 2006 als Erster und hält bis heute den grösseren Marktanteil. Azure hat sich seinen Vorsprung anders erarbeitet, nämlich durch die direkte Verzahnung mit jener Software, die in den meisten Unternehmen ohnehin läuft. Die Schätzungen der Synergy Research Group sehen AWS anfangs 2026 bei rund 28 % des weltweiten Marktes für Cloud-Infrastruktur, Azure bei etwa 21 %. Zusammen mit Google Cloud kontrollieren die drei grössten Anbieter inzwischen mehr als 60% des Marktes. Das sagt etwas Wichtiges aus: Dies ist kein zersplittertes Feld, in dem still und leise eine vierte oder fünfte Option aufholt. Es ist ein Rennen zwischen zweieinhalb Anbietern, und Ihr Entscheid läuft realistisch auf AWS oder Azure hinaus, sofern Sie keinen besonderen Grund haben, anderswo zu suchen.

Der Unterschied in der Grundhaltung zeigt sich, bevor Sie die erste Zeile Code schreiben. AWS hat ein weit verzweigtes, modulares Ökosystem aufgebaut: über 200 Dienste, von denen jeder ein eng umrissenes Problem löst, gedacht für Entwickler:innen, die ihren Technologie-Stack selbst zusammenstellen wollen. Azure ging den umgekehrten Weg: weniger Überraschungen, engere Integration mit Windows Server, Active Directory, Office 365 und Dynamics sowie ein klarer vorgegebener Pfad für Unternehmen, die ohnehin in der Microsoft-Welt leben.

Einige Fakten bilden das Fundament für den Rest dieses Vergleichs:

• AWS betreibt weltweit mehr Verfügbarkeitszonen und führt in der Regel bei der Breite des Serviceangebots und der Tiefe des Marktplatzes für Drittanbieter.

• Azure hat bei hybriden Umgebungen viel Schwung, weil Arc und Windows Server so tief mit bestehenden Rechenzentren verzahnt sind.

• Die Kundschaft von AWS besteht überdurchschnittlich oft aus Start-ups, digital geborenen Firmen und technisch geprägten Organisationen, die feine Kontrolle schätzen.

• Die Kundschaft von Azure besteht überdurchschnittlich oft aus Grossunternehmen, Behörden und regulierten Branchen, die bereits unter einem Microsoft-Unternehmensvertrag stehen.

Keine der beiden Plattformen ist auf eine Weise «voraus», die einem konkreten Workload standhält. Der Vergleich von AWS und Azure bei DataCamp kommt zum selben Schluss: Die relevanten Unterschiede stecken in den Details von Rechenleistung, Preismodell und hybrider Architektur, nicht in Werbeaussagen darüber, wer mehr Dienste anbietet.

Rechenleistung, Container und Speicher: Hier liegen die echten Unterschiede

Hier hört der Vergleich zwischen AWS und Azure auf, eine abstrakte Debatte zu sein, und wird zu einem technischen Entscheid. Rechenleistung, Container und Speicher sind die drei Schichten, die jeder Workload berührt, und die Plattformen behandeln jede davon unterschiedlich genug, um Ihre Gesamtbetriebskosten zu verändern.

Virtuelle Maschinen und Instanzfamilien. EC2 und Azure Virtual Machines bieten beide Familien für allgemeine Zwecke, für rechenintensive und für speicherintensive Aufgaben, und auf dem Papier wirken sie austauschbar. Der Unterschied, der zählt, sind die Chips. AWS hat stark auf eigene Graviton-Prozessoren gesetzt, die auf ARM basieren und bei Workloads ohne x86-Anforderung oft ein besseres Preis-Leistungs-Verhältnis liefern. Azure hält mit eigenen Chip-Initiativen dagegen sowie mit der engen Verzahnung von Windows-lizenzierten VMs, wo der Azure Hybrid Benefit die Rechnung komplett verändert, falls Sie bereits Lizenzen für Windows Server oder SQL Server besitzen.

Kubernetes und verwaltete Container. Ein Detail, das die meisten Vergleiche unter den Tisch fallen lassen: Azure Kubernetes Service verrechnet nichts für die Steuerungsebene, während Amazon EKS pro Cluster rund 0.10 US-Dollar pro Stunde dafür verlangt. Das sind etwa 876 US-Dollar pro Jahr und Cluster im Standardbetrieb von EKS. Wer ein Dutzend Cluster über mehrere Umgebungen betreibt, zahlt also bereits, bevor ein einziger Worker Node bereitsteht. Für die meisten Unternehmen ist das kein Ausschlusskriterium, aber es ist ein realer, wiederkehrender Posten, den AWS-orientierte Teams gerne vergessen.

Über den Preis hinaus bieten beide Plattformen serverlose Container-Optionen, AWS Fargate und Azure Container Instances, sowie eigene verwaltete Registries. AKS wirkt tendenziell etwas zugänglicher für Teams, die mit dem Portal und den Kommandozeilen-Konventionen von Azure vertraut sind. EKS gibt Ihnen feinere Kontrolle, wenn Sie eine komplexe, mandantenfähige Kubernetes-Umgebung betreiben.

Serverloses Rechnen. AWS Lambda hat einen Vorsprung von mehreren Jahren, und das merkt man. Das Integrationsökosystem, die Zahl der unterstützten Laufzeitumgebungen, die Tiefe der Werkzeuge von Drittanbietern und die schiere Menge an Dokumentation aus der Community sprechen für Lambda, wenn Sie ereignisgesteuerte Architekturen von Grund auf bauen. Azure Functions hat funktional viel aufgeholt und bietet engere native Verbindungen zu Logic Apps und Event Grid, was zählt, wenn Ihre Abläufe ohnehin im Microsoft-Stack leben.

Objekt- und Archivspeicher. S3 und Azure Blob Storage konkurrieren mit nahezu identischer Logik für Speicherklassen: heiss, kühl beziehungsweise selten genutzt, und Archiv. Multiple pricing comparisons show Azure Blob’s hot tier coming in slightly cheaper than S3 Standard for basic storage volumes, wobei sich der Abstand je nach Region, Redundanzeinstellungen und Zugriffshäufigkeit verkleinert oder umkehrt. Nehmen Sie hier nie eine Schlagzeilenzahl für bare Münze. Abrufkosten und Mindestspeicherdauern der Archivklasse unterscheiden sich so stark, dass ein für S3 Glacier optimierter Workload teurer werden kann, wenn Sie ihn ohne erneute Prüfung der Abruf-SLAs nach Azure Archive Storage verschieben.

Netzwerk. Amazon VPC und Azure Virtual Network folgen demselben Grundmodell aus isolierten Netzsegmenten, Subnetzen, Routing-Tabellen und Sicherheitsgruppen, doch die Werkzeuge gehen auseinander. Die Sicherheitsgruppen und Netzwerk-ACLs von VPC geben Ihnen zwei Filterebenen, eine zustandslose und eine zustandsbehaftete. Die Network Security Groups von Azure fassen das zu einer einzigen Ebene mit leicht anderen Standardverhalten zusammen. Die Optionen für Standortverbindungen (VPN Gateway auf beiden Seiten, Direct Connect gegenüber ExpressRoute) sind funktional ähnlich, doch Preisgestaltung und Partnernetz von ExpressRoute begünstigen Organisationen, die bereits mit Microsoft-orientierten Netzbetreibern arbeiten.

Das Muster zieht sich durch alles: AWS gibt Ihnen mehr Stellschrauben und die längere Erfolgsgeschichte, Azure nimmt Ihnen Entscheidungen ab und verhält sich im Standard besser, wenn Ihre Infrastruktur ohnehin von Windows und Active Directory ausgeht.

Bedrock gegen Azure OpenAI: Wie sich die KI-Plattformen unterscheiden

Die KI-Ebene ist der Punkt, an dem AWS gegen Azure zu einem eigenen Entscheid geworden ist, fast unabhängig von der darunterliegenden Infrastruktur.

AWS Bedrock bleibt herstellerneutral. Sie erhalten über eine einheitliche Schnittstelle Zugriff auf Modelle von Anthropic, Meta, Mistral, der Titan-Familie von Amazon und weiteren Anbietern. Das zählt, wenn Ihr Team Modelle gegeneinander vergleichen, bei einem besseren Angebot wechseln oder sich nicht an den Fahrplan eines einzelnen Modellanbieters binden will. Bedrock ist die pragmatische Wahl für Teams, die das Modell selbst als austauschbaren Baustein betrachten.

Azure OpenAI, kürzlich unter der Marke Azure AI Foundry erweitert, geht die umgekehrte Wette ein: tiefe, exklusive Integration der Modelle von OpenAI, eingebettet in Unternehmenskontrollen und direkt verdrahtet mit Microsoft 365 Copilot, Power Platform und Dynamics. Wenn Ihre Organisation ohnehin auf Microsoft 365 läuft und generative KI-Funktionen ohne eigene Integrationsarbeit in Word, Teams und Outlook auftauchen sollen, ist Azure OpenAI genau dafür gebaut. Vergleiche aus der Praxis zeigen durchgehend: Teams, die herstellerunabhängig experimentieren wollen, tendieren zu Bedrock, während Teams mit Wunsch nach enger Microsoft-365-Integration standardmässig bei Azure OpenAI landen.

Einige betriebliche Faktoren entscheiden, welcher Ansatz passt:

• Governance- und Auditanforderungen. Azure AI Foundry bringt Inhaltsfilter, rollenbasierten Zugriff über Entra ID und Protokolle mit, die sich in die bestehenden Microsoft-Compliance-Werkzeuge einfügen. Bedrock bietet vergleichbare Leitplanken, verlangt für dieselbe Prüftiefe aber mehr manuelle Konfiguration.

• Datenstandort. Beide Plattformen erlauben es, die Modellausführung an bestimmte Regionen zu binden, doch die verfügbare Modellliste unterscheidet sich auf beiden Seiten je nach Region. Prüfen Sie deshalb die Modellverfügbarkeit, bevor Sie sich aus Compliance-Gründen auf eine Region festlegen.

• Flexibilität beim Einsatz. Der Zugriff auf mehrere Modelle bei Bedrock erlaubt es, verschiedene Aufgaben an verschiedene Modelle zu leiten (ein günstigeres Modell für die Klassifikation, ein stärkeres für die Generierung), ohne die Plattform zu wechseln.

• Latenz und Durchsatz. Reservierter Durchsatz ist auf beiden Plattformen verfügbar, doch die Kapazität für stark nachgefragte Modelle schwankt. Testen Sie deshalb unter Last, bevor Sie ein SLA für den Produktivbetrieb festschreiben.

Profi-Tipp: Wählen Sie die KI-Plattform nicht vor der Modellstrategie. Wenn Ihr Fahrplan darauf beruht, zwischen Modellanbietern flexibel zu bleiben, erspart Ihnen die Abstraktionsschicht von Bedrock später einen Neubau. Wenn Ihr Fahrplan darauf beruht, Copilot-artige Produktivitätsfunktionen schnell zu den Nutzenden zu bringen, sparen Ihnen die nativen Microsoft-365-Verbindungen von Azure OpenAI Monate an eigener Integrationsarbeit.

Azure Arc gegen AWS Outposts: Die richtige Hybrid-Strategie wählen

Die Hybrid-Cloud ist in der Debatte zwischen AWS und Azure längst keine Fussnote mehr. Für jede Organisation mit bestehenden Rechenzentren, regulatorischen Vorgaben zum Datenstandort oder Aussenstandorten, die nicht alles über eine öffentliche Region leiten können, ist sie oft der ausschlaggebende Faktor.

Azure Arc setzt zuerst auf Software. Es erweitert die Verwaltungsebene von Azure, also Richtliniendurchsetzung, Überwachung und Sicherheitskontrollen, auf Infrastruktur, die überall stehen kann: eigene Server, andere Clouds, sogar Infrastruktur der Konkurrenz. Sie kaufen keine Hardware von Microsoft, sondern installieren einen Agenten, mit dem Azure Ressourcen steuert, die es nicht selbst betreibt. Das macht Arc attraktiv für Organisationen mit einem unübersichtlichen, heterogenen Bestand: etwas VMware, etwas Bare Metal, ein paar alte Windows-Server-Maschinen, alles mit einer einzigen Steuerungsoberfläche und ohne Hardware-Erneuerung.

AWS Outposts geht den umgekehrten Weg. Es ist ein physisches Rack, gebaut und gewartet von AWS, geliefert in Ihr Rechenzentrum oder an Ihren Aussenstandort, mit denselben Schnittstellen und Diensten wie die öffentliche AWS-Region, an die es angebunden ist. Sie erhalten echte lokale Rechen- und Speicherleistung mit niedriger Latenz, die sich genau wie die Cloud verhält, binden sich dafür aber an Hardware von AWS und den zugehörigen Beschaffungszyklus.

Das Entscheidungssignal ist eindeutig, sobald Sie die beiden Anwendungsfälle trennen.

• Wählen Sie Azure Arc, wenn einheitliche Steuerung und Richtlinien über bereits vorhandene Infrastruktur im Vordergrund stehen, ohne neue Hardware zu kaufen.

• Wählen Sie AWS Outposts, wenn lokale Latenz im Bereich unter einer Millisekunde oder strikte lokale Datenverarbeitung zählt, was ein Software-Agent allein nicht garantieren kann.

• Wählen Sie Arc, wenn Ihr Bestand aus einem Mix von Anbietern, Betriebssystemen und Cloud-Plattformen besteht, der eine einzige Steuerungsebene braucht.

• Wählen Sie Outposts, wenn eine Produktionshalle, eine Filiale oder ein regulierter Standort echte AWS-Dienste betreiben soll, ohne den Umweg über die öffentliche Cloud.

Günstig ist keine der beiden Optionen, und beiläufig entscheidet man sie ebenfalls nicht. Outposts bringt Hardware-Verträge und Kapazitätsplanung mit sich, Arc bedeutet, jedes bestehende Objekt in eine neue Steuerungsebene aufzunehmen. Rechnen Sie beide Varianten gegen Ihre tatsächlichen Latenz- und Compliance-Anforderungen durch, nicht dagegen, welches Verkaufsteam die bessere Präsentation hielt.

Verschafft die Microsoft-Identitätsintegration Azure einen Vorteil?

Für Organisationen, die bereits Microsoft 365 oder ein lokales Active Directory betreiben, beendet oft genau dieser eine Faktor die Debatte zwischen AWS und Azure, noch bevor der Preis überhaupt zur Sprache kommt.

Entra ID (früher Azure Active Directory) ist eine native Erweiterung jenes Identitätssystems, das in den meisten Unternehmen ohnehin läuft. Wenn sich Ihre Mitarbeitenden heute gegen AD anmelden, ist die Verbindung dieses Identitätsgraphen mit Azure-Ressourcen ein nahezu nativer, reibungsarmer Weg: Bestehende Gruppen, Richtlinien für bedingten Zugriff und die Registrierung für mehrstufige Anmeldung lassen sich mit minimalem Aufwand übernehmen. AWS IAM ist für sich genommen ein leistungsfähiges, ausgereiftes Identitätssystem, wurde aber nicht als Erweiterung von Active Directory gebaut. Die Anbindung von AWS an eine bestehende AD-Umgebung verlangt AD Connector, einen Verzeichnisdienst als Brücke oder eine Föderation über SAML. Jede Variante bringt Betriebsaufwand mit sich, den Azure-Kundschaft schlicht nicht aufbauen muss.

Dieser betriebliche Unterschied verstärkt sich, sobald die Lizenzen ins Spiel kommen. Fachleute und Analyst:innen, die den Quartalsrhythmus der Cloud-Anbieter verfolgen, weisen durchgehend darauf hin, dass bestehende Microsoft-Lizenzen und Investitionen in Identitäten die Gesamtkostenrechnung bei Workloads mit Windows und SQL Server deutlich Richtung Azure kippen können, weil Sie mit dem Azure Hybrid Benefit bereits gekaufte Lizenzen auf Cloud-VMs anwenden dürfen, statt zweimal zu bezahlen.

Das Signal der Lizenzmobilität: Organisationen mit bestehenden Lizenzen für Windows Server oder SQL Server unter einem Microsoft Enterprise Agreement können dank Hybrid Benefit spürbar tiefere VM-Kosten auf Azure erzielen. Wie hoch die Ersparnis ausfällt, hängt stark davon ab, wie viele Lizenzen Sie besitzen, wie viele VMs Sie betreiben und ob Sie für Software Assurance qualifiziert sind. Rechnen Sie diesen Posten explizit durch. Er ist mit Abstand der häufigste Grund, weshalb ein auf dem Papier kostenneutraler Workload nach Einbezug der realen Lizenzen Richtung Azure kippt.

Wenn in Ihrer Organisation bereits Systemintegrationen Identitäten, Schnittstellen und interne Werkzeuge verbinden, lohnt es sich, diese Lücke vor dem Plattformentscheid zu kartieren. Eine Identitätsföderation nachträglich einzubauen, ist deutlich teurer, als sie von Anfang an einzuplanen.

Wie vergleichen Sie die Preise von AWS und Azure fair?

Die offiziellen Preisseiten sind der unzuverlässigste Teil jedes Vergleichs zwischen AWS und Azure. Wer sie für bare Münze nimmt, landet als Beschaffungsteam bei einem Kostenmodell, das schon vor der ersten Rechnung um 30 % oder mehr danebenliegt.

Drei Dinge verzerren die Listenpreise jedes Mal. Erstens unterscheiden sich die enthaltenen Leistungen: Eine «vergleichbare» VM-Stufe der einen Plattform enthält vielleicht Überwachung oder Sicherung, die die andere separat verrechnet. Zweitens variiert die Behandlung von Lizenzen enorm: Eine Windows-VM auf AWS zahlt die volle Lizenzgebühr, sofern Sie keine eigene mitbringen, während dieselbe VM auf Azure vom Hybrid Benefit profitieren kann. Drittens werden Gebühren für Datenübertragung und ausgehenden Datenverkehr so unterschiedlich berechnet, dass ein datenintensiver Workload allein durch den Abfluss von Daten aus der Cloud spürbar teurer oder günstiger wird, völlig unabhängig von den Rechenkosten.

So modellieren Sie denselben Workload wiederholbar auf beiden Plattformen:

1. Definieren Sie die exakte Spezifikation des Workloads. Legen Sie Anzahl vCPUs, Arbeitsspeicher, Speichertyp und -volumen, den erwarteten monatlichen Datenabfluss sowie sämtliche Lizenzanforderungen (Betriebssystem, Datenbank) fest, bevor Sie einen der Kalkulatoren öffnen.

2. Wählen Sie auf beiden Seiten dieselbe Region. Die Preise schwanken auf beiden Plattformen je nach Region, und der Vergleich eines AWS-Preises für US East mit einem Azure-Preis für West Europe liefert eine nutzlose Zahl.

3. Rechnen Sie mit den offiziellen Kalkulatoren beider Anbieter und identischen Eingaben. Nutzen Sie den AWS Pricing Calculator und den Azure Pricing Calculator und geben Sie übereinstimmende Instanzgrössen, Speicherklassen und geschätzte Nutzungsstunden ein.

4. Berücksichtigen Sie Rabatte für Reservierungen separat. Rechnen Sie zuerst mit nutzungsabhängigen Preisen und dann erneut mit AWS Savings Plans oder Reserved Instances beziehungsweise Azure Reserved VM Instances oder Savings Plans, denn Rabatte für verbindliche Nutzung können den Vergleich je nach Planbarkeit Ihrer Auslastung stark verschieben.

5. Testen Sie Spot- und Niedrigpriorität-Kapazität für unterbrechbare Workloads. AWS Spot Instances und Azure Spot Virtual Machines bieten beide hohe Rabatte für Aufgaben, die eine Unterbrechung verkraften, etwa Stapelverarbeitung und CI-Pipelines. Die Höhe des Rabatts variiert je nach Instanztyp und Region.

6. Rechnen Sie ausgehenden Datenverkehr und regionsübergreifende Übertragung ausdrücklich ein. Lassen Sie diesen Posten nicht in einer Schätzung für «Speicher» verschwinden, sondern berechnen Sie ihn separat anhand der Preisseiten für Datenübertragung beider Anbieter.

7. Wenden Sie Lizenzmobilität an, wo sie greift. Falls Sie Lizenzen für Windows Server oder SQL Server besitzen, rechnen Sie die Azure-Schätzung mit angewendetem Hybrid Benefit erneut und vergleichen Sie die Differenz.

Profi-Tipp: Planen Sie ein kleines Pilotbudget ein, typischerweise ein paar tausend Dollar und zwei bis vier Wochen, um Ihr echtes Verkehrsmuster aus dem Produktivbetrieb auf beiden Plattformen zu fahren, bevor Sie einen mehrjährigen Vertrag unterschreiben. Eine Schätzung aus dem Kalkulator sagt Ihnen, was ein Workload kosten sollte. Ein Pilot sagt Ihnen, was er tatsächlich kostet, sobald echter Verkehr, echte Protokolle und echte Support-Tickets auftauchen.

Sicherheit, Compliance und regionale Verfügbarkeit prüfen

AWS und Azure halten beide eine breite Palette an Zertifizierungen, darunter SOC 2, ISO 27001, HIPAA-Eignung und FedRAMP. «Wer ist konformer» ist deshalb selten die richtige Frage. Die richtige Frage lautet, ob der konkrete Dienst, den Sie einsetzen wollen, in der konkreten Region zertifiziert ist, in der Sie betreiben wollen, denn die Abdeckung der Zertifizierungen ist auf beiden Plattformen nicht für jeden Dienst und jede Region gleich.

Azure publishes detailed compliance and trusted-cloud documentation, die Zertifizierungen nach Region und Dienst aufschlüsselt, und AWS pflegt über sein eigenes Compliance-Center einen gleichwertigen Katalog an Nachweisen. Prüfen Sie beides, bevor Sie annehmen, ein in einer Region genutzter Dienst trage überall dieselbe Zertifizierung.

Bevor Sie sich für einen regulierten Workload auf eine Plattform festlegen, klären Sie:

• Garantien zum Datenstandort für genau jene Region, in der Sie betreiben, einschliesslich der Frage, ob Sicherungen oder Protokolle diese Region standardmässig verlassen.

• Optionen für souveräne Clouds oder Behörden-Clouds, falls Sie in einer regulierten Branche oder im öffentlichen Sektor tätig sind, denn AWS GovCloud und Azure Government laufen als getrennte, isolierte Umgebungen mit eigenem Servicekatalog.

• Optionen für die Schlüsselverwaltung: kundenverwaltete Schlüssel, Unterstützung für Hardware-Sicherheitsmodule und die Frage, ob Sie eigene Verschlüsselungsschlüssel mitbringen können.

• Tiefe von Protokollierung und Prüfpfad: ob die nativen Werkzeuge (CloudTrail bei AWS, Azure Monitor und Aktivitätsprotokoll bei Azure) jene Detailtiefe erfassen, die Ihr Compliance-Rahmenwerk verlangt.

• Zusagen zur Reaktion auf Vorfälle im Modell der geteilten Verantwortung, denn das Standard-SLA deckt auf keiner der beiden Plattformen alles ab, was man vielleicht annimmt.

Behandeln Sie die Compliance-Prüfung als Checkliste pro Dienst und pro Region, nicht als einmaligen Entscheid auf Plattformebene.

Was eine Migration wirklich an Zeit und Wissen kostet

Der Listenpreis für Rechenleistung und Speicher ist beim Entscheid zwischen AWS und Azure selten der grösste Kostenblock. Teurer ist fast immer das, was beim Wechsel mit Ihrem Team und Ihrer bestehenden Codebasis passiert.

Versteckte Migrationskosten zeigen sich an vorhersehbaren Stellen: Infrastruktur als Code neu schreiben (Terraform-Module, CloudFormation-Vorlagen oder Bicep-Dateien lassen sich nicht direkt zwischen den Plattformen übertragen), CI/CD-Pipelines auf die Schnittstellen des neuen Anbieters umbauen, Integrationen für Überwachung und Alarmierung ersetzen, Betriebsanleitungen aktualisieren, die bestimmte Werkzeuge voraussetzen, und in vielen Fällen Spezialist:innen anstellen oder ausbilden, welche die Eigenheiten der Zielplattform kennen. Nichts davon erscheint im Preiskalkulator.

Drei Migrationsansätze bringen sehr unterschiedliche Kosten- und Risikoprofile mit:

• Rehosting («Lift and Shift»). Workloads unverändert verschieben. Am schnellsten und anfangs am günstigsten, aber Sie erben alle Ineffizienzen der alten Plattform und schöpfen die Kostenvorteile der neuen selten aus.

• Replatforming. Gezielte Anpassungen vornehmen, etwa eine selbst betriebene Datenbank durch einen verwalteten Dienst ersetzen oder das Netzwerkmodell des neuen Anbieters berücksichtigen, ohne alles neu zu schreiben. Für die meisten mittelgrossen Migrationen der ideale Mittelweg.

• Refactoring. Die Anwendung so umbauen, dass sie die nativen Dienste der neuen Plattform voll ausnutzt. Am teuersten zu Beginn, aber oft der einzige Weg zu echten Einsparungen auf lange Sicht, wenn ein Workload jahrelang auf der neuen Plattform bleibt.

Beim Wissen gilt: AWS-Zertifikate (Solutions Architect, DevOps Engineer) bleiben in Stelleninseraten für cloud-native Rollen und Start-ups der bekanntere Ausweis, während Azure-Zertifikate (Administrator Associate, Solutions Architect Expert) bei Grossunternehmen und im öffentlichen Sektor mehr Gewicht haben, vor allem weil dort ohnehin Microsoft-geprägte Infrastruktur läuft. Wenn Sie auf Ihre Laufbahn statt auf Ihr Unternehmen setzen, schauen Sie sich die Stelleninserate Ihrer Zielbranche an, bevor Sie sich für einen Zertifizierungspfad entscheiden.

Organisationen, die einen ernsthaften Plattformwechsel planen, unterschätzen diese Phase häufig. Eine sauber durchgeführte Migration von Altsystemen führt Umschulung und Prozessveränderung als eigenen Budgetposten, nicht als nachträglichen Gedanken.

Wie entscheiden Sie zwischen AWS und Azure? Ein Vorgehen Schritt für Schritt

Sie brauchen keine Gremiumsdebatte, um diesen Entscheid nachvollziehbar zu machen. Sie brauchen eine Bestandsaufnahme, einen Pilot und eine kleine Zahl von Kennzahlen, die objektiv zeigen, welche Plattform bei Ihrem tatsächlichen Workload besser abgeschnitten hat.

1. Erfassen Sie zuerst Ihre Rahmenbedingungen. Listen Sie jede bestehende Microsoft-Lizenz, jede Abhängigkeit von Active Directory, jede Anforderung an Compliance-Zonen und jede Vorgabe zum Datenstandort auf, bevor Sie die Werbeseite einer Plattform anschauen.

2. Wählen Sie zwei oder drei repräsentative Workloads, nicht Ihren gesamten Bestand. Nehmen Sie solche, die Ihren realen Mix abbilden: eine zustandsbehaftete Anwendung mit Datenbank, eine zustandslose Schnittstelle und, falls relevant, eine Stapelverarbeitung oder einen KI-Workload.

3. Fahren Sie gespiegelte Piloten in derselben Region auf beiden Plattformen, mit identischer Instanzgrösse, identischen Speicherklassen und identischen Verkehrsmustern, während mindestens zwei bis vier Wochen.

4. Messen Sie die Kosten pro Transaktion, nicht nur die Monatsrechnung, denn die reinen Monatsausgaben verdecken Unterschiede bei Durchsatz und Effizienz zwischen den Plattformen.

5. Verfolgen Sie die Latenz unter echtem Verkehr, nicht in synthetischen Tests, besonders bei allem, was Anmeldeabläufe über Entra ID oder IAM berührt.

6. Protokollieren Sie den Betriebsaufwand, also Stunden für Deployment-Skripte, Aufbau der Überwachung und Support-Tickets, denn hier tauchen versteckte Kosten am schnellsten auf.

7. Legen Sie Abbruchkriterien im Voraus fest: Wenn zum Beispiel die Lizenzkosten eine bestimmte Schwelle überschreiten oder eine erforderliche Zertifizierung in Ihrer Zielregion fehlt, ist das ein Ausschlussgrund und kein Verhandlungspunkt.

Entscheidungsfaktor	Spricht für AWS	Spricht für Azure
Bestehende Microsoft-Lizenzen / AD	Nein	Ja
Breitester Servicekatalog nötig	Ja	Nein
Experimente mit mehreren KI-Modellen	Ja (Bedrock)	Nein
Integration mit Microsoft 365 / Copilot	Nein	Ja (Azure OpenAI)
Hybrid mit gemischtem Anbieterbestand	Nein	Ja (Arc)
Physische Hardware vor Ort nötig	Ja (Outposts)	Nein
Team bereits Linux-nativ	Ja	Nein
Regulierte Workloads mit Windows/SQL	Nein	Ja

Fahren Sie den Pilot vor dem Vertrag, nicht danach.

Wo Ampersand Labs ins Spiel kommt, wenn Sie einen Migrationspartner brauchen

Die Wahl zwischen AWS und Azure ist nur die halbe Aufgabe. Jemand muss den Pilot trotzdem durchführen, die realen Workload-Kosten rechnen, die Identitätsintegration neu verdrahten und das Altsystem migrieren, ohne den Produktivbetrieb zu stören. Genau diesen Teil lassen die meisten Vergleichsartikel aus, und genau dort laufen viele Migrationen still und leise aus dem Budget.

Ein spezialisiertes Entwicklungsstudio kann solche Arbeit begleiten, mit erfahrenen Entwickler:innen vom ersten Architekturgespräch bis zur Übergabe, statt mit wechselnden Junioren, die Ihren Stack auf Ihre Kosten lernen. Das Studio hat Systemintegrationen umgesetzt, die Identitäten, Schnittstellen und Altsysteme verbinden, Migrations- und Replatforming-Projekte durchgeführt und Kunden wie UBS und die Stadt Lugano betreut, also Organisationen, die weder eine Neuentwicklung mitten im Projekt noch einen Anbieter dulden, der nach dem Start verschwindet.

Wenn Ihr Team eine technische Leitung auf Zeit braucht, um den Pilot zu führen und den Entscheid zu fällen, bietet Ampersand Labs genau dafür Unterstützung als Interim-CTO. Wenn Sie parallel zum Plattformentscheid neue Infrastruktur aufbauen, zeigt die Seite zu den Entwicklungsdienstleistungen, wie ein Aufbauprojekt aussieht, und die laufende Betreuung beschreibt, was nach dem Abschluss der Migration passiert, denn dann tauchen meist die echten Betriebsfragen auf. Wer speziell nach verwaltetem AWS-Support sucht, findet mit den AWS-Diensten von Vadacom einen spezialisierten Partner in diesem Bereich.

Beginnen Sie mit einem Beratungsgespräch zur Architektur, bevor Sie einen Plattformvertrag unterschreiben. Genau dort spart ein zweites erfahrenes Augenpaar am meisten Geld.

Quellen

Rechnen Sie mit Ihren eigenen Zahlen, bevor Sie irgendeinem Vergleich vertrauen, auch diesem hier. Nutzen Sie die Architekturhinweise von AWS zu Azure für die Zuordnung bei der Migration, die Compliance-Dokumentation von Azure für die Prüfung regionsspezifischer Zertifizierungen und die Marktanteils-Erhebung von Statista, um zu sehen, wie sich das Wettbewerbsbild jedes Quartal verschiebt.

• 60%

• Azure publishes detailed compliance and trusted-cloud documentation

Häufige Fragen

Was ist besser, Azure oder AWS?

Keine der beiden Plattformen ist generell besser. Azure passt in der Regel zu Microsoft-geprägten Unternehmen mit bestehendem Active Directory und Lizenzen für Windows und SQL Server, während AWS in der Regel zu Linux-nativen, cloud-nativen Teams passt, die den breitesten Servicekatalog brauchen. Rechnen Sie Ihren konkreten Workload auf beiden Plattformen durch, bevor Sie entscheiden.

Wer sind die drei grossen Cloud-Anbieter?

AWS, Microsoft Azure und Google Cloud bilden die grossen drei und hielten anfangs 2026 zusammen über 60 % des weltweiten Marktes für Cloud-Infrastruktur.

Wird Azure AWS überholen?

Azure hat den Rückstand beim Marktanteil verkleinert und führt bei Hybrid-Szenarien und der Identitätsintegration im Unternehmen. Anfangs 2026 lag AWS mit rund 28 % gegenüber 21 % von Azure gesamthaft aber weiterhin vorn. Es gibt keine Anzeichen für eine baldige Umkehr bei der Gesamtgrösse.

Lohnt es sich eher, Azure oder AWS zu lernen?

Für cloud-native Rollen und Positionen in Start-ups wiegen AWS-Zertifikate in Stelleninseraten meist schwerer. Für Rollen in Grossunternehmen und im öffentlichen Sektor sind Azure-Zertifikate oft wertvoller, insbesondere rund um Entra ID und hybride Administration, weil dort bereits Microsoft-geprägte Infrastruktur läuft.

Wie schneiden AWS und Azure bei KI-Workloads ab?

AWS Bedrock bietet herstellerneutralen Zugriff auf mehrere Modellanbieter, was zu Teams passt, die Modelle flexibel wechseln oder vergleichen wollen. Azure OpenAI (heute Teil von Azure AI Foundry) bietet die tiefere native Integration mit Microsoft 365 und Copilot, was zu Teams passt, denen die Verbindung mit Produktivitätswerkzeugen wichtiger ist als die Auswahl an Modellen.

Empfohlen

• Die Mitte: über 600 Websites für eine Schweizer Partei aus einem einzigen System.

• KI-Automatisierung & Workflow-Agents Zürich

• Interim-CTO Zürich, technische Leitung auf Zeit und in Teilzeit

• Arthouse Kinos: neue Website und Ticketshop für die bekanntesten Kinos Zürichs.