AWS費用削減のため未使用のVPCエンドポイントを確認していたら、作った覚えのない謎のインターフェース型VPCエンドポイントがありました。
エンドポイントのNameタグは空欄で、インターフェース型で、サービス名は以下形式のものです。
com.amazonaws.vpce.ap-northeast-1.vpce-svc-XXXXXXXXXXXXXX
上記の形式だと、VPCエンドポイントのサービス名から用途を類推することができません。
さらに私の環境の場合デフォルトVPCのサブネット3つにENIを出しているようでなかなかの金食い虫構成です。
VPCエンドポイントの作成日から考えると、私がDB系サービスの検証を網羅的に実施していた時期です。
個人環境なので気軽にVPCエンドポイントを削除しようとしたところ、以下のエラーが出て削除に失敗しました。
vpce-XXXXXXXXXXXXXXX - Operation is not allowed for requester-managed VPC endpoints for the service com.amazonaws.vpce.ap-northeast-1.vpce-svc-XXXXXXXXXXXXXX.
この操作を行ったIAMユーザの権限はAdministratorAccessであり、SCPの制限も入っていないので、権限上は問題ないはずです。
Webでエラー文字列を検索するとこのVPCエンドポイントは、AWSサービスがバックグラウンドで作成する「リクエスタマネージド型VPCエンドポイント」のようです。これはVPCの画面からではなく、各利用サービス側のリソースを削除することでエンドポイントが削除されるもののようです。
このタイプのエンドポイントを削除するには、エンドポイントを作成した AWS マネージドサービスを特定する必要があります。サービスを特定したら、エンドポイントを削除する前に、そのリソースを削除する必要があります。
上記サイトには作成後90日以内であれば、CloudTrailのイベント履歴からCreateVpcEndpoint API コールを検索することで、どのAWSサービスが作成したものであるか調べる方法が記載されています。
私の場合VPCエンドポイントは90日以上前の作成だったので、ClouTrailのイベント履歴では追うことができません。
代わりにAthenaやCloudtrail Lakeが必要になってきます。Athena系はちょっと面倒なので二の足を踏みます。
そこで上記サイトを見ていくと、現時点で「リクエスタマネージド型ネットワークインターフェイス」を作成するAWSサービスは以下の4種類のAWSサービスであるといえそうです。
- Network Firewall
- Aurora Serverless
- RDS Proxy
- Redshift
たしかにVPCエンドポイントの作成日時にこれらのサービスを触っていましたが、どれであるかは思い出せません。
いずれにせよ幸いなことに上記すべて検証は完了しており、サービスを消しても問題なかったため、上記サービスのリソースを一通り削除してみました。が、VPCエンドポイントが消えません。
AWSサポートに問い合わせをすると、 Redshift Serverlessが怪しそうとの回答がありました。
マネジメントコンソールからRedshiftを開き、[Redshift Serverless]ダッシュボードに切り替えてから「ワークグループの設定」を見たところ、たしかにVPCエンドポイントの記載がありました！
たしかにRedshift Serverlessは、サーバレスと謳いながらもVPCのENIなどが必要になるサービスです。
当時触ったことも事実で、初期セットアップ時に「デフォルト設定を使用」したため、デフォルトVPCを対象にしたワークグループが作成されたようです。
ということで犯人がわかったので、defaultワークグループを削除してみます。
ワークグループの一覧画面に戻って対象のワークグループを選択し削除します。
削除の際、チェックをいれることでワークグループが紐付けられた名前空間のほうも削除できるようです。
ワークグループを削除すると、件のVPCエンドポイントも削除されます。
※なお、私は最初ワークグループの削除がいつまでたっても完了せず、数時間後にrootのメールアドレス向けにAWSサポートセンターから、内部エラーにより削除できなかった旨と、修正の連絡がきました。その後削除したところ、ワークグループの削除が正常に完了しました。(workgroup削除と同時にnamespaceの削除も実施していたのですがそちらは失敗しました）
Redshift Serverlessを長期的に使用しないときは、将来的な再利用状況を鑑みながら、workgroupを削除するという手もよいかと思います。
（それにしてもRedshift Serverlessはサーバレスと謳っておきながら、VPCリソースやコストを何かと消費しますね・・）
以上、同様の事象に遭遇した方向けのメモでした。