--- title: "AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け" url: "https://www.issoh.co.jp/column/details/2805/" published: 2024-06-26 updated: 2026-09-27 categories: ["プラットフォーム"] publisher: "株式会社一創" --- # AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け AWSのネットワーク設計でつまずくのは、個々のサービス名を知らないからではなく、目の前の要件がどの通信経路の話なのかを切り分けられていないからです。VPCの中の話、VPC同士の話、オンプレミスとの話、インターネットとの出入り口の話は、使うコンポーネントも課金の考え方も別物です。この記事は4つの経路ごとに選択肢と判断基準を整理し、どこで方式が切り替わるかを公式仕様の数値で示します。Transit Gateway そのものの仕組みと料金は[AWS Transit Gatewayの解説記事](/tech/details/4263/)で扱っているため、ここでは選び分けの位置づけに絞ります。 ## まとめ：4つの経路と選び分けの結論 | 通信経路 | 主な選択肢 | 切り替わる目安 | | ------- | ---------------------------------------- | -------------------------- | | VPC内 | セキュリティグループ / ネットワークACL | 原則SG。ACLは面の遮断のみ | | VPC間 | VPC Peering / Transit Gateway | 数個ならPeering。出口集約でTGW | | オンプレミス | Site-to-Site VPN / Direct Connect | 1.25 Gbps超ならDirect Connect | | インターネット | インターネットゲートウェイ / NAT Gateway / VPCエンドポイント | S3・DynamoDB宛はゲートウェイエンドポイント | 4つのうちどれを選んでも、後から取り返しがつかないのはCIDR設計だけです。方式は入れ替えられますが、重複したアドレス空間はどの接続方式でも救えません。最終セクションで先に押さえるべき制約をまとめています。 ## VPC内の通信：セキュリティグループとネットワークACLの役割分担 同一VPC内のEC2インスタンス同士は、ルートテーブルに自動追加されるlocalルートで最初から到達可能です。したがって設計で決めるのは経路ではなく、どこで通信を絞るかだけになります。 セキュリティグループはインスタンス（正確にはENI）単位で、ステートフルに動きます。インバウンドで許可した通信の戻りは自動的に通るため、戻り方向のルールを書く必要がありません。書けるのは許可ルールだけです。同一リージョン内であれば、送信元に別のセキュリティグループIDを指定できるので、IPアドレスではなく役割で許可関係を表現できます。 ネットワークACLはサブネット単位で、ステートレスです。戻りの通信も明示的に許可しなければ落ちるため、エフェメラルポートの範囲まで書く必要があります。その代わりに書けるのが拒否ルールです。 役割分担の結論ははっきりしています。通常の許可設計はセキュリティグループだけで組み、ネットワークACLは特定のCIDRを面で遮断したい場合に限って使ってください。両方に同じ意図のルールを二重に書くと、通信断の原因を切り分けるコストだけが増えます。VPC全体でパブリックアクセスを封じたい場合は、ルールを積み増すより[Amazon VPC Block Public Access](/tech/details/4396/)のようなアカウント側の統制で止めるほうが確実です。 ## VPC間の通信：VPC Peeringで足りる規模と、足りなくなる境目 VPC Peeringは2つのVPCを1対1で結ぶ機能です。1つのVPCから複数のPeeringを張れますが、AWS公式が明記しているとおり推移的ピアリングはサポートされません。VPC AがBともCともピアリングしていても、Aを中継してB・C間の通信を流すことはできず、B・C間を通したければ別途Peeringを張る必要があります。 この「中継できない」という性質は、経路だけの話にとどまりません。エッジ間ルーティングの制約として、ピア先のVPCが持つインターネットゲートウェイ、NATデバイス、VPN接続、Direct Connect接続、ゲートウェイエンドポイントは、いずれも自分のVPCからは利用できません。共有サービス用のVPCにNAT Gatewayを1つ置いて全社で使い回す、といった設計はPeeringでは成立しないということです。 規模の境目はここで決まります。VPCの数だけを見れば、全結合に必要な接続数は4つで6本、6つで15本と増えていくので運用が重くなるのは確かですが、より早く効いてくるのは共有の出口や社内回線を1か所に集約したくなった瞬間です。この時点でハブ型が必要になり、選択肢は[Transit Gatewayによるハブ＆スポーク構成](/tech/details/4263/)に移ります。 ハブ型に移った後の構築作業は、[Transit Gatewayクロスアカウント構築手順｜TerraformとRAM共有](https://www.issoh.co.jp/tech/details/17694/)でTerraformコードとともに扱っています。 ## オンプレミスとの接続：Site-to-Site VPNとDirect Connectの選び分け 判断材料になる数値はAWSが公開しています。Site-to-Site VPNの帯域は標準トンネル1本あたり最大1.25 Gbps、パケット数で140,000 ppsが上限です。より広い帯域向けの大帯域トンネルで最大5 Gbps・400,000 pps、VPN Concentrator経由のトンネルは最大100 Mbps・10,000 ppsとされています。 1本で足りなければ、Transit Gateway上のVPN接続に限りECMPで複数トンネルを束ねて帯域を上げられます。ただし条件があり、動的ルーティング構成が必須で、静的ルーティングのVPN接続ではECMPは使えません。 帯域以外にVPNで見落とされやすいのがフレームサイズです。Site-to-Site VPNのMTUは1446バイト、対応するMSSは1406バイトで、ジャンボフレームには対応せず、Path MTU Discoveryもサポートされません。大容量のデータ転送やバックアップ経路として使う場合、この上限が実効スループットを左右します。 もう一つの壁がルート数です。仮想プライベートゲートウェイ上のVPN接続では、カスタマーゲートウェイから広告できる動的ルートが100本に固定されており、この値は引き上げられません。Transit Gateway上のVPN接続なら1,000本まで広告できます。オンプレミス側の経路数が多い環境でこの制限に当たる仕組みは、[Direct Connectの「100ルート問題」の解説](/tech/details/4648/)で扱っている考え方と同じです。 帯域が恒常的に1.25 Gbpsを超える、通信品質を回線として保証したい、といった条件が出てきたらDirect Connectの検討に移ります。回線調達のリードタイムや費用構造を含めた導入判断は[AWS Direct Connectの導入判断の記事](/tech/details/15476/)を参照してください。 ## インターネットとの出入り口：IGW・NAT Gateway・VPCエンドポイント パブリックサブネットからの双方向通信はインターネットゲートウェイが担い、プライベートサブネットから外向きだけ通したい場合はNAT Gatewayを置きます。NAT Gatewayは時間課金とデータ処理料の2本立てで、通した分だけ費用が積み上がる構造です。 宛先がS3かDynamoDBに限られるなら、答えは別です。この2サービスだけはゲートウェイエンドポイントに対応しており、AWS公式は「There is no additional charge for using gateway endpoints.」と追加料金が発生しないことを明記しています。他のVPCエンドポイントと違ってPrivateLinkを使わない仕組みで、ルートテーブルにはプレフィックスリスト宛のルートが自動で入る点も異なります。 ここで挙動をひとつ押さえておいてください。ルート選択は最長プレフィックス一致で行われるため、0.0.0.0/0をインターネットゲートウェイに向けるルートが存在していても、同一リージョンのS3宛の通信はエンドポイント側のルートが優先されます。逆に別リージョンのS3宛はプレフィックスリストの対象外なので、インターネットゲートウェイ側へ抜けます。クロスリージョンでS3を参照している構成では、エンドポイントを作っただけでは通信経路が想定どおりにならないということです。NAT Gatewayとエンドポイントのコスト比較は[VPCエンドポイントでNATゲートウェイを使わない理由の記事](/tech/details/2326/)で数値を追っています。 ## 接続方式より先に決めるべきCIDR設計 ここまで挙げた方式は、要件が変われば後から入れ替えられます。入れ替えが効かないのがアドレス設計です。AWS公式ドキュメントは、既存CIDRブロックのサイズは拡大も縮小もできないと明記しており、VPC作成時に指定したプライマリCIDRは関連付けを解除することすらできません。後から足せるのはセカンダリCIDRだけで、サイズは/16から/28の範囲に限られます。 そのセカンダリCIDRにも、あまり知られていない制約があります。既にVPCが10.0.0.0/8のレンジを使っている場合、172.16.0.0/12や192.168.0.0/16といった他のRFC 1918レンジからCIDRを追加することはできません。最初に選んだプライベートアドレスのレンジに、そのVPCは事実上縛られます。あわせて172.17.0.0/16は避けてください。AWS Cloud9やAmazon SageMaker AIがこのレンジを使うため、IPアドレスの競合が起きるとAWS自身が注意喚起しています。 接続方式との関係で決定的なのは重複の扱いです。VPC Peeringは、IPv4でもIPv6でもCIDRが一致または重複するVPC間では作成できません。複数のCIDRを持つVPCでは、そのうち1つでも重なっていれば、重ならない側だけを使うつもりであっても作成が拒否されます。Direct Connectゲートウェイに複数のVPCを関連付ける場合も同様に、関連付けるVPC群のCIDRが重複していてはいけません。 したがって、順序を逆にしてはいけません。「とりあえずVPCを作って、繋ぎたくなったらTransit Gatewayを入れる」という進め方は、アドレスが重複していた時点で破綻します。重複CIDRを救う接続方式は存在せず、残る選択肢はVPCの作り直しかNATによる変換だけです。VPCを1つ作る前に、部門・環境・リージョンの割り当てを決めたアドレス台帳を用意してください。この工程を省いた分のコストは、統合の局面でまとめて返ってきます。 ## よくある質問 ### Transit GatewayとVPC Peeringはどちらを選ぶべきですか？ 接続するVPCが数個で、共有の出口や社内回線を集約する予定がないならVPC Peeringで十分です。共有NAT Gatewayやオンプレミス回線を複数VPCで使い回したい場合は、Peeringのエッジ間ルーティング制約で実現できないため、Transit Gatewayが必要になります。料金体系を含めた比較は[Transit Gatewayの解説記事](/tech/details/4263/)を参照してください。 ### VPC Peeringで3つ以上のVPCを相互接続できますか？ できますが、全ペア間にPeeringを個別に張る必要があります。推移的ピアリングはサポートされないため、VPC AがBともCともピアリングしていても、Aを中継してB・C間の通信を流すことはできません。 ### Site-to-Site VPNの帯域が1.25 Gbpsで足りない場合はどうしますか？ 3つの方向があります。Transit Gateway上のVPN接続にしてECMPで複数トンネルを束ねる（動的ルーティング構成が条件）、最大5 Gbpsの大帯域トンネルを使う、Direct Connectへ移行する、のいずれかです。恒常的に超過するならDirect Connectが本筋です。 ### ゲートウェイエンドポイントに料金はかかりますか？ かかりません。AWS公式は追加料金が発生しないと明記しています。ただし対象はS3とDynamoDBの2サービスのみで、他のサービスへプライベート接続する場合はインターフェイスエンドポイントとなり、こちらは課金対象です。 ### VPCのCIDRは後から変更できますか？ 既存CIDRブロックのサイズ変更はできず、VPC作成時のプライマリCIDRは解除もできません。追加できるのは/16から/28のセカンダリCIDRだけで、それも既存CIDRと同じRFC 1918レンジ内に限られる制約があります。 ## 関連記事 - [AWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説](/tech/details/4263/) - [AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】](/tech/details/15476/) - [AWS Direct Connectの「100ルート問題」とは何か、その基本を解説](/tech/details/4648/) - [AWS VPCエンドポイントを使い、NATゲートウェイを使用しない理由とは？](/tech/details/2326/) - [Amazon VPC Block Public Accessとは何か？その背景と重要性](/tech/details/4396/) --- 出典: [AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け]()（株式会社一創）