この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、菊池です。
2019/12/26追記：構成によるアクセス可否についておよび、リージョンの注意点について追記しました。
「オンプレからインターネットに出ず、プライベートなネットワークのみを経由してS3にアクセスしたい」という要望はよくあります。しかし、Direct Connectから直接S3エンドポイントにアクセスするには、敷居の高いパブリック接続が必要だったり、VPCを経由する場合はプロキシを挟む必要があったりと、かなり構築・運用のハードルが高い要件でした。
上記のエントリではプロキシをマルチAZ構成で構築することで実現していますが、EC2の構築・運用が必要です。可能ならば、構築・運用面での負荷が小さいマネージドサービスだけで実現したいところです。
その、要望が多かった、マネージドサービスによるS3へのプライベートアクセスがついにできました。Transit Gatewayを利用することで！
S3へのプライベートアクセス構成
いきなりですが、実際に検証した構成です。
ポイントは以下の2点です。
- Transit GatewayとNAT Gatewayを利用する
- Transit Gatewayのアタッチサブネットと、NAT Gatewayを配置するサブネット/ルートテーブルを分ける
クライアント側からルートの設定を見ていきます。
- カスタマールーター：S3エンドポイントのIPアドレス範囲をVPNトンネルへルーティング
- Transit Gateway：デフォルトルート（0.0.0.0/0）をVPC側のアタッチメントへルーティング
- Transit GatewayをアタッチするVPCサブネット：デフォルトルート（0.0.0.0/0）をNAT Gatewayへルーティング
- NAT GatewayをアタッチするVPCサブネット：S3のVPCエンドポイントをルートテーブルに紐付け
S3のIPアドレス範囲は、こちらから確認することができます。各ルートテーブルに設定する宛先ネットワークには、対象リージョンのS3のアドレス範囲全てか、デフォルトルート（0.0.0.0/0）を設定します。デフォルトルートを設定する方が簡単ではありますが、それとは別にインターネットアクセスが必要な場合には対象リージョンのS3のアドレス範囲全てを設定します。そもそもこの要件のユースケースとして、AWS側は完全なプライベートにしておきたいということが多いかと思いますので、それであれば上記のようにカスタマールータのみ注意しましょう。
検証
実際のアクセス検証は、バケットポリシーでVPCエンドポイント経由以外のアクセスを禁止したS3に対し、クライアントからアクセスすることで実施しました。
まずはエンドポイントのIPと、経路に問題ないか確認。
$ nslookup s3.ap-northeast-1.amazonaws.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: s3.ap-northeast-1.amazonaws.com
Address: 52.219.136.2
$ traceroute 52.219.4.158
traceroute to 52.219.4.158 (52.219.4.158), 30 hops max, 60 byte packets
1 gateway (10.10.10.254) 4.586 ms 4.463 ms 4.467 ms
2 * * *
3 10.255.0.238 (10.255.0.238) 15.622 ms 15.523 ms 15.439 ms <- NAT GatewayのプライベートIP
4 * * *
5 * * *
6 * * *
7 * * *NAT GatewayのIPから応答が取れたので、VPNを通ってVPCを経由してます。
そしてS3へアクセス。ちゃんと応答が取れました！
$ aws s3 ls tgw-s3-access-xxxx
2019-12-18 15:57:26 5 test.txt
$ aws s3 rm s3://tgw-s3-access-xxxx/test.txt
delete: s3://tgw-s3-access-xxxx/test.txt追記1：なぜマネージドサービスだけで通信が実現可能か
本記事の公開後、「なぜ、この構成でS3にアクセスできるようになるのか」「なぜTransit Gateway/NAT Gatewayが必要なのか」といった質問を頂きました。その理由を解説したいと思います。
そもそも、なぜS3に直接プライベートアクセスできないのか？
Transit Gateway/NAT Gatewayを使うことでなぜS3にプライベートアクセス可能になるのかを理解するために、まず、そもそもなぜ、それらを使わないことでアクセスできなかったのかを考えます。
オンプレミスからVPN or DirectConnectを使ってS3にアクセスしたいと思った時に、まず考える一番シンプルな構成は以下のようになるでしょう。VPCにアタッチしたVGWに、VPNもしくはDirectConnectで接続し、S3へのVPCエンドポイントを設定します。
よく知られている通り、この構成ではオンプレミスのクライアントからS3にアクセスすることはできません。当たり前のことですが、S3へのアクセスを実現するためには、オンプレミスのクライアントとS3の間でIPレベルでの疎通が可能であることが必須です。VPCの仕様・制約として、トランジット通信（VPCをまたぐ通信）はできない、というのはよく知られていますが、その理由はVGWやInternet Gateway、VPCエンドポイント（ゲートウェイ型）などのゲートウェイサービスのルートテーブルにあります。以下のゲートウェイサービスに共通して、VPCへのインバウンドルート（VPCに入っていく方向の経路）を編集できない、という仕様があります。
- VGW
- Internet Gateway
- VPC Peering
- VPCエンドポイント（ゲートウェイ型）
そのため、VPCのインバウンド方向には、宛先IPがVPC CIDRの範囲にあるトラフィックしか配送できないと考えられます。これは公式ドキュメント等に明示されたものではありませんが、上記のゲートウェイサービスにインバウンド経路を設定あるいは学習する方法が存在しない点からの考察です。（注：Internet GatewayおよびVGWは先日のアップデートでインバウンドルートを一部設定可能になりましたが、あくまで宛先はVPC CIDR範囲内となっています。）
元の図に戻り、オンプレミスとS3の間での通信の到達を考えると2つの問題があることがわかります。1つは、S3のIPを宛先にもつトラフィックがVGWを越えられないことです。VGWはS3のIPアドレス範囲を経路に持ちませんので、VPC方向に配送することができません。2つ目は、S3からオンプレミスに戻るトラフィックが、VPCエンドポイントを越えられないことです。VPCエンドポイントもまた、オンプレミスのIPアドレス範囲への経路を知らないため、トラフィックを配送することができません。
この2つのルーティングの問題により、オンプレミスからS3へのプライベート通信が実現できていないと考えられます。
ルーティングの問題を解決する
上記2つのルーティングの問題が、Transit GatewayとNAT Gatewayを活用することでクリアできます。
まず1つ目の、S3への通信がVPC方向に配送できない点です。Transit Gatewayは独自のルートテーブルを持ち、デフォルトルート（0.0.0.0/0）を含む任意の宛先をVPCに対してルーティングすることが可能です。また、Transit GatewayからVPCに入るトラフィックは、VPCサブネットにアタッチされたENIから直接サブネットに入ります。ENIからサブネットに入ったトラフィックは、次にVPCサブネットに割り当てられたルートテーブルを参照しますので、ここも任意の宛先への配送が可能になります。
2つ目が、VPCエンドポイントがオンプレミスの宛先へのルーティングができないことです。これを解決するため、NAT Gatewayを中継します。NAT Gatewayを通ることで、S3へのトラフィックのソースIPアドレスはNAT Gatewayのプライベートアドレスに変換されます。これにより、VPCエンドポイントからはVPC内からのトラフィックと見なされますので、S3からのレスポンストラフィックもNAT Gateway宛に問題なく配送可能になります。
このように、各ポイントでのトラフィックの宛先IPとルートテーブルの関係をしっかりと把握することで、通信できる/できないが理解できるかと思います。IPレベルでの疎通可否がクラウドでもオンプレでも変わらず重要な要素です。
追記2：S3のリージョンには注意が必要
本構成でアクセス可能なS3は、VPCと同一のリージョンに作成されたS3です。VPCエンドポイントを利用してアクセスできるのは、VPCと同一リージョンのS3エンドポイントであることが制約となります。詳細は以下を参照ください。
まとめ
長年の夢（？）だった、マネージドサービスだけでS3へプライベートアクセスするというのがついに実現できました。最大のポイントは、Transit Gatewayが任意のルートを書けるという点です。Transit Gatewayは今までできなかった制約を取り払い、デザインパターンを大きく変える可能性をもつサービスです。
4
