【AWS】AWS通信サービスをシンプルに体系的に整理
はじめに
AWS を学んでいると、リソース間通信・VPC 間通信・オンプレミスとの接続など、"通信に関するサービス"がとても多いことに気づきます.
- VPC Peering（VPCピアリング）
- Transit Gateway
- PrivateLink
- Direct Connect
- Site-to-Site VPN
- Client VPN（クライアントVPC）
- NAT Gateway / Internet Gateway
- API Gateway
- App Mesh
など、目的や利用シーンによって異なる選択肢が多数存在します。
最初は「どれが何のためにあるのか？」「どれとどれが競合サービスなの？」と混乱しがちです。
そこで本記事では、AWS の通信系サービスを体系的に整理し、それぞれがどんな課題を解決するために存在するのかをまとめます。自分自身の学習のアウトプットも兼ねていますが、同じように混乱している方の助けになれば幸いです。
AWS通信サービスが多い理由
AWS の通信サービスが多い理由は一言で言うと、ユースケースが多様化し、それぞれに最適化されたサービスを提供するためです。
1. マイクロサービス時代に対応するため
モノリシックなアプリケーションでは通信経路はシンプルでしたが、マイクロサービスアーキテクチャでは、
- マイクロサービス間通信
- 共通基盤との通信
- 異なる VPC に分散したサービス連携
など、通信パターンが爆発的に増えます。
それに応じて AWS も、様々な要件に最適化された通信手段を提供する必要があるため、サービス数が増えています。
2. セキュリティ要件の高度化
パブリック通信ではなく、
- 内部ネットワークのみで通信したい
- SaaS をプライベートに利用したい
- ゼロトラストなアクセス管理を実現したい
など、細かな制御が必要とされるようになりました。
これにより、PrivateLink や VPC エンドポイントなどの新しい仕組みが増えています。
3. オンプレミスとの接続パターンが多様
企業によってはオンプレミス環境と組み合わせるハイブリッド構成が必要で、
- 高速・低遅延なら Direct Connect
- 暫定利用なら Site-to-Site VPN
- クライアント接続なら Client VPN
と、目的ごとに使い分ける必要があります。
各サービスの位置づけを理解する
AWS の通信サービスは目的ごとに大きく4つのカテゴリに分類できます。本セクションでは、それぞれのサービスが 「何を解決するためのものなのか」 を軸に整理します。
1. VPC 間の通信を実現するサービス
主に AWS 内部でのネットワーク通信（L3） を制御する仕組みです。
L3レイヤで通信できるため：
- 双方向通信
- 全サブネットへのルーティング
- ICMP/Ping
- SSH/RDP
- 相手VPC内の任意IPへのアクセス
これらをしたい場合は、VPCピアリングまたは**Transit Gateway(TGW)**が適切です。
VPCピアリング
- 1対１でVPC同士を接続するサービス
- シンプル・低レイテンシ・低コスト
- ただし、メッシュ構造になると管理が複雑
向いているシーン
- 少数（2〜4個程度）のVPCを相互接続
- 単純で管理しやすい構成を取りたい
- 一部のシステム間だけ双方向通信したい
Transit Gateway(TGW)
- 複数のVPCをハブ&スポークモデルで接続
- オンプレミスとも集中的に接続できる
- 大規模ネットワークの標準解
向いているシーン
- VPCが10個以上ある
- オンプレミスとの通信
- マルチアカウント / マルチ組織（“管理アカウントで作成することで各アカウントとの中央ハブとなり、管理者は接続ポリシーを一元管理できる）
- マルチリージョンをまとめたい(TGW 自体は リージョン単位 で存在するが、TGW 間を Transit Gateway Peering で接続できるため。)
2. AWS サービス・SaaS とのプライベート通信
インターネットを使わずにサービスへ接続したい場合の選択肢になります。
以下のサービスを使うことで、
VPC 内のリソース（EC2, Lambda, ECSなど）が、VPC の外にある AWS サービス（S3, DynamoDB, API Gateway, SaaS など）へインターネットを使わずに（IGW/NATなしで）AWSの内部ネットワークで直接通信できます。
VPC Endpoint
- AWS サービス (S3, DynamoDB など) や一部 SaaS にプライベート接続
- NAT Gateway や Internet Gateway を不要にする
向いているシーン
- セキュアに AWS サービスへアクセスしたい
- プライベート環境から外へ出たくない
実は、AWS の VPC Endpoint は2種類あります。
| 種類 | 対象サービス | 特徴 |
|---|---|---|
| Gateway Endpoint | S3, DynamoDB 専用 | ルートテーブルに経路を追加するタイプ。無料。 |
| Interface Endpoint（= PrivateLink） | ほぼ全ての AWS サービス、SaaS | ENI（Elastic Network Interface）で接続。Time-based課金あり。 |
| ※ PrivateLinkの実態は、AWS内部に存在するENI（ネットワークインターフェース(NIC)）で、VPC内でIP・MACアドレスを持ち通信 |
Gateway Endpointは、S3 / DynamoDB 専用で、VPC内 から、VPC外にある S3/DynamoDB にルートテーブル経由で接続します。インターネット不要（NAT/IGW不要）で、 Endpoint により AWS内部ネットワークで接続できます。
一方、Interface Endpoint（PrivateLink）は、VPC内 → AWSサービス / 他VPCのサービス / SaaSにENI（プライベートIP）経由で通信します。こちらもインターネット不要（NAT/IGW不要）です。
代表例として、
- Publisherとして公開しているAWSのネイティブサービス(SSM, EC2 API, CloudWatch Logs、API Gateway)
- Publisherとして公開している自社アカウントのVPC内のサービス
-
サードパーティのSaaS（Snowflakeなど、AWS（やAzure/GCP）上に構築されて動いているサービス）
は、Interface Endpoint(= PrivateLink)を使用することで接続します。
注意として、VPC Endpointは、インターネット上の外部には行けません。
そのため、例えば
- Google API
- Github
- Stripe API
- 自社オンプレのAPI
には、Endpoint経由では行けず、NAT/IGW や VPN等が必要となります。
「VPC Peering」「Transit Gateway（TGW）」との違いは？
PrivateLink（Interface Endpoint）と、「VPC Peering」「Transit Gateway（TGW）」は、は「VPC 間通信に使える」という点だけ見ると似ていますよね。僕はそう思いました。しかし、本質的には全く異なる性質を持つサービスです。
違いとしては、
- VPC Peering / TGW は “ネットワーク層（L3）で VPC と VPC をつなぐもの”
- PrivateLink は **“L4（TCP）レベルの中継機構“**で、特定サービス（NLB背後のアプリ）への TCP 通信だけを中継する
という点にあります。
そのため、
- 双方向通信
- 全サブネットへのルーティング
- ICMP/Ping
- SSH/RDP
- 相手のVPC全体にアクセス
といった “IPパケットを自由に配送する必要がある通信” は、L3接続である Peering や TGW では可能なものの、PrivateLink では不可能です。
PrivateLinkでは、Consumer VPC → Provider VPC の “特定サービス” に対して任意の TCP ポートを公開することで、TCP ベースの L4 通信 を中継します。
構造は以下の通りです。
Consumer VPC 内の Interface Endpoint → PrivateLink → Provider **NLB(L4としてTCP/UDP レベルの処理を実施)**
例えばHTTPSとしてL7のサービスに接続するときでも
HTTPS は L4 の TCP(443) の上に載った暗号化データであるため、
PrivateLink はL7の内容を一切理解しません。
そのため、HTTPS 以外にも以下のような TCP ベースの通信プロトコルは問題なく通ります：
- 443 (HTTPSアプリケーション層プロトコルでよく使われるTCP番号)
- 3306 (MySQLアプリケーション層プロトコルでよく使われるTCP番号)
- 5432 (PostgreSQLアプリケーション層プロトコルでよく使われるTCP番号)
- 22 (SSHアプリケーション層プロトコルでよく使われるTCP番号)
※ ポート番号はL4（TCP/UDP）の概念であり、L7(アプリケーション層)プロトコルを識別するための目印であり、それ自体が L7 プロトコルと1対１対応するわけではない。あくまでプロトコルの識別は目安として使われるだけであり、本当のポート番号の目的は1つのIPアドレスや単一のプロトコル(言語)で複数のアプリケーション(プログラム)を使用できるようにすること。
しかし中継できるのは「NLB(L4)背後の特定サービス」に限定され、
相手VPC内部の任意IPにアクセスすることはできません。また、TCP ベースに限り、UDPベースのプロトコルは通らないことにも注意が必要です。
このとき、相手VPC内の任意IPや任意ホストに接続することはできません。
また、Provider 側からは、(Consumer の VPC Endpoint ID（＝vpce-xxxx。これでConsumer側は、誰(どの顧客か)を識別する）やEndpoint ENI のプライベートIP(代理IP) は Provider 側のNLBのアクセスログに記録されますが、)、Consumer側の 元IP（プライベートIP）や内部ネットワーク構造(CIDR）は絶対に見えないです。これがPrivateLinkの、「VPCをつなぐのではなく、サービスの入口（NLB）だけを公開する技術」の本質で、Providerの内部ネットワークは一切見えないためセキュリティが非常に高いというメリットを享受することができます。
一方、VPC PeeringやTGWは、は **VPCルートテーブルにIP経路を追加してネットワークを“接続”**します。
宛先:10.2.0.0/16 → VPC PeeringやTGW
これにより、Ping（ICMPプロトコルで接続）やSSH（相手VPC内のIPアドレスに'ssh 10.1.0.2'のような形で接続）、RDP、双方向通信などの完全なL3レベルの通信が可能になります。
PrivateLinkは TCP ベースの L4 通信 を中継する仕組みで、ネットワーク接続(L3)とは別物です。
3. インターネットを介した通信（外部アクセス）
AWS → インターネット、または外部から AWS へのアクセスを制御する代表的サービス
Internet Gateway（IGW）
- VPC からインターネットへ出るためのゲートウェイ
- パブリックサブネットで必須
NAT Gateway
- プライベートサブネットのインスタンスが、インターネットへ出るための仕組み
- その際、**送信元IP を変換（Private → Public）**してくれる、ITアドレス変換ゲートウェイとして機能
- 外部からの通信は許可しない（アウトバウンド専用）
向いているシーン
- EC2 が外部 API にアクセスしたい
- パッチ適用・外部リポジトリの利用
4. オンプレミスと AWS を接続するサービス
ハイブリッド環境構築に欠かせない通信手段
Site-to-Site VPN
- 手軽・低コストでオンプレとAWSを接続
- インターネット経由なので遅延が安定しないことも
向いているシーン
- まずは暫定でオンプレ接続したい
- あまりお金をかけたくない小規模なハイブリット環境
AWS Direct Connect
- 物理専用線でオンプレとAWSを接続
- 安定・高速・低遅延
- 大規模環境で標準的に利用
向いているシーン
- クリティカルな基幹システムをクラウドと接続
- 帯域が大きく、VPN だと足りない
Client VPN
- クライアント端末（PCなど）が VPC へ直接接続
- リモートワーク用途にも利用されるAWS のフルマネージド SSL-VPN サービス
向いているシーン
- 社員が VPC 内のプライベートIPへアクセスしたい場合
- Bastion（踏み台）を廃止し、より安全な構成にしたい場合
- オンプレのPCから AWS VPC に “社内LANのように” 接続したい場合
また、Client VPNは OpenVPN互換プロトコルを使用しており、OpenVPN クライアントで接続可能です。
OpenVPN との違い
OpenVPN などのオープンソース VPN ソフトウェアを使って、EC2 上に VPN サーバーを構築することも可能ですが、以下のような点はすべて “自前で管理” になります。
- サーバーのパッチ管理／セキュリティ管理
- 証明書・ユーザ管理
- スケールさせる際のオートスケーリング設計
- 冗長化・可用性確保
- 障害監視・ログ管理
特に大規模接続になると、単一EC2がボトルネックとなりやすく、負荷管理が難しくなります。
一方、Client VPN は AWS がこれらをすべてマネージドで提供するため、管理負担を大幅に減らしたい場合は Client VPN が最適です。
5. アプリケーションレベルで通信を仲介するサービス
ネットワークレイヤ(L3)やトランスポートレイヤ(L4)ではなく、アプリケーションレイヤ(L7)の通信を扱う種類です。
L7では通信の**"内容（HTTPメソッド、URL、Headerなど）"を理解できる**ため、より高度なルーティング、認証、可観測性が可能になります。
API Gateway
L7のサービスです。
理解できる情報として
- HTTP メソッド（GET / POST / PUT / DELETE…）
- URL / パス（/users /items/1 …）
- クエリパラメータ（?page=1）
- ヘッダ（Authorization, Content-Type …）
- ボディ（JSON/XML）
- JWT の中身（claims）
- Hostヘッダ
- HTTPステータスコード
といった、L7にしか存在しない情報を理解することが可能です。
これが可能だからこそ：
/users → Lambda A
/orders → Lambda B
といった、URLベースのルーティング、
- 認証(Cognite JWT検証やIAM認証、Lambda Authorizer)
- リクエスト・レスポンス変換（API GatewayのREST API利用時のMapping Template）
- レート制限として、L7単位でのスロットリング
-
HTTPプロトコル由来のCORS処理
※ REST API（旧世代・高機能）と HTTP API（新世代・高速・安価）の2種類があり、Mapping TemplateはREST API利用時の機能となります。
といったL7 の高度な制御が可能になります。
向いているシーンとしては、
- サーバレスアーキテクチャ（API中心）
- フロントエンド→バックエンド間通信をセキュアにしたい
- APIをバージョニング・認証・スロットリングしたい
あたりです。
App Mesh（2026年9月30日にサービし終了予定）
マイクロサービス間の通信を制御するサービスメッシュ。
gRPCやHTTPなどのL7通信を可観測化し、リトライ・タイムアウト・トラフィック制御を統合管理するサービスです。
終わりに
概要を見てみたものの、感覚10個くらいあるのではないかな。
1個に統一してくれたいいけど、それだったら「モノシリックだ」ということでSOAやマイクロサービスアーキテクチャのAWSの設計思想に反するよなぁ。。
マイクロサービスは拡張性や柔軟性で非常に便利なものの、ユーザが使用できるツールの選択肢が増えるという意味では覚えることが複雑になり、ユーザに求められる知識が増えて大変になるなと思いました。
ただ、"ちゃんとそれぞれのサービスの仕組みや特徴を覚えたら"、本当にいいシステムがモノシリックサービスよりも安価に、しかも拡張性高く使えるようになるので、これからもちゃんと勉強しよう、と私自身心の中で思う今日この頃でした。
参考（AWS公式）
Discussion