概要
下記JAWS-UG栃木で登壇させていただいた内容です。
ガバメントクラウドの内容や公共領域での制約条件下でのAWS・生成AI活用などについてお話しさせていただきました。
ガバメントクラウドの概要
ガバメントクラウドはデジタル庁が整備する政府共通のクラウド基盤です。国の行政機関や地方公共団体などで利用されています。CSPとしてはAWS、Azure、OCI、Google Cloud、さくらのクラウドの5つが選定されており、各CSP上に業務システムが構築されます。
ガバメントクラウドの特徴①
ガバメントクラウドの技術的な特徴の一つにアカウント構成があります。自治体側でAWSを利用する場合はデジタル庁が管理するAWS Organizationsの子アカウントを利用します。そのため、自治体側アカウントではAWS Organizationsの機能を利用できないという制約があります。
ガバメントクラウドの特徴②
自治体でガバメントクラウドを使用する際のネットワーク構成の特徴として、閉域ネットワーク・ハイブリッド構成・マルチベンダーが挙げられます。また、各アカウントは管理主体が異なる場合もあり、調整や全体最適が難しい理由の一つにもなっています。
ガバメントクラウドの特徴③
セキュリティ面では、AWS BLEA（Baseline Environment on AWS）をベースにしたセキュリティテンプレートを適用する必要があります。図はテンプレートのイメージで、ガバメントクラウドアカウント内での監視・通知の流れを示しています。
AWS Organizationsの機能を使用せずに集約管理
先述の通り自治体側アカウントではAWS Organizationsの機能が使えないため、セキュリティの集約管理には工夫が必要です。例として、Security Hubでは委任管理者ではなく「招待」を利用して集約しています。
制約事項が多い環境
ここまで見てきたように、ガバメントクラウドは通常のAWS利用と比べて制約事項が多い環境です。Organizations機能が使えない、閉域ネットワーク構成、マルチベンダー運用など、さまざまな制約の中で設計・運用を行う必要があります。
生成AI利用も制約事項が多い環境
そしてこの制約はインフラ面だけでなく、生成AIの利用においても同様です。ガバメントクラウド上で生成AIを使おうとすると、追加の制約事項に直面します。
ガバメントクラウド上で生成AIを利用するには
ガバメントクラウド上で生成AIを利用するためには、以下の3つの視点で考える必要があります。特に③が大きなハードルでしたが、最近になって一部モデルが利用可能になりました。
これまでのガバメントクラウドでのAmazon Bedrockの利用方法
これまでガバメントクラウド上でAmazon Bedrockを利用するには、ガバメントクラウド外のアカウントを用意してクロスアカウントアクセスを行う方法が取られていました。ガバメントクラウド内で直接Bedrockが使えなかったため、外部アカウントを経由する必要があったわけです。
そのため、公共関連の構成図だと下記の通りBedrockのアカウントが分かれていることが多いと思います。
今後すぐに使っていきたいAI関連サービス
現在、生成AI関連で業務に直ぐに取り入れたいことは運用改善関連での使用です。今後すぐに使っていきたいAI関連サービスとして、以下の2つを挙げています。ガバメントクラウドの利用は運用フェーズに入ってきていたため、DevOps AgentやFinOps Agentを取り入れて、運用面の強化を行っていきたいと思います。
以前分析ツールを自分で作成
以前CloudTrailログの分析ツールを自前で作成しました。左側がUIで、検索期間（開始・終了）と検索キーワードを入力してログ分析を実行する画面です。右側は分析結果の「要約後」の出力例です。
DevOps Agentで簡単に出来るように
上記のような分析が、AWS DevOps Agentを使えば簡単にできるようになりました。
制約事項が多い環境 → 設計しがいがある
制約を理解し、その中でベストな設計を考えること自体がエンジニアとしての面白さにつながります。
資料