SRE部 佐竹です。
本日は S3 の PrivateLink (Interface 型 VPC Endpoint) について記載します。
はじめに
AWS PrivateLink for Amazon S3 は先日リリースされました。
上ブログでも取り上げております本機能ですが、今回のブログは「他の PrivateLink と比較した」記事となっております。
一般的な PrivateLink
ここでは Systems Manager (ssm.ap-northeast-1.amazonaws.com) を例にとって説明します。
まず前提として、AWS の各サービスは基本的に Global IP を返却します。
>nslookup ssm.ap-northeast-1.amazonaws.com サーバー: one.one.one.one Address: 1.1.1.1 権限のない回答: 名前: ssm.ap-northeast-1.amazonaws.com Address: 52.119.221.73
この通り、名前解決の結果は AWS が保持する Global IP が返ってきています。構成図で示すと以下の通りです。
構成図右端にあるピンク色の点線が経路を示しています。
SSM の PrivateLink
PrivateLink (Interface 型 VPC Endpoint) はその VPC に所属する Amazon Provided DNS (現在は Amazon Route 53 Resolver と呼ばれます) に対して割り当てた Private IP を返却するレコードを登録するところまでが1つの機能として提供されます。
そのため以下の通りの構成図になり、PrivateLink を作成した VPC の中に存在する EC2 Instance からの名前解決の結果として Private IP が返却されるようになります。
このため SSM の PrivateLink を作成すると ssm.ap-northeast-1.amazonaws.com が透過的に Private IP を返却するようになります。
さらに Amazon Provided DNS をオンプレミス側から名前解決できるようにすることで、オンプレミスのサーバーからも Private IP でサービスを利用できるようになります。
ここまでが SSM を例にとった、一般的な PrivateLink の機能説明になります。
S3 の PrivateLink
結論から記載すると、S3 の PrivateLink は SSM のように透過的には利用できません。つまり s3.ap-northeast-1.amazonaws.com が Private IP を返却するような機能ではありません。これには以下の設定項目が関連しています。
SSM の PrivateLink では「Private DNS names enabled」がデフォルトで true になっています。これが true であることにより ssm.ap-northeast-1.amazonaws.com は VPC の中で Private IP を返却可能となります。
しかし、S3 の PrivateLink はこの設定項目が設定できず false になっています。
後から設定を変更しようとしても設定変更不可となります。
このため s3.ap-northeast-1.amazonaws.com は PrivateLink を作成した後でさえ Global IP を返却します。
構成図で示すと上図のような経路で Global IP が取得されます。
追記
ここから追記です。現在は、本仕様が改善されています。追って AWS は以下のブログにある通り機能拡張を行っています。
少々長いですが、上記ブログより引用します。
多くのお客様は、オンプレミスと AWS リージョンでアプリケーションを所有しており、どちらも同じ VPC の S3 にデータが格納されています。これらのお客様から、オンプレミスからのトラフィックをインターフェイスエンドポイント経由でルーティングし、AWS 内からのトラフィックをゲートウェイエンドポイント経由で簡単にルーティングする方法が欲しいと言われていました。この課題を解決するために、「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」オプションを導入しました。S3 インターフェイスエンドポイントの「DNS 名を有効化」を有効にすると、「インバウンドエンドポイントのみプライベート DNS を有効にする（Enable private DNS only for inbound endpoint）」オプションがデフォルトで有効になります。この場合、オンプレミスから S3 への DNS クエリについては S3 インターフェイスエンドポイントのプライベート IP アドレスに名前解決され、 同じ VPC 内のリソースから S3 への DNS クエリについては引き続きゲートウェイ VPC エンドポイントを使用して S3 のパブリック IP アドレスに名前解決されます。
ここまでが引用となります。この通りに設計することで、ハイブリッドに S3 が利用できますので合わせて確認ください。
では、ここから先はブログの記事の続きとなります。以上が追記でした。
ではどのように利用するか？となるのですが、これが（先のブログでも紹介がありました）特別な（個別の） URL を利用することになります。
私のアカウントでは *.vpce-01cbf031c7fba2384-5xot5dtl.s3.ap-northeast-1.vpce.amazonaws.com がそれに当たります。先頭の * はバケット名を記載する箇所となります。
動作確認
実際に存在する私の所持するバケットで確認すると以下の通りです。
satake-ycloudtrail というバケットに対して通常通り S3 の URL を利用するよう nslookup をしてみます。結果は Global IP が返却されます。
>nslookup satake-ycloudtrail.s3.ap-northeast-1.amazonaws.com サーバー: one.one.one.one Address: 1.1.1.1 権限のない回答: 名前: s3-r-w.ap-northeast-1.amazonaws.com Address: 52.219.0.243 Aliases: satake-ycloudtrail.s3.ap-northeast-1.amazonaws.com
これに対し PrivateLink 用の URL を利用した nslookup を実行した結果は以下の通りです。
>nslookup satake-ycloudtrail.vpce-01cbf031c7fba2384-5xot5dtl.s3.ap-northeast-1.vpce.amazonaws.com
サーバー: one.one.one.one
Address: 1.1.1.1
権限のない回答:
名前: satake-ycloudtrail.vpce-01cbf031c7fba2384-5xot5dtl.s3.ap-northeast-1.vpce.amazonaws.com
Addresses: 192.168.64.82
192.168.64.204
192.168.64.188
特別な URL を利用した場合の経路
EC2 Instance の内部から S3 の PrivateLink へとアクセスする場合は以下のような経路になると考えられます。
これはどうしてこうなるかというと、この URL はグローバルでも有効となるためです。つまり RDS や ELB のようにグローバルに公開された DNS に対して名前解決を行うと Private IP が返却されるという実装です。
なおこの図のような場合 Private IP に対してのアクセス経路がない＝S3 にアクセスができないとなりますので、グローバルからのアクセスは今まで通りの URL を利用し、Private IP として利用したい場合は PrivateLink 用の URL を利用するという URL の使い分けが必要です。
DNS を利用して透過的にはできない
最後に注意点ですが、この個別のURLである *.vpce-01cbf031c7fba2384-5xot5dtl.s3.ap-northeast-1.vpce.amazonaws.com は CNAME として提供されているわけではないため、DNS による登録が想定されていません。
また S3 のエンドポイントは https による通信となっていますため、DNS に値を登録したとしても、証明書とドメイン名の不一致によるエラー (SSL_ERROR_BAD_CERT_DOMAIN) が発生してしまいます。
つまり、S3 の PrivateLink を利用したい場合は、個別に払い出される URL を利用するしかないのが実情です。
まとめ
本ブログでは S3 の PrivateLink (Interface 型 VPC Endpoint) が他のサービスの PrivateLink と異なるたった1つの点について SSM を比較対象として記載しました。
たった1つしか異なる点はないのですが、これにより他のサービスと異なり使い勝手がかなり変わってきます。
今後、もしかするとアップデートで Private DNS names enabled が true にできるようになるかもしれませんが、現状 URL の使い分けが必須となっています。
今回のブログは以上となります。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
