コーヒーが好きな木谷映見です。
Amazon Redshift を作成する際、多くの方は業務データ保護の観点でプライベートサブネットに作成されるのではないでしょうか。
「プライベートサブネットに作成したのだからもう安心」と思われるのはまだ早く、Redshift 側で拡張された VPC のルーティングの設定を行ったり、VPC エンドポイントを作成したりする必要がある場合があります。
今回は Redshift の「拡張された VPC のルーティング」という機能についてまとめていきます。
拡張された VPC のルーティング（enhanced VPC routing）とは
Amazon Redshift の拡張された VPC のルーティングを有効にすると、Amazon Redshift は Amazon VPC を介して通信します。
拡張された VPC ルーティングが無効の場合、Redshift は AWS ネットワーク内のその他のサービスなどへのトラフィックを、AWS 独自のグローバルネットワーク経由でルーティングします。
docs.aws.amazon.com
AWS クラウド上のパブリック IP での通信は、AWS 独自のグローバルネットワーク内で完結する旨が記載されています。AWS 独自のグローバルネットワークとは、AWS が管理しているインターネット空間で、パブリック IP で通信が行われます。
詳細は以下のブログもあわせてご参照ください。
blog.serverworks.co.jp
結論
たとえプライベートサブネットに Redshift を作成しても、VPC エンドポイントを作成しておいても、拡張された VPC ルーティングを有効にしないと、Redshift は AWS ネットワーク内のサービス（S3 バケットなど）と AWS 独自のグローバルネットワーク経由で通信してしまいます。
あくまで AWS 独自のグローバルネットワーク内で通信を行うのみで、完全に公のパブリックインターネット空間で通信が行われるわけではありません。
プライベートサブネットの Redshift が VPC 経由で AWS サービスと通信するには、以下 2 つの手順が必要です。
- 拡張された VPC のルーティングをオンにする
- VPC エンドポイントを作成する
検証
S3 バケットを作成しておき、
サンプルデータベース のデータを S3 バケットに格納しておきます。
インターネットゲートウェイもパブリックサブネットもない VPC 内のプライベートサブネットに、Redshift Serverless を作成します。
S3 バケットから Redshift Serverless にデータを COPY できるか検証します。
拡張された VPC のルーティング【オフ】の Redshift Serverless
インターネットゲートウェイがない VPC のプライベートサブネットに、拡張された VPC のルーティング【オフ】の Redshift Serverless を作成します。
こんなガチガチのプライベートサブネットの中の Redshift Serverless に、S3 バケットからデータ COPY することができるのでしょうか。
Redshift Serverless は AWS CLI で作成します。
aws redshift-serverless create-namespace \ --admin-user-password xxxxxxxxxxxx \ --admin-username rsadmin \ --db-name dev1 \ --iam-roles "arn:aws:iam::123456789012:role/20220929-Redshift-ServerlessRole" \ --log-exports "useractivitylog" "userlog" "connectionlog" \ --namespace-name redshift-demo1-ns \ --tags key=Name,value=redshift-demo1-ns
aws redshift-serverless create-workgroup \ --base-capacity 32 \ --namespace-name redshift-demo1-ns \ --security-group-ids "sg-0f418ee6d5c2ebf23" \ --subnet-ids "subnet-00c92067c4799becc" "subnet-03717d81afae29e7e" "subnet-0d9a487495d0b3930" \ --tags key=Name,value=redshift-demo1-workgp \ --workgroup-name redshift-demo1-workgp
ちなみに今回監査ログを 3 つともオンにしましたが、ちゃんと CloudWatch Logs にロググループが作成されています。
Redshift クエリエディタv2 で Redshift Serverless にクエリします。
Redshift のコンソールから Redshift クエリエディタ v2 を開き、今回はデータベース名とパスワードでログインします。
テーブルを作成し、COPY クエリを実行すると、S3 バケットからデータを コピーすることができてしまいました。
インターネットゲートウェイもない VPC 内のリソースが S3 バケットと通信できてしまうのですが、AWS の特にマネージドサービスは、ユーザーが意識しない裏側で、AWS 独自のグローバルネットワークを使用して通信をすることがあります。
拡張された VPC のルーティング【オン】の Redshift Serverless
ワークグループ画面から拡張された VPC のルーティングをオンにします。
再度 COPY クエリを実行すると、ずっと読み込み中のまま進みません。
拡張された VPC のルーティング【オン】の Redshift Serverless ～ S3 ゲートウェイ型 VPC エンドポイントを作成
この状態で、S3 ゲートウェイ型 VPC エンドポイントを作成します。
S3 ゲートウェイ型 VPC エンドポイントは AWS CLI で作成します。
create-vpc-endpoint — AWS CLI 2.8.5 Command Reference
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0d347caf64fe5bf83 \
--service-name com.amazonaws.ap-northeast-1.s3 \
--route-table-ids rtb-0984ab1105c50e494 \
--vpc-endpoint-type Gateway \
--tag-specifications "ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=redshift-demo1-gateway-vpcendpoint-s3}]"
再度 COPY クエリを実行すると、データコピーできました。
拡張された VPC のルーティング【オフ】で VPC エンドポイントを作成しても
検証 をお読みいただいた方は予想がついていらっしゃるかもしれませんが、拡張された VPC のルーティング【オフ】で VPC エンドポイントがある構成にしても、実際には VPC エンドポイントを介さない通信をおこなってしまいます。
VPC 経由の通信を行いたい場合は、拡張された VPC のルーティングを【オン】にするようにしましょう。
また、S3 バケットや Secrets Manager などと通信する必要がある場合は忘れずに VPC エンドポイントを作成しましょう。
考慮事項
- VPC でドメインネームサービス (DNS) 解決を有効にする必要があります。または、自分で所有する DNS サーバーを使用している場合は、Amazon S3 に送られる DNS リクエストが AWS により維持される IP アドレスに正しく変換されていることを確認する必要があります。
- DNS ホスト名を VPC で有効にする必要があります。DNS ホスト名はデフォルトで有効化されています。
参考
拡張 VPC ルーティングは Amazon Redshift ではどのように機能しますか?
Amazon Redshift の拡張 VPC ルーティング
emi kitani(執筆記事の一覧)
AS部LX課。2022/2入社、コーヒーとサウナが好きです。執筆活動に興味があります。AWS認定12冠。
