Poser la gouvernance AWS d'un éditeur de logiciels

Le contexte

Un éditeur de logiciels dont plusieurs équipes utilisent AWS. La question n’est pas de savoir si AWS fonctionne, mais selon quelles règles : qui a le droit de faire quoi, comment les comptes sont structurés, comment le réseau est segmenté. Sans réponse commune, chaque équipe invente la sienne.

Ce qui a été fait

• Gouvernance des comptes AWS — organisation, IAM, réseau : la structure et les droits, posés comme socle plutôt que négociés projet par projet.
• Accompagnement des nouvelles applications — conception de l’architecture, industrialisation, puis support une fois en production.

Ce que ça change

La gouvernance d’abord, les applications ensuite. C’est l’ordre inverse de celui qu’on rencontre souvent — les projets d’abord, les règles rattrapées après, quand elles coûtent une reprise.

Services AWS mobilisés

Amazon Organizations, AWS IAM, Amazon VPC, Amazon EC2, AWS Lambda, Amazon ECS, Amazon DynamoDB, Amazon S3, Amazon CloudFront.

La suite

Quelques années plus tard, la même entreprise — devenue Verimatrix — m’a repris pour tenir cette gouvernance dans la durée. Quatre ans, cette fois, en abonnement continu. Ce cas-ci montre la mise en place ; l’autre montre ce qu’elle devient quand elle est tenue. Voir le cas Verimatrix.