はじめに
GMOコネクトの永田です。
公共系の案件で「ゲートウェイ（ALB）までは暗号化されているけど、その内側、VPCの中は平文ですよね。それで問題ないんですか？」と指摘されました。
VPCがSDN（Software Defined Network）でできていて、他人の通信を覗くような盗聴が非常に困難なことは、以前から知ってはいました。ただ、いざ「なぜ大丈夫と言えるのか」を根拠立てて説明しようとすると、正確な一次情報がどこにあるのかを即答できず、VPC encryption controlsのような最近の動向も追えていませんでした。
そこで、VPC内（題材は ALB → ECS の1区間）のTLS化が必要かどうかを、改めて一次情報と脅威モデルで整理し直してみました。雰囲気で「危ない」と言う前に切り分けたら、結局「セキュリティが上がるか」ではなく「コスト vs ガイドライン準拠」の問題だった、と分かるまでの記録です。
先にまとめ
結論は3つです。
- VPC内はSDNなので、宛先以外のインスタンスにパケットが届きません。つまり昔ながらの受動的な盗聴（同じセグメントに居て他人の通信を覗く）は成立しません
- 経路をTLSで暗号化して"新たに"防げるのは、構成変更の権限を奪われた場合やAWSの外に通信が出ていく場合などに限られます。今の構成でTLSが減らすリスクは実質ゼロに近いです
- だから論点は「セキュリティ向上の要否」ではなく「コスト vs ガイドライン準拠」です。規範が求める内容に、どの手段でいくらのコストをかけて応えるか、という話になります
選択肢を先に並べると次の4つです。暗号化が効く「レイヤ」が違うのがポイントです。
| 案 | 暗号化レイヤ | 課金 | ガイドライン準拠（説得のしやすさ） |
|---|---|---|---|
| (a) HTTPのまま | なし | $0 | 不採用の理由を設計判断の記録（ADR）で残す必要（最難） |
| (b) HTTPS + 自己署名 | アプリ層（TLS/L7） | $0 | 経路は暗号化＝説明しやすい |
| (c) HTTPS + AWS Private CA | アプリ層（TLS/L7） | $400/月（CAごと） | 真正性まで担保＝最も強い |
| (d) VPC encryption controls | ネットワーク層（Nitro/L3相当） | $151.2/月〜（東京・VPCごと） | 経路は暗号化＝説明しやすい |
以下、なぜこの結論になるのかを順に書きます。
そもそもVPC内は盗聴できるのか
最初に確認したかったのは、「物理的に同じLANにぶら下がっていて、他人のパケットが流れてくる」という昔のオフィスLANのイメージが、VPCにも当てはまるのか、でした。当てはまりません。
AWSのVPCは物理的な共有LANではなく、SDNの上に作られた仮想ネットワークです。この「オンプレのL2スイッチング（同じセグメントにフレームが流れ、隣の通信も物理的には見え得る）」と「VPCのSDN（パケットが宛先ごとに個別に転送される）」の違いが、今回の議論の出発点です。SDNとしての全体像はIvan Pepelnjak氏の "AWS Networking 101"（ipspace.net, 2020）が分かりやすく、盗聴の可否に直結する挙動は、AWSのLogical Separation on AWS（ホワイトペーパー）に、次のように書かれています。
Every packet flow on the network is individually authorized against a rule to validate the correct source and destination before it is transmitted and delivered. (...) If a packet is being routed to a destination without a rule that matches it, the packet is dropped. (...) This means ARP spoofing is highly improbable on the AWS network. Also, promiscuous mode does not reveal any traffic other than traffic bound to and from the customer operating system.
要点はこの3つです。
- すべてのパケットフローが、送信前にルールで個別に認可される（"individually authorized against a rule"）。ルールに一致しなければ破棄されるので、宛先以外のインスタンスには届きません
- ARPスプーフィングは "highly improbable"（成立し得ない水準）。仮想ネットワークの経路探索にARPを使わず、ARPパケットがそもそもネットワークに流れないためです
- プロミスキャスモード（無差別受信）にしても、自分のOS宛て以外のトラフィックは見えません
加えて、AZ間やリージョン間をまたぐ通信は物理レイヤで自動的に暗号化されます（参考。本題のVPC内1区間とは別レイヤです）。
なお、これらを実現している内部実装（Mapping Service など）の詳細仕様は非公開です。本記事も、公式が認める範囲と観測できる挙動をもとに書いています。
「Fargate/Nitroだから暗号化済み」は本当か
次に引っかかったのが、「うちはFargate（Nitro）だから、VPC内も勝手に暗号化されているのでは？」という見立てです。これは半分正しくて半分間違いです。
Nitroシステム上のインスタンス間には、ハードウェアによる透過的な転送中暗号化の仕組みがあります。ただしAWSのEC2ユーザーガイド（Encryption in transit）には、適用条件として次のように明記されています。
the traffic does not pass through a virtual network device or service, such as a load balancer or a transit gateway
（訳：トラフィックがロードバランサーやTransit Gatewayといった仮想ネットワークデバイス・サービスを経由しないこと）
つまりALBを経由するALB → ECSの区間は、この既定のNitro透過暗号化の対象になりません。「Fargateだから暗号化済み」は、ALB配下の構成では成り立たないわけです。
ただし、ここに2026年の新しい選択肢——VPC encryption controls——が加わりました。2025年11月に登場し、2026年3月1日に課金化されました。これはVPC内・VPC間の転送中暗号化を監査・強制する機能で、有効にするとALB/NLB/Fargateを暗号化対応ハードウェアへ自動的に移行し、経路をネットワーク層（Nitro、AES-256-GCM）で暗号化します。強制モードでは暗号化されない通信を破棄し、暗号化されているかどうかをフローログでも確認できます。これが後述の選択肢(d)です。
注意したいのは、(d)が暗号化するのは経路（ネットワーク層）であって、相手が誰か（サーバの真正性）ではない点です。ここはTLSのアプリ層の話と分けて考える必要があります。
ついでに、自己署名証明書についても整理しておきます。自己署名は暗号化（盗み見られても読めない＝機密性）は満たしますが、TLSの証明書としては真正性（接続先が本物かの確認＝なりすまし／中間者攻撃の防止）を担保しません。
この点はAWSの一次情報がはっきり書いています。ALBのターゲットグループのドキュメント（Target groups for your Application Load Balancers）に、次の記述があります。
The load balancer establishes TLS connections with the targets using certificates that you install on the targets. The load balancer does not validate these certificates. Therefore, you can use self-signed certificates or certificates that have expired. Because the load balancer, and its targets are in a virtual private cloud (VPC), traffic between the load balancer and the targets is authenticated at the packet level, so it is not at risk of man-in-the-middle attacks or spoofing even if the certificates on the targets are not valid.
読み解くと2点です。ひとつは、ALBはバックエンド（ECS側）の証明書を検証しないので、自己署名でも期限切れでも通るということ。もうひとつは、それでもVPC内ではパケットレベルで認証されているので、証明書が無効でもMITM（中間者攻撃）やなりすましのリスクには晒されない、とAWS自身が述べていることです。先に見たSDNの話が、ここでも効いてきます。
要するに、ALB → ECSの区間にTLS（自己署名を含む）を入れる意味は「経路の暗号化（機密性）」であって、「真正性の担保」ではありません。真正性はTLS証明書ではなくVPCのSDNが担っている、というのがAWSの立場です。
では、何が脅威なのか
ここが本題です。VPC内のALB → ECS区間で、TLSが「新たに」防げるリスクは何か。脅威を並べて、HTTPのままの場合と経路を暗号化した場合で何が変わるかを見ます。
| 脅威 | HTTPのまま | 経路を暗号化 | 結論 |
|---|---|---|---|
| 受動的スニッフィング（プロミスキャス/ARPスプーフィング） | そもそも成立しない | － | SDNで宛先以外に届かない＝TLS以前の話 |
| 能動的傍受（VPC Traffic Mirroring／攻撃者による経路・検査機器の挿入） | 平文を取得され得る | 取得されても暗号文 | ただしミラー作成（ec2:CreateTrafficMirror*）も経路・構成変更もコントロールプレーンの権限が前提。その権限を奪われた時点でアカウントが陥落しており、TLSは焼け石に水 |
| エンドポイント（ECSタスク）侵害・アプリの平文ログ | 漏れる | 漏れる | TLSの対象外。ホストの堅牢化・最小権限・ログ設計の領域 |
| AWS内のトポロジ変更（PrivateLink/TGW/VPCピアリング） | VPC内と同等 | VPC内と同等 | 脅威モデルは変わらない＝新たな実利なし |
| AWSの外へ出る将来の変更（Direct Connect/オンプレ/インターネット） | 危険 | 効く | ここで初めてTLSが本来の効果を持つ（その変更時に再検討すれば足りる） |
要点をひとことで言うと、AWS内に閉じている限り、経路をTLS化して減らせるリスクは実質ゼロに近いということです。HTTPS化を正当化する理由は「リスクを下げるから」ではなく、監査やスキャナとの摩擦を避け、ガイドラインに準拠するため、という点に尽きます。将来AWSの外に通信が出ていく構成になればTLSは本来の意味を持ちますが、それはその変更時に判断すれば十分で、起きるか分からない将来のために今から入れるのは過剰です。
この「要件・準拠」の整理は、AWS自身のベストプラクティスとも一致します。Well-Architected フレームワークの「SEC09-BP02 Enforce encryption in transit」（Security Pillar）には、次のようにあります。
You encrypt network traffic within your internal AWS environment according to your security requirements. (...) Only use protocols with encryption when transmitting sensitive data outside of your virtual private cloud (VPC). Encryption helps maintain data confidentiality even when the data transits untrusted networks.
内部AWS環境のトラフィックは「自組織のセキュリティ要件に応じて（according to your security requirements）」暗号化する、暗号化は「信頼できないネットワーク（untrusted networks）を通る際の機密性」を保つ、という位置づけです。同BPはさらに、暗号化要件を「組織のポリシー・規制上の義務・標準（policies, regulatory obligations and standards）」に基づいて定めよ、とも書いています。読み取れるのは、AWSは暗号化を「自組織の要件・コンプライアンスに応じて選ぶ手段」として提供しているだけで、内部経路をVPC内の脅威対策として暗号化せよとは言っていない、ということです。
だから判断は「コスト vs ガイドライン準拠」
ここまでで、内部経路の暗号化は「リスク低減」ではなく「要件・準拠」の話だと整理してきました。では、その準拠すべき規範は、VPC内の暗号化を実際どこまで求めているのでしょうか。ここがもう一つの肝で、答えは適用される規範によって変わります。脅威モデル上の実利（薄い）に対して、規範の要求が必須まで振れることもあれば、判断に委ねられることもあります。
判断の手順に落とすとこうなります。
- 脅威モデルで、TLS化が減らす実利を見積もる（→ VPC内なら薄い）
-
適用される規範を見極める
- 自治体の個人番号利用事務系のように、伝送データの暗号化が事実上必須の領域 → 素直に暗号化する（判断の余地は小さい）
- 政府機関で要機密情報を扱うクラウド → ガイドラインは「通信経路全般の暗号化を確認」＝SHOULD相当（原則は暗号化、逸脱は要文書化）
- それ以外の一般的な通信回線 → 必要性を検討して判断・記録する
- 規範の要求に、最も低いコストで応える手段を選ぶ
規範の詳しい条文は後の「補足」にまとめます。ここでは「規範はレジームによって必須〜確認〜判断と幅がある」とだけ押さえて、手段の比較に進みます。
選択肢は冒頭の4つです。実装手段としては、公共系ではAWS Certificate Manager（ACM）のパブリック証明書、またはAWS Private CAと連携したプライベート証明書（自動更新）が標準的です。
| 案 | 暗号化レイヤ | 課金 | 機密性 | 真正性 | 経路暗号化の準拠 | 運用・実装の手間 | 監査での説明 | 向くケース |
|---|---|---|---|---|---|---|---|---|
| (a) HTTPのまま | なし | $0 | × | × | 不採用（要ADR） | ゼロ | 最難。なぜ平文かを脅威モデルで説明する必要 | AWS内に閉じ、監査要件が緩い／リスクを受容できる |
| (b) HTTPS + 自己署名 | アプリ層（TLS/L7） | $0 | ○ | ×（証明書では担保せず。ただしVPCのパケット認証でMITM/なりすましリスクなし＝AWS明記） | 満たす | 証明書の発行・更新・配布 | 容易（経路は暗号化済み）。真正性はSDNが担うため説明範囲が狭い | コストゼロで経路暗号化の要件を満たしたい |
| (c) HTTPS + AWS Private CA | アプリ層（TLS/L7） | $400/月（CAごと） | ○ | ○ | 満たす | マネージドなPKI運用（ACM連携で自動更新） | 最も強い | 証明書を一元管理したい／信頼できるCAチェーンで真正性まで担保したい規模 |
| (d) VPC encryption controls | ネットワーク層（Nitro/L3相当） | $151.2/月（東京 $0.21/h × 24 × 30、VPCごと） | ○（Nitro AES-256-GCM） | ×（経路の暗号化でありサーバ認証ではない） | 満たす（強制・フローログで可視化） | ほぼゼロ（証明書運用が不要、有効化の設定のみ） | 容易（AWSマネージドで暗号化状態が見える） | 証明書を自前で運用したくない／複数経路を一括で暗号化・強制したい |
レイヤの違いが効くポイントを補足します。(b)(c)はアプリ層でクライアントからサーバまでを暗号化し、(c)はサーバの真正性も担保します。(d)はネットワーク層で経路を包むので、アプリは無改修・証明書の運用も不要ですが、暗号化されるのは「経路」であって「相手が誰か」は別問題です。
ここで気をつけたいのが(d)とPrivate CAのコスト比較です。課金の軸が違います。
- (d) VPC encryption controls は VPCごとに $151.2/月（東京）
- Private CA は CAごとに $400/月。1つのCAで多数のVPC・サービスをカバーできる
なので「(d)のほうが安い」は、対象VPCが少ないときだけ成り立ちます。
- 1VPC: (d) 151.2USD/月 < Private CA 400USD/月
- 2VPC: (d) 302.4USD/月 < 400USD/月
- 3VPC: (d) 453.6USD/月 > 400USD/月 で逆転
つまり、普遍的に安い案は存在しません。結局は「対象VPC数・CAの運用方針・真正性が要るか」をふまえて、規模ごとに試算する話に帰着します。1区間のためだけなら、(b)の自己署名で十分だとリスク需要する判断もありです。
判断軸をまとめると、まず適用規範のレジームを見極めたうえで、「経路暗号化の要求をどう満たすか（または不採用としてADRに記録するか）」を、(金銭コスト・運用手間) ×(真正性まで要るか) の2軸で選ぶだけ、ということになります。脅威モデル上の"新たなリスク低減"はどの案でもほぼゼロなので、ここはセキュリティ向上ではなくコストとガイドライン準拠の判断です。
まとめ
- VPC内はSDNなので、受動的な盗聴は成立しない
- 経路のTLS/暗号化が"新たに"守るのは、権限奪取やAWS外への流出など限定的。今の構成では実利はほぼゼロ
- ただしこれは脅威モデルからの整理であって、AWS公式が「不要」と言っているわけではない。AWSは要否に中立で、HTTPSもHTTPも顧客要件に応じて選べる機能として提供している
- だから論点は「要否」ではなく「規範の要求にどの手段・コストで応えるか」＝コスト vs ガイドライン準拠
- そして「VPC内も暗号化が必須か」は適用される規範のレジーム次第（自治体個人番号系は事実上必須／政府機関の要機密はSHOULD相当／一般は判断）。単一の「不要」「必須」では切れない
- 自己署名は機密性○・真正性は証明書としては×。ただしVPC内はパケットレベルで認証されMITM/なりすましリスクは無いとAWSが明記＝実質的なギャップは小さい
補足: 規範の読み方（一次情報）
「必須かどうか」の起点は技術ではなく、どの規範が適用されるか（システムの所管・格付）です。確認できた範囲を、要求が強い順に並べます。
A. 自治体・個人番号利用事務系 ＝ 事実上必須
AWSのガバメントクラウドの道案内（ASP＆運用管理補助者編）によれば、「地方公共団体情報システム非機能要件の標準」はすべての伝送データの暗号化を求め、個人番号利用事務系は内部ネットワークからのアクセスでもTLS暗号化が必要です。判断の余地は小さく、素直にTLS化します（ACMのパブリック／Private CA連携のプライベート証明書）。
B. 政府機関・クラウドで要機密情報を扱う ＝ SHOULD相当（原則実施・逸脱は要文書化）
対策基準策定ガイドライン（令和7年度版）の基本対策事項 4.2.2(2)-1 d) にこうあります。
クラウドサービス上で取り扱われる情報に要機密情報が含まれるか確認し、含まれる場合は通信経路全般において暗号化されていることを確認すること。
「通信経路全般」はVPC内も含み得ます。遵守事項側の動詞は「確認すること」なので無条件の暗号化MUSTではありませんが、基本対策事項は「暗号化されていることを確認する」＝暗号化済みを前提とした書き方です。基本対策事項は統一基準体系で標準的に実施が期待される対策なので、ニュアンスとしてはSHOULD（原則は暗号化。やらないなら理由を示す）に近いと思われます。
C. 一般の通信回線 ＝ 判断ベース
統一基準（令和7年度版）本文は、6.4.1(1)(c)「秘匿性の確保が必要と考える場合は…措置を講ずること」、7.1.5(1)(a)(ア)「暗号化を行う機能の必要性の有無を検討し、必要があると認めたときは…設けること」。義務は「必要性を検討・記録すること」で、実装は判断次第です。脅威モデルで切る本記事の作業は、この「必要性の検討」そのものにあたります。ちなみに本文が経路暗号化を明示要求するのは 6.4.3 無線LAN だけで、理由は「電波のため傍受が容易」。受動傍受が成立しないVPC内SDNはその対極です。
なおAWS側も中立で、Prescriptive Guidance（ECS暗号化ベストプラクティス）は転送中暗号化を "any of the following approaches" と列挙するのみです（自己署名も選択肢の一つ）。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。