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

自治体システム標準化・ガバメントクラウド勉強会（基礎編）での登壇資料です。
https://gov-cloud.connpass.com/event/318262/

Transcript

1. オンプレミスネットワークとVPCとを接続する際に考慮すべ きポイントを考えてみた
 クラスメソッド株式会社 のんピ
 1
2. 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", ] }
3. 3 みなさんご覧になりましたか? ガバメントクラウド先行事業（市町村の基幹業務システム等）の中間報告を掲載しました - ガバメントクラウド利用における推奨構成（令和 6年5月22日作成） https://www.digital.go.jp/news/ZYzU5DYY/
4. 4 こちらに記載されている内容を中心に オンプレミスネットワークとVPCを接続する際の考 慮ポイントの一部を紹介します
5. 5 オンプレとVPC間を閉域接続で通信をするまで 1. AWSアカウントの用意 2. VPCの用意 3. VGW or Transit Gatewayの用意 4. Direct ConnectとDirect Connectロケーションまでの 回線用意 5. ルーティングの設定 6. DNSレコードの登録 7. 通信 が、ざっくり必要
6. 6 図に起こすと
7. 7 詳細はおおよそ以下資料に記載 https://dev.classmethod.jp/articles/developersio-2023-multi-account-hybrid-network/
8. 8 Direct Connect周りのイメージは以下が参考になります https://speakerdeck.com/minorun365/aws-direct-connecttoyu-kuai-nagwtatinoosarai
9. 9 今回はここに注目 1. AWSアカウントの用意 2. VPCの用意 3. VGW or Transit Gatewayの用意 4. Direct ConnectとDirect Connectロケーションまでの 回線用意 5. ルーティング設定 6. DNSレコードの登録 7. 通信
10. 10 VGW or Transit Gatewayの用意で考慮すべきこと オンプレと接続したいVPCの数の把握
11. 11 なぜ「オンプレと接続したいVPCの数の把握」？ 論理回線のハブとして動作するDirect Connect Gatewayにア タッチできるVPC (正しくはVGW) が20個までだから
12. 12 20個以上接続したい場合は? • Direct Connect Gatewayを増やす • Transit Gatewayで接続する • PrivateLinkを使用する
13. 13 Direct Connect Gatewayを増やす のイメージ 　
14. 14 Direct Connect Gatewayを増やした場合の考慮点 • DXGWに併せてPrivate VIFも増やす必要がある ◦ ホスト型VIFやホスト型接続の場合、VIF分だけコスト増加 AWS Direct Connectと愉快なGWたちのおさらい P.25
15. 15 Transit Gatewayで接続する のイメージ
16. 16 Transit Gatewayで接続する場合の考慮点 • 比較的高価 ◦ Transit Gatewayへの接続時間 : 0.07 USD/h/接続リソース ◦ Transit Gatewayへのデータ転送量 : 0.02 USD/GB • 回線増強は必要なケースがある ◦ 1本の論理回線をハブにしているためトラフィックが集中 • Transit VIFが必要 ◦ Transit VIFを提供しているプロバイダーを使用する必要がある
17. 17 PrivateLinkで接続する のイメージ PrivateLink各システム用のアクセスポイントを生やして、接続
18. 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
19. 19 結局どれ選ぶ? 個人的には接続がシンプルなTransit Gateway
20. 20 DXとDXロケーションまでの回線用意 どのパターンで用意するか
21. 21 ガバメントクラウドへの接続パターンは5種類 1. 自前で用意した専用線(ガバメントクラウド接続サービス含む)で接 続 2. 複数団体共同利用ASPのDCで経由で接続 3. 都道府県WAN経由で接続 4. 既存パブリッククラウド用の回線との相乗り 5. LGWAN経由で接続
22. 22 各ガバメントクラウドへの接続パターンのイメージ
23. 23 各ガバメントクラウドへの接続パターンのメリット
24. 24 各ガバメントクラウドへの接続パターンの考慮点
25. 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
26. 26 気になるのは三層分離 LGWAN経由でマイナンバー系システムに 接続して良い?
27. 27 接続OK (システムごとのネットワーク分離が前提) ガバメントクラウド利用における推奨構成 AWS P.73
28. 28 結局は、あくまで推奨構成 具体的な要件や環境に応じて調整はできる (調整しなければならない)
30. 30 以降作ったものの 時間が足りなかったもの
31. 31 AWSアカウントの用意で考慮すべきこと 団体間の分離をどうするか
32. 32 ガバメントクラウドの利用方式 ガバメントクラウド単独利用方式 vs ガバメントクラウド共同利用方式
33. 33 ガバメントクラウド単独利用方式とは 地方公共団体が、自ら直営で、ガバメントクラウド個別領域利用権限を行使し、ガ バメントクラウド個別領域のクラウドサービス等の運用管理をする方式 ガバメントクラウド利用における推奨構成 AWS P.44
34. 34 ガバメントクラウド共同利用方式とは ガバメントクラウド運用管理補助者が、複数の地方公共団体から付与された ガバメントクラウド個別領域利用権限を行使してクラウドサービス等の運用管理を行う 方式 ガバメントクラウド利用における推奨構成 AWS P.44
35. 35 前述の資料では「共同利用方式が推奨」とのこと ガバメントクラウド利用における推奨構成 AWS
36. 36 共同利用方式を使用する場合の分離パターンは3つ 1. アカウント分離 2. ネットワーク分離 3. アプリケーション分離
37. 37 それぞれの概要と特徴 ガバメントクラウド利用における推奨構成 AWS P.48
38. 38 疑問 結局、共同利用方式では どの分離パターンを選択すれば良い?
39. 39 再掲 : 「アプリケーション分離が推奨」とのこと ガバメントクラウド利用における推奨構成 AWS P.13
40. 40 現時点で個人的には アカウント分離
41. 41 アカウント分離を選択する理由 他分離パターンのメリットとデメリットの バランスを考えた結果
42. 42 ネットワーク分離パターン • メリット ◦ ネットワークレベルで他団体への影響を抑制することが可能 ◦ 共同利用しているリソースに対するコストメリットを得られる • デメリット ◦ アカウント単位でのクォータの上限に達しやすい ◦ 共同利用しているリソースのコストインパクトは大きくない(認識) ◦ 料金按分がしづらい ▪ 転送量などタグごとの使用量を把握できないものが存在 ▪ 団体の人口規模で按分するなど別途フォローが必要 ◦ 権限のコントロールがしづらい ▪ 事業者内で団体ごとにチーム分けをしている場合、担当外の他団体の リソースが見えてしまうことがある
43. 43 アプリケーション分離パターン (1/2) • メリット ◦ 共同利用しているリソースに対するコストメリットを得られる • デメリット ◦ アカウント単位でのクォータの上限に達しやすい ◦ 料金按分がしづらい ▪ 転送量などタグごとの使用量を把握できないものが存在 ▪ 団体の人口規模で按分するなどフォローが必要 ◦ 権限のコントロールがしづらい ▪ 事業者内で団体ごとにチーム分けをしている場合、担当外の他団体の リソースが見えてしまうことがある
44. 44 アプリケーション分離パターン (2/2) • デメリット つづき ◦ 障害発生や、各団体の利用状況に応じて他団体に影響がある可能性がある ▪ ノイジーネイバー対策などマルチテナント運用時に求められる対応が必要 ◦ ストレージやDBなどは物理的に分離をすることが求められるケースがある ▪ 共有利用することによるコストメリットが薄まる ガバメントクラウド利用における推奨構成 AWS P.52 マルチテナントSaaSのように利用するのは現時点では難しい感触
45. 45 ちなみに どのパターンを選択するにしても 本番/検証/開発のAWSアカウントは分離しよう
46. 46 詳細はP.52から https://speakerdeck.com/non97/aws-ambassadorgakao-eruge-ren-de-nizui-qiang-nomarutiakauntohaiburitudonetutowakugou-cheng?slide=52