Il existe deux méthodes principales pour gérer l'accès des employés au compte AWS de votre entreprise: les utilisateurs IAM et AWS Organizations. Les deux ont leurs utilisations, mais il est important de souligner les différences lors de la planification de votre structure d'autorisation AWS.

Réponse courte: les deux, en fait

Lequel devriez-vous utiliser? La réponse est à la fois, car les utilisateurs IAM et les organisations AWS font des choses différentes. Bien qu'ils soient similaires en surface, ils ont été conçus pour des objectifs différents.

Les utilisateurs IAM sont un excellent moyen de gérer l'accès des employés. Ils vous permettent d'authentifier les employés sur un «sous-compte» avec des autorisations limitées. Ce système de gestion des autorisations est essentiel pour segmenter l'accès des employés à vos ressources AWS.

Les utilisateurs IAM sont également utilisés pour authentifier les comptes de service. Par exemple, si vous avez l'AWS CLI en cours d'exécution sur une instance EC2 et que vous souhaitez lui donner l'accès pour gérer un compartiment S3, vous pouvez le faire avec un utilisateur IAM afin que vous n'ayez pas à laisser les informations d'identification de votre compte racine sur un serveur distant.

AWS Organizations fait quelque chose de similaire. Il vous permet de créer des sous-comptes réels qui sont entièrement séparés du compte principal, avec leurs propres autorisations, tout en maintenant une facturation et un contrôle centralisés. Vous pensez peut-être que ce serait un excellent moyen de donner accès aux employés, mais les organisations ne sont pas faites pour cela.

Le principal problème est que vous êtes limité à quatre comptes par défaut. Bien que vous puissiez demander une augmentation de la limite, la limite est ici pour une raison: tous vos comptes d'organisation sont entièrement séparé. Cela signifie que si vous aviez un développeur travaillant sur une table DynamoDB dans son propre compte, elle serait invisible pour tous les autres employés.

Ce que vous voulez vraiment, c'est que tous vos employés travaillent ensemble dans un environnement partagé. La meilleure configuration pour presque toutes les entreprises serait la suivante:

• Utilisez AWS Organizations et créez des comptes séparés pour le développement et la production. Cela soulage vos développeurs et vous permet de leur donner des autorisations plus laxistes dans l'environnement de développement sans craindre qu'ils puissent bousiller vos serveurs de production.
• Vous pouvez également créer deux autres environnements: testing, qui contient des données factices propres et est utilisé par l'équipe QE pour exécuter des builds automatisés; et la mise en scène, un miroir complet de la production utilisé pour détecter les bogues pouvant survenir à l'aide d'API publiques et de données réelles avant qu'ils n'affectent réellement les clients.
• Dans l'environnement de développement, créez plusieurs utilisateurs IAM pour donner un accès géré à vos employés.
• Répétez le même processus pour votre équipe QE lors des tests et pour vos chefs de projet et architectes de solutions lors de la mise en scène. La production ne doit être mise à jour que par des personnes très autorisées et, bien sûr, contenir les comptes de service IAM dont elle a besoin pour fonctionner correctement.

Cette structure combine les avantages des deux types de comptes et semble être la manière dont AWS souhaite que vous la configuriez, étant donné la règle des quatre comptes (par défaut) d'AWS Organization.