要約
その環境にNATゲートウェイを作成する要件が既にある場合、
- ログなどの転送量の多い経路は、転送コストの安いVPCエンドポイントをそれぞれ作成する
- 転送量の少ない経路は、NATゲートウェイにまとめる
ことでコスト最適化を達成できる。
はじめに
こんにちは。セゾンテクノロジーの伊藤です。
先日、開発環境で、セッションマネージャーを使ってEC2に接続しようとした際、経路にssmエンドポイントではなく、NATゲートウェイを利用していることに気付きました。
資格試験の勉強では、VPCエンドポイントを使う構成しか学んでいなかったため、「なぜこのような構成なのか？」と疑問に感じました。
そこで、先輩社員の監督のもと、AWS Well-Architectedフレームワークの6本の柱の観点から、NATゲートウェイとVPCエンドポイントの使い分けについて調査・考察を行いました。
これから自分がクラウドアーキテクトを目指す上で、非常に重要な考え方だと感じたので、共有させていただきます。
Well-Architectedフレームワークによる比較
AWS初学者の比較なので、厳密にWell-Architectedフレームワークに則っていないことはご容赦ください。
セキュリティ
まず思いついたのが、セキュリティ面の違いです。
- NATゲートウェイ：インターネット経由で通信を行う
- VPCエンドポイント：AWS ネットワーク内部で閉じた通信を行う
また、制御の粒度にも違いがあります。
- NATゲートウェイ：ネットワークACLによるアクセス制御
- VPCエンドポイント：エンドポイントポリシーやSGで、より細かい制御が可能
総じて、VPCエンドポイントの方がセキュリティ上のメリットが多いように思えます。
しかし、今回は開発環境のためセキュリティ要件はそこまで厳しくありません。これが理由ではないようです。
運用上の優秀性
NATゲートウェイにすべてまとめてしまえば、SGによる繊細なアクセス制御こそできなくなりますが、管理が簡単になります。
しかし、そうはなっていません。これも理由ではないようです。
信頼性
どちらもAWSマネージドサービスとしてAZ内で冗長化されており、SLAでは99.9%の稼働率が保証されています。
どちらも開発環境には十分な可用性だと思います。
パフォーマンス効率
NATゲートウェイに比べ、VPCエンドポイントはインターネットを経由することがないため基本的にレイテンシが低いですが、開発環境において問題になるレベルではないと思います。
持続可能性
今回は判断材料になっていなさそうなので、割愛します。
コスト最適化
というわけで、コスト面に理由があると判断しました。
コスト比較
### NATゲートウェイのコスト
1つあたりの時間料金: USD 0.062 / 時間
処理データ1GBあたりの料金: USD 0.062 / GB
### VPCエンドポイントのコスト
1つあたりの時間料金: USD 0.014 / 時間
処理データ1GBあたりの料金(最初の 1PB): USD 0.01 / GB
- 時間料金、転送料金ともに、VPC エンドポイントの方が安価
- 特にデータ転送料金は NATの約1/6
- ただし、VPCエンドポイントは通信先ごとに個別作成が必要
今回の開発環境では、別にNATゲートウェイを作成する要件が存在していたため、NATの時間料金は固定コストとして発生する状況です。
そのため、「VPCエンドポイントの時間料金」以上に転送料金が節約できるケースでは、VPCエンドポイントを作成するべきということになります。
つまり、
データ量が多い経路はVPCエンドポイントを作成することでデータ処理料金を抑え、
データ量が少ない経路はNATゲートウェイを利用することでVPCエンドポイントの時間料金を発生させない
ことで、コスト効率を最大化させることができます。
目安
- NATゲートウェイと VPCエンドポイントのデータ転送料金の差：USD 0.052 / GB
- VPCエンドポイントの時間料金：USD 0.014 / 時間
これより、1時間あたり 約0.27GB以上のデータ転送がある場合は、VPCエンドポイントの方がコスト効率が良いと言えます。
結論
今回の環境における使い分けの基準は、
- ログなどの転送量の多い経路は、転送コストの安いVPCエンドポイントをそれぞれ作成する
- 転送量の少ない経路は、NATゲートウェイにまとめる
というものでした。
今後サービスの使い分けについて悩んだ際には、この経験を活かし、より最適な設計判断ができるよう努めたいと思います。
参考
より詳細な比較をされています↓
SLA
料金