【入門編】 VPCエンドポイント(Interface型/AWS PrivateLink)のENI配置とIPアドレス消費 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！クラウドの深淵を覗き込み、インフラの「なぜ？」を紐解くSREブログへようこそ。

今日は、AWSエンジニアなら誰もが一度は頭を悩ませる「VPCエンドポイント（Interface型）とIPアドレス枯渇問題」について、現場の知見を交えてじっくり解説していきたいと思います。

「え、VPCエンドポイントってただのアクセス経路でしょ？何がそんなに怖いの？」と思う方もいるかもしれません。でも、この設計を甘く見ると、本番環境で突然「IPアドレスが足りなくてサーバーが増やせない！」という悪夢に直面することになります。

一歩ずつ、郵便配達の仕組みに例えて紐解いていきましょう！

—

そもそも「Interface型VPCエンドポイント」って何者？

AWSのサービス（S3やDynamoDBなど）に、インターネットに出ることなくプライベートにアクセスする仕組みがVPCエンドポイントです。その中でも「Interface型」は、「VPCの中にAWSサービスの専用窓口を置く」というイメージです。

これを実現するために、AWSは皆さんのVPCの中に ENI（Elastic Network Interface）という「仮想のネットワークカード」を差し込みます。

郵便配達で例えると…

VPC：巨大なマンションの敷地
サブネット：マンションの「棟」
ENI：その棟の入り口に設置された「専用の郵便ポスト」
AWSサービス：隣町にある巨大な物流センター

通常、物流センターへ荷物を送るには公道（インターネット）を通る必要がありますよね。でも、この専用ポスト（VPCエンドポイント）を設置すれば、マンションの敷地内から直接、物流センターへ専用回線で荷物を送れるようになるわけです。便利ですよね！

—

なぜIPアドレスが足りなくなるのか？

ここからが本題です。マンションの各棟（サブネット）に郵便ポスト（ENI）を設置する際、「どの棟にも必ずポストを置いてください」というルールにするとどうなるでしょう。

もし、Webサーバー用のサブネットが3つ、DB用のサブネットが3つある環境で、複数のVPCエンドポイントを全てのサブネットに配置すると、IPアドレスをものすごい勢いで消費していきます。

特に、/28 や /27 といった小さなサブネットを使っていると、あっという間に「IPアドレスの空きがありません」という悲しいエラーメッセージに出会うことになります。

—

枯渇を防ぐための「賢い設計」3つのステップ

では、どうすればこの事態を回避できるのでしょうか。現場でよく使う鉄則を3つご紹介します。

1. 「エンドポイント専用サブネット」を切り出す

全てのサブネットにENIを置く必要はありません。ネットワーク設計の定石は、「エンドポイント専用のサブネット」を一つ作ってしまうことです。

メリット：他のアプリ用サブネットのIPアドレスを圧迫しない。
注意点：AZ（アベイラビリティゾーン）をまたぐ場合は、それぞれのAZに専用サブネットを用意しましょう（高可用性のため）。

2. DNSの解決先を意識する

Interface型エンドポイントを使うと、vpce-12345678.s3.ap-northeast-1.vpce.amazonaws.com のような専用ホスト名が割り当てられます。
これをプライベートホストゾーンで既存のサービス名（例：s3.ap-northeast-1.amazonaws.com）に紐付ける設定（Private DNS）を有効にすると、アプリケーション側のコードを一切変えずに、自動的にこの専用ポストへ向かうようになります。

3. Terraformでの実装例

Terraformで構築する際、以下のように「必要なAZにだけENIを配置する」設定を明示的に書くことが大切です。

# VPCエンドポイントの定義例
resource "aws_vpc_endpoint" "s3_interface" {
  vpc_id              = aws_vpc.main.id
  service_name        = "com.amazonaws.ap-northeast-1.s3"
  vpc_endpoint_type   = "Interface"

  # IPアドレス枯渇を防ぐため、特定のサブネットのみを指定する
  subnet_ids          = [
    aws_subnet.endpoint_subnet_a.id, 
    aws_subnet.endpoint_subnet_c.id
  ]

  # セキュリティグループでアクセスを制限する（最小権限の原則！）
  security_group_ids  = [aws_security_group.endpoint_sg.id]

  # プライベートDNSを有効化して、接続を透過的にする
  private_dns_enabled = true
}

—

トラブルシューティングの現場から

もし皆さんの環境で「IPアドレスが足りない！」となったら、まずは aws ec2 describe-network-interfaces コマンドで、誰がIPを食いつぶしているか確認しましょう。

# どのENIがどのサービスのために作られたかを確認するコマンド
aws ec2 describe-network-interfaces \
    --filters Name=description,Values="VPC Endpoint Interface *" \
    --query "NetworkInterfaces[*].{ID:NetworkInterfaceId, Subnet:SubnetId, PrivateIP:PrivateIpAddress}" \
    --output table

もし、使っていない古いエンドポイントが残っていたら、それは「誰も使わないのに場所だけ取っている郵便ポスト」と同じです。勇気を持って削除しましょう。

—

最後に：設計は「引き算」が大切

クラウドのネットワーク設計は、つい「あれもこれも」と詰め込みたくなりますが、実は「いかにシンプルに保つか」が運用の成否を分けます。

IPアドレスの枯渇は、数ヶ月後、あるいは数年後の自分たちへの「借金」です。今日ご紹介した「専用サブネットへの切り出し」と「AZを意識した配置」を心がけるだけで、その借金はぐっと減らすことができます。

皆さんのネットワーク設計が、安全でスケーラブルなものになることを応援しています！また次の記事でお会いしましょう。