Pour le meilleur ou pour le pire, S3 s’est instauré comme un mécanisme de transport courant pour le partage de grands ensembles de données entre les organisations partenaires. Il s’agit d’une pratique courante dans un écosystème considéré comme un «lac de données» ou «hadoop», où des outils tels que Athena, Redshift, Snowflake, Hive, Pig, EMR, Glue, Lake Formation, etc. sont utilisés.

Dans certains cas où deux organisations exploitent toutes deux AWS et souhaitent partager des données, il existe plusieurs écueils courants. Il n’existe pas de «meilleure solution» – la marche à suivre est différente pour chaque entreprise, mais nous pensons que la définition de politiques de regroupement de comptes croisés comporte un certain nombre de fonctionnalités clés qui peuvent réduire les frais généraux de gestion et permettre une intégration fluide à long terme.

Cependant, il s’agit d’une configuration souvent mal comprise et peu intuitive pour de nombreux ingénieurs, même ceux qui ont une solide expérience dans AWS et IAM.

Imaginons qu’une entreprise A souhaite obtenir des données en provenance d’une entreprise B. A souhaite obtenir ces données pour parfaire ses algorithmes de reporting interne et d’apprentissage automatique, et comme les deux entreprises fonctionnent avec AWS, elles acceptent toutes deux que l’entreprise B entrepose ses données dans le compartiment S3 de l’entreprise A.

L’approche instinctive

Lorsqu’on propose une telle solution pour la première fois, l’approche qui est généralement employée est la suivante ; «Nous allons créer un nouvel utilisateur sur notre propre compte AWS auquel vous pourrez ensuite avoir accès».

Certes, c’est une option… mais qui peut mener vers quelques surprises.

Supposons que l’entreprise B prend la décision d’y aller de l’avant. Un nouvel utilisateur est créé, puis les clefs d’accès IAM sont envoyées à l’entreprise A. On découvre déjà là un enjeu important : La sécurité. En n’utilisant pas de rôle de service, ces accès secrets ne sont pas automatiquement sécurisés. Ils sont alors probablement transmis par e-mail à plusieurs parties prenantes impliquées dans l’entreprise. Si l’entreprise A ou l’entreprise B ont des exigences de conformité en lien avec la sécurité de telles informations, il est malheureusement rare que les différentes entreprises impliquées suivent les mêmes processus. Il y a alors une surcharge de conformité.

Mais c’est par la suite que nous atterrissons au cœur du problème. L’entreprise B utilise déjà AWS pour un procédé qui conçoit les données. Et ces données ont besoin d’être lues quelque part! Peut-être qu’elles se trouvent dans un compartiments S3 appartenant à B, ou alors parmi le flux Kinesis de B ou de Kafka. Quoi qu’il en soit, si B fonctionne avec AWS, il pourrait bien y avoir 10 raisons différentes pour lesquelles B a besoin d’autorisations AWS sur les comptes A et B, et vous ne pouvez vous connecter qu’à un AWS ARN à la fois! C’est là que réside la malheureuse vérité.

Plus concrètement, de nombreux utilisateurs sont familiers avec la commande aws s3 cp s3:from-bucket/file s3:to-bucket/file, qui est probablement le moyen le plus courant de transférer des données entre deux compartiments. Cette commande est exécutée avec une seule connexion ARN à AWS.

Alternativement, vous pouvez effectuer toutes les opérations dont vous avez besoin avec un compte, puis changer d’accès pour effectuer les opérations avec un second compte. Mais si l’objectif premier est de transférer de grandes quantités de données, cela pourrait être délicat – en particulier dans un monde de Lambdas et de conteneurs où de nombreuses entreprises n’ont même pas de processus de gestion des EC2 en lien avec de gros volumes de données. Plus important encore, le volume de travail et la marge d’erreur sont doublés. Si le processus cesse et qu’il est à refaire, vous devez pouvoir reprendre où vous en étiez. Comptez vous alors le faire manuellement? Vous venez d’introduire plusieurs complications et d’augmenter considérablement votre surcharge opérationnelle.

Accès entre les comptes

Mais qu’en est-il du «changement de rôle» ou de «l’accès croisé»? S’agit-il de la solution ultime pour se connecter à deux comptes AWS avec la même authentification? Vous pourriez en effet recourir à cette solution, mais pas en même temps. Une commande s3 cp ne fonctionnera donc toujours pas. Je réalise maintenant que c’est l’une de ces choses que l’on doit expérimenter par soi-même avant d’y croire. Lorsque j’ai moi-même rencontré ce problème pour la première fois, je refusais d’accepter que cet «accès croisé» ne puisse répondre à mes besoins d’accès entre comptes.

Alors, quelle est la solution?

Saisissez les «autorisations de compartiment multi-comptes», qui semblent très semblables à «l’accès multi-comptes», mais qui sont Ô combien différentes. C’est l’approche qui est recommandée par AWS Solutions Architect.

Les étapes décrites sont longues et quelque peu complexes, mais si vous les suivez à la lettre, vous vous retrouverez avec une solution extrêmement simple et un crédit technique qui se poursuit au fil du temps.

Collaboration

Vous voici donc équipé d’une solution à exploiter lorsque deux entreprises travaillent avec AWS, et d’après notre expérience, il s’agit toujours d’un processus semé d’embûches. Lorsque vous communiquez avec un partenaire, il est difficile de se faire une idée du contexte précis dans leur domaine d’expertise ou de leur position dans une organisation. Et si une solution de transfert peut très bien s’appliquer à l’un des partis, elle n’est pas nécessairement adéquate pour le second parti. Les deux entreprises concernées doivent composer avec ce système et prendre le temps de comprendre le contexte de leur partenaire et ses contraintes techniques. Vous aboutirez éventuellement à un scénario gagnant-gagnant.