AWS Service Catalog

AWS Service Catalog は、組織で承認した IT 製品（インフラやアプリケーションのテンプレート）をカタログとして整理し、エンドユーザーが必要なものを自分で選んで展開できるようにする管理サービスです。管理者は CloudFormation テンプレートなどで「承認済みの構成」を定義し、利用者は中身の詳細を意識せず、決められた範囲のパラメータだけを指定して環境を立ち上げます。ガバナンスを保ちつつ、利用者の自律性とスピードを両立させる点が特徴です。

解決する課題

組織が成長すると、各チームが独自にリソースを作り始め、構成がばらばらになりがちです。一方で中央のインフラチームに全依頼を集約すると、今度はそこがボトルネックになります。Service Catalog はこの緊張関係を解きます。

• 利用者に自由にリソースを作らせると構成が標準から外れ、ガバナンスが崩れる
• かといって中央チームに依頼を集約すると、展開のたびに待ち時間が生まれる
• どのチームも同じ構成（ネットワーク・タグ・セキュリティ設定）を再利用したいが徹底できない
• 利用者に強い IAM 権限を渡さずに、限定された範囲だけ自分で展開させたい
• 何が誰によって展開されているかを一元的に把握・統制したい

主要概念と用語

• 製品（Product）: 展開可能な IT サービスの単位。多くは CloudFormation テンプレートやその他の IaC で定義される
• ポートフォリオ（Portfolio）: 関連する複数の製品をまとめ、利用者やアカウントへアクセス権を付与する単位
• プロビジョニング済み製品（Provisioned Product）: 利用者が製品を起動して実体化したスタック相当のリソース群
• 起動制約（Launch Constraint）: 製品の展開時に使われる IAM ロールを指定し、利用者本人の権限と切り離す仕組み
• 制約（Constraints）: 展開時の振る舞いを制御するルール群。起動・テンプレート・通知・タグ更新などの種類がある
• バージョン: 製品テンプレートの版。新版を追加しつつ旧版も提供し続けられる
• 共有: ポートフォリオを別アカウントや AWS Organizations 内の組織単位へ配布する仕組み
• TagOptions: 製品に付与すべきタグの選択肢ライブラリ。タグ付けの標準化に使う

仕様・制限・クォータ

• 製品は主に CloudFormation テンプレートとして定義し、ポートフォリオ単位でアクセス権を管理する
• 利用者へのアクセス付与は IAM プリンシパル（ユーザー・グループ・ロール） をポートフォリオに関連付けて行う
• 製品・ポートフォリオの数、1 製品あたりのバージョン数などには アカウント単位のクォータがあり、必要に応じて引き上げを申請できる場合がある
• ポートフォリオは AWS Organizations と統合して組織内の複数アカウントへ共有でき、共有先での委任管理も構成できる
• 起動制約に指定したロールは、CloudFormation がリソースを作成・更新・削除するのに十分な権限を持つ必要がある

内部の仕組み

Service Catalog の中心は、製品テンプレートとそれを束ねるポートフォリオ、そして「誰がどの製品を起動できるか」を決めるアクセス制御です。利用者が製品を起動すると、裏側では多くの場合 CloudFormation スタックが作成され、その実体がプロビジョニング済み製品として管理されます。

• 利用者は製品が定義する限られたパラメータだけを入力し、テンプレート内部の詳細には触れない
• 起動制約を設定すると、展開時には利用者本人ではなく指定した IAM ロールの権限でリソースが作られる。これにより利用者へ直接強い権限を渡さずに済む
• テンプレート制約でパラメータの取り得る値（例: 許可するインスタンスタイプ）を絞り込み、想定外の構成を防ぐ
• バージョン管理により、新しいテンプレートを追加しても既存のプロビジョニング済み製品はそのまま運用でき、利用者は適切なタイミングで新版へ更新できる

設計パターン / ベストプラクティス

• ガードレール付きセルフサービス: 起動制約とテンプレート制約を組み合わせ、利用者には承認済み構成だけを限定パラメータで展開させる
• 組織横断の標準配布: ポートフォリオを AWS Organizations で共有し、複数アカウントへ同じ承認済み製品を一括展開する
• タグの強制: TagOptions やタグ更新制約で必須タグを徹底し、コスト配分やガバナンスを担保する
• バージョンによる段階的更新: 既定バージョンを切り替えて新構成へ誘導しつつ、旧版の即時廃止による事故を避ける
• IaC との連携: 製品テンプレート自体をリポジトリで管理し、パイプライン経由で製品やバージョンを更新する

運用・監視

• CloudTrail で誰がどの製品をいつ起動・更新・終了したかを記録し、監査に用いる
• プロビジョニング済み製品の一覧から、展開状況やスタックの状態を把握できる
• 通知制約や連携により、製品の展開イベントを 通知として受け取れる
• 起動の裏側で動く CloudFormation のスタックイベントを確認すれば、失敗時の原因切り分けができる
• 製品テンプレートの更新時は、まず検証用ポートフォリオで試してから本番ポートフォリオへ反映するとよい

コスト

Service Catalog 自体は管理のためのサービスであり、課金の中心は展開されるリソース側にあります。

• Service Catalog の機能利用には、一般に製品やポートフォリオの管理に対する追加の大きな費用は発生しにくいが、上位の管理機能や利用形態によっては課金対象になる場合がある
• 主なコストは、利用者が製品を起動して実際に作られる EC2・RDS などのリソースに対して発生する
• テンプレート制約で選べるインスタンスタイプを絞ることで、利用者による過大なリソース起動を抑止できる

セキュリティ

• 利用者へは 製品を起動する権限のみを与え、実リソースの作成権限は起動制約ロールに分離して最小権限を保つ
• ポートフォリオへのアクセスは IAM プリンシパル単位で付与し、誰がどの製品を使えるかを明確にする
• テンプレート制約で許可されないパラメータ値を排除し、セキュリティ要件を満たさない構成の展開を防ぐ
• すべての操作は CloudTrail に記録され、展開の責任追跡が可能になる

Well-Architected の観点

• 運用上の優秀性: 承認済み構成のカタログ化により、展開を標準化・反復可能にし、中央チームのボトルネックを解消する
• セキュリティ: 起動制約による権限委譲と最小権限、テンプレート制約による逸脱防止、CloudTrail による監査性
• 信頼性: 検証済みテンプレートの再利用とバージョン管理で、構成のばらつきや手作業ミスを減らす
• コスト最適化: テンプレート制約とタグ強制で過大なリソース起動を抑え、コストを追跡可能にする

試験で問われるポイント

関連サービス・比較

製品の実体は多くの場合 AWS CloudFormation で展開されます。CloudFormation がインフラを記述・展開する基盤であるのに対し、Service Catalog はその上で「誰に何を承認済みとして使わせるか」というガバナンス層を提供します。

ハンズオン / CLI例

# ポートフォリオを作成する
aws servicecatalog create-portfolio \
  --display-name "標準インフラ" \
  --provider-name "PlatformTeam"

# CloudFormation テンプレートから製品を作成する
aws servicecatalog create-product \
  --name "標準VPC" \
  --owner "PlatformTeam" \
  --product-type CLOUD_FORMATION_TEMPLATE \
  --provisioning-artifact-parameters \
    'Name=v1,Type=CLOUD_FORMATION_TEMPLATE,Info={LoadTemplateFromURL=https://example.com/vpc.yaml}'

# 利用者が承認済み製品を起動する（セルフサービス展開）
aws servicecatalog provision-product \
  --product-id prod-xxxxxxxxxxxxx \
  --provisioning-artifact-id pa-xxxxxxxxxxxxx \
  --provisioned-product-name "team-a-vpc"