パブリック IPv4 アドレスの有無を確認しよう

2023年7月30日にAWSから、パブリックIPv4アドレスに対して、新しい料金体系が発表されました。
https://aws.amazon.com/jp/blogs/news/new-aws-public-ipv4-address-charge-public-ip-insights/

簡単に言ってしまえば、AWS上で利用しているすべてのパブリック IPv4 アドレスに対して課金しますよ！ということです。
これまで 利用中のElastic IPアドレスや通常のパブリックIPv4アドレスであれば、課金の対象外でした。

今回の発表で設定された課金額は 1つのパブリック IPv4 アドレスあたり、 0.005USD/時間です。。
執筆時の2023年9月29日に確認した為替レートは、148.73円/USD なので、1カ月を30日として計算すると・・・

**0.005 x 30 x 24 x 148.73 = 535.428 円！！**

パブリックIPアドレスが1つあるだけで、 535.428 円利用額が上がるということです。

もちろん、システム上パブリックIPv4アドレスを使わないというのは難しい環境もあると思います。
しかし、不必要にパブリックIPv4アドレスを割り当てているということも考えられます。

そこで、Amazon VPC IP Address Manager（IPAM)の**パブリックIPに関するインサイト**機能を使って現状を確認し、不要なパブリックIPv4アドレスが無いか確認しましょう。

## パブリックIPv4アドレスを確認しよう
前述の通り、パブリックIPに関するインサイトは「Amazon VPC IP Address Manager（IPAM)」の一部機能です。こちらを使って、リージョン毎にパブリックIPv4アドレスの存在をを確認できます。

東京リージョンでのパブリックIPに関するインサイト：
https://ap-northeast-1.console.aws.amazon.com/ipam/home?region=ap-northeast-1#PublicIpInsights

パブリックIPv4アドレスがある環境の場合、下図のように表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548623/2c5449f5-06c0-38e3-8d5d-18844472e101.png)
左側にあるのはタイプ別のパブリックIPv4アドレスです。
* EC2パブリックIP
    * EC2 の ネットワークインターフェースに関連づいているパブリックIPアドレスの個数
* Amazon所有EIP
    * 割り当てられている Elastic IPアドレスの個数
* サービスマネージドIP
    * ELBなどのマネージドサービスが利用しているパブリックIPv4アドレスの個数
* BYOIP
    * 自社のIPアドレスをAWSにBYOIPした個数

右側にあるのは、その中でもElastic IPアドレスの使用状況です。
* 関連付けられている Amazon 所有 EIPs
* 関連付けられていない Amazon 所有 EIPs
* 関連付けられている BYOIP
* 関連付けられていない BYOIP

また、画面下部では、パブリックIPv4アドレスの詳細が一覧化されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548623/dbe4b508-15c6-8542-a76a-a0613e176058.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548623/3eb25327-4093-97ca-02d3-1ab38e885442.png)

１つもパブリックIPv4アドレスが存在しない場合は、以下のような表示になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/548623/430c09c1-72bf-efcd-026a-cca11c315bbb.png)


## パブリックIPv4アドレスを確認したら
パブリックIPv4の存在を確認したら、次に、その IP アドレスをどうするか検討します。
例えば、以下のような検討軸で判断します。

* パブリック通信は実は不要
* パブリック通信は必要
* パブリック通信が必要だか実は、間接的にできればOK
    * AWS のAPI　エンドポイントにアクセスするために必要
    * 双方向である必要ない(VPCから出る必要はあるが、外からEC2インスタンスに到達する必要はないなど)

それぞれの観点を見ていきます

### パブリック通信は実は不要
不要なパブリックIPアドレスが付与されていることなんてないとは思いたいですが、確認した結果不要なのであれば取り外しましょう。
見落としがちでよくあるのは、ロードバランサーのバックにいる Web サーバーです。後述の様にロードバランサーはインターネット側からの着信用にパブリックIPアドレスが必要ですが、バックエンド側のサーバーは、プライベートIPアドレスのみで問題ありません。

### パブリック通信は必要
このケースは以下が考えられます。
* セキュリティ上の理由
* 踏み台サーバ―
* ロードバランサーの着信用
* プロキシサーバーやNATサーバー
* AWS のAPIエンドポイントにアクセスする

IPアドレスには IPv6アドレスが存在します。このIPv6アドレスであれば、課金の対象外ですし、EC2インスタンスなどの上で動いているアプリケーションが対応さえしていれば利用可能です。
そのため、一旦はパブリックIPv4アドレスによるパブリック通信が必要であると判断しても、パブリックIPv4アドレスからIPv6アドレスに変更しても問題ないかを課金開始の残された期間で確認し、置き換えていくことで不必要なコスト増を防ぐことが可能です。

#### セキュリティ上の理由
例えば、VPC内のサーバーと外部のサーバー間で通信が行われ、EIPを用いている。この固定IPアドレス間のみ通信を認めているなどのファイアウォールルールがあるといった場合には、一旦はそのままにします。
VPC内のサーバーのアプリケーションや対向側が問題なければ IPv6 アドレスに置き換えます。

#### ロードバランサーの着信用
前述の通り、インターネットに公開するWebサーバーのフロント側に配置するロードバランサー(インターネットフェンシング)には、パブリックIPアドレスが必要です。
現状、ELBのIPアドレスタイプはIPv4のみかIPv4+IPv6のDualStackなので、バックエンドのサーバーの状況に応じて、IPv6を使うようにするか検討、確認します。

#### プロキシサーバーやNATサーバー
プライベートIPアドレスしか持たないEC2インスタンスなどが外部へアクセスするために、プロキシーやNATが必要になります。これらのサーバーやNATゲートウェイなどにはパブリックIPアドレスが必要です。
ただし、プライベートIPアドレスしか持たないEC2インスタンスなどであっても、IPv6アドレスに置き換えたうえで、Egress-Only Internet Gatewayを使うことでVPC内から出ていくことはできるが、VPC外から発信された通信を受けないといったことが可能です。
つまり、NATサーバー/NATゲートウェイなどが不要になるケースが出てきます。
NATゲートウェイは便利ですがコストが高めなのでこの機会に無くすというのも一つの案です。

#### AWSのAPIエンドポイントにアクセスする
AWS の API エンドポイントにアクセスするにはパブリックIPアドレスを用いた通信が必要になります。
しかし、VPC エンドポイントをサポートしているAWSサービスであれば、VPCエンドポイントを介してアクセスすることでパブリックIPアドレスが不要になります。
EC2インスタンスなどから利用しているAWSサービスを確認して、VPCエンドポイントに置き換えられるかを確認します。
ただし、VPCエンドポイントも一部を除いて有料なので、パブリックIPv4アドレスとVPCエンドポイントの費用を比較して、どちらが有利なのかを判断します。

#### 踏み台サーバ―
保守用の踏み台サーバ―として用意しているサーバーにもパブリックIPアドレスが付与されていると思います。運用上問題がなければ、Instance Connectやセッションマネージャーと併せてVPC エンドポイントを使うことでパブリックIPアドレスが不要になります。外部に公開しなくなるのでセキュリティ面も強化されます。



他にも検討すべき点などがありますが、まずは、IPアドレスの状況とアーキテクチャの再確認を行ってから、何をすべきか判断してください。

## まとめ
執筆時点で課金開始まで残り4か月ほどになりました。
以下の記事も参照し、皆さんの関係するネットワークの総点検をしてみましょう。
オンプレミスとは異なり、クラウドであれば作ったら作りっぱなしではなく、定期的に見直し、変更することもやりやすいです。
コストの最適化やネットワークの最適化などを推し進めていってください。

* [デュアルスタック または IPv6 のみを用いた Amazon VPC リファレンスアーキテクチャ(pdf)](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf)
* [AWS およびハイブリッドネットワークにおけるデュアルスタック IPv6 アーキテクチャ – パート1](https://aws.amazon.com/jp/blogs/news/adual-stack-ipv6-architectures-for-aws-and-hybrid-networks-jp/)
* [AWS およびハイブリッドネットワークにおけるデュアルスタック IPv6 アーキテクチャ – パート2](https://aws.amazon.com/jp/blogs/news/dual-stack-architectures-for-aws-and-hybrid-networks-part-2-jp/)
* [IPv6 on AWS](https://aws.amazon.com/jp/vpc/ipv6/)
* [IPv6 をサポートする AWS サービス](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/aws-ipv6-support.html)
* [AWS におけるパブリック IPv4 アドレスの使用状況の特定と最適化](https://aws.amazon.com/jp/blogs/news/identify-and-optimize-public-ipv4-address-usage-on-aws/)

ーーー
記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。