地方公共団体情報システムの標準化に関連して、ガバメントクラウドへの移行が本格的になってきています。
自治体はオンプレミスの庁舎やデータセンターから CSP 環境へ接続して、ベンダーとの調整も多く発生していると思いますが、パブリッククラウドはオンプレミスとは異なる調整が求められるし、分からないことも多く、困っている自治体職員も多いはずです。
そこで、AWS の話に限定されますが、ガバメントクラウドに環境の構築でベンダーと調整していくに当たり、持っておくと役に立つのではないかと自分が思った AWS のネットワークやガバナンスなどの知識について、デジタル庁の GCAS ガイド という公式ドキュメントで公表されている範囲でピックアップして解説してみます。
なお、ここでは地方公共団体（自治体）におけるガバメントクラウドの利用の話となり、国などのシステムはスコープ外としています。
事前知識
この後頻出する GCAS（ｼﾞｰｷｬｽ）とは、「オンボーディングツールとしてガバメントクラウドの情報提供、問合わせ対応、利用申請、利用案内等を行うWebサービスのこと1」ですが、ガバメントクラウドの AWS 環境との関係ではシングルサインオンの認証基盤でもあることがとても重要です。
ちなみに GCAS は Google Cloud に構築されています。2
ガバナンス編
自治体が使う AWS アカウントは Organizations のメンバーアカウントである
GCAS ガイドのとおり、自治体が使うガバメントクラウドの AWS の利用者環境は、デジタル庁が管理する Organizations から払い出される OU に紐付くメンバーアカウントとなります。また、SCP (Security Control Policy) でセキュリティに違反する操作を行えないよう制限がかけられています。
Organizations の概念はとても重要で、GCAS アカウントで自治体 AWS アカウントにシングルサインオンできるのも、ガードレールにより Security Hub など共通的なセキュリティが有効になるのも、Organizations の機能がベースとなっています。
自治体が使う AWS アカウントは IAM Identity Center で一元管理されている
ガバメントクラウドでは、自治体 AWS アカウントのルートユーザーや作成した IAM ユーザーは使用できません。その代わりデジタル庁の Organizations 管理アカウントにある IAM Identity Center で一元管理されたユーザーで自治体 AWS アカウントの IAM ロールへアクセスできるようになっています。
IAM Identity Center は GCAS の IdP と連携しており、自治体や運用管理補助者は自身に払い出されている GCAS アカウントで IAM Identity Center へシングルサインオンするようになっています。
そのため、自治体や運用管理補助者にとっては、ガバメントクラウドに関する申請や問い合わせなどに使う GCAS アカウント一つで AWS アカウントの管理もできるため、とても効率的と言えます。
また、何らかのリソースにアクセスする際、IAM ユーザーを作成してアクセスキーを使うよりも、IAM Identity Center の認証で都度一時的なクレデンシャルを取得する方がセキュリティ上望ましいとされているため、IAM ユーザーを禁止して IAM Identity Center の使用を強制することは、セキュリティ対策として合理的と言えそうです。
Organizations と IAM Identity Center による AWS アカウント管理
AWS アカウントの管理について、Organizations でマルチアカウントを管理すること、外部 IdP と IAM Identity Center を連携してシングルサインオンすることは、ベストプラクティスに沿っていると言えるので、もし検証用に個人で AWS アカウントを持つ際もぜひ初手からこれらを構築することがお勧めです。
実際にやってみた記事を書いていますので、良ければ参考にしてください。
ネットワーク編
自治体の庁舎またはデータセンターから AWS 環境へ接続するには、基本的に一つの（冗長化された）Direct Connect で接続します。一方、ガバメントクラウドへ移行するシステムは 20 業務あるため、オールインワンパッケージの場合などを除き、この一つの Direct Connect に複数の VPC を繋ぐことになります。
そのため、Direct Connect から Direct Connect Gateway (DXGW) に繋ぎ、VPC が少ない場合以外は DXGW を Transit Gateway へ繋ぐ構成が多いと思います。簡略化した図にすると以下のようになるのではないでしょうか。
それでは、このような構成を構築する際にポイントとなると思った部分を解説していきます。
マルチアカウントで Transit Gateway を共有して相互接続
ここで、Transit Gateway を自治体のネットワークアカウントに持たせ、事業者の ASP アカウントを Transit Gateway に繋ぐ場合を考えます。
この場合、アカウントを跨いで Transit Gateway を共有しなければなりません。
具体的には、最初に Resource Access Manager でネットワークアカウントの Transit Gateway を ASP アカウントに共有し、共有された ASP アカウントから Transit Gateway アタッチメントを作成し、最後にネットワークアカウントでこの Transit Gateway アタッチメントを承認する、という手順を踏む必要があります。
このように相互の作業がネットワークアカウントと ASP アカウントの運用管理補助者が異なるベンダーの場合、自治体職員が間に入って調整する必要があるかもしれません。
実際にマルチアカウントの間で VPC を Transit Gateway で接続する手順を検証したので、良かったら参考にしてください。
この時、Transit Gateway ルートテーブルを VPC ごとに分離するといいかもしれません。その手順を検証したものもあります。
オンプレの DNS と Route 53 インバウンドエンドポイントを連携してマルチアカウントのプライベートホストゾーンもまとめて名前解決
AWS 環境の名前解決を庁内のオンプレミスからできるようにすることは重要です。VPC で使うドメインを庁内オンプレミスで使っているドメインと別（サブドメインにするなど）とし、VPC 側は Route 53 プライベートホストゾーンを使うのが良いと思います。
また、ネットワークアカウントの VPC に庁内のオンプレミスにある DNS サーバーから参照が可能な Route 53 インバウンドエンドポイントを作成するのがお勧めです。
庁内オンプレミスのクライアントが参照するリゾルバー DNS サーバーに、VPC 側のドメインへの名前解決要求を、VPC にある Route 53 インバウンドエンドポイントへ転送する条件付きフォワーダーを設定することで、庁内オンプレミスと VPC との間で一体的に名前解決が管理できるようになります。
また、マルチアカウントで複数の VPC の Route 53 プライベートホストゾーンの名前解決を、庁内オンプレミスからさせたい場合も、Route 53 インバウンドエンドポイントのある VPC に別アカウントの Route 53 プライベートホストゾーンを関連付けることで実現できます。
ただし、別アカウントの VPC に Route 53 プライベートホストゾーンを関連付けるためには、双方のアカウントで AWS CLI などから関連付けの依頼・承認の作業が必要なので、実施に当たっては運用管理補助者と調整が必要です。
他にも、別アカウントの VPC の DHCP オプションセットを変更し、DNS 参照先をネットワークアカウントの Route 53 インバウンドエンドポイントに向かせることで、ネットワークアカウントで作成したインターフェース型の VPC エンドポイントを共有することができ、エンドポイントの数を節約することができます。
具体的な手順や、ここでは触れなかった Route 53 アウトバウンドエンドポイントの使い方など、検証した記事がありますので良かったら参考にしてください。
また、つい先日、Route 53 リゾルバーが DNS の委任に対応したため、庁内オンプレミスで使っているドメインのサブドメインを VPC で使いたいが、権威 DNS サーバーが李ゾルバー DNS サーバーを兼ねており条件付きフォワーダーができなかったケースの場合、委任を使えば解決できると思います。
Transfer Family で SFTP サーバーを立ててオンプレや他 CSP と S3 バケットのファイルを共有する
地方公共団体情報システムの標準化における標準準拠システム間でファイル連携をする場合、認証認可をした上で通信を暗号化しなければなりません。
AWS 環境同士で S3 を介してこれを行うことは比較的容易ですが、閉域網にあるオンプレミスや他 CSP から S3 に連携する場合、IAM ユーザーのアクセスキーを使えない制約もあり、認証認可サーバーを個別に立てるなど実装の難易度が高くなります。
そこで、AWS のマネージドサービスで完結し、上記の要件を満たすことを考える時、Transfer Family で SFTP サーバーを立てて S3 バケットと連携するのが簡単です。
AWS のマネージドサービス外で SFTP に使うキーペアを別途管理する必要があることに注意です。キーペアを誰が作成し、鍵ファイルの受け渡し方法をどうするか、事前に運用管理補助者と調整しておくと良いです。
Transfer Family で S3 に SFTP で連携する方法を検証した記事はこちらです。
こちらは参考ですが、Systems Manager Agent をオンプレミス側にインストールして、一時的なクレデンシャルを取得してオンプレミスから S3 にアクセスする方法も検証してますので、良かったら参考にしてください。
コスト管理編
AWS 利用料の内訳を確認するために Data Exports で CUR 2.0 を出力する
ガバメントクラウド利用料について、内訳ごとに単価と数量を確認したい場合、Billing and Cost Management から請求書の PDF を出力するか、Data Exports で CUR を出力する方法があります。
Data Exports は、出力先の S3 バケットを設定すれば、マネージメントコンソールから設定することで定期的に CUR を CSV などのデータ形式で出力し、ダウンロードできるようになります。
Data Exports で CUR 2.0 を毎月出力する設定は、次の記事で検証しています。
EC2 に Savings Plans を適用して長期継続割引を受ける
ガバメントクラウドでも AWS のリザーブドインスタンスや Savings Plans といった長期継続割引が使えますが、一部制限があるため注意です。
仕組みがとても複雑で難しいのですが、公共分野のクラウド利用に関する JAWS-UG 支部である Gov-JAWS の第 1 回の中で分かりやすくまとめて発表されていた方がいたので紹介します。
Gov-JAWS のような公共に特化したユーザーグループで一緒に学ぶのは有効だと思います。
このほか、私も EC2 に Savings Plans を購入する手順を検証していますので良かったら参考にしてください。
おわりに
以上、雑多ですが、私の検証した範囲を中心に、今自治体がガバメントクラウドへ移行するに当たり持っておくといいかもしれないポイントでした。
中々実際に AWS へ環境を作って試すのはハードルが高いかもしれませんが、手を動かすことで理解が深まることもあります。
ただし、上記の検証記事の中には放っておくと高額な課金が発生するものもあるので、実際に検証するときは、検証が終わったら速やかに停止するなど、細心の注意を払うようにしましょう。