管理アカウント単一運用からAWS Organizationsに移行するの大変で滅

2026年5月28日に行われた、
JAWS-UG東京 ランチタイムLT会 #35(https://jawsug.connpass.com/event/391811/ )に
登壇した時の資料になります。

Transcript

1. 管理アカウント単一運用から AWS Organizationsに 移行するの大変で オッスオッス JAWS-UG 東京 ランチタイムLT会 #35 の３番目の枠、 はぁじまぁるよー！！
2. 2 自己紹介 平目という名前で活動しております。 本日はよろしくお願いします。 自己紹介 HN：平目＠インフラエンジニア 所属：地方の一般の中小企業 ロール：クラウドエンジニアリングマネージャ
3. 3 自己紹介 本日聴講されている方の多くはIT企業にお勤めの方が多いかと思いますが、 私は地方の一般の中小企業に勤めるいわゆる情シスでして、 自己紹介 HN：平目＠インフラエンジニア 所属：地方の一般の中小企業 ロール：クラウドエンジニアリングマネージャ
4. 4 自己紹介 開発部門内のクラウド(AWS)担当の プレイングマネージャーをやっております。 自己紹介 HN：平目＠インフラエンジニア 所属：地方の一般の中小企業 ロール：クラウドエンジニアリングマネージャ emotional system とはいったい…？
5. 5 AWS Summit 行くよ そういえば来月はAWS Summitが幕張メッセにて開催されますが、 私も参加確定したので、 ホテルも移動経路も どちらも確保済
6. 6 AWS Summit 行くよ 同じように参加される方で、画面左側にいる顔に見覚えがあったら 声でもかけて頂けると嬉しいです。 ホテルも移動経路も どちらも確保済
7. 背景 背景 では内容に入りますが、 まず背景からお話しさせて下さい。
8. 8 ﾍｲｼｬでは2021年頃からAWSを使ってまして、 背景
9. 9 いくつかの小さなサービスを単体のEC2にて作成し、 管理アカウント上で運用していました。 背景
10. 10 その後に私が他社からジョインしまして、 この既存のアカウント内にサービスを追加していく訳ですが、 背景 今の企業には 転職で入って来た
11. 11 まずこうなりまして、 背景
12. 12 次にこうなりまして、 背景
13. 13 だんだんとアカウント内に複数のサービスが混在して来まして、 訳ﾜｶﾗﾝ状態になってきた訳です。（構成図はイメージ図です） 背景
14. 14 背景 悪魔的所業…！！！
15. 15 まあただ、この状態でも全然運用は可能なレベルで、 上手く管理上切り分けながら動かしていた訳です。 背景 意外と なんとかなる
16. 16 この状態に、そろそろ別クラウドにあるデカ目のワークロードを AWSに移転しようという話が持ち上がった訳です。 背景 言えないけど 別クラウドにある デカ目の ワークロード
17. 17 現環境だと管理上難しいだろう、という所感ですね。 背景 無理
18. 18 理由としては、同一環境にステージング環境などを置くリスクや、 アカウント環境をさらに複雑にしてしまう為ですね。 背景 言えないけど 別クラウドにある デカ目の ワークロード
19. 19 なので、ようやくAWS Organizationsのマルチアカウント環境に 着手し始めた、という所が現状となります。 背景 AWS Organizations
20. 本編 ようやく本編入ってくよ～ AWS Identity Centerに 移行するの大変で
21. 21 まず、管理アカウント単一運用だったこともあり、 主にIAMユーザを使っていた訳です。 IAM→ IAM Identity Center AWS IAM
22. 22 AWS Organizationsを運用するにあたり、 これらのIAMユーザはIdentity Centerに移行するのが自然ですね。 IAM→ IAM Identity Center AWS IAM AWS IAM Identity Center Identity Centerは マルチアカウント には必須に近い
23. 23 これだけならそんなに難しくないんじゃね？と思われると思いますが、 IAM→ IAM Identity Center Identity Centerは マルチアカウント には必須に近い
24. 24 ﾍｲｼｬはgitの管理にCodeCommitを使っていまして、 この辺りの運用の変更が意外と面倒だった、という話です。 IAM→ IAM Identity Center Identity Centerは マルチアカウント には必須に近い AWS CodeCommit
25. 25 CodeCommitといえば、一旦サ終の話が出て縮小運用の後、 不死鳥のごとく蘇ったサービスとして有名ですね。 IAM→ IAM Identity Center ポケ〇ンの世界の 不死鳥といえば この方 AWS CodeCommit
26. 26 そんなCodeCommitリポジトリへのアクセス方法は3種ありまして、 その中で、ﾍｲｼｬの従来環境だとHTTPSを利用していました。 IAM→ IAM Identity Center AWS CodeCommit
27. 27 これを利用する時の認証情報として、IAMユーザに対して CodeCommit用のAPIキーを設定した上で、アクセスする訳です。 IAM→ IAM Identity Center AWS CodeCommit
28. 28 この手法がセキュリティ上望ましくないのは当然として、 どの道AWS Identity Centerを使う前提だと、永続したキーは使えません。 IAM→ IAM Identity Center AWS CodeCommit Identity Centerでは 永続したAPIキーは 発行出来ない
29. 29 以上から、接続方法はHTTPS(Git Remote CodeCommit)での運用に 切り替えました。 IAM→ IAM Identity Center AWS CodeCommit Identity Centerでは 永続したAPIキーは 発行出来ない
30. 30 意外とここに障壁があったという事です。 IAM→ IAM Identity Center
31. 31 IAM→ IAM Identity Center AWS Organizations AWS IAM Identity Center まずはOrganizationsとIdentity Centerの概念の共有ですね。 AWSに詳しくないメンバーもいるので、SessionやProfileの作り方も含めて。 大変だった事一覧 ・AWS教育 ・既存リポジトリ ・運用変更
32. 32 次に、これまでHTTPSでアクセスしていた開発者が、 GRC経由でのアクセスに変更になる場合、 IAM→ IAM Identity Center 大変だった事一覧 ・AWS教育 ・既存リポジトリ ・運用変更
33. 33 こういう事を各開発者の端末内にある全てのリモートリポジトリに対して 行ってもらう必要がある訳です。面倒ですね。 IAM→ IAM Identity Center 大変だった事一覧 ・AWS教育 ・既存リポジトリ ・運用変更
34. 34 最後に、これまで我々はGitを使う上で永続化したキーを使ってきたので、 始業から終業まで何も意識せずそのままGitを使えた訳ですが、 AWS SSOへ認証情報を取得する手間が増えました。 IAM→ IAM Identity Center AWS IAM Identity Center 大変だった事一覧 ・AWS教育 ・既存リポジトリ ・運用変更
35. 35 つまり、こういう事でした。 Q.E.D. 証明終了。 IAM→ IAM Identity Center 大変だった事一覧 ・AWS教育 ・既存リポジトリ ・運用変更 システム的な事より 人間が関わる運用周りの事の方が面倒
36. 36 これは大事なことなので、今まさにXに投稿しておきました。 気になる方は #jawsug_tokyo でXを検索してね！ IAM→ IAM Identity Center システム的な事より 人間が関わる運用周りの事の方が面倒 #jawsug_tokyo(X)
37. ２つ目 次の内容入ってくよ～ 既存サービスを 別アカウントに 移行するの大変で
38. 38 背景でお話した通り、いくつかのサービスが管理アカウント上にあり、 出来れば他のアカウントに滅！したい訳です。必須では無いですが。 既存サービスを 滅したい
39. 39 今ではIaCを活用していて、AWSリソースはTerraform、 EC2の内部設定にはansibleなんかを利用している訳ですが、 既存サービスを 滅したい IaCは良いぞ
40. 40 しかしAWS導入当初の環境は、全てマネコンとSSHで作られたものですね。 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない
41. 41 タグ付けも徹底されていなかったこともあり、 関連リソースの完全な特定が難しかったりするのは当然として、 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない
42. 42 手動で設定されたEC2内部はブラックボックスでしかないので、 完全に作り直すのは難易度が高く、AMIで移行するか、という所です。 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない
43. 43 既存EC2のアカウント移転にはAMIの共有を使い、 そこからEC2を別アカウントに作り直す手法を取ります。 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない AWS account AWS account Amazon EC2 Amazon EC2 AMI Image AMI Image ElasticIP
44. 44 問題はPublic IPとなるElastic IPどうしようかな、 DNSの伝播の関係で、IP変わるのは難しいな～と思っていたのですが、 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない AWS account AWS account Amazon EC2 Amazon EC2 AMI Image AMI Image ElasticIP
45. 45 Elastic IPはアカウント間での移管が可能なんですね。 最近知りました。 既存サービスを 滅したい 関連リソースや EC2内部設定を 完全に特定出来ない AWS account AWS account Amazon EC2 Amazon EC2 AMI Image AMI Image ElasticIP
46. 46 体験談レベルですが、ブラックボックス化された環境から移行するのは 繊細な確認を大量に行う必要があるので、早い段階からIaC化は着手することをおススメします。 IAM→ IAM Identity Center IaC化していた方が アカウント間移管処理は圧倒的に楽 Cloudformationも いいぞ AWS onlyなら特に
47. 所感 あと感想ですね。 マルチアカウントは
48. 48 管理上の話ですが、やっぱり１アカウント内にあるというのは 非常にゴチャゴチャしているというか、分かり辛い部分もかなりあって、 所感 AWS account サービスA サービスAと 他サービスの 連結リソース 全サービスで使う 共有リソース サービスB サービスBと 他サービスの 連結リソース サービスC サービスCと 他サービスの 連結リソース サービスD サービスDと 他サービスの 連結リソース マルチアカウントで 明確な分界点を 作る事で 可視性が上がる
49. 49 コイツだけが分かってればいいって話ではないのですよね。 メンバー全員が理解できる必要がある訳です。 所感 AWS account サービスA サービスAと 他サービスの 連結リソース 全サービスで使う 共有リソース サービスB サービスBと 他サービスの 連結リソース サービスC サービスCと 他サービスの 連結リソース サービスD サービスDと 他サービスの 連結リソース マルチアカウントで 明確な分界点を 作る事で 可視性が上がる
50. 50 あと、各サービスに対してほぼ全員がアクセス可能になってしまう、 その制限も管理運用が面倒、という側面がありました。 所感 AWS account サービスA サービスAと 他サービスの 連結リソース 全サービスで使う 共有リソース サービスB サービスBと 他サービスの 連結リソース サービスC サービスCと 他サービスの 連結リソース サービスD サービスDと 他サービスの 連結リソース マルチアカウントで 明確な分界点を 作る事で 可視性が上がる
51. 51 結局こんな感じでまとめた方がシンプルだった、という感想です。 アカウント単位で追加して、複製環境を作れるのが良いですね。 所感 AWS account サービスA サービスAと 他サービスの 連結リソース 全サービスで使う 共有リソース サービスB サービスBと 他サービスの 連結リソース サービスC サービスCと 他サービスの 連結リソース サービスD サービスDと 他サービスの 連結リソース AWS account AWS account AWS account AWS account マルチアカウントで 明確な分界点を 作る事で 可視性が上がる
52. 52 もう１点言えば、コスト管理ですね。 所感
53. 53 ﾍｲｼｬのAWS利用コストで大きな割合を占めるサービスとして、 Amazon Bedrockがあるのですが、 所感 Amazon Bedrock お金の管理は大事 誰がどれだけ 使ったかを 把握しておくだけで 分かる事がある
54. 54 開発者のClaude Codeでの利用や社員の通常利用など、 多岐に渡る利用をしているためにコストの全容が見え辛くなっていました。 所感 Amazon Bedrock AWS account お金の管理は大事 誰がどれだけ 使ったかを 把握しておくだけで 分かる事がある
55. 55 これもアカウントを分けることで、それぞれのコスト感を 比較的簡単に、適切に把握出来るようになったのは大きいです。 所感 Amazon Bedrock AWS Dify account AWS Developer account Amazon Bedrock お金の管理は大事 誰がどれだけ 使ったかを 把握しておくだけで 分かる事がある
56. 体験談というか失敗談ですが、楽しんで聴講頂けていたら幸いです。 ご清聴どうもありがとうございました。 オワオワリ