À partir de ce mois de novembre 2024, Amazon Web Service (AWS) GameLift prend désormais en charge les conteneurs entièrement gérés. Edgegap et d'autres avaient souligné l'absence de support natif des conteneurs sur la plateforme depuis plusieurs années (selon la couverture précédente d'Edgegap). Cela permet aux développeurs d'utiliser des conteneurs, tels que ceux de Docker, pour déployer leur serveur de jeu sur l'orchestration de GameLift afin d'héberger et de faire évoluer des serveurs de jeux multijoueurs.

Analysons cela en détail et, surtout, demandons-nous si l'ajout de conteneurs est suffisant pour améliorer de manière significative l'orchestration des jeux multijoueurs et l'expérience de jeu en ligne pour les joueurs.

Qu'est-ce que les conteneurs AWS GameLift pour les jeux multijoueurs

En utilisant Amazon Elastic Container Service (ECS) intégré à l'orchestration de GameLift, les développeurs de jeux peuvent gérer les fluctuations de charge des joueurs et rationaliser le déploiement.

Cette configuration permet aux développeurs de personnaliser les environnements d'hébergement de jeux, d'automatiser la mise à l'échelle et de gérer les exigences réseau complexes indispensables aux jeux multijoueurs.

GameLift prend également en charge le Matchmaking des joueurs et la gestion des sessions, offrant des outils pour optimiser les expériences de jeu. Grâce à cette architecture basée sur des conteneurs, les développeurs bénéficient d'une flexibilité opérationnelle, se concentrant davantage sur le gameplay et moins sur l'infrastructure.

Ce qu'il faut examiner de près avec les conteneurs ECS sur GameLift pour les jeux multijoueurs

AWS GameLift prend en charge les conteneurs, mais pour les studios de jeux soucieux de réduire les coûts d'hébergement et de maximiser l'expérience des joueurs, plusieurs aspects de la configuration méritent un examen approfondi, à savoir l'allocation, la mise à l'échelle, la distribution dans les régions, le Matchmaking et la complexité de l'intégration.

Allocation

L'allocation fait référence à l'espace occupé par les serveurs de jeux sur la machine virtuelle (VM). Bien qu'AWS documente l'allocation de vCPU et de mémoire par groupe de conteneurs, l'effort d'intégration important requis de la part des studios de jeux signifie qu'il peut toujours être difficile d'optimiser le « remplissage » de votre serveur de jeu sur les machines virtuelles et de maximiser votre utilisation par vCPU en pratique.

Cette complexité souvent négligée signifie que les studios peuvent se retrouver à payer pour de la capacité inutilisée, en plus des coûts DevOps supplémentaires liés à la gestion du remplissage (backfilling).

L'architecture de GameLift nécessite également le préchauffage des machines virtuelles afin que les conteneurs soient prêts à être lancés, ce qui signifie qu'une partie de la capacité du parc (fleet) doit être conservée en réserve comme tampon à tout moment. Si ce tampon est configuré trop bas, cela risque d'entraîner des retards de mise à l'échelle prolongés qui peuvent affecter l'expérience des joueurs. À noter : selon l'analyse des tarifs de GameLift par Edgegap, le tampon par défaut de GameLift a été documenté à 10 % (veuillez vérifier auprès de la documentation actuelle d'AWS GameLift avant de publier, car les valeurs par défaut peuvent changer), ce que certains studios trouvent inférieur à ce dont ils ont besoin pour une demande de joueurs variable ou instable. Les studios ayant un trafic irrégulier augmentent souvent cette valeur, ce qui accroît le coût réel de fonctionnement de leur parc. Vous pouvez utiliser le calculateur d'Edgegap pour comparer l'impact des choix de capacité tampon sur les coûts d'hébergement globaux selon différents scénarios de trafic.

Si les serveurs se retrouvent en surcapacité en raison de tampons mal configurés, les joueurs peuvent subir de la latence et des pertes de trames (dropped frames), ce qui peut nuire à la valeur que les studios attendent de l'orchestration de serveurs dédiés.

Chez Edgegap, nous nous efforçons de donner aux développeurs de jeux la possibilité d'optimiser leur serveur de jeu et de fractionner leur utilisation de vCPU afin de réduire leurs coûts globaux.

Mise à l'échelle (Scaling)

La documentation de GameLift couvre la mise à l'échelle des parcs de conteneurs, y compris l'auto-scaling basé sur des cibles via la console ou le SDK. Cependant, plusieurs questions pratiques restent peu documentées pour les studios qui cherchent à optimiser le comportement de mise à l'échelle des parcs de conteneurs, en particulier sur la manière dont la mise à l'échelle interagit avec le préchauffage des conteneurs au niveau de l'instance.

Si les conteneurs sont pré-lancés sur des instances, comment GameLift détermine-t-il quand effectuer la mise à l'échelle, puisque les conteneurs consomment déjà des ressources d'instance ? Si les conteneurs sont déployés à la volée, quelle est la rapidité réelle de ce processus (mise à l'échelle verticale) et comment se comporte-t-il sur plusieurs régions simultanément (mise à l'échelle horizontale) ?

Edgegap propose un déploiement de conteneurs à la volée qui, selon le test de performance 2023 d'Edgegap, a soutenu jusqu'à 40 déploiements de serveurs de jeux sur 60 minutes lors de ce test (au moment de la rédaction). AWS est l'un des fournisseurs d'Edgegap, et Edgegap s'appuie également sur 16 fournisseurs (au moment de la rédaction) pour mettre à l'échelle votre jeu verticalement à l'endroit requis.

De plus, selon les propres mesures d'Edgegap, le déploiement de serveurs à « démarrage à froid » d'Edgegap a duré en moyenne environ 3 secondes (au moment de la rédaction), ce qui signifie plus de temps de jeu et moins d'attente pour le déploiement des serveurs de jeux. Cela se compare avantageusement aux durées de démarrage à froid plus longues généralement signalées par les développeurs utilisant d'autres plateformes.

Edgegap déploie également votre serveur de jeu dans ses plus de 615 emplacements à travers le monde à la demande (au moment de la rédaction). Bien qu'il soit utile de faire de la mise à l'échelle dans AWS US East pour les joueurs de la côte est des États-Unis, l'hébergement de jeux doit généralement être mis à l'échelle à la hausse et à la baisse partout dans le monde pour offrir une bonne expérience de jeu en ligne aux joueurs du monde entier.

Distribution dans les régions

Le cloud public, y compris AWS GameLift, utilise un modèle de facturation par instance avec auto-scaling : vous payez pour des machines virtuelles complètes par région, que des serveurs de jeux y soient activement exécutés ou non.

De nombreux studios AA et triple-I constatent qu'ils ont besoin d'environ 10 régions pour maintenir une latence suffisamment basse pour offrir une bonne expérience à l'ensemble de leur base de joueurs. Chaque région dans laquelle vous souhaitez être présent constitue un parc distinct par région que vous devez provisionner et payer.

Le facteur de coût structurel ici n'est pas la bande passante (voir la note à la fin de cet article sur le changement de tarification de la bande passante d'AWS en juin 2026), mais l'arrondi à l'instance complète sur l'ensemble des parcs par région. Comme GameLift facture par instance plutôt que par joueur ou par session, un parc desservant une poignée de sessions paie toujours pour l'instance complète, et les petites régions conservent un minimum d'une VM quelle que soit la demande. Sur une empreinte multirégionale, cette capacité réservée par région peut multiplier les dépenses d'hébergement bien au-delà du coût brut des sessions réellement jouées. La page des tarifs d'Edgegap propose une comparaison directe.

Pour donner des chiffres approximatifs, Edgegap a modélisé une comparaison pour un jeu de type extraction shooter représentatif ayant un pic d'utilisateurs simultanés de l'ordre de quelques milliers, répartis sur environ 10 régions sur des instances de génération 6 (c6i.4xlarge). Dans la modélisation d'Edgegap, le coût du paiement à l'utilisation s'élevait à environ 20 600 $ par mois, contre un coût modélisé pour AWS GameLift gen6 d'environ 27 600 $ pour le même scénario, soit une différence estimée par Edgegap d'environ 34 %. Ces chiffres AWS sont modélisés par Edgegap à l'aide des tarifs par instance publiés par AWS, et non des chiffres facturés par AWS, et sont donnés à titre illustratif : les factures réelles d'AWS varient en fonction du choix des instances, des plans d'épargne (Savings Plans) ou des instances Spot, et de l'arrondi par région. Le principal facteur de coût modélisé du côté d'AWS est l'arrondi à l'instance complète sur l'ensemble des parcs par région, plutôt que le transfert réseau.

Les nouveaux services d'orchestration pour l'hébergement de serveurs de jeux, comme Edgegap, utilisent plutôt le paiement à l'utilisation. Cela signifie que vous ne payez que lorsque vos joueurs jouent (pendant un déploiement) dans le monde entier. Cela représente un changement important par rapport au modèle de tarification à capacité réservée requis par l'orchestration de cloud public traditionnelle.

De plus, comme Edgegap s'appuie sur un vaste réseau edge, Edgegap a mesuré une réduction moyenne de latence de 58 % dans cette étude de cas (au moment de la rédaction) par rapport à une configuration d'orchestration de cloud public traditionnelle.

Utilisation avec le Matchmaking / Salons (Lobbies)

Un autre élément à prendre en compte est que votre outil de Matchmaking ou votre salon doit choisir le meilleur emplacement. Vous devrez créer des régions dans votre système de Matchmaking, et plus vous essaierez de réduire la latence (en ajoutant des régions dans AWS), plus le temps d'attente de votre file de Matchmaking pourra être long, car vous ne pourrez pas effectuer de parties inter-régions aussi facilement.

Le système de Matchmaking d'Edgegap est l'un des seuls outils de Matchmaking dotés de paramètres natifs basés sur la latence par défaut (au moment de la rédaction), ce qui vous aide à déployer des serveurs de jeux avec la latence la plus faible pour vos joueurs.

Facilité d'intégration et d'utilisation

La propre documentation d'intégration d'AWS pour cette configuration s'étend sur plusieurs guides couvrant la configuration d'ECS, ECR, CodeBuild et CloudFormation, ce qui reflète la réelle complexité liée à la mise en place d'un parc de conteneurs prêt pour la production.

Tout configurer est en soi une entreprise de grande envergure, et une fois le travail d'intégration terminé, ce n'est que le début. Vous aurez généralement besoin d'au moins un ingénieur ou d'un professionnel DevOps pour surveiller et gérer les fluctuations de votre trafic.

L'approche « juste à temps » des serveurs de jeux, qui permet de charger des données pour être entièrement personnalisées comme le contenu généré par les utilisateurs (UGC), contourne une grande partie de cette complexité. Par exemple, Six Days in Fallujah charge sa carte générée de manière procédurale pendant le déploiement du serveur de jeu, tout comme HIBERWORLD pour ses nombreux types de jeux et cartes développés via l'UGC.

Les conteneurs sont-ils suffisants pour AWS GameLift ?

Pour les jeux utilisant actuellement GameLift et souhaitant passer aux conteneurs pour un flux de travail plus rationalisé, cela peut s'avérer suffisant pour leur situation.

Si vous recherchez une solution plus flexible vous permettant de tirer parti de centaines d'emplacements dans un modèle juste-à-temps et de paiement à l'utilisation, sans avoir à gérer l'infrastructure vous-même, il vaut la peine de s'intéresser à la nouvelle génération de services d'orchestration de serveurs de jeux, notamment Edgegap.

Une remarque sur le changement de bande passante réseau d'AWS GameLift en juin 2026

Une mise à jour tarifaire importante à prendre en compte lors de la lecture de toute comparaison de coûts : à compter de la mise à jour d'AWS du 15 juin 2026, la bande passante réseau sortante est incluse sans frais supplémentaires sur les instances Amazon GameLift de génération 6 ou plus récente (les familles d'instances c6, m6, c7 et m7), dans toutes les régions à l'exception de la Chine. Cela s'applique à Windows et Linux, Spot et On-Demand, sans aucun engagement requis. L'exemple publié par AWS montre une réduction d'environ 34 % du coût total pour 1 000 joueurs simultanés sur un parc de génération 6 une fois la bande passante retirée de la facture.

Quelques points à clarifier pour plus de précision. Cela s'applique uniquement aux familles de génération 6 et plus récentes ; les familles plus anciennes telles que la série C5 de génération 5 ne sont pas incluses, de sorte que les studios utilisant des types d'instances plus anciens encourent toujours des frais de bande passante. En raison de ce changement, les comparaisons de coûts par rapport aux parcs GameLift de génération 6 ne doivent pas traiter la bande passante réseau comme faisant partie de la facture AWS. Le facteur de coût pertinent pour les parcs de génération 6 est la capacité d'instance réservée par région et l'arrondi à l'instance complète, et non le trafic sortant (egress). Pour les détails actuels, consultez directement l'annonce d'AWS et la page des tarifs de GameLift. Il s'agit d'un élément sensible au facteur temps ; nous recommandons un réexamen périodique à mesure que les tarifs d'AWS évoluent.