「EC2 から、オンプレの社内ドメイン（corp.example.jp）の名前が引けません。VPC の DNS サーバーを社内の DNS に向ければ解決しますか」
「プライベートサブネットのサーバーから S3 へ毎晩バックアップを送っていたら、NAT ゲートウェイの料金が S3 の保存料より高くなっていました」
第6回では、VPC の中の設計を見ました。オンプレでは DNS サーバー・専用線・VPN 装置・CDN 事業者がしていたことを、AWS ではサービスの組み合わせで作ります。
第7回では、VPC 内の DNS、VPC エンドポイント、VPC 間とオンプレとの接続、Route 53、CloudFront、Flow Logs を扱い、3 層 Web システムの演習、よくあるつまずき、Azure との対応表で締めくくります。料金・上限は2026年9月時点の値で、料金は東京リージョンの例です。
VPC 内の DNS：Route 53 Resolver
VPC 内のインスタンスは、DHCP（次の節の DHCP オプションセット）で配られる VPC の CIDR＋2 のアドレス（10.0.0.0/16 なら 10.0.0.2。169.254.169.253 でも可）を DNS サーバーとして使います。これが Route 53 Resolver（DHCP オプションセットでの名前は AmazonProvidedDNS。2025年に Route 53 VPC Resolver と改称）で、フルサービスリゾルバーの役割を AWS が提供しています（フルサービスリゾルバーは連載「DNS入門」第3回の「再帰問い合わせと反復問い合わせ」、VPC の DNS は第10回の「VPCのDNS（Route 53 VPC Resolver）」で詳しく扱っています）。
インターネットの名前解決に加え、ip-10-0-1-23.ap-northeast-1.compute.internal のような AWS 内部名や、VPC エンドポイントのプライベート名を解決します。VPC の属性 enableDnsSupport と enableDnsHostnames の両方を有効にしておく必要があり、これを切ると内部名や RDS のエンドポイント解決が壊れます。
プライベートホストゾーンは VPC に関連付ける内部専用のゾーンで、db.corp.internal のような社内名を VPC 内だけで解決させます。オンプレの DNS と相互に名前解決するには Resolver エンドポイントを使い、インバウンド（オンプレ → VPC の名前を引く）とアウトバウンド（VPC → オンプレの corp.example.jp を転送ルールで引く）を VPN／Direct Connect 越しに構成します。これはオンプレの DNS の「条件付きフォワーダー」そのものです（連載「DNS入門」第3回の「条件付きフォワーディング」、第10回の「Resolverエンドポイントと転送ルール」）。
- VPC 内 DNS＝Route 53 Resolver（CIDR＋2）。
enableDnsSupport／enableDnsHostnamesを有効にする - 社内名はプライベートホストゾーン
- オンプレとの相互解決は Resolver エンドポイント＋転送ルール（条件付きフォワーダー）
DHCP オプションセットと VPC エンドポイント
- DHCP オプションセット：VPC 内のインスタンスに配る
domain-name（検索ドメイン）、domain-name-servers（既定AmazonProvidedDNS）、ntp-servers、netbios-name-serversを定義する。VPC に 1 つ関連付ける。IP アドレスそのものは ENI に紐づき固定で、DHCP は「その IP を通知する」役。AD 環境で DNS を AD の DC に向けたいときにこれを差し替えるが、AWS 内部名の解決が壊れるので、DC 側で Resolver へ条件付き転送する構成が一般的 - NTP：Amazon Time Sync Service が
169.254.169.123（IPv6 はfd00:ec2::123）で提供され、AL2023 は既定でこれを使う（連載「NTP入門」第7回の「クラウドの時刻」）。外部 NTP に出す必要はない - VPC エンドポイント：VPC からインターネットを経由せずに AWS サービスへ到達できる
- ゲートウェイ型（S3、DynamoDB のみ）：ルートテーブルにプレフィックスリスト宛のルートを追加する。無料
- インターフェイス型（PrivateLink）：サブネットに ENI（プライベート IP）を作り、サービスの名前解決がその IP に向く（プライベート DNS）。時間＋処理量の課金。SSM、CloudWatch Logs、ECR、KMS など
- プライベートサブネットで「NAT なしで Session Manager と S3 だけ使いたい」なら、S3 ゲートウェイ＋SSM 系インターフェイスエンドポイント 3 つ（ssm、ssmmessages、ec2messages）で足りる
冒頭の1つ目の相談がこれです。DNS を社内の DNS サーバーに向けると、AWS 内部名や RDS の名前が引けなくなります。VPC の DNS は Resolver のままにして、アウトバウンドエンドポイントに corp.example.jp の転送ルールを付けるのが基本です。
冒頭の2つ目の相談もここです。NAT ゲートウェイは処理量に 0.062 USD/GB（第6回）がかかりますが、S3 のゲートウェイ型エンドポイントは無料です。
VPC 間の接続：ピアリングと Transit Gateway
- VPC ピアリング：2 つの VPC を 1:1 で接続する。別リージョン・別アカウントも可能。CIDR が重複していると不可。推移的ルーティングはできない（A–B、B–C を結んでも A–C は通らない）。両側のルートテーブルに相手 CIDR → pcx を追加する。転送料は、同じ AZ の中なら無料、AZ をまたぐと AZ 間と同じ（送信・受信それぞれ 0.01 USD/GB）、リージョンをまたぐとリージョン間の料金
- VPC が増えるとフルメッシュが必要になる（N 個で N(N−1)/2 本。10 VPC で 45 本）
- Transit Gateway（TGW）：リージョン単位のハブ。VPC・VPN・Direct Connect・他リージョンの TGW を「アタッチメント」として接続し、TGW 側のルートテーブルで経路を集中管理する。推移的ルーティングも可能で、数千 VPC まで拡張できる
- TGW の料金：アタッチメントあたり時間課金（約 0.07 USD/h）＋処理量（0.02 USD/GB）（2026年9月時点）。少数 VPC ならピアリングの方が安くなる
- TGW ルートテーブルで分離：本番用と検証用のアタッチメントを別のルートテーブルに置けば、同じ TGW でも相互に通信させない設計ができる（オンプレのルーターの VRF に相当する）
- VPC Lattice（2023）：サービス単位（HTTP）で VPC 越しに接続する新しい選択肢。ネットワーク層でなくアプリ層でつなぐ
オンプレとの接続①：サイト間 VPN
サイト間 VPN は、オンプレのルーター／ファイアウォール（カスタマーゲートウェイ）と AWS 側の仮想プライベートゲートウェイ（VGW）または Transit Gateway の間に、インターネット経由の IPsec トンネルを 2 本張ります。2 本は AWS 側の別 AZ の終端に落ちており、片方が保守で落ちても継続するので、両方を有効にして BGP で経路交換するのが正しい使い方です（静的ルートも可能です）。
トンネル 1 本あたりの帯域は標準で約 1.25 Gbps（Transit Gateway か Cloud WAN に接続する場合は、2025年11月に加わった大容量トンネルで最大 5 Gbps）、IKEv1/v2、AES-256、SHA-2 に対応しています。構築は数時間で、費用は接続あたり約 0.048 USD/h（東京、月 35 USD 程度。大容量トンネルは 0.60 USD/h。2026年9月時点）＋転送料と安いですが、インターネット経由のため遅延と帯域は保証されません。Accelerated VPN は Global Accelerator のエッジで受けて AWS バックボーンに乗せることで品質を改善します。
オンプレ側の機器設定は、コンソールから機種別（Cisco、Fortinet、YAMAHA 等）の設定サンプルをダウンロードできます。Direct Connect（次の節）のバックアップ回線として VPN を併用する構成が、コストと可用性のバランスから最も一般的です。
- IPsec トンネル 2 本、BGP で経路交換。1 本 1.25 Gbps（大容量トンネルは 5 Gbps）
- 数時間で構築、月 35 USD 程度＋転送料。帯域・遅延は非保証
- Direct Connect のバックアップとして併用するのが定番
オンプレとの接続②：Direct Connect
- AWS のネットワークとオンプレを専用線で直結する。インターネットを経由しないため、帯域・遅延が安定し、転送料もインターネット向けより安くなる
- 専有型（Dedicated）：1／10／100／400 Gbps（400 Gbps は一部のロケーションのみ）のポートを AWS から直接。ホスト型（Hosted）：APN パートナー（通信事業者）経由で 50 Mbps〜25 Gbps。国内の多くはホスト型
- 接続先は「Direct Connect ロケーション」（東京・大阪のデータセンター）。自社拠点からロケーションまでの回線は別途契約が必要
- VIF（仮想インターフェイス）：1 本の物理接続を VLAN（802.1Q）で分割する。プライベート VIF（VPC へ）、トランジット VIF（Transit Gateway へ）、パブリック VIF（S3 等のパブリックエンドポイントへ）。経路交換は BGP 必須
- Direct Connect Gateway：1 本の DX から複数リージョン・複数アカウントの VPC へ到達できる
- リードタイムは数週間〜数か月、費用はポート時間課金＋転送料（＋パートナー回線）。単一障害点にしないため 2 本（別ロケーション）か VPN バックアップが必須（AWS の SLA も冗長構成が条件）
- MACsec による物理層暗号化を、10／100／400 Gbps の専有型（一部のロケーション）で選択できる。VPN over DX で IPsec を重ねる構成もある
Route 53
Route 53 は AWS のマネージド DNS で、権威 DNS サーバー（ホストゾーン）、ドメイン登録（レジストラ）、そして VPC 内のリゾルバー（この回の「VPC 内の DNS：Route 53 Resolver」の節）の 3 つの機能を持ちます。名前は DNS のポート 53 に由来します（権威 DNS は連載「DNS入門」第1回の「DNSの3つの登場人物」、レジストラは第2回の「レジストリ・レジストラ・Whois／RDAP」）。
パブリックホストゾーンを作ると 4 つのネームサーバー（異なる TLD の awsdns-xx.com/.net/.org/.co.uk）が割り当てられ、SLA は 100% を謳っています。レコードは A/AAAA/CNAME/MX/TXT/SRV/NS/CAA など標準のものに加え、AWS 独自のエイリアスレコードがあり、ELB・CloudFront・S3・API Gateway・別のレコードを、CNAME では禁止されているゾーン頂点（example.jp そのもの）でも指せます。エイリアスは A レコードとして応答し、クエリ課金もかかりません。
ヘルスチェック（HTTP/TCP の監視、CloudWatch アラーム連動）と組み合わせると、異常なエンドポイントを応答から外す DNS レベルのフェイルオーバーができます。DNSSEC の署名にも対応しており、KMS の鍵で KSK を管理します（DNSSEC と KSK は連載「DNS入門」第9回の「DNSSECの仕組み」「アルゴリズムと鍵の運用」）。ゾーン転送（AXFR）はサポートしないので、オンプレの BIND からの移行はゾーンファイルのインポート機能か API で行います（AXFR は第7回の「ゾーン転送：AXFR・IXFR・NOTIFY」）。
- 権威 DNS＋レジストラ＋リゾルバー。SLA 100%
- エイリアスレコード：ゾーン頂点でも AWS リソースを指せる（A として応答）
- ヘルスチェック連動のフェイルオーバー、DNSSEC 対応。AXFR は非対応
Route 53 のルーティングポリシー
| ポリシー | 動作 | 用途 |
|---|---|---|
| シンプル | 固定の応答（複数値なら順不同で全部返す） | 通常のレコード |
| 加重（Weighted） | 重み（0〜255）に応じた割合で振り分け | カナリアリリース、段階移行 |
| レイテンシー | 問い合わせ元に対して最も遅延の小さいリージョンを返す | マルチリージョンの Web |
| フェイルオーバー | プライマリのヘルスチェック失敗時にセカンダリを返す | アクティブ／スタンバイの DR |
| 地理的位置（Geolocation） | 問い合わせ元の国・大陸で応答を変える | 国別コンテンツ、規制対応 |
| 地理的近接性（Geoproximity） | リソースの位置とバイアス値で振り分け | トラフィックフローで可視化しながら調整 |
| 複数値回答（Multivalue） | 最大 8 件をヘルスチェック済みで返す | 簡易な負荷分散 |
| IP ベース | 問い合わせ元の CIDR で応答を変える | 特定 ISP・拠点向け |
応答を決めているのは問い合わせてきたリゾルバーの IPです（EDNS Client Subnet 対応リゾルバーならクライアントのサブネット）。社内のフォワーダー経由で引くと「社内 DNS の場所」で判定される点は、EDNS の話と直結します（連載「DNS入門」第4回の「EDNS(0)とOPT疑似レコード」、第10回の「エイリアス・ルーティングポリシー・ヘルスチェック」）。TTL の設計（フェイルオーバーで短く、静的で長く）も同様です（第7回の「TTLの設計」）。
CloudFront（CDN）
- 世界数百のエッジロケーションにコンテンツをキャッシュし、利用者に近い場所から配信する CDN。HTTP のキャッシュ制御（
Cache-Control、ETag）がそのまま効く（連載「HTTP入門」第5回の「Cache-Controlの主なディレクティブ」「CDNの仕組み」） - オリジン：S3（OAC で S3 を非公開にしたまま CloudFront だけに読ませる）、ALB、EC2、任意の HTTP サーバー、MediaPackage（ライブ配信。以前のオリジン MediaStore は2025年11月13日に提供を終えた）
- ディストリビューションに、キャッシュ動作（パスパターンごとの TTL・転送するヘッダー／Cookie／クエリ）、証明書（ACM の us-east-1 で発行したものが必要。ACM は第9回と連載「証明書入門」第9回の「ACM（AWS Certificate Manager）」）、WAF、地理制限を設定する
- エッジでの処理：CloudFront Functions（軽量 JS、ヘッダー書き換え・リダイレクト）、Lambda@Edge（本格的な処理）を使える
- 効果：遅延の削減、オリジンの負荷軽減、AWS Shield Standard による DDoS 緩和が無料で付くこと、転送料がリージョンから直接出すより安いこと（CloudFront → インターネットは月 1 TB まで無料。2026年9月時点）など
- 動的コンテンツ（API）でも、TLS 終端をエッジで行い AWS バックボーンでオリジンまで運ぶことで体感速度が改善する
- キャッシュの無効化（Invalidation）はパス単位。バージョン付きファイル名（
app.3f2a.js）で運用する方が確実（連載「HTTP入門」第5回の「キャッシュバスティングと設定の型」）
VPC Flow Logs とネットワークの可観測性
- VPC Flow Logs：ENI・サブネット・VPC 単位で、通過した（または拒否された）フローの 5 タプル・バイト数・ACCEPT/REJECT を記録し、CloudWatch Logs か S3 に出力する。パケットの中身は含まない（NetFlow/IPFIX に相当する。連載「SNMP入門」第10回の「フロー監視とは」「NetFlow・IPFIX・sFlow の比較」）
- 用途：「SG で拒否されているか」の確認（REJECT を検索）、通信の棚卸し、GuardDuty（第9回）の入力
- VPC Reachability Analyzer：送信元と宛先を指定すると、ルート・NACL・SG のどこで止まるかを静的解析できる。実パケットは送らない
- Network Access Analyzer：「インターネットから DB に到達できる経路が無いか」を継続的に検査する
- Traffic Mirroring：ENI のパケットを複製して IDS/IPS へ送る（SPAN／ミラーポート相当）
- CloudWatch の NW メトリクス：ENI の
NetworkIn/Out、NetworkPacketsIn/Out、NAT のErrorPortAllocation（ポート枯渇）、DX のConnectionBpsEgress（CloudWatch は第11回） - パケットキャプチャは EC2 の OS 上で tcpdump／Wireshark を使う。AWS 側の機器で取ることはできない
演習：3 層 Web システムの VPC 設計
- VPC
10.0.0.0/16、AZ は 1a・1c の 2 つ - パブリックサブネット
10.0.0.0/24（1a）、10.0.1.0/24（1c）：ALB、NAT ゲートウェイ×2。ルート0.0.0.0/0 → igw - プライベート AP サブネット
10.0.10.0/24、10.0.11.0/24：ECS/EC2。ルート0.0.0.0/0 → 各 AZ の nat、S3 プレフィックス → ゲートウェイエンドポイント - プライベート DB サブネット
10.0.20.0/24、10.0.21.0/24：RDS マルチ AZ（第10回）。ルートはlocalのみ（外へ出さない） - SG は第6回の「セキュリティグループのルール例（3 層構成）」の 3 つ。NACL はデフォルト
- 運用アクセスは Session Manager（SSM 用インターフェイスエンドポイント）を使う。SSH ポートは開けない
- DNS：
www.example.jp→ Route 53 エイリアス → ALB とする。証明書は ACM を使う（第9回） - 拡張：オンプレ接続は VGW/TGW＋VPN、静的コンテンツは S3＋CloudFront に切り出す
- この構成が「AWS の基本形」であり、CloudFormation／Terraform のサンプルの多くはこの形をしている
ネットワークのよくあるつまずき
- パブリックサブネットに置いたのにつながらないケース → IGW ルート・パブリック IP・SG・OS の FW の 4 点を順に確認する
- NAT ゲートウェイ経由で外から入ろうとするケース → NAT は出口専用。入口は ELB か EIP を使う
- NACL の戻り（エフェメラルポート）を許可し忘れて、片方向だけ通ってしまうケース
- SG の送信元に IP を書き、Auto Scaling で台数が増えて通らなくなるケース → SG 参照にする
- VPC の CIDR がオンプレと重複して、VPN で経路が引けないケース → 設計台帳を最初に作る
- 1 つの AZ の NAT に全サブネットを向けて AZ 障害で全滅し、AZ 間転送料もかかってしまうケース
- S3 への大量転送を NAT 経由で行い、NAT の処理料が S3 の保存料を超えてしまうケース → ゲートウェイエンドポイントを使う
- ELB の IP を DNS に直書きして変わってしまうケース → DNS 名かエイリアスを使う
enableDnsHostnamesを切って RDS のエンドポイントが引けなくなるケース- EIP を確保したまま放置して課金されるケース（2024 年以降は使用中でも課金される）
Azure との対応（ネットワーキング）
| AWS | Azure | 補足 |
|---|---|---|
| VPC | Virtual Network（VNet） | VNet は複数の AZ にまたがる点は同じ。サブネットも AZ をまたぐ（AWS はサブネット＝1 AZ） |
| セキュリティグループ | ネットワークセキュリティグループ（NSG） | NSG はステートフルで許可・拒否・優先度を持ち、サブネットにも NIC にも付けられる。SG と NACL を 1 つにしたもの。SG 参照の代わりに Application Security Group |
| NACL | （相当なし） | NSG をサブネットに付けて代用 |
| IGW | （既定でアウトバウンド可。この既定のアウトバウンドアクセスは廃止の方向で、2026年3月31日より後に出た API の版で作る新しい VNet は、サブネットが既定でプライベート） | パブリック IP リソースを NIC に付ける |
| NAT ゲートウェイ | NAT Gateway | ほぼ同じ |
| VPC ピアリング | VNet ピアリング | 同様に非推移 |
| Transit Gateway | Virtual WAN（仮想ハブ）／Route Server | |
| サイト間 VPN（VGW） | VPN Gateway | |
| Direct Connect | ExpressRoute | 接続事業者経由が主流な点も同じ |
| VPC エンドポイント（PrivateLink） | Private Endpoint／Private Link、サービスエンドポイント | |
| Route 53 | Azure DNS／Private DNS Zone／Traffic Manager（ルーティングポリシー相当） | |
| CloudFront | Azure Front Door／Azure CDN | Front Door は L7 グローバル LB＋CDN＋WAF。Azure CDN Standard from Microsoft（classic）は2027年9月30日に廃止予定で、Front Door の Standard・Premium へ移行する |
| VPC Flow Logs | NSG Flow Logs → VNet Flow Logs | NSG Flow Logs は2025年6月30日から新規に作れず、2027年9月30日に廃止予定 |
| Reachability Analyzer | Network Watcher（接続のトラブルシューティング） |
（Azure の補足のうち、既定のアウトバウンド・Azure CDN・NSG Flow Logs の日付は2026年9月時点の Microsoft Learn の記述です。）
考えてみよう
- 演習の構成で NAT ゲートウェイを置かずに、EC2 から S3 と CloudWatch Logs に書き込み、Session Manager で操作するには、どの VPC エンドポイントが要りますか。費用がかかるのはどれですか。
- 演習の VPC をオンプレ（192.168.0.0/16、社内ドメイン corp.example.jp）とつなぐとき、経路と名前解決のために何を用意し、冗長はどう取りますか。
www.example.jpを東京の ALB に向け、東京が止まったら大阪へ切り替えるには、どのルーティングポリシーを使い、TTL はどう決めますか。
ヒント：1 は「DHCP オプションセットと VPC エンドポイント」、2 は「VPC 内の DNS：Route 53 Resolver」と2つの「オンプレとの接続」、3 は「Route 53 のルーティングポリシー」の節を見直してください。
まとめ
- VPC の DNS は Route 53 Resolver（CIDR＋2）。オンプレとは Resolver エンドポイント＋転送ルールで引き合う
- VPC エンドポイントは S3・DynamoDB 向けのゲートウェイ型が無料、ほかはインターフェイス型（PrivateLink）
- VPC 間はピアリング（非推移）か Transit Gateway（推移可）。オンプレとは Direct Connect を主、サイト間 VPN をバックアップに
- Route 53 はエイリアスでゾーン頂点も AWS リソースを指せ、ルーティングポリシーは問い合わせ元のリゾルバーで判定
- CloudFront は HTTP のキャッシュ制御が効く CDN。証明書は us-east-1
- 通らないときはルートテーブル → NACL → SG → OS。Flow Logs と Reachability Analyzer で確かめる
次回は、IAM とセキュリティの前編として、IAM のユーザー・ロール・ポリシーと評価の順序、ルートユーザーの保護、STS、Identity Center、Directory Service、Organizations と SCP を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）（この記事）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント