インフラチームへのリクエストが積み重なり、審査と展開に何日もかかるようになる。だからといって開発者全員にコンソール権限を与えれば、セキュリティ設定の漏れやコスト爆発が起きる。この板挟みは、クラウドを本格展開しているチームが必ず直面する問題だ。
AWS Service Catalogは「承認済みのCloudFormationテンプレートを製品としてカタログ化し、開発者がセルフサービスで選んで使える仕組み」を提供するAWSサービスだ。インフラチームは「何を使ってよいか」を定義し、開発チームは「いつ使うか」を決める。この役割分担によって、スピードとガバナンスを同時に実現できる。この記事では、ポートフォリオ・製品・制約という3つのコアコンセプトの設計から、AWS Organizationsを使ったマルチアカウント展開、Launch Roleの権限設計まで、現場で使えるポイントを整理する。
なぜセルフサービスプロビジョニングが必要なのか（オンプレとの構造的な違い）
オンプレミスでは、インフラリクエストは「申請→承認→構築」という手順で処理される。時間はかかるが、設定は専任チームが担うため品質が均一に保たれる。クラウドに移行すると状況が変わる。コンソールにアクセスできれば誰でも数分で環境を作れる一方、セキュリティグループのインバウンドを全開にしたまま放置する、費用の大きいインスタンスタイプを誤選択するといった問題が発生しやすくなる。
この問題を解消しようとすると、大きく2つのアプローチが出てくる。「強い権限制限でコンソール操作を禁止する」か、「安全なテンプレートだけを使わせる仕組みを作る」かだ。前者はスピードを損ない、後者こそがAWS Service Catalogが解決しようとしている課題だ。
特にマルチアカウント環境では、アカウントをまたいで同じ品質の製品を提供する必要があり、個別のCloudFormationテンプレート管理だけでは限界が来る。Service Catalogは「ガバナンスの一元管理」と「各チームへの権限委任」を両立させるための設計ツールとして機能する。
AWS Service Catalogの全体像
AWS Service Catalogは以下の要素で構成される。
・ポートフォリオ（Portfolio）: 製品をグループ化したもの。IAMユーザー・グループ・ロールやAWS OrganizationsのアカウントIDまたはOUに共有できる
・製品（Product）: 承認済みのCloudFormationテンプレート（またはTerraform設定）を1つのバージョン管理されたエンティティとして扱うもの
・制約（Constraint）: 製品の起動方法・タグ・通知に関するルール。エンドユーザーの操作範囲を絞り込む
・プロビジョニングされた製品（Provisioned Product）: ユーザーが実際に起動した製品のインスタンス。CloudFormationスタックとして管理される
ユーザーの視点では「Service Catalogのポータルから製品を選んでパラメータを入力するだけ」で環境が立ち上がる。裏側でCloudFormationが動き、インフラが作られる。エンドユーザーはEC2やRDSに対する直接の権限を持たなくてもよく、必要なのはService Catalogのservicecatalog:ProvisionProduct権限だけだ。
3つのコアコンセプトを理解する
1. ポートフォリオ（Portfolio）
ポートフォリオは「製品の入れ物」だ。たとえば「Webアプリ基盤ポートフォリオ」「データ分析基盤ポートフォリオ」のようにテーマ別に分類するのが一般的な設計だ。ポートフォリオを作成したアカウント（管理アカウント）が所有し、他のアカウントや組織に共有できる。
共有方法は2種類ある。
・アカウント単位の共有: 個別のAWSアカウントIDを指定して共有する
・Organizations連携での共有: OUまたは組織ルートに共有する。配下の全アカウントに自動的に展開できる
受け取り側のアカウントでは「インポートされたポートフォリオ」として表示され、管理アカウントが製品を更新するとインポート済みポートフォリオに自動反映される。
2. 製品（Product）
製品の実体はCloudFormationテンプレート（または外部リポジトリに置かれたTerraform設定）だ。製品にはバージョン管理の概念があり、テンプレートを更新するたびに新バージョンを追加できる。既存のプロビジョニング済み製品は旧バージョンのまま動き続け、アップデートをいつ適用するかはエンドユーザーが選択できる。
製品を作成する際には以下を設定する。
・名前と説明: ユーザーがカタログから選ぶときに表示される
・オーナー情報: 連絡先としてのチーム名・メールアドレスなど
・サポート情報: ドキュメントURLや問い合わせ先
・テンプレートソース: S3 URL（CloudFormation）またはTerraform設定
3. 制約（Constraint）
制約はService Catalogの中でも特に重要なコンセプトだ。以下の種類がある。
・Launch制約: 製品を起動する際に使うIAMロールを指定する。エンドユーザーが直接持たないリソース権限をLaunch Roleに持たせることで、最小権限を維持しながらプロビジョニングを可能にする
・テンプレート制約: CloudFormationパラメータの選択肢を絞り込む（例: インスタンスタイプをt3.mediumとt3.largeの2択に制限）
・通知制約: スタックイベントをSNSトピックに通知する
・リソース更新制約: エンドユーザーがプロビジョニング後にタグを変更できるかどうかを制御する
・StackSet制約: StackSetとして複数リージョン・複数アカウントに展開する際のデプロイオプションを設定する
Launch制約の設計が全体のセキュリティモデルを左右する。詳細は後述の「運用設計のポイント」で取り上げる。
製品を作って展開する手順
ここではAWS CLIを使ったセットアップの流れを示す。コンソールGUIでも同じ操作ができるが、IaCとして管理するならCLIが適している。
1. CloudFormationテンプレートの準備
まずS3にテンプレートをアップロードする。
# AWS CLI（管理アカウントで実行） # S3バケットにテンプレートをアップロード aws s3 cp my-ec2-template.yaml \ s3://my-service-catalog-templates/my-ec2-template.yaml \ --region ap-northeast-1
2. ポートフォリオの作成
# ポートフォリオ作成 aws servicecatalog create-portfolio \ --display-name "Webアプリ基盤ポートフォリオ" \ --description "本番環境向け承認済みEC2・RDS製品" \ --provider-name "インフラチーム" \ --region ap-northeast-1 # 出力される "Id" (例: port-xxxxxxxxxxxx) を控えておく
3. 製品の追加とポートフォリオへの関連付け
# 製品作成 aws servicecatalog create-product \ --name "EC2インスタンス（標準）" \ --owner "インフラチーム" \ --product-type CLOUD_FORMATION_TEMPLATE \ --provisioning-artifact-parameters \ '{"Name":"v1.0","Description":"初版","Type":"CLOUD_FORMATION_TEMPLATE","Info":{"LoadTemplateFromURL":"https://s3.ap-northeast-1.amazonaws.com/my-service-catalog-templates/my-ec2-template.yaml"}}' \ --region ap-northeast-1 # 出力の "ProductViewDetail.ProductViewSummary.ProductId" # (例: prod-xxxxxxxxxxxx) を控えておく # ポートフォリオに製品を関連付け aws servicecatalog associate-product-with-portfolio \ --product-id prod-xxxxxxxxxxxx \ --portfolio-id port-xxxxxxxxxxxx \ --region ap-northeast-1
4. Launch制約の設定
Launch Roleは製品の起動時にCloudFormationが使うIAMロールだ。エンドユーザーがEC2を作る権限を持たなくても、このロール経由でプロビジョニングできる。
# Launch制約を設定（事前にLaunch RoleをIAMで作成しておく） aws servicecatalog create-constraint \ --portfolio-id port-xxxxxxxxxxxx \ --product-id prod-xxxxxxxxxxxx \ --type LAUNCH \ --parameters '{"RoleArn":"arn:aws:iam::123456789012:role/ServiceCatalogLaunchRole"}' \ --region ap-northeast-1
5. IAMプリンシパルへのアクセス付与
# 開発チームのIAMグループにポートフォリオへのアクセスを付与 aws servicecatalog associate-principal-with-portfolio \ --portfolio-id port-xxxxxxxxxxxx \ --principal-arn arn:aws:iam::123456789012:group/DevTeam \ --principal-type IAM \ --region ap-northeast-1
これで開発チームのメンバーがService Catalog UIにアクセスすると「EC2インスタンス（標準）」製品が表示され、パラメータを入力して起動できる。
マルチアカウント展開（AWS Organizations連携）
単一アカウントでの運用に慣れたら、Organizations連携でマルチアカウントへの展開を考える。この仕組みの要点は「管理アカウントで製品を一元管理し、各アカウントには使わせる権限だけを配る」という構造だ。
ポートフォリオ共有の手順（管理アカウントから実行）
# Organizations連携でのポートフォリオ共有（OU単位） aws servicecatalog create-portfolio-share \ --portfolio-id port-xxxxxxxxxxxx \ --organization-node '{"Type":"ORGANIZATIONAL_UNIT","Value":"ou-xxxx-yyyyyyyy"}' \ --share-tag-options true \ --region ap-northeast-1 # 共有を受けたアカウントがインポートする aws servicecatalog accept-portfolio-share \ --portfolio-id port-xxxxxxxxxxxx \ --region ap-northeast-1
Organizations連携で共有したポートフォリオは、OU配下のアカウントに「シェアされたポートフォリオ」として届く。各メンバーアカウントでは管理者がaccept-portfolio-shareを実行するか、AWS Control Towerのアカウントファクトリーと連携した自動受け入れを設定できる。
CloudFormation StackSetsとの使い分け
StackSetsとService Catalogはどちらもマルチアカウント展開に使えるが、用途が異なる。
| 観点 | CloudFormation StackSets | AWS Service Catalog |
|---|---|---|
| 主なユーザー | インフラチーム（一括展開） | 開発チーム（セルフサービス） |
| 制御の粒度 | インフラチームが全体を制御 | 開発者がパラメータを選択 |
| 更新の管理 | インフラチームが一括更新 | 開発者が任意のタイミングで更新 |
| 向いているユースケース | ベースラインリソースの全アカウント展開 | チームごとに環境を作り分ける運用 |
Service CatalogとStackSetsは排他的ではなく、「StackSetsでベースライン（VPCやIAMロール等）を全アカウントに展開し、Service Catalogでアプリ環境のセルフサービスを提供する」という組み合わせが実務では多い。詳しいStackSetsの設定はAWS CloudFormation StackSets実践入門も参照してほしい。
料金の仕組みと実務コスト感覚
AWS Service Catalog自体には追加料金がない。ポートフォリオ・製品の作成・共有・プロビジョニングのAPI呼び出しに対する課金は発生しない（2026年10月時点）。コストが発生するのは、プロビジョニングされたAWSリソース（EC2・RDS・S3等）の通常料金のみだ。
ただし間接的なコスト要因として以下がある。
・S3のテンプレート保管: CloudFormationテンプレートをS3に置く場合の通常のS3料金（数十テンプレートなら月数円程度）
・SNS（通知制約）: 通知制約を設定した場合のSNSメッセージング料金
・CloudTrailのAPIログ: Service Catalog操作もCloudTrailに記録される（CloudTrailの通常料金）
Service Catalog自体がコスト要因になることはほぼないため、導入の費用対効果は「運用工数の削減」で測るのが実態に近い。
運用設計のポイント（実務Tips）
【重要】Launch Roleの権限設計
Launch Roleは「製品を起動するためだけに使うIAMロール」だ。このロールにどの権限を持たせるかが、Service Catalog全体のセキュリティモデルを左右する。
よくある落とし穴は「エンドユーザーがProvisioned Productを更新するとき、Launch Role経由でCloudFormationが動く」という点だ。そのためLaunch RoleはCreate権限だけでなくUpdate・Delete権限も必要になる。CloudFormationの実行に必要なcloudformation:*と対象リソース（ec2:*など）の権限を持たせる一方、iam:*を広く持たせると意図しない権限昇格の経路になるため、IAM関連は必要最小限に絞るのが原則だ。
IAM Permission BoundariesとLaunch Roleを組み合わせると、Launch Roleが作成するIAMロールの権限上限を制御できる。マルチアカウント環境での委任管理を安全に実現したい場合に有効な設計パターンだ。
製品バージョン管理の運用ルール
製品にはバージョンが付き、古いバージョンを削除しなければ複数バージョンが並存する。運用上は以下のルールが有効だ。
・旧バージョンは「非アクティブ」に設定し、新規プロビジョニングに使えなくする（既存のプロビジョニング済み製品には影響しない）
・バージョン説明欄に変更内容と日付を記載する
・テンプレートの変更は既存のProvisioned Productの「更新」動作に影響するため、事前に検証環境で動作を確認する
TagOptionsライブラリを使ったタグガバナンス
Service CatalogのTagOptionsライブラリは、ポートフォリオや製品に「使えるタグキーと値の候補」を定義する機能だ。エンドユーザーはTagOptionsで定義されたキーのみを付与でき、自由入力によるタグ名のゆらぎを防げる。たとえばEnvironmentタグの値をdev / staging / prodの3択に固定するといった使い方が典型だ。
TagOptionsはポートフォリオ単位で管理でき、ポートフォリオを複数アカウントに共有するときに--share-tag-options trueオプションを付けると、組織全体でタグポリシーを統一できる。
AWS Control TowerのAccount Factoryとの連携
AWS Control TowerのAccount Factoryは、新しいAWSアカウントを作成する際に承認済みベースライン設定を自動適用する仕組みだ。Service Catalogとは直接連携しており、Account Factory自体がService Catalogの製品として実装されている。新しいアカウントに自動でポートフォリオを受け入れさせるカスタマイズも可能だ。
よくあるトラブルと対処法
プロビジョニングが「IN_PROGRESS」のまま止まる
CloudFormationスタックが作成中のまま進まないケースは、Launch RoleにCloudFormation実行権限が足りないことが多い。CloudFormationコンソールで該当スタックのイベントを確認し、「IAMロールにXXXの権限がない」というエラーメッセージを読むとすぐ特定できる。一般的にはLaunch Roleにcloudformation:*と対象リソースの権限を追加して解消する。
Organizations共有でメンバーアカウントに製品が表示されない
管理アカウントでOrganizationsポートフォリオ共有を設定しても、受け取り側アカウントでaccept-portfolio-shareを実行していないと製品が表示されない。Control Towerのアカウントファクトリーと連携している場合は自動受け入れを設定できるが、手動展開環境では漏れやすい。台帳管理で「受け入れ済みアカウント」を追跡するか、AWS Configで未受け入れを検知する仕組みを作ると安心だ。
テンプレート制約でパラメータが選択肢に表示されない
テンプレート制約はCloudFormationテンプレート側に定義されていないパラメータキーを参照しても無視される。テンプレートのパラメータ名と制約のRulesセクションのパラメータ名が一致しているか確認する。
エンドユーザーが「更新」を実行すると意図しないリソース変更が起きる
Service Catalogの「製品を更新」はCloudFormationのスタック更新と同等だ。パラメータ変更の内容によってはEC2の再起動やRDSのスナップショット作成を伴う。エンドユーザー向けにどのパラメータが変更可能で変更時の影響が何かをドキュメント化しておくか、テンプレート制約でパラメータを固定するのが安全だ。
本記事のまとめ
| コンセプト | 役割 | 設計のポイント |
|---|---|---|
| ポートフォリオ | 製品をグループ化・アカウントに共有 | テーマ別（アプリ基盤/データ基盤等）に分割するとライフサイクル管理が楽 |
| 製品 | 承認済みCloudFormationテンプレートのバージョン管理 | 旧バージョンは非アクティブに設定して混在を防ぐ |
| Launch制約 | 起動時に使うIAMロールを指定 | Permission Boundariesと組み合わせて権限昇格を防ぐ |
| テンプレート制約 | パラメータの選択肢を絞り込む | インスタンスタイプや環境名を限定してガバナンスを保つ |
| TagOptions | タグキー・値の候補を定義 | ポートフォリオ共有時に--share-tag-options trueで伝搬させる |
| Organizations連携 | OU単位でポートフォリオを共有 | StackSetsとの組み合わせで「ベースライン+セルフサービス」を両立 |
AWS Service Catalogが真価を発揮するのは「チームが増えてきて、アドホックなリクエスト対応が追いつかなくなってきた」タイミングだ。まず単一アカウントで1つのポートフォリオを作り、Launch Roleの動作を確認してから段階的にアカウント数を増やすのが現実的な導入順序だ。
既存のCloudFormationテンプレート資産をService Catalogに登録するだけでも、可視性とガバナンスは大きく改善する。まずは既存テンプレートを1本選んでポートフォリオに追加するところから始めてみてほしい。マルチアカウント運用の全体像についてはAWS Organizations入門も合わせて参照すると理解が深まる。
PR
AWS上のシステム設計をアーキテクチャレベルで体系的に解説した実践書。Service Catalogを含むIaC設計・マルチアカウント構成・コスト最適化まで現場視点でまとめられており、本記事と合わせて読むと設計判断の引き出しが広がる。
