はじめに
こんにちは。株式会社両備システムズの渋瀬です。
この記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の39日目の記事となります。
過去の投稿（リンク集）はこちらからご覧ください。
2026 Japan AWS Jr. Champions 真夏のQiitaリレー：過去の投稿
2026年6月11日、AWS公式ブログでResource GatewayとResource Endpointを使ってInterface VPC Endpointを集約するアーキテクチャが紹介されました。
Interface VPC Endpointの集約自体は以前から可能でした。共有VPCにEndpointをまとめ、各VPCからTransit Gateway（TGW）やVPC Peeringを通して利用する方式です。
しかし、TGWには時間料金とデータ処理料金があり、TGWとVPC PeeringのどちらにもCIDR重複という悩みがあります。NLB、VPC Endpoint Service、Squidを組み合わせて回避する構成まで考えましたが、今度はプロキシの運用を抱えることになります。
そんな中で紹介されたのが、Resource GatewayによるInterface VPC Endpoint集約構成です。
そこで今回は、公式ブログの「Use case 4」を参考に、CIDRが重複する2つのVPCを用意し、TGW、VPC Peering、NAT Gatewayを使わずに、Consumer VPCのECS on Fargateから共有VPCのInterface VPC Endpointを利用できるか試しました。
1. 従来のVPC Endpoint集約方式と課題
なぜInterface VPC Endpointを集約したいのか
特に完全閉域を要求される環境において、Interface Endpointは必須となるサービスです。
しかし、Interface Endpointには、Endpoint数と配置するAvailability Zone（AZ）数に応じた時間料金がかかります。複数のVPCで同じAWSサービスを利用する場合、VPCごとにEndpointを作ると固定費と管理対象が増えていきます。
そこで、Interface Endpointを共有VPCへ集約するアーキテクチャが候補になります。
Transit Gatewayによる集約
共有VPCと各Consumer VPCをTGWへ接続し、共有VPCに作成したInterface Endpointへルーティングする方式です。
TGWは、VPC間通信、集中型NAT、Network Firewallなどもまとめられる汎用的なネットワークハブです。すでにTGWをネットワーク基盤として利用している環境なら、Interface Endpointの集約にも活用できます。
一方、目的がInterface Endpointの共有だけであれば、VPC Attachmentの時間料金とデータ処理料金が追加されます。コスト最適化のためにEndpointを集約したのに、別の固定費とデータ処理費が増える点は無視できません。
VPC Peeringによる集約
VPC PeeringでConsumer VPCと共有VPCを直接接続する方式です。TGWの利用料金を避けられるため、VPC数が少ない場合には有力です。
Consumer VPCから通常のAWSサービスFQDNを利用するには、Route 53 Private Hosted ZoneとDNSレコードの設計も必要にはなりますが、AWS利用料のコスト最適化という観点では理にかなった対処に思えます。
両方式に残るCIDR重複問題
TGWとVPC Peeringは、どちらもVPC間のIPルーティングを前提とします。そのため、接続するVPCのCIDRが重複していると、そのままでは相互接続できません。
Interface Endpointを必要とする環境では、「インターネットを経由させず、閉域でAWSサービスへ接続したい」という要件も多くあります。ところが、組織内の全VPCだけでなく、オンプレミス、買収した企業、パートナー環境まで含めてCIDRの一意性を維持し続けるのは簡単ではありません。
| 方式 | 主なメリット | 主な課題 |
|---|---|---|
| TGW | 多数のVPCやオンプレミス接続を一元管理できる | Attachment・データ処理料金、CIDR重複 |
| VPC Peering | 小規模なら構成が単純でTGW料金がない | 接続数の増加、非推移、CIDR重複、DNS管理 |
完全閉域のためにEndpointを集約したいのに、その前提として全ネットワークのCIDR調整が必要になる。これは運用管理の面で厳しいものがあります。
2. NLB＋SquidでPrivateLink公開する案も考えた
CIDR重複を回避する方法として、次のような構成も考えました。
Squidをフォワードプロキシとして動かし、NLBとVPC Endpoint Serviceを使って各Consumer VPCへPrivateLinkで公開する構成です。PrivateLinkであればVPC間の通常ルーティングを作らないため、CIDR重複を回避できます。
ただし、これはEndpointを共有するための仕組みを自分たちで運用する構成です。
- Squidコンテナのアップデートと脆弱性対応
- ECS Service、NLB、Target Groupの監視
- スケーリングと可用性設計
- プロキシ許可リストの管理
- NLB、ECSの料金
さらに、すべてのクライアントがプロキシ接続先を自由に変更できるとは限りません。特にFargateがタスク起動時に行うECRイメージ取得は、アプリケーションコンテナ内の通信とは別に扱われます。
技術的には面白いものの、「Interface Endpointの運用を減らしたい」という目的に対し、新たなプロキシ基盤の運用を増やしてしまいます。この案は採用に至りませんでした。
3. Resource Gatewayによる集約構成が紹介された
Resource GatewayとResource Endpoint自体は、2024年12月にAWS PrivateLinkの機能として発表されました。
そして2026年6月のAWS公式ブログで、具体的な実装パターンの1つとして「TGWやVPC Peeringを経由せず、AWSサービス向けInterface Endpointを集約する構成」が紹介されました。
公式ブログでは「Use case 4: Centralizing the interface endpoints for AWS services without going over Transit Gateway or VPC peering」として説明されています。
構成要素
この構成では、次の4つを使用します。
| リソース | 役割 |
|---|---|
| Resource Gateway | 共有VPC内のリソースへ到達する入口 |
| Resource Configuration | 公開対象となるDNS名、IPアドレス、ARNなどの定義 |
| Resource Configuration Group | 複数のResource Configurationをまとめるグループ |
| Resource Endpoint | Consumer VPCに配置する接続口 |
共有VPCにある各Interface EndpointのリージョナルDNS名をDNS型Resource Configurationとして登録し、それらを1つのGroupへまとめます。Consumer VPCは、そのGroupに関連付けたResource Endpointを1つ作成します。
Consumer VPC
Fargate
↓
Resource Endpoint（1つ）
↓
Shared Services VPC
Resource Gateway
↓
Resource Configuration Group
├─ ecr.api Interface Endpoint
├─ ecr.dkr Interface Endpoint
└─ logs Interface Endpoint
VPC間の通常ルーティングを作らず、公開されたResourceだけへ接続するため、Consumer VPCと共有VPCのCIDRが重複していても利用できます。TGW AttachmentもVPC Peeringも不要です。
また、複数の子Resource ConfigurationをGroupへまとめることで、Consumer VPC側では1つのResource Endpointから複数のInterface Endpointを利用できます。
TGWを完全に置き換えるものではない
Resource GatewayはTGWの後継ではありません。TGWはネットワーク全体を接続する汎用ハブであり、Resource Gatewayは公開対象を特定のTCPリソースへ限定する仕組みです。
AWS公式ブログでも、Interface Endpoint集約が主目的なら、Resource EndpointはTGW Attachmentより全体の時間料金とデータ処理料金を抑えられる選択肢として紹介されています。ただし、Resource Gateway、Resource Configuration、Resource Endpoint側にも料金は発生するため、VPC数と通信量を使った比較が必要です。
4. 実際に作ってみた
では実際にAWSブログで紹介された構成をマネジメントコンソールから作っていきましょう。
今回の構成
| 項目 | 設定 |
|---|---|
| Consumer VPC | 10.0.0.0/20 |
| Shared Services VPC | 10.0.0.0/20 |
| Consumer側ワークロード | ECS on Fargate |
| Consumer側Gateway Endpoint | S3を1つ |
| Shared側Interface Endpoint |
ecr.api、ecr.dkr、logs
|
2つのVPCには、意図的に同じCIDRを設定しています。TGWやVPC Peeringではそのまま接続できない条件です。
4-1. 共有VPCにInterface Endpointを作る
共有VPCに次の3つを作成します。
com.amazonaws.ap-northeast-1.ecr.api
com.amazonaws.ap-northeast-1.ecr.dkr
com.amazonaws.ap-northeast-1.logs
Resource Configurationへ登録するのは、各Interface EndpointのリージョナルDNS名です。
vpce-<id>.api.ecr.ap-northeast-1.vpce.amazonaws.com
vpce-<id>.dkr.ecr.ap-northeast-1.vpce.amazonaws.com
vpce-<id>.logs.ap-northeast-1.vpce.amazonaws.com
公式ブログにもあるとおり、Resource Gatewayから解決できる公開DNS名を指定する必要があります。Interface EndpointのリージョナルDNS名は公開DNSで名前解決できますが、応答として返るのはEndpoint ENIのプライベートIPアドレスです。
4-2. Resource Gatewayを作る
共有VPCのプライベートサブネットにResource Gatewayを作成します。
| 項目 | 設定値 |
|---|---|
| Resource Gateway名 | test |
| IPアドレスタイプ | IPv4 |
| Resource設定 DNS解決タイプ | パブリック |
| ENIごとのIPv4アドレス数 | 16 |
| VPC | Test-Provider-vpc |
DNS解決タイプはパブリックを選択しました。ここでいうパブリックはDNSの参照先であり、通信がインターネットを経由するという意味ではありません。
セキュリティグループは、Resource GatewayからInterface EndpointへTCP 443で接続できるように設定します。今回の検証では、Interface Endpoint側でResource Gateway専用セキュリティグループからのInbound TCP 443を許可しました。
4-3. Resource Configuration Groupを作る
3つのInterface EndpointをまとめるResource Configuration Groupを作成します。
| 項目 | 検証環境の設定 |
|---|---|
| 名前 | test |
| 設定タイプ | リソースグループ |
| プロトコル | TCP |
| Resource Gateway | test |
| Group Domain | 未使用 |
| ポート範囲 |
1〜65535
|
検証環境では既存設定を使用したためポート範囲が広くなっていますが、今回必要なのはHTTPSだけです。本番環境ではTCP 443へ限定します。
4-4. 3つの子Resource Configurationを作る
Groupの詳細画面から、子Resource Configurationを追加します。
設定タイプはリソース、タイプは子、Resource TypeはDNSリソースです。Domain Nameには、手順4-1で確認したInterface EndpointのリージョナルDNS名を指定します。
| 子Resource Configuration | Resource Definition |
|---|---|
| ECR API |
ecr.api EndpointのリージョナルDNS名 |
| ECR DKR |
ecr.dkr EndpointのリージョナルDNS名 |
| CloudWatch Logs |
logs EndpointのリージョナルDNS名 |
今回のGroupではCustom Domainを使用していません。
4-5. Consumer VPCにResource Endpointを1つ作る
Consumer VPCのプライベートサブネットに、TypeがResourceのVPC Endpointを1つ作り、Resource Configuration Groupへ関連付けます。
今回のGroupには3つの子Resource Configurationがありますが、Consumer VPC側のResource Endpointは1つです。
Resource EndpointのPrivate DNSは無効とし、各Resource Configuration Associationに発行されたDNS名を、次のRoute 53設定から参照します。
4-6. Consumer VPCのDNSを設定する
Fargateが利用するECRやCloudWatch Logsの接続先は任意のURLへ変更できません。そのため、通常のAWSサービスFQDNをResource Endpointの関連付けDNS名へ向ける必要があります。
最初は公式ブログのオプション例を参考に、ap-northeast-1.amazonaws.comという広いPrivate Hosted ZoneへECRとCloudWatch LogsのCNAMEを作成しました。
しかし、Fargateを起動すると次のエラーで停止しました。
CannotPullContainerError
lookup prod-ap-northeast-1-starport-layer-bucket.s3.ap-northeast-1.amazonaws.com: no such host
広いPrivate Hosted Zoneが、登録していないS3のDNS名まで権威的に覆っていたためです。ECRの認証とRegistryだけでなく、イメージレイヤー取得にはS3も使われることを見落としていました。
そこで広域Zoneを削除し、次のサービス別Private Hosted Zoneへ変更しました。
| Private Hosted Zone | レコード | 転送先 |
|---|---|---|
ecr.ap-northeast-1.amazonaws.com |
api.ecr...のCNAME |
ECR APIのResource Association DNS |
ecr.ap-northeast-1.amazonaws.com |
*.dkr.ecr...のCNAME |
ECR DKRのResource Association DNS |
logs.ap-northeast-1.amazonaws.com |
Zone ApexのAlias A | LogsのResource Association DNS |
CloudWatch Logsの通常FQDNはPrivate Hosted ZoneのZone Apexになるため、CNAMEは配置できません。Resource Association DNSのHosted Zone IDを使い、Alias Aレコードを作成しています。
この方式なら、ECRとCloudWatch LogsだけをResource Endpointへ誘導し、S3など他のAWSサービスの名前解決へ影響を与えません。
S3のインターフェースエンドポイントをProvider VPCに作成すれば、AWSブログの構成(ap-northeast-1.amazonaws.comでPrivate Hosted Zoneを作る構成)でも可能でしょうが、それではS3のインターフェースエンドポイントも料金がかかる上、データ処理料金も発生するためAWS利用料の削減という観点では望ましくありません。
4-7. S3 Gateway Endpointを確認する
Consumer VPCには、次のS3 Gateway Endpointを作成し、Fargateを配置するプライベートサブネットのルートテーブルへ関連付けます。
com.amazonaws.ap-northeast-1.s3
S3 Gateway Endpointは時間料金とデータ処理料金がかかりません。一方、VPC PeeringやTGWを越えて共有できないため、Consumer VPCごとに必要です。
4-8. Nginxイメージを作ってFargateを起動する
検証用Nginxイメージをprivate ECRへPushし、NAT GatewayとPublic IPを持たないConsumer VPCのプライベートサブネットでFargateタスクを起動しました。
タスクは正常にRUNNINGとなり、CloudWatch Logsへのログ出力にも成功しました。
5. まとめ
従来、Interface VPC Endpointを複数VPCで共有するには、TGWまたはVPC Peeringを使う構成が一般的でした。
しかし、TGWには時間料金とデータ処理料金があり、TGWとVPC PeeringのどちらもCIDR重複をそのまま扱えません。NLB、VPC Endpoint Service、Squidを組み合わせれば回避できる可能性はありますが、Endpoint集約のためにプロキシ基盤を自分たちで運用することになります。
Resource GatewayとResource Endpointを使う今回の構成では、次を確認できました。
- Consumer VPCと共有VPCのCIDRが重複していても接続できる
- 複数のInterface Endpointを、Consumer VPCの1つのResource Endpointから利用できる
一方で、DNS設計が不要になるわけではありません。通常のAWSサービスFQDNを使う場合はPrivate Hosted Zoneが必要であり、Zoneを広く取りすぎると、今回のS3のようにGroupへ登録していないAWSサービスの名前解決を壊します。
また、Resource GatewayはTGWの代替ではなく、特定のTCPリソースをConsumer側へ公開するための仕組みです。ネットワーク全体の接続が必要ならTGW、Interface Endpointなど限定したリソースの共有が目的ならResource Gateway、という使い分けになります。