AWS標準化は、組織全体でAWSの利用ルールを統一し、その内容をガイドラインとして文書化する取り組みを指します。ルールを定める対象には、アカウントの分割方針、ネットワーク構成、権限設計、命名規則やタグ設計、運用と監視の方法、コストの管理方法などが含まれます。
ルールが定まらないまま利用部門が増えると、設計が担当者ごとに分かれ、環境によってセキュリティの設定が揃わなくなります。インシデントの調査で全アカウントの状態を確認する必要が生じたり、コストの全体像を把握できなくなったりすることもあります。
AWS標準化ガイドラインは、企業が自社のAWS利用について定める社内文書です。AWSの設計ガイドラインと運用ルールを文書にまとめたものです。AWSなどから策定の参考にできる資料は公開されていますが、何をどのように定めるかは自社の要件に合わせて各社が判断します。
AWS標準化ガイドライン策定のポイント
ガイドラインで定める内容は、次のように整理できます。
- アカウントと権限の設計：アカウントを分ける単位、組織に適用する統制、利用者ごとの操作権限
- ネットワークと外部接続：AWS環境内の構成、オンプレミス環境との接続、インターネット接続の方式、外部との通信を許す範囲
- データの保護：機密度に応じた分類とアクセス制御、保管時と通信時の暗号化
- 監視とログの取得：稼働状況を見る範囲、設定の変更を後から検知する仕組みの要否、ログの取得対象と保管期間
- 運用と復旧：環境をコードで作る方法の標準化、インシデント発生時の対応手順、バックアップと災害対策
- コストの管理：費用の配分方法、購入オプション、最適化の進め方
このうちアカウントと権限の設計、ネットワークと外部接続、データの保護は、AWSのセキュリティ設計にあたる領域です。たとえばアカウントと権限の設計においては、アカウントをどの単位で分けるか、全社で共通に使うアカウントをどう構成するか、組織やアカウントの単位でどの統制を適用するか、誰にどの操作を許すかなどを定めます。どこまで細かく決めるかは、守らせるルールを決めたいのか、システムの構成を揃えたいのか、設計の品質を揃えたいのかなどの目的によって変わります。
生成AI対応で検討すべきAWS標準化ガイドラインのポイント
生成AIの活用が広がるなかで、AWS標準化ガイドラインでも生成AIを対象に含めるかどうかが論点になります。生成AIの利用を現場が先に始め、統制の整備が追いついていない状態から検討に入る場合もあります。
生成AIの利用に関して考慮が必要になるのは、先に挙げた6つのポイントのうち、アカウントと権限の設計、データの保護、監視とログの取得、コストの管理の4つです。
アクセス管理の対象にモデルとデータが加わる
アカウントと権限の設計では、誰がどのAWSサービスを操作できるかを定めます。生成AIを利用する場合、この設計にどの利用者がどのモデルを使えるかという判断が加わります。制御には、利用者やグループに権限を割り当てるIAMや、組織やアカウントの単位で許可する操作の範囲を定めるSCPを使います。
データの保護では、データを機密度に応じて分類し、生成AIが参照・入出力・保存してよい範囲を明確にします。社内の文書を検索して回答に使うRAG（検索拡張生成）のような構成では、利用者ごとにどの分類までアクセスを許可するかも決めます。
監視の対象にAIの利用量が加わる
監視とログの取得では、サービスの稼働状況やリソースの状態を確認します。生成AIを利用する場合、この監視にAIの利用量が加わります。モデルが処理する入出力の量を表すトークンの消費量や、モデルごとの利用状況を、どの単位で取得するかを決めます。
コストの管理に関して、AIの利用量は費用に直結します。予算の枠を設けて急増を検知する運用を定めます。部門やプロジェクトの単位で費用を見えるようにするかどうかも判断します。また、誤った回答を報告する窓口を設けるか、有害な出力を止める仕組みを使うか、利用者からの評価を集めるかといった、出力の品質に関する方針を定めることもできます。
AWS標準化ガイドラインを策定する5ステップ
ここまで、ガイドラインで決めるポイントと、生成AIを対象に含める場合に加わる判断を整理しました。ここからは、策定を進める手順を5つのステップで解説します。各段階で何をどこまで決めるかは、自社の要件によって変わります。
ガイドラインの目的と適用範囲を明確にする
ガイドラインの目的や適用範囲、対象となる読者、記載する内容、利用方法を決め、関係者で共有します。社内のセキュリティ規定や運用規定との関係も整理が必要です。これらの規定は従来主流であったオンプレミス環境を前提に作られていることがあり、AWSの利用に当てはまらない内容が出てくることもあるでしょう。その場合、規定そのものを改訂するか、ガイドライン側でAWS利用時の扱いを補うかを決めます。
関係者を洗い出し、役割とタスクを整理する工程でもあります。ガイドラインに書く内容ごとに、合意を取る相手が変わるためです。セキュリティ対策の基準はセキュリティ部門、費用の配分ルールは経理部門というように、決定できる部署がそれぞれ異なります。AWS推進を担う部門、セキュリティ部門、共通基盤を提供する部門、システムの所管部門、運用管理の担当、経理部門が関わります。検討の段階から関係者を巻き込み、合意を形成します。
ガイドラインに記載する範囲を絞り込む
先に挙げたポイントや、自社に固有の検討事項などから、ガイドラインで扱う範囲を絞ります。目的から逆算し、遵守を求める統制、システムの構成ルール、設計方針のうちどこに重心を置くかを決めます。生成AIの利用を対象に含めるかどうかも、ここで判断します。
範囲を判断するときに考慮すべき点はいくつかありますが、代表的なものとして次の2点があげられます。1つは、構築や運用に外部のベンダーが入るかどうかです。入る場合は、ベンダーに与える権限とネットワークの経路まで決めておく必要があります。
もう1つは、利用部門が自分で構築するのか、情報システム部門が代行するのかです。利用部門が自ら構築する場合は、ガイドラインに書く範囲が、設計の標準や命名規則まで広がります。
統制の方式を決める
統制の考え方は、レギュレーション型とガードレール型の2つに大別されます。レギュレーション型は、許可することと禁止することを細かくルールとして定義し、事前に承認された利用だけを許可する方式です。ガードレール型は、ルール違反につながる操作をあらかじめ止めるか、起きたときに検知する仕組みを環境側に適用して統制する方式です。AWSでは、サービスの追加と機能改善が頻繁に行われます。レギュレーション型で細かくルールを設けると管理の負荷が上がりやすいため、AWSはガードレール型をできる限り取り入れることを推奨しています。ただし規制の要件が厳しい領域では、事前に承認を得るレギュレーション型が適している場合もあり、対象の領域によって使い分けます。
執筆とレビューの体制を決める
これまでの内容が固まったら、ガイドラインの文書を作成します。着手する前に、執筆、レビュー、承認をそれぞれ誰が担うかを決めておきます。たとえば執筆はAWS推進部門、レビューはセキュリティ部門や運用部門などの関係部門、承認はAWS推進部門の責任者といった形で分担します。
レビューで何を見るかも、執筆を始める前に関係者で揃えておきます。決めるべきことが未検討のまま残っていないか、書いた内容を実際にAWS上で実装して運用できるかを確認します。必須と推奨と任意の区別が明確か、利用者側に選択の余地がある記載なら選択の基準が示されているかも、あわせてチェックすべき点です。
ガイドライン策定後の運用方法を決める
前段までで、ガイドラインの中身と作り方が決まります。策定したガイドラインは、社内で参照され続けてはじめて機能します。最後に、運用に乗せる方法も策定時に定めます。
最新版を社内ポータルなど参照しやすい場所に置き、質問と要望を受け付ける窓口を周知します。改訂を管理する部門と、見直しの頻度も定めます。AWSのサービス更新や自社の利用システムの変化で内容が古くなるため、定期的な改訂に加えて、随時見直せる形にしておきます。
参照される状態を保つ工夫としては、AWSの利用を始めるシステムの担当者に、利用開始のタイミングで説明の機会を設ける方法があります。システムの設計レビューの手順に、ガイドラインに沿っているかの確認を組み込むことも考えられます。ガイドラインを読む機会を、業務プロセスの中に作る形です。
AWS標準化は記載する範囲と統制の方式の見極めが必要
AWS標準化ガイドラインを策定する際は、目的と適用範囲を先に決め、そのうえで扱う範囲を自社の目的から絞ります。統制の方式は対象の領域によって使い分けます。執筆、レビュー、承認の担当を先に定めておくこと、策定後の運用まで含めて決めておくことも要点です。
進めるうえで見極めが必要になるのは、自社で定めるべき項目を洗い出せるか、項目ごとに何をどこまで書くかの方針を決められるかの2点です。生成AIを業務に使う場面が増えているため、その扱いをどこまで定めるかも検討が必要です。
検討の範囲が広いなど、判断の基準を社内だけで定めにくい場合は、専門家の知見を活用する方法もあります。サーバーワークスのAWS生成AIガイドライン策定サービスではAWS AIコンピテンシー（生成AIカテゴリー）の認定を取得した同社のエンジニアが、項目の洗い出しと記載方針の決定を支援します。すでにあるAWSのガイドラインへ統合する形にも対応しています。
