意外と高いVPCエンドポイントのコストを下げる方法

概要

複数のAWSアカウントを運用している時にそれぞれのアカウントでVPC Endpointを作ると、
意外とコストがかかることをご存じでしょうか？

VPCエンドポイントを1つのAWSアカウントに集約するとコストを削減できるので、
集約の方法と注意点についてご紹介したいと思います。

アカウント全体のサービスのコストで、VPCが上位にくるような場合は是非検討してみてください。

集約すると嬉しいこと

VPCエンドポイント自体のコストを大きく削減できるのが一番のポイントですが、
他にもこんなメリットがあると思います。

• NAT GatewayやTransit Gatewayへの通信量（≒コスト）が減る場合がある

VPCエンドポイントの通信料は$0.01/GB（東京リージョン）
Nat Gatewayの通信料は$0.062/GB（東京リージョン）
Transit Gatewayの通信料は$0.02/GB（東京リージョン）

Nat Gateway比較だと安くなりますが、Transit Gateway比較だと通信料がやや高めの上に、2つのTransit Gateway Attachmentを通過するため通信料が2倍になることに注意してください。

• アカウント全体でVPCエンドポイントを作成する回数が1回で済む
• パブリック/プライベートを意識せずに済む（強制的にプライベートな通信経路となる）
  などなど

コストはどれだけ減るのか

例えば50アカウントで10個のVPCエンドポイント（全て東京リージョン）を利用している場合、
月に $5,110 (¥740,950 $1=¥145）発生します。

これを1つのアカウントに集約すると、
純粋にアカウント数で割ったら月に $102.2(¥14,819 $1=¥145）に下がり、
約98％削減できることになります。

ちなみにVPCエンドポイントは1AZにつき1つ作成するため、
可用性を求められるシステムだと1サービスのVPCエンドポイントを3つのAZで3エンドポイントとなります。

つまりアカウント数が多いほど、展開するAZが多いほど、エンドポイントを作るサービスが多いほど削減効果は高くなります!

VPCエンドポイントの最新の料金は下記リンクをご参照ください。
https://aws.amazon.com/jp/privatelink/pricing/

対象となるインターフェース

VPCエンドポイントには2種類のタイプが存在しますが、対象となるのはInterface型のエンドポイントです。

Interface型エンドポイント（AWS PrivateLink）

ほとんどのAWSサービスでは、このInterface型のVPCエンドポイントを使用します。
ちなみにVPCエンドポイントを作成すると裏側でENIが自動的に作成されます。

VPCエンドポイントの仕組み

Interface型のVPCエンドポイントは、
名前解決を利用してプライベートな通信経路を利用できるようにしています。
例えば以下はVPCエンドポイント経由で、CloudWatchサービスとの通信の仕方です。

ポイント詳細

1. CloudWatchへ通信をするために、Route53 Resolver(VPC+2アドレスのAWSが管理するDNS）にIPアドレスを確認しに行きます。
2. Route53 ResolverがVPC EndpointのIPアドレス（実際にはENIのIPアドレス）を返却します。
3. 返却されたIPアドレス宛に通信をルーティングすると、VPC Endpoint経由でCloudWatchへ接続できるようになります。

（補足）Gateway型

今回の対象ではありませんが、
S3、DynamoDBを利用されている場合はぜひ作成しておいたほうがよいと思います！（無料なので）

VPCエンドポイントを集約した構成

VPCエンドポイントを集約する構成について、2パターンご紹介したいと思います。

構成パターン1

Centralized Accountのプライベートホストゾーンを各AccountのVPCと紐づけるパターンです。
この構成は2020年頃のre:Inventのセッションで紹介されて知りました。

構成のポイント

1. ネットワーク接続
   アカウント間はネットワーク的に接続されている必要があります。（VPC PeeringでもOK）

2. VPCエンドポイントの作成
   集約したいVPCエンドポイントをCentralized Account内のVPCに作成します。
   VPCエンドポイントはCloudWatch、Systems Manager、Lambdaなど利用したいエンドポイント数分作成します。

注意点として、Route53 Resolverを使わないように「DNS名を有効化」のチェックボックスを無効化にして作成する必要があります。

3. ホストゾーンの用意
   VPCエンドポイントのPrivate Hosted Zoneを用意し、エイリアスレコード（Aレコード）を作成します。

例えばCloudWatchのVPCエンドポイントを集約する場合は、
以下のホストゾーンをCentralized Account内に用意します。

ホストゾーンを作成したら以下のようにVPCエンドポイントへのAレコードを作成します。

各サービスのDNS名については、describe-vpc-endpoint-servicesコマンドで確認することができます。
詳細はこちらをご参照ください。

注意点として、選択時に特定のAZのDNS名とリージョン全体のDNS名を選択することができるのですが、
可用性の要件で複数のAZにVPCエンドポイントを作成した場合はリージョン全体のDNS名を選択する必要があります。

4. ホストゾーンとVPCの紐づけ
   最後にホストゾーンを各AccountのVPCと紐づけます。
   紐づけを行うことで各AccountのVPC側からはVPCエンドポイントのDNS名を名前解決できるようになります。
   

どのようにして集約されたVPCエンドポイントを経由するのか

例えばVPCエンドポイントを経由してCloudWatchサービスに接続する場合、
Centralized Account内のホストゾーンが管理するエイリアスレコードが返却されます。

構成パターン2

もう1つの構成パターンは、Route53のResolver RuleをRAMで共有するパターンです。
この構成はAWSの公式ドキュメントでも紹介されています。

構成のポイント

1. Inboud Resolverの作成
   VPCエンドポイントのDNS名の転送先を、Shared VPCのRoute53 Resolver(VPC Cidr+2)に設定します。

2. RAMによるルールの共有
   RAMを使ってResolver ruleを各Accountへ転送します。

3. Resolver RuleとVPCの紐づけ
   共有されたResolver ruleをVPCに紐づけます。

どのようにして集約されたVPCエンドポイントを経由するのか

VPCエンドポイントのDNS名の名前解決先としてShared VPCのRoute53 Resolverが利用され、
Centralized Account内のPrivate Hosted Zoneが管理するエイリアスレコードを返却されるようになります。

一見構成パターン1のほうがシンプルで手間も少なそうですが、
もし既にVPCエンドポイントを使っていて、できるだけリスクを最小限にシームレスに切替たい場合は構成パターン2が良いかもしれません。
各構成パターンの切替例は以下を参照してください。

既存のVPCエンドポイントの切替

構成パターン1の場合

1. Centralized AccountにPrivate Hosted ZoneとVPC Endpointを用意します。
   

2. 既存のAccount側のVPCエンドポイントはプライベートDNS名を無効化にします。
   

この時点でAccount側のVPCエンドポイントを経由した通信はできなくなります。
Nat GatewayやIGWがない場合はAWSサービスと通信ができなくなります。

3. Centralized AccountにPrivate Hosted Zoneを、既存のAccount側のVPCと紐づけます。
   この時点でCentralized Account側のVPCエンドポイントを経由して通信するようになります。
   

4. 既存のAccount側のVPC Endpointを削除します。
   

構成パターン2の場合

1. Centralized AccountにPrivate Hosted ZoneとVPCエンドポイント、Resolver Ruleを用意し、RAMで展開できるように準備をします。
   

2. RAMによるResolver ruleを各Account側に共有をします。
   

3. 2で共有したResolver ruleをAccount側のVPCに紐づけます。VPC内の名前解決はVPCのRoute53 ResolverよりResolver forwarding ruleのほうが優先されるため、この時点でCentralized AccountのVPC Endpointを利用するように切り替わります。
   

名前解決の優先順位が変わるだけなので実際にやってみた限りでは通信断はありませんでしたが、
アプリのキャッシュなどによって通信断となる可能性もあるため事前に検証をしてから切替ることをご検討ください。

4. 既存のAccount側のVPC Endpointを削除します。
   

注意しておきたい点

1. 切替ったことを確認する方法

実際に各Account側からCentralized AccountのVPCエンドポイントを見に行っているかどうかを確認するには、
Shared VPCのVPC EndpointのCloudWatchメトリクス（ActiveConnections）を見るとわかります。
問題なく切り替わっていれば、切り替え直後からConnection数が増加しているはずです。

2. 特殊なAWSサービスのDNS名

一部のAWSサービスのPrivate Hosted Zoneを作る際にはDNS名に注意をしてあげる必要があります。

例えばECRなどは2つのホスト名があります。

https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/aws-services-privatelink-support.html
このうちdkr.ecr.ap-northeast-1.amazonaws.comのほうは、
CNAMEレコードとして*.dkr.ecr.ap-northeast-1.amazonaws.comの値をdkr.ecr.ap-northeast-1.amazonaws.comとしたものを追加する必要があります。

これはAmazon ECRからDockerイメージをプルをする際に、
URIが「11111111111.dkr.ecr.ap-northeast-1.amazonaws.com」などとなるため、
URIの名前解決ができるようにする必要があるためです。

AWSサービスによっては、ECRのようにURIが少し特殊だったりする可能性もあるため、注意をする必要があります。

3. リソースポリシーの修正

一部のAWSサービスはリソースポリシーというアクセス制限方法があります。
例えばAPI Gatewayはリソースポリシーによって接続元のVPC Idを制限したり、
接続元のIPアドレスを制限することが可能です。
そのため、VPCエンドポイントを集約した際にはリソースポリシーをShard VPCのVPCエンドポイントを経由した通信を許可するなどといったポリシーの見直しが必要になってきます。

まとめ

複数のAWSアカウントを運用している際に、同一リージョンのVPC Endpointを集約するとコストが削減することが可能です。（削減効果は運用しているアカウントやエンドポイント数に比例）
今回VPCを集約する構成を2つほどご紹介しましたが、既存のVPC Endpointがあり、シームレスに切り替えたい場合は（通信断が許されない本番環境など）構成パターン2のRAMとResolver ruleを使った構成が良いかと思います。
この記事がどなたかの参考になれれば幸いです。