Combien de nœuds de capacité réservée macOS AWS CodeBuild ? Modèle de coûts d’entreprise 2026

La documentation AWS précise que la capacité d’une flotte réservée détermine le nombre de compilations pouvant s’exécuter en parallèle, tandis que la capacité configurée continue d’être facturée selon les règles applicables【documentation AWS sur les flottes à capacité réservée】. Si vos builds sont peu fréquents mais que la facture repose sur des nœuds maintenus disponibles, ne dimensionnez donc pas selon le nombre de développeurs : calculez le pic d’arrivées, la durée d’occupation, la file d’attente acceptable et la redondance nécessaire.

Symptôme : la moyenne de consommation paraît faible, mais les files s’allongent à chaque publication et la capacité réservée reste payée entre deux campagnes.
Solution la plus rapide : exportez un mois de journaux CI, séparez les scénarios de charge, puis choisissez entre flotte minimale réservée, capacité mixte et Mac distant élastique.

À qui cette méthode s’adresse

Ce guide concerne les responsables IT et FinOps qui doivent justifier le nombre de nœuds macOS AWS CodeBuild et le budget associé. Il s’adresse aussi aux responsables de l’efficacité développeur qui partagent une capacité entre plusieurs projets iOS tout en conservant une séparation stricte pour les signatures de production.

Vous y trouverez également une méthode pour les directeurs techniques dont la demande varie fortement entre les pull requests, les régressions nocturnes et les publications. L’objectif n’est pas de comparer les plateformes de CI, mais de décider quelle capacité votre organisation doit réellement garder disponible.

Première étape : remplacer le nombre de développeurs par une charge observable

Une équipe importante ne produit pas nécessairement une file d’attente importante. À l’inverse, un petit groupe peut déclencher une congestion si les builds arrivent dans la même fenêtre et occupent longtemps les nœuds. Le premier tableau de collecte doit donc utiliser les journaux de CI, et non l’effectif.

Relevez, pour chaque tâche :

• l’heure d’arrivée dans la file ;
• le début et la fin d’utilisation du nœud ;
• la branche et le projet concernés ;
• le type de tâche : validation de pull request, régression, archive, envoi TestFlight ou publication ;
• le nombre de relances après échec ;
• l’attente maximale acceptable pour chaque catégorie ;
• les dépendances privées, les secrets et les certificats utilisés ;
• la région et le réseau nécessaires.

La formule de base peut rester volontairement indépendante des tarifs :

charge simultanée moyenne = taux d’arrivée × durée moyenne d’occupation

Cette moyenne ne constitue pas votre capacité cible. Pour le dimensionnement, remplacez le taux moyen par le taux observé dans la fenêtre de pointe, puis ajoutez une marge issue de vos objectifs de file d’attente et de votre tolérance aux pannes :

capacité minimale du scénario = arrondi supérieur de (arrivées de pointe × durée d’occupation de pointe) + réserve de panne

Les variables doivent être calculées séparément pour les validations, les tests complets et les publications. Une archive de production ne doit pas être traitée comme une petite compilation de contrôle, même si les deux utilisent Xcode.

Pourquoi AWS CodeBuild macOS ne se paie-t-il pas simplement à la minute de compilation ?
Parce que le modèle documenté pour macOS repose sur une flotte à capacité réservée : vous configurez une capacité disponible, et cette capacité peut continuer à générer des frais pendant sa période de configuration, y compris lorsque la file est vide. Les détails de facturation, les éventuelles périodes minimales et les régions concernées doivent être vérifiés sur la page officielle de tarification AWS CodeBuild au moment de votre décision. La conséquence opérationnelle est claire : une capacité mal dimensionnée coûte pendant les creux au lieu de disparaître automatiquement.

Capacité réservée macOS AWS CodeBuild : distinguer moyenne, pointe et concurrence

La flotte doit être évaluée selon trois lectures différentes.

La première est l’occupation moyenne. Elle sert à savoir si les nœuds sont globalement utilisés. Elle ne dit pas si les développeurs attendent pendant une publication.

La deuxième est la concurrence maximale. Elle mesure combien de tâches demandent réellement un Mac au même moment. C’est cette valeur qui se rapproche le plus du nombre de nœuds nécessaires, car la capacité de la flotte définit le nombre de builds parallèles【propriétés des flottes à capacité réservée】.

La troisième est la file d’attente par criticité. Une validation de pull request peut tolérer une attente contrôlée ; une signature de production bloquée au moment d’une fenêtre commerciale ne se traite pas de la même manière. Additionner toutes les durées sans distinguer ces politiques produit une capacité théorique difficile à défendre.

Le tableau suivant sert à préparer la collecte, pas à inventer une capacité cible :

Utilisez ensuite cette règle de décision :

• Si la concurrence de pointe reste stable, que la file respecte son objectif et que l’occupation hors pointe demeure acceptable, choisissez une flotte réservée minimale.
• Si les pics se concentrent sur les publications et que les validations quotidiennes sont régulières, choisissez une flotte réservée pour le socle, puis testez une capacité Mac distante pour les campagnes ponctuelles.
• Si la file dépasse régulièrement l’objectif uniquement après des relances ou des tâches lentes, corrigez d’abord les retries, les caches et la durée d’occupation avant d’acheter un nœud supplémentaire.
• Si la charge est faible et imprévisible, revenez à une preuve de concept en capacité mixte au lieu de conserver une flotte dimensionnée pour un événement rare.
• Si un seul nœud doit être maintenu indisponible pendant une maintenance ou une panne, ajoutez une réserve de continuité ou adoptez un plan de secours documenté.

AWS précise également que l’environnement du projet, l’image et les paramètres de calcul encadrent les builds disponibles. Vérifiez les paramètres pris en charge dans la documentation de création d’un projet CodeBuild avant de conclure que plusieurs projets peuvent partager une flotte.

Attention. Une moyenne d’occupation acceptable peut masquer une congestion quotidienne. Tracez la distribution des arrivées par heure et par type de tâche ; la moyenne journalière ne suffit pas à expliquer une file apparue pendant une publication.

Deuxième étape : modéliser la publication sans acheter un pic permanent

Les tâches iOS ne se répartissent pas uniformément. Les validations de pull request alimentent le flux courant, les régressions peuvent se concentrer après une fusion, puis les archives et les téléchargements vers TestFlight ou la distribution officielle se regroupent dans une fenêtre plus sensible.

Pour cette raison, comparez trois stratégies.

Conserver des nœuds pour le pic. Cette solution réduit le risque de file lors des publications, mais vous payez la disponibilité entre les campagnes. Elle est défendable lorsque les pics sont fréquents, prévisibles et suffisamment longs pour maintenir une utilisation élevée.

Ajuster la flotte avant la campagne. Cette approche convient si la date de publication est connue et si votre processus d’approbation permet de modifier la capacité à temps. Vous devez toutefois mesurer le délai de mise à disposition, la validation du réseau, l’installation des dépendances et la réouverture des accès aux secrets.

Utiliser une capacité Mac distante pour l’extension. Cette option transforme une partie de la capacité fixe en ressource temporaire. Elle doit être validée sur un vrai pipeline : version de Xcode, certificats, accès au dépôt, dépendances privées, archivage, signature, téléversement et nettoyage.

Faut-il ajouter des nœuds réservés pour une pointe de publication ou utiliser un Mac distant ?
Ajoutez des nœuds si les pics reviennent souvent, si l’environnement doit rester dans le même périmètre réseau et si la charge est suffisamment régulière pour justifier une capacité permanente. Testez plutôt un Mac distant lorsque le pic est rare, que la capacité réservée reste vide une grande partie du temps et que le pipeline peut tolérer une étape de validation avant la campagne.

Le choix ne doit pas reposer sur une économie théorique. Comparez le coût de la capacité conservée, le coût de l’extension ponctuelle, le temps d’intégration et l’impact d’un échec de publication. Une ressource moins chère mais non validée sur la signature peut coûter davantage qu’un nœud maintenu en réserve.

Partage entre projets : meilleure utilisation, mais surface de contamination plus large

Partager une flotte entre plusieurs projets peut améliorer l’utilisation de la capacité fixe. Ce partage ne crée cependant pas automatiquement une isolation complète.

Supprimer le répertoire de travail ne suffit pas à effacer l’état global du système. Les caches, les trousseaux, les clés de signature, les outils installés, les variables d’environnement et les artefacts temporaires doivent être traités séparément. Un projet de confiance interne et une contribution externe ne doivent pas recevoir les mêmes permissions simplement parce qu’ils compilent la même application.

Plusieurs projets iOS peuvent-ils partager une même flotte Mac CodeBuild ?
Oui, mais seulement après une classification explicite. Regroupez les tâches qui partagent le même niveau de confiance, les mêmes dépendances et le même modèle de signature. Séparez les projets qui utilisent des certificats de production, des secrets sensibles ou des scripts non audités.

La politique IAM doit limiter les identités et les actions autorisées, conformément aux mécanismes décrits dans la documentation AWS sur le contrôle d’accès IAM de CodeBuild. Cette séparation doit également être vérifiée dans les journaux d’accès, et non seulement déclarée dans un fichier de configuration.

Attribuez à chaque projet une note interne selon quatre axes :

• confiance dans le code exécuté ;
• sensibilité des secrets ;
• dépendance aux caches persistants ;
• criticité de la publication.

Une flotte partagée n’est rentable que si le gain d’occupation dépasse les coûts supplémentaires de nettoyage, d’audit, de rotation des certificats et d’analyse des incidents. Si un incident sur un projet doit interrompre tous les autres, la mutualisation apparente peut dégrader votre coût réel.

Troisième étape : créer un bassin séparé pour le réseau privé et la signature

Les tâches qui atteignent des dépôts internes, des services privés ou des secrets de production doivent être évaluées comme un scénario distinct. Ne les envoyez pas automatiquement vers la flotte la plus libre.

Un projet connecté à un VPC peut dépendre d’un routage, d’un DNS privé, d’un pare-feu ou d’un proxy qui n’existe pas dans un environnement public. Les limitations du proxy géré et les conditions d’accès doivent être vérifiées dans la documentation AWS sur le proxy géré de CodeBuild avant de choisir une architecture.

Calculez au minimum deux capacités :

Bassin de validation. Il reçoit les builds ordinaires, les tests et les contrôles de pull request. Son objectif principal est une file courte et prévisible.

Bassin de confiance. Il reçoit les archives, la signature et les téléversements de production. Son objectif principal est la séparation des droits, la traçabilité et la continuité de la publication.

Pour chaque bassin, mesurez la concurrence observée, la durée d’occupation, l’attente tolérée et la réserve nécessaire lors d’une indisponibilité. Les journaux d’archivage, de signature, de téléversement et de révocation des permissions permettent de vérifier si cette séparation est réellement nécessaire ou si elle est seulement supposée.

Les régions et les types de calcul disponibles ne sont pas interchangeables. Consultez les régions et types de calcul CodeBuild documentés par AWS avant d’inscrire une capacité dans un budget. Une dépendance à une région non disponible pour votre configuration invalide le modèle, même si le nombre de nœuds paraît correct.

Quatrième étape : intégrer la panne, le démarrage et la reprise

Le temps de réussite du build ne représente pas tout le parcours. Vous devez aussi compter l’attente avant disponibilité du nœud, la récupération d’un hôte indisponible, la rotation des certificats, le rétablissement du réseau privé et la reprise d’une publication interrompue.

Un seul nœud peut convenir à un flux à faible criticité. Il ne peut pas garantir simultanément la maintenance, la panne et la livraison continue sans mécanisme de secours. La réserve de capacité doit donc être justifiée par vos historiques d’incidents et vos exercices de reprise, pas par une règle universelle.

Expérience de runbook. Si vous n’avez jamais exécuté une restauration complète depuis l’archive jusqu’au téléversement signé, vous ne connaissez pas encore le coût réel de votre redondance. Planifiez cet exercice avant de réduire la capacité au minimum théorique.

Comparez ensuite trois chemins de continuité :

• un nœud de réserve dans le même modèle de flotte ;
• une capacité alternative préparée et contrôlée périodiquement ;
• un Mac distant rapidement livré pour absorber la charge ou restaurer un pipeline.

La troisième option n’est acceptable que si vous avez validé l’accès, la version de Xcode, les certificats et les dépendances. Vous pouvez examiner les possibilités de location de nœuds Mac pour un environnement CI/CD ou comparer une méthode de tarification pour Mac mini M4, mais ces pages ne remplacent pas votre test de reprise.

Quand l’occupation justifie-t-elle un changement de modèle ?

À quel niveau d’inoccupation faut-il remplacer la capacité réservée ?
Il n’existe pas de seuil universel à appliquer sans vos tarifs, vos objectifs de file et vos coûts d’interruption. En revanche, une inoccupation persistante pendant les fenêtres où la flotte est conservée doit déclencher une comparaison. Reliez cette observation au nombre de publications, à la criticité des pipelines et au coût de l’extension temporaire.

Un taux d’occupation élevé n’est pas automatiquement une bonne nouvelle. Si les builds attendent constamment, la flotte est peut-être sous-dimensionnée. Si l’occupation augmente uniquement à cause de longues relances ou de caches défectueux, ajouter un Mac ne corrige pas la cause.

Avant toute modification, vérifiez :

• la durée médiane et la durée de pointe des builds ;
• la longueur de file par type de tâche ;
• la part des relances ;
• les périodes où les nœuds restent disponibles sans travail ;
• les incidents liés aux certificats, aux secrets ou au réseau ;
• le coût d’une capacité supplémentaire par rapport à une extension ponctuelle.

Une révision trimestrielle est adaptée à une organisation dont les projets changent régulièrement. Une modification de l’offre AWS, des régions, des types de Mac, du mode de facturation ou des conditions d’utilisation doit provoquer une vérification immédiate de votre modèle auprès des pages officielles citées plus haut. Les environnements d’exécution disponibles doivent également être contrôlés dans la liste officielle des runtimes CodeBuild.

Le modèle à présenter en comité FinOps

Préparez une feuille de calcul avec une ligne par scénario et les variables suivantes :

• taux d’arrivée de pointe ;
• durée d’occupation de pointe ;
• concurrence maximale enregistrée ;
• attente maximale autorisée ;
• taux de relance ;
• coût de la capacité réservée ;
• coût d’une extension temporaire ;
• coût administratif de l’isolation ;
• coût estimé d’une interruption ;
• réserve de panne et de maintenance.

Ne saisissez pas de montant générique pour remplacer une donnée absente. Rattachez chaque coût à la page tarifaire AWS, à votre facture ou à une mesure interne. La page officielle de tarification CodeBuild doit être relue lorsque le mode de facturation, la période minimale, les régions ou les types de Mac évoluent.

Déclenchez une nouvelle étude si l’un des événements suivants survient :

• l’objectif de file est dépassé de manière répétée ;
• l’occupation reste faible pendant les périodes où la flotte est conservée ;
• un nouveau projet demande une signature de production ;
• la chaîne réseau privée change ;
• une mise à niveau de Xcode modifie la durée d’occupation ;
• un exercice de reprise révèle qu’un seul bassin ne suffit pas.

En pratique, une charge stable et souvent occupée justifie une petite flotte réservée. Une charge avec des pics marqués mérite une architecture mixte avant tout engagement durable. Une charge peu fréquente doit être comparée à une capacité Mac distante louée selon le cycle réel des campagnes.

Conclusion : choisir selon le scénario, pas selon l’organigramme

La capacité réservée macOS AWS CodeBuild ne se déduit pas du nombre de développeurs. Elle se déduit de la concurrence de pointe, de la durée d’occupation, de la file acceptable, de l’isolation des signatures et de la continuité attendue. Exportez vos journaux, séparez validations, publications, partage et reprise, puis confrontez la capacité minimale à la facture réellement supportée.

Si votre solution actuelle conserve des nœuds inactifs, dépend d’une flotte unique pour des projets de confiance différente et absorbe mal les campagnes de publication, elle vous impose un coût fixe tout en laissant subsister un risque opérationnel. Une location de Mac auprès de MacDate peut alors servir de capacité d’appoint à valider sur vos pipelines réels, plutôt que de remplacer aveuglément votre flotte AWS.

Commencez par un test limité : rejouez un build Xcode représentatif, vérifiez la signature, le réseau privé, le nettoyage et la restauration, puis comparez la durée de location au coût de la capacité laissée vide. Si les résultats confirment un besoin ponctuel, une architecture hybride sera souvent plus défendable qu’un achat permanent dimensionné pour quelques journées de pointe.