オンプレミスのネットワーク設計には、長く機能してきた直感がある。 「ファイアウォールの内側は安全で、外側は危険」——境界の内外がそのままセキュリティの内外だった。
この直感を持ったままAWSに入ると、2つの症状が出る。 「とにかく全部プライベートサブネットに入れたい」という過剰な閉域志向と、 「プライベートに置いたのだから安全だ」という誤った安心感である。 本稿では、AWSに存在する3つのネットワークを区別するところから、この直感を組み立て直す。
1. AWSには3つのネットワークがある
オンプレの直感では1と3の二分法しかない。しかしAWSの実像は、 多くのサービスが2（AWSのグローバルネットワーク）に住んでいて、そもそも3の中にいないという構造をしている。
2. AWSのサービスはどこに住んでいるか
「S3をプライベートサブネットに置きたい」という要望は、オンプレ直感からは自然に聞こえるが、 構造的に成立しない。S3はVPCの外側、AWSのネットワークに住むサービスであり、 できるのは「S3への経路をどう通すか」を選ぶことだけである（後述のVPCエンドポイント）。
3. 核心: AWS APIは「場所」ではなく「署名」で守られている
ここが本稿でいちばん伝えたい一点である。
AWSのAPIは、リクエストが「どこから来たか」ではなく「誰が署名したか」で守られている。
すべてのAWS API呼び出しには、IAMの認証情報による署名（SigV4）が付く。 APIエンドポイントは署名を検証し、IAMポリシーで認可を判定する。この仕組みに、呼び出し元の場所は関係がない。
つまり——
- プライベートネットワークの内側にいることは、AWS APIに対して何の権限も与えない
- インターネット側にいることは、AWS APIに対して何の減点にもならない
オンプレの「境界の内側=信頼」という等式は、AWS APIのレイヤーには存在しない。 APIの安全性を決めているのは、IAMポリシーの設計品質（誰に・どの操作を・どのリソースへ許すか）であり、 ネットワーク構成ではない。プライベートサブネットに置いたことを理由にIAMを緩めるのは、 守られていない場所を守られていると誤認する、最も危険なパターンである。
4. ではプライベートネットワークは何のためにあるのか
プライベートネットワークが無意味だという話ではない。守る対象が違うという話である。
- データベースやアプリの内部通信のように、ポートへのネットワーク到達そのものを制限したいものには、プライベート配置とSecurity Groupが効く。ここはオンプレの直感がそのまま活きる領域である
- VPCエンドポイントは「S3への通信をインターネットに出さず、AWS網内で完結させる」という経路の選択であり、それ自体がAPIの認可を強化するわけではない。「閉域経路でなければならない」という要件があるときに選ぶ手段で、全構成に必須の安全装置ではない
- 閉域化にはNATやエンドポイントの構築・運用コストが伴う。要件のない閉域はコストだけを生む
5. 判断の整理: 守りたいものからレイヤーを選ぶ
設計の順序を「まずプライベートに閉じる」から始めるのではなく、「何を守るか」から始める。
この順序で考えると、「全部プライベートに置く」という一律の方針は、 第一の問い（API操作の防御）に対して何も答えていないことが分かる。
6. まとめ
プライベートネットワークは、選択肢の1つであって既定の正解ではない。 API認証とネットワーク制限は別のレイヤーである——この一点を押さえるだけで、 過剰な閉域構成と誤った安心感の両方から距離を取り、守るべきものに設計の力を集中できるようになる。