（この記事はAIで記述していますが、実作業をまとめたものです。）
潔くAIで書いたことを認めている記事はそうそう居ないでしょう（いるかな）
個人開発・学習用のAWSは、削れるコストは全部削りたい。とくに常設サービスはそのまま固定費になるので厄介です。かといって、コストを惜しんで構成をシンプルにしすぎると、今度は脆弱なシステムになってしまいます。
今回は「Private Subnetに置いたEC2から、安全に、しかもタダで外部インターネットに出る」という、ちょっとわがままな要件を試してみた記録です。
課題：外部通信させたいけど、NAT-GWもTransit-GWも高い
Private SubnetのEC2から外部通信をする場合、AWSのベストプラクティスだとNAT GatewayやTransit Gatewayを使うのが定番です。ですが、これらは個人開発者にとってはなかなかの金額で、どちらも月額6,000円前後の固定費がかかります。これは高すぎる…。
かといってプロキシサーバを自前で立てるにしても、サーバ代が月額数千円かかるのは同じです。
やりたいこと：目的のインスタンスはPrivate Subnetの隔離環境に置きつつ、特定方向への外部通信だけをエグレスルールで許可する、無料かつセキュアな構成
Publicサブネットに直接EC2を置いてしまう方法もありますが、これは踏み台なしでインターネットに直接晒すことになるので却下です。
結論：Egress-Only Internet Gatewayを使う
結論から言うと、Egress-Only Internet Gateway（EIGW） を使えば実現できました。
- NAT Gatewayが有料なのに対し、EIGW経由の外部アクセスは無料
- IPv6アドレスはグローバルで一意なので、そもそもNATが不要（＝踏み台も不要）
という、IPv6ならではの仕組みに乗っかる構成です。ただし制約もあって、IPv6の構成が必須になります（EIGWはIPv6専用のゲートウェイなので当然といえば当然です）。
全体構成イメージ
【インターネット (IPv6)】
│
│ (IPv6通信)
│
┌─────▼──────────────────────────────────────────────┐
│ VPC (IPv6有効化済み) │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ Egress-Only Internet Gateway (EIGW) │ │
│ │ (IPv6の外向き専用ドア：無料) │ │
│ └──────────────────────────────────────▲─────────┘ │
│ │ │
│ ┌──────────────────────────────────────┼─────────┐ │
│ │ Private Subnet │ │ │
│ │ │ │ │
│ │ ┌───────────────────┐ ┌───────────┴───────┐ │ │
│ │ │ EC2 (IPv6対応) │───>│ ルートテーブル │ │ │
│ │ │ ・IAMロール付与 │ │ (::/0 をEIGWへ) │ │ │
│ │ └───────────────────┘ └───────────────────┘ │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ EC2 Instance Connect Endpoint (EICE) │ │
│ │ (ブラウザ/CLIからSSH接続用：無料) │ │
│ └───────────────────────▲────────────────────────┘ │
│ │ │
└─────────────────────────┼──────────────────────────┘
│ (安全なSSH接続)
【手元のPC / AWS CLI】
EC2への管理アクセスも、NAT-GWや踏み台サーバなしで完結させたいので、SSH接続は**EC2 Instance Connect Endpoint（EICE）**を使います。こちらも無料です。
やったこと（設定はシンプル）
構成としてやったことは以下の4つだけです。
- VPCでIPv6を有効化し、Egress-Only Internet Gatewayを作成
- EC2のセキュリティグループで、Inbound: SSH(22)を許可、Outbound: IPv6を追加
- ルートテーブルに
::/0をEIGW向けに流すルートを追加 - EC2へのアクセスはEC2 Instance Connect Endpoint（EICE）経由に統一
「NAT-GWか踏み台サーバ、いずれも有料」というのがこれまでの常識でしたが、IPv6前提にするだけでこのあたりが軒並み無料になるのは地味に嬉しいポイントでした。
動かしてみた
まずはIPv6アドレスが正しく振られているか確認します。
ubuntu:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 state UP qlen 1000
inet6 2600:1f18:3cf8:81b:cf21:3331:d7b5:4229/128 scope global dynamic noprefixroute
valid_lft 431sec preferred_lft 121sec
inet6 fe80::cec:a7ff:feb3:cf79/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
GoogleのパブリックDNS（IPv6）にpingを打ってみると、無事に疎通できました。
ubuntu:~$ ping6 -c 3 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=116 time=1.33 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=116 time=1.34 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=116 time=1.36 ms
--- 2001:4860:4860::8888 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.328/1.341/1.358/0.012 ms
順調順調…と思ったら、ここで一つハマりました。
ubuntu:~$ curl -6 -v -I https://github.com
* Could not resolve host: github.com
* Store negative name resolve for github.com:443
* shutting down connection #0
curl: (6) Could not resolve host: github.com
原因は、GitHubがIPv6アドレスを持っていないからでした。
ubuntu:~$ nslookup github.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: github.com
Address: 140.82.112.4
見ての通り AAAA レコード（IPv6）がなく、A レコード（IPv4）しか返ってきません。つまりこの構成、GitHubのようにIPv6非対応のサイトにはそもそも繋がらないという弱点があります。
補足：世の中のIPv6普及率ってどれくらい？
「IPv6だけで足りるの？」が気になったので、ついでに普及率も調べてみました。
| 測定対象 | 普及率（2026年現在） | 特徴・意味合い |
|---|---|---|
| Googleユーザーの接続比率 | 約50% | Googleへの全アクセスのうち、IPv6で届く割合。クライアント側の普及を示す。 |
| 世界のWebサイト全体 | 約31% | ネット上に存在する全Webサイトのうち、IPv6（AAAA）に対応している割合。 |
| 世界上位1000サイト | 約52% | アクセス数の多い主要なドメインにおける対応率。 |
グラフを見ると、2015年ごろから右肩上がりで伸びていて、直近では40〜50%程度まで普及が進んでいます。とはいえ、まだ半分近くのサイトはIPv4オンリー。GitHubのように主要サービスでも非対応のところが普通にあるので、この構成は万能ではないというのが正直な感想です。
まとめ
- Private SubnetのEC2から外部通信したいだけなら、NAT-GW／Transit-GWを使わなくてもEgress-Only Internet Gateway + IPv6で無料・セキュアに実現できる
- 管理アクセスもEC2 Instance Connect Endpointを使えば踏み台サーバなしで無料
- ただしIPv6非対応のサイト（GitHubなど）には繋がらないので、アクセス先次第で使える／使えないが決まる
- 「個人開発でとにかくコストを削りたい、かつアクセス先がIPv6対応済み（またはIPv6対応のプロキシ経由でよい）」というケースには刺さる構成
FAQ
Q1. IPv6非対応のサイトにもアクセスしたい場合はどうすればいいですか？
A. この構成単体では無理なので、DNS64/NAT64のような変換の仕組みや、素直に有料のNAT Gatewayを併用する構成にするのがおすすめです。
Q2. Egress-Only Internet Gatewayって、NAT Gatewayと何が違うんですか？
A. NAT GatewayはIPv4のアドレス変換（多対1のNAT）を行いますが、EIGWはIPv6の「外向き通信だけ許可し、外からの新規接続は通さない」ゲートウェイです。IPv6はグローバルで一意なのでアドレス変換自体が不要、という違いがあります。
Q3. 既存のIPv4前提のVPC・EC2にもそのまま適用できますか？
A. できません。VPC・サブネットでIPv6を有効化し、EC2にもIPv6アドレスを割り当てる必要があります。既存構成に手を入れる場合は、デュアルスタック化がまず最初のステップになります。
次に試したいこと
- DNS64/NAT64を組み合わせて、IPv4オンリーのサイトにもこの構成からアクセスできるか試す
- 実運用でのコスト（EICE・データ転送量など）を数か月分計測してみる
参考サイト: