毎月のアカウント利用料を通知する機能をCloudFormationで作ってみた！
hiropy
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
AWS Service Catalogを活用した自由度とガバナンスの両立の実現方法
tecchan
AWSを導入するエンタープライズ企業では、インフラ利用の自由度とガバナンスの両立が大きな課題となっています。自由度を高くするとコストやセキュリティリスクの悪化につながりますが、ガバナンスを強化しすぎると開発のスピードが低下し、ビジネスの競争力に影響を与えます。
このような課題の解決策として有効なのがAWS Service Catalogです。本記事では、AWS Service Catalogを活用することで、企業がインフラの自由度とガバナンスを両立する詳細な方法と具体例を解説します。また、クラウド活用を高度化するためのビジネス課題を起点とした全社的なアプローチについても触れていきます。
AWS Service Catalogの概要
AWS Service Catalogは、承認済みのAWSリソースをカタログ化し、利用者が迅速に払い出しをできるようにするサービスです。例えば3層Webアプリのテンプレートを登録すれば、開発者はワンクリックでそのためのAWSリソースをデプロイすることができます。
AWS Service Catalogの機能の詳細は以下の公式ドキュメントをご参照ください。
本ブログでは、主に以下の２つの要素に触れながら解説を進めます。
- 製品：AWS CloudFormationテンプレートを基に定義されたAWSのリソースのセット。
- ポートフォリオ：複数の製品をグループ化したもの。グループやユーザごとにアクセス権が設定可能。
自由度とガバナンス両立の課題
当社がご支援を提供する中でも、多くの企業が自由度とガバナンスの両立に課題を抱えています。ここではその例を3つ紹介します。
課題1: スキル不足によるコスト・セキュリティリスク
AWSの柔軟性は利点ですが、スキル不足によるコスト増加やセキュリティリスクの発生が課題となっています。特にオンプレミスからクラウドへの移行フェーズの企業では、全員がクラウドの知見を持っているわけではありません。このようなパブリッククラウドの特徴と利用者のスキル不足により、次のような問題が発生します。
-
コスト管理の問題
- 不要リソースの放置やライフサイクル管理の欠如により無駄なコストが発生する。
- リソースのサイジングやサービス選定の考慮不足により、オーバースペックな設計になる。
-
セキュリティリスク
- Security GroupやNetwork ACLの不適切な設定により企業の機密情報が外部に漏洩する。
- AWS WAFやAWS Shieldの不適切な設定により不正アクセスやDDoS攻撃のリスクが高まる。
-
事業継続性のリスク
- リージョンやAZ障害への対策不足によるシステム停止のリスクが発生する。
- バックアップ・レプリケーション未整備によるデータ消失のリスクが高まる。
これらのリスクを避けるには、開発者はアプリケーション構築だけでなくAWSの知見も必要です。しかし、システム担当者は日々の業務に追われ、学習の時間を確保しにくいという課題があります。
課題2: 自由度とガバナンスのトレードオフの難しさ
スキルレベルが高くなると、適切なガバナンスを維持しながら開発の自由度を確保することで開発効率を向上することが求められます。しかし、バランスを誤ることで以下のような課題が生じます。
-
過剰なガバナンスによる開発スピードの低下
- ガバナンスを徹底することでインフラチームの負担が大きくなり、開発のボトルネックになる。
- 開発チームの自由度がなくなり、スキルが習得できず企業の競争力が低下する。
-
ガバナンス不足による運用リスクの増加
- 利用者のスキルレベルに過度に依存することで、人的ミスが大きな障害につながるリスクがある。
- システムの属人化が進み、異動時の引き継ぎや保守コストが増大する。
このトレードオフを解決するにはインフラとアプリの両担当が連携し、 ガバナンスを維持しながら自由度を高める仕組みを構築することが必要です。
課題3: クラウド活用の高度化と標準化の障壁
自由度とガバナンスの適切なバランスが取れるようになった場合、続いてクラウドの高度活用のステップへと進みます。ここではクラウドネイティブ化やコスト最適化、共通コンポーネント活用による開発効率向上等の取り組みが行われます。これらを進めるにあたり、以下のような課題があります。
-
コスト最適化の課題
- クイックウィンでのコスト最適化を進めたいが、リソースのタグ付けルールが整備されておらずクラウドコストの可視化ができない。
- クラウドネイティブ化を推進したいがクラウド利用状況が把握できず、全社的な移行戦略を立案できない。
-
共通コンポーネント活用の課題
- 自社のセキュリティ標準に準拠するために、各アプリが同様のコンポーネントを作成しており非効率。
- AWS Control Towerを利用してアカウント管理をしているが、ログ管理やセキュリティ監視の仕組みがアプリケーションによって異なるため、一元的なオブザーバビリティ（可観測性）の実現が難しい。
これらの課題を解決するためには、自由度とガバナンスを両立しつつ、クラウドの高度活用に向けたインフラ管理の仕組みが必要です。
AWS Service Catalogで対応する課題のユースケース
これらの課題を解決するために、AWS Service Catalogを活用したインフラ管理の運用モデルを「自由度とガバナンスのバランス」に着目して3つに整理します。
1. 完全管理型（ガバナンス重視）
-
対象：クラウドスキルが不十分な組織や、厳格なコンプライアンスが求められる企業
-
コンセプト：インフラチームがリファレンスアーキテクチャを定義し、それに準拠するAWS Service Catalogを登録する。アプリチームはカタログから製品を選択し、AWSリソースを払い出すことでガバナンスを強化する。
-
特徴：
- 設計の責任: インフラチームが全ての設計・管理を担当し、アプリチームは選択のみを行う。
- AWS Service Catalogの役割: リファレンスアーキテクチャの実装手段として機能。
- インフラチームの関与: 強い（設計・ポートフォリオ提供）。
- ポートフォリオ更新ルール: インフラチームが定期的（例：四半期ごと）にアップデートを実施。
2. バランス型（自由度とガバナンスの両立）
-
対象： クラウドスキルにバラツキがあり、標準化が必要な企業
-
コンセプト：アーキテクチャ設計はアプリチーム自身で行い、インフラチームはレビューを行う。承認された場合に、利用者はスキルレベルに合わせたService Catalogのポートフォリオから製品を選択しリソースの払い出しを行う。
-
特徴：
- 設計の責任: アプリチームが主体的に設計し、インフラチームがレビュー・承認を担当。
- AWS Service Catalogの役割: レビュー済みの標準的な環境を提供し、スキルレベルに応じたポートフォリオを準備。
- インフラチームの関与: 中程度（設計レビューとポートフォリオ提供）。
- ポートフォリオ更新ルール: アプリチームからの変更提案を随時受け付け、インフラチームが適切性を評価。変更は短期間（例：2週間ごと）に適用。
3. セルフサービス型（自由度重視）
-
対象：全社的に高度なクラウドスキルを持つ企業
-
コンセプト：アプリチームが自由に設計し、インフラチームが用意したポートフォリオから適切なリソースを選択する。 利用したいリソースが存在しない場合はアプリ側から提案し、インフラ部門がカタログを拡充する。
-
特徴：
- 設計の責任: アプリチームが全ての設計を担当。
- AWS Service Catalogの役割: 最低限の社内ルールを担保しながら、迅速なリソース提供を実現。
- インフラチームの関与: 最小限（ポートフォリオ提供のみ）。
- ポートフォリオ更新ルール: アプリチームが変更を随時提案でき、CI/CDパイプラインを活用してプルリクエストレビュー後に迅速に適用される。
3つの運用モデルの比較表
表形式に整理すると以下のようになります。
AWS Service Catalogは単一のソリューションではなく、ビジネス要件や開発チームのスキルレベルに応じて様々な運用モデルが考えられます。適切に選択することが、AWS環境の最適な活用につながります。
なお、AWS Service Catalogの製品テンプレートを更新するCI/CDパイプラインの構築については以下のチュートリアルをご参照ください。
AWS Service Catalog導入における考慮事項
AWS Service CatalogはAWSリソースの払い出しを管理するツールですが、設計プロセスやガバナンスの統制を直接サポートするものではありません。そのためAWS環境を適切に管理するには、AWS Service Catalogの活用とともに、払い出しプロセスの整備やドキュメント管理を組み合わせる必要があります。この章では、これらの具体的な活用方法を紹介します。
払い出しプロセスの整備
AWS Service Catalogは、適切なリソースを確実な払い出しをする仕組みを提供しますが、その前提となる「どのように設計し、どのような基準で承認するのか」の制御はできません。そこで、以下のような「設計 → PoC → レビュー → リソース払い出し」のプロセスを確立することで、AWS Service Catalogの運用を補完することができます。なお、アプリ設計とPoCは並行して行うことも多いです。
- アプリ設計：アプリケーションの設計をAWSのベストプラクティスに基づき実施する。
- PoC（概念実証）：設計内容が実際の環境で問題なく機能するかを検証する。
- レビュー：設計の妥当性を確認し、リソース払い出しの準備を整える。
- リソース払い出し：承認された設計を基に、実際のAWSリソースを払い出す。
この場合、AWS Service Catalogが有効であるのは「4. リソース払い出し」のフェーズのみであり、設計の品質自体はそれ以前にある程度は決まっています。そこを補うために払い出しプロセスの確立を組み合わせることが有効です。
ドキュメントの整備
払い出しプロセスを現実的に運用に乗せるためには、関係者が基準や手順を統一して理解し、運用できる状態であることが不可欠です。そのためには、各プロセスごとに必要なドキュメントを整備することが有効です。例として以下のドキュメントの整備を考えます。
-
アプリ設計
- セキュリティ基準やコンプライアンス要件を記載した社内セキュリティルール
- AWS Well-Architected Frameworkに準拠したリファレンスアーキテクチャ
-
PoC（概念実証）
- PoCのためのサンドボックス環境の利用制限を示した利用ガイド
- 実施すべき事項をまとめたナレッジベース
-
レビュー
- 統一性を担保するためのテンプレートドキュメント
- レビュー効率を向上させるためのレビュー観点表
-
リソース払い出し
- AWS Service Catalogを通じてリソースを払い出すためのユーザガイド
- AWS Service Catalogのメンテナンスに関する管理者向け手順書
- AWS Service Catalogの製品やポートフォリオの追加ルール
システム、プロセス、ドキュメントの相互補完のまとめ
以下の表に示すように、システムだけでなくそれぞれの要素を整備することで、自由度とガバナンスを両立のためのAWS Service Catalogの効果をより一層高めることが可能となります。
具体的な実践例
これまでの内容についてより具体的なイメージが湧くように、実践例を考えます。なお、これはあくまで例であり、実際に適用する場合はそれぞれの会社の特性やニーズに合わせた実装をご検討ください。
AWS環境の課題と背景
ある事業会社では、インフラ部門でAWSリソースの払い出しの管理をしています。開発部門はインフラ部門にAWS環境の払い出しを依頼し、払い出されたAWSリソース上に業務アプリケーションを構築します。インフラ部門は依頼に基づいて単純に払い出しを行っているため、以下のような課題が発生していました。
- インフラ部門によるAWS環境の払い出しの平均リードタイムが5日かかっており、アプリケーション開発のボトルネックになっている。
- クラウド活用経験の浅い開発チームでは、リソースの適切なサイジングができておらず不要なコストが発生していたり、セキュリティグループの設定不備により外部からのアクセスリスクが高まっている。
- クラウド活用経験の豊富な開発チームからはより柔軟で迅速なリソース提供を求める声が上がっており、一部の部門では独自でAWS環境を契約するシャドーITが発生し、ガバナンスが低下している。
これらの課題に対処するためのService Catalogの導入を検討します。
Service Catalog導入の方針
今回のユースケースでは、「AWS Service Catalogとその活用例」で紹介されている3つの導入モデルのうち、「バランス型」を選択します。理由は主に以下の2点です。
- 組織内のAWS知識レベルにバラつきがあるため、厳格なガバナンスだけでは効率が悪い。
- シャドーITの発生を抑制するため、完全な自由ではなく一定のガバナンスを維持する必要がある。
適用するプロセスとレビューフローの効率化
まずは運用面の整備について見ていきます。「AWS Service Catalogの課題とその解決方法」の章で、以下の表を紹介しました。
ここでは「レビュー」に焦点を当てて具体例を考えます。今回のシナリオでは以下のようなレビュールールを設けます。
- クラウド活用経験の浅い部門に対しては、インフラ部門によるオンラインでのレビュー会議を設定することを必須とする。
- クラウド活用経験の豊富な開発チームでは、社内標準を満たしたアーキテクチャ設計書と、PoCでの検証結果を提出することを条件に非同期でのレビューとする。
レビュープロセスの効率化については、AWS Service Catalog Connector for ServiceNowの活用を検討します。これを利用することで、ServiceNowの承認フローとAWSリソースのプロビジョニングを統合する事が可能です。
詳細は以下の記事もご参照ください。
ポートフォリオと製品の設計
続いて技術面についてです。AWS Service Catalogの設計について以下のようなコンセプトを考えます。
- 各利用部門の業務要件やスキルレベルに応じたポートフォリオを作成し、適切な製品を登録する。
- クラウド活用経験の浅い部門向けには、リファレンスアーキテクチャに1:1で対応する製品を用意し、ワンクリックでのデプロイを可能とする。
- クラウド活用経験の豊富な部門向けには、細分化されたインフラリソース（VPC、EC2、RDS、ECSなど）を個別の製品として提供し、それを組み合わせて利用できるようにする。
上記を元に、ポートフォリオと製品を図示すると以下のようになります。
-
ポートフォリオ1：クラウド導入初期段階の開発チーム向けポートフォリオ
- 3層Webアプリケーション、サーバレスアプリケーションなど、標準化されたアーキテクチャパターンを提供。
- 開発チームは、これらのテンプレートを選択し、パラメータを一部入力するだけで、安全かつ迅速に環境を構築できる。
-
ポートフォリオ2：クラウド活用経験の豊富な開発チーム向けポートフォリオ
- VPC、EC2、RDS、ECS、IAMロールなど、個別のAWSリソースを柔軟に組み合わせるための製品を提供。
- 開発チームは、これらの製品を自由に選択し、パラメータを細かく設定することで、独自のアーキテクチャを構築できる。
-
ポートフォリオ3：特定の部署（データ分析部門）向けポートフォリオ。
- S3、Redshift、Athena、QuickSightなど、データ分析に必要なAWSサービスを組み合わせたテンプレートを提供
- 開発チームは必要なリソースのみにアクセスすることができ、必要なサービスの中からニーズに合ったアーキテクチャを構築できる。
その他、部門特有のニーズにも対応可能です。例えば、基幹システムのクラウド移行を担う部門向けには、AWS Application Migration Service（MGN）との連携を強化したポートフォリオや、Amazon WorkSpacesで構築されたセキュアなハンズオン学習環境を提供するトレーニング環境ポートフォリオなども用意できます。
権限管理の設定に方法については以下のようなホワイトペーパーを参考にすることが可能です。
導入による期待効果
これらの取り組みにより、当初に発生していた課題を以下のように解決することが期待できます。
- 払い出しプロセスの整備により、リソース払い出しにかかる平均リードタイムが短縮される。
- クラウド活用経験の浅い部門はリファレンスアーキテクチャやオフラインレビューなどの支援を受けることで、AWS利用料およびセキュリティインシデント発生件数が抑制される。
- 経験豊富なチームは柔軟な環境構築が可能となり、シャドーITのうち大半が管理アカウント配下に移行される。
このように、AWS Service Catalogの最適な活用パターンの選択と、それを補完するプロセスやドキュメントの整備により、自由度とガバナンスの両立というビジネス課題を、高いレベルで解決することが可能となりました。
まとめ
AWS Service Catalogを最大限に活用するためには、企業の課題を起点に考えることが重要です。そこからAWS Service Catalogの活用パターンや業務プロセスの整備、加えてトレーニングやインフラ部門からの支援もセットで考えることで、より高いレベルで企業の課題解決にアプローチをすることが可能となります。
クラウド環境における自由度とガバナンスの両立は、クラウドサービスの機能のみでは完結できず、全方位で考える必要があります。本記事で紹介した内容を一例として、それぞれの企業に応じた更に視野の広いソリューションや仕組みの構築に役立てていただけますと幸いです。
AUTHOR
金融業界のSIerにて5年間勤務。大小様々な規模の案件にてプロジェクトマネジメントを経験後2022年5月にDWSへ入社。最先端の技術を用いる開発業務を担当。最近では先端技術への理解とマネジメントの経験を活かし、スクラムマスターとして案件を推進。2023, 2024 Japan AWS All Certifications Engineer。認定スクラムマスターPSMⅡ取得。
