AWSで他社の環境を共有してもらうとき

Question

他社で開発中の環境を共有してもらうときは、どのようにするのが一般的なのでしょうか。

①AssumeRoleを使う参考記事
②IAMユーザーを発行してもらう

それぞれのメリット・デメリット・使用場面はありますか。そもそもの認識が間違っていたら教えてください。

①は、参考URLにある通り、CUIでの操作しかできないんでしょうか。
②は、ユーザー作成するときにGUIへのアクセスも許可すると、GUI（AWSコンソール）にログインできて便利だと思ったのですが、、、

Answer 1

他社で開発中の環境を共有してもらうときは、どのようにするのが一般的なのでしょうか。

クロスアカウントアクセスには、ロールによるアクセス許可がよく利用されます。

公式ドキュメントで、ロール利用の一般的なシナリオとして紹介されています。

第三者が所有する AWS アカウントへのアクセス権を付与する - AWS Identity and Access Management

マネージメントコンソールへのログインを許可したいなら、スイッチロールという機能があります。

• 自社環境:AWSアカウントA
• 他社環境:AWSアカウントB

の場合、アカウントAのIAMユーザーがアカウントBのロールにスイッチすると、アカウントBのマネージメントコンソールにログインできます。

所有している別の AWS アカウントへのアクセス権を IAM ユーザーに提供 - AWS Identity and Access Management

リンク先でロールへの切り替えと記述されているのが、スイッチロールです。

補足です。

回答の内容は、質問者さんの「①AssumeRoleを使う」にあたります。

Answer 2

「どちらが一般的か」という言い方だと、正直②のほうが多いように思います。
しかし望ましいのは①のほうです。

②はメリットとしては単純にキーを発行して渡せば良いというわかりやすさでしょう。
ただし、都度アクセスキーを発行する運用はアクセスキーの管理の手間も増えますし、使用しなくなった際にきっちりアクセスキーを無効化するようにしていないとセキュリティ事故の元です。
また、アクセスキーを受け取った側が適切に管理できるか、という問題もあります。
IAMアクセスキーは必要がない限り発行しない、が鉄則です。

①のAssumeRoleによるクロスアカウントアクセスについては既に詳しく説明して頂いてるので省きます。
こちらのやり方のメリットは、キーの漏洩による事故が起こりにくいことです。
もしある別アカウントのユーザにクロスアカウントアクセスを許可していたとしてそのユーザのアクセスキーが漏洩したとしても、ロールの名前とアカウントIDもセットでわからなければ自アカウントへのアクセスができません。
コンソールでSwitchRoleするのが多少面倒ではありますが、基本的にはこちらを推奨します。