マルチアカウント環境におけるAmazon Q Developerサブスクリプション管理の設計と課題
本記事では、マルチアカウント環境においてAmazon Q Developerのサブスクリプション管理を導入する際の設計要素について、直面した課題と最終的なアーキテクチャ設計の判断を解説します。
取り上げるAWSの主要サービスは以下の通りです。
AWS Control Towerなどを利用したマルチアカウント環境において、開発者の生産性を飛躍的に高める Amazon Q Developer Pro をどのように導入・管理すべきか。エンタープライズアーキテクチャのベストプラクティスに基づいたアカウント構成を前提としつつ、実践的な対応案をご紹介します。
前提となるアカウント構成と当初の想定
マルチアカウント環境のベストプラクティスに従い、以下のようなアカウント構成を想定していました。
- 管理アカウント（Management Account）
- Audit / Log Archiveアカウント（Control Towerにより払い出し）
- 共通サービスアカウント（Shared Services）
- Developmentアカウント
- 複数のメンバーアカウント（本番・検証など）
この構成において、ユーザー管理の要となる IAM Identity Centerの管理者権限は、共通サービスアカウントに委任 して、全社的な統合管理を行う想定でした。
直面した課題：管理者委任の未サポート
いざAmazon Q Developer Proのサブスクリプション管理をIAM Identity Centerと連携して行おうとした際、アーキテクチャ上の大きな壁にぶつかりました。
Amazon Q Developerは、管理者委任されたIAM Identity Centerでの管理をサポートしていない（参考: AWS re:Post 記事）
この仕様上の制約により、当初予定していた「共通サービスアカウントでのサブスクリプション一元管理」が実現できず、設計の根本的な見直しを迫られることになりました。
検討した3つの対応案
この制約に対し、アーキテクチャの観点から以下の3つの対応案を検討しました。
① 管理者アカウントでの一元管理
管理者アカウントからIAM Identity Centerの管理者権限を委任せず、Amazon Q Developerのサブスクリプション管理も含めて管理者アカウントで実施する案です。
- メリット: 組織全体でのサブスクリプションの集中管理が可能になります。
- 懸念点: 「管理者アカウントは基本的に日常的な業務作業には使わない」というAWSの強固なベストプラクティスに反してしまいます。
② 各メンバーアカウントでの個別管理（アカウントインスタンス）
各メンバーアカウントでAmazon Q Developerを使用し、アカウント毎にIAM Identity Centerのアカウントインスタンスを立てて個別に管理する案です。
- メリット: 実装自体は各アカウント内で完結するため、シンプルに導入できます。
- 懸念点: システム毎のアカウントで管理が分散するためガバナンスが効きません。マルチアカウント構成におけるID集中管理のベストプラクティスに完全に逆行してしまいます。
③ Developmentアカウントへの集約とCI/CDデプロイ
DevelopmentアカウントにIAM Identity Centerのアカウントインスタンスを立て、開発作業を同アカウントに集約する案です。
- メリット: 開発はこのアカウント内で完結します。CI/CDパイプラインも同アカウントに配置し、デプロイ先を各メンバーアカウントに指定することで、複数システムへの対応と集中管理の考え方を両立できます。
- 懸念点: IAM Identity Centerの組織インスタンスによる全社的な統合管理とは異なるアプローチになります。
結論：案③（Developmentアカウントへの集約）を採用した理由
チーム内で検討を重ねた結果、最終的に 「③ Developmentアカウントへの集約とCI/CDデプロイ案」 を採用することに決定しました。
その採用理由は以下の通りです。
-
開発リソースの集中管理とマルチデプロイの両立
開発に必要なリソース（ソースコード、パイプライン、Amazon Q Developer環境など）をDevelopmentアカウントという1つの環境に集中管理できます。その上で、CI/CDパイプラインを経由することで、複数システム（メンバーアカウント）に対するセキュアなデプロイ要件もしっかりと満たすことができます。 -
IAM Identity Centerを用いたユーザー単位のサブスクリプション管理
Developmentアカウント内にIAM Identity Centerの「アカウントインスタンス」を構築することで、開発者に対するAmazon Q Developerのユーザー単位のサブスクリプション管理を適切に行うことができます。 -
AWS環境へのログイン統制との分離（最大の決め手）
Amazon Q Developer用の管理をDevelopmentアカウントに切り出したことで、組織全体のAWS環境へログインするためのユーザー管理（IAM Identity Centerの組織インスタンス）は、当初の設計通り 共通サービスアカウントに委任したまま継続 することが可能です。
これにより、「管理アカウントにログインしない」というセキュリティのベストプラクティスを守りつつ、開発チームの俊敏性と全社的なアクセスガバナンスを綺麗に両立するアーキテクチャを実現できました。
最終的なアーキテクチャ構成図
本記事で採用した構成の概念図です。用途に応じてIAM Identity Centerのインスタンス（組織 vs アカウント）を使い分けている点がポイントです。
まとめ
Amazon Q DeveloperがIAM Identity Centerの管理者委任をサポートしていないという制約が発端となった検討でしたが、結果的にマルチアカウント環境におけるベストプラクティスに則った、堅牢で実用的な設計に着地することができました。
今後はIAM Identity CenterとAmazon Q Developerの更なる親和性が生まれ、管理機能が拡張されることを期待しつつ、本記事の締めとさせていただきます。
読んでいただきありがとうございました。同様の課題に直面している方の参考になれば幸いです。