トップ > ガバメントクラウド > LGWAN経由でガバメントクラウドAWSへ接続する際のパラメーター回答

LGWAN経由でガバメントクラウドAWSへ接続する際のパラメーター回答

ガバメントクラウド
記事タイトルとURLをコピーする

こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。

ガバメントクラウドへの移行において必ず必要となるのが、オンプレミスとクラウド間の専用線接続になります。

地方⾃治体の基幹業務システムの統⼀・標準化に関し「LGWANについては、地⽅公共団体の庁内システムからガバメントクラウドへの当⾯の接続回線として利⽤可能となるよう更改する」との方針が閣議決定されております*1。

本BLOG執筆時点(2024年6月中旬)では、LGWANをガバメントクラウドへの専用線接続に利用される地方自治体様向けに、パラメーター等のヒアリングが開始されているようでした。その回答のために抑えておきたいAWSの用語や回答例について、本BLOGにてご紹介させていただきます。

想定されるLGWAN経由での接続の構成図

各所で拝見する情報などをみると、おそらくこのような構成図になるのではと考えられます。今後情報の公開などの進展あればアップデートしたいと思います。

AWS側の接続部分としては Direct Connect 仮想インターフェース (以下VIFと表記)、Direct Connect Gateway、Transit Gateway といったAWSサービスで構成されており、一般的にAWSで構築するときのヒアリングや設計ポイントは同じと考えられます。ガバメントクラウドやLGWANの固有の要素は特段無さそうです。

LGWAN経由でAWSへ接続する際のヒアリング項目（想定）

LGWAN経由でAWSへ接続する際に想定されるパラメーターヒアリングへの回答について、自分なりの考察をご紹介いたします。AWS側の接続部分のみを記載しておりますので、実際には加えてオンプレミス側の接続部分や地方自治体様の既存ネットワークに関するヒアリングがある可能性があります。ご了承ください。

Direct Connect 仮想インターフェース の Transit VIF または Private VIFの指定

Direct Connect 仮想インターフェース (VIF) には数種類方式があります。ヒアリングが想定されるのが「Transit VIF または Private VIF どちらにしますか？」という問いになります。どちらを選ぶかについては重要でありますが、決定は簡単にできます。

  • Transit Gateway を利用する（予定含む） → Transit VIF
  • Transit Gateway を利用しない → Private VIF

Transit Gateway の利用が明確であれば VIF の指定もそれに従います。難しいのが、地方自治体様側で Transit Gateway の利用方針が決まっていない場合です。「ガバメントクラウド利用における推奨構成（AWS編）」*2 においても Transit Gateway を利用するパターン、しないパターン両方が書かれており、地方自治体様毎で判断する必要があります。Transit Gateway は利用するメリットが沢山ありますが、AWS利用料が追加されることや、運用管理においてネットワークの知識が求められることがデメリットとしてあります。おおまかですが下記の場合は Transit Gateway を利用する、つまり Transit VIF を選ぶのがよろしいかと思います。

  1. 運用管理補助者（保守ベンダー）が複数存在
  2. ガバメントクラウド単独利用方式、ガバメントクラウド共同利用方式を組み合わせて利用

AWSアカウントID

AWSアカウント とは、クラウド利用料の請求支払いの単位、また管理コンソールへの認証およびアクセス許可を制御する単位となります。AWSアカウントには一意の12桁数字のID（例：1234-5678-9012）が付与されており、これをAWSアカウントIDと呼びます。

AWSアカウントIDはデジタル庁よりAWSアカウントが払い出しされた際にも通知されます。また実際の管理コンソール（AWSマネジメントコンソール）からも確認して知ることができます。ヒアリングに対する回答も容易かと思われます。

ただし、AWSアカウントを用途・環境・権限の分離のため、地方自治体様においては複数AWSアカウントが存在する「AWSマルチアカウント構成」が一般的かと思われます。この場合は、下記のAWSアカウントIDを回答します。

  • Direct Connect Gateway を作成した（予定含む）AWSアカウントID

Direct Connect Gateway や Transit Gateway など、複数のアプリケーションで共同利用するネットワーク集約関係のAWSサービスについては「ネットワーク管理アカウント」や「ネットワーク集約アカウント」という区分けで専用のAWSアカウントを作成し、ネットワーク構築および保守を専門に担う「ネットワーク運用管理補助者」のベンダー様が運用保守を担う構成が多いかと思われます。

Connecting Point

Connecting Point とは AWS とオンプレミス間を専用のネットワークで接続する Direct Connect の接続部分のことを指します。AWS においては AWS Direct Connect ロケーション とも呼ばれ、2024年6月の時点では日本国内では「東京ロケーション」「大阪ロケーション」を選ぶことができます。

ややこしいのですが、AWSリージョンとAWS Direct Connect ロケーションは異なる概念であり、AWS Direct Connect ロケーションに「大阪ロケーション」を選択しても、AWS東京リージョンのVPCやAWSリソースに接続することが出来ます。利用する（予定含む）AWSリージョンが決まっていれば 同じ Connecting Point を選択すればよいです。AWSリージョンと異なる Connecting Point を選んでも接続は可能ですが、東京ー大阪間の迂回によって若干の遅延が起こるとされています。

また、目標稼働率を高く設定される場合は、Connecting Point に「東京ロケーション」と「大阪ロケーション」の両方を選択することをお勧めします。AWSとしての SLA は下記のサイトに掲載されております。最も高い SLA 99.99% にするためには2つ以上の AWS Direct Connect ロケーション を選択して、それぞれのロケーションにおいても接続を2つ以上にすることが求められます。

aws.amazon.com

BGP接続に関する設定情報

Direct Connect においては、オンプレミスとAWS間において BGP を用いてルーティング情報(経路情報)を動的交換することが仕様となっています。細かい説明は割愛しますが、BGP においてはネットワーク機器間でBGPセッションを構築するにあたり、「ASN(AS番号)」「ピアIP」「BGP認証キー(MD5キーとも呼ぶ)」というパラメーターを双方で設定する必要があり、Direct Connect を利用するLGWAN経由の接続においてもこれらパラメーターのヒアリングがあると想定されます。

ASN

BGPにおいてはASN（自律システム番号 - AS番号とも呼ぶ）という値をネットワーク機器毎に設定します。ASNは1～65534といった数字となります。AWSにおいてもオンプレミス側とAWS側とで一意のASNを設定する必要があります。AWS側では一部のAWSリソースを作成する際にASNの設定を行いますので、この値のヒアリングがあると想定されます。AWS側でASNを設定する箇所は下記になります。うち Virtual Private Gateway (以下VGWと記) でもASNを設定はできますが Direct Connect の利用においては影響しませんので無視します。

  • Direct Connect Gateway 用に1つのASN
  • Transit Gateway 用に各リージョンのASN (例：東京リージョンと大阪リージョンを併用の場合は2つのASN)
  • 各VPCの VGW のASN (Direct Connect と Transit Gateway 構成の場合は利用しない)

昨今のAWSの設計・構築においては Direct Connect Gateway をAWS側の接続部分とする構成が一般的です。ヒアリングへの回答としては Direct Connect Gateway に設定した（設定予定の）ASNを回答すればよいです。

  • 例) Direct Connect Gateway に設定したASN 64512

ピアIP

BGP においてのネットワーク機器間のセッションに利用されるIPアドレスになります。こちらはオンプレミス側とAWS側とのいずれのプライベートネットワークとも競合しないIPアドレスであればよいです。AWSの自動割り当てを用いる場合は 169.254.0.0/16 の範囲内から自動採番される*3とあるので、特段こだわりが無ければ例えば下記のようなIPアドレスを回答すればよいと思われます。169.254.0.0/16 はRFC 3927 で Link-Local Addresses として定義されたIPアドレス帯になります。*4

  • 例1) ルーターのピア IP：169.254.0.1/30、Amazon ルーターのピア IP：169.254.0.2/30
  • 例)2 ルーターのピア IP：169.254.0.5/30、Amazon ルーターのピア IP：169.254.0.6/30

BGP認証キー

BGP認証キーについてヒアリングがあった場合、地方自治体側で任意の値を決めます。パスワード的な扱いの値になりますが、VPNのように通信暗号化に利用しているわけではないのと、専用閉域ネットワークを用いることから漏洩やなりすましリスクはそこまで高くありません。わかりやすい値等にしておくと良いと思います。

  • 例) GovCloud

経路制御で利⽤するパラメーター

おそらくですが、オンプレミス側からAWS方向へのルーティングを制御するために、AWS側のCIDRに関するヒアリングがあると想定されます。 AWS側のVPCのすべてのCIDR(IPアドレス範囲 - 192.168.0.0/24 等のように記載) を回答すればよいのですが、当面は標準準拠システム等が数年かけてAWS上にリフトするため多段的にAWSを構築する地方自治体様が多いと考えられます。AWSの構築都度VPCのCIDRが増える度にパラメーターを連携するのは運用が煩雑になります。ガバメントクラウドAWSの構築初期の段階においてAWS上で利用予定の広い範囲のCIDR(例 192.168.0.0/16 など) を設計しておき最初にパラメーター回答しておけば、後々の運用が楽になると思われます。

LGWAN側またはオンプレミス側のネットワーク機器で、BGPによる経路広報がサポートされている可能性もあるので、技術的にはVPCやCIDR 追加の都度の申請は必要ないかもしれません。詳細が判明しましたら本BLOG記事アップデートしたいと思います。

まとめ

いかがでしたでしょうか。地方自治体のご担当者様におかれては、AWSのみならずネットワークに関する専門用語でのパラメーターヒアリングに悪戦苦闘されておられる方も多いのではないかと予想します。回答内容について相談できるベンダーとお付き合いがあればよいのですが、そのようなベンダーが居ない状況の地方自治体様もおられるかと思います。本BLOGの内容が皆様への少しでものお助けになれば幸いです。

*1:デジタル庁：令和5年6月9日 閣議決定 - デジタル社会の実現に向けた重点計画：https://www.digital.go.jp/policies/priority-policy-program/#document

*2:デジタル庁 - ガバメントクラウド先行事業（市町村の基幹業務システム等）の中間報告を掲載しました：https://www.digital.go.jp/news/ZYzU5DYY

*3:AWS Direct Connect のよくある質問：https://aws.amazon.com/jp/directconnect/faqs/

*4: Dynamic Configuration of IPv4 Link-Local Addresses：https://datatracker.ietf.org/doc/html/rfc3927

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎