AWS PrivateLink完全ガイド：Interface型VPCエンドポイントとEndpoint Serviceの違い、そして他社へのプライベート公開

Posted at 2026-07-03

概要

AWS PrivateLinkにおけるInterface型VPCエンドポイントの「名前」の誤解を解消し、VPC Endpoint Serviceを使った他社・他アカウントへのプライベート公開方法を実践的に解説します。オンプレミス接続の代替手段についても紹介します。

はじめに
Interface型VPCエンドポイントの名前の正体
VPC Endpoint Serviceとは
他社・他アカウントへのプライベート公開
具体的な実装例：決済代行業者への公開
相手がAWSアカウントを持たない場合
注意点とベストプラクティス
終わりに

1. はじめに

AWS PrivateLinkを利用する際、「Interface型VPCエンドポイントに任意の名前をつけたい」という要望をよく耳にします。しかし、実はここに大きな誤解があります。コンソールで入力できる「名前」は、単なる見た目のラベル（Nameタグ）であり、エンドポイント自体のDNS名とは全く別物なのです。

本記事では、Interface型VPCエンドポイントとVPC Endpoint Serviceの仕組みを正確に理解し、他社や他アカウントにプライベートにサービスを公開する方法を実践的に解説します。

2. Interface型VPCエンドポイントの名前の正体

付けられる「名前」の実態

Interface型VPCエンドポイントをAWSマネジメントコンソールで作成する際、「名前」欄に任意の文字列を入力できます。しかし、この名前はNameタグとして保存されるだけで、エンドポイントの識別や通信には一切影響しません。

実際にエンドポイントが持つのは以下の2つです。

エンドポイントID: vpce-xxxxxxxxxx という形式の一意な識別子
自動生成されるDNS名: vpce-xxxxxxxxxx-yyyyyyyy.ssm.ap-northeast-1.vpce.amazonaws.com のような形式

これらは変更不可であり、通信時には自動生成されたDNS名を使用します。

なぜこのような仕様になっているのか

AWS PrivateLinkは、ENI（Elastic Network Interface）を使ってプライベートIPアドレスでサービスにアクセスする仕組みです。エンドポイントごとに一意のDNS名が必要であり、システム上の一貫性を保つために自動生成される形式が採用されています。

3. VPC Endpoint Serviceとは

AWSサービス向けエンドポイントとの違い

多くの人が利用しているのは、AWSが提供するサービス（SSM、S3、ECRなど）へのエンドポイントです。これらのサービス名は、com.amazonaws.<region>.ssm のような形式で固定されており、AWSがあらかじめ用意した「VPC Endpoint Service」に接続しています。

一方、自分のサービスを他者に公開したい場合は、自分で「VPC Endpoint Service」を作成します。両者は接続先が違うだけで、仕組みは同じPrivateLinkです。

VPC Endpoint Serviceのサービス名

自分で作成したVPC Endpoint Serviceのサービス名は、以下の形式で自動的に決まります。

com.amazonaws.vpce.<region>.vpce-svc-xxxxxxxxxx

このサービス名も変更できませんが、Private DNS名を関連付けることで、api.example.co.jp のような独自ドメインでアクセスできるようになります。

4. 他社・他アカウントへのプライベート公開

VPC Endpoint Serviceによる公開の仕組み

AWS PrivateLinkを使えば、自社のサービスを他社や他のAWSアカウントにインターネットを経由せずにプライベート公開できます。具体的には以下の流れになります。

公開側（プロバイダ）: Network Load Balancer（NLB）を配置し、その背後にVPC Endpoint Serviceを作成
許可設定: 接続を許可するAWSアカウントID、Organizations、またはOUを指定
利用側（コンシューマ）: 自分のVPC内にInterface型VPCエンドポイントを作成し、プロバイダのサービス名を指定
接続確立: プロバイダ側で接続リクエストを承認（または自動承認設定）

Private DNS名を使った独自ドメインでの公開

より実用的な運用では、api.partner.example.co.jp のような独自ドメインを使いたい場合があります。これは以下の手順で実現できます。

プロバイダ側でPrivate DNS名を設定: VPC Endpoint Serviceの設定で独自ドメイン名を関連付け
ドメイン所有の検証: AWSが指定するTXTレコードをDNSに追加し、ドメインの所有を証明
コンシューマ側で有効化: Interface型VPCエンドポイントの作成時に「プライベートDNSを有効化」オプションを選択

この設定により、コンシューマ側では vpce-xxxx.vpce.amazonaws.com のような複雑なDNS名ではなく、api.partner.example.co.jp で直接アクセスできるようになります。

AWS公式ドキュメント ( https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/manage-dns-names.html ) では、『Private DNS名を使用すると、サービスコンシューマーがサービスに接続する方法が簡素化されます』と説明されています。

5. 具体的な実装例：決済代行業者への公開

シナリオ

あなたの会社がFargateでホストしている決済APIを、決済代行業者にプライベートに公開したいとします。インターネット経由では機密情報の漏洩リスクがあるため、AWS PrivateLinkを使ってセキュアな接続を確立します。

公開側（プロバイダ）の設定手順

ステップ1: Network Load Balancerの作成

# NLBを作成（ap-northeast-1リージョン）
aws elbv2 create-load-balancer \
  --name payment-api-nlb \
  --type network \
  --subnets subnet-xxxxx subnet-yyyyy \
  --scheme internal \
  --region ap-northeast-1

ステップ2: ターゲットグループの設定

# ターゲットグループを作成
aws elbv2 create-target-group \
  --name payment-api-targets \
  --protocol TCP \
  --port 443 \
  --vpc-id vpc-xxxxx \
  --target-type ip \
  --region ap-northeast-1

# Fargateタスクをターゲットとして登録
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:... \
  --targets Id=10.0.1.100,Port=443 \
  --region ap-northeast-1

ステップ3: VPC Endpoint Serviceの作成

# VPC Endpoint Serviceを作成
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:... \
  --acceptance-required \
  --region ap-northeast-1

作成されたサービス名は com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxx のような形式になります。

ステップ4: 許可プリンシパルの設定

# 決済代行業者のAWSアカウントIDを許可
aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id vpce-svc-xxxxx \
  --add-allowed-principals arn:aws:iam::123456789012:root \
  --region ap-northeast-1

ステップ5: Private DNS名の設定（オプション）

# Private DNS名を関連付け
aws ec2 modify-vpc-endpoint-service-configuration \
  --service-id vpce-svc-xxxxx \
  --private-dns-name api.payment.example.co.jp \
  --region ap-northeast-1

# 検証用TXTレコードを確認
aws ec2 describe-vpc-endpoint-service-configurations \
  --service-ids vpce-svc-xxxxx \
  --region ap-northeast-1

Route 53またはお使いのDNSプロバイダで、表示されたTXTレコードを追加します。

# 検証を開始
aws ec2 start-vpc-endpoint-service-private-dns-verification \
  --service-id vpce-svc-xxxxx \
  --region ap-northeast-1

利用側（コンシューマ）の設定手順

ステップ1: Interface型VPCエンドポイントの作成

決済代行業者側のAWSアカウントで以下を実行します。

# VPCエンドポイントを作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-yyyyy \
  --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxx \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-aaaaa subnet-bbbbb \
  --security-group-ids sg-xxxxx \
  --private-dns-enabled \
  --region ap-northeast-1

--private-dns-enabled オプションを指定することで、api.payment.example.co.jp での名前解決が可能になります。

ステップ2: セキュリティグループの設定

# VPCエンドポイントのセキュリティグループにHTTPSアクセスを許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 10.1.0.0/16 \
  --region ap-northeast-1

ステップ3: 接続確認

# エンドポイントからAPIにアクセス
curl https://api.payment.example.co.jp/v1/transactions

または、プライベートDNSを有効化していない場合は以下のように直接エンドポイントDNS名を使用します。

curl https://vpce-xxxxx-yyyyy.vpce-svc-xxxxx.ap-northeast-1.vpce.amazonaws.com/v1/transactions

6. 相手がAWSアカウントを持たない場合

PrivateLinkの制約

AWS PrivateLinkは、両側がAWS環境を持っている場合にのみ使用できます。相手が完全にオンプレミス環境のみの場合、PrivateLink単体では接続できません。

代替手段1: AWS Site-to-Site VPN

最もシンプルな代替手段は、AWS Site-to-Site VPNです。オンプレミス側のルーターとAWS VPCをIPsec VPNで接続します。

メリット

比較的低コストで導入可能
セットアップが比較的簡単
インターネット経由だが暗号化された通信

デメリット

インターネット経由のため、帯域や遅延が不安定になる可能性
大容量データ転送には不向き

構成例

# VPNゲートウェイを作成
aws ec2 create-vpn-gateway \
  --type ipsec.1 \
  --amazon-side-asn 65000 \
  --region ap-northeast-1

# VPCにアタッチ
aws ec2 attach-vpn-gateway \
  --vpn-gateway-id vgw-xxxxx \
  --vpc-id vpc-xxxxx \
  --region ap-northeast-1

# カスタマーゲートウェイを作成（オンプレミス側のルーターIPを指定）
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 203.0.113.5 \
  --bgp-asn 65001 \
  --region ap-northeast-1

# VPN接続を作成
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --vpn-gateway-id vgw-xxxxx \
  --customer-gateway-id cgw-xxxxx \
  --region ap-northeast-1

AWS公式ドキュメント ( https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPC_VPN.html ) では、『AWS Site-to-Site VPN を使用すると、オンプレミスネットワークまたはブランチオフィスサイトを Amazon Virtual Private Cloud に接続できます』と説明されています。

代替手段2: AWS Direct Connect

より安定した高品質な接続が必要な場合は、AWS Direct Connectを使用します。これは、通信事業者の閉域ネットワークを経由して、物理的な専用線でAWSに接続する方式です。

メリット

インターネットを経由しない高セキュリティ
安定した帯域と低遅延
大容量データ転送に適している
ネットワークコストの削減（大量データ転送時）

デメリット

初期費用と月額費用が高い
導入に数週間〜数ヶ月かかる
通信事業者との調整が必要

料金例（2025年1月時点、ap-northeast-1）

Direct Connectの料金は、ポート時間料金とデータ転送料金の2つで構成されます。通信事業者のパートナーサービスを利用する場合（ホスト型接続）の例です。

帯域	ポート時間料金（月額概算）	データ転送アウト料金
50Mbps	約$36	$0.09/GB
100Mbps	約$72	$0.09/GB
1Gbps	約$720	$0.09/GB

※料金は変動する可能性があります。最新の料金は AWS Direct Connect料金ページ ( https://aws.amazon.com/jp/directconnect/pricing/ ) をご確認ください。

構成例

# Direct Connect Gatewayを作成
aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name my-dx-gateway \
  --amazon-side-asn 64512 \
  --region ap-northeast-1

# Transit Gatewayと関連付け（複数VPC接続の場合）
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id dx-gw-xxxxx \
  --gateway-id tgw-xxxxx \
  --region ap-northeast-1

# 仮想インターフェース（VIF）を作成
aws directconnect create-private-virtual-interface \
  --connection-id dxcon-xxxxx \
  --new-private-virtual-interface \
    VirtualInterfaceName=my-vif,VlanId=100,Asn=65001,\
    AddressFamily=ipv4,CustomerAddress=192.168.1.1/30,\
    AmazonAddress=192.168.1.2/30,DirectConnectGatewayId=dx-gw-xxxxx \
  --region ap-northeast-1

代替手段3: ハイブリッド構成（Direct Connect + VPN）

冗長性とコストのバランスを取る場合、Direct ConnectをメインにしてSite-to-Site VPNをバックアップとするハイブリッド構成も推奨されます。

比較項目	Site-to-Site VPN	Direct Connect	ハイブリッド構成
導入期間	数時間〜数日	数週間〜数ヶ月	Direct Connectに準じる
月額コスト	低（VPN接続料金のみ）	高（専用線料金）	中（両方の合計）
通信品質	不安定（インターネット依存）	安定（専用線）	安定（DX優先、VPNフェイルオーバー）
セキュリティ	高（IPsec暗号化）	非常に高（物理的分離）	非常に高
適用ケース	小規模、コスト重視	大規模、品質重視	エンタープライズ、冗長性重視

最小構成のAWSアカウントを用意する方法

どうしても相手がAWSアカウントを持てない場合でも、最小構成のAWSアカウント + VPCを相手側に用意してもらい、そこにInterface型VPCエンドポイントを作成することで、PrivateLinkを活用できます。

この場合、相手側のオンプレミス環境からそのVPCへはSite-to-Site VPNやDirect Connectで接続します。この構成により、「オンプレミス → 相手のVPC → PrivateLink → あなたのVPC」という経路が確立されます。

7. 注意点とベストプラクティス

Network Load Balancer必須（ALB不可）

VPC Endpoint Serviceの背後には、必ずNetwork Load Balancer（NLB）を配置する必要があります。Application Load Balancer（ALB）は使用できません。

理由は、AWS公式ドキュメント ( https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/configure-endpoint-service.html ) で『VPC エンドポイントサービスは Network Load Balancer をサポートします』と説明されている通り、PrivateLinkはTCP/UDPレベルの負荷分散を前提に設計されているためです。

クロスリージョンアクセスの考慮

2024年11月のアップデートにより、Interface型VPCエンドポイントはクロスリージョン接続をサポートするようになりました。これにより、ap-northeast-1（東京）リージョンのVPCから、us-east-1（バージニア北部）リージョンのAWSサービスへプライベートにアクセスできます。

ただし、クロスリージョンアクセスには追加料金が発生します。

料金について（2025年1月時点、ap-northeast-1）

Interface型VPCエンドポイントの料金

項目	料金
VPCエンドポイント時間料金	$0.014/時間/AZ
データ処理料金（最初の1PBまで）	$0.01/GB
データ処理料金（次の4PBまで）	$0.006/GB
データ処理料金（5PB以上）	$0.004/GB

例えば、3つのAZにエンドポイントを配置し、月間100GBのデータを処理した場合：

エンドポイント料金: $0.014 × 24時間 × 30日 × 3AZ = $30.24/月
データ処理料金: 100GB × $0.01 = $1.00/月
合計: 約$31.24/月

VPC Endpoint Serviceの料金

プロバイダ側でEndpoint Serviceを作成する場合、追加料金はかかりません（NLBの料金のみ）。ただし、クロスリージョンアクセスを有効にした場合、リモートリージョンごとに$0.05/時間の料金が発生します。

※料金は変動する可能性があります。最新情報は AWS PrivateLink料金ページ ( https://aws.amazon.com/jp/privatelink/pricing/ ) をご確認ください。

セキュリティグループの設計

VPCエンドポイントを使用する際は、適切なセキュリティグループの設定が重要です。

推奨設定:

VPCエンドポイントのセキュリティグループ: 接続元（EC2、Lambda等）からの通信を許可
NLBのターゲット（Fargate、EC2等）のセキュリティグループ: VPCエンドポイントのサブネットCIDRからの通信を許可

接続承認フロー

VPC Endpoint Serviceは、デフォルトで手動承認が必要です。セキュリティ上問題ない場合は、自動承認に変更できます。

# 自動承認を有効化
aws ec2 modify-vpc-endpoint-service-configuration \
  --service-id vpce-svc-xxxxx \
  --acceptance-required false \
  --region ap-northeast-1

モニタリングとログ

CloudWatch メトリクスとVPC Flow Logsを活用して、エンドポイントの使用状況とトラフィックを監視しましょう。

# VPC Flow Logsを有効化
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxxxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --region ap-northeast-1

8. 終わりに

本記事では、AWS PrivateLinkにおけるInterface型VPCエンドポイントとVPC Endpoint Serviceの違い、そして他社・他アカウントへのプライベート公開方法を実践的に解説しました。

重要なポイントをまとめます。

Interface型VPCエンドポイントの「名前」はタグであり、DNS名は自動生成される
AWSサービス向けと自分のサービスの公開は、同じPrivateLinkの仕組みを使用
VPC Endpoint Serviceを使えば、他社・他アカウントにプライベート公開できる
Private DNS名を設定すれば、独自ドメインでのアクセスが可能
相手がAWSアカウントを持たない場合は、Site-to-Site VPNやDirect Connectを検討
NLBは必須、ALBは使用不可

AWS PrivateLinkは、セキュアなマルチアカウント・マルチ組織間の接続を実現する強力な機能です。本記事が、皆さんのPrivateLink活用の一助となれば幸いです。

次のステップ

AWS PrivateLink公式ドキュメントで詳細な仕様を確認
AWS Direct Connect料金ページで接続方法とコストを比較
実際に検証環境でVPC Endpoint Serviceを作成してみる
CloudFormationやTerraformでのIaCテンプレートを作成

参考文献・参考サイト

「VPC エンドポイントサービス」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/configure-endpoint-service.html
「プライベート DNS 名」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/manage-dns-names.html
「AWS Site-to-Site VPN とは」AWS Documentation, https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPC_VPN.html
「AWS PrivateLink 料金」AWS, https://aws.amazon.com/jp/privatelink/pricing/
「AWS Direct Connect 料金」AWS, https://aws.amazon.com/jp/directconnect/pricing/
アルテリア・ネットワークス「AWSとオンプレミス環境を接続する3つの方法と6つの事例」, https://www.arteria-net.com/business/column/awsconnect
クラスメソッド「「オンプレとAWSをDirect Connectで接続したい」と言われたときの第一歩」DevelopersIO, 2025年1月8日, https://dev.classmethod.jp/articles/aws-direct-connect-first-step-idea/

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS PrivateLink完全ガイド：Interface型VPCエンドポイントとEndpoint Serviceの違い、そして他社へのプライベート公開

概要

目次

1. はじめに

2. Interface型VPCエンドポイントの名前の正体

付けられる「名前」の実態

なぜこのような仕様になっているのか

3. VPC Endpoint Serviceとは

AWSサービス向けエンドポイントとの違い

VPC Endpoint Serviceのサービス名

4. 他社・他アカウントへのプライベート公開

VPC Endpoint Serviceによる公開の仕組み

Private DNS名を使った独自ドメインでの公開

5. 具体的な実装例：決済代行業者への公開

シナリオ

公開側（プロバイダ）の設定手順

ステップ1: Network Load Balancerの作成

ステップ2: ターゲットグループの設定

ステップ3: VPC Endpoint Serviceの作成

ステップ4: 許可プリンシパルの設定

ステップ5: Private DNS名の設定（オプション）

利用側（コンシューマ）の設定手順

ステップ1: Interface型VPCエンドポイントの作成

ステップ2: セキュリティグループの設定

ステップ3: 接続確認

6. 相手がAWSアカウントを持たない場合

PrivateLinkの制約

代替手段1: AWS Site-to-Site VPN

メリット

デメリット

構成例

代替手段2: AWS Direct Connect

メリット

デメリット

料金例（2025年1月時点、ap-northeast-1）

構成例

代替手段3: ハイブリッド構成（Direct Connect + VPN）

最小構成のAWSアカウントを用意する方法

7. 注意点とベストプラクティス

Network Load Balancer必須（ALB不可）

クロスリージョンアクセスの考慮

料金について（2025年1月時点、ap-northeast-1）

Interface型VPCエンドポイントの料金

VPC Endpoint Serviceの料金

セキュリティグループの設計

接続承認フロー

モニタリングとログ

8. 終わりに

次のステップ

参考文献・参考サイト