テクニカルインストラクターと学ぶインターフェース型とゲートウェイ型の VPC エンドポイント
Author : 杉本 圭太
テクニカルインストラクターの杉本圭太です !
今回は Amazon VPC 内からインターネットゲートウェイ無しで AWS サービスへアクセスできる「VPC エンドポイント」について、ゲートウェイ型とインターフェース型の違いに着目しながら解説をしていきます !
1. VPC エンドポイントとは
VPC エンドポイントの話をする前に、まずは VPC 内のリソースから AWS サービスへアクセスする方法を確認しましょう。
VPC から AWS サービスのパブリック IP アドレスへアクセス
「AWS の API を理解しよう ! ~ 初級編」に詳細を載せていますが、AWS サービスへはパブリック IP アドレスで通信ができます。つまり Amazon EC2 などの VPC 内にあるリソースから Amazon S3 や Amazon Bedrock などの AWS サービスのパブリック IP アドレスへアクセスするには、インターネットゲートウェイとパブリック IP アドレス (必要に応じて NAT ゲートウェイ) が必要です。
ちなみに VPC のよくある質問 に記載がある通り、この場合はインターネットゲートウェイを使用していても例外を除いて AWS のネットワーク内に通信はとどまります。
2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
しかし業務の要件によっては「そもそもセキュリティリスクを減らすため、インターネットゲートウェイやパブリック IP アドレスを持たせたくない」「1 つの AWS サービスにアクセスしたいだけなのに NAT ゲートウェイやパブリック IPv4 アドレスのコストをかけたくない」といった VPC が必要になることもあります。
VPC エンドポイントの役割とメリット
AWS では「VPC エンドポイント」を使用することで、インターネットゲートウェイ、NAT ゲートウェイ、パブリック IP アドレスを用意せずに VPC 内のプライベートな IP アドレスから特定の AWS サービスへアクセスできます。
VPC エンドポイントはそれぞれの VPC でアクセスしたい AWS サービスエンドポイントごとに 1 つ作成する必要があります。
また同じサービスでも Action によって サービスエンドポイント が別に分けられている場合があるため注意してください。例えば東京リージョンで Amazon Bedrock の「ListFoundationModels (モデルの一覧取得)」と「InvokeModel (プロンプトを与えて出力)」の両方を行いたい場合は bedrock.ap-northeast-1.amazonaws.comと bedrock-runtime.ap-northeast-1.amazonaws.com の 2 つのサービスエンドポイントに対して VPC エンドポイントを作成します。
VPC エンドポイントのメリットは VPC にパブリック IP アドレスなどを用意しないで済むだけではなく、エンドポイントポリシー を使用して VPC と同じ AWS アカウントや同じ組織内の AWS のバケットにしかアクセスさせないなどの制御ができる点も挙げられます。
他にも AWS Site-to-Site VPN や AWS Direct Connect などを使用して 社内のデータセンターと VPC の経路を確保 している場合であれば、VPC エンドポイントを使用して社内のデータセンターから AWS サービスへプライベート IP アドレスでアクセスさせるという使い方もできます ! これは後ほど図を交えて説明します。
AWS サービスへの VPC エンドポイントは 2 種類ある
ここからが本題なのですが、VPC エンドポイントには特徴によって 型が分けられています。 [※]
- Interface (インターフェース)
- GatewayLoadBalancer
- Resource
- Service network
- Gateway (ゲートウェイ)
そして AWS サービスへのアクセスで使用するのがゲートウェイ型とインターフェース型の 2 種類なのですが、仕組みが大きく異なります。それぞれの特徴を理解しておくとより適切に扱えるため、ここからはそれぞれがどのような経路で VPC 内から AWS サービスへアクセスしているかの詳細をお伝えしていきます !
※ VPC エンドポイントの中で Gateway 型以外は PrivateLink という技術が使用されています。PrivateLink は VPC 内から VPC 外のサービスへプライベート接続をするための仕組みで、インターフェース型の VPC エンドポイントの説明時に併せて出てくることが多いため用語だけ紹介しました。PrivateLink を使用することで IP アドレスの範囲が重なっている別の VPC のサービスへプライベート接続できたりなど色々役立つ機能なので、詳細を知りたい方はドキュメントを読んでみてください !
2. ゲートウェイ型
ゲートウェイ型の VPC エンドポイントを理解するために押さえておきたい特徴を挙げます φ(•ᴗ•๑)
- ゲートウェイ型を使用できるサービス は現時点で Amazon S3 と Amazon DynamoDB のみ [※]
- ルートテーブルに VPC エンドポイントへのルートを追加することでアクセスができる仕組み
- サブネットごとに VPC エンドポイントを使用するかしないかを設定できる (ルートテーブルはサブネットごとに設定できるため)
- AWS サービスのパブリック IP アドレスにリクエストを送信すると、VPC エンドポイントを経由して AWS サービスにアクセスできる
ゲートウェイ型の VPC エンドポイントを作成すると、どのルートテーブルに関連付けるかの設定ができるようになっています。関連付けをしたルートテーブルには自動で「送信先が AWS マネージドプレフィックスリスト (特定サービスの IP アドレスの一覧) のターゲットは VPC エンドポイント」というルートが追加されます。
ゲートウェイ型の VPC エンドポイントを使用して、EC2 インスタンス X から Amazon S3 の「s3.us-west-2.amazonaws.com」へアクセスする経路を概略図にしてみました ! 順を追って確認しましょう !
この図ではプライベートサブネット b1 に紐づくルートテーブルに VPC エンドポイントを使用できる設定をしています。
- us-west-2 の Amazon S3 にアクセスするためには「s3.us-west-2.amazonaws.com」の IP アドレスを取得する必要があるため、VPC から使用できる Amazon DNS サーバー (Route 53 Resolver) を使用して名前解決のリクエストをする。
- 名前解決の結果、Amazon S3 へアクセスするためのパブリック IP アドレスを受け取る。複数の値が返ってくることもある。
- EC2 インスタンス X は “52.92.xx.xx” を使用する場合、サブネット b1 に紐づくルートテーブル b1 に「この IP アドレスへ送信したい場合に向かうべき場所 (ターゲット)」を確認する。
- “52.92.xx.xx” が AWS マネージドプレフィックスリストに含まれるので、ルートテーブルからターゲットが VPC エンドポイント (vpce-123abc) であることを受け取る。
- EC2 インスタンス X は “52.92.xx.xx” へのリクエストを VPC エンドポイント (vpce-123abc) に送信することで、Amazon S3 へリクエストが届く。
※ 元々は Amazon S3 と Amazon DynamoDB ではゲートウェイ型しか使用できなかったのですが、Amazon S3 は 2021 年の 2 月、Amazon DynamoDB は 2024 年の 3 月にインターフェース型も使用できるようになりました。
3. インターフェース型
インターフェース型の VPC エンドポイントを理解するために押さえておきたい特徴を挙げます φ(•ᴗ•๑)
- インターフェース型の VPC エンドポイントをサポートしているサービスエンドポイント は 200 以上ある (リージョンごとに差異あり)
- Elastic network interfaces (ENI) のプライベート IP アドレスを経由して VPC エンドポイントへアクセスができる仕組み + VPC 内から使用できる DNS で AWS サービスの名前解決結果も変更できる
- VPC 内のサブネット全てから VPC エンドポイントを使用できる (VPC エンドポイントに紐づく ENI が 1 つ以上ある場合)
- 同じVPC 内にある ENI のプライベート IP アドレスにリクエストを送信すると、VPC エンドポイントを経由して AWS サービスにアクセスできる
インターフェース型の VPC エンドポイントを作成すると、AZ ごとに 1 つまでサブネットを指定して ENI を作成できるようになっています。3 つの AZ でサブネットを持つ VPC であれば、VPC エンドポイント用の ENI を 3 つまで作れます。この ENI はサブネットの CIDR の範囲でプライベート IP アドレスが付与されます。そしてこの ENI へリクエストを送信すると VPC エンドポイントを経由して AWS サービスへ到達します。
そして VPC エンドポイントの ID が付いたドメイン名が、AZ 単位とリージョン単位でパブリックに名前解決できるレコードとして登録されます。例えば us-west-2 で Amazon Bedrock のインターフェース型エンドポイント (vpce-xxxx) と AZ a, b で ENI を作成した場合、以下のようなドメイン名が AWS によって作成されます。
- vpce-xxxx.bedrock.us-west-2.vpce.amazonaws.com
- vpce-xxxx-us-west-2a.bedrock.us-west-2.vpce.amazonaws.com
- vpce-xxxx-us-west-2b.bedrock.us-west-2.vpce.amazonaws.com
また VPC エンドポイントの「プライベート DNS 名を有効化」オプションをオンにすると、VPC 内から対象サービスのドメイン名を名前解決した場合に ENI のプライベート IP アドレスが返ってきます。
インターフェース型の VPC エンドポイントを使用して、EC2 インスタンス X から Amazon Bedrock の「bedrock.us-west-2.amazonaws.com」へアクセスする経路を概略図にしてみました ! 順を追って確認しましょう !
この図では「プライベート DNS 名を有効化」をオンにしています。
- us-west-2 の Amazon Bedrock にアクセスするためには「bedrock.us-west-2.amazonaws.com」の IP アドレスを取得する必要があるため、VPC から使用できる Amazon DNS サーバー (Route 53 Resolver) を使用して名前解決のリクエストをする。
- 名前解決の結果、VPC エンドポイント用の ENI の IP アドレスを受け取る。ENI を複数の AZ で作成しておくと複数の値が返ってくる。
- EC2 インスタンス X は “10.0.2.12” を使用する場合、サブネット b1 に紐づくルートテーブル b1 に「この IP アドレスへ送信したい場合に向かうべき場所 (ターゲット)」を確認する。
- “10.0.2.12” は VPC の CIDR の範囲であるため、ルートテーブルからターゲットが local (VPC 内の通信) であることを受け取る。
- EC2 インスタンス X は “10.0.2.12” へのリクエストを ENI に送信する。
- ENI のセキュリティグループで HTTPS のリクエストを受け取れるインバウンドルールを設定しておくと VPC エンドポイントを経由して Amazon Bedrock へリクエストが届く。
特定の AZ を指定してインターフェース型の VPC エンドポイントを使用する
先程の例では「プライベート DNS 名を有効化」をオンにして「bedrock.us-west-2.amazonaws.com」へリクエストしましたが、指定した AZ へリクエストを送りたい場合は「vpce-xxxx-us-west-2b.bedrock.us-west-2.vpce.amazonaws.com」のようなドメイン名に対してリクエストすれば OK です ( •̀ᴗ•́ )و ̑̑
VPC 外からインターフェース型の VPC エンドポイントを使用する
冒頭で述べた AWS Site-to-Site VPN や AWS Direct Connect などを使用して 社内のデータセンターと VPC の経路を確保 している場合、VPC エンドポイントを使用して AWS サービスへプライベート IP アドレスでアクセスさせる経路も図にしておきました ! VPC 内からのアクセスと少し経路が違うだけで、流れはほぼ同じですね !
VPC 外から VPC エンドポイントを使用する場合でも、ENI のプライベート IP アドレスに到達できれば良いのでこのような経路が可能です !
ただしゲートウェイ型の場合はルートが設定されているサブネット内から始まる通信ではないと VPC エンドポイントへの経路が使用できないため、オンプレミスから VPC を経由して使用することはできません 😣
4. ゲートウェイ型とインターフェース型の両方をサポートしているサービスはどちらの VPC エンドポイントを使用すれば良いのか ?
Amazon S3 と Amazon DynamoDB はゲートウェイ型とインターフェース型の両方の VPC エンドポイントが作成できるので、どちらを使えば良いか迷うという方もいるはずです。
端的に言うと「VPC 内のリソースからしか VPC エンドポイントにアクセスしない」のであれば、ゲートウェイ型の使用で良い場合が多いはずです。というのもゲートウェイ型は VPC エンドポイントに関しては追加料金は発生しませんが、インターフェース型は各 AZ に作成するエンドポイントごとの料金と処理されるデータ量での料金がかかるためです。
ただしオンプレミスなど VPC 外から VPC エンドポイントを経由したプライベートなアクセスを Amazon S3 や Amazon DynamoDB へしたいのであれば、インターフェース型の方がマネージドな仕組みで実現できるため使用するのが適切な場合もあります。
5. まとめ
最後に今回学んだことを確認しましょう !
| ゲートウェイ型 | インターフェース型 | |
| 対象サービス | 現時点で Amazon S3 と Amazon DynamoDB のみ | 200 以上 (リージョンごとに差異あり) |
| 仕組み | ルートテーブルと AWS マネージドプレフィリスト | ENI と DNS |
| サブネットごとに使用する | サブネットごとに使用する・しないを設定できる | どのサブネットからでも使用可能 |
| 送信 IP アドレス | パブリック IP アドレス | プライベート IP アドレス |
| 送信ターゲット | VPC エンドポイント | 同じ VPC 内の ENI |
| 追加で発生する料金 | なし | 各 AZ のエンドポイント 1 つあたりの料金 (USD/時間) と、処理データあたりの料金 |
このようにテクニカルインストラクターは、自学だけではつまずきやすい部分などを含め、みなさんにより AWS を理解してもらいやすくなる工夫を日々行いながら クラスルームトレーニング を提供しております !
質問もリアルタイムでできるため分からない部分はとことんお付き合いしますし、ほとんどのコースには演習の時間も多くあるため学んだ内容を AWS 環境で実践できます !
AWS のトレーニングについてもっと知りたい方は、以下の連載記事も参考にどうぞ。
これまで自分で勉強してきたけど AWS を体系的に学ぶことでもっと詳しくなって業務で活用したい ! という方はぜひ AWS のトレーニングを受講してみてください !
筆者プロフィール
杉本 圭太
アマゾン ウェブ サービス ジャパン合同会社
トレーニングサービス本部 テクニカルインストラクター
テクニカルインストラクターとして、知識をつけることが目的ではなく実際に業務で活用できる力を得ることを目指したトレーニングを提供しています。自分自身が新しいことを知るのが好きなので、「AWS を知るのは面白い ! もっと学んでみよう !」と多くの方に感じてもらえる工夫を常に考えながら活動しています。
AWS を無料でお試しいただけます