このブログからパブリックIPv4 IPアドレスをなくしてコスト最適化
2024年2月より使用中のパブリックIPv4アドレスに1時間あたり0.005USDが請求されるようになりました。
パブリックIPv4をどこまでなくせるかもコスト最適化につながります。
AWSの各サービスもIPv6に対応しつつありますし、プライベートEC2 Instance ConnectやCloudFrontのVPCオリジンなどの機能も揃いつつあるので、このブログのパブリックIPv4をなるべくなくしてみます。
目次
現在の構成とパブリックIPv4の必要性
現在のこのブログの構成です。
使用しているパブリックIPv4アドレスは最低4つで、最低2つがApplication Load Balancer、最低2つがEC2インスタンスで使用されています。
最低2つと書いているのは、リクエスト量によって増える可能性があるためです。
だいたい4つのパブリックIPv4アドレスで月額15USD弱かかってます。
これを削減してみます。
Application Load Balancerの方針
Application Load BalancerはCloudFrontのVPCオリジンを使ってプライベートサブネットでパブリックIPv4なしで再構築します。
EC2インスタンスの方針
現在EC2インスタンスがパブリックサブネットにあってパブリックIPv4アドレスを設定している理由を書き出してみます。
S3への画像アップロードはすでにS3 VPCゲートウェイエンドポイントを使用しています。
* CloudWatch Logsへのログ書き込み
* CloudWatchカスタムメトリクスの送信
* Systems Managerセッションマネージャー使用
* WordPressとプラグイン更新時にwordpress.orgへのアクセス
このうち2025年1月現在でIPv6に対応しているのはCloudWatch Logsのみですので、カスタムメトリクスとセッションマネージャーは代替を考えなければいけません。
カスタムメトリクスはメモリ使用量のみモニタリングしているので、メモリ使用量のモニタリングを一時的にやめることにします。
セッションマネージャーの代替にEC2インスタンスコネクトを使用することにします。
wordpress.orgへのアクセスは更新時のみですので、メンテナンス用のEC2インスタンスのみ一時的にパブリックサブネットで起動することにします。
EC2 Instance Connect エンドポイントの作成
EC2 Instance Connect エンドポイントの作成
セッションマネージャーの代替でEC2 Instance Connect エンドポイントを使用できるようにしました。
CloudWatch LogsをIPv6アドレスを使用して送信する
CloudWatch LogsをIPv6アドレスを使用して送信する
EC2インスタンスのパブリックIPv4アドレスを無効にするために、CloudWatch Logsへの送信をIPv6エンドポイントに変更しました。
VPCオリジンを使用してApplication Load Balancerを内部ロードバランサーにする
CloudFrontのVPCオリジンを使用してApplication Load Balancerをプライベートサブネットで起動する
VPCオリジンを使用して、内部ロードバランサーを構築して以前のパブリックサブネットのApplication Load Balancerから移行しました。
最終構成
以上で請求対象のパブリックIPv4をこのブログから削減できました。
最後までお読みいただきましてありがとうございました!
「AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト [DVA-C02対応] 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。


開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。
このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。
また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。
ad
ad
関連記事
-
-
slackのbotにWikipediaを調べてもらう(Python on AWS Lambda + API Gateway)
slackのbotに少しでも役に立ってもらおうと、Wikipediaを調べてもら …
-
-
ブログの画像を別アカウントのS3に移動するためにIAMロールでクロスアカウントアクセス
ずっと先延ばしにしていたのですが、このブログの画像はEC2から直接配信しています …
-
-
AWS Well-Architected フレームワークによるクラウド ベスト プラクティスのセッションを聞いたので自アカウントの環境を確認してみる
AWS Summit Tokyo 2017で「AWS Well-Architec …
-
-
AWS OrganizatonsのRCP(リソースコントロールポリシー)を設定しました
2024/11月に発表されましたリソースコントロールポリシーを管理している組織に …
-
-
JAWS-UG関西「AI で人を笑わせてみよう!ハンズオン」に参加しました
AI で人を笑わせてみよう!ハンズオン 灼熱の7月最終日にJAWS-UG関西のオ …
-
-
GoogleForm,GASからAPI Gateway, Lambdaで入力情報をDynamoDBに格納する
vol.26 AWS認定試験テキスト認定クラウドプラクティショナーのデモ(Dyn …
-
-
Mountpoint for Amazon S3を試しました
このブログでは、画像などの配信にS3を使用しています。 WordPressのプラ …
-
-
[事前準備] JAWS-UG 関西IoT専門支部「マクニカkibo + AWS IoTハンズオン」
来る12/19(土)の JAWS-UG 関西IoT専門支部第一回勉強会「マクニカ …
-
-
ALBのヘルスチェックでPHPとMySQL接続をチェック
当ブログで504エラーが発生して、オートスケーリングにより自動でインスタンスが置 …
-
-
AWS 認定クラウドプラクティショナーのサンプル問題
AWS認定クラウドプラクティショナのサンプル問題2018年9月25日現在で、英語 …