大規模なAWS NWを管理する
（VPCエンドポイント、Route53の共有）（2）

投稿日: 2025/03/03

はじめに

こんにちは、園田です。

前回記事にて、大規模なAWS NW管理におけるVPCエンドポイントの共有について記載しました。

前回の記事はこちら
大規模なAWS NWを管理する（VPCエンドポイント、Route53の共有）（1）

今回は前回でお話しできなかったRoute53リゾルバの共有（アウトバウンドエンドポイントの共有）と、大規模NW管理のための設計勘所についてお話ししたいと思います。

Route53 リゾルバを使う理由と作り方

そもそもRoute53リゾルバって何？という方はこちらの記事を参照ください。

はじめてのAWS NW（その4）
AWSのNWを利用する際の名前解決（route53リゾルバ）について説明しています。

そんなの分かっているよ。という方は飛ばしてください。

まず今回大規模なAWS NWの管理で利用するのはRoute53リゾルバのアウトバウンドエンドポイントです。簡単にアウトバウンドエンドポイントの説明を実施すると、例えば「CTC園田株式会社」がオンプレミスからAWSに移行を考えているとします。

■社内でDNSを使う理由とAWSへの移行時の課題

企業間の内部通信を実施する際、DNSにて名前解決をするのが一般的です。
理由としては、IPアドレスでも通信は出来ますが（もしくはhostsを書くとか）、その場合、サーバのリプレイス等が発生した際に、通信先のIPアドレスを変更する必要があります。
（同じIPでもリプレイス出来ますが、リスクを考慮し、通常は実施しません。）

基本通信先のIPアドレスを変更するのが面倒なので、DNSで名前解決を実施し、リプレイス等のIPアドレスが変更になる際は、DNS側のレコードを変更して対応します。

で、このDNSが公開されていれば特に問題は無いのですが、基本的には公開されていないケースがほとんどです。（ちなみにAWSのエンドポイント（RDSなど）は利便性、柔軟性を考慮し、公開されています。）

また公開されていても内部と外部のDNSは「応答するIPアドレスが異なる」というケースも存在します。

例えば、CTC園田株式会社が「ctc-sonoda.co.jp」というドメインを保持していたとしましょう。（sonodaのco.jpは既に別会社が取得済みでした。）

この社外WebページのURLである、www.ctc-sonoda.co.jpを社外から名前解決をすると、グローバルIPアドレスを応答。社内NWからwww.ctc-sonoda.co.jpの名前解決をすると、プライベートのIPアドレスを返信するというケースがそれに該当します。

www.ctc-sonoda.co.jpを名前解決すると

これは外部向けの「ctc-sonoda.co.jp」ゾーンを保持しているDNSサーバと、社内向けの「ctc-sonoda.co.jp」ゾーンを保持しているDNSサーバが異なるためです。

このように外部と内部のDNSが異なる場合、AWSに設置したEC2等からも内部向けのDNSサーバを参照する必要があります。

ただ、通常AWS環境ではグローバルのDNSサーバを参照してしまいます。そうすると（その企業的には）本来したい通信が実施できません。

これを解決するためのサービスが「Route53リゾルバ（アウトバウンド）」になります。

■route53リゾルバ（アウトバウンド）とは

route53リゾルバ（アウトバウンド）はこんな感じです。

AWS上のサーバ等がDNSを引く際に通常はAWSのDNSを確認します。
その際に、例えば、「ctc-sonoda.co.jp」のゾーンだけは公開サイトではなく、オンプレミスのDNSサーバを参照したいとします。

その場合、アウトバウンドのルールにて、「ctc-sonoda.co.jp」はオンプレミスのDNSサーバを参照する。というルールを記載します。
このルールに一致したものはDNSの問い合わせをフォワードする形になります。

「ctc-sonoda.cojp」以外にも「ctc-sonoda.local」など複数のドメインに対してもルールを定義することが可能です。

■実際に設定してみる

では実際にRoute53リゾルバ（アウトバウンド）を設定してみましょう。こんな感じ設定できます。

1. アウトバウンドエンドポイントの作成
2. オンプレミスのDNSに問い合わせを行うゾーン名を定義（例えば、「ctc-sonoda.co.jp」）
   ゾーンを保持しているDNSサーバのIPアドレスを定義
   （「ctc-sonoda.co.jp」のゾーンを192.168.1.10のサーバが関しているなら、192.168.1.10を記載）

1．アウトバウンドエンドポイントの作成

エンドポイント名：
複数のゾーンを管理できるため、任意の名前を記載

このエンドポイントのセキュリティグループ
マルチアカウント構成時、全てのAWSアカウントからこのエンドポイントにアクセスするため、AWSアカウントに割り当てる予定のIPアドレスを許可します。

その後、エンドポイントを作成するサブネットを選択し、「アウトバウンドエンドポイントの作成」をクリックします。

2．オンプレミスのDNSに問い合わせを行うゾーン名を定義（「ctc-sonoda.co.jp」）

ゾーンを保持しているDNSサーバのIPアドレスを定義
（「sonoda.co.jp」のゾーンを192.168.1.10のサーバが関しているなら、192.168.1.10を記載）

名前
任意ですが、ゾーン名が良いでしょう。
「.」が利用できないので「-」とかを利用しましょう。

名前
転送するゾーン名を記載します。
今回は「ctc-sonoda.co.jp」とします。

このルールを利用するVPC
本アカウントにて利用するVPCを選択します。
マルチアカウントの場合、この利用するVPCを増やしていくことになります。
（他のアカウントの追加方法は後で記載）

アウトバウンドエンドポイント
「1」にて作成したエンドポイントを指定します。

ターゲットIPアドレス
ゾーン（「ctc-sonoda.co.jp」を管理しているDNSサーバ）を管理しているDNSサーバのIPを記載します。
オンプレミス側に複数サーバがある場合、複数のIPを記入します。

「送信」ボタンをクリックするとルールが作成されます。
これで「Route53リゾルバ（アウトバウンド）」の設定が完了です。

Route53 リゾルバって共有したほうがいいの？

こちらもVPCエンドポイントと同様、複数のAWSアカウントがある状況で統制が取れたNWにしようとすると共有は必須かな。と思っています。

また、統制云々はおいて置いたとして、費用面でも共有したほうが良いでしょうか。

具体的な費用は以下の通りです。（東京リージョン。2025年2月時点）

参照：
https://aws.amazon.com/jp/route53/pricing/

ぶっちゃけクエリはほぼ費用が発生しないと思って問題ないので、基本はENIの費用となります。ただ、基本ENIはマルチAZで作るので、

の費用となります。
これも各アカウントに都度Route53リゾルバ（アウトバウンド）を作ると、凄い金額が発生します。

これを複数のアカウントに作るとなるとルールの統一が難しいですし、費用面でも凄い金額になってしまいます。

複数アカウントがある場合は、必ず共有するようにしましょう。

Route53 リゾルバ（アウトバウンド）を共有する

Route53リゾルバ（アウトバウンド）を共有する方法ですが、AWS Resouce AccessManager（以下、RAM）」にて実施が可能です。手順は、以下の通りです。
（共有系は大体がRAMにて実施可能なのですが、VPCエンドポイントやDirectConnect Gateway はRAMでは実施できません。出来るだけ手順は共通化して欲しいところですが、仕方ありません。今後に期待しましょう。）

A．アカウントAでの「リソース共有」

まずはRAMにアクセスし、「リソース」にて「リゾルバルール」を選択します。

作成したRoute53リゾルバ（アウトバウンド）が出力されるので、チェックを入れ、次へをクリックします。

「全てのユーザとの共有を許可」をクリックし、プリンシパルに「AWSアカウント」を選択。
共有したいアカウントID（アカウントBのID）を記入し、「追加」をクリック。

「次へ」で次の画面に移動し、「リソース共有を作成」をクリックすることでリソース共有が実施されます。

共有が出来るとこんな感じで、「リソース共有が正常に作成されました。」と出力されます。

B．共有を受けるアカウント（アカウントB）にて、「リソース共有を承認」

続けて、アカウントBで「リソース共有を承認」します。

アカウントBのRAMにアクセスし、左タグの「リソースの共有」の所に、共有をリクエストしたリソースが　「保留中」のステータスにて存在します。

対象の名前をクリックし、「リソース共有を承認」を押下することで「リソース共有を承認」が完了します。

C．共有を受けるアカウント（アカウントB）にて「ルール」に自身のVPCを追加

最後にroute53 リゾルバーのルールにて、アカウントBのVPCを追加します。

この作業は共有された側（アカウントB）から実施可能です。

route53の画面を表示し、下の画像のように「リゾルバー」のルールをクリックすると、共有を承認した「リゾルバルール」が出力されます。

名前（画像はマスクしています）をクリックとルールの詳細が閲覧可能です。

ルール画面にて「VPCを関連付ける」をクリック

本作業で、作成したルールに対し、アカウントBのVPCの紐付けが完了となります。

なお、このA、B、Cの作業については、ルール毎に実施する必要があります。
転送するドメインルールが複数ある場合は、複数回作業を実施ください。

大規模なAWS NWを設計する際のポイント

最後に、大規模なAWS NWを設計する際のポイントを記載します。復習っぽくなりますが、この辺を抑えておけばOKでしょう。

■AWS NW設計のポイント①　IPをバッティングさせない

NW設計のポイントですが、ともかく「IPアドレスは被ってはいけない」。これだけです。

IPv6はもともと被らないことを前提にしていますが、IPv4でも被ってはいけません。
オンプレミスの場合は無理やりNATしていた方も多いと思いますが、NWがややこしくなるだけでよいことは基本何1つありません。（もちろん、グローバルからのアクセスについては、NATによりIP隠ぺい等のメリットがあります）

そもそもNWはつながって初めてメリットがあるものです。繋がらない原因となるIPかぶりは絶対にやめましょう。

という訳で、ともかく最初にやるべきことは、お客様にAWSで利用する「IPアドレスレンジ」を払い出してもらう事です。
とりあえず、「10.x.0.0/16」とかを確保できれば安心ですね。
1つのVPCに「/24」使った場合でもVPCを256個作成できます。

「/23」で使っても128個のVPCを作成できるので、当面は安心です。

■AWS NW設計のポイント②　AWSの設計は大体一緒にしておく

NWの設計は、ポイント・ポイントではなく全体的に整合性が取れた設計にしておく必要があります。（そうしないと、全体的によくわからない形になるため）。

なので、基本は大体一緒（「ハンコ」、もしくは「金太郎あめ」）にしておくのがセオリーです。

AWSの場合であれば、サブネットは「/25」 or 「/26」。VPCのアドレスは、「/23」みたいな感じで定義しておきましょう。
定義しておけばその中で頑張ってやりくりするものです。

なお、VPC間はTransit Gatewayを使うケースが多いかと思いますが、この場合は念のためTransit Gateway用のサブネットを作りましょう。

「/28」で十分です。また、Transit Gatewayのアドレスに直接接続することはありませんので、VPCに割り当てた「/23」のアドレスから払い出ししなくてOKです。 適当にTransit Gatewayセグメントを「/24」単位で確保して、その中から割り当ててしまいましょう。 IPは貴重なので無駄にしてはいけません。 （Transit Gateway利用時のNW構成は大規模なAWS NWを管理する（VPCエンドポイント、Route53の共有）（1）を参照ください。）

※Transt Gateway用サブネットはTranst Gatewayでルーティングを制御する必要が無い時は不要なのですが、AWSのベストプラクティスがセグメントを設ける形になっていること。および将来的な拡張を見越して一応分けておきましょう。

しつこいですが、ともかくNWは「ハンコ」にしておくことが重要です。
NWを払い出す際に都度検討してはいけません。

■AWS NW設計のポイント③　VPCエンドポイントは統合しておく

大規模なAWS NWを管理する（VPCエンドポイント、Route53の共有）（1）
にて記載している通りです。

エンドポイントを共有することで、AWSアカウントにも意味を持たせると良いですね。
（共有機能提供アカウント、個別アカウントなど。）

■AWS NW設計のポイント④　DNSで名前を引けるようにしておく

本記事にて記載の通り、Route53リゾルバ（アウトバウンド）にてオンプレミスの名前を引けるようにしておきましょう。
また、共有も実施しておきましょう。

VPCエンドポイントと同様、共有機能提供アカウントにRoute53リゾルバを持たせると良いでしょう。（名称は何でも良い）

■おまけ　各クラウドを含めたAWS NWの全体設計

以下のようにAWSをNWの中心として、Transit GatewayからAzureやGCPと接続することも可能です。

Transit Gatewayを利用することで他のクラウドとも結構簡単にNWの統合（？）が可能となります。

この場合、AWSがNWの中心になってしまうため、NW設計における好みが反映されるところですね。（特定のベンダーを中心にしたくない、という場合は難しいかなと思います。）

大規模なAWS NWを管理する（VPCエンドポイント、Route53の共有）のまとめ

今回は大規模AWS NWを管理するためRoute53リゾルバ（アウトバウンド）の共有と、大規模なNWを設計する際のポイントでした。

NWは一度作ってしまうと中々変更が難しいので最初から今後を見据えて設計をしたいものです。
大規模なAWS NWを設計する際のポイントでも記載していますが、NWは「ハンコ」にしておくのが良いです。全体設計でパワーポイント1ページに収まらないNWにしてしまうと碌なことが起こりません。（持論ですが、設計書をぱっと見て頭にすっと入ってくるような設計でないと、運用はきちんとまわりません。）

ＮＷ部分、特に設計についてはとっつきにくい箇所かと思いますが本記事が少しでもお役に立てれば幸いです。
NW設計大好き人間がクラウド環境で増えますように。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。