オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた #自治体クラウド勉強会

by のんピ

Slide 1

Slide 1 text

オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた  クラスメソッド株式会社のんピ  1

Slide 2

Slide 2 text

2 自己紹介 { "本名": "山本涼太 (覚えなくていいです)", "部署": "AWS事業本部コンサルティング部", "前職": "インフラエンジニア in データセンター", "興味のあること": "面白そうなブログネタ探し", "好きなAWSサービス": [ "Amazon FSx for NetApp ONTAP (FSxN)" "AWS Transit Gateway", "AWS Step Functions" "AWS CDK" ], "称号" : [ "2023 Japan AWS Ambassador", "NetApp Advanced Solution Leading Award 2023", ] }

Slide 3

Slide 3 text

3 みなさんご覧になりましたか? ガバメントクラウド先行事業（市町村の基幹業務システム等）の中間報告を掲載しました - ガバメントクラウド利用における推奨構成（令和 6年5月22日作成） https://www.digital.go.jp/news/ZYzU5DYY/

Slide 4

Slide 4 text

4 こちらに記載されている内容を中心にオンプレミスネットワークとVPCを接続する際の考慮ポイントの一部を紹介します

Slide 5

Slide 5 text

5 オンプレとVPC間を閉域接続で通信をするまで 1. AWSアカウントの用意 2. VPCの用意 3. VGW or Transit Gatewayの用意 4. Direct ConnectとDirect Connectロケーションまでの回線用意 5. ルーティングの設定 6. DNSレコードの登録 7. 通信が、ざっくり必要

Slide 6

Slide 6 text

6 図に起こすと

Slide 7

Slide 7 text

7 詳細はおおよそ以下資料に記載 https://dev.classmethod.jp/articles/developersio-2023-multi-account-hybrid-network/

Slide 8

Slide 8 text

8 Direct Connect周りのイメージは以下が参考になります https://speakerdeck.com/minorun365/aws-direct-connecttoyu-kuai-nagwtatinoosarai

Slide 9

Slide 9 text

9 今回はここに注目 1. AWSアカウントの用意 2. VPCの用意 3. VGW or Transit Gatewayの用意 4. Direct ConnectとDirect Connectロケーションまでの回線用意 5. ルーティング設定 6. DNSレコードの登録 7. 通信

Slide 10

Slide 10 text

10 VGW or Transit Gatewayの用意で考慮すべきことオンプレと接続したいVPCの数の把握

Slide 11

Slide 11 text

11 なぜ「オンプレと接続したいVPCの数の把握」？論理回線のハブとして動作するDirect Connect GatewayにアタッチできるVPC (正しくはVGW) が20個までだから

Slide 12

Slide 12 text

12 20個以上接続したい場合は? ● Direct Connect Gatewayを増やす ● Transit Gatewayで接続する ● PrivateLinkを使用する

Slide 13

Slide 13 text

13 Direct Connect Gatewayを増やすのイメージ　

Slide 14

Slide 14 text

14 Direct Connect Gatewayを増やした場合の考慮点 ● DXGWに併せてPrivate VIFも増やす必要がある ○ ホスト型VIFやホスト型接続の場合、VIF分だけコスト増加 AWS Direct Connectと愉快なGWたちのおさらい P.25

Slide 15

Slide 15 text

15 Transit Gatewayで接続するのイメージ

Slide 16

Slide 16 text

16 Transit Gatewayで接続する場合の考慮点 ● 比較的高価 ○ Transit Gatewayへの接続時間 : 0.07 USD/h/接続リソース ○ Transit Gatewayへのデータ転送量 : 0.02 USD/GB ● 回線増強は必要なケースがある ○ 1本の論理回線をハブにしているためトラフィックが集中 ● Transit VIFが必要 ○ Transit VIFを提供しているプロバイダーを使用する必要がある

Slide 17

Slide 17 text

17 PrivateLinkで接続するのイメージ PrivateLink各システム用のアクセスポイントを生やして、接続

Slide 18

Slide 18 text

18 PrivateLinkで接続する場合の考慮点 ● 双方向通信はできない ○ システムAから拠点へのリクエストは不可 ○ 拠点からシステムAのリクエストに対するレスポンスは可 ● 安いという訳ではない ○ VPCエンドポイント稼働時間 : 0.014 USD/h/AZ ○ VPCエンドポイントのデータ処理量: 0.01 USD/GB (最初の1 PB) ○ NLBの稼働時間 : 0.0243USD/h ○ NLCU 時間 : 0.006 USD/NLCU

Slide 19

Slide 19 text

19 結局どれ選ぶ? 個人的には接続がシンプルなTransit Gateway

Slide 20

Slide 20 text

20 DXとDXロケーションまでの回線用意どのパターンで用意するか

Slide 21

Slide 21 text

21 ガバメントクラウドへの接続パターンは5種類 1. 自前で用意した専用線(ガバメントクラウド接続サービス含む)で接続 2. 複数団体共同利用ASPのDCで経由で接続 3. 都道府県WAN経由で接続 4. 既存パブリッククラウド用の回線との相乗り 5. LGWAN経由で接続

Slide 22

Slide 22 text

22 各ガバメントクラウドへの接続パターンのイメージ

Slide 23

Slide 23 text

23 各ガバメントクラウドへの接続パターンのメリット

Slide 24

Slide 24 text

24 各ガバメントクラウドへの接続パターンの考慮点

Slide 25

Slide 25 text

25 手軽さからLGWAN経由の接続が人気出そうな予感ただし、LGWANへの回線の太さやLGWAN特有の制約事項は要注意総合行政ネットワーク（ LGWAN）の概要 P.17 https://www.j-lis.go.jp/data/open/cnt/3/180/1/L-2_gaiyou_Internet_201804.pdf

Slide 26

Slide 26 text

26 気になるのは三層分離 LGWAN経由でマイナンバー系システムに接続して良い?

Slide 27

Slide 27 text

27 接続OK (システムごとのネットワーク分離が前提) ガバメントクラウド利用における推奨構成 AWS P.73

Slide 28

Slide 28 text

28 結局は、あくまで推奨構成具体的な要件や環境に応じて調整はできる (調整しなければならない)

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 以降作ったものの時間が足りなかったもの

Slide 31

Slide 31 text

31 AWSアカウントの用意で考慮すべきこと団体間の分離をどうするか

Slide 32

Slide 32 text

32 ガバメントクラウドの利用方式ガバメントクラウド単独利用方式 vs ガバメントクラウド共同利用方式

Slide 33

Slide 33 text

33 ガバメントクラウド単独利用方式とは地方公共団体が、自ら直営で、ガバメントクラウド個別領域利用権限を行使し、ガバメントクラウド個別領域のクラウドサービス等の運用管理をする方式ガバメントクラウド利用における推奨構成 AWS P.44

Slide 34

Slide 34 text

34 ガバメントクラウド共同利用方式とはガバメントクラウド運用管理補助者が、複数の地方公共団体から付与されたガバメントクラウド個別領域利用権限を行使してクラウドサービス等の運用管理を行う方式ガバメントクラウド利用における推奨構成 AWS P.44

Slide 35

Slide 35 text

35 前述の資料では「共同利用方式が推奨」とのことガバメントクラウド利用における推奨構成 AWS

Slide 36

Slide 36 text

36 共同利用方式を使用する場合の分離パターンは3つ 1. アカウント分離 2. ネットワーク分離 3. アプリケーション分離

Slide 37

Slide 37 text

37 それぞれの概要と特徴ガバメントクラウド利用における推奨構成 AWS P.48

Slide 38

Slide 38 text

38 疑問結局、共同利用方式ではどの分離パターンを選択すれば良い?

Slide 39

Slide 39 text

39 再掲 : 「アプリケーション分離が推奨」とのことガバメントクラウド利用における推奨構成 AWS P.13

Slide 40

Slide 40 text

40 現時点で個人的にはアカウント分離

Slide 41

Slide 41 text

41 アカウント分離を選択する理由他分離パターンのメリットとデメリットのバランスを考えた結果

Slide 42

Slide 42 text

42 ネットワーク分離パターン ● メリット ○ ネットワークレベルで他団体への影響を抑制することが可能 ○ 共同利用しているリソースに対するコストメリットを得られる ● デメリット ○ アカウント単位でのクォータの上限に達しやすい ○ 共同利用しているリソースのコストインパクトは大きくない(認識) ○ 料金按分がしづらい ■ 転送量などタグごとの使用量を把握できないものが存在 ■ 団体の人口規模で按分するなど別途フォローが必要 ○ 権限のコントロールがしづらい ■ 事業者内で団体ごとにチーム分けをしている場合、担当外の他団体のリソースが見えてしまうことがある

Slide 43

Slide 43 text

43 アプリケーション分離パターン (1/2) ● メリット ○ 共同利用しているリソースに対するコストメリットを得られる ● デメリット ○ アカウント単位でのクォータの上限に達しやすい ○ 料金按分がしづらい ■ 転送量などタグごとの使用量を把握できないものが存在 ■ 団体の人口規模で按分するなどフォローが必要 ○ 権限のコントロールがしづらい ■ 事業者内で団体ごとにチーム分けをしている場合、担当外の他団体のリソースが見えてしまうことがある

Slide 44

Slide 44 text

44 アプリケーション分離パターン (2/2) ● デメリットつづき ○ 障害発生や、各団体の利用状況に応じて他団体に影響がある可能性がある ■ ノイジーネイバー対策などマルチテナント運用時に求められる対応が必要 ○ ストレージやDBなどは物理的に分離をすることが求められるケースがある ■ 共有利用することによるコストメリットが薄まるガバメントクラウド利用における推奨構成 AWS P.52 マルチテナントSaaSのように利用するのは現時点では難しい感触

Slide 45

Slide 45 text

45 ちなみにどのパターンを選択するにしても本番/検証/開発のAWSアカウントは分離しよう

Slide 46

Slide 46 text

46 詳細はP.52から https://speakerdeck.com/non97/aws-ambassadorgakao-eruge-ren-de-nizui-qiang-nomarutiakauntohaiburitudonetutowakugou-cheng?slide=52