こんにちは。NTTデータ九州 ビジネス共創部 デジタルビジネス推進室の中野です。
本記事では、Amazon Web Services（以下、AWS）Service Catalog の基本的な使い方を整理します。あわせて、「なぜAWS Service Catalogは実務で広く使われていないのか」という点について、構造的な観点から考察します。
本記事は以下のような方を対象としています。
- クラウドアーキテクト
- インフラ／プラットフォームエンジニア
- IaC標準化やガバナンスを検討しているチーム
- AWS IAMやAWS Service Catalogの運用設計に関わる方
※本記事は2026年5月時点の情報に基づいて作成しています。サービス仕様は変更される可能性があるため、実際の利用時には最新の公式ドキュメントをご確認ください。
はじめに
IaC（Infrastructure as Code）が一般化した現在、CloudFormation や Terraform によるインフラ構築は当たり前になりました。
その一方で、次のような課題は依然として残っています。
- チームごとに構成がバラバラになる
- セキュリティ基準が統一されない
- インフラ申請がボトルネックになる（毎回インフラチームに依頼が来る）
このような課題を解決し、アジリティとガバナンスを両立するための仕組みとして提供されているのが AWS Service Catalog です。
しかし実際には、広く使われているとは言い難いサービスでもあります。
本記事では、AWS Service Catalogを実際に使い、利用方法を整理したうえで、普及しにくい理由について掘り下げます。
AWS Service Catalogとは何か
AWS Service Catalogは、AWS上で「標準化されたインフラを、安全にセルフサービス提供するためのカタログ基盤」です。
しかし、単なる「テンプレート管理サービス」ではなく、
- 利用者の自由度
- 組織としての統制
- 標準化された構成管理
を両立するための ガバナンスレイヤーとしても機能します。
構成要素は以下の通りです。
- 製品（プロダクト）
- ポートフォリオ（製品の集合）
- 制約（利用ルール）
- IAMによるアクセス制御
AWS Service Catalogは元々CloudFormationをバックエンドとして設計されたサービスであり（現在はTerraformにも対応）、「IaCの実行基盤の上に、統制レイヤーを被せている構造」と言えます。
では実際に、どのように利用するのかを簡単に見ていきます。
実践 ── 実際に使ってみる（ハンズオン）
ここではシンプルな例として、IAMグループを作成する製品をAWS Service Catalogで公開し、実際に利用してみます。
前提
- AWSリージョン：東京リージョン（ap-northeast-1）
- 動作確認日：2026年5月
今回AWS Service Catalogの製品に登録するCloudFormationテンプレートは以下のとおりです。
AWSTemplateFormatVersion: '2010-09-09'
Description: IAM Group Creation Template for Service Catalog
Parameters:
GroupName:
Type: String
Description: Name of the IAM Group to create
AllowedPattern: '[a-zA-Z0-9+=,.@_-]+'
ConstraintDescription: Must be a valid IAM group name
Resources:
IAMGroup:
Type: AWS::IAM::Group
Properties:
GroupName: !Ref GroupName
Outputs:
GroupArn:
Description: ARN of the created IAM Group
Value: !GetAtt IAMGroup.Arn
AWS Service Catalogの管理者、利用者にはそれぞれ以下のポリシーをアタッチしています。（どちらもAWS管理のポリシーです。）
- 管理者：AWSServiceCatalogAdminFullAccess
- 利用者：AWSServiceCatalogEndUserFullAccess
①管理者側の作業（製品/ポートフォリオ作成、登録など）
管理者は、利用者向けに標準化されたインフラテンプレート（CloudFormationテンプレート）を製品として登録し、ポートフォリオを通じて公開できます。
製品の作成
AWS Service Catalogで「製品の作成」を押下
今回は、IAMグループを定義するCloudFormationテンプレート（YAMLファイル）をアップロードし、製品に登録
ポートフォリオの作成/製品の登録
ポートフォリオの作成を押下
ポートフォリオ名を入力し、作成を押下
ポートフォリオが作成されていることを確認 （※この時点では空のポートフォリオ）
作成したポートフォリオに製品を登録
製品タブにて、「ポートフォリオに製品を追加」を押下
先ほど作成した製品「IAMグループテスト」を選択し、「ポートフォリオに製品を追加」を押下
ポートフォリオに製品が追加されていることを確認
製品起動時の制約を設定
※起動時のIAMロールを指定することが可能であるため、ユーザー側に権限を与える必要がない
ポートフォリオへのアクセス権をユーザーに追加
※アクセス権を付与しないと、製品が表示されない
②利用者側の作業（製品の起動）
利用者は、公開された製品を選択し、必要なパラメータを入力して起動できます。
製品の起動
必要な情報（今回はIAMグループ名）を入力し、「製品を起動」を押下
製品が作成されていることを確認
考察 ── なぜ「必要そうなのに使われない」のか
単なる機能不足ではなく、設計思想と現実のギャップがあると考えています。
実際に今回のハンズオンで検証した範囲でも、製品の登録からポートフォリオの作成、制約の設定まで、管理者側の初期セットアップに一定の工数がかかることを実感しました。特に、既にTerraformでCI/CDパイプラインを構築済みの環境にAWS Service Catalogを追加導入する場合、既存ワークフローとの整合性をどう取るかが課題になります。
以下では、この構造的なギャップについて5つの観点から掘り下げます。
1. Terraform中心の運用モデルとのギャップ
成熟したクラウド運用組織では、Terraform を中心とした GitOps 型の IaC 運用が広く採用されています。
（HashiCorp の「State of Cloud Strategy Survey」や JetBrains の「Developer Ecosystem Survey」などでも、Terraform は IaC 分野で高い利用率を占めています。また、6sense の調査によると、Terraform は構成管理ツール分野で市場シェア約36%を占め、1位に位置しています。）
GitOpsとは、Gitリポジトリを唯一の信頼源（Single Source of Truth）とし、インフラやアプリケーションの変更をすべてGit経由で管理・適用する運用モデルです。
※以下の画像はAIにより生成しています。
Terraform は AWS / Azure / GCP を横断して利用できるため、マルチクラウドやハイブリッド構成との親和性が高く、多くの組織では以下のような運用が一般的です。
- Git を唯一の変更ソースとする
- Pull Request ベースでレビューする
- CI/CD 経由で plan / apply を実行する
- tfstate を集中管理する（Terraform では、tfstate が「現在のインフラ状態」を表す基準となるため、この state 管理が運用の中心になります。）
- drift（実環境との差分）を継続監視する
つまり Terraform では、「インフラ変更そのもの」を継続的に管理することが運用の中心です。
一方 AWS Service Catalog は、もともと CloudFormation を前提に設計された「承認済みインフラを安全に払い出すためのカタログ基盤」です。
利用者は、
- 承認済みテンプレートを選択する
- 必要なパラメータを入力する
- 制約付きでセルフサービス利用する
という形でインフラを利用します。
そのため AWS Service Catalog は、「変更管理」よりも「標準化された環境の配布」に主眼があります。
現在では Terraform 製品にも対応していますが、前述のとおり Terraform では Git を信頼源とした Pull Request ベースの変更管理や CI/CD 経由の plan/apply が運用の中心であり、AWS Service Catalog の設計思想とは依然としてギャップがあります。
しかし AWS Service Catalog は、「どの製品を払い出したか」を管理する設計であり、Terraform の state 管理や GitOps ワークフローそのものを中心には設計されていません。
その結果、
- Terraform 標準の plan/apply サイクル
- Atlantis や Terraform Cloud との統合
- GitOps ベースの継続運用
- Platform Engineering 的なセルフサービス
とは、一部で責務や思想がズレやすくなります。
つまり AWS Service Catalog は、「Terraform に統合された」というより、「Terraform テンプレートも扱えるカタログになった」に近いと言えます。
特に近年は、
- AWS + Azure
- AWS + GCP
- SaaS を含むハイブリッド構成
などを前提とするケースも増えており、多くの組織では AWS 固有の統制モデルより、「クラウド横断で統一された運用モデル」が優先される傾向があります。
そのため、AWS Service Catalog の AWS ネイティブな統制思想は一部の組織には非常に適合する一方、Terraform 中心の運用文化とは必ずしも一致しない場合があります。
2.「承認済み環境の配布」に強みがある一方、動的運用との相性に差がある
AWS Service Catalog の基本思想は、管理者が承認済みリソースを用意し、利用者が選択して払い出すというモデルです。
しかし現在は、
- Ephemeral Environment
- Self-Service API
- Dynamic Provisioning
のように、「必要に応じて自動生成・自動破棄する」運用が増えています。
その結果、
- 固定的なカタログ運用
- 長寿命リソース前提
が現代のクラウドネイティブ運用と噛み合いにくくなっています。
3. AWS Organizations / Control Tower に役割が吸収された
AWS 環境の統制において、現在は以下のサービスが中心的な役割を担っています。
- AWS Organizations
- AWS Control Tower
- IAM Identity Center
- SCP（Service Control Policies）
特に大規模環境では、「アカウント単位の統制」が主軸になるケースが多く、AWS Service Catalog 単体が統制基盤の中心になることは減っています。
しかし実際には、AWS Service Catalog は AWS の統制基盤内部コンポーネントとして現在も重要な役割を担っています。
例えば Control Tower の Account Factory では、AWS Service Catalog を利用して標準化された AWS アカウントを払い出しています。
ただし利用者からは AWS Service Catalog の存在が見えにくいため、「AWS Service Catalog を直接利用している」という認識が生まれにくい構造になっています。
4. Platform Engineering の潮流とズレがある
近年は「Platform Engineering」という考え方が急速に普及しています。
これは、開発者がセルフサービスで安全かつ迅速にインフラやツールを利用できる「内部開発者プラットフォーム（IDP）」を構築・運用する取り組みです。
Platform Engineering では、
- Backstage
- Port
- Humanitec
などの IDP が注目されています。
これらは単なるインフラ払い出しではなく、
- Developer Portal
- CI/CD 統合
- Software Catalog
- Golden Path 提供
- Self-Service API
などを含め、Developer Experience（開発者体験）全体を設計対象にしています。
一方 AWS Service Catalog は、「承認済みインフラの提供」には強みがあるものの、Developer Experience 層やソフトウェアライフサイクル全体の統合までは主目的としていません。
つまり AWS Service Catalog は、「Developer Platform」そのものというより、「統制された AWS リソースを提供するためのガバナンスレイヤー」に近い性質を持っています。
5. 導入効果が見えにくい
AWS Service Catalog は単体導入だけで劇的な効果が出るサービスではありません。
実際には、
- 組織設計
- 権限設計
- IaC 標準化
- 運用プロセス整理
まで含めて初めて価値が出ます。
そのため、
- 導入コストが高い
- 学習コストが高い
- 運用設計が難しい
という課題があります。
特にスタートアップや中規模組織では、Terraform + GitHub Actions などの組み合わせで十分に運用できるケースも多く、AWS Service Catalog を導入する必然性が生まれにくい状況があります。
AWS Service Catalogが効果的なケース
AWS Service Catalog は、「クラウド全体の開発者プラットフォーム」として見ると弱みがありますが、用途を限定すると非常に強力です。
特に、「自由度よりも統制・再現性・標準化を重視する環境」では大きな価値を発揮します。
代表的なユースケースを紹介します。
ケース1：標準環境の払い出し
例えばインフラチームが、
- 標準VPC
- 標準IAM Role
- 標準EC2構成
- 標準EKSクラスタ
- 標準S3設定
などを事前承認済みテンプレートとして提供します。
利用部門は、
- セキュリティレビュー済み
- コスト設計済み
- 監査対応済み
の環境をセルフサービスで利用できます。
このモデルでは、
- 統制
- 再現性
- ガバナンス
が非常に重要であり、AWS Service Catalog の思想と一致します。
ケース2：AWSアカウント払い出し基盤
現在の AWS 大規模運用では、「アカウント＝環境境界」として扱うケースが増えています。
例えば：
- 開発用アカウント
- 検証用アカウント
- 本番アカウント
- プロジェクト専用アカウント
を自動払い出しするケースです。
特に AWS Control Tower の Account Factory は、内部的に AWS Service Catalog を活用しています。
この用途では、
- 命名規則
- SCP適用
- 権限境界
- ログ設定
- ネットワーク標準
を一括適用できるため、非常に相性が良いです。
ケース3：CloudFormationのみを利用している組織
組織全体が CloudFormation ベースで統一されている場合は、AWS Service Catalog の価値が大きく上がります。
例えば：
- AWS専業企業
- AWS依存度が高い組織
- マルチクラウド戦略を取らない組織
では、
- IAM
- Organizations
- CloudFormation
との統合メリットを最大化できます。
この場合、Terraform との競合問題も発生しません。
まとめ
AWS Service Catalog は、単なる「CloudFormation のカタログ機能」ではなく、
AWS上で統制されたセルフサービス環境を実現するためのガバナンス基盤です。
実際に触ってみると、
- 標準化された構成の再利用
- 権限を分離したセルフサービス提供
- 組織的な統制
を実現できる点は非常に強力であり、特に大規模組織や厳格なセキュリティ統制が必要な環境では今でも有効な選択肢です。
一方で、現在のクラウド運用は、
- Terraform を中心としたマルチクラウド運用
- GitOps
- Platform Engineering
へ大きくシフトしています。
その結果、AWS Service Catalog が前提としている
- カタログ型のセルフサービス提供
- Console ベースの運用フロー
- 払い出し型
- 中央集権的統制
という思想との間にギャップが生まれています。
つまり、AWS Service Catalog が広く普及しない理由は、単なる機能不足ではなく、「現代的なクラウド運用モデルとの構造的なズレ」にあると言えます。
ただし逆に言えば、
- AWS に強く統一された環境
- ガバナンスを重視する大企業
- 標準化された環境配布
- アカウント払い出し基盤
といったユースケースでは、現在でも非常に有効です。
重要なのは、「モダンな開発者プラットフォーム」として評価するのではなく、「AWS統制基盤の一部」として位置づけることではないでしょうか。
本記事がAWS Service Catalogの導入判断の参考になれば幸いです。ご質問やご意見がありましたら、ぜひコメントでお聞かせください。
参考文献
- AWS Service Catalog ドキュメント
- Terraform 製品の使用開始 - AWS Service Catalog 管理者ガイド
- Account Factory でのアカウントのプロビジョニングと管理 - AWS Control Tower
- Terraform Market Share - 6sense
関連記事
- 【GitOps】～基礎編～ GitOpsとは何か？ - Qiita
- プラットフォーム・エンジニアリングとは何か - Qiita
- 【初心者向け】Terraformってなに？簡単に整理してみた - Qiita
- AWS Service Catalogの超詳細解説 - Qiita