オンプレミスのネットワーク設計には、長く機能してきた直感がある。 「ファイアウォールの内側は安全で、外側は危険」——境界の内外がそのままセキュリティの内外だった。
この直感を持ったままAWSに入ると、2つの症状が出る。 「とにかく全部プライベートサブネットに入れたい」という過剰な閉域志向と、 「プライベートに置いたのだから安全だ」という誤った安心感である。 本稿では、AWSに存在する3つのネットワークを区別するところから、この直感を組み立て直す。
ページ構成
- AWSには3つのネットワークがある
- AWSのサービスはどこに住んでいるか
- 核心: AWS APIは「場所」ではなく「署名」で守られている
- ではプライベートネットワークは何のためにあるのか
- 判断の整理: 守りたいものからレイヤーを選ぶ
- まとめ
1. AWSには3つのネットワークがある
| # | ネットワーク | 誰が管理するか | 性質 |
|---|---|---|---|
| 1 | 一般インターネット | 誰でもない（公共） | 経路上に不特定の第三者がいる前提。TLSで内容を守る |
| 2 | AWSグローバルネットワーク | AWS | AWSサービスのAPIエンドポイント群が生きている場所。リージョン間通信もAWSの専用網を通る |
| 3 | VPCプライベートネットワーク | 利用者 | 利用者が自分で作る仮想ネットワーク。EC2やRDSなど「住所を持つリソース」だけがここに住む |
オンプレの直感では1と3の二分法しかない。しかしAWSの実像は、 多くのサービスが2（AWSのグローバルネットワーク）に住んでいて、そもそも3の中にいないという構造をしている。
2. AWSのサービスはどこに住んでいるか
| サービス例 | 住んでいる場所 | あなたのVPCに「入れられる」か |
|---|---|---|
| S3 / DynamoDB / Lambda（関数実行の管理面） / CloudWatch / IAM | AWSグローバルネットワーク上のAPIエンドポイント | 入れられない（そういう場所にいない） |
| EC2 / RDS / ElastiCache / ECSタスク | VPC内（利用者が決めたサブネット） | もともとVPCの住人 |
「S3をプライベートサブネットに置きたい」という要望は、オンプレ直感からは自然に聞こえるが、 構造的に成立しない。S3はVPCの外側、AWSのネットワークに住むサービスであり、 できるのは「S3への経路をどう通すか」を選ぶことだけである（後述のVPCエンドポイント）。
3. 核心: AWS APIは「場所」ではなく「署名」で守られている
ここが本稿でいちばん伝えたい一点である。
AWSのAPIは、リクエストが「どこから来たか」ではなく「誰が署名したか」で守られている。
すべてのAWS API呼び出しには、IAMの認証情報による署名（SigV4）が付く。 APIエンドポイントは署名を検証し、IAMポリシーで認可を判定する。この仕組みに、呼び出し元の場所は関係がない。
| 呼び出しの状況 | 結果 |
|---|---|
| インターネットの自宅回線から、正しい認証情報でS3を操作 | 成功する |
| VPCのプライベートサブネット内のEC2から、IAM権限なしでS3を操作 | 拒否される |
つまり——
- プライベートネットワークの内側にいることは、AWS APIに対して何の権限も与えない
- インターネット側にいることは、AWS APIに対して何の減点にもならない
オンプレの「境界の内側=信頼」という等式は、AWS APIのレイヤーには存在しない。 APIの安全性を決めているのは、IAMポリシーの設計品質（誰に・どの操作を・どのリソースへ許すか）であり、 ネットワーク構成ではない。プライベートサブネットに置いたことを理由にIAMを緩めるのは、 守られていない場所を守られていると誤認する、最も危険なパターンである。
4. ではプライベートネットワークは何のためにあるのか
プライベートネットワークが無意味だという話ではない。守る対象が違うという話である。
| 守りたいもの | 有効な手段 | プライベート配置の意味 |
|---|---|---|
| AWS APIの操作（S3読み書き、リソース作成…） | IAMポリシー、（必要なら）エンドポイントポリシー | 本質的な防御ではない |
| VPC内リソースへのネットワーク到達（DBの接続口、管理ポート…） | Security Group、プライベートサブネット配置 | 有効。これが本来の役割 |
| 通信経路の要件（閉域要件、監査要件…） | VPCエンドポイント、専用線・VPN | 経路の統制として有効 |
- データベースやアプリの内部通信のように、ポートへのネットワーク到達そのものを制限したいものには、プライベート配置とSecurity Groupが効く。ここはオンプレの直感がそのまま活きる領域である
- VPCエンドポイントは「S3への通信をインターネットに出さず、AWS網内で完結させる」という経路の選択であり、それ自体がAPIの認可を強化するわけではない。「閉域経路でなければならない」という要件があるときに選ぶ手段で、全構成に必須の安全装置ではない
- 閉域化にはNATやエンドポイントの構築・運用コストが伴う。要件のない閉域はコストだけを生む
5. 判断の整理: 守りたいものからレイヤーを選ぶ
設計の順序を「まずプライベートに閉じる」から始めるのではなく、「何を守るか」から始める。
| 問い | Yesなら |
|---|---|
| 守りたいのはAWS APIの操作か？ | IAMポリシーを設計する。ネットワークをどれだけ閉じてもここの代わりにはならない |
| 守りたいのは特定ポートへの到達か？ | Security Groupで接続元を絞る。必要ならプライベートサブネットへ |
| 「経路をAWS網内に閉じよ」という明文の要件があるか？ | VPCエンドポイント等を追加する。要件がないなら、その運用コストは他に回す |
この順序で考えると、「全部プライベートに置く」という一律の方針は、 第一の問い（API操作の防御）に対して何も答えていないことが分かる。
6. まとめ
| オンプレの直感 | AWSでの実像 |
|---|---|
| ネットワークは内と外の2つ | 一般インターネット / AWSグローバルネットワーク / VPCの3つ |
| 主要なシステムは内側に置く | 多くのAWSサービスはそもそもVPCの外（AWS網）に住んでいる |
| 境界の内側=信頼できる | AWS APIは場所を見ない。署名とIAMポリシーだけを見る |
| 閉じるほど安全 | 閉域は「経路の要件」に応える手段。APIの防御はIAMの設計品質で決まる |
プライベートネットワークは、選択肢の1つであって既定の正解ではない。 API認証とネットワーク制限は別のレイヤーである——この一点を押さえるだけで、 過剰な閉域構成と誤った安心感の両方から距離を取り、守るべきものに設計の力を集中できるようになる。