AWSネットワークの基本と設計ポイントをわかりやすく解説

はじめに

概要

この文書は、AWSで安全かつ効率的なネットワークを設計・構築するための全体像をやさしく解説します。基本概念からVPC設計、可用性の考慮、ルーティング、DHCP/DNS/NTPの構成、インターネット接続、IPv6対応までを順に扱います。

目的

読み手が実務で使える設計の考え方と注意点を身につけることを目的とします。具体例を交えて、設計判断がしやすいように説明します。

対象読者

クラウド初心者から中級者のネットワーク担当者や、設計方針を学びたい開発者を想定しています。専門用語は必要最小限に留め、初学者でも理解できる表現を心がけます。

本書の使い方

各章は独立して参照できますが、順に読むことで設計の流れをつかめます。実際の操作や図解を併用すると理解が早まります。顔の見える合同作業やレビューを行い、設計意図を共有してください。

AWSネットワークの基本概念と重要性

概要

AWSではAmazon VPCでプライベートな仮想ネットワークを作ります。VPCは自分専用のネットワーク空間で、サブネット、ルート、セキュリティ設定を組み合わせて構成します。ブラウザやCLIで迅速に設定できる点が特徴です。

VPCとは（具体例付き）

VPCは屋内に置く「建物」に例えられます。建物に部屋（サブネット）を作り、部屋ごとに入退室ルールを決めます。たとえば10.0.0.0/16をVPCに割り当て、10.0.1.0/24をWeb用、10.0.2.0/24をDB用にするイメージです。

サブネットとルーティング

サブネットはIPのまとまりで、ルートテーブルで行き先を決めます。パブリックサブネットはインターネットゲートウェイを経由し、プライベートはNATなどで外部通信を行います。

セキュリティの考え方

セキュリティグループはサーバー単位のファイアウォール、ネットワークACLはサブネット単位の簡易フィルタです。両方を組み合わせると層で防御できます。

接続オプションと運用

オンプレミス接続はVPNやDirect Connectを使います。監視はVPCフローログやCloudWatchで行い、通信の可視化とトラブル時の原因特定に役立てます。

なぜ重要か

基礎設計をしっかり作ると運用が楽になります。後から変更すると影響範囲が広くなるため、最初に分かりやすい設計を行うことが重要です。

VPC設計の基本要素

はじめに

VPC設計では、ネットワークの土台をしっかり作ることが重要です。ここでは、主要な要素を分かりやすく説明します。実務でよく使う具体例を交えて解説します。

ネットワークアドレス（CIDR）の設計

CIDRはVPCの住所範囲です。例：10.0.0.0/16は約65,000台分のIPを表します。小さすぎると将来足りなくなり、大きすぎると管理が難しくなります。オンプレミスとつなぐ場合は重複しない範囲を選びます。

サブネット設計（パブリック／プライベート）

サブネットは用途ごとに分けます。外部に公開するサーバーはパブリック、データベースなどはプライベートに配置します。可用性のために複数のアベイラビリティゾーン（AZ）に均等に割り当てます。例：/24を各AZに割り振る方法が一般的です。

ルーティング設計

ルートテーブルで経路を定義します。パブリックサブネットはインターネットゲートウェイ（IGW）へ、プライベートはNATや専用接続へ向けます。社内接続や他VPCとの通信は明確な経路で管理します。

DHCP/DNS/NTPの基本設定

AWS提供のサービスを使うと簡単です。必要に応じてカスタムDHCPオプションでDNSサーバーやNTPサーバーを指定できます。例：オンプレのDNSを使う場合はDHCPで指定します。

可用性と拡張性の考え方

各AZにリソースを分散し、IPアドレスの余裕を持って割り当てます。将来の拡張に備えてCIDRを余裕ある範囲で設計してください。

実装チェックリスト（簡潔）

• CIDRのサイズと重複確認
• パブリック/プライベートの分離
• AZごとのサブネット割当
• ルートとNAT/IGWの設定
• DHCP/DNS/NTPの確認
• セキュリティグループとNACLの基本設定

これらを最初に計画することで、後からの運用がずっと楽になります。

可用性を考慮したアベイラビリティゾーン（AZ）の選択

概要

可用性を高めるには複数のAZにリソースを分散します。一般的に最低2AZで冗長化を確保しますが、負荷分散やデータベースの自動フェイルオーバーを利用する場合は3AZを推奨します。

なぜAZを分けるのか

AZは物理的に分離されたデータセンターの集合です。片方のAZで障害が起きても、別のAZでサービスを継続できます。例えばWebサーバーを2つのAZに置くと、一方が落ちても他方が応答を続けます。

2AZと3AZの使い分け

• 小規模や初期環境：2AZで十分です。コストを抑えつつ基本的な冗長性を確保できます。- ELBやAuroraなどの高可用性サービス：3AZを推奨します。自動フェイルオーバーや分散リードを活かせます。

設計上の注意点

• リージョンごとに使えるAZ数は異なります。事前に確認してください。- サブネットはAZごとに作成し、同じ設計を各AZに展開します。- クロスAZの通信は転送コストと若干の遅延が発生します。コスト設計に組み込んでください。- データレプリケーションは同期/非同期の特性を理解して選びます。

運用のヒント

1. まず2AZで開始し、負荷や要件に応じてAZを追加します。2. フェイルオーバーや障害発生時の動作を定期的にテストします。3. 監視とアラートを各AZで均等に設定します。4. 拡張時はIPアドレス空間やルーティングの影響を確認してください。

以上を踏まえ、可用性とコストのバランスを意識してAZを選択してください。

ネットワークアドレス設計と拡張性

設計方針

将来の拡張を見越して、余裕を持ったネットワーク設計を行います。特にマネージドサービスやAuto Scalingを使うサブネットは、/27（32アドレス）より大きいプレフィックスを推奨します。小さすぎるとIP枯渇で運用に支障が出ます。

AWSのIP予約について

AWSは各サブネットで最初の4つと最後の1つ、合計5アドレスを予約します。たとえば/27は32アドレスで、使えるのは約27個です。設計時はこの点を必ず考慮します。

CIDRサイズの目安（具体例）

• /27：32総数 → 約27利用可（小規模テスト用）
• /26：64総数 → 約59利用可（小規模サービス）
• /24：256総数 → 約251利用可（Auto Scalingやロードバランサで推奨）
• /20以上：複数サブネットや将来的拡張向け（大規模環境）

拡張戦略

1. 初めからVPCを大きめに設計（例：/20や/16）します。2. サブネットに余裕を持たせ、すべてのアドレスを割り当てないようにします。3. 必要ならVPCのセカンダリCIDRを追加して拡張します。4. アドレス割り当て表を作り、用途別（管理系、アプリ系、DB系、共有サービス）に分けます。

注意点

• VPC間のピアリングやVPNで重複があると接続できません。アドレス範囲は組織で統一して管理します。- サービスごとにIP必要数の見積りを行い、余裕（20〜30%推奨）を確保します。- 小さなサブネットに多数のマネージドリソースを置かないようにします。

以上の考え方で、可用性と将来の拡張性を両立したアドレス設計を行います。

ルーティング設計と経路優先度

ルーティング設計の基本

サブネットごとにルートテーブルを作り、役割ごとに明確に分けます。たとえば、パブリックサブネットはデフォルトルートをIGW（インターネットゲートウェイ）へ、プライベートはNATゲートウェイへ向けます。VPC内通信は自動で”local”ルートが作られます。

経路優先度のルール

ルートの優先度はまず最長プレフィックス一致（より狭いネットワークが優先）です。次に、同一プレフィックスであれば静的ルートが動的伝搬ルート（ルート伝搬）より優先されます。BGPを使う場合はAS-PATH（経路に含まれるASの長さ）が短い方を優先します。

実践的な設計例

• Webサーバー（10.0.1.0/24）: ルートテーブルにlocalと0.0.0.0/0→IGW
• アプリ（10.0.2.0/24）: localと0.0.0.0/0→NAT
• オンプレ接続: 明示的にオンプレネットワークへの静的ルートを優先させると障害時の挙動が分かりやすくなります。

運用上の注意

重複プレフィックスを避け、伝搬ルートを使うときはどのリソースが伝搬するか明確にします。BGPではAS-PATHの変化で経路が切替わるため、予期しない経路変更を監視します。

DHCP、DNS、NTPサービスの構成

概要

VPC内のインスタンスは通常、DHCPでIPやドメイン名情報を取得し、AWSが提供するDNSや時刻サービスを使えます。追加サーバーは基本不要です。

DHCP（DHCPオプションセット）

VPCに「DHCPオプションセット」を割り当てて、domain-name、domain-name-servers、ntp-serversなどを指定できます。例：domain-nameは「ec2.internal」や自社ドメインに設定し、domain-name-serversはAmazonProvidedDNSを指定します。

DNS（Route 53 Resolver と AmazonProvidedDNS）

• AmazonProvidedDNS：VPC内の標準DNS。インスタンスから自動で参照します（例：VPCの“+2”アドレス）。
• Route 53 Resolver：オンプレミスとの名前解決にはOutbound/Inboundエンドポイントとフォワーダールールを使います。オンプレミスDNSへ転送する場合はResolverルールを作成してください。

NTP（Amazon Time Sync Service）

AWSは169.254.169.123のAmazon Time Sync Serviceを提供します。インスタンスはこのアドレスを直接参照するか、DHCPオプションでntp-serversを指定して利用します。

ハイブリッド環境の注意点

オンプレ側との同期や名前解決が必要ならResolverエンドポイントやDHCP設定で調整します。セキュリティ上、DNSフォワード先やNTPアクセスの許可を最小限にしてください。

推奨設定（簡潔）

• DHCPオプションセットでdomain-nameとdomain-name-serversを設定
• DNSはまずAmazonProvidedDNSを利用、必要時にRoute 53 Resolverでフォワード
• NTPは169.254.169.123を利用し、追加サーバーは不要

これらでVPC内の基本的な名前解決と時刻同期が安定します。

インターネット接続の設定

概要

VPCをインターネットに接続する基本はインターネットゲートウェイ（IGW）をアタッチすることです。IGWを経由してパブリックIPを持つリソースが外部と通信できます。

IGWの設定

IGWをVPCに関連付けて、パブリックサブネットのルートテーブルに0.0.0.0/0をIGWへ向けるルートを追加します。例：WebサーバーにElastic IPを割り当てて直接やり取りします。

プライベートサブネットとNAT

プライベートサブネットからのアウトバウンド接続はNATゲートウェイ（IPv4）やNATインスタンスで行います。冗長性のために各アベイラビリティゾーン（AZ）にNATを置き、ルートをAZ内のサブネットへ向けます。

IPv6とEgress-Only

IPv6ではEgress-Onlyインターネットゲートウェイを使い、外向きのみ許可します。Egress-OnlyはIPv6アドレスを持つプライベートリソースの外向け通信に適します。

高可用性とスケーリング

NATは単一障害点になりやすいので、複数AZに配置しオートスケーリングや冗長構成を検討してください。コストと可用性のバランスを常に確認します。

運用上の注意

セキュリティグループとネットワークACLでアクセス制御を行い、ログ（VPCフローログ）で通信を監視します。更新時は段階的にルートを切り替えて影響を最小化します。

パブリックとプライベートサブネットのルーティング設定

概要

パブリックサブネットはインターネットゲートウェイ（IGW）を使って外部と通信します。プライベートIPv4はNATゲートウェイで発信を許可し、プライベートIPv6はEgress-Onlyインターネットゲートウェイでのみ発信を行います。EC2インスタンスは原則としてプライベートサブネットに置くことを推奨します。

具体的なルート設定例

• パブリック用ルートテーブル
• 0.0.0.0/0 → IGW（IPv4の全ての発信）

• ::/0 → IGW（パブリックIPv6を割り当てる場合）

• プライベートIPv4用ルートテーブル

• 0.0.0.0/0 → NATゲートウェイ（パブリックサブネット内に配置）

• プライベートIPv6用ルートテーブル

• ::/0 → Egress-Only IGW（IPv6の発信のみ許可）

運用上のポイント

• EC2はプライベートサブネットに配置し、フロントにはパブリックなロードバランサーを置きます。これで直接のインターネット到達を防ぎつつ、外部アクセスを受けられます。
• NATゲートウェイはAZごとに冗長化すると可用性が高まります。コストと可用性のバランスを考えて配置してください。
• セキュリティグループとNACLで不要なアクセスを遮断します。ルートだけでなくフィルタリングも重要です。

注意点

• IPv6でインバウンドも許可したい場合はパブリックIPv6をサブネットに割り当て、パブリックルートに::/0を設定します。プライベートIPv6はEgress-Only IGW経由で外向きのみです。したがって、設計時にアクセス方向を明確にしてください。

IPv6インターネット検査アーキテクチャの設計

背景

IPv6対応の環境では、リソースごとにIPv4/IPv6の扱いが異なります。たとえばプライベートIPv4だけのサーバーはNATゲートウェイ経由でIPv4インターネットに出ます。一方、IPv6アドレスを持つインスタンスはIGWやEgress-Only IGWで直接IPv6に接続できます。検査設計ではこの違いを踏まえます。

設計の要点

• デュアルスタックの確認: 各サブネットでIPv4とIPv6がどう割り当てられているか明示します。例: アプリは両方、DBはIPv4のみ。
• 経路とゲートウェイ: IPv6は::/0をIGWまたはEgress-Only IGWへ向けます。IPv4は0.0.0.0/0をNATへ。
• 変換の準備: IPv6のみのクライアントがIPv4のみの宛先へ行く場合は、NAT64/DNS64やプロキシを用意します。
• ログと可視化: VPCフローログ（IPv6対応）とtcpdumpやCloudWatchでトラフィックを追跡します。

検査手順（実践例）

1) テスト用インスタンスを各サブネットに用意し、IPv6アドレスで疎通確認（ping6, curl -6）。
2) traceroute6で経路を確認し、ルートテーブルとIGWへ到達するか確認。
3) VPCフローログで送受信のIPバージョンとポートを確認。必要ならtcpdumpでパケットレベルを取得。

注意点

• セキュリティグループとネットACLはIPv6ルールを別途設定します。ポリシー忘れで通信が止まることが多いです。
• NATや変換装置は性能とログ出力を確認して設計してください。

これでIPv6の到達性と検査フローを設計できます。現場ごとの要件に合わせて、上記を組み合わせてください。