Architecture, déploiement et gestion AWS
Conseil, déploiement et exploitation de vos infrastructures Amazon Web Services.
Un compte AWS que l'entreprise ne possède pas vraiment
L'application ne redémarre pas après une coupure. Elle 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 la plateforme. Le service finit par revenir, mais l'entreprise découvre ce jour-là qu'elle ne possédait pas son environnement. Ce cas n'a rien à voir avec la qualité de la plateforme : il vient de l'ordre dans lequel les choses ont été faites.
Le second symptôme est financier et tout aussi révélateur. AWS facture à la seconde ou au gigaoctet, et rien ne s'arrête tout seul. Un volume 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 recette oubliée continue d'être facturée pendant des mois. Sans étiquette de projet ni alerte de budget, la dérive se découvre au moment du relevé, trop tard pour savoir quelle décision l'a provoquée et qui l'avait prise.
Ce que nous posons avant de démarrer le premier serveur
Nous commençons par les fondations du compte, avant tout service métier. Le compte est ouvert au nom de l'entreprise, avec une adresse de messagerie qui lui appartient et un moyen de paiement professionnel. Le compte racine reçoit une double authentification et cesse de servir à l'usage quotidien. Les accès deviennent nominatifs et passent par des rôles IAM aux permissions limitées, ce qui nous conduit à supprimer les clés permanentes qui circulent dans les fichiers de configuration et que l'on retrouve un jour dans un dépôt de code accessible.
Nous fermons ensuite le réseau par défaut : aucun accès d'administration en SSH ou en bureau à distance n'est publié sur Internet, l'administration passe par un point d'entrée contrôlé, et les règles de filtrage sont écrites et relues. Les sauvegardes sont conservées hors de portée d'un compte compromis, avec une conservation qui résiste à une suppression volontaire. Chaque ressource porte enfin des étiquettes de projet et d'environnement, et une alerte de budget est active dès le premier mois. Le service métier vient après, jamais avant.
Ce que couvre une mission AWS
- Nous remettons le compte au nom de l'entreprise, protégeons le compte racine et sortons son usage du quotidien.
- Nous construisons les rôles et permissions IAM par personne et par application, puis nous retirons les clés permanentes existantes.
- Nous posons un réseau privé fermé par défaut, avec un accès d'administration contrôlé et des règles de filtrage documentées.
- Nous mettons les sauvegardes hors de portée d'un compte compromis et nous vérifions une restauration réelle avant de les valider.
- Nous étiquetons chaque ressource par projet et par environnement, et nous activons des alertes de budget dès le premier mois.
- Nous décrivons le socle dans des fichiers versionnés, en important l'existant plutôt qu'en recréant une plateforme en parallèle.
- Nous documentons les droits, les procédures de redémarrage et les sauvegardes, puis nous formons votre équipe ou assurons le run.
Ce qui décide vraiment de la solidité d'un compte AWS
IAM avant tout le reste
Des rôles nominatifs aux permissions restreintes remplacent les clés permanentes partagées entre applications et personnes. C'est la mesure qui empêche qu'un fichier de configuration égaré donne accès à toute la plateforme.
Un VPC fermé par défaut
Les machines vivent dans un réseau privé, et l'administration passe par un point d'entrée contrôlé plutôt que par un port publié. Une adresse publique de fournisseur n'améliore en rien un bureau à distance ouvert sur Internet.
Des étiquettes posées dès la première ressource
Sans marquage de projet et d'environnement, une dépense n'a pas de propriétaire et ne peut donc pas être remise en cause. L'étiquetage est la mesure la moins visible et la plus rentable d'un compte.
IAM, VPC et sauvegardes avant les services à la mode
Nous posons le compte, les droits et le réseau, puis seulement les services métier. EKS, Lambda ou EC2 : le choix suit le besoin, pas le catalogue AWS de l'année.
Outils et délai
Fondations compte 1 à 2 semaines, puis les workloads.
Les services AWS que nous utilisons, et l'ordre dans lequel
AWS est un catalogue de briques que vous assemblez vous-même, avec un vocabulaire propre : les machines virtuelles s'appellent EC2, le stockage d'objets S3, le réseau privé dans lequel vos machines sont isolées VPC, et la gestion des droits IAM. Vous ne louez pas un serveur au mois avec un panneau de configuration, vous consommez des ressources et la facture reflète ce que vous avez laissé allumé. Cette structure a deux faces : un environnement de test peut être détruit le vendredi soir, mais aucune ressource ne s'éteint d'elle-même. Nous décrivons ces fondations dans notre article sur AWS pour une PME.
Trois situations rendent cette plateforme pertinente dans nos dossiers. La première est celle d'une application déjà développée pour AWS, dont les scripts de déploiement, les droits et les sauvegardes existent dans ce vocabulaire : changer de fournisseur reviendrait à tout réécrire pour un bénéfice incertain. La deuxième est celle d'un besoin précis auquel un service répond bien, par exemple un volume important de fichiers dans un stockage objet, une file de messages entre deux applications, ou une base de données managée. La troisième est celle d'une charge fortement variable, à condition que l'application sache réellement réduire sa consommation hors des pointes.
Nous voyons aussi des cas où AWS n'est pas la bonne réponse, et nous le disons avant le devis. Installer un site vitrine sur une instance revient à devenir son propre hébergeur : correctifs du système, serveur web, sauvegardes, certificat et supervision deviennent votre affaire, alors qu'un hébergement professionnel coûte moins cher et sera mieux tenu. Un parc de huit postes relève d'un contrat d'infogérance à partir de 120 HT / mois, qu'aucun compte cloud ne remplace. Et une architecture découpée en dizaines de petites fonctions dans une entreprise qui n'a personne pour les suivre rend un moins bon service qu'une machine unique, sauvegardée et documentée.
Ce que nous automatisons ici, c'est la description du socle : réseau, rôles, groupes de sécurité, stockage et étiquetage sont écrits dans des fichiers versionnés, avec un plan relu avant application, méthode détaillée dans notre article sur Terraform et Ansible. Nous importons l'existant plutôt que de tout recréer, ce qui évite toute interruption pendant la reprise. Reste manuel ce qui demande un arbitrage : le choix de la région, la décision de réserver de la capacité, la validation d'un arrêt en production, et l'analyse d'un incident, qu'aucun outil ne conduit à votre place.
Deux décisions coûtent cher longtemps après avoir été prises. La région détermine où vos données résident et influence la structure de votre facture, et la disponibilité des services que vous comptez y utiliser se vérifie au moment du projet, car tous ne sont pas ouverts partout. L'autre décision concerne les sauvegardes : un stockage objet versionné et répliqué est utile mais ne constitue pas une sauvegarde, comme l'explique notre article sur le stockage objet qui n'est pas une sauvegarde. Le choix entre fournisseurs, lui, se tranche sur vos contraintes et non sur un catalogue, sujet de notre article sur les critères qui décident pour une PME.
Les erreurs de compte que nous reprenons le plus souvent
-
Un compte au nom d'une personne
Adresse personnelle, carte bancaire du gérant, double authentification sur un téléphone qui a quitté l'entreprise. Le jour de l'incident, la reprise de contrôle passe par une procédure de récupération au lieu d'une connexion.
-
Des clés d'accès permanentes qui circulent
Une clé collée dans un fichier de configuration finit dans un dépôt de code, une pièce jointe ou sur le poste d'un prestataire. Les rôles temporaires évitent ce scénario, à condition de supprimer les anciennes clés.
-
Des services multipliés sans exploitant
Une architecture découpée en dizaines de composants impressionne à la conception et devient indépannable ensuite. La question à poser avant de choisir est simple : qui maintiendra cela dans deux ans.
Du cadrage aux fondations, puis au premier workload
-
Cadrage
1 à 2 jours
-
Architecture et déploiement
selon le périmètre
-
Sécurisation
sous 7 jours
-
Exploitation
en continu
Les comptes AWS que nous reprenons
Nous intervenons pour des entreprises dont l'application métier a été développée pour AWS et dont l'auteur n'est plus disponible, pour celles qui ouvrent un compte et veulent poser les fondations avant d'y placer une application, et pour celles dont le relevé mensuel est devenu illisible. Les missions se déroulent à distance, pour des clients de toute la France et de Suisse, avec un déplacement quand le dossier le justifie.
Zone d'intervention
Comptes AWS d'entreprises du Bassin Genevois, régions eu-central ou eu-west selon latence et résidence des données.
Ce que disent nos clients
Des PME et des indépendants du Bassin Genevois, suivis dans la durée.
« Mickael a été très réactif pour répondre à ma demande, en plus d'être très professionnel dans sa démarche, de bon conseils, et très agréable. Je le recommande fortement. »
« Mickael est très serviable. Je l'ai contacté par téléphone et il m'a gentiment proposé différentes solutions. »
« Très réactif, pro et de très bons conseils. Je le recommande les yeux fermés. »
Questions fréquentes
Faut-il déjà disposer d'un compte AWS ?
Non. Nous pouvons l'ouvrir avec vous, au nom de l'entreprise et avec un moyen de paiement professionnel, puis poser les accès, le réseau, les sauvegardes et le suivi de facturation avant d'y placer la moindre application. Si un compte existe déjà, nous commençons par un inventaire en lecture seule des ressources allumées.
Comment reprendre un compte créé par un prestataire parti ?
Nous identifions le compte de facturation et son responsable, nous inventorions les ressources actives, puis nous retirons les droits des personnes qui ne travaillent plus avec vous. Nous exportons ce qui doit être conservé avant toute suppression, et nous arrêtons l'inutile par étapes, avec une période d'observation.
Choisissez-vous la région à notre place ?
Nous instruisons la décision, vous la prenez. La région détermine la résidence de vos données et influence la structure de la facture, et la disponibilité des services envisagés se vérifie au moment du projet. Si un contrat vous impose une localisation, nous demandons la clause écrite et vous orientons vers un conseil spécialisé.
Gérez-vous aussi le suivi de la facture AWS ?
Oui, le suivi des consommations fait partie de l'exploitation. Nous posons les étiquettes, les budgets et les alertes dès la mise en place, puis nous tenons une revue régulière du relevé. Nous n'engageons aucune réservation de capacité de longue durée tant que l'architecture n'est pas stabilisée.
Comment cette prestation est-elle facturée ?
Au taux journalier de 1000 HT. Le contrat AWS reste le vôtre et la consommation vous est facturée directement par le fournisseur. Une fois la plateforme stabilisée, un forfait de run se discute pour l'exploitation courante.
Les autres prestations expertise cloud
Réalisations liées
Un projet, une panne, un rendez-vous.
Choisissez un créneau, ou décrivez votre besoin : nous répondons avec un périmètre clair, un prix hors taxes, et un interlocuteur nommé.