Der Name „Amazon Q“ steht bei AWS für eine ganze Familie generativer KI-Assistenten. Amazon Q Developer ist der Teil, der sich an Entwicklerinnen und Entwickler, Cloud-Architekten und IT-Betrieb richtet. Daneben existiert Amazon Q Business, ein Assistent für Wissensarbeit auf Unternehmensdaten, der mit dem hier behandelten Produkt wenig zu tun hat. Wer sich mit dem Thema befasst, sollte diese Trennung im Hinterkopf behalten, weil Angebote, Preisseiten und Dokumentationen beide Produkte gelegentlich nebeneinander nennen.
Drei Eigenschaften prägen Amazon Q Developer:
AWS hat Code-Vorschläge zunächst unter dem Namen CodeWhisperer angeboten. Dieser Dienst konzentrierte sich auf Inline-Vervollständigung in der IDE, eine Erkennung von Ähnlichkeiten zu Open-Source-Code und einfache Sicherheitsscans. Mit der Einführung der Amazon-Q-Familie wurde CodeWhisperer in Amazon Q Developer überführt und um Chat- und Agentenfunktionen ergänzt. Bestehende Funktionen blieben weitgehend erhalten, wurden aber unter neuer Marke und mit erweitertem Umfang fortgeführt.
Die Produktgeschichte zeigt ein Muster, das man bei AWS kennen sollte: Namen, Zuschnitte und Paketierungen ändern sich vergleichsweise häufig. So wurden etwa Transformationsfunktionen in ein eigenes Angebot unter dem Namen AWS Transform überführt, und mit Kiro hat AWS eine agentische Entwicklungsumgebung vorgestellt, die konzeptionell an Amazon Q Developer anknüpft. Nach unserem Kenntnisstand wurde zudem die Kommandozeilen-Variante von Amazon Q Developer in Richtung Kiro weiterentwickelt beziehungsweise umbenannt. Prüfhinweis: Wie Amazon Q Developer, Kiro und AWS Transform zum Zeitpunkt Ihrer Entscheidung zueinander stehen – welche Funktionen wo verortet sind, welche Varianten auslaufen und welche Tarife gelten –, sollten Sie unbedingt in der aktuellen AWS-Dokumentation nachlesen.
Am meisten profitieren Teams, die Anwendungen auf AWS entwickeln und betreiben: Backend-Entwicklung mit Lambda, Containern oder klassischen Instanzen, Datenpipelines, Infrastruktur als Code mit CloudFormation, CDK oder Terraform sowie Betriebsteams, die Fehlerbilder in Cloud-Ressourcen analysieren müssen. Hier kann der Assistent seinen Plattformkontext ausspielen. Ebenfalls interessant ist er für Organisationen mit nennenswerten Altbeständen in Java oder .NET, die Versionsupgrades oder Plattformwechsel vor sich herschieben.
Weniger zwingend ist Amazon Q Developer für Teams, die überwiegend auf Microsoft Azure oder Google Cloud setzen, die stark in GitHub- oder GitLab-Workflows verankert sind und dort bereits einen integrierten Assistenten nutzen, oder die einen reinen Fokus auf Frontend-Entwicklung haben. Auch Organisationen mit sehr strengen Souveränitätsanforderungen, die Quellcode grundsätzlich nicht an einen US-Hyperscaler übermitteln wollen, müssen genauer hinsehen – dazu mehr in Kapitel 09.
AWS bietet Amazon Q Developer in einer kostenlosen Stufe und in einer kostenpflichtigen Stufe an, die üblicherweise als Pro bezeichnet wird. Die kostenlose Stufe richtet sich an Einzelpersonen und zum Ausprobieren; sie ist mit einer persönlichen AWS-Kennung nutzbar und enthält Kontingente für Chat, Agenten und Transformationen, die bewusst begrenzt sind. Die Pro-Stufe wird pro Nutzer und Monat abgerechnet, über das AWS-Konto des Unternehmens verwaltet und an eine zentrale Identitätsverwaltung angebunden. Sie bietet höhere Kontingente, Verwaltungsfunktionen für Administratoren, Richtlinien auf Organisationsebene und – besonders wichtig – andere Zusagen zur Verwendung der übermittelten Inhalte.
Konkrete Preise, Kontingente und Abrechnungsmodelle für zusätzliche Nutzung, etwa bei Transformationen größerer Codebestände, ändern sich erfahrungsgemäß. Wir nennen sie hier bewusst nicht. Für eine belastbare Kalkulation sollten Sie die aktuelle Preisseite von AWS heranziehen und gegebenenfalls Ihren AWS-Ansprechpartner einbinden, insbesondere wenn bereits Rahmenverträge oder Rabattvereinbarungen bestehen.
Amazon Q Developer begegnet Nutzern an mehreren Stellen. Am bekanntesten ist die Erweiterung für verbreitete Entwicklungsumgebungen wie Visual Studio Code, die JetBrains-Familie und Visual Studio; für weitere Umgebungen gab es zeitweise Vorschau-Versionen. Hinzu kommt eine Kommandozeilen-Variante, die Befehlsvorschläge, Übersetzung natürlicher Sprache in Shell-Befehle und einen agentischen Chat im Terminal bot – diese Variante ist nach unserem Kenntnisstand inzwischen in Kiro aufgegangen, was Sie beim Anbieter prüfen sollten. Ein dritter Zugang ist die AWS-Managementkonsole selbst, in der Amazon Q als Assistent für Fragen zu Diensten, Ressourcen, Fehlern und Kosten bereitsteht. Schließlich lässt sich der Assistent je nach Konfiguration auch über Chat-Kanäle wie Slack oder Microsoft Teams ansprechen.
Diese Vielfalt ist Stärke und Herausforderung zugleich. Sie erlaubt, dass Entwicklung und Betrieb mit demselben Assistenten arbeiten. Sie bedeutet aber auch, dass eine Einführung mehr umfasst als das Verteilen einer IDE-Erweiterung: Berechtigungen in der Konsole, Richtlinien für Chat-Kanäle und die Frage, welche Zugangswege überhaupt freigegeben werden, gehören mit auf die Agenda.
Im Umfeld von Amazon Q Developer sind mehrere verwandte Angebote entstanden. Kiro ist eine eigenständige, agentische Entwicklungsumgebung von AWS, die stark auf spezifikationsgetriebenes Arbeiten setzt: Aus Anforderungen werden strukturierte Spezifikationen, daraus Entwürfe und Aufgabenlisten, die ein Agent abarbeitet. AWS Transform bündelt agentische Modernisierungsfunktionen für größere Vorhaben, etwa für .NET-Portierungen, Mainframe-Modernisierung oder Migrationen von virtualisierten Umgebungen. Amazon Q Business schließlich ist ein Assistent für Unternehmenswissen und gehört nicht zur Entwicklerwerkzeugkette.
Für die Praxis heißt das: Wer heute über Amazon Q Developer spricht, sollte klären, ob der klassische IDE-Assistent, die agentische Entwicklungsumgebung oder ein Modernisierungsprojekt gemeint ist. Die Zuordnung von Funktionen zu Produkten hat sich mehrfach verschoben und kann sich weiter verschieben. Prüfhinweis: Lassen Sie sich vor einer Entscheidung vom Anbieter bestätigen, welche Funktion unter welchem Produkt, Tarif und Vertrag angeboten wird.
Die Inline-Vervollständigung ist die unauffälligste, aber im Alltag oft wirkungsvollste Funktion. Sie greift dort, wo Code vorhersehbar ist: Datenklassen, Schleifen, Validierungen, wiederkehrende Aufrufe von Bibliotheken und – für AWS-Teams besonders relevant – Aufrufe der AWS-SDKs mit ihren oft umständlichen Parameterstrukturen. Wer schon einmal eine Berechtigungsrichtlinie oder eine Infrastrukturvorlage von Hand zusammengesetzt hat, weiß, wie viel Zeit hier in Nachschlagen fließt. Genau dort spart der Assistent spürbar Aufwand.
Der Chat ergänzt dies um Erklärungs- und Diagnosefähigkeiten. Typische Fragen sind „Was macht diese Funktion?“, „Warum bekommt meine Lambda-Funktion keinen Zugriff auf den Bucket?“ oder „Wie migriere ich diesen Aufruf auf die neue SDK-Version?“. Markierter Code, geöffnete Dateien und – je nach Version – ein Index des Arbeitsbereichs dienen als Kontext. Wie bei allen Assistenten gilt: Die Qualität der Antwort hängt stark davon ab, wie präzise die Frage gestellt und wie gezielt der Kontext gewählt ist.
Ein Merkmal, das Amazon Q Developer von Beginn an mitbrachte, ist das Referenz-Tracking. Erkennt der Dienst, dass ein Vorschlag deutlich einem Code-Abschnitt aus öffentlich verfügbaren Quellen ähnelt, kann er darauf hinweisen und die vermutete Lizenz nennen. Administratoren können festlegen, ob solche Vorschläge überhaupt angezeigt werden. Das ersetzt keine Lizenz-Compliance, ist aber ein hilfreicher Baustein im Umgang mit Fremdcode.
Die Sicherheitsscans prüfen Code auf bekannte Schwachstellenmuster, hartkodierte Geheimnisse und unsichere Infrastruktur-Konfigurationen. Sie können im Editor während der Arbeit oder für ganze Projekte angestoßen werden und liefern Korrekturvorschläge. Sie ersetzen keine etablierten Prüfwerkzeuge in der Build-Pipeline, können diese aber sinnvoll ergänzen, weil sie Probleme bereits beim Schreiben sichtbar machen.
Für die Pro-Stufe bietet AWS zudem Anpassungen an: Unternehmen können den Assistenten mit ihren eigenen, privaten Repositorys verbinden, damit Vorschläge interne Bibliotheken, Schnittstellen und Konventionen berücksichtigen. Das ist für Organisationen mit umfangreichem eigenem Framework-Code interessant, wirft aber zusätzliche Fragen auf: Welche Repositorys werden einbezogen, wo liegen die abgeleiteten Daten, wer hat Zugriff, und wie werden sensible Bereiche ausgeschlossen? Diese Fragen sollten vor der Aktivierung beantwortet sein. Umfang und Verfügbarkeit solcher Anpassungen sind beim Anbieter zu prüfen.
In der IDE lassen sich Agenten über den Chat beauftragen. Ein Entwicklungsagent nimmt eine Aufgabenbeschreibung entgegen, analysiert den relevanten Code, erstellt einen Umsetzungsplan und schlägt Änderungen über mehrere Dateien vor, die als Diff geprüft und übernommen werden können. In neueren Versionen arbeitet der Chat selbst agentisch: Er liest Dateien, führt nach Freigabe Befehle aus, wertet Ergebnisse aus und korrigiert sich an Fehlern. Ein Testagent erzeugt Unit-Tests für ausgewählte Funktionen und versucht dabei Randfälle abzudecken. Ein Dokumentationsagent erstellt oder aktualisiert README-Dateien und Beschreibungen auf Basis des Codes. Ein Review-Agent prüft Änderungen auf Qualitäts-, Sicherheits- und Stilprobleme und kommentiert sie.
Die genaue Benennung und Bedienung dieser Agenten hat sich mehrfach verändert – zeitweise wurden sie über Schrägstrich-Befehle im Chat aufgerufen, später stärker in einen allgemeinen agentischen Chat integriert. Für die Praxis entscheidender als die Bedienung ist das Prinzip: Der Agent liefert einen Vorschlag, der Mensch entscheidet. Agenten, die Befehle ausführen oder Dateien schreiben dürfen, sollten nur mit klar begrenzten Berechtigungen und in einer kontrollierten Umgebung arbeiten.
Ein Alleinstellungsmerkmal von Amazon Q Developer war von Beginn an die automatisierte Code-Transformation. Der bekannteste Anwendungsfall ist das Anheben von Java-Anwendungen von älteren auf neuere Long-Term-Support-Versionen: Der Agent analysiert das Projekt, aktualisiert Abhängigkeiten und Build-Konfigurationen, ersetzt veraltete Schnittstellen, versucht das Projekt zu bauen und die vorhandenen Tests auszuführen und legt am Ende einen Änderungsvorschlag samt Zusammenfassung vor. Ähnliche Ansätze gibt es für die Portierung von Anwendungen auf Basis des klassischen .NET Framework auf das plattformübergreifende .NET, das unter Linux und in Containern betrieben werden kann.
Darüber hinaus hat AWS agentische Unterstützung für sehr große Vorhaben angekündigt und ausgebaut: die Analyse und Modernisierung von Mainframe-Anwendungen, etwa in COBOL, und die Migration virtualisierter Umgebungen in die Cloud. Diese Funktionen sind inzwischen überwiegend unter dem Namen AWS Transform gebündelt. Für den Mittelstand sind vor allem die Java- und .NET-Transformationen relevant, weil viele gewachsene Fachanwendungen genau auf diesen Plattformen laufen und die Versionsmigration seit Jahren auf der Liste steht.
Realistisch betrachtet sind solche Transformationen kein Knopfdruck. Sie funktionieren umso besser, je sauberer das Projekt strukturiert ist, je vollständiger der Build reproduzierbar ist und je besser die Testabdeckung ausfällt. Eigene Frameworks, exotische Abhängigkeiten oder fehlende Tests führen zu Teilergebnissen, die manuell nachgearbeitet werden müssen. Der Nutzen liegt dann darin, dass der mühsame, mechanische Teil der Migration beschleunigt wird und die Fachleute ihre Zeit auf die wirklich schwierigen Stellen konzentrieren können.
Mit Kiro hat AWS die agentische Idee weitergedacht. Der Kern ist ein strukturierter Ablauf: Anforderungen werden in Spezifikationen überführt, daraus entstehen ein technischer Entwurf und eine Aufgabenliste, die der Agent Schritt für Schritt abarbeitet. Ergänzend gibt es ereignisgesteuerte Automatisierungen, die etwa beim Speichern einer Datei Tests oder Dokumentation aktualisieren. Dieser Ansatz adressiert ein bekanntes Problem agentischer Werkzeuge: dass sie ohne klare Vorgaben schnell vom Ziel abweichen. Für Teams, die Nachvollziehbarkeit schätzen, ist die Idee attraktiv, weil die Spezifikation zugleich als Dokumentation dient.
Ob Kiro für Ihr Team der bessere Einstieg ist als die klassische IDE-Erweiterung von Amazon Q Developer, hängt von Arbeitsweise und Toolchain ab. Kiro ist eine eigene Entwicklungsumgebung, was einen Werkzeugwechsel bedeutet; die IDE-Erweiterung fügt sich in bestehende Editoren ein. Prüfhinweis: Produktstatus, Tarife, Datenverarbeitungsbedingungen und die Frage, welche Varianten weiterentwickelt oder eingestellt werden, sollten Sie zum Entscheidungszeitpunkt beim Anbieter verifizieren. Unser Beratungsansatz bleibt davon unberührt: Wir bewerten Werkzeuge anhand Ihrer Ziele, nicht anhand von Produktnamen.
Die IDE-Erweiterungen decken die Umgebungen ab, in denen die meisten professionellen Teams arbeiten: Visual Studio Code, die JetBrains-Familie mit IntelliJ IDEA, PyCharm, WebStorm und weiteren sowie Visual Studio für .NET-Entwicklung. Für weitere Editoren wie Eclipse gab es Vorschau-Versionen, deren aktueller Status beim Anbieter zu prüfen ist. Auch in Datenwerkzeugen wie JupyterLab und in AWS-eigenen Umgebungen für Datenanalyse und maschinelles Lernen ist der Assistent verfügbar. Für die Kommandozeile existierte eine eigene Variante mit Befehlsvervollständigung und agentischem Chat, die nach unserem Kenntnisstand in Kiro überführt wurde.
Für Teams mit gemischten Umgebungen ist das ein Vorteil: Java-Teams in IntelliJ, .NET-Teams in Visual Studio und Skript- oder Infrastrukturteams in VS Code können denselben Assistenten mit denselben Richtlinien nutzen. Der Funktionsumfang ist allerdings nicht in jeder Umgebung identisch; neue Funktionen erscheinen häufig zuerst in VS Code und JetBrains. Vor einem Rollout lohnt ein kurzer Abgleich, ob die gewünschten Funktionen in allen relevanten Umgebungen verfügbar sind.
Hinzu kommt die Erweiterbarkeit über das Model Context Protocol (MCP), einen offenen Standard, über den Agenten an zusätzliche Werkzeuge und Datenquellen angebunden werden können – etwa an Ticketsysteme, interne Dokumentationen oder Datenbanken. Das erweitert die Möglichkeiten erheblich, vergrößert aber auch die Angriffsfläche. Jede MCP-Anbindung sollte deshalb wie eine neue Software-Abhängigkeit behandelt werden: Herkunft prüfen, Berechtigungen minimieren und Freigaben dokumentieren.
Bei Git-Plattformen hat AWS Partnerschaften und eigene Integrationen aufgebaut. So gibt es eine Kombination aus GitLab Duo und Amazon Q, die agentische Funktionen in GitLab-Workflows bringen soll, sowie Integrationen für GitHub, über die etwa Reviews oder Feature-Umsetzungen aus Issues heraus angestoßen werden können. Reifegrad, Verfügbarkeit in bestimmten Editionen und Regionen sowie die Bedingungen solcher Integrationen unterscheiden sich und sind beim Anbieter zu prüfen. Wer bereits stark in GitHub oder GitLab investiert ist, sollte genau vergleichen, ob der dort nativ angebotene Assistent nicht reibungsloser passt.
In CI/CD-Pipelines spielt Amazon Q Developer vor allem über Sicherheits- und Review-Funktionen sowie über die Unterstützung beim Schreiben von Pipeline-Definitionen eine Rolle. Für Pipelines auf AWS-Basis, etwa mit CodePipeline und CodeBuild, ist die Nähe naturgemäß größer. Für Jenkins, GitHub Actions oder GitLab CI hilft der Assistent eher beim Schreiben und Erklären von Konfigurationen als durch direkte Einbindung.
Hier liegt der eigentliche Unterschied zu allen anderen Coding-Assistenten. In der AWS-Managementkonsole kann Amazon Q Fragen zu Diensten und Architekturmustern beantworten, Fehlermeldungen erläutern und – mit entsprechenden Berechtigungen – Ressourcen im eigenen Konto auflisten oder deren Zustand erklären. Bei Netzwerkproblemen kann er beim Eingrenzen von Verbindungsfehlern helfen, bei operativen Störungen bei der Analyse von Metriken und Protokollen, und bei Kostenfragen bei der Einordnung von Ausgaben. Auch in einzelnen Dienst-Konsolen, etwa für Lambda, Datenbanken oder Datenintegration, tauchen kontextbezogene Assistenzfunktionen auf.
Für den Mittelstand ist das besonders wertvoll, weil Cloud-Know-how dort oft auf wenige Köpfe verteilt ist. Ein Assistent, der erklärt, warum eine Funktion keinen Zugriff auf eine Datenbank bekommt oder weshalb eine Rechnung gestiegen ist, entlastet diese Schlüsselpersonen. Gleichzeitig gilt: Ein Assistent mit Lesezugriff auf Kontoressourcen braucht ein sauberes Berechtigungskonzept. Wer welche Fragen zu welchen Konten stellen darf, sollte über IAM-Richtlinien geregelt und nicht dem Zufall überlassen werden.
Die Tabelle gibt eine qualitative Einschätzung aus unserer Beratungspraxis wieder. Funktionsumfänge ändern sich in diesem Markt in kurzen Abständen; vor einer Entscheidung empfehlen wir einen eigenen, strukturierten Vergleich mit realen Aufgaben aus Ihrem Codebestand.
Amazon Q Developer spielt seine Stärken aus, wenn die Zielplattform AWS ist. Dann wirken die Vorteile zusammen: Der Assistent versteht die Dienste, hilft bei Infrastrukturvorlagen und Berechtigungen, unterstützt im Betrieb und lässt sich über das bestehende AWS-Konto beschaffen, abrechnen und verwalten. Ein zweites starkes Argument sind anstehende Modernisierungsvorhaben in Java oder .NET, bei denen die Transformationsfunktionen echten Aufwand einsparen können. Und schließlich ist für viele Unternehmen die Vertrags- und Compliance-Seite einfacher, wenn AWS ohnehin bereits als Auftragsverarbeiter geprüft und eingebunden ist.
GitHub Copilot ist meist die naheliegendere Wahl für Teams, die ihren gesamten Entwicklungsprozess auf GitHub abbilden und eine möglichst reibungslose Integration in Pull-Requests, Issues und Actions suchen. Gemini Code Assist bietet sich für Organisationen an, die auf Google Cloud setzen. Wer maximale Souveränität verlangt und Code das eigene Netz nicht verlassen soll, sollte selbst betreibbare Lösungen wie Tabby oder Assistenten mit lokalen Modellen prüfen; für eine Plattformbindung an GitLab ist GitLab Duo eine Alternative. Für Teams, die primär agentisch und terminalnah arbeiten, sind Werkzeuge wie Claude Code einen Blick wert, für editorzentriertes Arbeiten mit Modellwahl etwa Cursor.
Die Entscheidung ist selten ein reines Entweder-oder. Häufig sehen wir Kombinationen: Amazon Q Developer für AWS-nahe Arbeit und den Cloud-Betrieb, ein weiterer Assistent für die allgemeine Entwicklung. Entscheidend ist, dass jede Kombination dieselben Datenschutz- und Sicherheitsregeln einhält und nicht unkontrolliert wächst.
Anders als bei einigen Open-Source-Assistenten lässt sich Amazon Q Developer nicht im eigenen Rechenzentrum betreiben. Die Modelle laufen in der AWS-Infrastruktur, und auch Anpassungen auf Basis eigener Repositorys werden dort verarbeitet. Für Unternehmen, die AWS bereits nutzen, ist das in der Regel kein grundsätzliches Problem, weil die Cloud-Abhängigkeit ohnehin besteht. Für Unternehmen ohne AWS-Bezug bedeutet es dagegen, einen zusätzlichen US-Cloud-Anbieter in die Werkzeugkette aufzunehmen. Wer Code grundsätzlich nur auf eigener Infrastruktur verarbeiten will, muss auf andere Lösungen ausweichen.
Innerhalb von AWS gibt es dennoch Stellschrauben: die Wahl der Region für das Pro-Profil, Netzwerkoptionen für private Verbindungen, die Protokollierung von Aktivitäten über die üblichen AWS-Werkzeuge und die Steuerung über Organisationsrichtlinien. Welche dieser Optionen für Amazon Q Developer im Detail verfügbar sind, sollte im Rahmen der Einführung mit der aktuellen Dokumentation abgeglichen werden.
Das Onboarding sollte nicht bei der Installation enden. Entwicklerinnen und Entwickler profitieren von kurzen, praxisnahen Formaten: Wie formuliere ich Aufgaben für einen Agenten? Wie prüfe ich einen Mehrdatei-Diff effizient? Wann ist der Chat in der Konsole hilfreich, wann gefährlich? Bewährt haben sich interne Ansprechpersonen, die Erfahrungen bündeln und Muster weitergeben, sowie eine kleine Sammlung guter Beispiele aus dem eigenen Codebestand.
Governance sollte mitwachsen. Zu Beginn reichen klare Grundregeln; mit zunehmender Nutzung kommen Fragen zu Anpassungen, MCP-Anbindungen, Agenten-Berechtigungen und neuen Produktvarianten hinzu. Für die Wirkungskontrolle empfehlen wir wenige, aussagekräftige Indikatoren statt pauschaler Produktivitätsversprechen: Durchlaufzeiten ausgewählter Aufgaben, Zufriedenheit der Teams, Fehlerquoten nach Reviews und der Fortschritt bei Modernisierungsvorhaben. Die Nutzungsstatistiken der Administrationsoberfläche liefern ergänzende Hinweise, ersetzen aber keine qualitative Bewertung.
Ein produzierendes Unternehmen mit einigen hundert Beschäftigten betreibt ein selbst entwickeltes Auftragsportal auf Basis einer älteren Java-Version, das intern gehostet wird. Die Geschäftsführung möchte das Portal auf AWS verlagern; die beiden zuständigen Entwickler sehen sich mit einem Versionsupgrade, neuen Abhängigkeiten und einer ungewohnten Cloud-Umgebung konfrontiert. In einem solchen Szenario kann Amazon Q Developer an drei Stellen helfen: beim Upgrade der Java-Version durch eine Transformation, beim Erstellen der Infrastrukturvorlagen für die Zielumgebung und bei der Fehlersuche im laufenden Betrieb. Der entscheidende Erfolgsfaktor ist jedoch nicht das Werkzeug, sondern die Vorbereitung: eine Testbasis, die das Verhalten des Portals absichert, ein reproduzierbarer Build und klare Freigaberegeln für Infrastrukturänderungen.
So hilfreich der Assistent sein kann, er ersetzt weder Architekturkompetenz noch Fachwissen. Gerade in kleinen Teams besteht die Gefahr, dass Vorschläge ungeprüft übernommen werden, weil die Zeit für gründliche Reviews fehlt. Hier hilft eine einfache Regel: Je größer die Tragweite einer Änderung – Berechtigungen, Netzwerk, Datenhaltung, Produktionssysteme –, desto strenger die Prüfung. Außerdem lohnt es sich, Abhängigkeiten bewusst zu bewerten: Wer Entwicklung, Betrieb und KI-Assistenz bei einem einzigen Hyperscaler bündelt, gewinnt Einfachheit, verliert aber Verhandlungsspielraum und Wechselfreiheit.
Für viele mittelständische Unternehmen ist zudem die Frage der Datenhoheit entscheidend. Quellcode enthält oft Geschäftslogik, Kalkulationsregeln oder Kundenbezüge, die als Betriebsgeheimnis gelten. Ob dieser Code an einen US-Anbieter übermittelt werden darf, ist eine Abwägung, die nicht allein von der IT, sondern gemeinsam mit Geschäftsführung, Datenschutz und gegebenenfalls Betriebsrat getroffen werden sollte.
Die Lizenzkosten der Pro-Stufe werden pro Nutzer und Monat abgerechnet; zusätzliche Kosten können bei intensiver Nutzung einzelner Funktionen entstehen, etwa bei der Transformation größerer Codemengen oder bei Nutzung jenseits enthaltener Kontingente. Wir nennen bewusst keine Beträge, weil sich Preise und Kontingente regelmäßig ändern – die aktuelle Preisseite von AWS und gegebenenfalls Ihr Rahmenvertrag sind maßgeblich. Für eine ehrliche Kalkulation gehören neben den Lizenzen auch Einführungsaufwand, Schulung, Review-Zeit und die Pflege von Richtlinien dazu. Bei Modernisierungsvorhaben sollte zudem die manuelle Nacharbeit nach einer Transformation realistisch eingeplant werden.
AWS sagt für die Pro-Stufe zu, Inhalte nicht zur Verbesserung des Dienstes zu verwenden; für die kostenlose Stufe gelten andere Regeln mit Opt-out-Möglichkeit. Diese Zusagen sollten Sie in der jeweils aktuellen Fassung der Bedingungen nachlesen und dokumentieren. Beim geistigen Eigentum sind zwei Richtungen zu unterscheiden: der Schutz des eigenen Codes vor unerwünschter Weiterverwendung und das Risiko, über Vorschläge fremden, lizenzpflichtigen Code zu übernehmen. Für Letzteres helfen das Referenz-Tracking und eine klare Regel, wie mit markierten Vorschlägen umzugehen ist. AWS bietet nach eigenen Angaben für bestimmte Konstellationen Freistellungen bei Urheberrechtsansprüchen an; Umfang und Voraussetzungen sind beim Anbieter zu prüfen.
Auf der Sicherheitsseite stehen Berechtigungen im Mittelpunkt. Agenten, die Befehle ausführen, und ein Konsolenassistent, der Ressourcen einsehen kann, brauchen das Prinzip der minimalen Rechte. Sensible Repositorys, Geheimnisse und Konfigurationsdateien mit Zugangsdaten gehören nicht in den Kontext eines Assistenten. Aktivitäten sollten über die vorhandenen AWS-Protokollierungswerkzeuge nachvollziehbar sein.
Quellcode ist nicht automatisch personenbezogen, enthält aber häufig personenbezogene Daten – in Testdaten, Kommentaren, Konfigurationen oder Protokollen. Zudem werden Nutzerdaten der Entwicklerinnen und Entwickler selbst verarbeitet. Damit ist eine datenschutzrechtliche Einordnung erforderlich: Auftragsverarbeitung mit AWS, Rechtsgrundlage für Übermittlungen in die USA, Eintrag ins Verzeichnis der Verarbeitungstätigkeiten und gegebenenfalls eine Datenschutz-Folgenabschätzung. Da AWS ein US-Unternehmen ist, bleibt auch bei Verarbeitung in einer EU-Region die Frage nach Zugriffsmöglichkeiten von US-Behörden bestehen, die in der Bewertung berücksichtigt werden sollte.
Die DSGVO-konformere Ausgestaltung besteht aus mehreren Bausteinen: ausschließlich die zentral verwaltete Pro-Stufe nutzen, das Profil in einer EU-Region anlegen und regionsübergreifende Verarbeitung prüfen, Datenminimierung durch Ausschluss sensibler Bereiche, ein dokumentiertes Opt-out für jede Weiterverwendung von Inhalten und eine interne Richtlinie. AWS hat zudem ein souveränes Cloud-Angebot für Europa aufgebaut; ob und in welchem Umfang Amazon Q Developer dort verfügbar ist, sollten Sie beim Anbieter erfragen. Wer Code grundsätzlich nicht an einen US-Anbieter übermitteln will, findet in selbst betriebenen Assistenten oder europäischen Anbietern die konsequentere Alternative – mit eigenen Abstrichen bei Funktionsumfang und Komfort.
