【イベントレポート】第4回　自治体システム標準化・ガバメントクラウド勉強会 #自治体クラウド勉強会

Last updated at 2024-12-18Posted at 2024-12-18

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

12/18（木）に参加した第4回　自治体システム標準化・ガバメントクラウド勉強会のイベントレポートとなります。スキマ時間にサクッと読める分量となっていますので、お気軽に読んでいただけますと幸いです。

イベントページ

2025年度末を目処に、各自治体ごとに異なるシステムを標準化する「自治体システム標準化」。そして、これらの標準化したシステムを「ガバメントクラウド」に移行する動きがあります。自治体のシステムが大きく変わろうとしているものの、庁内ネットワークやLGWANとの接続、システム構成のあり方ーーなどと考慮しなければならないことが次々と生まれています。
こうした疑問を相互に共有し、解決する場を作るためのクラウド勉強会を開催します。全国どこからでも、どなたでもご参加可能です。

今回のテーマ

そこで第4回となる今回は、北海道の某自治体職員の方が実際に作成したAWS構成図（ガバメントクラウドを想定したマルチアカウント間の Route 53 プライベートホストゾーンとインバウンドエンドポイントの共有について）を題材に、主にネットワーク周辺の解説および設計のポイントなどをパネルディスカッション形式でお届けいたします。
「そもそもそれってなんでこうなってるの？」「なぜこれが必要なの？」などなどの初心者目線の質問にエキスパート達がわかりやすく解説してくれるはずです。

イベントを聞いてもらいたい方

自治体の標準化に関わる、担当の方や関連のITベンダー、ネットワーク事業者の方など
「標準化やガバクラ移行に対応しなければならないことは認識しているが、何から理解を深めれば良いかわからないーー。」
「今後の移行に向けて、何から始め、注意すべき技術的ポイントは何か知りたいーー。」
「担当者になったが、何から理解していけばいいのかわからない！」
このようなお悩みがある方の疑問を解決できる場になればと思います。
お昼ご飯を食べながら、ラジオ感覚で気軽にご参加ください！

ガバメントクラウド事例集リンク

イベントレポート

LT & 構成図の解説

登壇資料

レポート

お話ししたいこと
- ガバメントクラウドでAWSを利用する際閉域ならではのネットワークの難しさを感じた
  - ブログへ体験談を執筆してみた
- AWSサービスの一つであるRoute 53を例にした名前解決の方法
自己紹介
- 北海道の某自治体の情シスっ担当の方
- オンプレミスネットワークは触ったことがあるがクラウドは少し触ったレベル
- AWS ANS取得者（つよつよの方）
ガバメントクラウドでのAWSの難しさ
- パブリッククラウドなのに閉域網を利用しないといけない
- 庁内の閉域ネットワークと連携しないといけない
- 情報リソースが少ない
  - 自分で構築しながら試してみる
ガバメントクラウドでのRoute 53の名前解決
- オンプレミスの庁内ネットワークからAWS上のリソースの名前解決が必要
- マネージドサービスの名前解決も重要
- 自前でAWS側のDNSサーバを構築するのは厳しい
  - 解決策としてプライベートホストゾーンの活用
プライベートホストゾーン
- 閉域内のネットワークから名前解決してくれるサービス
- オンプレ環境に対し2つのVPCがある構成
  - Direct Connect⇔DXGW⇔TGWの構成
- VPCごとにRoute53インバウンドエンドポイントを置くことで管理が煩雑になる
  - コストもエンドポイント数分かかってしまう
- Route53インバウンドエンドポイントを一つにまとめることで解決可能
まとめ
- Route53以外にもS3関連も考えてみましょう
- マルチベンダーでガバメントクラウドを行う場合集約が難しい場合がある
  - その場合、保守工数がかかってしまいコスト増になってしまう
  - 場合によってはベストプラクティスではない可能性もある
  - 信頼できる事業者へ相談してみましょう！！

パネルディスカッション

レポート

イベントテーマのきかっけ
- ネットワーク周りの知識が難しくキャッチアップするため（すぎいさん談）
庁内ネットワーク内のDNSへの処理は
- インバウンドエンドポイントへフォワーディングをさせる処理（条件付きフォワーダー）をいれる
Naas拠点とは何か
- Customer GatewayとDirect Connectを仮想線でつなぐサービス
インバウンドエンドポイントの役割は
- AWS内になるVPCエンドポイントに対して外から見れるようにする機能
  - （例）AのVPC内にインバウンドエンドポイントがある場合、BのVPC内のEC2からAのVPCEへアクセスできるイメージ
ネットワークアカウントに作った方がいいのではないか
- ネットワークアカウントの方が管理しやすい
共同利用方式の場合、個別調整が必要なため難しい
個人的にAWSアカウントで試してみるのはおススメ
EC2で名前解決させた方がいいのでは
- Route 53で対応したほうが管理しやすくなる
- 管理負荷・コストを考えると高くなる場合も
AWSを利用する場合は責任共有モデルの先はAWSに任せる精神が必要
高橋名人の学習方法
- トレノケート・なんちゃらテックのコンテンツを触ってみる
エンタープライズ関連でも同じような悩みがある