AWS Service Catalog のアイコン

AWS Service Catalog

承認済みの IT サービスを組織全体にセルフサービスで提供するカタログサービス

何ができるか

AWS Service Catalog は、組織が承認した IT サービスのカタログを作成・管理し、エンドユーザーがセルフサービスでリソースをプロビジョニングできるようにするサービスです。管理者は CloudFormation テンプレートや Terraform 構成をベースに製品 (Product) を定義し、ポートフォリオ (Portfolio) としてグループ化して特定のユーザーやチームに公開します。エンドユーザーはカタログから必要な製品を選択するだけで、事前に承認された構成のリソースが自動的にプロビジョニングされます。

どのような場面で使うか

開発チームへの標準化された開発環境の提供、データサイエンスチームへの分析基盤のセルフサービス展開、新入社員向けの初期環境セットアップ自動化、コンプライアンス準拠のインフラテンプレート配布、マルチアカウント環境での共通リソースの標準化、部門ごとのコスト管理を伴うリソース提供など、IT ガバナンスとセルフサービスの両立が求められる場面で活用されています。 この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

身近な例え

社内の備品カタログに例えるとわかりやすいでしょう。社員がパソコンや備品を購入する際、自由に選ぶと管理が煩雑になります。承認済みの備品カタログから選んで申請すれば、会社の基準に合った製品が確実に届きます。Service Catalog も同様に、IT 部門が承認した構成のリソースだけをカタログとして提供し、ガバナンスを維持しながらセルフサービスを実現します。

Service Catalog とは

AWS Service Catalog は、IT ガバナンスとセルフサービスプロビジョニングを両立するためのサービスです。大規模な組織では、開発者が自由にリソースを作成するとセキュリティやコンプライアンスの基準を満たさない構成が生まれるリスクがあります。一方で、すべてのリソース作成を IT 部門が承認するプロセスでは開発速度が低下します。Service Catalog はこの課題を解決し、管理者が定義した安全な構成テンプレートをカタログとして公開することで、開発者の自律性と組織のガバナンスを両立します。

製品とポートフォリオの管理

Service Catalog の中核概念は製品 (Product) とポートフォリオ (Portfolio) です。製品は CloudFormation テンプレートまたは Terraform 構成をベースに定義され、バージョン管理が可能です。ポートフォリオは複数の製品をグループ化したもので、IAM ユーザー、グループ、ロールに対してアクセス権を付与します。たとえば、データ分析チーム向けのポートフォリオには Redshift クラスター、Glue ジョブ、S3 バケットの製品を含め、開発チーム向けには EC2 インスタンス、RDS データベース、Lambda 関数の製品を含めるといった運用が可能です。

制約とタグ管理

Service Catalog では、製品のプロビジョニングに制約 (Constraints) を設定できます。起動制約 (Launch Constraint) により、エンドユーザーの IAM 権限に関係なく、指定したロールでリソースを作成できます。テンプレート制約 (Template Constraint) では、パラメータの選択肢を制限し、たとえばインスタンスタイプを特定のサイズに限定できます。タグオプション機能を使えば、プロビジョニングされるすべてのリソースに組織標準のタグを自動付与でき、コスト配分や管理の一貫性を確保できます。

Azure・オンプレミスとの比較

Azure の対応サービス Azure Managed Applications
オンプレミスでの対応手段 ServiceNow、自前のプロビジョニングポータル

AWS の優位点

  • CloudFormation や Terraform テンプレートをベースに製品を定義でき、インフラのコード化 (IaC) と IT カタログ管理を統合してガバナンスとアジリティを両立できる
  • 起動制約により、エンドユーザーに最小限の IAM 権限しか付与せずに複雑なリソースのプロビジョニングを許可でき、セキュリティリスクを低減できる
  • AWS Organizations との統合により、数百のアカウントに対してポートフォリオを一括共有でき、組織全体で標準化された IT サービスを効率的に展開できる

注意点

  • 製品のバージョン更新時は既存のプロビジョニング済み製品に自動適用されないため、ユーザーへの更新通知と移行計画を事前に策定すること
  • ポートフォリオの共有範囲を適切に設定し、意図しないユーザーが高コストなリソースをプロビジョニングできないよう制約を設けること

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。