Cloud infogéré ou AWS pour une PME : un cadre de décision

Pour une petite ou moyenne entreprise (PME), AWS est le bon choix quand la charge de travail dépend de services propres à AWS ou exige de nombreuses régions. AWS est aussi le bon choix quand des ingénieurs sont responsables du compte au quotidien. Un fournisseur de cloud infogéré convient mieux quand la charge est une pile applicative classique et que personne dans l’entreprise n’est responsable de l’exploitation. Les deux options ne s’excluent pas, car une entreprise peut rester sur AWS et payer un fournisseur pour opérer le compte. La décision repose sur ce que la charge de travail utilise et sur qui répond de son exploitation.

Quelle est la différence entre le cloud infogéré et AWS ?

Amazon Web Services (AWS) est un cloud public à très grande échelle, qu’on appelle aussi un hyperscaler. AWS vend de la capacité en libre-service et un vaste catalogue de services, facturés à l’usage. AWS fonctionne selon un modèle de responsabilité partagée. AWS sécurise et exploite les installations, le matériel et les plateformes de service. Le client, lui, configure, surveille, sauvegarde et sécurise tout ce qu’il bâtit par-dessus, et il y applique les correctifs.

Le cloud infogéré est un modèle de service où le fournisseur apporte l’infrastructure et les personnes qui l’opèrent. Le fournisseur s’occupe du provisionnement, des correctifs, du durcissement, des sauvegardes, de la surveillance et de la réponse aux incidents. Il le fait selon un périmètre écrit et un accord de niveau de service (SLA). Le client conserve son application, son code et ses décisions sur les données.

Les services AWS infogérés forment un troisième modèle : un fournisseur opère un compte AWS dont le client reste propriétaire et qu’il continue de payer.

Pour une PME, la comparaison contient donc deux questions distinctes : où la charge de travail devrait tourner, et qui devrait l’opérer.

Comment le cloud infogéré et AWS se comparent-ils pour une PME ?

Le tableau compare trois modèles d’exploitation selon les critères qui tranchent habituellement la question.

La première colonne suppose des compétences à l’interne. La troisième colonne suppose que la charge de travail n’a besoin de rien que seul un hyperscaler offre.

Quand AWS est-il le bon choix pour une PME ?

AWS est le bon choix quand la charge de travail tire de la valeur de ce qui est propre à AWS. Quatre conditions indiquent qu’il vaut mieux rester.

1. L’architecture repose sur des services propres à AWS. Les fonctions sans serveur (serverless), les flux d’événements infogérés, les tables de base de données globales et les services d’apprentissage automatique n’ont pas d’équivalent direct sur une plateforme d’infrastructure générique. Les remplacer oblige à refaire l’ingénierie de l’application.
2. L’entreprise a besoin d’une présence mondiale. Des clients sur plusieurs continents, ou une conception active dans plusieurs régions à la fois, demandent un fournisseur qui a de nombreuses régions.
3. La charge varie fortement et de façon imprévisible. Une charge qui fluctue beaucoup en quelques heures profite de la facturation à l’usage et d’une mise à l’échelle automatisée éprouvée.
4. Une équipe est responsable de la plateforme. Des ingénieurs qui gèrent la production sous forme de code, lisent la facture ligne par ligne et assurent la garde ont déjà ce que vend un fournisseur de cloud infogéré.

La taille seule n’est pas une raison de quitter AWS. AWS peut très bien convenir à une entreprise de 20 personnes dont le produit repose d’abord sur des services sans serveur.

Quand AWS est-il le mauvais choix pour une PME ?

AWS convient mal à une PME quand la charge de travail utilise peu de ce qui est propre à AWS et que l’entreprise assume un travail d’exploitation pour lequel elle n’a pas le personnel. Quatre signes vont dans ce sens.

• La charge est une pile classique : un groupe de machines virtuelles, une base de données relationnelle, un cache et un réseau de diffusion de contenu (CDN).
• Personne à l’interne n’a lu la facture ligne par ligne depuis un an, et personne ne peut expliquer les frais les plus élevés.
• La personne qui a monté le compte est partie, et les accès, l’étiquetage et la surveillance ont dérivé depuis.
• Des sauvegardes existent, mais aucune restauration n’a jamais été testée.

Les trois derniers signes décrivent un problème de responsabilité, qui peut se régler sur AWS. Seul le premier signe décrit une plateforme mal adaptée. La base de connaissances énumère les signes qu’un environnement AWS a dépassé l’équipe.

Quand un fournisseur de cloud infogéré n’est-il pas le bon choix ?

Un fournisseur de cloud infogéré est le mauvais choix dans six situations.

• La charge dépend de services exclusifs à AWS. Une plateforme régionale de cloud infogéré ne les offrira pas, et les rebâtir est rarement rentable.
• L’entreprise a besoin de régions que le fournisseur n’a pas. Un fournisseur qui a deux sites dans un seul pays ne peut pas servir localement des utilisateurs en Europe ou en Asie.
• L’exploitation est le produit. Une entreprise dont le produit est l’infrastructure devrait garder cette compétence à l’interne. Un autre article aide à décider s’il faut embaucher un ingénieur DevOps ou impartir les opérations.
• L’empreinte est minuscule. Une instance et un compartiment de stockage ne justifient pas un contrat d’exploitation infogérée.
• Des ingénieurs sont déjà responsables de l’exploitation et s’en acquittent bien. Ajouter un fournisseur divise la responsabilité, à moins que le partage du périmètre soit explicite.
• Les incidents viennent de défauts de l’application. Ni une nouvelle plateforme ni un fournisseur de cloud infogéré ne corrigent les bogues applicatifs.

Lequel coûte le moins cher à exploiter : le cloud infogéré ou AWS ?

Ni le cloud infogéré ni AWS n’est moins cher de façon générale. Le résultat dépend de la charge de travail et du travail d’exploitation que l’entreprise absorbe aujourd’hui sans le compter. Une comparaison valable utilise les mêmes postes de coût des deux côtés.

Trois facteurs pèsent le plus du côté d’AWS. Le premier, ce sont les ressources inactives et surdimensionnées, qui s’accumulent quand personne n’est responsable du compte. Le deuxième est le transfert de données, expliqué dans le guide sur les coûts de transfert de données AWS. Le troisième est la main-d’œuvre. La page de cadrage de Stack Harbor évalue une rotation interne 24/7 à six équivalents temps plein et plus, une fois les vacances, la maladie et l’épuisement couverts.

Avant de comparer, exportez douze mois de factures et regroupez les frais par service. Estimez les heures d’ingénieur consacrées chaque mois aux correctifs, aux incidents et aux questions de coûts. Divisez le coût mensuel total par le nombre de clients actifs, à l’aide du guide sur le coût par client d’un logiciel-service (SaaS). Le calculateur de coûts cloud donne une estimation repère du gaspillage probable, pas une mesure de la vraie facture. L’article sur ce que devrait coûter l’hébergement cloud infogéré explique les facteurs derrière un devis de cloud infogéré.

Une entreprise devrait-elle quitter AWS pour réduire ses coûts ?

Une entreprise devrait décider de quitter AWS seulement après un audit de la facture et de l’architecture. Le guide sur ce qu’un vrai audit de coûts AWS couvre en décrit le périmètre. L’audit mène habituellement à l’une des trois voies suivantes.

1. Rester sur AWS et faire opérer le compte. L’architecture est saine et il manque un responsable. Dans un mandat auprès d’un SaaS en techno juridique, le client est resté sur AWS. Le travail a porté sur les runbooks, le ménage des alertes et la couverture de garde.
2. Faire la remédiation sur AWS. La plateforme convient et le compte traîne du gaspillage. La base de connaissances classe les mesures habituelles dans les 12 leviers qui réduisent une facture AWS.
3. Réarchitecturer sur une plateforme de cloud infogéré. La charge n’utilise pas de services propres à AWS, et une topologie plus simple lui suffirait.

Un scénario type compare la deuxième et la troisième voie. Un SaaS analytique canadien avait un compte AWS dont personne n’était responsable depuis 2023. Une vente était aussi bloquée par l’exigence de garder les données de production au Canada. La proposition comprenait un chemin de remédiation sur AWS, avec une baisse de la facture estimée à 28 % sans quitter la plateforme. Le client a plutôt choisi une reconstruction réarchitecturée de douze semaines. Dans ce seul scénario type, le scénario type d’AWS vers le cloud infogéré rapporte un taux mensuel d’infrastructure en baisse de 54 %. Ce chiffre comprend les sauvegardes, la supervision, le plan du CDN et les frais d’opération. C’est le résultat d’une seule charge de travail, pas une économie typique.

Le même scénario type affirme qu’AWS est la bonne réponse pour beaucoup de charges. Elle précise que quitter AWS coûtera de la réingénierie à une équipe dont l’architecture repose sur des services propres à AWS. Elle déconseille aussi le « lift-and-shift », qui copie chaque serveur chez un autre fournisseur et transporte l’ancienne architecture avec lui.

Un cadre de décision : six questions à trancher avant de choisir

1. Quels services AWS l’application appelle-t-elle directement ? Si la liste se limite à des machines virtuelles, une base de données infogérée, un cache, du stockage objet et un CDN, la charge est probablement portable. Si des services exclusifs à AWS sont au cœur de l’application, prévoyez de rester.
2. Qui est responsable du compte aujourd’hui ? Nommez la personne qui lit la facture, révise les accès et répond aux alertes. S’il n’y a pas de nom, réglez d’abord la question de la responsabilité.
3. Où les données de production, les sauvegardes et les journaux doivent-ils résider ? Mettez l’exigence par écrit. L’article sur la résidence des données au Canada et ce qu’il faut exiger d’un hébergeur dresse la liste des éléments à obtenir par écrit.
4. À quoi ressemble la charge sur une année ? Une charge stable convient à un environnement défini avec des frais récurrents. Des variations brusques et imprévisibles conviennent à la facturation à l’usage.
5. Quel est le coût mensuel complet aujourd’hui, main-d’œuvre comprise ? Utilisez les postes de coût du tableau de la section sur les coûts.
6. Que coûterait un changement, et que coûte le statu quo ? Comptez l’ingénierie de migration et l’exploitation en parallèle d’un côté. Comptez le gaspillage récurrent et le risque que personne n’assume de l’autre.

Si les questions 1 et 2 mènent toutes deux à AWS, restez et continuez d’opérer le compte vous-même. Si la question 1 mène à AWS et que la question 2 reste sans réponse, restez et faites opérer le compte. Si la question 1 révèle une charge portable et que les questions 3, 4 et 5 favorisent un environnement défini, demandez une proposition de cloud infogéré en même temps qu’une estimation de remédiation. Les critères présentés dans l’article sur ce qu’il faut rechercher chez un fournisseur d’hébergement infogéré s’appliquent aux deux propositions.

Où se situe Stack Harbor

Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) de propriété canadienne, dont le siège est à Montréal. Stack Harbor opère des environnements cloud de production et ne fait pas de TI de bureau. L’entreprise sert des PME et des agences d’environ 5 à 200 personnes qui opèrent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7.

Pour une entreprise qui reste sur AWS, le service d’opérations AWS infogérées couvre les deux premières voies. Son périmètre publié comprend l’optimisation de taille des ressources, le nettoyage des ressources inactives, le ménage des accès, la couverture de supervision et un exercice de restauration testé. Stack Harbor travaille au moyen d’un rôle dédié de gestion des identités et des accès (IAM), et le compte racine (root) reste chez le client. L’hébergement chez Stack Harbor n’est pas requis. Stack Harbor ne promet pas de pourcentage d’économies forfaitaire, parce que le chiffre dépend de la charge de travail.

Pour la troisième voie, Stack Harbor exploite sa propre infrastructure canadienne dans deux centres de données à Montréal. Cloud Compute fournit des machines virtuelles et du bare metal. Cloud PaaS est une plateforme applicative infogérée, avec des bases de données infogérées et de l’autoscaling. Une charge de travail placée dans ces centres de données reste au Canada, et le placement est documenté. Stack Harbor ne détient aucun rapport SOC 2 en son nom, et la page Confiance et sécurité expose sa position en matière de conformité.

Les limites sont publiées elles aussi. Sur Cloud Compute, la bascule régionale est une opération infogérée, pas automatique. La mise à l’échelle horizontale sur Cloud Compute est une opération planifiée, et la mise à l’échelle automatisée se trouve sur Cloud PaaS. La plateforme de Stack Harbor n’est pas AWS, donc les services exclusifs à AWS n’y sont pas offerts. L’accord de niveau de service engage Stack Harbor à 99,9 % de disponibilité mensuelle, avec un crédit de service comme recours. Cet engagement vise le réseau de Stack Harbor et son infrastructure en tant que service (IaaS). Il ne s’étend pas à un environnement hébergé sur AWS.

Stack Harbor ne publie pas de prix. Un devis fixe pour un périmètre écrit suit une évaluation, comme le décrit la page Comment nous cadrons les mandats. Un déménagement vers sa plateforme passe par les services de migration, où la découverte est un mandat de cadrage court et payant.

Le choix entre AWS, AWS opéré par un fournisseur et une plateforme de cloud infogéré repose sur deux faits qu’une entreprise peut établir elle-même : ce que la charge de travail utilise, et qui répond de son exploitation.