はじめに

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内でのインターネットトラフィックの量を正しく見積もる必要がありそうでした。

ともあれ、選択肢のひとつにはできる程度には、概要を理解できたと思います！