Redshiftでは他のVPC(他AWSアカウントも可)にVPCエンドポイントを作成することができます。
通常のVPCエンドポイントの作り方とは異なりますし、挙動も変わってるので紹介します。
Contents
前準備が必要
クラスタ再配置
RedshiftでVPCエンドポイントを作成するにはクラスタの再配置を有効にしておく必要があります。
クラスタの再配置を有効化すると裏ではVPCエンドポイントが作成されて通常のエンドポイントもVPCエンドポイント経由になるようです。
再配置を有効化するためには以下の条件があります。
- RA3インスタンスであること
- ポート番号がデフォルトの5439
- パブリックアクセス不可であること
- サブネットグループに複数サブネットが含まれること
クラスタの再配置は通常5-10分程度で終わるようです。その間Redshiftは使用できません。
再配置有効化後もこれまで使っていたFQDNを使ってRedshiftにアクセスできますが、FQDNが返すIPアドレスが変化します。
そのIPにちょっと奇妙な挙動があります。
再配置有効化後、このFQDNが返すIPは1個のみとなります。
詳細には裏で自動的に作成されるVPCエンドポイントにて、サブネットグループに含まれるサブネットがランダムに選択されたサブネットにENIが作成され、IPがアサインされます。
クラスタの再配置を実施すると別AZにRedshiftクラスタを移動させることができるんですが、それをやると別のサブネットにもENIが作成され、FQDNが返すIPが増えます。
VPCエンドポイントの作成画面が違う
RedshiftのVPCエンドポイントはRedshiftの画面から作成します。
どのクラスタに接続するか、どのVPCか、どのサブネットグループか、VPCエンドポイントにつけるセキュリティグループを指定して作成します。5分くらいでエンドポイントは作成できます。
サブネットグループは事前に作成しておく必要があります。
また、私だけかもしれませんが、「エンドポイントの作成」ボタンを押しても何も反応しませんでした。マネジメントコンソールの言語を英語に変えたら作成できました。謎です。
Redshift-managed VPCエンドポイントはAZ冗長ではない
VPCエンドポイントを作成すると新規にFQDNが払い出されるんですが、このFQDNが返すIPが一つとなります。サブネットグループに含まれるサブネットからランダムにサブネットが選択されそこにENIが作られます。
本体のFQDNはクラスタの再配置を行うとIPが増えていきましたが、こっちは増えません。
そしてENIがあるAZに障害があった場合、別サブネットにENIが作成され、フェイルオーバーする、なんてこともありません。
つまりAZ冗長にできず、AZ 障害時に通信の迂回は行われず影響が発生してしまいます。
この挙動に関しては改善のフィールドバックをAWSに投げています。
今後のアップデートで改善されることを祈っています。
アクセステスト
下記のような感じでテストしました。
- RedshiftはアカウントAのVPC-Aにある
- VPC EndpointをアカウントBのVPC-Bに作成
- VPC-CとVPC-BをVPCピアリング
- VPC-CにEC2立てて、VPCエンドポイントのFQDNに対してアクセス
- VPC-AにEC2立てて、Redshift本体のFQDNに対してアクセス
結果、
- VPC-A,VPC-CのEC2どちらからもpsqlのリモート接続、pyodbcでのアクセスできた
- VPC-Aから、VPC-CからどちらからのアクセスもソースIPはlocalhostとなっていた
- VPC-AのEC2からのアクセスにはSG-1だけ影響
- VPC-CのEC2からのアクセスはSG-2だけ影響(SG-1で禁止されていてもアクセスできる)
まとめ
他アカウントへのVPCエンドポイントの作成も簡単にできますし、作成後のアクセスも問題ないです。
IPアドレスのところ注意が必要で、
- クラスタ再配置有効化後、Redshift本体のFQDNにアサインされるIP アドレスは初期状態は 1 個でクラスターの再配置(別アベイラビリティーゾーンへの移動)を行うたびに増える。
- Redshift-managed VPCエンドポイントにアサインされるIP アドレスは VPC ごとに 1 つ
AZ冗長ではないところだけが残念なのでここだけ改善してくれたらなと思います。
関連書籍
