Service Catalogを数年ぶりに使ってみて思ったこと

背景

数年ぶりにService Catalogを触ることになったので、備忘がてらこちらに内容を残しておこうと思います。

2022年頃に触っていたのですが当時と比較してTerraformのサポートなど新機能も追加されており、これから導入を検討していらっしゃる方などの手助けになったら幸いです。

想定読者

本記事は以下の方々を想定しています。

• AWSインフラ管理者・運用担当者
• 情報システム部門・セキュリティ担当者

Service Catalogとは

AWS Service CatalogはAWSリソースのカタログを作成・管理し、組織内のユーザが承認済みのリソースを簡単にデプロイできるようにするサービスです。

特殊な概念として製品とポートフォリオが存在しています。簡単にまとめると下記のような概念です。

• 製品：CloudFormationまたはTerraformのテンプレートで、実際のリソースが記載されています。
• ポートフォリオ：製品を整理・管理するためのコンテナで、複数の製品をグループ化したものになります。

事前に定義したIaCテンプレートを「製品」として登録することでエンドユーザはポートフォリオから選択するだけで、標準化されたリソースをデプロイすることが可能になります。

複数の環境に何度もデプロイするものもの(例えば、IAMユーザのパスワード期限切れ通知の仕組みなど)については、Service Catalogを使うことによって誰でも簡単にデプロイできるようになります。

Service Catalogの仕組み

実施内容

① 製品の作成と登録(管理者アカウント)

管理者は特定のアカウントで製品とポートフォリオを作成し、Service Catalogコンソール経由で登録を行います。

② ポートフォリオへの製品追加（管理者アカウント）

登録された製品を適切なポートフォリオに追加します。例えば「開発環境ポートフォリオ」に開発用の製品をまとめます。

製品は複数のポートフォリオに登録することが可能なので、VPCなどは使い回されることが多いです。

③ ポートフォリオの共有（管理者アカウント）

作成したポートフォリオはアカウント単位で共有が可能です。

大体の場合は管理者アカウントで一括でポートフォリオを監視しておき、そこから各アカウントに共有しておくことが多いです。

④ ポートフォリオのインポートとアクセス権限の付与（利用アカウント）

共有されたポートフォリオを利用アカウント側でインポートします。

インポートしたポートフォリオに対して、製品を起動できるIAMユーザ、グループ、ロールを指定します。

ここでインポートされポートフォリオと製品を用いて利用アカウント側でリソースのデプロイを行います。

Service Catalogの利用シーン

過去には下記のような使い方をしていました。

• アプリチームへのPoC環境提供
  • 小規模なWebアプリ検証環境：VPC + ALB + ECS + RDS
  • SFTPサーバ利用環境：VPC + AWS Transfer Family + S3

特に「インフラ側の設定はお任せでいいよ」と言う時には非常に重宝していました。導入して以降、アプリチームが自分たちで起動・削除ができるようになったためインフラ側への問い合わせが激減しました。

• 複数環境で利用される仕組みの一括導入
  • IAMユーザの自動無効化：EventBridge + Step Functions
  • CDパイプライン作成：CodePipeline + CodeDeploy + CodeBuild + S3

上記の使い方をしていて、一定の成果を上げることはできたのですがService Catalogにも苦手なシチュエーションが存在しています。

Service Catalogが向かないシチュエーション

ある程度作り込みをすることによって回避できるものもありますが、個人的には以下のようなケースはService Catalogが苦手としているものかなと思っています。

• 本番環境の作成

  • Service Catalogの仕様上、更新管理を厳密に行うのが非常に難しいです。例えば、初回デプロイ後に利用アカウント側のみで閉じる要件変更があった場合にはデプロイ先のアカウントで変更することになると思います。その際には利用者側で製品を触ることは想定していないため、手動での変更を実施することになります。この手動変更を行うと元々の製品とはドリフトが発生するため、管理者アカウント側で製品の一斉更新が入った場合にどのように取り込むのかで毎回頭を悩ませることになります。最悪の場合、手動変更のことを忘れた状態で上書きをかけてしまい想定外の変更が発生する場合が考えられます。

• 同一環境内でのリソースデプロイ

  • ポートフォリオによってはIAMやS3など同一の製品が含まれている場合があります。その場合、リソースの名前が一意にならなければデプロイに失敗してしまいます。ここでは命名規則を明示的に設けることで回避することはできますが、自動で割り振ることは難しいです。

• 頻繁に変更が入るリソース

  • 更新を行うには管理アカウントで製品のバージョンを更新し、再度登録する手間が発生します。頻繁に変更を入れようとするとService Catalogの変更を取り入れる担当を常に準備しておく必要が出てきます。
    少人数のチームでこのようなことをやってしまうと運用が破綻してしまうので、不向きかなと思います。(この辺りはService Catalogの思想ともあっていないので、採用するなよってことなのかもしれませんが...)

終わりに

久しぶりにService Catalogを使いましたが、PoC〜開発環境向きだなという印象は当時と変わっていません。

これ以外の使い方があまり浮かんでいないので、「こんな使い方をしたことがある」などを教えていただけますと幸いです。

余談ですけど、Service Catalogを業務で使っている人をあまり見かけたことがないのでサービス終了しないかちょっとだけ心配しています。