Une société de services d'une quinzaine de personnes nous contacte parce que son application client ne démarre plus après une coupure. L'application tourne chez AWS depuis quatre ans. Le développeur qui avait tout mis en place est parti depuis deux ans, le compte a été créé avec son adresse personnelle, la carte bancaire enregistrée est celle du gérant, et personne ne sait quelles machines composent réellement la plateforme. Le service finit par redémarrer, mais l'entreprise découvre ce jour-là qu'elle ne possédait pas son propre environnement.
Ce cas se répète, et il n'a rien à voir avec la qualité d'AWS. Il vient du fait que l'on commence presque toujours par le service métier, en remettant à plus tard le compte, les droits et les sauvegardes. Cet article décrit ce qu'AWS représente concrètement pour une PME, dans quels cas il se justifie, et ce que nous mettons en place avant de démarrer le premier serveur. Le choix entre les grands fournisseurs fait l'objet d'un article distinct sur les critères qui décident pour une PME.
Ce qu'AWS est réellement : des briques d'infrastructure facturées à l'usage
AWS est un catalogue de services d'infrastructure que vous assemblez vous-même. Les machines virtuelles s'appellent EC2, le stockage d'objets s'appelle S3, le réseau privé dans lequel vos machines sont isolées s'appelle VPC, et la gestion des droits s'appelle IAM. Vous ne louez pas un serveur au mois avec un panneau de configuration : vous consommez des ressources à la seconde ou au gigaoctet, et la facture reflète exactement ce que vous avez laissé allumé.
Cette structure de coût a deux conséquences opposées. Du bon côté, vous n'achetez plus une machine surdimensionnée pour cinq ans : vous ajustez la taille quand la charge change, et un environnement de test peut être détruit le vendredi soir. Du mauvais côté, rien ne s'arrête tout seul. Un disque détaché d'une machine supprimée continue d'être facturé, une adresse réservée sans usage continue d'être facturée, une base de données de recette oubliée continue d'être facturée pendant des mois. Nous décrivons cette mécanique et la façon de la reprendre en main dans notre article sur la facture cloud qui augmente.
AWS n'est pas non plus un hébergement de site. Installer un WordPress vitrine sur une instance EC2 revient à devenir son propre hébergeur : correctifs du système, serveur web, sauvegardes, certificat, supervision. Pour un site de présentation, un hébergement mutualisé chez un professionnel coûte moins cher et sera mieux tenu. De la même manière, un parc de huit postes et une imprimante relèvent de l'infogérance à partir de 120 HT / mois : aucun compte cloud ne remplace un contrat de support pour les utilisateurs.
Les situations où AWS se justifie chez une PME
Le premier cas est celui d'une application métier déjà développée pour AWS, par une équipe interne ou un prestataire qui connaît la plateforme. Les scripts de déploiement, les droits et les sauvegardes existent déjà dans ce vocabulaire, et changer de fournisseur reviendrait à tout réécrire pour un bénéfice incertain.
Le deuxième cas est celui d'un besoin précis auquel un service AWS répond bien : un volume important de fichiers à conserver dans S3, une file de messages entre deux applications, une base de données managée que vous ne voulez plus administrer vous-même. Le besoin est écrit, mesurable, et il commande le choix.
Le troisième cas est celui d'une application dont la charge varie fortement, par exemple une plateforme utilisée intensément quelques jours par mois. La facturation à l'usage devient alors un avantage réel, à condition que l'application sache effectivement réduire sa consommation en dehors des pointes.
En revanche, AWS ne se justifie pas parce que l'écosystème est réputé, ni parce qu'un article évoquait les fonctions sans serveur. Nous voyons régulièrement des architectures découpées en dizaines de petites fonctions dans des entreprises qui n'ont personne pour les suivre. Une machine virtuelle unique, correctement sauvegardée et documentée, rend souvent un meilleur service qu'une architecture élégante que personne ne sait dépanner.
Les fondations que nous posons avant le premier serveur
Nous commençons systématiquement par cinq points, avant tout service métier.
- Le compte est ouvert au nom de l'entreprise, avec une adresse de messagerie appartenant à l'entreprise et un moyen de paiement professionnel. Le compte racine est protégé par une double authentification et ne sert plus à l'usage quotidien, sujet que nous traitons dans notre article sur le compte root d'un environnement cloud.
- Les accès sont nominatifs et passent par des rôles IAM, avec des permissions limitées à ce que chaque personne doit faire. Nous supprimons les clés d'accès permanentes qui circulent dans les fichiers de configuration, car ce sont elles que l'on retrouve un jour dans un dépôt Git accessible publiquement.
- Le réseau est fermé par défaut. Aucun accès d'administration en SSH ou en bureau à distance n'est ouvert à Internet entier : l'administration passe par un point d'entrée contrôlé ou un tunnel, et les règles de filtrage sont documentées. Nous expliquons pourquoi dans notre article sur le bureau à distance exposé sur Internet.
- Les sauvegardes sont conservées en dehors du périmètre qui peut être compromis, avec une conservation qui résiste à une suppression accidentelle ou volontaire. Un bucket S3 versionné est utile, mais il ne constitue pas une sauvegarde à lui seul, comme nous le détaillons dans notre article expliquant que S3 n'est pas une sauvegarde.
- Chaque ressource porte des étiquettes de coût indiquant le projet et l'environnement, et une alerte de budget est active dès le premier mois. Sans cela, vous découvrirez une dérive au moment de la facture, c'est-à-dire trop tard pour comprendre ce qui l'a provoquée.
Le choix de la région se traite au moment du projet
La région détermine où vos données résident physiquement et influence la structure de votre facture, puisque les tarifs ne sont pas identiques partout. Si un contrat client vous impose une localisation, cette exigence doit être écrite avant l'architecture, et la disponibilité de la région comme celle des services que vous comptez y utiliser se vérifient dans la documentation du fournisseur au moment du projet : tous les services ne sont pas ouverts dans toutes les régions, et les catalogues évoluent. Nous développons ce raisonnement dans notre article sur le choix d'une région cloud. La qualification juridique de votre obligation, elle, relève d'un conseil spécialisé.
Notre déroulé sur une mission AWS
Nous commençons par un cadrage court : quelle application, quel volume, quelles contraintes écrites, qui exploitera la plateforme ensuite. Si un environnement existe déjà, nous demandons un accès en lecture et nous produisons un inventaire réel des ressources allumées, ce qui suffit souvent à identifier les premières économies.
Nous posons ensuite les fondations décrites plus haut, puis nous migrons un seul workload, avec une procédure de retour arrière prévue et testée. Nous décrivons l'infrastructure dans des fichiers plutôt que dans des clics, méthode que nous expliquons dans notre article sur Terraform et Ansible, afin que la plateforme soit reproductible et lisible. Nous documentons enfin les droits, les sauvegardes et les procédures, puis nous proposons soit une maintenance cloud régulière, soit un transfert de compétences vers votre équipe.
Nos missions AWS se facturent 1000 HT / jour, à distance, pour des clients de toute la France et de Suisse, avec le même montant hors taxes en euros et en francs. L'infogérance des postes de travail, elle, reste un contrat de proximité dans le Bassin Genevois.
Si votre environnement AWS repose aujourd'hui sur la carte bancaire du gérant et sur une instance dont plus personne ne connaît le rôle, envoyez-nous vos factures et vos accès en lecture. Le sujet n'est presque jamais de consommer davantage de cloud : il s'agit d'identifier un propriétaire, de reprendre les droits et de disposer d'un moyen d'arrêter ce qui ne sert plus.