AWS Service Catalogとは？仕組み・ポートフォリオ設計と組織展開の判断を実装者目線で解説

AWS Service Catalogは、管理者が承認済みのAWS構成をカタログとしてまとめ、エンドユーザーがコンソールからセルフサービスで払い出せるようにするサービスです。中身はCloudFormationテンプレートで、ポートフォリオ・プロダクト・制約という3層で「誰が・何を・どの権限で起動できるか」を管理します。この記事では、構成要素の仕組み、IAMとAWS Organizationsを使った権限設計と組織横断の展開、月1,000回まで無料のAPI課金モデル、導入手順、そしてCloudFormationを直接配る運用と比べていつ採用すべきかまでを実装者目線で整理します。

まとめ：AWS Service Catalogの要点と導入判断の指針

AWS Service Catalogの本質は「IaCテンプレートに承認とガードレールを付けて配る仕組み」です。開発者にAdministratorAccessを渡さず、事前に許可した構成だけをボタン一つで起動させたい組織に向きます。ポートフォリオで公開範囲を、プロダクトで中身を、制約で起動時のルールを分けて管理する三層構造が中核になります。

費用はリソース本体とは別に、Service CatalogのAPI呼び出しへ課金されますが、1アカウント・1リージョンあたり月1,000回まで無料枠があり、通常の運用で課金に届く場面は限られます。判断の分かれ目は組織規模とガバナンス要件です。数名の開発チームでCloudFormationを直接運用できているなら導入は過剰で、複数アカウント・複数部門にまたがって払い出しの標準化と権限分離が要る段階から効いてきます。

AWS Service Catalogの仕組みとポートフォリオ・プロダクトの構造

Service Catalogは、管理者向けの「カタログを作る側」と、エンドユーザー向けの「カタログから選んで起動する側」の2つの視点で成り立ちます。まず全体像を、ポートフォリオ・プロダクト・制約という単位で押さえます。

ポートフォリオとプロダクトが担う役割と管理者・利用者の視点の違い

プロダクトは、1本のCloudFormationテンプレートに相当する起動可能な単位です。EC2とRDSを組み合わせたWebサーバー一式、VPC込みの検証環境など、承認済みの構成をパッケージ化したものを指します。プロダクトは単体では配布できず、必ずポートフォリオに入れて公開します。

ポートフォリオは、複数プロダクトをまとめ、IAMのユーザーやグループ、ロールに対して公開範囲を割り当てる箱です。「開発部門向けポートフォリオ」「データ分析チーム向けポートフォリオ」のように部門単位で束ね、そこに含めたプロダクトだけがエンドユーザーのコンソールに並びます。管理者はポートフォリオ設計で「誰に何を見せるか」を決め、エンドユーザーは見えているプロダクトを選んで起動するだけ、という役割分担になります。

プロビジョニングされたプロダクトの管理とバージョン更新の考え方

エンドユーザーがプロダクトを起動すると、その実体は「プロビジョニングされたプロダクト（provisioned product）」として管理されます。裏側ではCloudFormationスタックが1つ作られ、パラメータやタグ、更新・削除の履歴がひも付く形です。エンドユーザーはスタックを直接触らず、Service Catalog上の1オブジェクトとして自分が払い出した環境を扱えます。この考え方はプロビジョニングとは何かを整理した記事で扱う「宣言的に環境を用意する」流れの延長線上にあります。

プロダクトはバージョン管理され、管理者が新しいテンプレートをバージョンとして追加します。既存のプロビジョニングされたプロダクトは、管理者が許可した範囲で新バージョンへ更新でき、古い構成を段階的に置き換えられます。制約は「起動されていない全バージョンに即時適用される」ため、ルール変更が既存の払い出し済み環境の設定を勝手に書き換えることはありません。

Launch・Template・Notificationなど5種類の制約の使い分け

制約（constraint）は、ポートフォリオに入れたプロダクトへ「起動時のルール」を後付けする仕組みです。公式には次の5種類があり、単体でも組み合わせても付けられます。

実務でまず設定するのはLaunch制約とTemplate制約です。Launch制約が権限分離の土台になり、Template制約が「t3.large以外は選ばせない」といったコスト・構成の逸脱を止めます。NotificationとTag Updateは運用監視やコスト配賦タグの整備が要る段階で足す、という優先順位で考えると過不足がありません。

IAMとAWS Organizationsで実現する権限設計と組織横断の展開

Service Catalogの価値は権限設計にあります。エンドユーザーに強い権限を渡さずに、承認済み構成だけを起動させる仕組みを、IAMとOrganizationsの2軸で組み立てます。

Launch制約とIAM起動ロールで最小権限を担保する仕組み

Launch制約を付けると、プロダクトの起動時に「エンドユーザー自身の権限」ではなく「管理者が指定したIAMロール」でCloudFormationが実行されます。これにより、エンドユーザーにはService Catalogのプロダクトを起動する権限だけを与え、実際にEC2やRDSを作る強い権限は起動ロール側に閉じ込められます。開発者へAdministratorAccessを配らずに済むのが、この仕組みの核心です。権限設計の前提となるロールとポリシーの考え方はAWS IAMの仕組みを解説した記事で整理しています。

起動ロールには、そのプロダクトが作るリソースに必要な最小限の権限だけを付けます。Webサーバー一式のプロダクトならEC2・ELB・関連ネットワークの作成権限に絞り、データベース作成権限は含めない、という設計で「払い出しの範囲」を技術的に固定できます。

AWS Organizationsを使ったポートフォリオ共有と横断展開

単一アカウント内の配布に加え、Service CatalogはAWS Organizations経由でポートフォリオを組織全体や特定OU（組織単位）へ共有できます。共有された側のアカウント管理者は、そのポートフォリオを自組織にインポートし、ローカルのIAMプリンシパルへ公開できる形です。全社標準のネットワーク構成やセキュリティ設定込みのテンプレートを、中央のポートフォリオから各アカウントへ配る運用に向きます。

複数アカウントの発行そのものを標準化するなら、AWS Organizationsの管理・設計を扱った記事や、ランディングゾーンを自動構築するAWS Control Towerの仕組みを解説した記事と合わせて設計すると、アカウント発行から中身の払い出しまでを一貫させられます。Control Towerが「アカウントの器」を、Service Catalogが「器に入れる中身」を担うイメージです。

AWS Service Catalogの料金モデルと導入手順の全体像

導入前に費用感と作業の流れを把握します。料金はリソース本体とService CatalogのAPI利用が別建てで、導入自体は数ステップで開始できます。

API課金モデルと月1,000回の無料枠を踏まえた費用の考え方

Service Catalog自体の料金は、機能利用に伴うAPI呼び出し回数への従量課金です。最低料金や前払いはなく、公式の料金ページでは1アカウント・1リージョンあたり月1,000回のAPI呼び出しが無料、超過分が1回あたり0.0007ドルとされています。AppRegistryのアプリ作成やリソース関連付け、タグ付け操作は無料です。

ポートフォリオ作成に必要なAPIは数回程度で、日常の払い出しでも無料枠に収まる規模が多くなります。費用の主体はService Catalog経由で作られるEC2やRDS本体であり、カタログ機能そのものはコスト要因になりにくい、と捉えるのが実態に近い理解です。

ポートフォリオ作成からエンドユーザーへの配布までの導入手順の流れ

最小構成での導入は、次の順で進めます。既存のCloudFormationテンプレートがあれば、それをそのままプロダクト化できます。

1. 公開したい構成のCloudFormationテンプレートを用意する
2. テンプレートをプロダクトとして登録し初期バージョンを作る
3. ポートフォリオを作成しプロダクトを追加する
4. Launch制約に起動用IAMロールを指定する
5. ポートフォリオへエンドユーザーのIAMプリンシパルを割り当てる

この5ステップで、エンドユーザーのコンソールにプロダクトが並び、ボタン操作で承認済み環境を起動できる状態になります。テンプレートの設計や起動ロールの権限設計まで含めた導入は、AWSのインフラ構築・運用支援として設計から実装まで受託しています。

Service Catalogを採用すべき組織と見送るべき場面の判断

Service Catalogは万能ではありません。CloudFormationを直接運用する体制で足りている組織にとっては、管理レイヤーが1枚増えるだけの負担になります。採用条件と見送る場面を条件付きで切り分けます。

Service Catalogが効く条件とCloudFormation直接運用との線引き

採用が効くのは、次の3条件が重なる場合です。第一に、テンプレートを使う人（エンドユーザー）とテンプレートを作る人（管理者）が分かれていること。第二に、エンドユーザーに強いIAM権限を渡したくないこと。第三に、複数アカウントや複数部門へ標準構成を配る必要があること。この3つが揃うと、Launch制約による権限分離とポートフォリオ共有が明確な利得になります。

逆に、少人数の開発チームが自分たちのアカウントでCloudFormationやTerraformを直接回している段階では、Service Catalogは見送るのが妥当です。テンプレートを書く人と使う人が同じなら、承認・配布・権限分離のレイヤーは設計・保守コストに見合いません。この場合はCI/CDパイプラインでのテンプレート管理に投資するほうが、payが大きくなります。「配布と権限分離が要るか」を採否の一線と置くと迷いません。

Service Catalog導入でつまずく典型的な失敗パターンと回避策

典型的な失敗は2つあります。1つ目は、Launch制約を設定せずにプロダクトを公開してしまうケースです。この状態ではエンドユーザー自身の権限で起動されるため、権限分離という導入目的が成立せず、結局は強い権限を配ることになります。プロダクト公開とLaunch制約の設定は必ずセットにします。

2つ目は、ポートフォリオを部門・用途で分けずに1つへ詰め込み、公開範囲の管理が崩れるケースです。全プロダクトが全ユーザーに見える状態は、承認済み構成を絞って見せるという設計思想を無効にします。ポートフォリオは「公開対象の単位」で切り、Template制約で選べるパラメータを絞り込むことで、運用が肥大化しても統制を保てるのが利点です。設定変更の記録や逸脱検知を重ねるなら、AWS Configによる構成評価と組み合わせると、払い出し後のドリフトまで追えます。

AWS Service Catalogに関してよくある質問と回答

導入検討で挙がりやすい質問を、実装の観点でまとめます。

AWS Service Catalogは無料で使えますか？

カタログ機能のAPI呼び出しは、1アカウント・1リージョンあたり月1,000回まで無料で、超過分が1回0.0007ドルです。ただしService Catalog経由で作られるEC2やRDSなどのリソースは、各サービスの通常料金がかかります。カタログ機能自体は低コストで、費用の主体は起動されるリソース側だと考えてください。

Service CatalogとCloudFormationの違いは何ですか？

CloudFormationはテンプレートからリソースを作る仕組みそのもので、Service Catalogはそのテンプレートに承認・公開範囲・起動時ルールを付けて配布する管理レイヤーです。プロダクトの実体はCloudFormationテンプレートであり、両者は競合せず、上下の関係にあります。配布や権限分離が不要ならCloudFormation単体で十分です。

エンドユーザーに管理者権限を渡さずに済みますか？

Launch制約を使えば、起動時に管理者が指定したIAMロールでCloudFormationが実行されます。エンドユーザーにはプロダクトを起動する権限だけを与え、リソース作成の強い権限は起動ロールに閉じ込められるため、AdministratorAccessを配らずに運用できます。

複数アカウントへ同じ構成を配れますか？

配れます。AWS Organizations経由でポートフォリオを組織やOUへ共有する方法と、Stack Set制約で複数アカウント・リージョンへ同時展開する方法の2通りです。全社標準の構成を中央で管理し、各アカウントへ配布する運用に向きます。

Terraformで作った構成もプロダクトにできますか？

Service Catalogは外部のIaCエンジンにも対応しており、Terraformで定義した構成をプロダクトとして登録できる仕組みが用意されています。ただし基本はCloudFormationテンプレートが前提のため、既存資産がTerraform中心なら、対応方式と運用フローを事前に確認しておくと移行がスムーズです。

関連記事

• AWS IAMとは？権限設計のベストプラクティス：Launch制約で使う起動ロールと最小権限の設計を深掘りできます。
• AWS Organizationsとは？マルチアカウント管理の仕組み：ポートフォリオ共有の前提となる組織・OU設計を扱います。
• AWS Control Towerとは？マルチアカウント統制の仕組み：アカウント発行の標準化とService Catalogの組み合わせに役立ちます。
• AWS Configとは？設定変更の記録とルール評価：払い出し後の構成ドリフトを検知する仕組みを補えます。
• プロビジョニングとは？種類と自動化の判断：プロダクトの土台となる宣言的な環境払い出しを整理します。