AWS Service Catalog本番運用Vol2｜制約・Terraform Engine・承認自動化

1. Vol2の全体像とVol1からの差別化

AWS Service Catalogは「製品を作って配布する」基盤を整えた後が本番です。Vol1では、ポートフォリオと製品の設計・Launch Roleによる権限分離・TagOptionsによるタグ強制・Organizations跨ぎ共有・CDKによるIaC統合という土台を築きました。Vol2ではその土台の上に乗り、「運用し続けるための統制設計」という高度運用とガバナンス深化のフェーズに踏み込みます。

なお、Service Catalog（コアサービス）は2026年7月時点でEOLやメンテナンスモードにはなっていません。AWS Proton（2026年10月にend-of-support予定）とは別のサービスですので混同しないようご注意ください。

1-1. Vol2の射程とVol1との境界

Vol1が提供した基礎——ポートフォリオと製品の設計、LaunchRoleConstraintによる最小権限分離、TagOptionsによるタグ付け強制、Organizations組織単位での共有、CDKを用いたIaC統合——は本連載を通じて前提として扱います。これらの詳細はVol1に委ねていますので、必要に応じて本§冒頭のリンクからVol1に戻ってご参照ください。

Service Catalogの本番運用設計は、組織のクラウドガバナンス成熟度によって課題の重心が変わります。立ち上げ直後の組織では制約の設計と権限分離が優先課題となり、成熟した組織では運用自動化・コンプライアンスの継続評価・大規模展開制御という高度な論点が前面に出てきます。Vol2は後者——既にVol1の基礎を実装済みで、さらなる統制強化を検討している組織——を主な対象としています。

Vol2が扱う射程は、「立ち上げた後に何を設計し、どう維持するか」という本番統制の問いです。具体的には次の6つのテーマに絞り込みます。

• 制約の完全設計: Vol1で導入したLaunch制約・Template制約に加え、Tag Update（RESOURCE_UPDATE）制約・Stack Set制約・Notification制約という5種全体の体系と相互排他ルールを明確にします。本番環境で特に見落とされがちな「LaunchとStack Setの相互排他」を設計判断として定着させることが本§の目標です。
• Terraform EXTERNAL Engineの内部: 2023年末に非推奨となったTERRAFORM_OPEN_SOURCEの後継エンジン（EXTERNAL型）の内部アーキテクチャと移行設計を解説します。Reference EngineはCodeBuildではなくEC2 Auto Scaling Group上でSSM Run Commandを用いてterraformを実行する点を正確に押さえます。
• Service Actionsの運用自動化と承認ワークフロー: Day-2 Operationsをセルフサービス化する仕組みと、SSM Automationを通じた承認ゲートの実装パターンを取り上げます。Service ActionはSSM Automation限定であり、Lambdaへの直接呼び出しはできないという前提が設計上の重要な境界線です。
• AppRegistryの現在地: 2026年7月にメンテナンスモードへ移行しているという事実を踏まえ、既存ユーザーの利用価値と新規読者への代替案を整理します。新規採用を煽らず、現実に即した移行判断を提示することが本§の責務です。
• Security Hub集約コンプライアンス: AWS ConfigとSecurity Hubを組み合わせ、Service Catalog経由リソースのコンプライアンス状態を組織横断で評価する設計を示します。Service Catalog自動付与タグをConfigのスコープ条件として活用する具体的な設計が差別化のポイントです。
• StackSets大規模展開制御: マルチアカウント展開における同時実行制御と製品バージョンの強制移行設計を解説します。ProvisioningPreferencesの4パラメータを適切に設定することで、展開リスクをコントロールしながらスケールできます。

これら6つのテーマは互いに独立していますが、設計上の接点があります。Tag Update制約（§2）はAppRegistry（§5）やConfig（§6）と組み合わせることで、タグを起点とした一貫したコンプライアンス評価基盤が完成します。また、Terraform EXTERNAL（§3）で作成したリソースはService Actions（§4）で運用自動化でき、その状態はConfig×Security Hub（§6）で継続評価できます。各セクションを単独で読んでも有益ですが、統制の全体像として連続して読むことでより深い設計判断軸を得られます。

1-2. 想定読者と持ち帰れる設計判断軸

本記事の主な読者は次の3つのロールを想定しています。

プラットフォームチーム（Cloud Platform / Landing Zone担当）

組織全体に製品カタログを展開・維持する立場の方々です。本記事では、制約5種の設計判断・StackSets大規模展開の同時実行制御パラメータ・製品バージョンの強制移行設計という「展開の信頼性設計」に関わる意思決定軸を持ち帰っていただけます。特に、LaunchConstraintとStack Set Constraintの相互排他という本番設計の落とし穴は、Vol2を通じて最も強調したいポイントです。具体的な業務シナリオとして、新しいビジネスユニットへの製品カタログ展開時にStackSets制御パラメータをどう設定するか、あるいはTerraform製品のバージョンアップを数十アカウントへ安全に一括展開するにはどうするか、という判断が典型的な設計課題です。

クラウドガバナンス担当

ポリシー順守と運用自動化を両立させたい方々です。Service ActionsによるDay-2 Operationsの承認ワークフロー設計と、Config×Security Hubを用いた集約コンプライアンス評価アーキテクチャが主な参照先になります。「どのレイヤーで何を制御するか」の設計判断軸を体系的に整理しています。典型的な業務課題として、定期監査レポートのためにSecurity Hub findingsをService Catalogの製品単位で集計する仕組みの設計があります。本記事の§6はその設計の起点になります。

監査・GRC担当

Service Catalog経由で作成されたリソースの継続的なコンプライアンス状態を把握したい方々です。Service Catalogの自動付与タグ（aws:servicecatalog:*）をConfigルールのスコープに活用する設計と、Security Hubでの標準/コントロール管理の全体像が参照点になります。監査証跡の起点としてタグを活用するアーキテクチャを§6で詳解します。例えば、特定のポートフォリオに所属する製品のみを対象にConfigルールを評価し、ポートフォリオ単位でのコンプライアンス証跡を残す設計が典型的な業務要件として想定されます。

3つのロールに共通する設計判断軸として、「何をService Catalogのレイヤーで制御し、何をConfigやSecurity Hubのレイヤーに委ねるか」 というアーキテクチャの切り分けを意識しながら読み進めていただくと、各セクションの位置づけが一層明確になります。

1-2-b. 前提とするAWS環境

本記事の設計例は以下のAWS環境を前提としています。

• AWS Organizationsによるマルチアカウント構成が整備済みである
• Service Catalog管理用のポートフォリオと製品がVol1の手順で作成済みである
• LaunchRoleConstraintによる最小権限分離が導入済みである
• Organizations共有によって本番/開発/サンドボックス等の環境に製品が配布済みである
• 管理アカウントまたは委任管理者アカウントでService Catalogの管理権限を保持している
• AWS CloudTrailがマルチアカウントで有効化され、操作履歴が取得できる環境である
• AWS Configが有効化され、リソース変更履歴の記録が可能な状態になっている
• Security Hubが有効化され、少なくとも1つの標準（AWS基礎セキュリティのベストプラクティス等）が有効になっている
• Service CatalogのIaCテンプレートがGitリポジトリで管理されており、変更履歴が追跡できる状態になっている

これらの前提を満たしていない場合は、まずVol1で基礎を固めてからVol2に進むことをお勧めします。なお、上記はVol2の設計例を最大限に活用するための推奨環境であり、個々のセクションは単独の環境からでも参照いただけます。特に§6（Security Hub集約）はAWS Configの有効化を前提としているため、該当セクションを参照する際はConfigの設定状況を事前にご確認ください。

Vol2が目指す設計哲学は「宣言的ガバナンス」です。Service Catalogの制約・タグ付け・IaCテンプレートはすべてコードとして定義でき、Gitによるバージョン管理・コードレビュー・CI/CDデプロイが実現します。これにより「誰が・いつ・何の権限で・どの製品を変更したか」を追跡できる体制が整います。設計判断に迷ったとき、「この統制はコードで宣言できるか、変更履歴として残せるか」という問いがVol2全体を通じた指針になります。

1-3. Vol2で扱う6つの論点の地図

Vol2は§2から§7まで、それぞれ独立した論点として読めるよう設計しています。各セクションの概要を以下に示します。

§2 制約の完全設計

Service Catalogの制約は全部で5種あります。Vol1で紹介したLaunch・Template・StackSet・Notificationの4種に加え、Vol2ではTag Update（RESOURCE_UPDATE）制約を主役に据え、5種の体系と「LaunchとStackSetは同一製品で併用不可」という相互排他ルールを設計判断まで掘り下げます。本番設計の落とし穴である相互排他ルールは、設計レビューのチェックリストに必ず含めることを推奨します。

§3 Terraform EXTERNAL Engineの深掘り

TERRAFORM_OPEN_SOURCEが2023年12月に非推奨となり、後継のEXTERNAL型が現行の標準です。AWS管理のTerraform Reference Engine（Step Functions/SQS/EC2 Auto Scaling Group/SSM Run Command/S3で構成）の内部アーキテクチャと、OPEN_SOURCEからEXTERNALへの移行設計を正確に解説します。既存のTERRAFORM_OPEN_SOURCE製品をお持ちの方は、本§の移行手順が直接の参照先になります。

§4 Service Actionsの運用自動化と承認ワークフロー

Service ActionはSSM Automationドキュメントのみを実行できます（Lambdaへの直接呼び出しは不可）。この前提を押さえたうえで、パッチ適用・夜間停止・コンプライアンス修復といったDay-2 Operations自動化と、承認ゲートの実装パターンを解説します。エンドユーザーにIAM権限を付与することなくDay-2操作を委任できる点が、Service Actionsの最大の価値です。

§5 AppRegistryの現在地

AppRegistryは2026年7月30日をもって新規顧客の受付を終了し、メンテナンスモードへ移行しています（既存顧客は継続利用可能）。本セクションでは既存ユーザーにとっての価値を整理しつつ、新規採用を検討する読者には代替手段（Resource Groups・Resource Explorer・Application Signals）を案内します。本§では「どう移行するか」の判断軸を提示することを優先し、新規導入の手順詳細は扱いません。

§6 Security Hub集約コンプライアンス

Service CatalogとSecurity Hubの間にネイティブ統合は存在しません。AWS Configが評価エンジン、Security Hubが集約レイヤーという2層構造で、Service Catalog経由リソースのコンプライアンス評価を実現する設計を解説します。Service Catalogが自動付与するタグ（aws:servicecatalog:portfolioId等）をConfigルールのスコープ条件に活用する具体例は、本§の中心となる設計パターンです。

§7 StackSets大規模展開制御

StackSet制約を用いたマルチアカウント展開において、ProvisioningPreferencesの4パラメータ（MaxConcurrencyCount/Percentage・FailureToleranceCount/Percentage）で同時実行ウィンドウを制御する設計と、既存製品バージョンを新バージョンへ一括強制移行する手順を解説します。数十〜数百アカウントへの展開を安全に行う際、これらのパラメータ設計が展開失敗時の影響範囲を決定します。

章間の関係と推奨学習順序

§2から§7は独立して読めますが、初めてVol2を通読する方には§2（制約の体系理解）→§3（IaCエンジン連携）→§4（運用自動化）→§6（コンプライアンス評価）→§7（大規模展開）→§5（AppRegistryの現在地）の順序を推奨します。§5は「現在地の整理」という性質上、他の§を読んだ後に参照しても理解が深まります。一方、IaCを主な関心事とする方は§3から読み始め、その後§2で制約設計を深掘りする読み方も有効です。特定の運用課題（コンプライアンス評価・大規模展開制御）に直面している方は、§6または§7から読み始め、前後のセクションに戻る参照スタイルでご利用いただけます。

Vol2で学ぶ高度運用は、AWS Well-Architected Frameworkの運用上の優秀性（Operational Excellence）ピラーにおける「運用の自動化」「変更の管理」「リスクの特定と軽減」という原則と直接対応しています。制約設計（§2）は「変更の管理」、Service Actions（§4）は「運用の自動化」、Config×Security Hub（§6）は「リスクの特定と軽減」という観点からそれぞれ位置づけられます。各章をWell-Architectedの原則と紐づけて読むことで、個々の設計判断が組織全体のクラウドガバナンス成熟度向上にどう貢献するかが一層明確になります。

Vol2を通じて、Service Catalogを「立てた後に使い続けられるプラットフォーム」として整備するための設計判断軸をご提供します。

2. 制約の完全設計 — 5種の体系と相互排他ルール

AWS Service Catalogの制約（Constraint）は、ポートフォリオと製品の組み合わせに付与するルールセットであり、公式には5種類が提供されます。本セクションでは5種の役割と分類を体系的に整理し、特にVol1で扱わなかったTag Update制約（API識別子：RESOURCE_UPDATE）と、制約同士の相互排他ルールという本番設計の要点を掘り下げます。

2-1. 制約5種の全体マップ

Service Catalogの制約は、エンドユーザーのアクション制御とプロビジョニングの実行方式を定義します。2026年7月時点で提供される5種類を以下の表に示します。

ここで重要な点は、「Resource Update Constraint」と「Tag Update Constraint」は同一の制約だということです。公式ドキュメントではUIラベルとして「Tag Update」、APIおよびCloudFormation識別子としては「RESOURCE_UPDATE」が使われます。ドキュメントのページスラグも constraints-resourceupdate.html となっており、名称の揺れで別制約と誤解されやすいため注意が必要です。「Resource Update Constraint」という6種目は存在しません。

制約はポートフォリオと製品の関連付け（portfolio-product association）ごとに設定します。同種の制約は1つの関連付けにつき1件まで付与できます。またLaunchとStackSetの2種には後述する相互排他の制約があります。

2-2. Tag Update（RESOURCE_UPDATE）制約 — プロビジョニング後のタグ更新統制

Tag Update制約は、プロビジョニング済みの製品（Provisioned Product）が含むリソースのタグをエンドユーザーが変更できるかどうかを制御します。この制約を設定しない状態では、エンドユーザーは製品の更新操作（UpdateProvisionedProduct）を通じてタグを自由に変更できます。

UpdateProvisionedProduct操作とTag Update制約の関係

Tag Update制約は「UpdateProvisionedProduct」APIが呼ばれた際のタグ変更を含む更新操作だけを制御します。制御される操作とそうでない操作を明確に区別することが、設計判断の出発点です。

Tag Update制約はタグ変更に特化した制御であり、パラメータ値の変更はそのまま許可されます。この独立性が重要な点で、「インスタンスサイズは変更できるがタグは変更できない」という業務要件を正確に実装できます。

NOT_ALLOWED による拒否が発生した場合、コンソール上にエラーが表示されます。エンドユーザーにとって理由がわかりにくいケースがあるため、ポートフォリオの説明文やセルフサービスポータルのUI上に「このポートフォリオの製品はプロビジョニング後のタグ変更が禁止されています」という告知を事前に記載することを推奨します。タグを変更するための正規ルート（管理者への申請フロー等）も合わせて案内することで、ガバナンスを損なわずにエンドユーザー体験を保てます。

Tag Update制約とTAINTED状態・インフラ直接変更の限界

プロビジョニング済み製品がTAINTED状態（ドリフト）になった場合、管理者がリソースのタグをAWSコンソールやCLIから直接変更した可能性があります。重要なのは、Tag Update制約はService CatalogのUpdateProvisionedProduct経由の操作のみを制御するという点です。AWSコンソールやCLIからEC2やS3などのリソースタグを直接変更することは、Tag Update制約では防げません。

プロビジョニング済みリソースのタグを包括的にガードするには、Tag Update制約に加えて以下の施策が必要です。

• SCP（Service Control Policy）: Organizations SCPで ec2:CreateTags・ec2:DeleteTags 等を制限し、直接変更をアカウントレベルで禁止する
• AWS Configの required-tags ルール: 必須タグの存在確認と値の検証を継続評価し、違反リソースをコンプライアンスレポートに可視化する
• CloudTrailアラート: タグ変更API呼び出しをCloudWatch Events + SNSでリアルタイム検知し、異常変更を即時察知する

Tag Update制約はService Catalogの操作レイヤーを守る一層目であり、インフラ全体のタグガバナンスにはSCP・Config・CloudTrailの三層防御と組み合わせることが推奨されます。

Tag Update制約が必要な場面

タグを組織のコスト配賦・コンプライアンス・セキュリティポリシーの基盤として活用している環境では、エンドユーザーが任意にタグを変更できると以下のリスクが生じます。

• コスト配賦タグの書き換えによる請求先部門の意図しない変動
• Environment: prod タグの改ざんによるポリシー対象外化
• AWS Configコンプライアンス評価ルールの対象スコープからリソースが外れる

Tag Update制約を有効にすることで、Service Catalog経由のタグ更新操作をロックできます。逆に、タグの変更を認める運用ポリシーであればこの制約は不要です。

CFnによるTag Update制約の設定

CloudFormationでTag Update制約を設定する例を示します。

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  TagUpdateConstraint:
 Type: AWS::ServiceCatalog::ResourceUpdateConstraint
 Properties:
PortfolioId: !Ref PortfolioId
ProductId: !Ref ProductId
TagUpdateOnProvisionedProduct: "NOT_ALLOWED"
Description: "エンドユーザーによるタグ変更を禁止します"

TagUpdateOnProvisionedProduct パラメータには ALLOWED（許可）または NOT_ALLOWED（禁止）を指定します。既存の制約なし環境にこの制約を追加しても、既プロビジョニング済みの製品にさかのぼって即時適用されることはなく、設定後の更新操作から有効になります。

Tag Update制約の運用設計ポイント

• Launch Constraintとの連携: Launch制約のIAMロールは製品のプロビジョニング・更新・終了時に使われます。Tag Update制約は「更新操作のうちタグ変更部分だけ」を制御するため、両方を同時に設定することが可能です。
• TagOptionsとの組み合わせ: TagOptionsはプロビジョニング時に選択肢を提示するタグ定義機能です。Tag Update制約と組み合わせることで「初期タグは限定選択肢から選ばせ、その後の変更もロックする」という強固なタグガバナンスを実現できます。
• CloudTrailによる監査: servicecatalog:UpdateProvisionedProduct のAPI呼び出しログがCloudTrailに記録されるため、制約設定の有無に関わらずタグ変更の履歴を追跡できます。

2-3. Launch と StackSet の相互排他 — 設計判断

Launch Constraint（LAUNCH）と Stack Set Constraint（STACKSET）は、同一のポートフォリオ・製品関連付けに対して共存できません（相互排他）。これはService Catalog APIの仕様による制限であり、両方を付与しようとするとエラーが返されます。

なぜ相互排他なのか

Launch制約は、Service Catalogがエンドユーザーのコンテキストではなく指定のIAMロールを引き受けてプロビジョニングする仕組みです。一方、Stack Set制約はAWS CloudFormation StackSets経由でマルチアカウント/マルチリージョン展開を実現しますが、StackSetsには独自の実行ロール（AWSCloudFormationStackSetExecutionRole）と管理ロール（AWSCloudFormationStackSetAdministrationRole）があります。2つの権限引き受けモデルが競合するため、Service Catalogは両方の制約を同一関連付けに受け付けません。

設計判断：どちらを選ぶか

マルチアカウント展開が要件の場合はStack Set制約を選択し、Launch制約を代わりに設けることはできません。単一アカウント内の権限分離ときめ細かいIAMロール設計が優先ならLaunch制約を選びます。製品単位で使い分ける（ある製品はLaunch、別の製品はStackSet）ことは可能です。

この相互排他の設計制約は §7 のStackSets大規模展開でも重要になりますので、製品設計フェーズで単一アカウントかマルチアカウントかを先に確定させることが重要です。

相互排他を回避する設計パターン：製品分割

「単一アカウント向けにはLaunchを使いたい、かつマルチアカウント向けにも同じテンプレートを使いたい」という要件がある場合、同一の製品に対して両方の制約を付与することはできません。この場合の対応策は製品を用途別に分割することです。

たとえば、「VPC製品（単一アカウント用）」と「VPC製品（ランディングゾーン用）」を別々の製品として登録し、それぞれのポートフォリオにLaunch制約とStackSet制約を個別に設定します。製品テンプレート自体は同一のS3パスを参照する形で実質的に共有しつつ、Service Catalogの製品定義レイヤーで用途を分けることが実用的な解決策です。

また、マルチアカウント展開のうち一部アカウントのみで使うケースでは、StackSet制約の AccountList（対象アカウントID列挙）および RegionList（対象リージョン列挙）パラメータで展開範囲を明示的に限定できます。さらに StackInstanceControl パラメータでスタックインスタンスの更新権限を制御することで、制約の適用スコープを細かく設計できます。

2-4. Template制約の高度活用とNotification制約の運用連携

Template制約：CloudFormation Rulesによるパラメータガード

Template制約は、CloudFormation Rulesブロックを使って入力検証ロジックを定義する仕組みです。エンドユーザーがプロビジョニング時に指定するパラメータの許容値を事前に絞り込めます。

Rules:
  AllowedInstanceTypes:
 Assertions:
- Assert:
 Fn::Contains:
- - "t3.micro"
  - "t3.small"
  - "m5.large"
 - !Ref InstanceType
  AssertDescription: >-
 選択できるインスタンスタイプは t3.micro / t3.small / m5.large のみです。
 他のタイプが必要な場合はプラットフォームチームへ申請してください。

上記の例では、エンドユーザーが InstanceType パラメータに許可リスト外の値を入力するとプロビジョニングが拒否されます。Template制約の設定は、CloudFormation RulesブロックをJSON文字列として AWS::ServiceCatalog::LaunchTemplateConstraint リソースに渡します。

Template制約はパラメータの数値範囲、CIDR形式チェック、条件付きルール（AZとインスタンスタイプの組み合わせ制限など）にも対応しており、ガードレール実装の主力手段です。AWS Control TowerのSCP（Service Control Policy）でアカウントレベルを守り、Template制約で製品レベルのパラメータを守るという二段構えが推奨されます。

AssertDescription には日本語の修正手順を記載することで、エラー時のユーザーの問い合わせコストを削減できます。

Notification制約：プロビジョニングイベントのSNS連携

Notification制約は、製品のプロビジョニング・更新・終了といったライフサイクルイベントを指定のSNSトピックへ通知します。Service Catalog側でのイベント通知は、CloudFormationスタックイベントを拡張した形で送信されます。

主な活用パターンは以下のとおりです。

• ITSM連携: ServiceNow等のチケットシステムへのLambdaブリッジ（SNS → Lambda → ServiceNow）
• コスト超過の早期検知: プロビジョニング完了タイミングでコスト試算を行うLambdaをSNSにサブスクライブ
• Slack/Teamsアラート: プロビジョニング失敗時の即時チャット通知

1つの製品・ポートフォリオ関連付けに付与できるNotification制約は1件ですが、SNSトピック側でファンアウト（複数LambdaやSQSをサブスクライブ）することで複数の通知先へ配信できます。

CloudFormationでNotification制約を設定する場合は AWS::ServiceCatalog::LaunchNotificationConstraint リソースを使用します。

NotificationConstraint:
  Type: AWS::ServiceCatalog::LaunchNotificationConstraint
  Properties:
 PortfolioId: !Ref PortfolioId
 ProductId: !Ref ProductId
 NotificationArns:
- !Sub "arn:aws:sns:${AWS::Region}:${AWS::AccountId}:sc-provisioning-events"
 Description: "プロビジョニングイベントをSNSへ通知します"

SNSトピックのアクセスポリシーにはService CatalogのPrincipal（servicecatalog.amazonaws.com）を必ず許可してください。ポリシーが未設定の場合、通知はサイレントに失敗します（エラーはService Catalogコンソールに表示されません）。

2-5. 制約設計のアンチパターンとチェックリスト

よくあるアンチパターン

AP-1: EXTERNAL/StackSet製品にLaunch制約を付与していない

Terraform EXTERNAL型製品およびStack Set制約を使う製品では、Launch Constraintの設定が必須です（EXTERNAL製品はlaunch roleがなければプロビジョニング不可）。Launch制約なしのまま製品を公開するとプロビジョニングが失敗するため、製品RegistrationフェーズでのCI/CD検証項目に組み込んでおくことを推奨します。

AP-2: Tag Update制約を後から有効化する際に既存リソースの棚卸しを省く

Tag Update制約を追加しても既存プロビジョニング済みリソースへの即時遡及適用はありません。ガバナンス強化のタイミングで既存リソースのタグ棚卸しが必要になります。新規製品はデフォルトで NOT_ALLOWED にして始め、タグ変更が業務上必要なユースケースのみ ALLOWED に例外設定するのが推奨です。

AP-3: Template制約のAssertDescriptionを空にする

エラーメッセージが空や英語のデフォルトになると、エンドユーザーが何を修正すればよいかわからず問い合わせが増えます。AssertDescription には日本語で「何を・どう直すか」を記載してください。

AP-4: Launch制約とStackSet制約を同一関連付けに付与しようとする

APIがエラーを返すため実際には設定できませんが、「両方設定すれば両立できる」という誤解が現場でよく見られます。製品設計フェーズでのアーキテクチャ決定（単一アカウント vs マルチアカウント）を明確にし、制約選択の判断を先行させてください。

3. Terraform 連携の深掘り — Reference Engine内部とEXTERNALへの移行

Service CatalogはCloudFormation以外のIaCも製品として扱えますが、Terraform連携は2023年末に大きな転換を迎えています。本セクションでは、現行のEXTERNAL製品タイプとAWS管理のTerraform Reference Engineの内部構成を正確に押さえ、非推奨となったTERRAFORM_OPEN_SOURCEからの移行設計までを解説します。

3-1. 製品タイプの現在地 — 3タイプの整理

AWS Service CatalogのTerraform製品タイプには現在3種類ありますが、2023年末の仕様変更によってその位置づけが大きく変わっています。混乱を避けるため、まず現時点での正確な3者関係を整理します。

TERRAFORM_OPEN_SOURCEが非推奨になった背景には、HashiCorpが2023年8月にTerraformのライセンスをMPL 2.0からBusiness Source License（BSL）1.1へ変更したことがあります。AWSはこれを受けて製品タイプをEXTERNALとして再設計し、2023年12月14日にTERRAFORM_OPEN_SOURCEを正式に非推奨化しました。EXTERNALは名称からも分かるとおり特定のIaCツールに依存しない汎用的な設計になっており、Terraform Community Edition（OpenTofuを含む）に加え、Pulumi・Ansible・Chefなども扱えます。

既存のTERRAFORM_OPEN_SOURCE製品を利用している場合、新規プロビジョニングはすでにブロックされています。Service Catalogの管理コンソールから対象製品を確認し、EXTERNALへの移行計画を立てることが急務です。

3-2. Terraform Reference Engineの内部アーキテクチャ

EXTERNAL製品タイプが利用するAWS管理のTerraform Reference Engineは、GitHubでオープンソース公開されているCloudFormation/SAMテンプレートを使い、管理（hub）アカウントへデプロイします。その内部アーキテクチャは次の6つの構成要素で成り立っています。

コア構成要素（hubアカウント内）:

Service Catalog → Lambda（リクエスト受付） → Amazon SQS（キュー）
  → AWS Step Functions（ワークフロー制御）
→ EC2 Auto Scaling Group（terraform実行ノード）
 + AWS Systems Manager Run Command（コマンド制御）
→ Amazon S3（tfstate・実行ログ保管）

各構成要素の役割を詳しく説明します。

1. Lambda（リクエスト受付・ディスパッチ）

Service Catalogからのプロビジョニング/更新/削除リクエストを受信し、SQSキューへメッセージを投入します。リクエストのバリデーションと初期処理を担い、後続のStep Functionsワークフローへ橋渡しをします。

2. Amazon SQS（キュー）

Lambdaからのメッセージを保持し、Step Functionsのワークフローが拾い上げる非同期バッファとして機能します。これにより、長時間かかるTerraform実行をService Catalog本体の処理から切り離して非同期で処理できるようになっています。

3. AWS Step Functions（ワークフロー制御）

Terraformのapply/plan/destroyの各フェーズを管理するステートマシンです。EC2インスタンスの起動・ジョブ割り当て・完了確認・エラーハンドリングというライフサイクル全体をStep Functionsが制御します。べき等性を保ちながら複雑な非同期フローを管理できるのが、Step Functionsを採用する利点です。

4. EC2 Auto Scaling Group（terraform実行ノード）

実際にTerraformコマンドを実行する環境です。オンデマンドで起動するASGとして構成されており、必要なときだけEC2インスタンスが立ち上がり、実行後にスケールインします。なお、CodeBuildは使用しません。EC2上でterraformを直接実行する構成である点を押さえておくことが重要です。従来のCI/CDパイプライン（CodePipeline/CodeBuild）とは独立した専用の実行基盤です。

5. AWS Systems Manager Run Command（コマンド制御）

Step FunctionsからEC2インスタンスに対してterraformコマンドを送信・制御する仕組みです。SSMエージェント経由で実行されるため、SSH接続不要でセキュアなコマンド実行が実現できます。実行ログはSSMのコマンド履歴にも記録されるため、監査証跡としても活用できます。

6. Amazon S3（tfstate・ログ保管）

Terraformのステートファイル（.tfstate）と実行ログを保管します。ステートはS3に集中管理されるため、複数のプロビジョニングリクエストが並走しても一貫したステート管理が維持されます。

このReference Engineは管理（hub）アカウントに1セットデプロイします。エンドユーザーの各アカウント（スポーク）とは、IAMロール（launch role）のクロスアカウントAssumeRoleで権限を委譲する形をとります。Reference Engineそのものはオープンソース（GitHubで公開）ですが、AWSが運用・更新を担うため、エンジン自体のメンテナンスをユーザーが行う必要はありません。

3-3. EXTERNAL型でのProduct登録とlaunch role設計

EXTERNAL製品タイプでService Catalog製品を登録するには、CloudFormation製品タイプとは異なるいくつかの追加要件があります。

Product登録の基本形（AWS CLI）:

aws servicecatalog create-product \
  --name "MyTerraformProduct" \
  --owner "PlatformTeam" \
  --product-type EXTERNAL \
  --provisioning-artifact-parameters '{
 "Name": "v1.0",
 "Type": "EXTERNAL",
 "Info": {"SourceArtifactUrl": "s3://my-bucket/terraform-package.tar.gz"}
  }'

Terraformの設定ファイルは、S3バケットにtar.gz形式でパッケージングして配置します。パッケージ内にmain.tf・variables.tf・outputs.tfなどのファイルを含めるだけで、Service CatalogがTerraformテンプレートとして認識します。

launch constraintとlaunch roleの設計:

EXTERNAL型製品は、必ずlaunch constraint（launch role）が必要です。launch roleはReference Engineがプロビジョニング時に引き受けるIAMロールであり、エンドユーザー自身が対象リソースへの直接権限を持つ必要がなくなります。これが最小権限原則の実現において重要なポイントです。

launch roleに付与すべき権限は大きく2種類に分かれます。

まず、Reference Engine連携のための権限です。S3へのtfstateアクセス、SSM Run Command実行権限、Step FunctionsとSQSへの適切なアクセス権が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "s3:GetObject",
  "s3:PutObject",
  "s3:ListBucket",
  "s3:DeleteObject"
],
"Resource": [
  "arn:aws:s3:::sc-terraform-engine-state-ACCOUNTID",
  "arn:aws:s3:::sc-terraform-engine-state-ACCOUNTID/*"
]
 },
 {
"Effect": "Allow",
"Action": [
  "ssm:SendCommand",
  "ssm:GetCommandInvocation",
  "ssm:ListCommandInvocations"
],
"Resource": "*"
 }
  ]
}

次に、Terraformが実際に作成/更新/削除するリソースに応じた権限です。EC2・VPC・IAMなど対象リソースに合わせて追加します。launch roleに必要な権限の洗い出しは、まずterraform planの出力を参照して特定するのが確実です。権限不足はterraform applyの実行フェーズで発覚することが多いため、テスト環境での事前検証が重要です。

3-4. OPEN_SOURCE→EXTERNAL 移行手順と移行判断

既存のTERRAFORM_OPEN_SOURCE製品をEXTERNALへ移行する場合、製品とプロビジョニング済み製品の両方を対応する必要があります。以下の手順で順序立てて進めます。

Step 1: 現状棚卸し

対象ポートフォリオとTERRAFORM_OPEN_SOURCE製品の一覧を確認します。

aws servicecatalog search-products-as-admin \
  --filters '{"FullTextSearch": [""]}' \
  --query 'ProductViewDetails[?ProductViewSummary.Type==<code>TERRAFORM_OPEN_SOURCE</code>].{Name:ProductViewSummary.Name,Id:ProductViewSummary.ProductId}'

Step 2: Reference Engineのデプロイ（hubアカウント）

まだEXTERNAL向けReference Engineをデプロイしていない場合は、AWSのGitHubリポジトリ（aws-samples/service-catalog-engine-for-terraform-os）から最新のCloudFormation/SAMテンプレートを取得し、管理アカウントへデプロイします。TERRAFORM_OPEN_SOURCEで使っていたエンジンとは別のスタックになります。

Step 3: 新規EXTERNAL製品の作成

既存のTERRAFORM_OPEN_SOURCE製品のTerraformコードを流用し、ProductTypeをEXTERNALとして新しい製品を作成します。ポートフォリオへの関連付けとlaunch constraintも設定します。

Step 4: テスト環境での動作検証

テスト環境でEXTERNAL製品をプロビジョニングし、リソース作成・更新・削除が正常に動作することを確認します。この段階でlaunch roleの権限不足が見つかることが多いため、入念に検証します。

Step 5: ProvisionedProduct側の移行

既存のTERRAFORM_OPEN_SOURCE ProvisionedProductは、新しいEXTERNAL製品への移行にあたってin-placeでの製品タイプ変更ができません。terminate後に新EXTERNAL製品でprovisionし直す形が基本になります。リソースの一時的な再作成が発生するため、メンテナンスウィンドウの設定が必要です。tfstateの引き継ぎが必要な場合は、移行前にstateファイルをバックアップし、新しいS3パスへの移動を事前に計画します。

Step 6: 旧製品のDEPRECATED化

新EXTERNAL製品への移行が完了したら、旧TERRAFORM_OPEN_SOURCE製品のプロビジョニングアーティファクトをDEPRECATEDに設定し、新規プロビジョニングをブロックします。

aws servicecatalog update-provisioning-artifact \
  --product-id prod-xxxxxxxxxxxx \
  --provisioning-artifact-id pa-xxxxxxxxxxxx \
  --guidance DEPRECATED

移行判断の指針:

移行の優先度は「新規プロビジョニングの必要性」「既存ProvisionedProductの稼働重要度」「移行テスト工数」の3軸で判断します。新規追加製品は即EXTERNAL対応が必須です。既存ProvisionedProductは、次回の計画的なメンテナンスウィンドウに合わせてリソース再作成の作業を組み込むことを推奨します。重要度の高い本番環境では、並行稼働期間（新EXTERNAL製品でのshadow run）を設けてリスクを低減してください。

3-5. Terraform Cloud型との使い分け指針

TERRAFORM_CLOUDはHashiCorp（現IBM傘下）のTerraform Cloudをエンジンとして利用するタイプで、EXTERNALとは根本的に異なる動作をします。以下の観点で使い分けを判断します。

既存のTerraform Cloud環境を組織的に利用しており、Service Catalogの製品もその上で一元管理したい場合はTERRAFORM_CLOUDが適しています。一方、新規にService CatalogのTerraform連携を構築する場合、またはTerraform Cloud以外のIaCツールも視野に入れる場合は、EXTERNALが現行の標準的な選択肢です。ネットワーク的にすべての処理をAWS VPC内に閉じたい要件（クローズド環境・金融・政府系）では、EXTERNALのReference EngineがVPC内で動作するため適しています。

4. Service Actions による運用自動化と承認ワークフロー

Service Actionsは、プロビジョニング済み製品に対するDay-2 Operations（パッチ適用・再起動・コスト最適化・コンプライアンス修復など）をセルフサービス化する仕組みです。エンドユーザーはプロビジョニング済み製品のコンソールから「操作メニュー」としてアクションを呼び出すだけで、プラットフォームチームが事前に定義した運用ドキュメントが実行されます。本セクションでは、DefinitionTypeがSSM_AUTOMATIONのみという正確な前提を押さえたうえで、Day-2運用自動化の設計パターンと承認ワークフローの実装手順を掘り下げます。Vol1 §7-2で触れたService Actionsの導入基礎はそちらを参照ください。

4-1. Service Actionsの正確な前提 — SSM_AUTOMATION限定とLambda間接呼出

Service Actionsで定義できる操作の種別（DefinitionType）は、SSM_AUTOMATION の1種類のみです。CloudFormationリソース AWS::ServiceCatalog::ServiceAction の DefinitionType 属性はこの単一の値しか受け付けません。Step Functions、EventBridge、SQSなどを直接起動するアクション型は現時点のAPI仕様には存在せず、全てSSM Automationドキュメントを経由する設計になります。

Service Actionの定義は次の3要素で構成されます。

• DefinitionType：SSM_AUTOMATION（固定値・必須）
• Name（Definition.Key）：実行するSSM Automationドキュメント名
• AssumeRole（Definition.Key）：SSM Automationが引き受ける実行IAMロールのARN

以下はCloudFormationでService Actionを定義し、製品に関連付ける最小構成例です。

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  PatchAction:
 Type: AWS::ServiceCatalog::ServiceAction
 Properties:
Name: Apply-Patch-Baseline
DefinitionType: SSM_AUTOMATION
Definition:
  - Key: Name
 Value: AWS-RunPatchBaseline
  - Key: Version
 Value: "$DEFAULT"
  - Key: AssumeRole
 Value: !GetAtt ServiceActionRole.Arn
  - Key: Parameters
 Value: '{"Operation":["Install"]}'
  PatchActionAssociation:
 Type: AWS::ServiceCatalog::ServiceActionAssociation
 Properties:
ProductId: !Ref MyProduct
ProvisioningArtifactId: !Ref MyArtifact
ServiceActionId: !Ref PatchAction

DefinitionType: SSM_AUTOMATION を省略するか異なる値を指定するとCloudFormationバリデーションエラーになります。定義したService Actionは ServiceActionAssociation リソースで製品の特定バージョンに関連付けることで、エンドユーザーのプロビジョニング済み製品画面の操作メニューに表示されます。複数の製品バージョンに同じService Actionを関連付ける場合は、ServiceActionAssociation リソースをバージョン数分作成します。

4-2. Day-2運用の自動化設計

Service Actionsが最も価値を発揮するのは、プロビジョニング済み製品への「定型運用操作」を安全に委任したい場面です。代表的なユースケースを3つ取り上げます。

① パッチベースライン適用

AWSマネージドドキュメント AWS-RunPatchBaseline を利用します。エンドユーザーは製品コンソールからアクションを起動するだけで、SSM AutomationがEC2インスタンスに対してパッチスキャンとインストールを実行します。パッチグループ（Patch Groupタグ）の設定はプラットフォームチームが事前に用意しておけば、エンドユーザーがOSレベルの詳細を知る必要はありません。パラメータとして Operation: Scan と Operation: Install の2つのService Actionを用意しておくと、まず影響範囲を確認してから適用するという2ステップ運用がコンソール操作だけで完結します。

② 夜間停止・朝の再起動

AWS-StopEC2Instance と AWS-StartEC2Instance を2つの独立したService Actionとして登録します。エンドユーザーは開発環境の製品ページから「Stop」「Start」を随時呼び出せるようになります。スケジュール実行が目的なら EventBridge + SSM Automationの組み合わせが別途有力ですが、Service Actionとして公開することで「誰がいつ停止/起動したか」がCloudTrailに記録され、操作証跡が保たれます。コスト削減施策の効果測定にも役立ちます。

③ コンプライアンス修復ドキュメント

AWS Configのコンプライアンス修復と連携したカスタムSSM Automationドキュメントを使うパターンです。例えば「S3バケットのパブリックアクセスブロックが無効になっている場合に有効化する」ドキュメントを作成し、Service Actionとして製品に関連付けます。Configが違反を検出した際、エンドユーザーはService Catalogコンソールのアクション起動で即座に修復を開始でき、コンプライアンス担当者への問い合わせを省けます。

修復ロジックにLambdaを組み込む場合は、SSM Automationドキュメント内に aws:invokeLambdaFunction ステップを追加します。

schemaVersion: "0.3"
description: "S3バケットのパブリックアクセスブロックを有効化します"
parameters:
  BucketName:
 type: String
 description: "対象S3バケット名"
mainSteps:
  - name: InvokeRemediationLambda
 action: aws:invokeLambdaFunction
 inputs:
FunctionName: "arn:aws:lambda:ap-northeast-1:123456789012:function:remediate-s3-public-access"
Payload: '{"bucketName": "{{BucketName}}"}'

SSM AutomationがLambdaを間接的に呼び出すこのパターンが、Service Actionsにおける「Lambda活用の正規ルート」です。Service ActionのトリガーはService Catalogサービスプリンシパルであり、実際のLambda実行権限は後述する実行ロールが保持します。

よく利用されるAWSマネージドSSM Automationドキュメントを以下に整理します。

カスタムドキュメントを作成する場合は schemaVersion: "0.3" を使い、mainSteps に操作ステップを記述します。

Service Actionはエンドユーザーがプロビジョニング済み製品の詳細ページを開き、「Actions」タブから起動します。起動後の実行ステータスは同ページの「Events」タブでリアルタイムに確認でき、ステップごとの成功・失敗もここに表示されます。エンドユーザーがSSM Automationコンソールを直接操作する必要はなく、Service Catalogの画面内で完結する運用体験がセルフサービス化の利点です。

4-3. 実行ロール（AssumeRole）の最小権限設計

Service Actionが実行されるとき、Service CatalogはDefinitionの AssumeRole に指定されたIAMロールをSSMサービスプリンシパル経由で引き受けてSSM Automationを開始します。エンドユーザー自身がSSM実行権限やEC2操作権限を直接持つ必要はありません。これがService Actionsにおける「エンドユーザーIAM不要原則」の核心です。

「エンドユーザーが実行ロールを直接AssumeRoleできない」設計が前提です。信頼ポリシーにConditionを追加して発信元アカウントを制限することで、Service Actionの経路以外からのロール利用を防止できます。

{
  "Effect": "Allow",
  "Principal": {
 "Service": "ssm.amazonaws.com"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
 "StringEquals": {
"aws:SourceAccount": "123456789012"
 }
  }
}

エンドユーザーに付与するIAMポリシーは以下の最小限に留めます。EC2やSSMへの直接操作権限はエンドユーザーに渡しません。

{
  "Effect": "Allow",
  "Action": "servicecatalog:ExecuteProvisionedProductServiceAction",
  "Resource": "*",
  "Condition": {
 "StringEquals": {
"servicecatalog:productId": "prod-xxxxxxxxxx"
 }
  }
}

servicecatalog:productId 条件キーを使うことで、エンドユーザーが自分の担当製品以外のService Actionを誤って起動するリスクを排除できます。実行ログはSSM Automation実行履歴とCloudTrailの両方に記録されるため、「誰が何の製品に対してどのアクションを実行したか」という監査証跡が自動で保たれます。

実行ロールはアクション単位に分離することが推奨です。例えばパッチ適用ロール・停止/起動ロール・修復ロールをそれぞれ独立して作成することで、万一一つのロールが過広な権限を持っていた場合でも影響範囲を限定できます。権限境界（Permission Boundary）をロールに付与することで、付与できる権限の上限を組織ポリシーで管理する方法も有効です。

4-4. 承認ワークフロー — SSM Automationのaws:approveアクションによるゲート実装

本番DBのフェイルオーバー、セキュリティグループの変更、スケールアップ操作など、エンドユーザーが自由に起動できると困る操作には承認ゲートが必要です。Service Catalog自体には承認制約APIは存在しません。Service ActionのDefinitionTypeはSSM_AUTOMATIONに限定されているため、承認ゲートもSSM Automationドキュメント内のaws:approveアクションで実装します。

aws:approveを使った承認ワークフローの実行フロー

1. エンドユーザーがプロビジョニング済み製品のコンソールから対象のService Actionを選択し、起動リクエストを送信します。
2. SSM Automationが起動し、ドキュメント内のaws:approveステップに到達すると実行が一時停止（Waiting状態）します。
3. aws:approveの設定に従い、SNSトピックへ承認要求が発行されます。承認者はメール等で通知を受け取ります。
4. 承認者がAWS CLIで応答します。承認する場合は aws ssm send-automation-signal --automation-execution-id --signal-type Approve、却下する場合は --signal-type Reject を実行します。
5. Approve応答を受け取るとSSM Automationが再開し、後続ステップ（パッチ適用・フェイルオーバーなど）が実行されます。Reject応答の場合はAutomation全体がキャンセルされます。

SSM Automationドキュメント内でのaws:approveステップの定義例は次のとおりです。

mainSteps:
  - name: ApproveOperation
 action: aws:approve
 timeoutSeconds: 3600
 inputs:
NotificationArn: arn:aws:sns:ap-northeast-1:123456789012:ops-approval
Message: "Service Action: 本番DBフェイルオーバーの承認リクエストです。実行者: {{RequesterArn}}"
MinRequiredApprovals: 1
Approvers:
  - arn:aws:iam::123456789012:role/PlatformOpsRole
  - name: ExecuteFailover
 action: aws:executeAwsApi
 inputs:
Service: rds
Api: RebootDBInstance
DBInstanceIdentifier: "{{DBInstanceId}}"
ForceFailover: true

NotificationArnにSNSトピックを指定するとメール通知が届き、ApproversにIAMロールまたはユーザーのARNを列挙します。承認者は複数名指定でき、MinRequiredApprovalsで必要承認数を設定できます。timeoutSecondsを超えると自動的にキャンセルされるため、ハング防止になります。

なお、Service Actionの起動前ゲートとして「起動そのものをブロックしたい」場合は、Lambda関数と CloudFormation WaitConditionを組み合わせる方式も選択肢です。また、ServiceNow等のITSMツールと統合する場合はAWS Service Management Connector（ServiceNow版）を利用すると、Service CatalogのリクエストをITSMのチケットワークフローに乗せられます。

aws:approveステップの承認・却下操作はCloudTrailにssm:SendAutomationSignalとして記録されます。誰がいつ承認・却下したかの証跡がAPI呼び出し単位で自動保存されるため、規制対応（SOC 2・PCI-DSS）の監査要件を満たす形で承認履歴を残せます。

4-5. 運用自動化のアンチパターン

Service Actionsの設計でよく見られる誤りを整理します。

① Lambda直接呼び出しを試みる

DefinitionType にLambdaを指定しようとするケースです。現行API仕様では SSM_AUTOMATION のみが許容値であり、異なる値を指定するとCloudFormationバリデーションエラーになります。Lambdaロジックが必要な場合はSSM Automationドキュメントの aws:invokeLambdaFunction ステップを経由します。この間接呼び出しの仕組みを前提に設計することが重要です。

② 実行ロールへの過広な権限付与

「とりあえず AdministratorAccess」にした実行ロールは、アクションが誤動作した際に本来の範囲を超えた変更を引き起こすリスクを高めます。アクション単位で専用ロールを作成し、そのアクションに必要なAPI呼び出しのみを許可する最小権限設計が原則です。権限の棚卸しはIAM Access Analyzerで定期実施することを推奨します。

③ 危険な操作を承認なしで公開する

データ削除、ネットワーク変更、IAMポリシーの書き換えを承認なしでエンドユーザーに公開すると、セルフサービスの利便性がリスクに転化します。「元に戻すのが困難な操作」には必ず承認ゲート（SSM Automationのaws:approve）を設けるポリシーを組織として確立し、Service Actionの登録申請フローの中でレビューするガバナンスプロセスを設けることが重要です。

④ 実行ログの収集設計を後回しにする

Service Action経由の操作はCloudTrailにAPI呼び出しとして記録されますが、SSM Automation実行の詳細（各ステップの入出力・タイムスタンプ）はSSM Automation実行履歴（aws ssm describe-automation-executions）で別途確認が必要です。CloudWatch Logsへの転送設定とログ保持期間を設計段階で決めておかないと、インシデント発生時に調査ログが存在しない状況に陥ります。Service Actionを本番運用に導入する前に、ログ収集パイプラインの検証まで完了させることを強く推奨します。

⑤ パラメータ入力値を無検証で受け渡す

Service ActionのDefinitionでSSM Automationドキュメントにパラメータを渡す際、入力値の検証ロジックを省くと意図しないリソースへの操作が発生する可能性があります。例えばインスタンスIDをエンドユーザーが入力できる形式にしている場合、自分のプロビジョニング済み製品以外のインスタンスIDを入力されると、そのインスタンスに対してアクションが実行されてしまいます。SSM Automationドキュメント内のassertステップでパラメータ値を検証するか、Lambdaブリッジ（aws:invokeLambdaFunction ステップ）で入力値を正規化・確認したうえで操作対象のリソースを絞り込む実装を取り入れることで、誤操作や意図しない横断操作を防止できます。Service Actionの登録申請フローでパラメータ設計のレビューを必須化することも有効な対策です。

5. AppRegistry の現在地 — アプリ可視化とメンテナンスモードへの対応

AppRegistryは、複数のAWSリソースを「アプリケーション」という論理単位でグルーピングし、可視化・コスト配賦・コンプライアンス評価のスコープを統一するための機能です。2026年7月現在、AppRegistryはメンテナンスモードへの移行が発表されており、新規採用には後述の代替手段の検討が必要です。本セクションでは、AppRegistryの構成と既存ユーザーへの価値を整理したうえで、現在地と移行判断の指針を示します。

5-1. AppRegistryの構成 — Application・attribute groups・awsApplicationタグ

AppRegistryは次の3つのコア構成要素で成り立っています。

Application（アプリケーション定義）

AppRegistryにおける最上位の論理エンティティです。CloudFormationスタックまたはService CatalogのProvisioned Productを関連付けることで、複数のAWSリソースを「1つのアプリケーション」として扱う範囲を定義します。同一アカウント内の複数リージョン、あるいは複数アカウントをまたいだリソースを1つのApplicationに関連付けることも可能です。Applicationはリソースの実体ではなく、あくまでグルーピングの論理単位であり、関連付けの追加・削除はいつでも行えます。

attribute groups（属性グループ）

Applicationに任意のメタデータ（JSON形式）を付与するためのコア構成要素です。チーム名・コストセンター・コンプライアンス分類・環境（本番/ステージング）といったビジネスコンテキストをApplicationに紐付け、ツール横断での一貫した参照を実現します。attribute groupsはAppRegistry独自のメタデータ管理メカニズムであり、AWSタグとは独立して機能します。同一のattribute groupを複数のApplicationに関連付けることも可能で、組織横断のメタデータ標準を共有する用途に活用できます。

awsApplicationタグ

AppRegistryがApplicationを作成・更新すると、関連付けられたリソースに対して awsApplication タグが自動付与されます。このタグはAWS Billing・AWS Config・AWS Security Hubなど各サービスにおけるスコープ指定のための共通キーとして機能します。awsApplication タグを起点に、コスト分析やコンプライアンス評価の粒度をApplicationと揃えられる点が、AppRegistryの主な技術的価値です。

なお、AppRegistryとAWS Systems Manager Application Managerは「連携（integrate）」の関係にあるスタンドアロンサービスです。両者は統合されておらず、AppRegistryで定義したApplicationをApplication Manager上から参照・運用する形で組み合わせます。

AppRegistryはAWS内の複数サービスと公式に連携しています。

• AWS Billing: awsApplication タグ経由でアプリ単位のコスト配賦・Cost Explorer/Budgets分析に利用
• CloudWatch Application Insights: アプリケーション単位の異常検知・ログパターン分析
• AWS Resource Groups: タグベースのリソースグルーピングと管理コンソール上の一覧表示
• AWS Resilience Hub: Applicationを単位とした耐障害性評価・RTO/RPO測定
• AWS Systems Manager Application Manager: Application定義を参照したオペレーションビュー
• AWS Well-Architected Tool: アプリケーション単位のWell-Architected レビュー
• AWS RAM（Resource Access Manager）: Application関連リソースのクロスアカウント共有

5-2. 既存ユーザーにとっての価値 — 可視化・コスト配賦・スコープ共通化

Service Catalogをすでに本番環境で運用している組織にとって、AppRegistryは以下の3点で価値を発揮します。なお、AppRegistry自体の利用料金は無料です。プロビジョニングされたリソースとその実行コストのみが課金対象となるため、既存のService Catalog環境にAppRegistryを後付けで導入するコスト障壁はほぼありません。

アプリ単位のリソース可視化

ポートフォリオ横断でプロビジョニングされた製品（CloudFormationスタック）を、「受注管理システム」「データ分析基盤」といったアプリケーション単位でグルーピングして俯瞰できます。製品数・リソース数が増加しても、Applicationという論理単位で一元的に把握できるため、運用・監査担当者がリソースの帰属を確認するコストを削減できます。

例えば「注文処理システム」というApplicationに、API GatewayスタックとLambdaスタック、RDSスタックをそれぞれ関連付けると、AppRegistryコンソールの単一画面で全リソースを確認できます。各スタックが異なるリージョンやアカウントに分散していても、Application単位で集約できる点が、複数チームが並行して製品を提供するプラットフォーム組織で特に有効です。CloudWatch Application Insightsと連携してアプリケーション単位の異常検知・ログ集約を行う構成も可能です。

コスト配賦タグによる費用分析

自動付与される awsApplication タグはAWS Billingのコスト配賦タグとして機能します。Cost ExplorerやAWS Budgetsでこのタグをフィルタ・グルーピング条件として使うことで、アプリケーション単位のコスト分析と予算管理が可能になります。タグベースのコスト配賦自体はAppRegistryを使わずとも実現できますが、AppRegistryを導入することでApplication定義と配賦タグの管理を一元化し、手動のタグ付け漏れリスクを低減できます。なお、コスト分析の起点はあくまで awsApplication タグ経由であり、AppRegistryがCost Explorerと直接統合しているわけではありません。

ConfigとSecurity Hubのスコープ共通化

awsApplication タグをAWS Configのルールスコープ設定やSecurity Hub上のフィルタ条件と紐付けることで、コンプライアンス評価の対象範囲をApplicationと一致させられます。§6で詳述するConfig→Security Hub集約アーキでも、このタグが評価スコープの共通項として機能します。これにより、制度上の「アプリ」と技術上の「コンプライアンス評価単位」を揃えた統制設計が実現します。

具体的には、AWS Configのカスタムルールまたはマネージドルールのスコープに awsApplication タグをリソースフィルタとして指定することで、特定のApplicationに属するリソースのみを継続評価の対象にできます。Service Catalogが自動付与する aws:servicecatalog:portfolioId タグと組み合わせると、ポートフォリオ単位でコンプライアンス評価スコープを制御する二段構えの設計も可能です。AWS Resilience HubやWell-Architected Tool、AWS RAMとの連携にも awsApplication タグが橋渡しとして機能します。

5-3. 現在地：メンテナンスモード移行と2026-07-30新規受付終了

この変更はService Catalog本体（ポートフォリオ/製品/プロビジョニング機能）のメンテナンスモード化ではありません。Service Catalog本体は現役のサービスとして機能追加が継続しています。AppRegistryはService Catalogのオプション機能の一つであり、今回のメンテナンスモード移行はAppRegistryコンポーネントのみに適用されます。

整理すると、メンテナンスモードに入るのはAppRegistry（アプリケーション定義・attribute groups・awsApplicationタグの管理機能）のみです。ポートフォリオ管理・製品カタログ・プロビジョニング・各種制約・Service Actions・StackSet連携といったService Catalogのコア機能は影響を受けません。また、同時期に発表されたAWS Protonの2026-10-07 end-of-supportとは別の動きであり、両者を混同しないよう注意が必要です。

既存のAppRegistryユーザーが考慮すべき点を以下に整理します。

• 機能追加・バグフィックス: 新機能の追加は予定されていません。クリティカルなセキュリティ修正を除き、機能変更も行われません。
• 既存環境の継続性: 現時点では既存のApplicationや attribute groups、awsApplicationタグの動作に変更はありません。設定済みのコスト配賦や評価スコープはそのまま機能し続けます。
• 移行タイミングの判断: 代替サービスへの移行には既存のタグ戦略や連携設定の見直しが必要です。次のインフラ刷新タイミングでの計画的移行か、短期継続のうえで状況を見るかを、切り替えコストとリスクに応じて判断します。
• 新規リージョン・機能の期待をしないこと: 今後、東京リージョン以外へのAppRegistryの拡張や新しいAPIの追加は行われません。長期依存を深める設計変更は避けることを推奨します。

「メンテナンスモード」はサービスの即時終了ではなく、AWSがそのサービスへの投資を縮小する一方で既存機能の維持のみを約束する状態です。日常的な運用には引き続き使えますが、新しい統合要件を満たすためにAppRegistryを選定することは避けるべきです。中長期的には代替サービスへの移行計画を持つことが合理的な判断です。

Service Catalog機能全体のうち、どの機能がメンテナンスモードに入り、どの機能が継続提供されるかを以下に整理します。

5-4. 新規採用の移行判断と代替手段

2026年7月30日以降、AppRegistryへの新規顧客登録は受け付けられません。新たにアプリケーション単位のリソース管理・可視化を実現したい場合は、以下の代替手段を検討してください。

AWS Resource Groups

タグベースでAWSリソースをグルーピングする基本機能です。awsApplication タグを含む任意のタグ条件でリソースをグループ化し、マネジメントコンソール上での一覧表示やAWS Systems Managerとの連携に利用できます。AppRegistryのApplication管理に最も直接的に代替できるサービスであり、追加費用なく利用できます。既存のタグ付け戦略があればそのまま移行しやすく、移行コストが最小です。

Resource Groupsは「クエリベース」と「スタックベース」の2種類のグループタイプを持ちます。タグ条件でリソースを動的にグルーピングするクエリベース型が、AppRegistryのApplicationに最も近い動作をします。AppRegistryのattribute groups（メタデータ管理）相当の機能はResource Groupsには存在しないため、ビジネスコンテキストの管理にはタグの体系化で補完する設計が必要です。

AWS Resource Explorer

複数リージョン・複数アカウントにわたるAWSリソースを横断検索するサービスです。タグや属性でフィルタリングし、組織全体のリソースを一元的に可視化できます。AppRegistryの「アプリ単位のリソース俯瞰」ユースケースに対応しつつ、AWS Organizations全体へのスコープ拡張が容易です。集約リージョンで検索インデックスを管理するため、組織全体のリソースを単一ビューで検索できる点が強みです。マルチアカウント・マルチリージョン環境での横断的な可視化を重視する場合に適しています。

Resource Explorerの利用には、集約リージョンとメンバーリージョンへのインデックス作成が必要です。インデックスが揃うと、awsApplication タグでフィルタした検索ビューを保存し、アプリ単位のリソース一覧を即座に呼び出せます。

Amazon CloudWatch Application Signals

アプリケーションのパフォーマンスとヘルスをサービスレベル目標（SLO）ベースで監視するサービスです。アプリケーション単位のオブザーバビリティという観点では、AppRegistryよりも機能的に成熟した代替です。サービス間依存関係のトポロジー可視化、トレース・メトリクスを統合したヘルス把握、SLO違反アラートなど、運用視点での高度な機能を提供します。単なるリソース管理を超えて、アプリケーションの稼働品質管理まで担いたい場合に適しています。CloudWatch Application Insightsと組み合わせることで、アプリケーション異常の自動検知もカバーできます。

既存のAppRegistryユーザーが移行を計画する際は、まずResource Groupsへのタグ管理の移行から着手し、横断検索の要件に応じてResource Explorer、オブザーバビリティの要件に応じてApplication Signalsを段階的に組み合わせるアプローチを基本方針とします。AppRegistryが提供していた価値（グルーピング・コスト配賦タグ・連携サービスへのスコープ提供）は、これら3サービスを組み合わせることで機能的に置き換えられます。attribute groupsのようなアプリケーションへのメタデータ付与機能は代替サービスには存在しないため、その役割はタグの追加・命名規則の整備で補完する設計変更が必要です。移行を急ぐ必要はありませんが、2026年7月30日以降に新規アカウントを追加する場合はAppRegistryへの登録ができなくなることを念頭に置いておく必要があります。

移行時の確認チェックリスト（既存AppRegistryユーザー向け）

• 現在のApplicationと attribute groupsの一覧を書き出し、移行対象スコープを把握する
• awsApplication タグの付与対象リソースを棚卸しし、タグ付け方針を標準化する
• Cost ExplorerやBudgetsで awsApplication タグをフィルタとして使用している箇所を特定する
• AWS Configのルールスコープ・Security Hubのフィルタで awsApplication を参照している箇所を確認する
• 代替サービス（Resource Groups・Resource Explorer等）で同等のグルーピング・可視化が再現できるか検証する
• AppRegistryへの依存が残る連携（Resilience Hub・WAFレビュー等）を個別に評価し、移行優先度を決定する
• attribute groupsで管理していたビジネスメタデータをタグ体系に落とし込む方針を確定する
• 移行完了後も awsApplication タグが既存リソースに残存していないか定期的に確認する
• 2026-07-30以降に追加する新規AWSアカウントはAppRegistryに登録できないため、代替での管理体制を事前に整備する

6. Security Hub と Config による集約コンプライアンス評価

Service Catalog経由で作成したリソースも、通常のAWSリソースと同様にコンプライアンス評価の対象になります。本セクションでは、Service CatalogとSecurity Hubの間にネイティブ統合がないという正確な前提を押さえ、AWS Configを評価エンジン、Security Hubを集約レイヤーとする集約コンプライアンスガバナンスの設計を解説します。

6-1. 集約コンプライアンスの正確なアーキ

最初に押さえるべき重要な前提があります。AWS Service CatalogとAWS Security Hubの間には、ネイティブ統合は存在しません。 Service Catalogが「コンプライアンス評価の結果をSecurity Hubへ直接送信する」という機能は提供されておらず、両者を接続するにはAWS Configを中継レイヤーとして挟む必要があります。

集約コンプライアンスのアーキテクチャは、次の3ステップで構成されます。

ステップ1: リソースのプロビジョニングとタグ付与

Service Catalogが製品をプロビジョニングすると、作成されたAWSリソース（EC2インスタンス、S3バケット、RDSインスタンスなど）に対して、Service Catalogが自動的にメタデータタグを付与します。aws:servicecatalog:portfolioIdやaws:servicecatalog:productIdといったタグがここで付与され、後続のコンプライアンス評価スコープのフィルタリングに使えます。

ステップ2: AWS Configによる継続評価

AWS Configは、アカウント内のAWSリソースを継続的に記録・評価します。ConfigマネージドルールやカスタムルールあるいはConformance Packを通じて、各リソースが設定ポリシーに準拠しているかどうかをCOMPLIANTまたはNON_COMPLIANTとして判定します。ConfigはService Catalog固有の機能ではなく、すべてのAWSリソースを対象とした汎用サービスです。Service Catalogが作成したリソースも、その評価対象に含まれます。

ステップ3: Security Hubによるfindings集約

AWS Security HubはConfigと連携しており、Configが提供するセキュリティ標準（AWS基本セキュリティベストプラクティス、CIS AWS Foundations Benchmark、PCI DSS、NIST SP 800-53など）のコントロールを評価した結果をSecurity Findingsとして集約します。Security HubがConfigを「データソース」として取り込む構造であり、Service CatalogがSecurity Hubへ直接findingsを送信するわけではありません。

このアーキテクチャの核心は、Service Catalogで管理するリソースも、手動で作成したリソースも、Config→Security Hubの評価フローにおいては区別されないという点にあります。Service Catalog管理リソースをコンプライアンス評価のスコープに絞り込むためには、タグによるフィルタリングが実質的な手段になります。

なお、マルチアカウント環境では、Config委任管理者アカウントをOrganizationsの管理アカウントから指定し、Security Hubの集約リージョンで全アカウントのfindingsを一元管理するという構成を取ります。この場合でも、Service CatalogとSecurity Hubの直接統合ではなく、Config→Security Hubというデータフローは変わりません。

6-2. Service Catalog自動付与タグをConfigルールのスコープに使う設計

Service Catalogがプロビジョニング時にリソースへ自動付与するタグは、コンプライアンス評価スコープの共通項として機能します。主要なタグを以下に整理します。

これらはAWSが管理するシステムタグであり、ユーザーが削除・変更することは推奨されません。また、Service CatalogのTagOptionsを使って追加した業務タグ（Environment: production、CostCenter: 12345など）も同様にリソースへ伝播するため、これらも組み合わせてスコープ設計に活用できます。

Configルールへのスコープ適用例

たとえば「ポートフォリオID port-abc123 に属するEC2インスタンスのみを対象に、EBS暗号化必須ルールを適用する」という設計を考えます。Configマネージドルール ec2-ebs-encryption-by-default 自体はタグフィルタを直接持ちませんが、Configのスコープ設定でタグキー/値を指定することで、対象リソースを絞り込めます。

{
  "Scope": {
 "TagKey": "aws:servicecatalog:portfolioId",
 "TagValue": "port-abc123"
  }
}

このスコープ設定により、Configルールの評価対象を「特定ポートフォリオ経由でプロビジョニングされたリソース」に限定できます。環境タグ（Environment: production）と組み合わせて「本番ポートフォリオのリソースだけを厳格なルールセットで評価する」という多段スコーピングも可能です。

AppRegistryのawsApplicationタグを利用している場合は、アプリケーション単位でのスコープ絞り込みも選択肢になります。ただし、§5で述べたAppRegistryのメンテナンスモード移行（2026-07-30以降新規受付終了）を考慮すると、新規設計においてはaws:servicecatalog:*タグを主軸に置くことを推奨します。

Conformance Packでのタグスコープ活用

Config Conformance PackのYAMLテンプレートでも、各ルールにScopeパラメータを指定することでタグフィルタを組み込めます。以下は、ポートフォリオIDをパラメータとして受け取り、対象ポートフォリオ管理のEC2インスタンスにのみEBS暗号化ルールを適用するConformance Packの設定例です。

Parameters:
  PortfolioId:
 Default: "port-abc123"
Resources:
  EbsEncryptionRule:
 Type: AWS::Config::ConfigRule
 Properties:
ConfigRuleName: sc-ebs-encryption-check
Source:
  Owner: AWS
  SourceIdentifier: EC2_EBS_ENCRYPTION_BY_DEFAULT
Scope:
  TagKey: aws:servicecatalog:portfolioId
  TagValue: !Ref PortfolioId

このようにConformance PackをポートフォリオID単位でパラメータ化しておくと、複数ポートフォリオのコンプライアンス基準を独立して管理できます。Organizations Conformance Packとして展開する場合も、パラメータをアカウント/OU単位で上書きする設計が可能です。

6-3. Conformance Pack と Security Hub標準の使い分け

コンプライアンス評価を実装する際、Config Conformance PackとSecurity Hub標準のどちらを選択するかは重要な設計判断です。両者は役割が異なり、多くの場合は組み合わせて使います。

Security Hub標準を優先すべきケース

既製の業界標準（PCI DSS、NIST SP 800-53、CIS AWS Foundations Benchmark v1.4）への準拠が要件の場合は、Security Hub標準を主軸に置くことを推奨します。Security Hub標準は、対応するConfigルールを自動的に有効化し、findingsをSecurity Hub側で一元管理できます。監査レポートの生成、findingsの重大度付け（CRITICAL/HIGH/MEDIUM/LOW）、自動修復のトリガー（EventBridge連携）といった運用機能がSecurity Hub側に集約されるため、セキュリティ運用チームが一元的に対応できます。

Security Hubが提供する主要な標準フレームワーク:

• AWS基本セキュリティベストプラクティス（FSBP）: AWS推奨のセキュリティ設定を網羅した汎用標準です。新規採用時の出発点として最適です。
• CIS AWS Foundations Benchmark: Center for Internet Securityによるベストプラクティスです。アカウント設定・IAM・モニタリング等を体系化します。
• PCI DSS v3.2.1: クレジットカード業界の準拠要件です。決済フローを扱うワークロードに適用します。
• NIST SP 800-53 Rev.5: 米国政府機関および高セキュリティ要件向けです。金融・医療・公共機関での採用が多いです。

不要なコントロールがある場合は、Security Hubコンソールで個別に無効化できます。標準全体を一括で有効化しつつ、環境に合わないコントロールを除外するのが実務上の一般的な運用です。

Config Conformance Packを選ぶケース

以下のケースでは、Config Conformance Packを主に活用します。

1. カスタムルールとマネージドルールの組み合わせ: 組織固有のポリシー（命名規則チェック、特定タグの必須化など）をカスタムルールで定義し、AWSマネージドルールと1つのパックにまとめたい場合です。
2. Service Catalogポートフォリオ単位の分離: 特定のaws:servicecatalog:portfolioIdに限定したスコープを持つConformance Packを作成し、ポートフォリオ別のコンプライアンス基準を分離管理する場合です。
3. Organizations全体への一括展開: AWS OrganizationsでOrganizations Conformance Packを展開することで、委任管理者アカウントから全メンバーアカウントへ統一基準を適用できます。
4. Security Hub標準に含まれないコントロールの補完: FSBPやCISで評価されないリソース設定（特定のService Catalog製品固有のタグ要件など）を追加でチェックしたい場合です。

組み合わせ設計の推奨パターン

実際の本番環境では、Security Hub標準（業界標準への準拠）とConfig Conformance Pack（組織固有ルール・SC管理スコープ分離）を並行稼働させるのが一般的です。Security HubはConfigをデータソースとして取り込むため、Conformance Packのルール評価結果も間接的にSecurity Hubのfindingsに反映されます（Security Hub標準コントロールに対応するConfigルールが有効である場合）。

6-4. TAINTEDドリフトとNON_COMPLIANTの突合による逸脱原因特定

Service Catalog管理リソースのコンプライアンス逸脱を分析する際、TAINTEDステータス（Service Catalogのプロビジョニング済み製品状態）とNON_COMPLIANT（Config評価結果）の突合が、根本原因の特定に効果的です。

TAINTEDの意味

Service CatalogのプロビジョニングされたProductがTAINTED状態になるのは、CloudFormationスタックで管理されているリソースが、Service Catalog（および対応するCloudFormation）を経由せずに変更された場合（アウト・オブ・バンド変更、いわゆるドリフト）です。具体的には次のような操作がTAINTEDを引き起こします。

• EC2コンソールからインスタンスの設定を直接変更した
• AWS CLIを使ってS3バケットポリシーを直接更新した
• 別のCloudFormationスタックや手動操作でセキュリティグループルールを変更した

TAINTEDは「Service Catalogによる管理状態からの逸脱」を示すものであり、必ずしもコンプライアンス違反を意味するわけではありません。しかし、TAINTEDとNON_COMPLIANTが同時に発生している場合は、アウト・オブ・バンド変更が違反の引き金になっている可能性が高まります。

突合ロジックと逸脱原因の分類

TAINTEDとNON_COMPLIANTの状態を組み合わせると、逸脱原因の仮説が絞り込めます。

TAINTED × NON_COMPLIANTのリソースは、Service Catalog管理外の変更によってコンプライアンスが悪化した可能性が高く、優先的に調査すべき対象です。

調査フロー

1. AWS Config タイムラインの確認: 対象リソースのConfig履歴（Configuration History）を参照し、設定変更のタイムスタンプを確認します。
2. CloudTrailとの突合: Configが記録した設定変更タイムスタンプを基点に、CloudTrailのAPI呼び出し履歴を参照し、誰がいつどのAPIで変更したかを特定します。
3. Security Hub findingsの確認: 該当リソースに関連するfindingsをSecurity Hubで確認し、違反コントロールと重大度を把握します。
4. 修復判断: テンプレートを修正してService Catalog経由で再プロビジョニングするか、対象リソースをService Catalog外で直接修復するかを判断します。いずれにせよ、TAINTEDを解消してService Catalogによる管理状態に戻すことが長期的な統制の観点から推奨されます。

EventBridgeによる自動検知パターン

TAINTEDとNON_COMPLIANTの突合を手動で行うのは運用コストが高いため、EventBridgeを活用した自動検知が有効です。aws.configイベントソースのConfig Rules Compliance ChangeイベントをEventBridgeで受信し、LambdaでService Catalog APIを呼び出してプロビジョニング済み製品のステータスを照合するというパターンが実装できます。

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
 "newEvaluationResult": {
"complianceType": ["NON_COMPLIANT"]
 }
  }
}

このEventBridgeルールをトリガーに、LambdaがService Catalog DescribeProvisionedProduct APIを呼び出し、ステータスがTAINTEDであれば優先アラートをAmazon SNSまたはSlackへ送信するという自動化ループを組めます。これにより、手動の定期チェックに頼らず、逸脱発生から検知までのタイムラグを最小化できます。

Config Auto Remediationと組み合わせる場合は、SSM Automationドキュメントを指定してNON_COMPLIANTを自動修復する設定も可能です。ただし、Service Catalog管理リソースへの自動修復はCloudFormationスタックとの整合性を壊すリスクがあるため、修復内容はテンプレート変更＋再プロビジョニングのフローへ誘導するか、Service Actionsを経由したDay-2 Operations（§4参照）として設計することを推奨します。

同一のaws:servicecatalog:portfolioIdタグを持つリソースで複数のNON_COMPLIANT findingsが同時に検出された場合は、製品テンプレート自体の設計上の問題である可能性が高まります。この場合は個別リソースの修復より、テンプレートを修正したうえで新バージョンとして再プロビジョニングする根本解決を選択することを推奨します。TAINTEDドリフトが原因であれば、アウト・オブ・バンド変更の実施者と変更理由をCloudTrailで確認し、正規の変更フローをService Actionsに移行するための設計見直しの機会として活用してください。

自動通知ループを運用する際は、誤検知（false positive）への対策も設計に含めておくことが重要です。Configルールの評価頻度（定期評価・変更トリガー）やスコープ設定の誤りにより、本来COMPLIANTなリソースがNON_COMPLIANTと判定されるケースがあります。誤検知が多発する場合は、Configルールのパラメータ調整を行うか、EventBridgeルールにSuppression条件（例: 特定のリソースタイプや特定タグを持つリソースを除外）を追加して通知を絞り込むことで、運用負荷を適切にコントロールできます。また、Security HubではSuppressor機能を使い、既知の例外事項をfindingsレベルで除外することも可能です。

Vol1 §7-2ではConfig Conformance Packの基礎まで解説しました。Vol2では、Security Hub集約レイヤーを加えることで、ポートフォリオ単位のコンプライアンス可視化から業界標準への準拠管理、ドリフト起因の逸脱特定まで、一気通貫のガバナンスループを形成できます。Service CatalogとSecurity Hubの間にネイティブ統合がないという制約は、AWS Configとタグ設計によって克服できます。

7. StackSets 大規模展開制御と製品バージョンの強制移行

大規模なマルチアカウント環境では、製品の展開速度と失敗時の影響範囲を制御することが運用上の要点になります。本セクションでは、StackSetベース展開の同時実行制御パラメータと、既存のプロビジョニング済み製品を新しい製品バージョンへ強制移行・一括更新する設計を解説します。

7-1. StackSet Constraint による大規模展開の前提

StackSet Constraint は、Service Catalog の製品を AWS CloudFormation StackSets 経由でマルチアカウント・マルチリージョンへ一括展開するための制約です。エンドユーザーがカタログから製品を起動すると、管理アカウント（または委任管理アカウント）から StackSets のスタックインスタンスが指定のアカウント・リージョンに自動的に作成されます。

Launch Constraint と StackSet Constraint の相互排他

§2 でも整理したとおり、Launch Constraint と StackSet Constraint は同一の product/portfolio の関連付けに対して共存できません。「単一アカウントへのデプロイには Launch Constraint（launch role）を使い、マルチアカウント展開には StackSet Constraint を使う」という二択になります。両方を同じ product/portfolio 関連付けに設定しようとすると API がエラーを返します。この制約の選択は製品設計の初期段階で明確に決定しておかないと、大規模展開の途中でアーキテクチャを見直す必要が生じます。

StackSet Constraint が適している主なシナリオを示します。

• 全社の AWS Organizations Landing Zone 配下の全アカウントへ、共通セキュリティベースライン（VPC Flow Logs 有効化・CloudTrail 設定・Config ルール）を一括展開する
• 新規アカウントが OU に追加されたタイミングで、Service Catalog 製品のプロビジョニングをトリガーし、標準的なリソース構成を自動適用する
• 特定の OU 配下の全アカウントに、定期改版される統一タグ付けポリシーや IAM 権限境界を一括展開・更新する

service-managed / self-managed StackSets の基礎については Vol1 §6-2 にて解説済みのため、本セクションではその上に乗る同時実行制御パラメータと、製品バージョンの大規模移行設計に集中します。

7-2. 同時実行制御と失敗許容 — ProvisioningPreferences の設計

StackSet Constraint 付きの製品を起動・更新する際、StackSets のロールアウト速度と失敗時の影響範囲は ProvisioningPreferences で制御します。provision-product および update-provisioned-product の両コマンドに JSON 形式で指定するこのパラメータには、同時実行と失敗許容に関する 4 つのフィールドがあります。

StackSetMaxConcurrencyCount

同時に展開（または更新）を進めるスタックインスタンスの上限件数を指定します。たとえば 10 を指定すると、最大 10 インスタンスが並行して処理されます。いずれかのインスタンスが完了したタイミングで次のインスタンスがキューから取り出されます。全体のインスタンス数に関係なく絶対件数で制御したい場合に用います。

StackSetMaxConcurrencyPercentage

同時展開インスタンス数の上限を「全インスタンス数に対する割合（1〜100）」で指定します。インスタンス数が増減しても比率で制御でき、OU のアカウント数が変動する組織では Count よりも安定した制御が得られることがあります。StackSetMaxConcurrencyCount と StackSetMaxConcurrencyPercentage はどちらか一方のみ指定します。

StackSetFailureToleranceCount

ロールアウトを継続するために許容する失敗インスタンス数を指定します。この値を超えた失敗が発生した時点でロールアウトが停止し、残りのインスタンスへの展開が中止されます。0 に設定すると 1 件でも失敗した時点で即停止する最も保守的な設定です。

StackSetFailureTolerancePercentage

許容する失敗インスタンス数を「全インスタンス数に対する割合」で指定します。StackSetFailureToleranceCount と StackSetFailureTolerancePercentage はどちらか一方のみ指定します。

以下に AWS CLI での具体的な指定例を示します。100 インスタンス（50 アカウント × 2 リージョン）を最大 10 並行・2 件失敗許容でロールアウトする場合です。

aws servicecatalog provision-product \
  --product-id prod-xxxxxxxxxx \
  --provisioning-artifact-id pa-xxxxxxxxxx \
  --provisioned-product-name "security-baseline-v2" \
  --provisioning-preferences '{
 "StackSetAccounts": ["111111111111", "222222222222"],
 "StackSetRegions": ["ap-northeast-1", "us-east-1"],
 "StackSetMaxConcurrencyCount": 10,
 "StackSetFailureToleranceCount": 2
  }'

Terraform の aws_servicecatalog_provisioned_product リソースでは、provisioning_preferences ブロックとして記述できます。

resource "aws_servicecatalog_provisioned_product" "baseline" {
  name= "security-baseline"
  product_id= var.product_id
  provisioning_artifact_id = var.artifact_id

  provisioning_preferences {
 accounts  = var.target_accounts
 regions= var.target_regions
 stack_set_max_concurrency_count= 10
 stack_set_failure_tolerance_count = 2
  }
}

パイロット展開と本番ロールアウトの 2 段階戦略

大規模環境での安全なロールアウトには、2 段階のアプローチが有効です。

まずパイロットフェーズでは、代表的な 5〜10 アカウントに限定し、StackSetMaxConcurrencyCount: 5・StackSetFailureToleranceCount: 0 という厳しい設定で展開します。失敗が 1 件でも発生した時点でロールアウトが停止するため、テンプレートの差分や IAM 権限の不備を早期に発見できます。

パイロットが成功したら、本番ロールアウトフェーズとして残りの全アカウントへ展開します。このタイミングで同時実行数を増やし（例: StackSetMaxConcurrencyCount: 30）、失敗許容数も適切に緩和（例: StackSetFailureToleranceCount: 5）することでスループットを高めながら、許容範囲外の障害が発生した際には自動停止させるバランスを確保します。

Count と Percentage の使い分け指針

Count か Percentage かの選択は、組織規模と将来のアカウント増減を見越して判断します。

• Count を選ぶ場合: 対象アカウント数が固定されており（例: 50 アカウント固定）、同時実行の上限を明確な件数で管理したいとき。インフラの観点から「同時に N 本のスタック更新まで」という絶対的な上限がある場合にも適します。
• Percentage を選ぶ場合: Organizations のアカウント数が増減する組織や、OU 単位でロールアウトする場合。新規アカウントが OU に参加するたびに全体数が変わるため、割合で制御するほうがパラメータの手動更新が不要になります。

失敗許容についても同様で、「絶対に 3 件以上は失敗させない」なら Count: 3、「全体の 5% 以内に収める」なら Percentage: 5 を選びます。展開規模が小さいうちは Count が直感的で扱いやすく、スケールアウト後は Percentage のほうが運用しやすくなる傾向があります。

7-3. 製品バージョンの強制移行 — UpdateProvisionedProduct による一括更新

Service Catalog の製品にはバージョン管理（Provisioning Artifact）の仕組みがあり、CloudFormation テンプレートや Terraform コードを改版するたびに新しいバージョンが作成されます。マルチアカウント環境に展開されたプロビジョニング済み製品が旧バージョンを使い続けている場合、セキュリティパッチや設計変更を全アカウントへ確実に行き渡らせるために「バージョンの強制移行」が必要です。

強制移行のコアは update-provisioned-product コマンドです。既存の ProvisionedProduct に対して新しい provisioning-artifact-id を指定することにより、テンプレートの差分を StackSets 経由で適用した更新展開が実行されます。

aws servicecatalog update-provisioned-product \
  --provisioned-product-id pp-xxxxxxxxxxxxxxxxx \
  --product-id prod-xxxxxxxxxx \
  --provisioning-artifact-id pa-newversion \
  --update-token "$(uuidgen)" \
  --provisioning-preferences '{
 "StackSetMaxConcurrencyCount": 10,
 "StackSetFailureToleranceCount": 2
  }'

大規模環境では、プロビジョニング済み製品が数十〜数百存在することがあります。一括更新の実装パターンとして、list-provisioned-products で全 ProvisionedProduct を取得し、旧バージョン（ProvisioningArtifactId が古いもの）を絞り込んでループ処理する方法が一般的です。

OLD_ARTIFACT_ID="pa-oldversion"
NEW_ARTIFACT_ID="pa-newversion"
PRODUCT_ID="prod-xxxxxxxxxx"

aws servicecatalog list-provisioned-products \
  --access-level-filter Key=Account,Value=self \
  --query "ProvisionedProductDetails[?ProvisioningArtifactId=='${OLD_ARTIFACT_ID}'].Id" \
  --output text | tr '\t' '\n' | while read -r pp_id; do
 echo "Updating ${pp_id} ..."
 aws servicecatalog update-provisioned-product \
--provisioned-product-id "${pp_id}" \
--product-id "${PRODUCT_ID}" \
--provisioning-artifact-id "${NEW_ARTIFACT_ID}" \
--update-token "$(uuidgen)" \
--provisioning-preferences '{
  "StackSetMaxConcurrencyCount": 10,
  "StackSetFailureToleranceCount": 2
}'
 sleep 2
done

StackSet Constraint 付きの製品では、update-provisioned-product が裏側で StackSets の UpdateStackSet / UpdateStackInstances を実行します。このとき StackSetMaxConcurrencyCount / StackSetFailureToleranceCount がロールアウト速度を制御するため、前節の 2 段階戦略を踏まえたパラメータを設定したうえで一括更新を実行することが重要です。

更新の進捗と結果は describe-record コマンドで確認できます。Status が SUCCEEDED になれば移行完了、FAILED の場合は RecordErrors でエラー詳細を確認して対処します。

aws servicecatalog describe-record \
  --id rec-xxxxxxxxxxxxxxxxx \
  --query 'RecordDetail.[Status,RecordErrors]'

7-4. 旧バージョンの DEPRECATED 化と移行ロールアウト計画

新バージョンへの移行を確実に進めるには、旧バージョンを DEPRECATED 状態にして、エンドユーザーが新規プロビジョニング時に旧バージョンを選択できないようにすることが有効です。

aws servicecatalog update-provisioning-artifact \
  --product-id prod-xxxxxxxxxx \
  --provisioning-artifact-id pa-oldversion \
  --guidance DEPRECATED

--guidance DEPRECATED を指定すると、そのバージョンはカタログの製品一覧に表示されなくなり、新規起動・更新時の選択肢から外れます。ただし、すでに旧バージョンを使用中の ProvisionedProduct は影響を受けず、引き続き稼働します（自動シャットダウンはされません）。旧バージョンを完全に削除するには delete-provisioning-artifact を使いますが、使用中の ProvisionedProduct が存在する場合は削除できません。全 ProvisionedProduct の移行が完了してから削除を実施してください。

DEPRECATED 化と一括更新を組み合わせた段階的な移行ロールアウト計画の例を示します。

ロールアウト監視

list-provisioned-products を定期実行して旧バージョンの残存数を確認し、移行完了率を可視化します。Amazon EventBridge で AWS Service Catalog の UPDATE_SUCCEEDED / UPDATE_FAILED イベントを検知して SNS 通知するとリアルタイムの失敗検知に役立ちます。

aws servicecatalog list-provisioned-products \
  --access-level-filter Key=Account,Value=self \
  --query "length(ProvisionedProductDetails[?ProvisioningArtifactId=='pa-oldversion'])"

EventBridge ルールの例を示します。UPDATE_FAILED を検知した際に SNS トピックへ通知する設定です。

{
  "source": ["aws.servicecatalog"],
  "detail-type": ["AWS Service Catalog Provisioned Product Event"],
  "detail": {
 "status": ["FAILED"],
 "statusMessage": [{ "prefix": "" }]
  }
}

このルールをデプロイしておくことで、大規模ロールアウト中に失敗が発生した際に運用チームへの通知を自動化できます。SNS トピックを Slack や PagerDuty と連携させれば、夜間バッチ実行中の障害も即座に検知できます。

失敗時の対応

StackSetFailureToleranceCount を超えた失敗が発生するとロールアウトが自動停止します。describe-record でエラー詳細（スタックエラーメッセージ・IAM 権限不足など）を確認し、テンプレートや IAM ポリシーを修正してから update-provisioned-product を再実行します。手動ロールバックが必要な場合は、旧バージョンの --guidance を一時的に DEFAULT に戻したうえで旧バージョンへ再プロビジョニングする手順を採ります。

8. まとめ — Vol2の運用ベストプラクティス

Vol2では、Service Catalogを本番で統制し続けるための高度運用とガバナンスを整理しました。Vol1で築いた基礎（ポートフォリオ/製品設計・権限分離・Organizations共有）の上に、6つの高度な運用設計論点を積み上げてきました。本§では各論点のベストプラクティスを要約し、本番環境で即座に活用できるチェックリストをお届けします。

8-1. Vol2の要点サマリ（6論点）

制約の完全設計（§2）

制約は全5種（Launch・Notification・Template・Stack Set・Tag Update）であり、Launch制約とStack Set制約は同一製品に併用できません（相互排他）。Tag Update（RESOURCE_UPDATE）制約はプロビジョニング済み製品リソースのタグ変更可否を統制するガバナンス上の要点であり、本番環境ではデフォルトで「更新不可」として設計し、必要な製品にのみ明示的に許可することを推奨します。

Terraform EXTERNAL Engine（§3）

TERRAFORM_OPEN_SOURCEは2023年12月に非推奨となり、現行の標準はEXTERNAL型です。AWS管理のTerraform Reference Engine（Step Functions/SQS/EC2 Auto Scaling Group/SSM Run Command/S3で構成）を用い、terraform apply処理はEC2インスタンス上でSSM Run Command経由で実行されます。CodeBuildは使用しません。EXTERNAL型の製品にはlaunch constraintが必須であり、launch roleにはS3・SSM・対象リソース操作の3カテゴリの権限が必要です。

Service Actionsの運用自動化と承認ワークフロー（§4）

Service ActionはSSM Automationドキュメントのみを実行できます。LambdaはSSM Automationのステップ（aws:invokeLambdaFunction）経由で間接的に呼び出せますが、Service ActionからLambdaに直接アクセスすることはできません。Day-2 Operations（パッチ適用・夜間停止・コンプライアンス修復）を承認ワークフローと組み合わせることで、エンドユーザーに安全なセルフサービス操作を提供できます。

AppRegistryの現在地（§5）

AppRegistryは2026年7月30日をもって新規顧客の受付を終了し、メンテナンスモードへ移行しています（既存顧客は継続利用可能、機能追加・新リージョン展開なし）。新規採用を検討している場合は、AWS Resource Groups・Resource Explorer・CloudWatch Application Signalsへの移行を推奨します。既存ユーザーにとっては、awsApplicationタグを活用したコスト配賦（AWS Billing/Budgets）・Config/Security Hubのスコープ共通化の価値は引き続き有効です。

Security Hub集約コンプライアンス（§6）

Service CatalogとSecurity Hubの間にネイティブ統合は存在しません。AWS Configが継続評価エンジン、Security Hubが集約レイヤーという2層構造が正確なアーキテクチャです。Service Catalogが自動付与するタグ（aws:servicecatalog:portfolioId・aws:servicecatalog:productIdなど）をConfigルールのスコープ条件として活用することで、Service Catalog経由で作成したリソースのみを対象とした精密なコンプライアンス評価が実現します。

StackSets大規模展開制御（§7）

StackSet制約を用いたマルチアカウント展開では、ProvisioningPreferencesの4パラメータ（MaxConcurrencyCount/Percentage・FailureToleranceCount/Percentage）で同時実行ウィンドウを制御します。製品バージョンの強制移行は、新バージョンの公開→UpdateProvisionedProductによる既存スタックの一括更新→旧バージョンのDEPRECATED化という順序で進め、移行ロールアウト計画と組み合わせることで大規模環境でも安全に実施できます。

8-2. 本番運用推奨チェックリスト（Vol2範囲）

8-3. 対象AWS試験・コスト・関連リソース

本記事で扱う設計知識は、AWS Certified Solutions Architect – Professional（SAP） および AWS Certified DevOps Engineer – Professional（DOP） の試験範囲に含まれます。特に、Service Catalogの制約設計・Organizations連携・StackSets大規模展開制御は両試験で出題頻度が高いトピックです。

コストについて: AWS Service Catalog自体は無料です。費用は、Service Catalog経由でプロビジョニングされたリソース（EC2・RDS等）の利用料として発生します。StackSet制約を使用する場合は、デプロイ先アカウント数とリージョン数に応じたStackSetスタックインスタンス数に留意してください。

試験対策の実践演習には、以下のリソースもあわせてご活用ください。

Vol1の基礎から本記事Vol2の高度運用まで、AWS Service Catalogの全体像をシリーズで体系的に学べます。