AWS Service Catalog - セルフサービス型ITカタログとガバナンス統制 ​

AWS Service Catalog は、企業でAWSリソースを安全かつ効率的に配布するためのサービスです。IT部門が事前に承認したクラウド環境の設定を「商品カタログ」のように整理し、各部門の担当者が自分で必要なリソース（サーバーやデータベースなど）を簡単に作成できるようにします。

例えば、開発チームが新しいWebサーバーが必要になったとき、IT部門に依頼して数日待つ代わりに、承認済みの「Webサーバーセット」を自分でワンクリックで作成できるイメージです。この仕組みにより、IT部門は統制を保ちながら、各部門の作業効率を大幅に向上させることができます。

Service Catalog の基本概念 ​

Service Catalogの全体像 ​

Service Catalogは「ITリソースのアプリストア」のような仕組みです。アプリストアでアプリをダウンロードするように、承認されたクラウドリソースを簡単に入手できます。

基本的な仕組み：

  • IT部門: 安全で標準化されたクラウド環境のテンプレートを事前作成
  • 各部門: 必要な時に承認済みのテンプレートを選んで、簡単な設定だけで利用開始
  • Service Catalog: 両者の間に立って、安全性と利便性を両立

コアコンポーネントの理解 ​

Service Catalogは、ポートフォリオ、プロダクト、制約という3つの主要要素で構成されます。

プロダクトとポートフォリオ ​

プロダクト設計の原則 ​

プロダクトとは何か ​

プロダクトは、AWS上で動作する「システムの部品」のようなものです。例えば：

  • Webサーバーセット: サーバー、ロードバランサー、セキュリティ設定をまとめたもの
  • データベース環境: データベースサーバーと必要なバックアップ設定のセット
  • 開発環境: 開発者が使う仮想マシンとツール群

プロダクトのバージョン管理 ​

プロダクトには複数のバージョンが存在し、それぞれ異なるステータスを持ちます：

  • Active（アクティブ）: ユーザーが新規作成できるバージョン
  • Inactive（非アクティブ）: 新規作成できないが、既存リソースは継続使用可能
  • Deleted（削除済み）: 完全に使用不可になったバージョン

この仕組みにより、セキュリティパッチや機能改善を段階的に展開できます。

ポートフォリオによる分類管理 ​

ポートフォリオによる整理 ​

ポートフォリオは、関連するプロダクトをグループ化したものです。実際のオンラインショップで商品が「家電」「本」「服」にカテゴリ分けされているのと同じように、IT環境も整理して管理します。

部門別の整理例：

  • 開発部門向け：Webサーバー、テストサーバー
  • 営業部門向け：CRMシステム、レポート生成環境
  • 人事部門向け：勤怠管理システム、データ分析環境

環境別の整理例：

  • 本番環境：実際にお客様が使うシステム
  • テスト環境：動作確認用のシステム
  • 開発環境：プログラマーが作業用に使うシステム

この整理により、各部門の担当者は自分に必要なプロダクトだけを見つけやすくなります。

セルフサービス型プロビジョニング ​

エンドユーザーエクスペリエンス ​

Service Catalog は、技術的詳細を隠蔽し、シンプルなインターフェースを提供します。

プロダクトパラメータ設計 ​

ユーザビリティを考慮した入力設計 ​

yaml
パラメータ設計例:
  Webサーバープロダクト:
    必須パラメータ:
      - プロジェクト名: [文字列]
      - 環境タイプ: [本番/ステージング/開発]
      - 責任者メール: [メールアドレス]
    
    オプションパラメータ:
      - インスタンスタイプ: [ドロップダウン選択]
      - バックアップ有効: [真偽値]
      - 監視レベル: [基本/拡張]
    
    隠蔽パラメータ:
      - VPC設定: [組織標準値を自動設定]
      - セキュリティグループ: [事前定義済み]
      - AMI ID: [最新承認済みAMI]

制約とガバナンス ​

制約による安全な運用 ​

Service Catalogでは「制約」という機能で、組織のルールに従った安全なリソース作成を保証します。会社の経費精算システムで「交通費は5万円まで」「会食費は1万円まで」といった上限が設定されているのと似た考え方です。

制約の種類と具体例 ​

Launch Constraints による権限制御 ​

セキュアなリソース作成 ​

Launch Constraints - 安全な権限管理 ​

権限の適切な分離 ​

Launch Constraintsは「代理作成」の仕組みです。一般の社員がAWSリソースを直接作成する権限は持たせず、Service Catalogが代わりに安全に作成します。

具体的なメリット：

  • 社員：「Webサーバーが欲しい」とリクエストするだけ
  • Service Catalog：事前に定義された安全な設定でリソースを自動作成
  • IT部門：すべての作成履歴を監視・管理

この仕組みにより、セキュリティを保ちながら必要なリソースを迅速に提供できます。

Template Constraints - 設定値の自動チェック ​

不正な設定を事前に防止 ​

Template Constraintsは、ユーザーが入力した設定値が会社のルールに従っているかを自動チェックする機能です。

チェック例：

  • 本番環境では、承認された安全なサーバータイプのみ使用可能
  • 高額なサーバータイプは管理者承認が必要
  • 特定の地域でのみリソース作成を許可

具体的な動作シナリオ：

  1. ユーザーがWebサーバーの設定で「超高性能サーバー」を選択
  2. システムが「このサーバーは月額50万円です。承認が必要です」と警告
  3. 承認されたサーバータイプへの変更を促す

この自動チェックにより、予算オーバーやセキュリティ違反を事前に防止できます。

CloudFormationと外部エンジンの統合 ​

プロビジョニングエンジンの選択肢 ​

Service Catalogでは、複数のプロビジョニングエンジンをサポートしています：

CloudFormation（標準） ​

  • AWSネイティブなインフラストラクチャコードツール
  • JSONまたはYAML形式でリソースを定義
  • AWSサービスとの最適な連携

外部エンジン（EXTERNALタイプ） ​

  • Terraform: HashiCorp社のインフラストラクチャコードツールをサポート
  • マルチクラウド対応のテンプレートを利用可能
  • 既存のTerraformアセットの再利用が可能

再利用可能なテンプレート作成 ​

モジュラー設計パターン ​

yaml
テンプレート設計原則:
  単一責任原則:
    - 1つのプロダクト = 1つの明確な機能
    - 関連するリソース群の適切なグルーピング
    - 依存関係の明確化
  
  パラメータ化:
    - 環境固有値の外部化
    - デフォルト値の適切な設定
    - 検証ルールの実装
  
  出力定義:
    - 重要な情報のエクスポート
    - 他システムとの連携ポイント
    - 運用に必要な情報の提供

標準化されたリソース構成 ​

yaml
CloudFormation設計例:
  Webサーバー環境:
    Resources:
      - EC2 Instance (Auto Scaling対応)
      - Application Load Balancer
      - Security Groups (標準設定)
      - CloudWatch Alarms
      - IAM Role (最小権限)
    
    Parameters:
      - ProjectName: タグ付けに使用
      - Environment: 環境別設定制御
      - InstanceType: パフォーマンス調整
      - KeyPair: セキュアアクセス
    
    Outputs:
      - LoadBalancerDNS: アクセスポイント
      - InstanceID: 運用管理用
      - SecurityGroupId: 連携用

高度な活用パターン ​

マルチアカウント展開 ​

Organizations統合による組織展開 ​

マルチアカウント展開の仕組み ​

AWS Organizationsと統合することで、複数のAWSアカウント間でService Catalogを効率的に運用できます。

ポートフォリオ共有のプロセス：

  1. 共有: Hubアカウントがポートフォリオを他アカウントに共有
  2. 受け入れ: 各SpokeアカウントがAcceptedPortfolioShareリソースで共有を受け入れ
  3. 利用開始: 受け入れ後、各アカウントのユーザーがプロダクトを利用可能

参照共有 vs コピー共有：

  • 参照共有: Hub側の更新が自動的にSpoke側に反映される
  • コピー共有: 各アカウントに独立したコピーを配置（手動更新が必要）

自動化とCI/CD統合 ​

継続的な改善プロセス ​

Service Catalogのプロダクトは、Git やCI/CDツールと連携して継続的に改善できます。

品質保証の自動化：

  • 新しいテンプレートは複数の技術者がレビュー
  • セキュリティや設定ミスを自動検出
  • テスト環境での検証後に本番環境へ適用

運用最適化：

  • 利用状況データに基づいた人気プロダクトの特定
  • 使用されていない無駄なリソースの発見・削除
  • セキュリティアップデートの自動適用

運用管理とモニタリング ​

プロビジョニング状況の可視化 ​

管理ダッシュボードでの一元管理 ​

Service Catalogでは、組織全体のクラウド利用状況を一元的に把握できます。

具体的な監視内容：

  • 利用状況の分析: どのプロダクトがよく使われ、エラーが多いか
  • コスト管理: 部門別・プロジェクト別の費用分析、予算超過の早期警告
  • セキュリティ・コンプライアンス: すべての活動履歴、規制遵守状況

ライフサイクル管理 ​

プロビジョニング済みプロダクトの管理 ​

トラブルシューティング ​

よくある問題と対処法 ​

プロビジョニング失敗：

  • 症状：「リソースの作成に失敗しました」エラー
  • 原因：多くの場合、設定されたIAM権限が不十分
  • 対策：Launch Constraintで設定された権限を確認・修正

パラメータ検証エラー：

  • 症状：「入力値が無効です」エラー
  • 原因：Template Constraintで設定されたルールに違反
  • 対策：エラーメッセージに従って入力値を修正、または制約ルールの見直し

CloudFormation関連エラー：

  • 症状：リソース作成途中で停止
  • 原因：AWSのリソース上限に達している、または依存関係の問題
  • 対策：テンプレートの設計見直し、事前のテスト環境での検証強化

セキュリティとコンプライアンス ​

アクセス制御設計 ​

役割別のアクセス制御 ​

カタログ管理者（IT部門の責任者）：

  • Service Catalog全体の設計・運用責任
  • プロダクトの承認・却下の決定権
  • 利用者の権限管理
  • セキュリティポリシーの策定・運用

プロダクト開発者（IT部門の技術者）：

  • CloudFormationテンプレートの作成・更新
  • 新しいプロダクトの開発・テスト
  • 既存プロダクトのバージョンアップ

エンドユーザー（各部門の担当者）：

  • カタログからのプロダクト選択・利用
  • 自分が作成したリソースの基本的な管理
  • 必要に応じたリソースの削除や設定変更

この役割分担により、適切な権限分離とセキュリティを保ちながら、効率的な運用を実現できます。

監査とコンプライアンス ​

包括的な監査・記録機能 ​

すべての活動を記録：

  • いつ、だれが、どのプロダクトを作成・変更・削除したか
  • 管理者によるシステム設定の変更履歴
  • 失敗したアクセス試行の記録

コンプライアンス対応：

  • 金融業界やヘルスケア業界の規制要件への対応
  • セキュリティポリシー遵守状況の自動レポート
  • 監査人への証跡提供機能

リスク管理：

  • 不審な活動パターンの検出
  • 権限の不正利用の早期発見
  • インシデント発生時の原因究明支援

まとめ ​

AWS Service Catalogは、企業のクラウド活用を安全かつ効率的に進めるための重要なサービスです。IT部門は統制を保ちながら、各部門の担当者は専門知識がなくても必要なクラウドリソースを迅速に利用できる環境を実現します。

適切に設計されたService Catalogの導入により、以下のメリットが得られます：

  • 作業効率の大幅向上：数日かかっていたリソース作成がワンクリックで完了
  • コスト管理の改善：事前承認されたリソースのみ使用、予算超過の防止
  • セキュリティの強化：標準化された安全な設定の自動適用
  • コンプライアンスの確保：すべての活動履歴を自動記録・監査対応

組織の規模やニーズに応じて段階的に導入することで、クラウド活用の成熟度を着実に向上させることができます。

引用元：