AWS CodePipeline vs. Argo CD: CI/CD als Service oder als Architekturentscheidung

Service oder Architekturentscheidung?

CI/CD wird oft als Werkzeugfrage behandelt: Welcher Dienst, welche Pipeline, welcher Anbieter? In Wirklichkeit ist CI/CD eine architektonische Grundsatzentscheidung. Sie definiert, wie Deployments gedacht werden, wie stark Plattformen an Anbieter gebunden sind und wie kontrollierbar Systeme langfristig bleiben.

AWS CodePipeline und Argo CD stehen exemplarisch für zwei sehr unterschiedliche Ansätze. Das eine ist ein Cloud-Service zur Orchestrierung von Deployments. Das andere ist ein Betriebsmodell, das Deployments strukturell neu definiert.

AWS CodePipeline: CI/CD als nativer Cloud-Service

AWS CodePipeline ist der native CI/CD-Dienst von Amazon Web Services. Er orchestriert Build-, Test- und Deployment-Schritte über AWS-Services wie CodeCommit, CodeBuild, CodeDeploy und CloudFormation. Pipelines werden ereignisbasiert ausgelöst, integrieren sich eng mit IAM, AWS-Ressourcen und Regionen und werden vollständig als Managed Service betrieben.

Der operative Einstieg ist niedrig. Für bestehende AWS-Workloads funktioniert CodePipeline reibungslos. Es gibt wenig zu betreiben, wenig zu planen und klare Defaults. CI/CD wird konsumiert – ähnlich wie andere Cloud-Funktionen.

Diese enge Integration definiert jedoch auch die Grenzen des Modells.

Imperative Ausführung innerhalb einer Plattform

CodePipeline folgt einem imperativen Ansatz. Eine Pipeline beschreibt Schritte, die aktiv einen Zielzustand herstellen: Build ausführen, Artefakte deployen, Infrastruktur verändern. Nach erfolgreichem Lauf gilt der Zustand als korrekt, bis eine neue Pipeline gestartet wird.

Was fehlt, ist eine kontinuierliche Überprüfung dieses Zustands. Der tatsächliche Laufzeit-Zustand wird nicht dauerhaft gegen eine deklarative Quelle geprüft. Drift-Erkennung ist kein zentrales Konzept, sondern muss über zusätzliche Mechanismen ergänzt werden.

Multi-Cluster- oder Multi-Cloud-Szenarien erfordern parallele Pipelines, zusätzliche Tools oder komplexe Orchestrierung. Portabilität ist nicht vorgesehen, sondern höchstens nachträglich konstruierbar. Deployment-Logik bleibt technisch und organisatorisch an AWS gebunden.

Argo CD: GitOps als konsequentes Betriebsmodell

Argo CD setzt an einer anderen Stelle an. Als Open-Source-Projekt aus dem Kubernetes-Ökosystem implementiert es GitOps nicht als Tool, sondern als Betriebsprinzip.

Der gewünschte Zustand von Anwendungen liegt deklarativ in Git-Repositories. Argo CD läuft im Cluster und vergleicht kontinuierlich diesen Soll-Zustand mit dem Ist-Zustand. Abweichungen werden erkannt und – je nach Konfiguration – automatisch oder kontrolliert synchronisiert.

Deployments sind damit keine einmaligen Aktionen mehr, sondern ein dauerhaft überwachter Zustand.

Infrastrukturunabhängige Architektur

Diese Architektur ist bewusst infrastrukturoffen. Argo CD funktioniert unabhängig vom Cloud-Provider, unterstützt mehrere Kubernetes-Cluster parallel und trennt Deployment-Logik strikt von Build-Systemen.

CI erzeugt Artefakte. Git definiert den Zielzustand. Argo CD sorgt für dessen Durchsetzung. Rollbacks sind einfache Git-Reverts, keine komplexen Pipeline-Skripte. Auditierbarkeit, Nachvollziehbarkeit und Reproduzierbarkeit ergeben sich aus Versionskontrolle – nicht aus Logfiles proprietärer Dienste.

Deployment-Logik wird damit Teil der Plattformarchitektur, nicht ein externer Service.

Betrieb: Abstraktion vs. Kontrolle

Der Unterschied zeigt sich besonders im Betrieb. CodePipeline abstrahiert Komplexität, bindet diese Abstraktion jedoch an AWS-Schnittstellen, Service-Limits und Kostenmodelle. Änderungen am Deployment-Modell folgen der Plattformlogik des Anbieters.

Argo CD verlangt initial mehr konzeptionelle Klarheit. Repository-Strukturen, deklarative Manifeste und Zuständigkeiten müssen sauber definiert werden. Dafür reduziert sich langfristig manueller Eingriff. Konfigurationsdrift, Umgebungsinkonsistenzen und schwer reproduzierbare Deployments werden strukturell vermieden.

Deployments werden deterministisch, clusterübergreifend vergleichbar und unabhängig von einzelnen Anbieter-Services.

CI/CD als Gestaltungsfrage

In Umgebungen mit [Kubernetes]-Fokus, regulatorischen Anforderungen oder Multi-Cloud-Strategien wird CI/CD damit zur Gestaltungsfrage. Proprietäre Pipelines optimieren den Weg innerhalb einer Plattform. GitOps mit Argo CD entkoppelt Deployments von Infrastrukturentscheidungen.

Das Ergebnis ist kein schnelleres Deployment, sondern ein stabileres Betriebsmodell. Plattformen bleiben beweglich, auditierbar und langfristig wartbar – auch dann, wenn sich Infrastruktur oder Anbieter ändern.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

AWS CodePipeline ist sinnvoll für:

• klar AWS-zentrierte Workloads
• klassische CI/CD-Pipelines
• schnelle Umsetzung ohne Plattformanspruch
• geringe Anforderungen an Portabilität

Argo CD ist sinnvoll für:

• [Kubernetes]-zentrierte Plattformarchitekturen
• GitOps-basierte Betriebsmodelle
• Multi-Cluster- oder Multi-Cloud-Setups
• Compliance- und Audit-Anforderungen
• langfristig stabile Deployment-Strategien

Fazit

CI/CD ist kein Komfort-Feature. Es entscheidet, wie viel Kontrolle, Transparenz und Beweglichkeit eine Plattform langfristig behält.

AWS CodePipeline optimiert Ausführung innerhalb einer Plattform. Argo CD etabliert ein Betriebsmodell, das Deployments von Infrastrukturentscheidungen entkoppelt.

Der Unterschied ist nicht technisch, sondern strukturell. Wer CI/CD als Service konsumiert, akzeptiert Plattformgrenzen. Wer GitOps als Architekturentscheidung trifft, schafft eine belastbare Grundlage – auch in fünf Jahren.