AWS Service Catalog で実現する IT ガバナンス - 承認済み製品の標準化とセルフサービス
IT 部門が承認した CloudFormation テンプレートをカタログ化し、起動制約とテンプレート制約でエンドユーザーのセルフサービスを安全に提供する手法を紹介します。
Service Catalog の役割
Service Catalog は IT 部門が承認した AWS リソースの構成を最大 5,000 製品のカタログとして管理し、エンドユーザーにセルフサービスでプロビジョニングさせるサービスです。エンドユーザーが自由に AWS リソースを作成すると、セキュリティ設定の不備、コスト管理の困難、アーキテクチャの不統一が発生します。Service Catalog では、IT 部門が CloudFormation テンプレートを製品として登録し、承認済みの構成のみをエンドユーザーに提供します。エンドユーザーはカタログから製品を選択してパラメータを入力するだけで、標準化されたリソースがプロビジョニングされます。Terraform テンプレートも製品として登録可能で、既存の IaC 資産を活用できます。
ポートフォリオと制約の設計
ポートフォリオは製品のコレクションで、IAM プリンシパル (ユーザー、グループ、ロール) にアクセス権を付与します。開発チーム用ポートフォリオには開発環境の EC2 と RDS を、データチーム用ポートフォリオには Redshift と Glue を含めるといった設計が可能です。起動制約は製品のプロビジョニング時に使用する IAM ロールを指定し、エンドユーザー自身の IAM 権限ではなく、制約で指定されたロールの権限でリソースが作成されます。これにより、エンドユーザーに CloudFormation の直接実行権限を与えずに、カタログ経由でのみリソース作成を許可できます。テンプレート制約で CloudFormation パラメータの許容値を制限し、インスタンスタイプを t3.micro と t3.small のみに制限するといった制御も可能です。TagOptions を設定すれば、プロビジョニング時にコスト配分タグやオーナーシップタグの付与を強制でき、タグ付け漏れによるコスト追跡の困難を未然に防げます。
マルチアカウント環境での活用
Organizations との統合で、管理アカウントで作成したポートフォリオを組織内の全アカウントまたは特定の OU に共有できます。共有されたポートフォリオの製品は各アカウントのエンドユーザーが利用でき、組織全体で統一されたアーキテクチャパターンを適用できます。製品のバージョン管理により、テンプレートの更新を段階的にロールアウトできます。新バージョンを公開しても、既存のプロビジョニング済み製品は自動更新されず、エンドユーザーが明示的にバージョンアップを実行します。これにより、更新による予期しない影響を防止できます。Control Tower との併用では、Service Catalog の製品が Landing Zone のガードレールに準拠していることを自動的に保証できます。 Service Catalog の運用設計を検討するうえで関連書籍 (Amazon)が参考になります。
設計のベストプラクティスと落とし穴
Service Catalog の設計で最も重要なのは製品の粒度です。1 製品に EC2 + RDS + VPC をすべて含めると柔軟性が低下し、EC2 だけ欲しいユーザーにも不要なリソースが作成されます。逆に粒度を細かくしすぎると、ユーザーが複数製品を正しい順序でプロビジョニングする負担が増えます。推奨されるパターンは、ネットワーク基盤 (VPC、サブネット) を 1 製品、コンピュート (EC2 + ALB) を 1 製品、データベース (RDS) を 1 製品として分離し、CloudFormation のクロススタック参照で接続する構成です。起動制約の IAM ロールは製品ごとに最小権限で作成し、全製品共通の管理者ロールを使い回さないことが重要です。共通ロールを使うと、1 製品の脆弱性が全リソースへのアクセスに波及します。また、ポートフォリオ共有時に委任管理者アカウントを設定すると、管理アカウントの権限集中を避けられます。
Service Catalog の料金と制限
Service Catalog 自体に追加料金は発生しません。コストはプロビジョニングされた AWS リソース (EC2、RDS 等) の利用料金のみです。ただし、AWS CloudFormation のサードパーティリソースタイプを使用する場合は、ハンドラー操作ごとに課金されます。Organizations でポートフォリオを共有する場合も追加料金はなく、組織全体のガバナンス基盤として導入コストが低い点が魅力です。テンプレート制約でインスタンスタイプを制限することで、エンドユーザーが高額なリソースを誤って作成するリスクも抑えられます。制限としては、1 リージョンあたりポートフォリオ数は 100、1 ポートフォリオあたり製品数は 150 がデフォルト上限です。大規模組織ではクォータ引き上げリクエストが必要になる場合があります。また、プロビジョニング済み製品の更新は CloudFormation スタック更新として実行されるため、変更セットの互換性に注意が必要です。
他サービスとの比較
Service Catalog と類似の目的を持つサービスとして、AWS Proton と Control Tower があります。Proton はプラットフォームエンジニアリング向けで、環境テンプレートとサービステンプレートの 2 層構造でマイクロサービスの標準化を実現します。Service Catalog が汎用リソースのセルフサービスに適する一方、Proton はコンテナ/サーバーレスのアプリケーションデプロイパイプラインに特化しています。Control Tower は組織全体のアカウントガバナンス (ガードレール、ログ集約、アカウント発行) に重点を置き、Service Catalog は個々のリソースプロビジョニングの標準化に重点を置きます。実際の運用では Control Tower でアカウント基盤を整え、Service Catalog でアカウント内のリソース提供を標準化する組み合わせが一般的です。
まとめ
Service Catalog は IT ガバナンスとエンドユーザーのセルフサービスを両立するサービスです。承認済みのアーキテクチャパターンをカタログ化し、起動制約とテンプレート制約で安全なプロビジョニングを強制します。Organizations との統合でマルチアカウント環境の標準化を実現し、Control Tower と組み合わせることで組織全体の一貫したガバナンスを構築できます。