LGCS接続パラメータ設定の躓きポイントを考えてみた（AWSのみ）
１ はじめに
先日、ある自治体の方からLGCS接続パラメータシートの提出について相談を受けました。
ご存じの通り、名古屋市はガバメントクラウド接続回線は独自に専用回線を調達しているため、蚊帳の外の話ではありますが、興味本位で実際のパラメータシートを見てみると、一般的な自治体職員が正確に記入するのは非常に厳しい気がしました。
そのため、筆者が考える躓きポイントについて記載していこうと思います。
なお筆者はAWSしか分からないのでAWSについてのみ記載します(´・ω・｀)
１（１）【躓きポイント】回線より先にネットワーク運用管理補助者とガバクラアカウントが必要
パラメータシートの中身に入る前に幾つか注意点があります。
まず、回線を引き込むにはガバメントクラウドのアカウント（いわゆるネットワークアカウント）が必要になります。デリバリーパートナーとなるLGCSの事業者がダイレクトコネクトを提供する際、どのAWSアカウントに対してコネクションを払い出すかを設定する必要があるためです。
ガバメントクラウドのアカウントについては、令和６年度は早期移行検証事業と窓口DXSaaSでのみ発行されます。基本は前者だと思いますので、事業計画書の作成と提出が必要になります。
事業計画書には全体構成図やカリキュレーターが必要ですし、いずれにせよ職員のみでLGCSのパラメータシートを全部正確に埋めるのは困難なので、事前にネットワーク運用管理補助者を調達し、その上で早期移行検証事業の事業計画書を作成してデジタル庁に提出し、アカウントの発行を受けるのが良いと思います。
ネットワーク運用管理補助者（各標準準拠システム環境とのネットワーク接続を確保する運用管理補助者）については、筆者の過去の記事も参考にしてください。
１（２）【躓きポイント】ネットワーク運用管理補助者だけでの早期移行検証事業申請は出来ない
ネットワークアカウントを払い出してもらうには、ネットワーク運用管理補助者を調達して早期移行検証事業の申請をする必要がありますが、ネットワーク運用管理補助者のみ、言い換えればネットワークアカウントのみでの申請は出来ません。
なぜならば、早期移行検証事業は標準準拠システムの移行にかかるデジタル庁の検証事業だからです。
標準準拠システムの事業者から、先に回線だけ繋いでおいて欲しいと言われる自治体が数多く見受けられますが、そのためには最低１システムは標準準拠システムを含めて申請する必要がありますので、要注意です。
２ 接続構成情報シート
２（１）【躓きポイント】東京リージョンと大阪リージョン、両方使う場合でも接続数は１で良い
LGWAN本体の内容は割愛して、一番下のガバメントクラウド接続の部分です。「接続数」「リージョン」「接続サービスプラン」を選択するようになっています。簡単なようですが、正確に選択するにはクラウドアーキテクチャへの理解が必要です。
まず接続数は１、リージョンは東京を選択してください。
東京経路は東京リージョン、大阪経路は大阪リージョンというように誤読するような案内文が書いてありますが、AWSはグローバルサービスであり、どの接続ロケーションからでも（ガバクラでの国内限定制限はさておき）世界中のあらゆるリージョンにアクセス可能です。
東京ロケーションで接続して大阪リージョンへアクセスしたり、大阪ロケーションで接続して東京リージョンにアクセスしたりできるのはもちろん、ブラジルのリオデジャネイロロケーションで接続して大阪リージョンにアクセスしたり、アメリカペンシルベニア州のフィラデルフィアロケーションで接続して東京リージョンにアクセスするのも可能です。
言い換えれば、「接続数：１」「リージョン：東京」「接続サービスプラン：東京のみ（東京ロケーションに接続）」で問題なく大阪リージョンが利用できます。図示すると以下のようになります。
リージョンの欄が各接続ごとに東京と大阪しか選べませんので、両リージョン使う場合は接続を２にしてそれぞれ東京リージョンと大阪リージョンを選択したくなりますが、これは間違いです。料金２倍かかります。孔明の罠です。
これAWSのクラウドネットワークの知識ないと、絶対分からないですよね(´・ω・｀)
じゃあ「接続サービスプラン」の「東京＆大阪」は何ぞやって話ですけど、主に大規模災害対策を踏まえた高い稼働率確保のため、途中経路を冗長化する場合に選択するメニューになります。当然料金も２倍です。
名古屋市はほぼこれと同じ構成を取っています。参考までに、前者（東京のみ）のSLAは99.9%、後者（東京＆大阪）のSLAは99.99%です
この接続構成の選択は、純粋に自治体の判断（非機能要件）によります。名古屋市はちょうど東京と大阪の中間地点にあるので、両経路の確保は大規模災害対策として非常に効果的です。しかし東北、北海道、四国や九州の場合、そうとも限りません。両方の経路が例えば太平洋側と日本海側で異なるルートであれば良いのですが、途中まで両経路が同じルートを辿るのであれば、SLAの確保以上の意味は無いことになります。
判断が難しいですね。
３ AWSパラメータ情報
３（１）1.クラウド接続ルータ～AWS間ネットワークの1-1～1-6は適当で良い（多分）
1-1～1-6は経路上ルータ等の各ノードのIPアドレス設定です。
自治体がアクセスして何かするわけではありませんので、庁内プライベートIPに重複しないものを適当に割り当てれば良いと思います。迷ったらネットワーク運用管理補助者に投げちゃいましょう。
名古屋市はクラスAのプライベートIPで運用していますが、この経路上のノードについてはクラスA外のアドレス（言い換えれば絶対重複しないアドレス）を適当に割り振っています。
３（２）1-7 BGP認証キーも適当で良い（多分）
要するにBGP認証のパスワードをMD5でハッシュ化してキーにするよってことなので、こちらも適当で良いと思います。迷ったらネットワーク運用管理補助者に投げましょう。
普通ユーザーが設定するようなものじゃない気がしますがね(´・ω・｀)
３（３）【躓きポイント】2-1/2-4 接続種別（VIF）の選択は慎重に！
LGCSが提供するヴァーチャルインターフェースの種類をTransit VIFとPrivate VIFから選択する項目ですが、非常に重要な選択です。
違いをここで説明すると、それだけで一本の記事が書けてしまうので、割愛しますが、以下の２点だけ理解してください。。
まず、この選択により、ゲートウェイ以降のアーキテクチャが大きく変わります。ガバメントクラウド推奨構成で言えば、旧版がTransit VIFの構成で、新版が Private VIFの構成です。
そして、一度決めたら容易には変更できません。LGCS側の変更自体は可能ですが、変更されたヴァーチャルインターフェースに対応するためのアーキテクチャの構成変更が必要になります。そしてネットワーク運用管理補助者のみならず、標準準拠システムの事業者の作業も発生します。
これは職員が勝手に決めず、ネットワーク運用管理補助者が各標準準拠システムの事業者としっかり調整したうえで将来性も踏まえて決定した方が良い事項です。
どうしても職員が判断・選択しなければならない場合は、Transit VIFを選択してください。こちらはまだリカバリが効きます。
３（４）2-3/2-6 接続ポイントはどこでも良い
TY2がエクイニクス、CC2がアット東京です。両方使うので、どちらをプライマリにしても問題ありません。
３（５）【躓きポイント】3-1 AWSアカウントはネットワーク運用管理補助者が扱うネットワークアカウントのものを記入
１（１）でも記載しましたが、AWSのアカウントIDは自動付番であり、事前設計が不可能です。あらかじめネットワーク運用管理補助者を調達し、早期移行検証事業に申し込みを行い、GCASでCSPアカウントの発行申請を行い、発行後にネットワーク運用管理補助者からアカウントIDを教えてもらう流れです。なお、ネットワークアカウントは単独利用方式のケースが多いと思いますので、頑張れば職員でも確認可能です。
記入要領に「共同利用方式の場合の注意事項」とありますが、これは標準準拠システムの共同利用ではなく、ネットワークアカウントが共同利用の場合です。このケースはほぼ無い（共同調達はあり得ても、ネットワークアカウントを共同利用するメリットはほとんどない）と思われます。間違えて共同利用の標準準拠システムのアカウントIDを記載することが無いように注意ください。
３（６）【躓きポイント】3-2 ASNはVGWではなくDXGWのものを記入
他のCSPと異なり、AWSはユーザー側がASNを指定範囲から設定することが可能です。ASNはBGPネットワーク経路におけるIPアドレスのようなもので、重複せず一貫した設計がされていれば問題ありません。パラメータシート記載の標準指定値でも問題ありませんが、他のリソース（Transit GatewayやVGW）のASNをネットワーク運用管理補助者が設計すること考えれば、併せてお任せするのが良いでしょう。
なお、パラメータシートの図ではVGWの所に「3-2」とありますが、これは誤りです。VGWではなくDXGWのASを記入してください。
BGPセッションにおいてはVGWのASNではなくDXGWのASNが Amazon側 ASNとして採用されますので、VGWのASNはここで聞く必要の無い内容です。そもそもTransit VIFの場合はVGWは登場しませんしね。
３（７）【躓きポイント】3-3 ネットワークアドレスはVPCではなくガバクラAWS全体を
VPCのアドレスをカンマ区切りで全て記載するような指示がされていますが、小間切れのアドレスを羅列するのではなく、今後の拡張性も踏まえ、自団体のプライベートネットワーク空間においてガバクラAWSを割り当てる大きなCIDR範囲を記載してください。
オンプレミスネットワークの状況や将来展望も踏まえた設計が必要となりますので、実際に当面利用するVPCのCIDRを各標準準拠システムの事業者と調整して決めた上で、ネットワーク運用管理補助者に決めてもらうのが良いでしょう。
ちなみに名古屋市のプライベートネットワークはクラスＡであり、そのうち /16×5をガバクラに割り当てています。
※ 【6月9日追記】この部分の記載について、齋籐和明さんから「地情機3561別冊p37及びp38「IPアドレスの申請」によりますと、LGWANルータがガバクラ上VPCのNW情報を学習するので、構築時点で正しく伝搬しているか確認したいという趣旨」とのコメントをいただきました。ありがとうございます。この件に関しての筆者の見解もコメント欄に追記しています。
ただ筆者はどこまでいっても門外漢で、他の団体の申請内容に責任を持てるわけでもないので、心配であればJ-LISさんに直接確認いただくのが良いと思います。
３（８）東京＆大阪プランを利用する場合の大阪経路の記載内容
1-1～1-6は東京経路とは別のIPアドレス範囲を割り当ててください。
1-7はお好みで。セキュリティ強度を考えれば東京経路とは別のものを設定した方が良いでしょう。
2-1/2-4 接続種別（VIF）は東京経路と同じものを選択してください。
2-3/2-6 どちらもエクイニクスです。どちらでも良いです。
3-1～3-2 アカウントID、DXGW、ネットワーク空間は共通ですので、東京経路と同じものを記入してください。
４ 最後に
LGCSのパラメータシート記載について説明してきましたが、随所にクラウドネットワーク構築の知識が必要であり、職員のみの対応ではハードルが高いことが理解していただけたかと思います。
是非事前に信頼できるネットワーク運用管理補助者を調達して対応してもらってください。
スケジュール的な課題が出てきた場合はリスケも視野に入れた方が良いと思います。標準準拠システムが単独利用方式ならともかく、共同利用方式の場合は事業者が環境にアクセスする手段を既に別に持っており、回線を接続しなくても構築を先に進めることが可能です。（回線接続はデータ移行の際に必須になります）
この記事が気に入ったらサポートをしてみませんか？