大規模なAWS NWを管理する
（VPCエンドポイント、Route53の共有）（1）
投稿日: 2025/2/26
はじめに
こんにちは、園田です。
前回記事を投稿してから大分時間が経ってしまいました。
これまで統制等の観点から色々記事を書いてきましたが、今回は久しぶりにNWの記事になります。
これまでNWの記事は以下4つ記載していますので、よろしければ是非参照ください。
はじめてのAWS NW（その1）
基本的なNWの構成、設定について説明しています。
はじめてのAWS NW（その2）
DirectConnectおよびVPNでのオンプレミスとの接続について説明しています。
はじめてのAWS NW（その3）
大規模でNWを利用するための共有VPC、Transit Gatewayについて説明しています。
はじめてのAWS NW（その4）
AWSのNWを利用する際の名前解決（route53リゾルバ）について説明しています。
今回は実際に大規模なAWS NWを管理するにあたり、どんな感じで設計・運用すればよいの？、という点についてお話ししたいと思います。
大規模NWってどんな感じで設計するの？
まず最初にどんな感じで大規模NWって設計するの？
というお話からしたいと思います。
身も蓋も無くて申し訳ないですが、基本は「共有VPCを利用する」、もしくは「Transit Gatewayを利用する」の2択になります。
個人的な好みからすると「共有VPC」が非常に優れています。
理由として、管理アカウント（便宜上、「システム共通アカウント」を呼称します）側で全てNWを作ってしまい個々のアカウント（便宜上、「個別システムアカウント」と呼称します。）に共有することにより、個別システムアカウント側はNWの設計が不要になります。
また不要になる以外にも「個別システムアカウント側はNW設定を変更できない」為、NW統制が意図せず取れてしまいます。
Transit Gatewayを使った場合も、SCP等で個別アカウント側はNW操作をさせない（全体管理者以外、触らせない）という設計をすればよいのですが、正直意外と大変です。
※SCPについては以下の記事を参照ください。
https://www.ctc-g.co.jp/solutions/cloud/column/article/53.html
なので、SCPを使わずにNW統制が取れる共有VPCはとても優れています。
ただ、1点共有VPCは欠点があって、共有VPCを利用するアカウントは全て同一のOrganization配下に存在する必要があります。
どういうことかというと、例えば外部のベンダーと接続したいといった場合、自社のアカウントのOrganizationをベンダーのOrganizationは基本異なるため、共有することはできません。
そのため、厳格な意味での共通化がむずかしく設計の破綻が生じやすいです。
「将来どのような形でも対応できる」という事を目指すのであれば、Transit Gatewayを利用するのが無難と言えます。
（個人的には共有VPCかつ、Transit Gatewayのハイブリットアーキテクチャが良いと思うのですが、ハイブリットにしてしまうと運用担当者がついてこれないリスクもあり、難しいところです）
という訳で、Transit Gatewayの設計を前提に進めていきましょう。
Transit Gatewayにて大規模環境を作る際はこんな感じになりますね。
Transit Gatewayを使った際のNW構成図
いきなり、結論が出てしまって大変申し訳ないですが、大体こんな感じです。
とりあえず簡単にNW構成図（？）を見ていきましょう。
共有システムアカウント
会社の共通機能等をまとめたアカウントです。
それぞれ、PrivateとPublicセグメントを有しています。
Privateセグメント、Publicセグメントとも、「サーバ用」、「マネージド用」を用意しています。
ぶっちゃけ、サーバ用って必要？という話になるかと思いますが、IPを管理したいという需要を考慮してマネージド用と分割しています。（一般的なベストプラクティスって大多数の人にとってベストではないというのが持論です。（ベストプラクティスとはいったい…））
また、このアカウントにDirectConnectの機能（Transit Gateway含む）、VPCエンドポイント、Route53リゾルバ（アウトバウンド）などを管理します。
個別システムアカウント
LOB部門など全社共通ではないシステム等を配置するためのアカウントです。
権限や予算問題（RI）を考慮し、アカウントを分割しています。
後できちんと記載しますが、VPCエンドポイントやRoute53リゾルバ（アウトバウンド）などは個別アカウント側では作成せず、共有システムアカウント側のものを利用します。
Transit Gatewayサブネット
AWSさんが「独立したサブネットにしなさい。」というので分けています。
Transit GatewayでNWを制御する必要が無ければ、サブネットを分ける必要はないのですが、「もしかして要件が変わるかも」（なお、変わらない模様）ということで念のため、分けています。
VPCに複数のIPを付与できますので、Transit Gaewayに割り当てるIPは、サーバ用、マネージド用と異なるIPを付与するのが好みです。
（サーバ、マネージドは、10.0.0.0/16のレンジから利用するがTransit Gatewayは10.1.0.0/16のレンジを利用する、とか。わざと分けてる感がありますからね。ぱっと見分かり易くするのはとても重要です。）
VPCエンドポイントを共有する理由
という訳で、こんな感じで大規模NWを設計したわけですが、見ての通りアカウントがたくさんあります。
なるべく共通設計で管理の手間を省いて、費用がかからないようにと考えた場合、VPCエンドポイントは基本共有しましょう。
VPCエンドポイントとは
VPCと他のサービス間の通信を可能にするVPCコンポーネント(仮想デバイス)となります。
通常、EC2が他のサービスと通信を実施する場合、インターネットを経由する必要があります。
具体的には、
EC2→（NAT Gateway）→igw→インターネット→AWSサービス、という形になります。
オンプレミスを経由している場合は、EC2→オンプレミス（プロキシなども含む）→インターネット→AWSサービスとなります。
AWSのigwを経由する場合、インターネットとはいえ、あくまでAWS内のインターネットなので個人的には問題ない（セキュリティ的な観点で）と思っていますが、何はともあれインターネット経由させたくないというケースがあるかと思います。
そんな時に大変便利なのがVPCエンドポイントになります。
このVPCエンドポイントを使うと、
EC2→VPCエンドポイント→AWSサービスという形の経路となり、インターネットを経由していません。
なのでよりセキュアに利用可能という事になります。
なお、VPCエンドポイントには、Gateway型とインターフェイス型（以下、「IF型」）が存在します。
VPCエンドポイントの困った点
説明を聞いて「VPCエンドポイントいいじゃん。」となる訳ですが、意外と問題点もあります。
問題点は大きく分けて以下の２つです。
問題点1：
意外と費用がかかる。
IF型のエンドポイントの場合、費用は「10.08ドル（30日/シングルAZ）」となります。
そのため、マルチAZ構成の場合、「20.16ドル（30日/マルチAZ）」となります。
（Gateway型はS3とDynamoDBのみなので、基本はIF型になります。）
20.16ドルだと大した金額じゃないよね。と思うかもしれませんが、エンドポイントはサービス毎に作る必要があります。
例えばSSMセッションマネージャを利用したい場合、以下の3つのエンドポイントを作成する必要があります。
（これはAWSの設計がおかしいのではないかと思うのですが…。）
SSMセッションマネージャを利用する際に必要なエンドポイント
ssm.ap-northeast-1.amazonaws.com
ssmmessages.ap-northeast-1.amazonaws.com
ec2messages.ap-northeast-1.amazonaws.com
ほかにも、CloudWatch、Athena、CodeCommit、ecsとか言っているとキリがありません。都度お金がかかってしまいます。
また、各アカウントでVPCエンドポイントを作ってしまうと、例えば50アカウントでそれぞれに10VPCエンドポイントがあった場合、
20.16ドル×10 VPCエンドポイント×50 = 10080ドル
という金額になってしまいます。
（日本円にして151万2千円（月額、1ドル150円計算の場合））
ぶっちゃけ絶対に払いたくない金額ですね。
問題点2：
なんだかんだ言ってIPアドレスも消費する
IF型のエンドポイントの場合、IPアドレスを1つ消費します。
そのため、10個のVPCエンドポイントを作ってしまった場合、10 IPが消費されてしまいます。
時々、オンプレっぽく、「/27」とかでサブネット作成しているケースが見られます。
その中で10個のVPCエンドポイントを作ると…、
- NWアドレスとブロードキャストアドレス
- サブネット +1、+2はAWS利用
- VPCエンドポイントで10個
という形になってしまい、32個中、14 IPが消費される計算となります。
そうなると、実際使えるIPはサブネットの半分ちょっととなります。
（これらを踏まえると/28とかでサブネット作成するのは正気とは思えません。（稀に見かけます。）
最低でも/26以上で作成して欲しいものです。）
これらを踏まえ、各AWSアカウントでVPCを作るというのは良くないという事が、分かっていただけたのではないでしょうか。
NWは設計が重要ですね。
実際にVPCエンドポイントを共有する
はい、では早速VPCエンドポイントを共有していきましょう。
こんな感じですね。
VPCエンドポイントを共有する
今回は上の画像の通り、
- 共有アカウント（仮にアカウントAと呼称）にてVPCエンドポイントを作成
- 個別アカウント（仮にアカウントBと呼称）は共有アカウントのVPCを共有
という形でやってみたいと思います。
まずはアカウントAになります。
なお、実際には各アカウントはTransit Gatewayで接続されている必要がありますが、Transit Gatewayの接続までやるとだいぶ長くなってしまうので、割愛します。
前提として、「Transit Gatewayにより、各アカウントのVPC間は接続が出来ている状態。」とします。
（ちゃんとルーティングも入れてくださいね）
アカウントAでやること：
- 1.VPCエンドポイントを作成（プライベートDNSは無効化しておく）
- 2.プライベートホストゾーンを作成
- 3.プライベートホストゾーンをアカウントBに共有
という作業が必要になります。
一方アカウントBでは、
アカウントBでやること：
- 4.共有申請された、プライベートホストゾーンの承認
という作業が必要となります。
ぶっちゃけこれだけといえば、これだけです。
なお、運用では「3」と「4」のみ実施でOKです。（初回のみ「1」、「2」を実施）
ただし、 「2」～「4」の作業はVPCエンドポイントごとに実施する必要があります。
具体的に言うと、SSMセッションマネージャを利用するという事で、以下の3つのエンドポイントを作った場合、3つのゾーンに対して、「2」～「4」を実施する必要があります。
ssm.ap-northeast-1.amazonaws.com
ssmmessages.ap-northeast-1.amazonaws.com
ec2messages.ap-northeast-1.amazonaws.com
エンドポイントが10個ぐらいあると面倒ですね。
仕方ないことですが、もうちょっと手間がかからないようにして欲しいものです。
■Step 1 VPCエンドポイントを作成（プライベートDNSは無効化しておく）
実際の作業内容になります。
まずは軽くVPCエンドポイントを作成しましょう。
こんな感じで、サクッとエンドポイントを作ります。
ポイントは、「DNS名を有効化」のチェックを外すだけです。
なお、既に作ってしまっているよー。という場合はこんな感じで「プライベート DNS 名の設定を変更」のチェックを外すことが可能です。
（作成したエンドポイントをチェック→アクション→「エンドポイント設定を変更」にて下記の画面が表示されます。）
この「プライベートDNSを無効化」ですが、これをするとどうなるかというと、せっかくVPCエンドポイントを作ったのに、DNSで名前を引くことが出来ないため、利用することが出来ません。（プライベートホストゾーンをつくらないと、名前解決時にグローバルのIPアドレスとなってしまいます。）
そのため、既存のVPCエンドポイントから「プライベートDNSを無効化」する際は、注意が必要です。（いきなりエンドポイントにアクセス出来なくなるため、障害発生の可能性があります。）
特に共有予定が無いよ。という場合は、「プライベートDNSを有効化」で作ってしまいましょう。その方が楽なので。
ではなぜ、わざわざ「プライベートDNSを無効化」するかというと、自身で作成したDNSレコード（プライベートホストゾーン）じゃないと共有が出来ないからです。
共有する気が無いのであれば、AWSが勝手に作ってくれたDNSレコード（プライベートホストゾーン）で十分です。
これに限らず、AWSは結構知らなくて使えるようになっているため、意外と見落としてることがあるかと思います。注意しましょう。
■Step 2 プライベートホストゾーンを作成
次はStep2です。
アカウントAでプライベートホストゾーンを作成しましょう。
プライベートホストゾーンの作成はもちろん、route53の機能です。
こちらは途中で記載している通り、VPCエンドポイントごとにプライベートホストゾーンを作成する必要があります。
今回は、SSMセッションマネージャを使う場合を例にとって進めたいと思います。セッションマネージャ利用には3つのプライベートホストゾーンが必要になるので注意しましょう。
〇SSMセッションマネージャを使う場合、必要なホストゾーン（3つ必要）
実際にホストゾーンをつくる時の設定
ドメイン名：
「ec2messages.ap-northeast-1.amazonaws.com」みたいな感じで、エンドポイント名を記載します。
※「ec2messages」の部分はサービス名によって、変更ください。
※「ap-northeast-1.amazonaws.com」の部分はVPCエンドポイントを作成したリージョンによって変更ください。
ホストゾーンに関連付ける VPC：
VPCエンドポイントを作成したVPCを選択してください。
ホストゾーンにレコードを作成
作成した「ec2messages.ap-northeast-1.amazonaws.com」ゾーンに対し、作成したVPCエンドポイントの「ec2messages」を紐付けます。
Route53ではネイキッドドメインがエイリアスレコードで利用できるので、エイリアスで設定します。
レコード名：
何も入力しません。
エイリアス：
有効化します。
トラフィックのルーティング先：
- 「VPCエンドポイントのエイリアス」を選択
- VPCエンドポイントがあるリージョンを選択
- 作成したエンドポイントを選択（※）
※画像にある「ec2messages」は3つ出力されます。
各AZに紐つくエンドポイントではなく「自動作成されるリージョン毎のパブリックDNS名」にしましょう。
（「ap-northeast-1a」、「ap-northeast-1c」とかの具体的な物は選択しない）
この「ホストゾーンを作成」、「ホストゾーンにレコードを作成」はエンドポイントごとに実施します。
SSMセッションマネージャを使いたい場合、以下の3つに対して作業が必要となります。
〇以下に対して「ホストゾーンを作成」、「ホストゾーンにレコードを作成」が必要
ssm.ap-northeast-1.amazonaws.com
ssmmessages.ap-northeast-1.amazonaws.com
ec2messages.ap-northeast-1.amazonaws.com
■Step 3 プライベートホストゾーンをアカウントBに共有
いよいよ準備が出来ましたので、アカウントAで作成したプライベートホストゾーンをアカウントBに共有申請をしたいと思います。
共有申請といえば、RAM（AWS Resource Access Manager）ですが、この作業はRAMでは出来ません。
（ややこしいので、統一化して欲しいものです…。）
また、CLIオンリーの作業となっており、マネジメントコンソールからは実施できません。
〇「CLIで実施しなさい」とのAWSからのありがたい記載
仕方ないのでCLIで実施をしましょう。
CLIで実施するときに便利なのがCloudShellになります。
CloudShellって何？という人はこちらを参照ください。時間があれば、CloudShellのお話も書きたいなと思いますが今はAWSのドキュメントで我慢してください。
https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/welcome.html
という訳で、CloudShellをアカウントAで立ち上げましょう。なお、当たり前ですが、CloudShellを実施するアカウントはVPCに対して操作権限が必要となります。
基本PowerUser以上の権限で実施しましょう。
実施するコマンドは以下の通りです。
コマンド1：
#aws route53 list-hosted-zones --no-cli-pager
実施するとこんな感じの出力が実施されます。
「“/hostedzone/xxxxxxxxxxxxxxxxxxx”,」のxxxxxxxxxxの文字列について実際に共有申請を実施する際に必要となるIDとなります。メモ帳等に控えておきましょう。
コマンド2：
コマンド1にて確認したIDを利用して共有申請を実施します。
コマンドは以下の通りです。
aws route53 create-vpc-association-authorization \
--hosted-zone-id 【先程メモったID】 \
--vpc VPCRegion=ap-northeast-1,VPCId=【紐付けを行うVPC ID】
【紐付けを行うVPC ID】はアカウントBのVPC IDになります。アカウントBにログインしてIDを確認しておきましょう。
実際にコマンドを打つとこんな感じです。
こんな感じで、エラーが出力されなかったら問題なく実行できています。
なお、こちらも「ホストゾーン分」作業が必要となります。
しつこいですが、SSMセッションマネージャを利用する場合、3つ作業が必要となります。
これでアカウントAでの作業は完了です。
■Step 4 共有申請された、プライベートホストゾーンの承認
これはアカウントBでの作業となります。
これもCLIオンリーとなります。
という訳でCloudShellを起動しましょう。CloudShellの注意点はStep3と同じです。
承認するコマンド
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id 【step3でメモったID】 \
--vpc VPCRegion=ap-northeast-1,VPCId=【紐付けを行うVPC ID】
step3と大体一緒です。
step3は「create-vpc-association-authorization」、step4は「associate-vpc-with-hosted-zone」になりますが、それ以外は一緒です。
実際にコマンドを打つとこんな感じです。
こんな感じで、エラーが出力されなかったら問題なく実行できています。
■最後に稼働確認
最後に実際に稼働確認を実施しましょう。
方法として
- アカウントBのcloudshellでVPCエンドポイントに対してpingを打つ
- アカウントAのプライベートホストゾーンで確認を行う
の2つの方法があります。
- アカウントBのcloudshellでVPCエンドポイントに対してpingを打つ
こちらの確認を実施する際は、アカウントAのVPCエンドポイントのIPアドレスが出力されることを確認ください。
- アカウントAのプライベートホストゾーンで確認を行う
こちらの場合、こんな感じで、追加したVPCがホストゾーンに共有されています。
という訳で、共有されました。
しつこいですが、作成したホストゾーンの数分、実施する必要があります。
ご注意ください。
大規模なAWS NWを管理する（VPCエンドポイント、Route53の共有）のまとめ
今回は大規模AWS NWを管理するための構成と、それを実施するためのVPCエンドポイントの共有にてのお話でした。
これ以外にもDNSリゾルバの共有もしておいた方が良いのですが、あまりに長くなってしまったので、その２でお話ししたいと思います。
ぶっちゃけてしまうと、こんな構成にしなくても大丈夫と言えば大丈夫です。また、VPCエンドポイントも別に共有しなくても問題ありません。
ただVPCエンドポイントの問題点でも述べたように、費用が掛かりすぎたり、リソースを無駄に使うなど、共有しないと運用の観点から大変なことになってしまいます。
オンプレミス、クラウドに共通して、NWの設計・運用というのは最初にきちんと実施しておかないと後々後悔する筆頭を考えています。
（クラウド環境になってもNWだけは後で変更が難しいです。また最初のうちは設計しなくてもまぁ何とかなってしまうというのもＮＷの特性だと思っています。）
ＮＷ部分、特に設計についてはとっつきにくい箇所かと思いますが本記事が少しでもお役に立てれば幸いです。
NW設計大好き人間がクラウド環境で増えますように。
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。
