3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hacchi_no_donburi(佐藤 祥人)
in

AWSでプライベートIPが無駄に使われていないか調べてみた

3
Posted at

はじめに

本記事は、以下のような方を対象にしています。

  • オンプレミス＋AWS のハイブリッド構成など、何らかの制約により IPv4 のみで運用しており、十分なIPセグメントを確保できていない
  • サブネット内のプライベートIPが枯渇しつつあり、どこで使われているか把握したい

なお、本記事では EIP（パブリックIP）については扱いません。対象は VPC 内のプライベートIP です。
また、記事内では調査用のCLIコマンドを紹介していますが、あくまで一時的な現状把握を目的としています。運用に組み込む際は、要件に応じた作り込みが必要です。

概要

「サブネットのIP、なんか足りなくなってきた...？ 」

調べてみたら、Lambda や VPC Endpoint、DataSync あたりで結構消費されてたので、整理してみました。

今回やったのは主にこの3つ：

  • VPC Lambda のセキュリティグループをまとめる
  • 使ってない Interface VPC Endpoint を消す
  • DataSync のロケーション削除忘れを片付ける

本記事では調査用のCLIコマンドを紹介していますが、あくまで一時的な現状把握を目的としています。運用に組み込む際は、要件に応じた作り込みが必要です。

背景

オンプレミスと AWS を併用したハイブリッド環境で、プライベートIPをIPv4 のみで構成している方はいませんか？

オンプレ側との接続要件によって IPv6 が利用できず、やむなくIPv4だけで運用していると、避けて通れないのがサブネットのIP枯渇リスクです。実際、私たちの環境でも「あれ、IP足りなくなりそう…？」という場面が出てきました。

そこで「いったいどこでIPが消費されているのか？」を洗い出してみたところ、棚卸しや運用の見直しによって削減できるポイントがいくつも見つかりました。今回は、その調査過程と対応策をまとめて共有します。

AWS で ENI を消費するサービス一覧

「そもそもどのサービスがIPを食ってるんだ？」と思って調べてみたら、思ってた以上にいろんなサービスがENIを使ってました。

せっかくなので、自分が調べた範囲でカテゴリ別にまとめてみます。

自分が調べた範囲でのまとめです。他にもENIを消費するサービスはあると思います。抜け漏れがあるかもしれませんが、ご了承ください。

以下の一覧は参考情報として折りたたんでいます。必要に応じて展開してください。

ENIを消費するAWSサービス一覧

コンピュート系

サービス ENI 消費パターン 備考
EC2 インスタンスごとに1個以上 ・インスタンスタイプにより最大ENI数が異なる
・追加ENIをアタッチして複数IPやネットワーク分離が可能
ECS (Fargate) タスクごとに1個 ・awsvpcネットワークモードを使用
・タスクごとに固有のプライベートIPを持つ
・タスク数に比例してENI消費が増加
EKS ノードごとに複数 ・VPC CNI使用時、PodにVPCのIPアドレスを直接割り当て
・ノードのインスタンスタイプにより割り当て可能なIP数が制限
・Prefix Delegationで効率化可能
・他のCNI（Calico等）使用時は動作が異なる
Lambda (VPC) サブネット＋SG組み合わせごとに共有 ・Hyperplane ENIにより複数関数・実行がENIを共有
・同時実行数が増えてもENI数は大きく増加しない
App Runner (VPC) VPCコネクタごとに2個以上 ・複数AZに配置される
・VPC内リソース（RDS等）へのアクセス時に使用
・VPCコネクタ未使用時はENI消費なし
Elastic Beanstalk インスタンスごとに1個 ・内部でEC2が起動するためインスタンスごとにENIを消費
・オートスケーリング時はインスタンス数に比例してENI数が増加
・ELB使用時は追加でENIを消費
Batch コンピュート環境に依存 ・Fargateタイプ：タスクごとに1個
・EC2タイプ：インスタンスごとに1個
AppStream 2.0 インスタンスごとに1個 ・フリート内のインスタンス数に比例してENI数が増加
・オートスケーリング時はIP/ENI枯渇に注意

データベース・ストレージ系

サービス ENI 消費パターン 備考
RDS インスタンスごとに1個以上 ・Multi-AZ構成ではスタンバイ側にもENIが作成される
・フェイルオーバー時はENIの付け替えが発生
Aurora インスタンスごとに1個 ・Readerを追加するとその数だけENI数が増加
・Serverless v2はスケーリングにより必要なENI/IPが動的に変化（サブネットのIP枯渇時はスケールアウト不可）
ElastiCache ノードごとに1個 ・各ノードがVPC内でプライベートIPを持つ
・Redis Cluster Modeではシャード追加に比例してENI数が増加
Amazon MQ ブローカーごとに1個以上 ・ブローカー作成時に専用ENIが自動作成される
・サービスが自動管理（削除不可）
Amazon MSK ブローカーごとに1個 ・ブローカー数に比例してENI数が増加
DocumentDB インスタンスごとに1個 ・Auroraと同様のアーキテクチャ
・リードレプリカ追加に比例してENI数が増加
Neptune インスタンスごとに1個 ・Auroraと同様のアーキテクチャ
・リードレプリカ追加に比例してENI数が増加
Redshift ノードごとに1個 ・クラスターのノード数に比例してENI数が増加
OpenSearch ノードごとに1個（VPCデプロイ時のみ） ・VPC内デプロイ時のみENIを消費
・データノード、マスターノード等の合計分が必要
・パブリックデプロイ時はENI消費なし
EFS マウントターゲットごとに1個 ・AZごとに1つのマウントターゲットが必要
・AZ数に比例してENI数が増加
FSx ファイルシステムごとに1個以上 ・ENIが自動作成される
・タイプ（Lustre/Windows/ONTAP/OpenZFS）や構成により数が異なる

データ転送・統合系

サービス ENI 消費パターン 備考
DataSync タスクごとに2〜4個 ・エージェント使用時は通常4個
・AWS内転送では通常2個（S3のみの場合は0個）
・タスク削除後もロケーションが残るとENIが解放されない
Transfer Family サーバー × AZごとに1個 ・VPCでホストする場合のみENIを消費
・パブリックエンドポイント選択時はENI消費なし
・複数AZに配置する場合はAZ数分のENIが必要
DMS レプリケーションインスタンスごとに1個以上 ・ソースDBとターゲットDBへの接続用にENIを使用
・Multi-AZ構成では追加のENIが必要
Glue ワーカーごとに1個（VPC接続時のみ） ・VPC内のデータソースに接続する場合のみ
・ジョブ終了後にENIが解放される
・同時実行数×ワーカー数分のENI/IPが必要
AppFlow PrivateLinkごとに1個（プライベート接続時のみ） ・プライベート接続（PrivateLink経由）を使用する場合のみ
・パブリック接続時はENI消費なし

ネットワーク・セキュリティ系

サービス ENI 消費パターン 備考
ELB/ALB/NLB AZごとに1個以上 ・有効化したAZ数分のENIが作成される
・トラフィック増加に応じてENI/ノード数が自動スケール
NAT Gateway ゲートウェイごとに1個 ・AZごとに作成が必要（高可用性のため複数AZ推奨）
・ENIにElastic IPが関連付けられる
VPC Endpoint (Interface) AZごとに1個 ・PrivateLinkを使用したAWSサービスやエンドポイントサービスへの接続
・有効化したAZ数分のENIが作成される
・Gateway型エンドポイント（S3、DynamoDB）はENI消費なし
CloudHSM HSMインスタンスごとに1個 ・高可用性のため複数AZに配置推奨（最低2 HSM = 2 ENI）
・サービスが自動管理（削除不可）
Client VPN サブネット関連付けごとに1個 ・サブネットとの関連付けごとにENIが作成される
・複数サブネットに関連付けると可用性向上＋ENI数増加
Transit Gateway アタッチメントのサブネットごとに1個 ・VPCアタッチメント時、指定したサブネットごとにENIが作成される
・複数AZを指定した場合はAZ数分のENIが必要
Network Firewall エンドポイントごとに1個 ・AZごとにファイアウォールエンドポイントを作成
・AZ数に比例してENI数が増加
Global Accelerator VPC内エンドポイントごとに1個 ・エンドポイントがVPC内リソース（ALB、EC2等）の場合にENIを消費
・インターネット向けALB等の場合はENI消費なし
Directory Service ドメインコントローラーごとに1個 ・AWS Managed Microsoft ADの場合、各AZにドメインコントローラーが配置される
・最小構成で2AZ = 2 ENI以上
WorkSpaces WorkSpaceごとに2個 ・各WorkSpaceに管理用ENI（AWS管理）とプライマリENI（顧客VPC）が作成される
・WorkSpaces数に比例してENI数が増加
Verified Access エンドポイントごとに1個 ・アプリケーションごとにエンドポイントを作成
・VPN不要でアプリケーションへのセキュアなアクセスを提供
GuardDuty (Malware Protection) スキャン実行ごとに一時的に1個 ・EBSマルウェアスキャンのためにサービスが一時的にENIを作成
・スキャン終了後に自動削除される
・通常のGuardDuty（脅威検知）はENI消費なし

分析・ML系

サービス ENI 消費パターン 備考
SageMaker リソースごとに1個以上（VPC実行時のみ） ・VPC内実行時のみENIを消費
・ノートブックインスタンス：1個以上
・推論エンドポイント：インスタンス数に比例してENI数が増加
・トレーニングジョブ：ジョブ実行中のみ使用、終了後に解放
EMR ノードごとに1個 ・マスター/コア/タスクノードそれぞれがENIを消費
・オートスケーリング時はノード数に比例してENI数が増加
・EMR on EKSの場合はPodごとのENI消費パターンが適用
Athena クエリ実行ごとに一時的に消費（VPC実行時のみ） ・プライベートサブネット内のデータソースにアクセスする場合
・Athenaワークグループの設定でVPC接続を指定
・クエリ実行中のみ使用、終了後に解放
QuickSight VPC接続ごとに複数 ・VPC内のデータソース（RDS、Redshift等）に接続する場合
・VPC接続設定でENIが作成される
・VPC接続未使用時はENI消費なし
MWAA (Airflow) 環境ごとに複数 ・Webサーバー、スケジューラー、ワーカー用に複数ENIが必要
・最低2つのAZにサブネット指定が必須
・ワーカーのオートスケーリングでENI数が変動
Amazon Managed Service for Apache Flink KPU（並列処理単位）ごとに1個（VPC接続時のみ） ・VPC内のリソース（RDS、ElastiCache等）にアクセスする場合
・KPU数に比例してENI数が変動
・サブネットのIP枯渇時はスケール不可

開発者ツール系

サービス ENI 消費パターン 備考
CodeBuild ビルドごとに1個以上（VPC実行時のみ） ・VPC内実行時のみENIを消費
・ビルド開始時にENI作成、完了後に解放
・同時ビルド数が多い場合はIP枯渇に注意
CodeDeploy デプロイ先に依存（サービス自体は消費なし） ・CodeDeploy自体はENI消費なし
・デプロイ先のEC2/ECS/LambdaがENIを消費
・Blue/Greenデプロイ時は一時的にリソースが倍増
CodeArtifact VPCエンドポイントのAZごとに1個 ・VPCエンドポイント（Interface型）を使用する場合のみ
・パブリックアクセス時はENI消費なし

アプリケーション統合

サービス ENI 消費パターン 備考
API Gateway (Private) VPCリンクごとに1個以上 ・プライベートAPIまたはVPC内リソースへの接続時に使用
・VPCリンク作成時にENIが作成される
・REST APIとHTTP APIでVPCリンクの動作が異なる
AppSync VPCデータソースごとに1個以上 ・GraphQL APIがVPC内データソース（RDS、ElastiCache等）に接続する場合
・パブリックデータソースのみの場合はENI消費なし
Step Functions 呼び出し先に依存（サービス自体は消費なし） ・Step Functions自体はENI消費なし
・Lambda（VPC）やECSタスクなど呼び出し先がENIを消費
SQS VPCエンドポイントのAZごとに1個 ・Interface型VPCエンドポイント使用時のみ
・パブリックアクセス時はENI消費なし
SNS VPCエンドポイントのAZごとに1個 ・Interface型VPCエンドポイント使用時のみ
・パブリックアクセス時はENI消費なし

ENI使用状況の確認コマンド

「で、うちの環境は実際どうなってるの？」という方のために、現状を把握できる CLI コマンドを用意しました。

ENIの使用状況を可視化する方法は他にもあります（AWS IPAM、自作ダッシュボード、サードパーティツール等）。今回はCloudshellで確認できるCLIベースの方法に絞って紹介します。

サブネットごとの空きIP数を確認

まずはサブネットの空き状況をチェックします。

aws ec2 describe-subnets \
   --query 'Subnets[*].[SubnetId,CidrBlock,AvailableIpAddressCount,Tags[?Key==`Name`].Value|[0]]' \
   --output table

出力例：

---------------------------------------------------------------------------------------------
|                                      DescribeSubnets                                      |
+---------------------------+-------------------+-------+-----------------------------------+
|  subnet-01234567890abcdef1 |  192.168.10.64/26  |  35   |  subnet1                         |
|  subnet-02345678901abcdef2 |  172.16.25.32/27   |  27   |  subnet2                         |
|  subnet-03456789012abcdef3 |  10.50.100.64/26   |  31   |  subnet3                         |
|  subnet-04567890123abcdef4 |  192.168.50.96/27  |  27   |  subnet4                         |
|  subnet-05678901234abcdef5 |  172.20.30.64/28   |  11   |  subnet5                         |
|  subnet-06789012345abcdef6 |  10.100.200.64/26  |  58   |  subnet6                         |
|  subnet-07890123456abcdef7 |  192.168.80.0/26   |  58   |  subnet7                         |
+---------------------------+-------------------+-------+-----------------------------------+

このコマンドでは、各サブネットのCIDR、残りのIPアドレス数、サブネット名を一覧で確認できます。
AvailableIpAddressCountが少ないサブネットは IP 枯渇リスクが高いため、優先的に対策を検討したいポイントです。

サービス別・サブネット別のENI使用状況を集計

次に、どのサービスがどのサブネットで ENI を使っているのか を集計してみます。

aws ec2 describe-network-interfaces \
   --query 'NetworkInterfaces[*].[InterfaceType,RequesterId,SubnetId]' \
   --output table | sort | uniq -c | sort -rn

--------------------------------------------------------------------------------------------------
|                                    DescribeNetworkInterfaces                                   |
+----------------------------+--------------------------------------+----------------------------+
     42 |  interface                 |  amazon-elb                          |  subnet-12345657890123456  |
     35 |  interface                 |  123456789012                        |  subnet-22345657890123456  |
     31 |  interface                 |  amazon-rds                          |  subnet-32345657890123456  |
     14 |  network_load_balancer     |  234567890123                        |  subnet-42345657890123456  |
      7 |  vpc_endpoint              |  345678901234                        |  subnet-62345657890123456  |
      3 |  transit_gateway           |  456789012345                        |  subnet-72345657890123456  |
      2 |  interface                 |  567890123456                        |  subnet-82345657890123456  |
      2 |  efs                       |  678901234567                        |  subnet-92345657890123456  |
      1 |  nat_gateway               |  789012345678                        |  subnet-10345657890123456  |
      1 |  lambda                    |  AROAXXXXXXXXXXXX:890123456789       |  subnet-11345657890123456  |
      1 |  global_accelerator_managed|  AROAXXXXXXXXXXXX:901234567890       |  subnet-12345657890123457  |
+----------------------------+--------------------------------------+----------------------------+

特定のサブネットに ENI が偏っている場合、そのサブネットから手を付けるとIP を整理・確保できると思います。

コマンドの解説

部分 説明
describe-network-interfaces アカウント内の全ENI情報を取得
--query '...[InterfaceType,RequesterId,SubnetId]' 必要な3項目のみ抽出
sort | uniq -c 同一パターンをカウント
sort -rn 件数の多い順に並び替え

出力項目の意味

InterfaceType（インターフェースタイプ）

ENIの用途・作成元サービスを示します。

値 作成元
interface 汎用（EC2、ALB/CLB、RDS、Lambda等）
network_load_balancer NLB
vpc_endpoint VPCエンドポイント
transit_gateway Transit Gateway
nat_gateway NAT Gateway
efs EFSマウントターゲット
lambda Lambda（VPC接続）

RequesterId（リクエスターID）

ENIを作成したエンティティを示します。

値 意味
amazon-サービス名 サービス（rdsやelbなど）が自動作成
AROA... IAMロール経由（Lambda、Global Accelerator等）

結果の読み方

上記の例では、subnet-12345657890123456 に ELB が 42 個の ENI を作成していることが分かります。
ENI が特定サブネットに偏っている場合は、以下のような改善を検討できます：

  • サブネット設計の見直し
  • ENI を大量に作成するサービスの配置変更
  • 不要リソースの削除

今回の主な対策

上記のコマンドで現状を把握した結果、今回の環境では以下の3点が改善ポイントとして見えてきました。

対象 問題 対策
VPC Lambda SGがバラバラでHyperplane ENIの共有が効いていない SG運用を共通化（原則）と個別化（例外）に整理
Interface VPC Endpoint 使われていない・低頻度のエンドポイントが残っている 棚卸しして削除、またはAZ数をスリム化
DataSync タスク削除後もロケーションが残りENIを占有 不要なロケーションを削除

以降のセクションでは、それぞれの具体的な対処方法を紹介します。

VPC Lambda のセキュリティグループを束ねよう

以下の名称は一例です。実際の環境に合わせて読み替えてください。

原則：共通SGを利用する

VPC内のLambda関数は、原則として共通のセキュリティグループ（例：common-vpc-lambda）を使用します。

目的： SG × サブネットの組み合わせを収束させ、Hyperplane ENI の共有・再利用を促進するため1

例外：個別SGの利用を許容するケース

以下の条件に該当する場合は、個別SGの利用を許容します。

  • 特定のLambdaに厳格な通信制御が必要な場合（例：外部ネットワークとの個別接続要件、通信元/先の厳密な制限）
  • セキュリティポリシー上、明確なネットワーク分離が求められる場合

共通SGの設定例

項目 設定値
SG名 common-vpc-lambda
Inbound（受信） 許可なし
Outbound（送信） すべて許可（0.0.0.0/0）

IaCでの参照方法（例）

SGのIDをSSMパラメータに格納しておき、Lambda作成時に参照する運用がおすすめです。

項目 値
SSMパラメータ名 /network/security-group/common-vpc-lambda
格納する値 sg-0123456789abcdef0
用途 CloudFormation / CDK などでLambda作成時にSGを指定

ポイント

  • SGを統一し、サブネットも用途ごとに整理することで、Hyperplane ENIの組み合わせを最小化できます。
  • 「Lambdaごとに個別SG」という設計は避けましょう。ENI数＝IP消費の増加につながります。

Interface VPC Endpoint を棚卸ししよう

目的：未使用または利用頻度が低いエンドポイントを特定し、削除やAZ削減を判断するための実践的な方法です。

1. メトリクスの存在確認（CloudWatch）

まず、対象エンドポイントのメトリクスが発行されているか確認します。

aws cloudwatch list-metrics \
  --namespace "AWS/PrivateLinkEndpoints" \
  --region ap-northeast-1

ここで BytesProcessed メトリクスとディメンション（VPC Endpoint Id、Service Nameなど）が表示されれば、次のステップへ進みます2。

2. 14日間のトラフィック確認（CLI）

特定エンドポイントの過去14日間のトラフィックを1日単位で確認します。

aws cloudwatch get-metric-statistics \
  --namespace "AWS/PrivateLinkEndpoints" \
  --metric-name "BytesProcessed" \
  --dimensions \
    "Name=Endpoint Type,Value=Interface" \
    "Name=Service Name,Value=com.amazonaws.ap-northeast-1.サービス名" \
    "Name=VPC Endpoint Id,Value=vpce-xxxxxxxxxxxxxxxxx" \
    "Name=VPC Id,Value=vpc-xxxxxxxxxxxxxxxxx" \
  --start-time 2025-03-01T00:00:00Z \
  --end-time   2025-03-14T00:00:00Z \
  --period 86400 \
  --statistics Average \
  --region ap-northeast-1

結果例

  • 未使用：
{
    "Label": "BytesProcessed",
    "Datapoints": []
}
  • 利用中：
{
    "Label": "BytesProcessed",
    "Datapoints": [
        {
            "Timestamp": "2025-03-09T00:00:00+00:00",
            "Average": 18119.454545454544,
            "Unit": "Count"
        },
        {
            "Timestamp": "2025-03-08T00:00:00+00:00",
            "Average": 17483.0,
            "Unit": "Count"
        },
        {
            "Timestamp": "2025-03-02T00:00:00+00:00",
            "Average": 17724.894736842107,
            "Unit": "Count"
        },
        {
            "Timestamp": "2025-03-10T00:00:00+00:00",
            "Average": 16886.275862068964,
            "Unit": "Count"
        }
    ]
}

通信先等を確認したい場合は、VPCフローログの有効化やCloudWatch Logsにロググループが存在していることが条件ですが、VPCフローログやCloudWatch Logs Insightsで、クロスチェックすることで、洗い出しができるかと思います3。
本記事では、通信先特定までは範囲に含んでいないため、割愛します。
また、似た事例として、TGW アタッチメント、VPC Link、Client VPNも廃止漏れしやすいため、ここらへんも確認しておくとよいかもしれません。

DataSync のロケーション、残ってないか確認しよう

問題

DataSyncのロケーションは、タスクを削除してもロケーション自体が残り続け、ENIを占有し続けることがあります4。

確認手順

1. タスク一覧の取得

aws datasync list-tasks --output table

実行例：

$ aws datasync list-tasks --output table
-------------------------------------------------------------------------------------------------------------------------
|                                                       ListTasks                                                       |
+-----------------------------------------------------------------------------------------------------------------------+
||                                                        Tasks                                                        ||
|+--------------+------------+----------------------------------------------------------------------------+------------+|
||     Name     |  Status    |                                  TaskArn                                   | TaskMode   ||
|+--------------+------------+----------------------------------------------------------------------------+------------+|
||  task-a      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef0  |  BASIC     ||
||  task-b      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef1  |  BASIC     ||
||  task-c      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef2  |  BASIC     ||
||  task-d      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef3  |  BASIC     ||
||  task-e      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef4  |  BASIC     ||
||  task-f      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef5  |  BASIC     ||
||  task-g      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef6  |  BASIC     ||
||  task-h      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef7  |  BASIC     ||
||  task-i      |  AVAILABLE |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef8  |  BASIC     ||
|+--------------+------------+----------------------------------------------------------------------------+------------+|

2. ロケーション一覧の確認

タスクに紐づいていないロケーションがないか確認します。

aws datasync list-locations --output table

実行例：

$ aws datasync list-locations --output table
--------------------------------------------------------------------------------------------------------------------------------------------------
|                                                                  ListLocations                                                                 |
+------------------------------------------------------------------------------------------------------------------------------------------------+
||                                                                   Locations                                                                  ||
|+------------------------------------------------------------------------------+---------------------------------------------------------------+|
||                                  LocationArn                                 |                          LocationUri                          ||
|+------------------------------------------------------------------------------+---------------------------------------------------------------+|
||  arn:aws:datasync:ap-northeast-1:123456789012:location/loc-0123456789abcdef1 |  s3://example-bucket/path/                                    ||
||  arn:aws:datasync:ap-northeast-1:123456789012:location/loc-0123456789abcdef2 |  efs://fs-0123456789abcdef0.efs.ap-northeast-1.amazonaws.com/ ||
||  arn:aws:datasync:ap-northeast-1:123456789012:location/loc-0123456789abcdef3 |  nfs://192.168.1.100/share/                                   ||
|+------------------------------------------------------------------------------+---------------------------------------------------------------+|

ポイント
LocationUriのプレフィックスでロケーションタイプを判別できます

  • s3:// → S3
  • efs:// → EFS
  • nfs:// → NFS

3. タスクの詳細確認（ロケーションとENIの紐付け）

手順1で取得したTaskArnを指定して、詳細を確認します。

aws datasync describe-task \
  --task-arn "arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef0" \
  --output table

実行例：

$ aws datasync describe-task --task-arn "arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef0" --output table
-----------------------------------------------------------------------------------------------------------
|                                              DescribeTask                                               |
+------------------------+--------------------------------------------------------------------------------+
|  CloudWatchLogGroupArn |  arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/datasync              |
|  CreationTime          |  2025-12-25T13:24:55.022000+00:00                                              |
|  DestinationLocationArn|  arn:aws:datasync:ap-northeast-1:123456789012:location/loc-0123456789abcdef1   |
|  Name                  |  sample-task                                                                   |
|  SourceLocationArn     |  arn:aws:datasync:ap-northeast-1:123456789012:location/loc-0123456789abcdef2   |
|  Status                |  AVAILABLE                                                                     |
|  TaskArn               |  arn:aws:datasync:ap-northeast-1:123456789012:task/task-0123456789abcdef0      |
|  TaskMode              |  BASIC                                                                         |
+------------------------+--------------------------------------------------------------------------------+
||                                    DestinationNetworkInterfaceArns                                    ||
|+-------------------------------------------------------------------------------------------------------+|
||  arn:aws:ec2:ap-northeast-1:123456789012:network-interface/eni-0123456789abcdef1                      ||
||  arn:aws:ec2:ap-northeast-1:123456789012:network-interface/eni-0123456789abcdef2                      ||
||  arn:aws:ec2:ap-northeast-1:123456789012:network-interface/eni-0123456789abcdef3                      ||
||  arn:aws:ec2:ap-northeast-1:123456789012:network-interface/eni-0123456789abcdef4                      ||
|+-------------------------------------------------------------------------------------------------------+|
||                                                Options                                                ||
|+-------------------------------------------------------+-----------------------------------------------+|
||  Atime                                                |  BEST_EFFORT                                  ||
||  BytesPerSecond                                       |  1048576                                      ||
||  Gid                                                  |  INT_VALUE                                    ||
||  LogLevel                                             |  TRANSFER                                     ||
||  Mtime                                                |  PRESERVE                                     ||
||  ObjectTags                                           |  PRESERVE                                     ||
||  OverwriteMode                                        |  ALWAYS                                       ||
||  PosixPermissions                                     |  PRESERVE                                     ||
||  PreserveDeletedFiles                                 |  REMOVE                                       ||
||  PreserveDevices                                      |  NONE                                         ||
||  SecurityDescriptorCopyFlags                          |  NONE                                         ||
||  TaskQueueing                                         |  ENABLED                                      ||
||  TransferMode                                         |  CHANGED                                      ||
||  Uid                                                  |  INT_VALUE                                    ||
||  VerifyMode                                           |  ONLY_FILES_TRANSFERRED                       ||
|+-------------------------------------------------------+-----------------------------------------------+|

4. 確認ポイント

describe-taskの結果から以下を確認します。

確認項目 説明
SourceLocationArn 転送元ロケーション
DestinationLocationArn 転送先ロケーション
DestinationNetworkInterfaceArns タスクが使用しているENI（=プライベートIP消費）

転送パターンによってENI消費数が異なります5。

転送パターン ENI消費数（目安）
DataSyncエージェント使用（オンプレミス→AWS等） 4個/タスク
AWS内転送（EFS→EFS、FSx→S3等） 2個/タスク
S3のみのロケーション 0個

ポイント

  • DestinationNetworkInterfaceArnsにENIが表示されている場合、そのタスクがENI（プライベートIP）を消費しています。
  • 上記例ではDataSyncエージェントを利用しているため、1タスクあたり4つのENIが使用されており、4つのプライベートIPを消費しています。
  • 不要なタスクを削除することで、関連するENIも解放されます。

不要なタスクがある場合

注意

  • タスクを削除してもロケーションは自動削除されません。
  • ENIを解放するには、タスクの削除に加えてロケーションの削除も必要です。
  • ロケーション削除前に、他のタスクで使用されていないことを確認してください。

おわりに

今回は「サブネットのIPが足りない」という課題に対して、以下の3点を実施しました。

対象 実施内容
VPC Lambda セキュリティグループを共通化し、Hyperplane ENIの共有を促進
Interface VPC Endpoint 未使用エンドポイントを棚卸しして削除
DataSync 放置されていたロケーションを削除してENIを解放

もちろん、これ以外にも改善できるポイントはあると思います。環境によっては、別のアプローチが有効なケースもあるでしょう。

調査を通じて改めて感じたのは、「IPが足りない」の原因は新規リソースの増加だけではないということです。

放置されたリソース、最適化されていない設計、削除し忘れ——こうした積み重ねが、気づかないうちにIPを圧迫していました。

定期的な棚卸しと、作成時のルール整備（LambdaのSG共通化など）を意識するだけでも、枯渇リスクはかなり抑えられると思います。

同じ悩みを持つ方の参考になれば幸いです。

参考文献

  1. Configuring VPC access for Lambda functions - AWS Lambda ↩

  2. AWS PrivateLink metrics - Amazon CloudWatch ↩

  3. Logging IP traffic using VPC Flow Logs - Amazon VPC ↩

  4. How AWS DataSync works - AWS DataSync ↩

  5. Network interfaces for AWS DataSync transfers - AWS DataSync ↩

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?