Wie viele reservierte Kapazitäten benötigt AWS CodeBuild macOS? Unternehmenskostenmodell 2026

📋 Inhaltsverzeichnis

Sie zahlen dauerhaft für reservierte macOS-Kapazität, obwohl Builds nur in kurzen Fenstern laufen? Kaufen Sie nicht nach Entwicklerzahl, sondern berechnen Sie die Mindestkapazität aus Ankunftsrate, Build-Dauer, zulässiger Wartezeit und Ausfallreserve.
Bei stabiler, hoher Auslastung bleibt ein kleines reserviertes Fleet sinnvoll; bei seltenen oder stark schwankenden Peaks sollten Sie zuerst einen PoC mit Remote Mac oder einer gemischten Kapazität durchführen.

Dieser Beitrag richtet sich an Sie, wenn Sie als IT- oder FinOps-Verantwortlicher ein Budget für AWS CodeBuild macOS begründen müssen.
Er hilft Ihnen außerdem, wenn mehrere iOS-Projekte dieselben Build-Ressourcen nutzen sollen oder Sie zwischen reservierten Knoten, elastischer Erweiterung und Remote Mac entscheiden.

Die Kapazität beginnt mit dem Lastprofil, nicht mit der Teamgröße

AWS CodeBuild macOS wird laut AWS-Dokumentation über reservierte Kapazitäts-Fleets betrieben. Eine gewöhnliche Abrechnung ausschließlich nach tatsächlich verbrauchten Build-Minuten ist für diese macOS-Konfiguration daher nicht die Grundlage des Modells. Die reservierten Knoten erzeugen während ihrer konfigurierten Nutzungsdauer Kosten; die konkrete Abrechnung hängt von Region, Konfiguration und gültiger Preisseite ab. Prüfen Sie deshalb vor jedem Budgetantrag die offiziellen AWS-CodeBuild-Preisinformationen.

Die entscheidende Größe ist die Zahl der gleichzeitig laufenden Builds. Ein Fleet mit einer parallelen Kapazität von drei kann nicht automatisch sechs wartende Jobs ohne Verzögerung abarbeiten. Umgekehrt bedeutet eine niedrige durchschnittliche Auslastung nicht, dass die Kapazität ausreichend dimensioniert ist. Wenn viele Pull Requests zwischen 09:00 und 11:00 Uhr eintreffen, kann die Warteschlange lang werden, obwohl der Tagesmittelwert unauffällig bleibt.

Erheben Sie für mindestens einen vollständigen Arbeitszyklus, besser für mehrere Release- und normale Entwicklungsphasen, diese Eingaben:

Ankunftszeit jedes Build-Jobs;
belegte Zeit vom Start bis zur Freigabe des macOS-Knotens;
Build-Typ: Pull Request, Regression, TestFlight oder Produktion;
Warteschlangendauer bis zum Start;
Anzahl und Dauer von Wiederholungen;
Projekt, Signaturprofil und Netzwerkabhängigkeiten;
Zeitpunkt und Ursache fehlgeschlagener Builds;
geplante Wartung und nicht verfügbare Knoten.

Die wichtigste Variable ist nicht die Zahl der Entwickler, sondern die zeitabhängige Ankunftsrate. Ein kleines Team kann durch automatisierte Pull-Request-Builds mehr parallele Jobs erzeugen als ein größeres Team mit manuell gestarteten Builds.

Für ein Zeitfenster gilt als einfache Planungsformel:

Grundkapazität = Aufrunden(Ankunftsrate × durchschnittliche belegte Zeit)

Diese Formel liefert nur den Startpunkt. Ergänzen Sie anschließend eine Reserve für die höchste beobachtete Last, Wartung und den tolerierten Ausfall eines Knotens. Verwenden Sie für die Kostenrechnung Variablen statt erfundener Preise:

Gesamtkosten = reservierte Knoten × gültiger Knotensatz × Abrechnungsdauer + Betriebs- und Isolationskosten

Die AWS-Dokumentation zu Reserved Capacity Fleets beschreibt die Kapazitätssemantik. Für den Budgetantrag sollten Sie daneben die Rohdaten aus Ihrer CI-Pipeline als Nachweis anhängen.

Achtung: Ein Durchschnittswert ist kein Schutz vor Stoßzeiten. Wenn Ihr Warteschlangenziel in einem festen Zeitfenster verfehlt wird, müssen Sie dieses Fenster separat dimensionieren, auch wenn die Tagesauslastung niedrig erscheint.

Tagesbetrieb und Release-Fenster verlangen unterschiedliche Reserven

Im Tagesbetrieb konkurrieren typischerweise Pull-Request-Builds, nächtliche Regressionen und manuell gestartete Validierungen. Für jeden dieser Fälle sollten Sie eine eigene Ankunftskurve erstellen. Ein nächtlicher Rückstau ist nicht gleichwertig mit einem Rückstau vor einem Produktionsrelease: Beim Release wirkt sich jede zusätzliche Wartephase auf Abnahme, Signierung und Veröffentlichung aus.

Trennen Sie zunächst vier Szenarien:

Pull-Request-Builds: viele kurze, unregelmäßige Jobs mit hoher Parallelität;
Regression: längere Jobs, oft in einem planbaren Zeitfenster;
TestFlight- beziehungsweise Beta-Release: begrenzte, aber zeitkritische Ausführung;
Produktionsrelease: strenge Berechtigungen, Signaturprüfung und Upload mit höherem Ausfallrisiko.

Für jeden Szenariotyp erfassen Sie die maximale gleichzeitige Belegung, nicht nur die tägliche Jobanzahl. Ein Job, der selten ausgeführt wird, aber einen Knoten lange blockiert, kann die Kapazitätsplanung stärker beeinflussen als viele kurze Builds.

Die AWS-Anleitung zur Projektkonfiguration ist dabei für die Zuordnung von Umgebung, Build-Spezifikation und Fleet wichtig. Sie ersetzt aber nicht Ihre historische Messung. AWS-Dokumentation beschreibt die Plattformgrenzen; nur Ihre CI-Logs zeigen, wann Ihre Teams tatsächlich Kapazität benötigen.

Für eine Entscheidung ohne Scheingenauigkeit verwenden Sie diese Bedingungen:

Wenn die Warteschlange im normalen Entwicklungsfenster wiederholt das definierte Ziel überschreitet, dann erhöhen Sie zuerst die minimale parallele Kapazität.
Wenn die Tagesauslastung hoch ist und die Last über viele Arbeitstage ähnlich bleibt, dann prüfen Sie ein dauerhaft reserviertes Fleet.
Wenn die Last nur in wenigen Release-Fenstern ansteigt, dann reservieren Sie nicht automatisch das Peak-Niveau für den gesamten Abrechnungszeitraum.
Wenn ein Release ohne zusätzliche Kapazität nicht rechtzeitig abgeschlossen werden kann, dann vergleichen Sie eine temporäre Erweiterung mit Remote Mac und dokumentieren beide Wiederherstellungswege.
Wenn die zusätzlichen Knoten außerhalb des Peak-Fensters überwiegend leer stehen, dann behandeln Sie die Leerkosten als eigenes FinOps-Risiko und nicht als unvermeidbare Infrastrukturkosten.

Das Modell sollte auch Wiederholungen enthalten. Ein instabiler Build erzeugt nicht nur mehr Rechenzeit, sondern kann die Warteschlange durch erneute Starts verdoppeln oder verlängern. Notieren Sie daher, ob ein Fehler durch Code, Abhängigkeit, Signierung, Netzwerk oder einen nicht verfügbaren Knoten verursacht wurde.

Die Entscheidungshilfe für das Kapazitätsmodell

Nutzen Sie die folgende Bedingungsliste nach dem Export Ihrer Build-Logs. Setzen Sie ein Häkchen nur, wenn die Aussage durch Messwerte, Berechtigungsnachweise oder ein dokumentiertes Wiederherstellungsziel belegt ist:

[ ] Reserviertes Fleet wählen: Die Grundlast ist über die meisten Arbeitstage stabil, die parallele Kapazität wird regelmäßig genutzt und die Warteschlange bleibt mit der Mindestkapazität innerhalb des vereinbarten Ziels.
[ ] Reserviertes Fleet erweitern: Das Warteschlangenziel wird in normalen Arbeitsfenstern wiederholt verfehlt und die zusätzliche Last tritt nicht nur an einzelnen Release-Tagen auf.
[ ] Gemischte Kapazität wählen: Die Tageslast ist planbar, aber TestFlight- oder Produktionsspitzen überschreiten die Grundkapazität deutlich und treten nur in begrenzten Zeitfenstern auf.
[ ] Remote Mac als elastische Ergänzung prüfen: Die Zusatzknoten stehen außerhalb seltener Peak-Fenster überwiegend leer, während die Jobs technisch auf einem getrennten Mac-Pfad ausgeführt werden können.
[ ] Kapazität strikt aufteilen: Produktionszertifikate, interne Abhängigkeiten, Secrets oder Compliance-Vorgaben verhindern eine gemeinsame Nutzung mit normalen Pull-Request-Builds.
[ ] Noch keine Umstellung durchführen: Der alternative Pfad wurde noch nicht mit Xcode, Signierung, Netzwerkzugriff, Artefakt-Upload und Wiederherstellung vollständig getestet.

Die Entscheidung ist erst belastbar, wenn mindestens die Kapazitätsauswahl und ihre Begründung zusammen dokumentiert werden. Ein Häkchen bei „Remote Mac prüfen“ ist kein Freigabesignal für die Produktion. Es bedeutet lediglich, dass ein PoC wirtschaftlich und technisch sinnvoll sein kann.

Gemeinsame Projekte steigern die Auslastung, aber nicht automatisch die Sicherheit

Ein gemeinsames Fleet kann die feste Kapazität besser auslasten. Das gilt besonders dann, wenn Projekt A vormittags und Projekt B am Nachmittag baut. Diese Rechnung ist jedoch nur gültig, wenn beide Projekte dieselben Sicherheits- und Bereinigungsanforderungen erfüllen.

Das Löschen des Arbeitsverzeichnisses entfernt nicht zwingend globale Zustände. Prüfen Sie mindestens:

systemweite und Benutzer-Caches;
Schlüsselbunddaten und temporäre Signaturartefakte;
installierte Tools und Laufzeitversionen;
Umgebungsvariablen und Credentials;
private Paketquellen;
lokale Logs mit Quellcode- oder Kundendaten;
wiederverwendete Artefakte aus vorherigen Builds.

Die AWS-Unterlagen zu IAM und identitätsbasierten Zugriffsrichtlinien bilden die Berechtigungsseite ab. Für die Fleet-Entscheidung benötigen Sie zusätzlich eine Projektklassifizierung. Ordnen Sie jeden Job einer Vertrauensstufe zu:

Niedriges Risiko: öffentliche Abhängigkeiten, keine Produktionsschlüssel, reproduzierbarer Build;
Mittleres Risiko: interne Pakete oder private Repositories, aber keine Produktionssignatur;
Hohes Risiko: Produktionszertifikate, App-Store-Upload, Kunden- oder Zahlungsdaten;
Sonderpool: regulierte Daten, streng getrennte Mandanten oder nicht gemeinsam nutzbare Netzwerkpfade.

Teilen Sie ein Fleet nur, wenn Berechtigungen, Abhängigkeiten und Bereinigung nachweisbar zusammenpassen. Ein gemeinsam genutzter Pool kann zwar reservierte Knoten besser auslasten, verursacht aber zusätzliche Prüfungen, Audit-Aufwand und potenziell längere Fehleranalysen. Diese Aufwände gehören in Ihr TCO-Modell.

Für Teams, die physisch oder logisch getrennte macOS-Build-Umgebungen benötigen, kann ein Vergleich von Bare-Metal- und virtualisierten macOS-Ansätzen bei der Architekturprüfung helfen. Übertragen Sie daraus jedoch keine Preise oder Verfügbarkeitsannahmen auf AWS CodeBuild.

Private Netzwerke und Produktionssignaturen bilden einen eigenen Pool

Sobald ein Build interne Dienste, private Paketquellen oder Secrets benötigt, verändert sich die Kapazitätsgrenze. Ein Fleet mit hoher Auslastung ist nicht automatisch für jeden Job geeignet. VPC-Anbindung, interne DNS-Auflösung, Firewall-Regeln und der Zugriff auf Secrets Manager müssen für den jeweiligen Build-Pool nachweisbar funktionieren.

Produktionssignaturen verschärfen die Trennung. Ein nicht vertrauenswürdiger Pull-Request-Build darf nicht nur deshalb auf einem Produktionsknoten laufen, weil dieser gerade frei ist. Die bessere Struktur besteht aus mindestens zwei logischen Kapazitätspools:

Validierungspool: Pull Requests, Test-Builds und nicht produktive Regression;
Vertrauenspool: signierte Archive, Produktions-Uploads und streng kontrollierte Release-Jobs.

Berechnen Sie für beide Pools separat:

minimale parallele Kapazität;
maximal erlaubte Warteschlange;
zulässige Wiederholung;
Wartungsfenster;
Ausfallreserve;
Zugriff auf private Netzwerke und Secrets;
Zeit für Schlüssel- oder Berechtigungsentzug.

Dokumentieren Sie, wie lange ein signierter Build tatsächlich benötigt: Archivierung, Signatur, Verifikation und Upload müssen zusammen betrachtet werden. Nur die reine Kompilierzeit zu messen, unterschätzt die belegte Fleet-Zeit.

Die AWS-Dokumentation zu verwalteten Proxy-Servern sollte geprüft werden, wenn private Abhängigkeiten oder kontrollierte ausgehende Verbindungen Teil Ihrer Architektur sind. Entscheidend ist nicht, ob ein Netzwerkpfad theoretisch existiert, sondern ob ein vollständiger Build einschließlich Paketauflösung, Signierung und Upload reproduzierbar durchläuft.

Ausfälle, Regionen und Wiederherstellung werden häufig unterschätzt

Ein einzelner Knoten kann die normale Build-Last bewältigen und trotzdem für kontinuierliche Lieferfähigkeit ungeeignet sein. Während Wartung, Fehleranalyse oder Nichtverfügbarkeit fehlt dann die gesamte Kapazität. Ein Fleet ohne Reserve muss daher mindestens gegen die eigenen Wartungs- und Ausfallanforderungen geprüft werden.

Nehmen Sie diese Zeitanteile in die Messung auf:

Start- oder Bereitstellungswartezeit;
Zeit bis zur Fehlererkennung;
Ersatz- oder Wiederanlaufzeit;
erneuter Checkout und Cache-Aufbau;
Signatur- und Upload-Wiederholung;
Freigabe eines Ersatzpfads;
Wiederherstellung nach einem regionalen Problem.

Die AWS-Übersicht zu Fleet-Regionen und Compute-Typen sowie die Liste verfügbarer Runtimes sind vor einer regionalen Kapazitätsentscheidung zu prüfen. Unterstützte Region, Runtime und macOS-Umgebung müssen zu Ihrem Build passen; aus der Existenz einer Region folgt nicht automatisch die Verfügbarkeit jeder gewünschten Konfiguration.

Ein einzelner reservierter Knoten ist nur dann vertretbar, wenn Ihr Warteschlangenziel, Ihr Release-Prozess und Ihr Wiederherstellungsziel diesen Ausfall akzeptieren. Andernfalls benötigen Sie eine zusätzliche Reserve, einen geprüften alternativen Kapazitätspfad oder eine schnell verfügbare Remote-Mac-Option.

FAQ: Kapazität, Abrechnung und elastische Erweiterung

Warum ist eine minutengenaue Abrechnung bei macOS nicht die Ausgangsbasis?

AWS CodeBuild macOS verwendet reservierte Kapazitäts-Fleets. Das bedeutet, dass die konfigurierten Knoten während der reservierten Nutzungsdauer Kosten verursachen können, auch wenn keine Builds laufen. Für Ihre Kalkulation sind deshalb nicht nur Build-Minuten relevant, sondern auch Mindestnutzung, Fleet-Größe, Region, Warteschlange und Reserve.

Wie lässt sich die Fleet-Größe belastbar berechnen?

Starten Sie mit den CI-Logs: Ankunftsrate je Zeitfenster, belegte Zeit und zulässige Wartezeit. Multiplizieren Sie Ankunftsrate und durchschnittliche Belegungszeit, runden Sie auf parallele Jobs auf und ergänzen Sie Spitzen- sowie Ausfallreserve. Validieren Sie das Ergebnis anschließend mit historischen Release-Tagen, nicht nur mit einem durchschnittlichen Arbeitstag.

Ist ein gemeinsames Fleet für mehrere iOS-Projekte sinnvoll?

Ein gemeinsames Fleet ist sinnvoll, wenn Projekte dieselben Berechtigungs- und Bereinigungsanforderungen erfüllen. Es ist nicht ausreichend, nur das Arbeitsverzeichnis zu löschen. Globale Caches, Schlüsselbunddaten, Credentials und installierte Werkzeuge können weiterhin Einfluss haben. Produktionssignaturen und sensible private Abhängigkeiten sprechen meist für einen separaten Pool.

Wie behandeln Sie seltene Release-Spitzen?

Reservieren Sie nicht dauerhaft die höchste beobachtete Spitze, wenn sie nur selten auftritt. Vergleichen Sie den zusätzlichen Knoten über die gesamte Reservierungsdauer mit einer temporären Remote-Mac-Kapazität. Der Vergleich muss echte Xcode-Builds, Signierung, Upload, Netzwerkabhängigkeiten und die Wiederherstellung nach einem Fehler enthalten.

Wann ist ein Wechsel des Kapazitätsmodells angebracht?

Ein Wechsel ist angebracht, wenn feste Knoten außerhalb der bekannten Build-Fenster wiederholt leer stehen, während das Warteschlangenziel trotzdem verfehlt wird. Ebenso relevant sind neue Projekte mit anderen Signaturanforderungen, eine geänderte Xcode-Umgebung oder eine zusätzliche Region. Eine universelle Leerlaufquote gibt es nicht; Ihre Kosten- und SLA-Grenzen entscheiden.

Entscheidung für reservierte, gemischte oder Remote-Mac-Kapazität

Für den Budgetantrag sollten Sie vier Szenarien getrennt ausweisen: stabile Tageslast, kurze Release-Spitze, gemeinsam genutzte Projekte und Ausfall- beziehungsweise Wiederherstellungskapazität. Vermischen Sie diese Szenarien nicht zu einem einzigen Durchschnittswert. Sonst erscheint ein Fleet möglicherweise günstig, obwohl die Release-Wartezeit oder die Signaturisolierung nicht erfüllt wird.

Führen Sie den PoC in diesen Schritten durch:

Exportieren Sie Build- und Warteschlangenlogs aus einem repräsentativen Zeitraum.
Gruppieren Sie die Jobs nach Tagesbetrieb, Regression, Beta- und Produktionsrelease.
Berechnen Sie Grundkapazität, Spitzenkapazität und Ausfallreserve getrennt.
Markieren Sie Jobs mit privaten Netzwerken, Secrets oder Produktionssignaturen.
Führen Sie einen vollständigen Testlauf auf dem alternativen Mac-Pfad durch.
Vergleichen Sie Kosten, Wartezeit, Bereinigungsaufwand und Wiederherstellung.
Wiederholen Sie die Rechnung bei jedem größeren Xcode-, Signatur- oder Projektwechsel.

Wenn Sie eine eigene Mac-Basis für solche Tests benötigen, können Sie die verfügbaren M4-Rechenknoten für Ihre Region prüfen. Das ist kein Beleg für AWS-CodeBuild-Preise, aber ein möglicher technischer Vergleichspunkt für einen getrennten Remote-Mac-PoC.

Prüfen Sie das Modell mindestens bei vier Auslösern neu: Wenn das Warteschlangenziel verfehlt wird, die reservierte Kapazität dauerhaft leer steht, sich die Projektisolierung ändert oder eine neue Xcode-Umgebung eingeführt wird. Zusätzlich sollte eine quartalsweise Überprüfung der AWS-Preisseite und der Fleet-Dokumentation in Ihren FinOps-Prozess aufgenommen werden.

Wenn Ihre aktuelle AWS-CodeBuild-macOS-Lösung außerhalb der Release-Fenster dauerhaft Kapazität bezahlt, ist das Problem nicht zwingend eine zu große Build-Last, sondern möglicherweise ein unpassendes Reservierungsmodell. Reservierte Knoten bleiben bei stabiler Grundlast sinnvoll, doch seltene Spitzen, getrennte Signaturpools und regionale Einschränkungen können die Rechnung kippen. MacDate eignet sich in diesem Fall als zu prüfender Remote-Mac-Pfad, sofern ein PoC Ihre Xcode-, Netzwerk-, Signatur- und Wiederherstellungsanforderungen erfüllt. Beginnen Sie mit Ihren echten Logs und entscheiden Sie erst danach, ob Sie kaufen, mischen oder bedarfsweise erweitern.