AWS Service CatalogとCloudFormationで標準テンプレートを配布する考え方

Last updated at 2026-08-27Posted at 2026-08-24

はじめに

CloudFormationテンプレートを作れるようになると、次に出てくる悩みがあります。

チーム全員にテンプレートを配りたい
ただし、誰でも自由に大きなEC2やRDSを作れる状態にはしたくない
承認済みの構成だけを、セルフサービスで使えるようにしたい
権限、タグ、パラメータ、バージョンを管理したい

このときに使う候補が AWS Service Catalog です。

この記事では、 CloudFormationは設計図、Service Catalogは承認済みメニュー という見方で、両者の関係を整理します。

この記事でわかること

AWS Service CatalogとCloudFormationの役割の違い
Portfolio、Product、Provisioned productの意味
Launch constraintとTemplate constraintで何を制御するか
CloudFormationテンプレートをService Catalogの製品として配布する流れ
Git管理したテンプレートをコンソール、S3＋CLI、Git直接同期で登録する違い
マルチアカウント、マルチリージョンで使うときの考え方
最小構成のCloudFormation例とAWS CLI例

先に結論

CloudFormationとService Catalogは、競合するものではありません。
役割が違います。

項目	CloudFormation	AWS Service Catalog
ざっくり言うと	AWSリソースを作る設計図	承認済みテンプレートを配るメニュー
主な利用者	インフラ担当、開発者、運用担当	管理者、エンドユーザー
管理するもの	テンプレート、スタック、変更差分	Portfolio、Product、権限、制約、バージョン
強いところ	構成をコード化できる	標準構成を安全に配布しやすい
注意点	使う人にAWS権限が必要になりやすい	管理設計を作らないと運用が重くなる

個人学習や小さな検証なら、まずCloudFormationだけで十分です。
複数チームに標準構成を配る、利用者に強いAWS権限を渡したくない、承認済みメニュー化したい場合にService Catalogが効きます。

前提

対象読者: CloudFormationは少し触ったことがあり、Service Catalogの位置づけを知りたい人
確認日: 2026-08-08
扱う範囲: CloudFormationテンプレートをService Catalog製品として配布する基本設計
扱わない範囲: AWS Organizationsでの大規模共有、Terraform製品、Control Tower連携、承認ワークフローの完全実装
注意: 料金、UI、制限、対応リージョン、CLIの詳細は変わるため、実作業前にAWS公式ドキュメントを確認してください

この記事のコードは説明用の最小例です。
本番環境では、IAM権限、S3バケットポリシー、KMS、タグ設計、ログ、料金、削除方針を必ず確認してください。

用語の短い説明

用語	短い説明
CloudFormation	AWSリソースをテンプレートで定義し、スタックとして作成・更新・削除するサービス
Service Catalog	組織で承認したITサービスやIaCテンプレートを、利用者へ配布・管理するサービス
Portfolio	Productをまとめる入れ物。部署、用途、環境単位で分けることが多い
Product	利用者に提供するメニュー。CloudFormationテンプレートやTerraform構成などを元に作る
Provisioning artifact	Productのバージョン。`v1`、`v2` のように管理する
Provisioned product	Productから実際に起動されたもの。CloudFormation製品なら裏側にスタックが作られる
Launch constraint	利用者の代わりにService Catalogが引き受けるIAMロールを指定する制約
Template constraint	起動時に入力できるパラメータ値を制限する制約

全体像

Service Catalogを使うと、管理者と利用者の責任を分けやすくなります。

ポイントは、利用者が直接CloudFormationテンプレートを自由に実行するのではなく、 管理者が承認したProductを選んで起動する ことです。

CloudFormationだけでよいケース

次のような場合は、Service Catalogまで入れなくても運用できます。

ケース	理由
個人学習	管理対象が少なく、権限分離より学習速度が大事
1人または少人数の検証	テンプレートをGitで管理すれば十分なことが多い
管理者だけがデプロイする	エンドユーザー向けのセルフサービス化が不要
テンプレートが頻繁に変わる	Product化より、まずCloudFormationの設計を固める方が先

Service Catalogは便利ですが、導入するとPortfolio、Product、権限、制約、バージョン、運用ルールが増えます。
目的がないまま入れると、単に管理対象が増えます。

Service Catalogを使うとよいケース

Service Catalogが効くのは、 標準化したものを、権限を絞って、何度も配る 場面です。

ケース	Service Catalogが効く理由
開発者に標準S3バケットを作らせたい	パブリックアクセス禁止、暗号化、タグを標準化できる
検証用EC2をセルフサービス化したい	インスタンスタイプやAMIを制限しやすい
RDS構成を承認済みパターンに寄せたい	Multi-AZ、バックアップ、削除方針を標準化しやすい
複数部署へ同じ構成を配りたい	Portfolio単位でアクセス制御しやすい
利用者に強いIAM権限を渡したくない	Launch constraintで起動ロールを使える

AWS公式ドキュメントでも、Service Catalogの管理者はCloudFormationテンプレート、制約、IAMロールを準備し、利用者へ製品として提供する整理になっています。

まず押さえる設計単位

Service Catalogは、次の順番で考えると分かりやすいです。

順番	設計するもの	例
1	Productの元になるCloudFormationテンプレート	標準S3、標準EC2、標準RDS
2	Product名とバージョン	`standard-private-s3-bucket` / `v1`
3	Portfolio	`dev-standard-products`
4	利用できるIAM principal	`DeveloperRole`、`PlatformUserGroup`
5	Launch constraint	Service Catalogが引き受ける起動ロール
6	Template constraint	入力できる環境名、サイズ、リージョンなど
7	更新・廃止ルール	`v1` を残すか、`v2` へ誘導するか

最初から大きなカタログを作るより、 小さなProductを1つ作って、起動・更新・削除まで確認する 方が失敗しにくいです。

Git管理したCloudFormationテンプレートをどう取り込むか

結論から言うと、 S3へのアップロードは必須ではありません。
CloudFormationテンプレートをGitで管理している場合、主に次の3方式があります。

方式	マネジメントコンソール	AWS CLI	自分で管理するS3	向いている場面
ローカルファイルをコンソールから登録	必要	不要	不要	初回学習、小規模な検証
S3へ配置してCLIから登録	不要	必要	必要	CI/CD、明示的なバージョン管理
外部Gitリポジトリと直接同期	初回接続で使用	接続後はCLIでも操作可能	不要	Gitを正本にしてProductの版を自動作成したい場合

マネジメントコンソールだけでも作成できる

Service Catalogの管理者画面では、Product作成時のテンプレート取得元として次を選べます。

ローカルPCにあるCloudFormationテンプレート
Amazon S3に置いたテンプレートのHTTPS URL
GitHub、GitHub Enterprise、Bitbucketの外部リポジトリ
既存のCloudFormationスタック

ローカルファイルを使う最小手順は次のとおりです。

AWSマネジメントコンソールでService Catalogを開く
管理者画面の「製品」から「製品を作成」を選ぶ
製品タイプでCloudFormationを選ぶ
バージョン詳細でローカルテンプレートファイルを選ぶ
Product名、所有者、バージョン名を入力して作成する
PortfolioへProductを追加する
利用者のIAMロールとLaunch constraintを設定する
利用者画面から起動し、CloudFormationスタックと実リソースを確認する

この方法ならAWS CLIも自分で用意するS3バケットも不要です。
ただし、Gitの更新とProductの新バージョン作成は自動では連動しません。テンプレートを変更するたびに、管理者が新しいバージョンを登録します。

CLI中心ならS3経由が分かりやすい

CLIだけでProductを作る場合は、次の流れが単純です。

Gitから対象バージョンのテンプレートを取得する
validate-templateやcfn-lintで検査する
テンプレートをS3へアップロードする
S3のHTTPS URLをLoadTemplateFromURLに指定する
create-productまたはcreate-provisioning-artifactでProductのバージョンを作る

この方式は、AWS認証と必要なIAM権限があればコンソール操作なしで実行できます。
同じS3オブジェクトを上書きするのではなく、次のようにバージョンごとのキーへ保存する方が、Productの版とテンプレートを対応させやすくなります。

S3 URI例

s3://your-catalog-template-bucket/service-catalog/standard-s3/v1.0.0/template.yaml
s3://your-catalog-template-bucket/service-catalog/standard-s3/v1.1.0/template.yaml

Gitリポジトリと直接同期できる

Service Catalogには、外部Gitリポジトリ内のテンプレートとProductを直接同期する機能があります。
対応するリポジトリは、AWS公式ドキュメント上ではGitHub、GitHub Enterprise、Bitbucketです。

リポジトリは、例えば次のように分けます。構成はtreeコマンドで確認すると分かりやすくなります。

ターミナル

# Git管理するテンプレートとService Catalog設定の配置を確認する
tree -a -I '.git' infra-catalog

実行結果

infra-catalog/
├── .github
│   └── workflows
│       └── validate-cloudformation.yml
├── products
│   └── standard-s3
│       └── template.yaml
└── service-catalog
    └── create-git-synced-product.json

5 directories, 3 files

products/standard-s3/template.yamlをProductの同期対象にし、Pull Requestではcfn-lintやレビューを行います。
承認後に同期対象ブランチへマージすると、Service Catalogが対象ファイルの変更を検知します。

リポジトリの対象テンプレートへ変更をコミットすると、Service Catalogが変更を検知し、新しいProductバージョンを作成します。
前のバージョンは規定の上限まで維持され、古い版には非推奨の状態が設定されます。

コンソールで設定する場合は、Product作成時に「外部リポジトリを使用」を選び、接続、リポジトリ、ブランチ、テンプレートのパスを指定します。

接続が利用可能になった後は、CLIでもGit同期Productを作成できます。

create-git-synced-product.json

{
  "Name": "standard-private-s3-bucket",
  "Owner": "Cloud Platform Team",
  "Description": "Private S3 bucket managed from a Git repository.",
  "ProductType": "CLOUD_FORMATION_TEMPLATE",
  "SourceConnection": {
    "Type": "CODESTAR",
    "ConnectionParameters": {
      "CodeStar": {
        "ConnectionArn": "CONNECTION_ARN",
        "Repository": "your-organization/infra-catalog",
        "Branch": "main",
        "ArtifactPath": "products/standard-s3/template.yaml"
      }
    }
  }
}

ターミナル

# 接続済みのGitリポジトリをソースにしてProductを作る
aws servicecatalog create-product \
  --cli-input-json file://create-git-synced-product.json \
  --region ap-northeast-1

Repositoryは所有者名/リポジトリ名、ArtifactPathはリポジトリ内のテンプレートパスです。
API上の接続タイプ名はCODESTARですが、AWSの画面や現在のサービス名ではCodeConnectionsと表示される場合があります。

日常の更新は次の流れになります。

ターミナル

# Productのテンプレートを変更する作業ブランチを作る
git switch -c update-standard-s3-v2

# 変更後のCloudFormationテンプレートをローカルで検査する
cfn-lint products/standard-s3/template.yaml

# 変更をGitへ記録し、リモートへ送る
git add products/standard-s3/template.yaml
git commit -m "標準S3 Productを更新"
git push -u origin update-standard-s3-v2

Pull Requestをレビューしてmainへマージすると、同期対象がmainの場合はService Catalog側に新しいProvisioning artifactが作成されます。
作成後はService CatalogのProduct詳細で同期状態と新バージョンを確認し、すぐに既定版として利用させるか、検証後に案内するかを判断します。

AWS CLIやCloudFormationで外部リポジトリ接続を新規作成しただけでは、接続はPENDINGになります。
GitHubなどとの認証ハンドシェイクをコンソールで完了し、接続をAVAILABLEにする必要があります。最初から完全にCLIだけでGit認証まで終える運用ではない点に注意してください。

CloudFormation Git syncとの違い

名前が似ていますが、CloudFormationにもGit syncがあります。

機能	更新されるもの	主な用途
CloudFormation Git sync	CloudFormationスタック	Gitの変更から特定環境のスタックを直接更新する
Service CatalogのGit同期	Service Catalog Productのバージョン	承認済みテンプレートを複数の利用者へ配布する

単一システムのスタックをGitから継続デプロイしたいだけなら、CloudFormation Git syncやCI/CDで十分な場合があります。
複数の利用者に「選んで起動できる標準メニュー」として提供したい場合は、Service CatalogのGit同期が合います。

実務でのおすすめ運用

最初は次の順で導入すると、問題を切り分けやすくなります。

ローカルテンプレートをCloudFormationで直接起動し、正常に作成・更新・削除できることを確認する
Gitへ保存し、Pull Requestでcfn-lintとレビューを通す
Service Catalogのローカルファイル登録で、Product起動まで試す
運用を自動化する段階で、Git直接同期またはS3＋CLI方式へ切り替える
Productの旧バージョンを非推奨にする条件と、既存Provisioned productの更新手順を決める

サンプル: 標準S3バケットをProduct化する

ここでは、CLI＋S3方式を使い、説明用の「標準S3バケット」をService CatalogのProductにする流れを見ます。

構成は次のとおりです。

ターミナル

# サンプルで使用するCloudFormationテンプレートとProduct設定を確認する
tree service-catalog-demo

実行結果

service-catalog-demo/
├── create-product-standard-s3.json
└── product-standard-s3.yaml

1 directory, 2 files

1. Productの元になるCloudFormationテンプレート

まず、利用者に配布するCloudFormationテンプレートを作ります。
ここでは、パブリックアクセスをブロックし、SSE-S3で暗号化するS3バケットの例にします。

product-standard-s3.yaml

AWSTemplateFormatVersion: '2010-09-09'
Description: Standard private S3 bucket for Service Catalog demo

Parameters:
  EnvironmentName:
    # 利用者が選べる環境名。Service Catalog側のTemplate constraintでも制限する
    Type: String
    AllowedValues:
      - dev
      - stg
      - prod

  ProjectName:
    # タグに使うプロジェクト名。バケット名には使わず、グローバル一意制約を避ける
    Type: String
    MinLength: 3
    MaxLength: 32
    AllowedPattern: '^[a-z0-9-]+$'

Resources:
  StandardBucket:
    Type: AWS::S3::Bucket
    # スタック削除時にデータを誤削除しないため、説明用にRetainを付ける
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      # S3バケットのパブリック公開をブロックする
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      # SSE-S3でサーバー側暗号化を有効にする
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      Tags:
        - Key: Environment
          Value: !Ref EnvironmentName
        - Key: Project
          Value: !Ref ProjectName
        - Key: ManagedBy
          Value: ServiceCatalog

Outputs:
  BucketName:
    # 利用者が作成後に確認しやすいよう、バケット名を出力する
    Value: !Ref StandardBucket

DeletionPolicy: Retain を付けると、スタック削除後もS3バケットが残ることがあります。
削除事故は防ぎやすくなりますが、不要リソースの片付け漏れも起きるため、タグと棚卸し運用が必要です。

2. CLI＋S3方式としてテンプレートをS3へ置く

このサンプルでは、Service CatalogのProductとして使うCloudFormationテンプレートをS3のHTTPS URLから読み込ませます。
Git直接同期を選ぶ場合、このS3アップロードは不要です。

ターミナル

# アップロード前にCloudFormationの構文を検証する
aws cloudformation validate-template \
  --template-body file://product-standard-s3.yaml

# Productのv1として固定できるパスへテンプレートをアップロードする
aws s3 cp product-standard-s3.yaml \
  s3://your-catalog-template-bucket/service-catalog/standard-s3/v1/product-standard-s3.yaml

実環境では、テンプレート置き場のS3バケットに対するアクセス権限も設計します。
Productの作成、起動、更新で使う管理者や起動ロールが、必要に応じて対象テンプレートを取得できることを確認します。

3. Portfolioを作る

Portfolioは、Productをまとめる棚です。
部署別、環境別、用途別に分けます。

ターミナル

# 開発者向けの承認済み製品をまとめるPortfolioを作る
aws servicecatalog create-portfolio \
  --display-name "dev-standard-products" \
  --provider-name "Cloud Platform Team" \
  --description "Approved products for development accounts"

戻り値にPortfolio IDが含まれます。
以降のコマンドでは、例として port-xxxxxxxx と表記します。

4. Productを作る

Productは、利用者が選ぶメニューです。
CloudFormationテンプレートをProductとして登録します。

create-product-standard-s3.json

{
  "AcceptLanguage": "jp",
  "Name": "standard-private-s3-bucket",
  "Owner": "Cloud Platform Team",
  "Description": "Public access block and SSE-S3 enabled private S3 bucket.",
  "ProductType": "CLOUD_FORMATION_TEMPLATE",
  "ProvisioningArtifactParameters": {
    "Name": "v1",
    "Description": "Initial version for development use.",
    "Info": {
      "LoadTemplateFromURL": "https://your-catalog-template-bucket.s3.ap-northeast-1.amazonaws.com/service-catalog/standard-s3/v1/product-standard-s3.yaml"
    },
    "Type": "CLOUD_FORMATION_TEMPLATE"
  },
  "Tags": [
    {
      "Key": "ManagedBy",
      "Value": "ServiceCatalog"
    }
  ]
}

ターミナル

# JSONで指定した内容をもとにService Catalog Productを作る
aws servicecatalog create-product \
  --cli-input-json file://create-product-standard-s3.json

戻り値には、Product IDとProvisioning artifact IDが含まれます。
例として、以降は次の値で表します。

ID例

PortfolioId: port-xxxxxxxx
ProductId: prod-yyyyyyyy
ProvisioningArtifactId: pa-zzzzzzzz

5. ProductをPortfolioへ入れる

作ったProductをPortfolioへ関連付けます。

ターミナル

# ProductをPortfolioへ入れて、利用者がPortfolio経由で見つけられるようにする
aws servicecatalog associate-product-with-portfolio \
  --product-id prod-yyyyyyyy \
  --portfolio-id port-xxxxxxxx

6. 利用者にPortfolioへのアクセスを付ける

利用者がProductを見られるよう、IAMロールやIAMグループをPortfolioへ関連付けます。

ターミナル

# 開発者ロールにPortfolioへのアクセスを付ける
aws servicecatalog associate-principal-with-portfolio \
  --portfolio-id port-xxxxxxxx \
  --principal-arn arn:aws:iam::123456789012:role/DeveloperRole \
  --principal-type IAM

ここで付けるのは、Service CatalogのProductを見つけて起動するためのアクセスです。
実際にS3やEC2を作る権限は、後述のLaunch constraintで分けて考えます。

7. Launch constraintを付ける

Launch constraintは、Service CatalogがProductを起動・更新・終了するときに引き受けるIAMロールを指定します。

これにより、利用者へS3作成権限を直接渡さずに、承認済みProductだけを起動させる設計にしやすくなります。

ターミナル

# Product起動時にService Catalogが使うIAMロールを指定する
aws servicecatalog create-constraint \
  --portfolio-id port-xxxxxxxx \
  --product-id prod-yyyyyyyy \
  --type LAUNCH \
  --description "Use controlled launch role for this product." \
  --parameters '{"RoleArn":"arn:aws:iam::123456789012:role/ServiceCatalogLaunchRole"}'

Launch constraintは、ProductとPortfolioの関連に対して効きます。
Portfolio全体へ一括で効くものではないため、Productごとに設定する必要があります。

Launch constraintを使う場合、起動ロールの信頼ポリシー、iam:PassRole、CloudFormation権限、作成対象サービスの権限、テンプレート読み取り権限を確認します。
利用者に強い権限を渡さない代わりに、起動ロールの設計が重要になります。

8. Template constraintで入力値を制限する

Template constraintは、Product起動時に利用者が入力できるパラメータ値を制限します。

例えば、検証用Portfolioでは EnvironmentName を dev と stg だけに制限し、prod を選べないようにできます。

Template constraint

{
  "EnvironmentRule": {
    "Assertions": [
      {
        "Assert": {
          "Fn::Contains": [
            [
              "dev",
              "stg"
            ],
            {
              "Ref": "EnvironmentName"
            }
          ]
        },
        "AssertDescription": "EnvironmentName must be dev or stg in this portfolio."
      }
    ]
  }
}

Template constraintのルールは、CloudFormationテンプレートの Rules セクションに近い考え方です。
エンドユーザーがProductを作成・更新する前に、入力値がルールを満たすかを確認できます。

AWS公式ドキュメントでは、Template constraintはCloudFormation製品向けの制約として説明されています。
Terraform Open SourceやTerraform Cloud製品ではTemplate constraintをサポートしない旨が記載されています。

利用者側の起動イメージ

利用者は、Service Catalogのエンドユーザー画面からProductを選んで起動できます。
CLIで起動する場合は、Product名とバージョン名を指定する形にもできます。

ターミナル

# 承認済みProductを起動し、裏側でCloudFormationスタックを作る
aws servicecatalog provision-product \
  --product-name standard-private-s3-bucket \
  --provisioning-artifact-name v1 \
  --provisioned-product-name dev-sample-private-bucket \
  --provisioning-parameters \
      Key=EnvironmentName,Value=dev \
      Key=ProjectName,Value=sample-app

CloudFormationテンプレートから既存のService Catalog Productを起動する場合は、 AWS::ServiceCatalog::CloudFormationProvisionedProduct も使えます。

provision-existing-product.yaml

AWSTemplateFormatVersion: '2010-09-09'
Description: Provision an existing Service Catalog product

Resources:
  StandardPrivateBucket:
    Type: AWS::ServiceCatalog::CloudFormationProvisionedProduct
    Properties:
      # Product IDではなく名前で指定する例。ID指定と名前指定は混在させない
      ProductName: standard-private-s3-bucket
      # Productのバージョン名を指定する
      ProvisioningArtifactName: v1
      # 作成されるProvisioned product名。アカウント内で一意にする
      ProvisionedProductName: dev-sample-private-bucket
      ProvisioningParameters:
        - Key: EnvironmentName
          Value: dev
        - Key: ProjectName
          Value: sample-app
      Tags:
        - Key: ManagedBy
          Value: CloudFormation

この方法は、アプリケーション側のCloudFormationテンプレートから、管理者が用意した標準Productを呼び出したい場合に使えます。

Service CatalogとCloudFormationの責任分担

実務では、どこまでをCloudFormationに寄せ、どこからをService Catalogに任せるかを決めます。

責任	主に見る場所	具体例
リソース定義	CloudFormationテンプレート	S3、EC2、RDS、IAM、CloudWatch
差分管理	Git、CloudFormation change set	Pull Request、Change set確認
製品メニュー化	Service Catalog Product	標準S3、標準EC2、標準RDS
利用者への公開範囲	Service Catalog Portfolio	開発者向け、運用者向け、部署別
起動時の権限	Launch constraint、IAM	利用者に直接S3作成権限を渡さない
入力値の制御	Template constraint、Parameters	インスタンスタイプ、環境名、バックアップ日数
バージョン管理	Provisioning artifact	`v1`、`v2`、非推奨バージョン

CloudFormationがリソースを作ります。
Service Catalogは、誰に、どのテンプレートを、どの制約で使わせるかを管理します。

マルチアカウントで使う方法

複数のAWSアカウントで使う場合は、管理用のハブアカウントでProductとPortfolioを管理し、開発・検証・本番などのスポークアカウントへPortfolioを共有する構成が分かりやすいです。

共有方法は大きく2つあります。

方式	共有されるもの	更新時の動き	向いている場面
Portfolioを参照共有	元Portfolioへの参照	元Productや制約の変更が共有先へ反映される	同一リージョンで中央管理したい
StackSetsなどでカタログをコピー	各アカウントの独立したPortfolioとProduct	更新時に再デプロイが必要	複数リージョン、共有先ごとに独立管理したい

アカウント単位でPortfolioを共有する

管理アカウントから特定のAWSアカウントへ共有する例です。

ターミナル

# 管理アカウントから利用アカウントへPortfolioを共有する
aws servicecatalog create-portfolio-share \
  --portfolio-id port-xxxxxxxx \
  --account-id 111122223333 \
  --region ap-northeast-1

利用アカウント側では、共有されたPortfolioを受け入れます。

ターミナル

# 利用アカウント側でPortfolio共有を受け入れる
aws servicecatalog accept-portfolio-share \
  --portfolio-id port-xxxxxxxx \
  --portfolio-share-type IMPORTED \
  --region ap-northeast-1

受け入れたPortfolioでは、管理アカウントが定義したProductと制約を利用できます。
利用アカウントの管理者は、自分のアカウントにあるIAMユーザー、グループ、ロールをPortfolioへ関連付けます。

AWS OrganizationsのOUへ共有する

AWS Organizationsを使っている場合は、組織全体、OU、個別アカウントへ共有できます。
次はOUへ共有する概念例です。

ターミナル

# OU配下のアカウントへPortfolioを共有する
aws servicecatalog create-portfolio-share \
  --portfolio-id port-xxxxxxxx \
  --organization-node Type=ORGANIZATIONAL_UNIT,Value=ou-abcd-12345678 \
  --region ap-northeast-1

Organizations共有を使うには、AWS Service CatalogのOrganizationsアクセスを有効にします。
共有を作成できるのは、Organizationsの管理アカウントまたはService Catalogの委任管理者です。

起動ロールは利用アカウント側に置く

マルチアカウントでは、Launch constraintに固定のIAMロールARNを指定するより、各利用アカウントに同じ名前のIAMロールを作り、LocalRoleNameで参照する方法が扱いやすくなります。

ターミナル

# 各利用アカウントに存在する同名ロールを起動時に使う
aws servicecatalog create-constraint \
  --portfolio-id port-xxxxxxxx \
  --product-id prod-yyyyyyyy \
  --type LAUNCH \
  --description "Use a local launch role in each account." \
  --parameters '{"LocalRoleName":"ServiceCatalogLaunchRole"}'

ServiceCatalogLaunchRoleは、制約を作成するアカウントとProductを起動する各アカウントに作成します。
このロールには、CloudFormationとProductが作成するAWSサービスへの必要最小限の権限を付けます。

共有元アカウントの固定RoleArnを指定すると、利用者が別アカウントにいても共有元のロールが使われる設計になり得ます。
どのアカウントへリソースを作るのかを明確にし、マルチアカウントではLocalRoleNameを優先的に検討してください。

Service Catalogはリージョンサービスか

はい。AWS Service Catalogはリージョン単位で扱うサービスです。

Product、Portfolio、制約、Provisioned productは、操作しているAWSリージョンを意識して管理します。
東京リージョンのProductやPortfolioが、大阪リージョンへ自動的に作成されるわけではありません。

特に重要なのは、Portfolioの参照共有をインポートできるのは、管理アカウントと利用アカウントで 同じリージョン にある場合だという点です。

やりたいこと	方法
東京リージョンのPortfolioを別アカウントの東京リージョンで使う	PortfolioをアカウントまたはOrganizationsで共有する
同じProductを別リージョンにも配置する	`copy-product`、CloudFormation、CI/CDなどでリージョンごとに作成する
複数アカウント・複数リージョンへカタログ自体を配る	CloudFormation StackSetsでPortfolioやProductのコピーを配る
1つのProductから複数アカウント・複数リージョンへリソースを展開する	Service CatalogのStack Set constraintを検討する

Git同期Productの対応リージョンにも差があります。
AWS公式ドキュメントの2026年8月22日時点の一覧では、東京リージョンap-northeast-1は対応していますが、大阪リージョンap-northeast-3は非対応です。利用前に最新の対応リージョン一覧を確認してください。

Portfolioを複数アカウントへ共有することと、Productを複数アカウント・複数リージョンへ一括デプロイすることは別です。
前者はカタログの配布、後者はStack Set constraintによるリソース展開です。Launch constraintとStack Set constraintは同じProductとPortfolioの関連に同時設定できません。

よくある失敗

1. Service Catalogを入れれば安全になると思ってしまう

Service Catalogは、標準化と権限制御の仕組みです。
Productの元になるCloudFormationテンプレートが危険なら、危険な構成を標準配布してしまいます。

先にテンプレートレビュー、cfn-lint、Change set確認、削除方針、料金確認を整えます。

2. Launch constraintのIAMロールが強すぎる

利用者に強い権限を渡さないためにLaunch constraintを使っても、起動ロールが強すぎると意味が薄れます。

最初は広めの権限で検証する場合でも、本番運用ではProductが作るリソースに合わせて絞ります。

3. Productのバージョン運用を決めていない

Productは作って終わりではありません。
テンプレートを更新すると、次の判断が必要です。

判断	例
新バージョンを追加するか	`v1` を残し、`v2` を追加する
旧バージョンを使わせ続けるか	既存利用者だけ許可する
既存Provisioned productを更新するか	更新手順と影響を案内する
廃止予定をどう伝えるか	Product説明、運用手順、社内告知に残す

Productを配るということは、テンプレートのライフサイクルも管理するということです。

4. Template constraintとCloudFormation Parametersの役割が混ざる

CloudFormationの AllowedValues や AllowedPattern でも、入力値はある程度制限できます。
それに加えてService CatalogのTemplate constraintを使うと、Portfolioごとに異なる制約をかけやすくなります。

例:

場所	役割
CloudFormation Parameters	Productそのものの基本ルール
Service Catalog Template constraint	Portfolioや利用者グループごとの追加ルール

同じProductでも、開発者向けPortfolioでは dev と stg のみ、運用者向けPortfolioでは prod も許可する、といった分け方ができます。

料金と片付けの注意

CloudFormationやService Catalogの操作そのものだけを見ず、 作成されるAWSリソースの料金 を必ず確認します。

例えば、Productが次を作るなら、それぞれ料金が発生する可能性があります。

EC2
EBS
NAT Gateway
ALB
RDS
S3
CloudWatch Logs

CloudFormationスタックやProvisioned productを削除しても、 DeletionPolicy: Retain などで一部リソースが残る場合があります。
学習用途では、作成したもの、残すもの、削除するものを確認するチェックリストを用意しておくと安全です。

導入前チェックリスト

Service Catalogを導入する前に、次を確認します。

Product化するCloudFormationテンプレートはレビュー済みか
作成されるAWSリソースと料金を説明できるか
Launch constraint用IAMロールの権限は最小化できているか
利用者へ直接渡すIAM権限と、起動ロールの権限を分けているか
Template constraintで制限すべきパラメータが決まっているか
Portfolioを部署別、環境別、用途別のどれで分けるか決めているか
Productのバージョン追加、非推奨、削除ルールがあるか
Provisioned productの更新・終了手順を利用者へ説明できるか
CloudFormation change setで更新影響を確認する運用があるか
Git直接同期、S3＋CLI、手動登録のどれを使うか決めているか
マルチアカウントでは各利用アカウントにローカル起動ロールがあるか
Product、Portfolio、利用アカウントのAWSリージョンが一致しているか
複数リージョンへ展開する場合のコピーまたはStackSets運用があるか
不要リソースの棚卸し方法があるか

AWS資格学習での覚え方

資格学習では、細かいCLIよりも役割の違いを押さえると整理しやすいです。

観点	覚え方
CloudFormation	インフラをコード化し、スタックとして管理する
Service Catalog	承認済みのテンプレートやITサービスをカタログ化して配布する
Portfolio	Productの配布先をまとめる
Product	利用者が選ぶ標準メニュー
Launch constraint	利用者の代わりに使う起動ロールを指定する
Template constraint	起動時の入力値を制限する

試験観点では、 セルフサービス化、 ガバナンス、 標準化、 権限制御 という言葉が出たらService Catalogを思い出すとつながりやすいです。

CloudFormationの基本から確認したい場合は、次の記事が近いです。

参考・確認先

確認日: 2026-08-22

まとめ

CloudFormationは、AWSリソースを作るための設計図です。
Service Catalogは、承認済みのCloudFormationテンプレートをProductとして配布する仕組みです。
コンソールだけでもProductを作成でき、S3は必須ではありません。
Git直接同期では、テンプレートのコミットから新しいProductバージョンを自動作成できます。
Launch constraintを使うと、利用者に強いAWS権限を直接渡さずにProductを起動しやすくなります。
Template constraintを使うと、Product起動時の入力値をPortfolio単位で制御しやすくなります。
マルチアカウントではPortfolio共有とLocalRoleNameを使った起動ロールを検討します。
Service Catalogはリージョン単位で管理し、Portfolioの参照共有は同一リージョンで行います。
導入前に、IAM、料金、削除方針、バージョン運用、更新手順を決めておく必要があります。

おわりに

Service CatalogとCloudFormationは、仕組みだけでなく、誰に何を許可し、どこまでを標準化するかまで決めると使いやすくなります。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。

会社の取り組みは、会社サイトにまとめています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS Service CatalogとCloudFormationで標準テンプレートを配布する考え方

はじめに

この記事でわかること

先に結論

前提

用語の短い説明

全体像

CloudFormationだけでよいケース

Service Catalogを使うとよいケース

まず押さえる設計単位

Git管理したCloudFormationテンプレートをどう取り込むか

マネジメントコンソールだけでも作成できる

CLI中心ならS3経由が分かりやすい

Gitリポジトリと直接同期できる

CloudFormation Git syncとの違い

実務でのおすすめ運用

サンプル: 標準S3バケットをProduct化する

1. Productの元になるCloudFormationテンプレート

2. CLI＋S3方式としてテンプレートをS3へ置く

3. Portfolioを作る

4. Productを作る

5. ProductをPortfolioへ入れる

6. 利用者にPortfolioへのアクセスを付ける

7. Launch constraintを付ける

8. Template constraintで入力値を制限する

利用者側の起動イメージ

Service CatalogとCloudFormationの責任分担

マルチアカウントで使う方法

アカウント単位でPortfolioを共有する

AWS OrganizationsのOUへ共有する

起動ロールは利用アカウント側に置く

Service Catalogはリージョンサービスか

よくある失敗

1. Service Catalogを入れれば安全になると思ってしまう

2. Launch constraintのIAMロールが強すぎる

3. Productのバージョン運用を決めていない

4. Template constraintとCloudFormation Parametersの役割が混ざる

料金と片付けの注意

導入前チェックリスト

AWS資格学習での覚え方

関連記事

参考・確認先

まとめ

おわりに