Gestion infonuagique AWS pour agences : opérer les comptes clients sans embaucher une équipe infonuagique

La plupart des agences finissent par opérer des comptes AWS de clients par accident : un lancement de site ici, une migration là, et deux ans plus tard quinze charges de production dépendent d’une agence dont le vrai métier est le design et le développement. Gérer ce portefeuille sans embaucher une équipe infonuagique est possible, mais seulement avec de la structure — un compte AWS par client, des rôles inter-comptes plutôt que des mots de passe partagés, une base d’exploitation répétable estampillée sur chaque compte, et une réponse honnête à la question de l’après-heures. Sans ces quatre-là, l’agence ne gère pas de l’infrastructure; elle accumule du passif au rythme de son propre succès commercial.

Ce que vous décidez

Trois décisions définissent le modèle, et la plupart des agences ont pris les trois implicitement, mal.

La structure de comptes. Le mauvais patron : tout dans un seul compte AWS, les charges des clients séparées par étiquettes et par espoir — un identifiant compromis ou un mauvais script atteint tous les clients d’un coup, et la facturation devient de l’archéologie. Le bon patron : un compte par client (par environnement, idéalement) sous AWS Organizations — isolement du rayon d’impact, facturation par client gratuite, et transfert propre si la relation se termine. Cette dernière propriété compte plus que les agences le pensent — le client propriétaire de son propre compte, avec l’agence comme opérateur à l’intérieur, c’est à la fois la position éthique et celle qui survit aux litiges contractuels.

Le modèle d’accès. Des identifiants root partagés dans un coffre de mots de passe, c’est le patron qui finit par produire les pires rapports d’incident de l’industrie. Le remplacement, c’est IAM Identity Center : le personnel de l’agence a des identités nommées, des ensembles de permissions définissent ce que chaque rôle peut toucher, l’accès se révoque à un seul endroit quand quelqu’un part, et chaque action atterrit dans CloudTrail sous un vrai nom.

Le service que vous vendez réellement. « On l’héberge » cache un éventail énorme : est-ce que ça inclut la surveillance avec intervention, les correctifs, les sauvegardes avec tests de restauration, la réponse aux incidents à 2 h du matin, les revues de coûts? Chaque élément non défini est vendu implicitement et livré jamais. La décision : lesquels vous dotez en personnel, lesquels vous confiez à un partenaire d’exploitation en coulisses, et lesquels vous déclinez explicitement par écrit.

Quoi vérifier en premier

Combien de charges clients partagent un seul compte AWS aujourd’hui, et combien d’employés connaissent un mot de passe root.
Si l’agence pourrait produire un coût d’infrastructure par client sans un après-midi de chiffrier.
Ce qui arrive au site de production d’un client un samedi soir — concrètement, le téléphone de qui, et le sait-il.
Si un compte client possède CloudTrail, des sauvegardes et des alarmes — ou si la base, c’est ce dont l’ingénieur du jour de lancement s’est souvenu.
Qui possède légalement chaque compte : le client ou l’agence. Les deux réponses fonctionnent; ne pas le savoir, non.

Comment vérifier

Depuis le compte de gestion d’une Organization existante :

# Quels comptes existent, et y en a-t-il un par client?
aws organizations list-accounts \
  --query 'Accounts[].[Name,Id,Status]' --output table

# Qui est cet identifiant, et dans quel compte?
aws sts get-caller-identity

Par compte client, vérifiez que la base existe vraiment :

# Quelque chose enregistre-t-il qui a fait quoi?
aws cloudtrail describe-trails \
  --query 'trailList[].[Name,IsMultiRegionTrail,HomeRegion]'

# Des sauvegardes existent-elles pour les charges qui comptent?
aws backup list-backup-jobs --by-state COMPLETED --max-results 5

# Hygiène du compte root : MFA sur root, aucune clé d'accès root
aws iam get-account-summary \
  --query 'SummaryMap.[AccountMFAEnabled,AccountAccessKeysPresent]'

Dans la console, IAM Identity Center > Users montre si l’accès repose sur des individus nommés ou sur une connexion partagée qui se fait passer pour une équipe.

L’approche

Passer à un compte par client sous Organizations. Les nouveaux clients reçoivent un compte neuf dès le premier jour; les colocataires existants migrent à la prochaine fenêtre naturelle (replateformage, refonte, renouvellement). L’Account Factory de Control Tower fait de la création de compte un processus estampillé et gouverné plutôt qu’une liste dans la tête de quelqu’un.
Remplacer les identifiants partagés par Identity Center. Utilisateurs nommés, ensembles de permissions (lecture seule pour les chargés de projet, exploitation pour les ingénieurs, facturation pour les finances), MFA imposée, identifiants root scellés avec MFA et jamais utilisés.
Estampiller une base sur chaque compte. CloudTrail, garde-fous via politiques de contrôle de service — l’ensemble de départ est dans la base SCP pour Organizations — plus des plans AWS Backup, une douzaine d’alarmes de symptômes et une alerte budgétaire par compte. Définissez-la en code une fois; appliquez-la chaque fois.
Rendre la facturation par client par construction. Les comptes séparés le font automatiquement; la facturation consolidée conserve les rabais de volume au niveau de l’Organization. Revendez au coût, à coût majoré ou en forfait — mais décidez, et mettez-le au contrat.
Écrire les paliers de service. Palier un : hébergement et sauvegardes, réponse aux heures de bureau. Palier deux : plus surveillance avec délais de réponse définis. Palier trois : exploitation complète avec couverture après les heures. Facturez le téléavertisseur honnêtement — c’est la partie chère, et c’est exactement pourquoi il ne faut pas la donner implicitement.
Choisir entre bâtir et s’allier pour la couche après-heures. Une agence avec deux ingénieurs ne peut pas doter une vraie rotation 24/7; prétendre le contraire dure jusqu’à la première panne pendant une semaine de vacances. Un partenaire d’exploitation en marque blanche derrière l’agence couvre les nuits; l’agence garde la relation client.
Tenir un guide d’intervention par client. Résumé de la pile, chemin d’accès, procédure de déploiement, contacts d’escalade, pièges connus. Le test : un ingénieur qui n’a jamais touché ce client peut agir en quinze minutes.

Quand c’est la mauvaise approche

Si l’infrastructure se résume à trois petits sites vitrines, cette machinerie est du surcoût — un hébergement géré de qualité par site est moins cher et plus sûr qu’une pratique AWS à moitié bâtie. Si la charge d’un client porte de vraies obligations de conformité (données de santé, paiement à grande échelle), le geste honnête est un partenaire d’exploitation spécialisé dans ce compte, pas du meilleur-effort d’agence. Et si la marge d’hébergement est la seule raison pour laquelle l’agence tient ces comptes, faites le calcul en incluant les heures d’incident non facturées; un revenu d’hébergement qui coûte des fins de semaine n’est pas une marge.

Erreurs fréquentes

Un seul compte AWS pour tous les clients, découvert indivisible des années plus tard quand le plus gros client demande ses clés.
Des connexions root partagées, si bien qu’un départ exige de tourner les identifiants de tous les clients — ce qui, du coup, n’arrive jamais.
Vendre de l’« hébergement géré » avec des attentes de réponse qui n’existent que dans l’imagination du client, révélées à la première vraie panne.
Aucune porte de sortie : propriété des comptes, registraires de domaines et DNS emmêlés dans des comptes personnels de l’agence, transformant chaque fin de contrat en négociation d’otages.

Garder le contrôle

Une revue de portefeuille trimestrielle : chaque compte client contre la liste de base, les écarts mis en billets.
Des alertes budgétaires sur chaque compte, parce que la facture surprise d’un client devient l’appel téléphonique gênant de l’agence.
Une recertification des accès deux fois par année : qui a quel ensemble de permissions, et la liste des employés partis la croise-t-elle.
Des guides testés par rotation — un ingénieur différent exécute une tâche routinière à partir du guide chaque trimestre.
Le langage contractuel révisé annuellement contre ce que l’exploitation livre réellement.

Le patron qui échoue, c’est quinze comptes gérés chacun de mémoire par celui qui les a bâtis. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.