概要
オンプレミスのアプリケーションからAWSのマネージドサービスにデータを送信する場合、通常はインターネット経由でパブリックエンドポイントにアクセスします。しかし、セキュリティポリシーで「データはプライベートネットワーク経由で転送し、転送中に暗号化すること」が求められるケースでは、インターネットを経由しない接続方法が必要です。
本記事では、AWS Direct Connectで接続されたオンプレミス環境からAmazon Data Firehose（旧 Kinesis Data Firehose）にプライベートにアクセスする方法として、インターフェイス型VPCエンドポイント（AWS PrivateLink） を使用する構成を解説します。ゲートウェイ型VPCエンドポイントやIAMポリシーによる送信元IP制限など、他の選択肢との違いも整理します。
この記事のメリット
- インターフェイス型VPCエンドポイントの仕組みとオンプレミスからのアクセス方法を理解できる
- ゲートウェイ型VPCエンドポイントとの違いを明確に区別できる
- Direct Connect経由でAWSサービスにプライベートアクセスする構成パターンを把握できる
- SCS試験で「プライベートネットワーク経由のデータ転送」に関する問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
VPCエンドポイントとは
VPCエンドポイントは、VPC内のリソースからAWSサービスにプライベートに接続するための仕組みです。インターネットゲートウェイ、NATデバイス、VPN接続、Direct Connect接続を経由せずに、AWS内部ネットワークを通じてサービスにアクセスできます。VPCエンドポイントにはインターフェイス型とゲートウェイ型の2種類があります。
インターフェイス型VPCエンドポイント（AWS PrivateLink）
インターフェイス型VPCエンドポイントは、AWS PrivateLinkを使用してAWSサービスにプライベートに接続する仕組みです。エンドポイントを作成すると、指定したサブネットにエンドポイントネットワークインターフェイス（ENI） が作成され、サブネットのアドレス範囲からプライベートIPアドレスが割り当てられます。
Amazon Data Firehoseを含む多くのAWSサービスがインターフェイス型VPCエンドポイントに対応しています。サービス名の形式は以下の通りです。
com.amazonaws.<リージョン>.kinesis-firehose例: com.amazonaws.ap-northeast-1.kinesis-firehose
インターフェイス型VPCエンドポイントの主な特徴は以下の通りです。
- 指定したサブネットにENIが作成され、プライベートIPアドレスが割り当てられる
- セキュリティグループでENIへのトラフィックを制御できる
- エンドポイントポリシーでアクセスできるアクションやリソースを制御できる
- プライベートDNSを有効化すると、パブリックエンドポイント名でのリクエストが自動的にVPCエンドポイントに解決される
- オンプレミスネットワークからDirect ConnectやVPN経由でアクセスできる
ゲートウェイ型VPCエンドポイント
ゲートウェイ型VPCエンドポイントは、ルートテーブルにルートを追加することでAWSサービスへのトラフィックをAWS内部ネットワークに誘導する仕組みです。対応しているサービスはAmazon S3とAmazon DynamoDBの2つのみです。
ゲートウェイ型はルートテーブルベースの仕組みであるため、VPC内部のリソースからのアクセスに限定されます。オンプレミスネットワークからDirect Connect経由でゲートウェイ型VPCエンドポイントに直接アクセスすることはできません。
2種類のVPCエンドポイントの比較
| 項目 | インターフェイス型（AWS PrivateLink） | ゲートウェイ型 |
|---|---|---|
| 仕組み | サブネットにENIを作成し、プライベートIPで接続 | ルートテーブルにルートを追加 |
| 対応サービス | 多数のAWSサービス | Amazon S3、Amazon DynamDBのみ |
| オンプレミスからのアクセス | Direct Connect/VPN経由で可能 | 不可（VPC内部のみ） |
| セキュリティグループ | 適用可能 | 適用不可 |
| 料金 | 時間課金 + データ処理量課金 | 無料 |
オンプレミスからのプライベートアクセス構成
Direct Connectで接続されたオンプレミス環境からAmazon Data Firehoseにプライベートにアクセスする構成は以下の通りです。
graph LR
subgraph On-Premises
APP[Application]
end
subgraph AWS
subgraph VPC
DX[Direct Connect Gateway]
ENI[VPC Endpoint ENI<br>Private IP]
end
FIREHOSE[Amazon Data Firehose]
end
APP -->|Direct Connect| DX
DX -->|Private Network| ENI
ENI -->|AWS PrivateLink| FIREHOSE- オンプレミスのアプリケーションがDirect Connect経由でVPCに接続する
- VPC内のインターフェイス型VPCエンドポイントのプライベートIPアドレスに対してリクエストを送信する
- AWS PrivateLinkがエンドポイントからAmazon Data Firehoseにトラフィックを転送する
この構成により、データはインターネットを経由せず、すべてプライベートネットワーク上で転送されます。
プライベートDNSとオンプレミスからのDNS解決
インターフェイス型VPCエンドポイントでプライベートDNSを有効化すると、VPC内ではパブリックサービスエンドポイント名（例: firehose.ap-northeast-1.amazonaws.com）に対するDNSクエリが、自動的にVPCエンドポイントのプライベートIPアドレスに解決されます。
オンプレミスからこのDNS解決を利用するには、Route 53 Resolverのインバウンドエンドポイントを設定し、オンプレミスのDNSサーバーからサービスのDNSクエリをRoute 53 Resolverに転送する条件付き転送ルールを構成します。
他の選択肢との比較
この要件に対して、以下の選択肢が挙がることがあります。
| 選択肢 | プライベートネットワーク経由 | 転送中の暗号化 | 適切か | 理由 |
|---|---|---|---|---|
| VPCエンドポイント + Direct Connect | はい | はい（TLS） | はい | プライベートネットワーク経由のアクセスと転送中の暗号化の両方を実現 |
| IAMポリシーの送信元IP制限 | いいえ | いいえ | いいえ | アクセス制御の仕組みであり、通信経路やデータの暗号化には関与しない |
| Direct ConnectでFirehoseのVPCにピア接続 | – | – | いいえ | Amazon Data FirehoseはAWSマネージドサービスであり、特定のVPCに属さないためピア接続は不可 |
| CloudFrontディストリビューション経由 | いいえ | はい（TLS） | いいえ | CloudFrontはパブリックインターネット経由のアクセスであり、プライベートネットワークの要件を満たさない |
IAMポリシーの送信元IP制限（aws:SourceIp 条件キー）は、特定のIPアドレスからのアクセスのみを許可するアクセス制御機能です。通信経路をプライベートにする機能ではなく、データの転送中の暗号化を提供するものでもありません。
Amazon Data Firehoseは特定のVPCに属するサービスではなく、AWSが管理するリージョナルなサービスです。そのため、Direct ConnectでFirehoseの「VPC」にピア接続するという構成は成立しません。
実践
ここでは、Amazon Data Firehose用のインターフェイス型VPCエンドポイントをVPC内に作成し、エンドポイントのプライベートIPアドレスを確認するまでの手順をコンソールで説明します。
前提条件
- リージョン:
ap-northeast-1（東京） - VPC・サブネットが作成済みの状態
- VPCの「DNS ホスト名」と「DNS 解決」が有効化されていること（プライベートDNSの利用に必要）
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPCエンドポイント | firehose-vpce | Amazon Data Firehoseへのプライベートアクセス |
| セキュリティグループ | firehose-vpce-sg | VPCエンドポイントのトラフィック制御 |
手順1: VPCエンドポイント用セキュリティグループの作成
インターフェイス型VPCエンドポイントのENIにはセキュリティグループを関連付けます。VPC内やオンプレミスからのHTTPS通信を許可するセキュリティグループを作成します。
- AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック（東京） ap-northeast-1」であることを確認します。
- 上部の検索バーに
VPCと入力し、表示された「VPC」を選択します。 - 左側ナビゲーションの「セキュリティ」→「セキュリティグループ」を選択します。
- 「セキュリティグループを作成」をクリックします。
- 「基本的な詳細」に以下を入力します。
- セキュリティグループ名:
firehose-vpce-sg - 説明:
Security group for Firehose VPC endpoint - VPC: VPCエンドポイントを作成するVPCを選択します
- 「インバウンドルール」セクションで「ルールを追加」をクリックし、以下を設定します。
- タイプ:
HTTPS（選択するとプロトコルはTCP、ポート範囲は443が自動で入り、変更できなくなります） - ソース: 「カスタム」のまま、検索欄にVPCのCIDR（例:
10.0.0.0/16）を入力して候補から選びます - 説明 – オプション:
HTTPS from VPCなど - その他の項目はデフォルトのままにします。
- 「セキュリティグループを作成」をクリックします。
オンプレミスからDirect Connect経由でアクセスする場合は、オンプレミスネットワークのCIDRもインバウンドルールのソースに追加します。
手順2: インターフェイス型VPCエンドポイントの作成
- 左側ナビゲーションの「仮想プライベートクラウド」→「エンドポイント」を選択します。
- 「エンドポイントを作成」をクリックします。
- 「エンドポイントの設定」で以下を設定します。
- 名前タグ – オプション:
firehose-vpce - タイプ: 「AWS のサービス」を選択します
- 「サービス」セクションの検索欄に
kinesis-firehoseと入力してEnterを押し、絞り込まれたcom.amazonaws.ap-northeast-1.kinesis-firehose（タイプ: Interface）のラジオボタンを選択します。 - 「ネットワーク設定」の「VPC」でVPCエンドポイントを配置するVPCを選択します。
- 「追加設定」の「プライベート DNS 名を有効化」にチェックが入っていることを確認します。
- 「サブネット」セクションで、配置するアベイラビリティーゾーンの行にチェックを入れ、その行の「サブネットを選択」からサブネットを選びます。各アベイラビリティーゾーンにつき1つのサブネットを選択します。
- 「セキュリティグループ」セクションで、手順1で作成した
firehose-vpce-sgにチェックを入れます（デフォルトのセキュリティグループのチェックは外します）。 - 「ポリシー」セクションは「フルアクセス」のままにします。
- 「エンドポイントを作成」をクリックします。
手順3: エンドポイントの確認
作成したVPCエンドポイントの状態とプライベートIPアドレスを確認します。
- エンドポイント一覧から
firehose-vpceのVPCエンドポイントIDをクリックします。 - 「詳細」の「ステータス」が「使用可能」になっていることを確認します。作成直後は「保留中」と表示される場合があります。
- 同じ「詳細」の「DNS 名」に以下のようなDNS名が表示されます。サービス名は
kinesis-firehoseですが、DNS名はfirehoseになる点に注意してください。 - リージョナルDNS名:
vpce-xxxxxxxxxxxxxxxxx-yyyyyyyy.firehose.ap-northeast-1.vpce.amazonaws.com - ゾーンDNS名:
vpce-xxxxxxxxxxxxxxxxx-yyyyyyyy-ap-northeast-1a.firehose.ap-northeast-1.vpce.amazonaws.com - プライベートDNS名:
firehose.ap-northeast-1.amazonaws.comとfirehose.ap-northeast-1.api.awsの2つ（プライベートDNS有効時） - 「サブネット」タブでは、エンドポイントネットワークインターフェイスのIDとプライベートIPアドレスを確認できます。
プライベートDNSが有効化されている場合、VPC内から firehose.ap-northeast-1.amazonaws.com に対するDNSクエリは、VPCエンドポイントのプライベートIPアドレスに解決されます。オンプレミスのアプリケーションからも、Direct Connect経由でこのプライベートIPアドレスに到達できます。
まとめ
オンプレミス環境からAmazon Data Firehoseにプライベートネットワーク経由でアクセスするには、インターフェイス型VPCエンドポイント（AWS PrivateLink） を使用します。
| 要件 | 適切な方法 |
|---|---|
| プライベートネットワーク経由でAWSサービスにアクセスしたい | インターフェイス型VPCエンドポイント + Direct Connect |
| VPC内からS3/DynamoDBにプライベートアクセスしたい | ゲートウェイ型VPCエンドポイント（無料） |
| 特定のIPアドレスからのアクセスのみを許可したい | IAMポリシーの aws:SourceIp 条件キー |
ゲートウェイ型VPCエンドポイントはAmazon S3とAmazon DynamoDBのみに対応しており、VPC内部のリソースからのアクセスに限定されます。オンプレミスからDirect Connect経由でアクセスする構成には使用できません。
IAMポリシーの送信元IP制限はアクセス制御の仕組みであり、通信経路のプライベート化やデータの転送中の暗号化を実現するものではありません。
SCS試験では「プライベートネットワーク経由でAWSマネージドサービスにアクセスする」要件に対して、VPCエンドポイントの種類（インターフェイス型/ゲートウェイ型）の違いと、それぞれのオンプレミスからのアクセス可否を正確に把握しておくことが重要です。
参照先
- Amazon Data Firehose での AWS PrivateLink の使用 – Amazon Data Firehose
- AWS PrivateLink を介した AWS サービスへのアクセス – Amazon VPC
- インターフェイスエンドポイントの設定 – Amazon VPC
- インターフェイス VPC エンドポイントを使用して AWS サービスにアクセスする – Amazon VPC
