オンプレミスのクライアントには S3 ゲートウェイかインターフェイスエンドポイントか

オフィスネットワークからサイト VPN 経由で S3 に到達することは、静的ルートだけで解決できるルーティングの問題ではありません。ゲートウェイエンドポイントはルートテーブルに紐づき、VPC の内部で発生するリクエストを処理します。インターフェイスエンドポイントは、サブネット内にプライベートアドレスを持つ弾力性のあるネットワークインターフェイスを配置し、そのアドレスには VPN または Direct Connect 経由でオンプレミスから到達できます。リクエストがどこから始まるかで実際にどちらが必要かが決まり、DNS、セキュリティグループ、ポリシーの作業はその答えから導かれます。

リクエストの開始地点でエンドポイントの種類を分ける

ゲートウェイエンドポイントは、管理されたプレフィックスリストを指すルートテーブルのエントリとして現れます。ネットワークインターフェイスもセキュリティグループも独自のプライベートアドレスも持たず、反対側にルーティングする先が何もないため、オンプレミスのホストはそこへルーティングできません。VPC の内部からのトラフィックが S3 に届くのは、サブネットのルートテーブルがそのプレフィックスをエンドポイントへ送るからです。それ以外の場所からのトラフィックには、たどるべきそのようなエントリがありません。

インターフェイスエンドポイントは、選択したサブネット内のネットワークインターフェイスの集合で、それぞれにそのサブネットのプライベートアドレスとセキュリティグループが付きます。トンネルがパケットを運べる通常の宛先なので、これがハイブリッドクライアントに使える形です。同時に、エンドポイントはサブネット内のアドレスを消費し、不足する可能性があることも意味します。

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

名前ではなく Type 列を読みます。単一の VPC が同じサービスに対して両方の種類を持つことはよくあり、オンプレミスのアプリケーションが必要とするのはインターフェイスのエントリです。

S3 をテストする前にインターフェイスアドレスへの経路を作る

同時に成り立つ必要があるのは、オンプレミスのルーターがエンドポイントのサブネットへのルートを持つこと、そのサブネットからの戻り経路がクライアントネットワークに届くこと、エンドポイントのセキュリティグループがクライアントの送信元範囲を許可することの三つです。三つが通った後でもサブネットのネットワーク ACL はパケットを落とせるため、後回しの思いつきではなく四番目の項目として確認してください。

VPC 内のどこかの EC2 インスタンスへの経路が通ることは、このいずれも証明しません。トンネルが上がっていること、つまりすでに知っていた経路の一部を示すだけです。エンドポイントのアドレスを別に証明し、そのうえで名前がそこへ解決することを証明します。

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

最初のコマンドはクライアントが使うインターフェイスを示します。二番目は TCP のハンドシェイクを証明します。三番目は、エンドポイント名に対して有効な証明書で TLS が完了することを証明するもので、権限を疑う前に誤ったアドレスを捕まえるのはこの確認です。

アプリケーションが受け取る DNS の応答を決める

VPC にインターフェイスエンドポイントがあるだけでは、オンプレミスの SDK は自動的に転送されません。クライアントは、AWS がそのエンドポイント向けに公開するエンドポイント固有の名前を使うか、オフィスから解決できるように意図的に設定したプライベートホストゾーンを使うかのどちらかです。

ハイブリッド解決には、オンプレミスのリゾルバーが VPC の DNS ビューへ入るためのサポートされた経路を必要とし、通常は Resolver のインバウンドエンドポイントを経由します。どのクエリ送信元に影響するかを理解せずにプライベート DNS を有効にすると、オフィスから到達できないアドレスを検索が返し始めます。この設定が変えるのは VPC リゾルバー経由で届くクエリの応答であり、どこにいてもすべてのクライアントの応答ではありません。

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

どちらもアプリケーションのホストで実行し、VPC 内のジャンプボックスでは実行しないでください。そこで応答するリゾルバーがワークロードの使うものであり、別のホストから得た異なる応答がこの設計で最も多い混乱の原因です。

到達可能性は認可ではない

エンドポイントに届いたリクエストには、依然として認可されたプリンシパルと適用されるバケット権限が必要です。エンドポイントポリシーはエンドポイントが許可する範囲を狭められ、バケットポリシーはそれをさらに狭められます。インターフェイスに到達しても、呼び出し元が読めるオブジェクトについては何も分かりません。

意図したバケットへの無害な認可済み呼び出しと、ポリシー外の ID やリソースに対して拒否されるはずの呼び出しの両方向を試します。エンドポイント名、解決されたアドレス、ポリシーの文脈を結果と一緒に残し、次の人が再現できるようにします。ポリシーの種類を名指しする拒否は、一時間の推測を省きます。

最後に、構築前に二つの選択肢の費用を見積もります。インターフェイスエンドポイントはインターフェイス時間とギガバイト単位で課金されますが、ゲートウェイエンドポイントは課金されず、この違いが、VPC 側のアクセスだけを必要とする低容量のワークロードの多くで答えを決めます。