自治体情シスとして、AWS のネットワークの知識を手っ取り早く覚える方法を考えた時に、私が思いついたのは、AWS 認定試験のAWS Certified Advanced Networking -Specialty (ANS-C01) の勉強をしてみることでした。
ガバメントクラウドに関わっている人で ANS-C01 の勉強をしたことがある人は分かると思うのですが、ANS-C01 の試験範囲にはガバメントクラウドでもよく使われる知識がかなり含まれています。
そこで、ANS-C01 の試験範囲のうち、自治体基幹業務システムにおけるガバメントクラウド利用で使うネットワークの知識をピックアップしてみます。
本記事は ガバメントクラウド Advent Calendar 2025 の 10 日目の投稿となります。
VPC に関する知識
ガバメントクラウドの AWS 環境における自治体基幹業務システムのネットワークは、自治体のオンプレミス環境と VPC が閉域網で接続されており、また複数のベンダーがシステムを構築・保守運用しているため、ベンダー・システムごとに AWS アカウント、VPC が分かれている構成が多いです。
そのため、自治体基幹業務システムのネットワークを構築するためには、オンプレミスや複数のアカウントに跨る VPC と連携するためのネットワーク構成の知識が必要になりますが、ANS-C01 試験ガイドでこれに関連する箇所は以下のとおりです。
- 「タスクステートメント 1.5: オンプレミスネットワークと AWS クラウド間のルーティング戦略と接続アーキテクチャを設計する。」
- 「タスクステートメント 1.6: さまざまな接続パターンをサポートするために、複数の AWS アカウントや AWS リージョン、VPC を含むルーティング戦略と接続アーキテクチャを設計する。」
- 「タスクステートメント 2.1: オンプレミスネットワークと AWS クラウド間にルーティングと接続を実装する。」
- 「タスクステートメント 2.2: さまざまな接続パターンをサポートするために、複数の AWS アカウント、リージョン、VPC にルーティングと接続を実装する。」
- 「タスクステートメント 3.1: AWS とハイブリッドネットワークでルーティングと接続性を維持する。」
このうち、Direct Connect、Transit Gateway、PrivateLink は、自治体基幹業務システムの VPC 間の連携によく使われています。
Direct Connect
ガバメントクラウドには閉域で接続しなければならないため、自治体のオンプレミス環境から AWS 環境への接続は Direct Connect 一択となります。
自治体が自前の専用線を Direct Connect ロケーションまで敷設し、ルーターを持ち込むケースは少ないと思われ、LGWAN Government cloud Connection Service (LGCS) や、通信事業者の CSP 接続サービスを利用して Direct Connect を利用するケースが多いのではないでしょうか。
そのため、Direct Connect を使う手続き的な部分はこういったサービス側で行ってもらえるため、自治体側で気にすべきポイントは以下のものが挙げられます。
- BGP で AWS 環境側にオンプレミスのサブネットへのルート情報を渡す（広告する）
- BGP で冗長構成の優先経路を制御する（プレフィックス長、AS_PATH、Local Preference 属性、BGP コミュティなど）
LGCS の仕様は公開情報がほとんどないので不明ですが、一般に提供されている通信事業者の CSP 接続サービスの中には、通信事業者網に仮想のルーターがあり、仮想ルーターに BGP の設定を行うことで、オンプレミスのルーターから BGP で広告された経路情報が Direct Connect (VIF) へ広告される、といった仕様のものがあると思います。
ポイントになるのは、
- Direct Connect では、BGP でルーティングテーブルを設定する
- VIF や VIF に繋がるまでの仮想ルーターなどの冗長化された経路を選択する場合の優先制御は BGP の属性などで行う
ことかと思います。
Direct Connect Gateway
Direct Connect では VIF と 1 つの VPC の VGW を直接接続することができますが、複数の VPC とそのままでは接続できません。
Direct Connect の VIF と Direct Connect Gateway を接続し、Direct Connect Gateway 経由で VPC と接続すれば、VIF は 最大 20 個の VPC へ接続できるようになるため、Direct Connect Gateway を使うことが推奨されています。
Direct Connect Gateway に VPC 側のサブネットを許可されたプレフィックスとして設定することで、設定されたサブネットの経路情報が BGP でオンプレミス側へ広告されるようになります。
Direct Connect Gateway は複数の VPC を接続できますが、VPC 間の通信はサポートしていませんので、VPC 間を接続するハブのように使えるわけではありません。
Transit Gateway
前述のとおり、自治体の基幹業務システムは複数のシステムベンダーの VPC を連携するケースが多いため、複数の VPC 間の接続に Transit Gateway を採用することが多いです。
Transit Gateway は Direct Connect Gateway では出来ない VPC 間のルーティングをサポートしています。
自治体のオンプレミスから来ている Direct Connect の Transit VIF が接続された Direct Connect Gateway のあるアカウント（ネットワークアカウントと呼ぶことが多いです）に Transit Gateway を設置することで、1 つの VIF で複数の VPC と接続して相互接続することができます。
また、複数のシステムベンダーの VPC を Transit Gateway に接続する際は、マルチアカウント構成となることがほとんどであるため、Transit Gateway を Resource Access Manager で共有する必要があります。
PrivateLink
VPC と Transit Gateway などで直接接続せずに、PrivateLink でサービスだけ別の VPC から接続させる構成もたまにあります。
PrivateLink は別の VPC からエンドポイント経由でのアクセスとなるため、別の VPC やオンプレミスとの CIDR の重複が可能です。
そのため、PrivateLink を採用する構成は、VPC 内のサブネットを自治体オンプレミス側の CIDR に合わせたくないケースが多いのではないかと思います。
Elastic Load Balancer の知識
自治体基幹業務システムでもアプリケーションサーバーの手前に Elastic Load Balancer を置くケースが多いです。
ANS-C01 試験ガイドの中では以下の箇所に Elastic Load Balancer が登場します。
- 「タスクステートメント 1.3: 高可用性、スケーラビリティ、セキュリティ要件を満たすようにロードバランシングを統合するソリューションを設計する。」
- 「タスクステートメント 2.1: オンプレミスネットワークと AWS クラウド間にルーティングと接続を実装する。」
- 「タスクステートメント 4.3: ワークのデータと通信の機密性を実装し、保守する。」
このうち、自治体基幹業務システムで頻出なのは Application Load Balancer と Network Load Balancer の 2 つです。
Application Load Balancer (ALB)
アプリケーション層（レイヤー 7）で動作するロードバランサーです。自治体基幹業務システムでは以下の場面で使われることが多いです。
- HTTPS 通信を終端する（クライアントからサーバーまでの間の暗号化対応）
- 負荷分散とフェイルオーバー（マルチ AZ 冗長化対応）
標準準拠システムの非機能要件仕様で、ガバメントクラウドとの間の通信は暗号化が要件となっており、これを満たすためにクライアントから ALB 間の通信は TLS で暗号化し、クライアントから HTTPS で接続させるために使われています。
また、ALB には負荷分散だけでなくターゲットのヘルスチェック機能があり、これにより例えばマルチ AZ に配置したアプリケーションサーバーをフェイルオーバーすることができます。
注意点は、ALB の IP アドレスが固定ではなく時間と共に変更されることです。ALB で HTTPS を終端させたいが IP アドレスを固定させたい場合は、Network Load Balancer (NLB) を併用する必要があります。
Network Load Balancer (NLB)
トランスポート層（レイヤー 4）で動作するロードバランサーです。ALB と違い NLB は IP アドレスを固定することができます。
そのため、クライアントからの接続先 IP アドレスを固定したいときは、ALB の前段に NLB を配置することで実現できます。
また、PrivateLink で他の VPC にサービスエンドポイントを公開したい時にも NLB を使うことがあります。
Route 53 の知識
自治体基幹業務システムでも、AWS 環境での名前解決には Route 53 が使われます。特に自治体のオンプレミス環境と AWS 環境とのハイブリッドな名前解決をできるようにするケースが多いです。
ANS-C01 試験では以下の箇所で Route 53 が登場します。
- 「タスクステートメント 1.2: パブリック、プライベート、ハイブリッドの要件を満たす DNS ソリューションを設計する。」
- 「タスクステートメント 2.1: オンプレミスネットワークと AWS クラウド間にルーティングと接続を実装する。」
- 「タスクステートメント 2.2: さまざまな接続パターンをサポートするために、複数の AWS アカウント、リージョン、VPC にルーティングと接続を実装する。」
- 「タスクステートメント 2.3: 複雑なハイブリッドおよびマルチアカウント DNS アーキテクチャを実装する。」
- 「タスクステートメント 3.3: AWS ネットワークを最適化して、パフォーマンス、信頼性、費用対効果を高める。」
Route 53 は、通常の名前解決だけでなく、名前解決を使った冗長化（DNS フェールオーバー）にも使われることがあります。
また、自治体オンプレミスの DNS リゾルバーとの連携や、別アカウントとのホストゾーンの共有などは、自治体基幹業務システムでも使われる場面が非常に多いです。
Route 53 Private Hosted Zone
Route 53 Private Hosted Zone は、プライベートに閉じた環境のホストの DNS 名を登録することで、プライベート環境内で名前解決させることができます。
VPC のホストをクライアントからプライベートなドメインで名前解決させるのに使われます。
別のアカウントの VPC に Route 53 Private Hosted Zone を関連付ける場面は多く、特にネットワークアカウントの集約用 VPC に VPC エンドポイントを集約する構成では、集約用 VPC に別アカウントから Route 53 Private Hosted Zone を関連付けるケースは多いと思います。
Route 53 Resolver エンドポイント
Route 53 インバウンド / アウトバウンドエンドポイントは、オンプレミスや他の VPC と DNS を連携するときによく使います。
自治体基幹情報システムでは、自治体のオンプレミスの DNS サーバーと Route 53 インバウンドエンドポイントを連携し、オンプレミスから AWS 環境の名前解決をするのに使われています。
AWS 環境から庁内オンプレミス側の名前解決をしたい場合は、Route 53 アウトバウンドエンドポイントと、DNS フォワーダールール（オンプレミス側のドメインに対する条件付きフォワーダー設定）を使います。
逆にガバメントクラウド（地方自治体）であまり見かけない知識
地方自治体のガバメントクラウド利用は主に基幹業務システムがほとんどで、インターネットに公開するシステムでは使われていない（一部都道府県のセキュリティクラウドで使われているような例外あり）ことから、主にグローバルに展開するためのサービスは見かけることがあまりありません。
具体的には CloudFront や Global Accelerator、AWS Shield といったインターネットとの接点で使われるものや、インターネット接続が必要な Site-To-Site VPN やパブリック VIF、ネットワーク規模的に使われない SD-WAN などです。（国のガバメントクラウド環境では使われているのだと思います）
自治体情シスが ANS-C01 試験を受けるとしたら、これらのサービスはイメージが湧きづらいので辛いかもしれません。
試験合格を目指さなくても試験対策テキストを読むことは勉強になる
ANS-C01 の試験範囲に地方自治体のガバメントクラウドで使うネットワークの知識がたくさん含まれていることは分かりましたが、実際に試験を受けて合格を目指すのはかなり大変だと思います。受験料もかなり高額（300 USD）なので……。
おすすめなのは、ANS-C01 の試験対策テキストを一通り読むことです。試験対策テキストは体系的に試験範囲の内容がまとめられているので、パラパラめくりながら、気になる項目があれば AWS Black Belt セミナーの資料や動画を見る、構築例を書いたブログなどを読む、といった深掘りをするといいと思います。できれば AWS 公式のドキュメントの該当箇所を読むこともおすすめです。
ネットワークの基礎知識も必要
パブリッククラウドでもオンプレミスでも、ルーティングや名前解決、暗号化通信、アプリケーションレイヤーのプロトコル、ファイアウォールといったネットワークの基礎知識が求められる場面は多々あります。
AWS のネットワークを学ぶには、併せてネットワークの基礎知識もしっかり学ばないと、自治体基幹業務システムのようにオンプレミスと AWS をハイブリッドに接続するネットワークを理解することは難しいと思います。
ネットワークの基礎知識がしっかりしていれば、あとは AWS でそれをどう実現するのか、AWS ならではの機能は何なのか、理解が早いと思います。