はじめに
VPCエンドポイントは、NATゲートウェイなどインターネットGWを経由することなく、
プライベートなサブネットのリソースをVPCの外のサービスにアクセスできるようにしてくれるリソースです。
アーキテクチャの構成次第ですが、このVPCエンドポイントを利用することで、
課金額に大きく跳ねるNATゲートウェイを使わずにすむ可能性があります。
是非使えるようになっておきたいリソースなので、触ってみました！
VPCエンドポイントとは
イメージとしては、グローバルなインターネットGWではなく、プライベートな裏口を作る感じです。
上記の図にもある通り、インターネットGWを経由せずに各リージョンリソースにアクセスできます。
ほぼすべてのサービスのエンドポイントに対応している「インターフェイスエンドポイント」と、
S3, DynamoDBにのみ対応している「ゲートウェイエンドポイント」の2種類が存在します。
やってみた
今回は、NATゲートウェイへのルートを持たない、プライベートサブネットと、EC2を用意しました。
通常のプライベートサブネット上のインスタンスは、NATゲートウェイからインターネットゲートウェイを経由して通信を行いますが、
そもそもプライベートサブネットのルートにNATへのルートがなければ、それもままなりません。
参考イメージ：
このNATゲートウェイへのルートを持たないプライベートサブネット上のEC2から、VPCエンドポイントを利用して、SSM、S3と通信させてみようと思います！
参考イメージ：
ゴールの確認
インターフェイスエンドポイントは、APIエンドポイント先の数だけ配置する必要があります。
ドキュメントによって揺れがあるのですが、今回は下記のドキュメントを参考に、
SSMを実行するためのエンドポイント
- com.amazonaws.ap-northeast-1.ssm
- com.amazonaws.ap-northeast-1.ssmmessages
- com.amazonaws.ap-northeast-1.ec2
- com.amazonaws.ap-northeast-1.ec2messages
S3へのアクセスのためのエンドポイント
- com.amazonaws.ap-northeast-1.s3
これらを作成し、インターネットGWではなく、
プライベートなインターネットを経由してSSM,S3操作を行ってみようと思います！
事前準備
エンドポイントを作成する前に、
前述したNATへのルートのない孤立したEC2を作成したので、設定の確認を行います。
VPCの名前解決設定
VPCエンドポイントを使用するためには、
VPC内のリソースが、AWS DNSを利用して、プライベートホストネームを解決できる必要があります。
VPCの「enable_dns_support」「enable_dns_hostnames」がtrueになっていることを確認します。
ルートテーブルのルート設定
VPC内のリソースへのルートが存在し、NATまたはインターネットGWへのルートがないことを確認します
EC2のプライベートDNS割り当て
エンドポイントを利用するインスタンスがプライベートDNS名前解決可能な状態か確認します。
プライベートDNS応答を拒否する設定になっているので、変更します。
SSM管理できていないことを確認
session managerで接続できないことが確認できればOKです
VPCインターフェースエンドポイントを作成してSSMしてみる
まずは、インターネットへの通信経路のないEC2にSSMでアクセスできるようにしてみます
SSMを実行するためのエンドポイント
- com.amazonaws.ap-northeast-1.ssm
- com.amazonaws.ap-northeast-1.ssmmessages
- com.amazonaws.ap-northeast-1.ec2
- com.amazonaws.ap-northeast-1.ec2messages
これらを作成していきます！
エンドポイントにアタッチするセキュリティグループを作成する
VPCインターフェースエンドポイントはプロキシサーバーのようなものです。
443ポートでアクセスできるようセキュリティグループを設定します。
エンドポイントを作成する
さっそくインターフェイスエンドポイントを作成していきます。
VPC > エンドポイントと移動します。
「エンドポイントを作成」をクリックします。
作成画面がでました。
必要な設定を行っていきます。
エンドポイント名前タグを入力します。
その他の値はデフォルトです。
次に、エンドポイントとするサービスを選択します。
検索ボックスを利用し、「com.amazonaws.ap-northeast-1.ssm」を指定します。
エンドポイントを作成するVPCを選択します。
用意したVPCを選択します。
その他の値はデフォルトです。DNS有効化が必須な点に注意です。
インターフェイスエンドポイントのみ、AZ, サブネットを選択します。
今回は、EC2の存在するサブネットを指定します。
エンドポイントにアタッチするセキュリティグループを選択します。
先ほど作成した、VPC内からの443アクセスを許可するセキュリティグループを指定します。
最後に、ポリシーを設定できます。
今回はフルアクセスを指定します。
タグと、ここまでの設定に問題がなければ、作成をクリックします。
無事、エンドポイントが作成されました！
サービス名が正しいこと、インターフェイス型なことがコンソールから確認できますね。
同じ要領で4つのエンドポイントを作成する
同じ要領で、今回必要となる4つのエンドポイントを用意しました。
SSMで接続する準備が完了しました！
SSM経由でアクセスできるか確認
まずはEC2インスタンス接続画面から確認してみます。
「接続」ボタンが活性化され、アラート類が表示されていないですね。
無事、session manager経由で接続できました！
その他のリソースにはアクセスできないことを確認
aws cli でS3にアクセスしてみます。
少し待ちましたが、応答が返ってきませんでした・・・・
次はS3へのエンドポイントを作成してみます！
VPCゲートウェイエンドポイントを作成してS3にアクセスしてみる
それでは、ゲートウェイエンドポイントを作成していきます。
大まかな流れはインターフェイスエンドポイントと同じです！
エンドポイントを作成する
VPC > エンドポイントから同じく作成していきます。
エンドポイント名とサービスを選択します。
「com.amazonaws.ap-northeast-1.s3」を選択します。
2つありますが、ゲートウェイタイプを選択します。
ゲートウェイタイプを選択した場合、サブネットやセキュリティグループを選択する必要はありません。
インターネットGWやNATゲートウェイを作成する時と同様、どのルートテーブルのルートに追記するか？を選択します。
分かりづらいですが、EC2インスタンスが所属するサブネットに紐づくルートテーブルを指定しています。
設定は以上ですので、作成します！
問題なく、ゲートウェイエンドポイントが作成されました。
作成時に選択したルートテーブルを確認してみると、S3のプレフィックスリストがトラフィックの送信先の場合、vpce（VPCエンドポイント）へターゲットされる設定になっていることが確認できます。
S3でアクセスできるか確認
session managerから先ほど同様のコマンドを実行してみます。
パブリックインターネットへのルートがないのにS3にアクセスできました！
コスト感を比較してみる
動作確認が終わったところで、当初のモチベーションだった、NATの使用を控え、コストを抑えることができるか？に着目してみます。
それぞれ、公式で確認した料金表です。
NAT
VPCエンドポイント
表にしてみると以下のようになりますね。
| 1リソースあたり料金 | 処理データ1GBあたり料金 | |
|---|---|---|
| NAT | 0.062USD | 0.062USD |
| VPCエンドポイント | 0.014USD | 0.01USD |
VPCエンドポイントの料金は、処理データ1GBあたりの料金が使用量ごとに減っていきますが、
エンドポイントが増えるたびに、0.014USDがかさんでいきます。
今回の例ですと、5つのエンドポイントを作成するため、0.062 > 0.014 * 5で、
処理データが多い場合でないと、NATを使用したほうが課金額は安く済みそうです。
おわりに
以外に、VPCエンドポイントを使うだけで簡単にNAT使用量を節約できそうにありませんでした。
NATとVPCエンドポイントの比較には、VPC内でのインターネットトラフィックの量を正しく見積もる必要がありそうでした。
ともあれ、選択肢のひとつにはできる程度には、概要を理解できたと思います！