[アップデート]AWS Transfer Family SFTP コネクタがVPCを経由してプライベートなSFTPサーバにアクセスできるようになりました
初めに
先日SFTPコネクタにアップデートがあり、VPC Latticeの機能を利用することでパブリックIPを持たないリソースに対してアクセスできるようになりました。
これまでSFTPコネクタの通信はアカウントに割り当てられたパブリックIPから通信をするものとなっており、この関係で通信するSFTPサーバもインターネット経由でアクセスできるようにしておく必要がありました。
そのため外部公開したくないSFTPサーバをターゲットとして利用することがこれまでは難しかったのですが、今回のアップデートによりVPCを経由して通信ができるようになったので、これによりDirect Connectや拠点VPNを併用することでインターネットに公開されていないSFTPサーバとの通信が可能となります。
またVPCを経由することで通信経路をユーザ側で制御できるようになりますので、インターネット経由の場合でもNAT Gateway + BYOIPを利用してユーザが指定するIPから通信を行う、Network Firewallや各種仮想アプライアンス製品の利用で通信をIPS/IDS管理配下におくといったメリットを得られます。
VPC Latticeの利用?
さてVPC Latticeです。自分も概要は知っている程の知識ですので改めてなんだっけ?を少しだけ見ておきます。
VPC LatticeはVPCを跨いで各種VPC上のサービスのデータをやりとりするためのサービスとなります。
概念としてはVPC Peeringといったネットワーク全体を共有するものではなくPrivate Linkのようなイメージが近く、生成されたエンドポイントを通して共有しているサービス間での通信を行うものといったものになります。
VPC Latticeは元々はHTTP(S)、gRPCでの通信のみをサポートしていましたが現在ではTCP通信全般をサポートしており、今回もその方式を利用して通信をする形になります。
今回のイメージとしてはこのような形です。
VPC Latticeの仕組みを使ってアクセスはしてはいますが、SFTPコネクタ自体はVPC外リソースとはなります(見えないけどAWS管理のVPCが動いてるんだろうなぁで想像しています)。
ユーザ側で設定が必要なのは自VPC上のResource ConfigurationとResource Gatewayのみになり、SFTPコネクタ作成時の設定でこれを指定するとよしなに繋ぎ込んでくれる形です。
料金について
本機能によるTransfer Family側の追加費用はありません。
ただしVPC Latticeの通信料金、Direct Connectを利用する場合はその維持・通信料金、NAT Gatewayを利用する場合NAT Gateway側の通信料金、といった形で周辺の部分で追加費用が発生するためご注意ください。
使ってみる
さて実際に設定して使ってみましょう。今回はLatticeを経由してVPC上のEC2と通信します(上の図のCase 2)
VPC Latticeの設定
SFTPコネクタでLatticeのリソースの指定が必要となるためこちらを生成します。
必要なのは以下の2種のリソースです
- Resource Gateway
- Latticeで接続に利用するENIの集合体
- Resource Configuration
- 利用するResource Gatewayの情報、接続先となるリソースのIPやポートといった接続情報
設定は執筆現時点のマネジメントコンソールですと、VPCの画面の左メニュー「リソースゲートウェイ」「リソース設定」になります。
Resource Gateway
以下のように生成するENIの数、ENIが生成されるサブネット、利用するセキュリティグループを指定します。
通信はSFTPコネクタ側から接続先のサーバのアウトバウンド方面で行われますので、セキュリティグループの設定上インバウンドの許可は不要です。
用途としてはアウトバウンドを明確に制御したい場合はアウトバウンド方面を制御する設定を追加する、接続先がAWS上のサービスの場合は接続先のセキュリティグループ側で制御するために利用するという形になります。
IPは指定したサブネットからランダムに割り当てられますので、Direct Connectや拠点間VPN経由でオンプレミス上のサーバに接続するといったIPベースでアクセスの制御が必要になる場合は専用のサブネットを作ってそこにResource Gatewayを配置する方が良さそうです。
Resource Configuration
リソース設定は以下のようになります。SFTPコネクタ上の設定としてはこれを指定しどのゲートウェイを利用してどのサーバに接続するかを設定する形になります。
ポートの範囲についてはLatticeとして指定したサーバに対してどのポートのアクセスを許可するか?といった通信の許可的な意味合いとなり、実際に利用するポートに関してはSFTPコネクタ側で指定する形になります。
少ないとは思いますが定期的にポートを変更するようなケースかつ、変更の手間を減らしたいのであればここは少し広めに開けておいても良いかもしれません。
SFTPコネクタの設定
設定としては「サービスマネージド」がこれまでの接続方式となり、「VPC Lattice」が今回利用する方式となります。
マネジメントコンソール経由での設定の場合は、接続先の指定が「サービスマネージド」URLで接続先のIP(+ポート)、「VPC Lattice」先ほど作成したVPC LatticeのResource Configurationの指定+利用するポートの違いのみでそれ以外の項目は変わりません。IAMロールの権限にLattice用に追加の権限をというのもありませんでした。
各種設定については以下の記事を参考にしてください。
動作確認
ここまでうまくできていればマネジメントコンソールのテスト接続から確認可能となります。
接続先となる/var/log/secure
を確認するとテスト接続のアクセスが指定したサブネットのプライベートIPから来てることが確認できます。
Oct 17 09:24:55 ip-192-168-4-xxx sshd[1741]: Did not receive identification string from 192.168.1.xxx port 38242
Oct 17 09:24:55 ip-192-168-4-xxx sshd[1742]: Accepted publickey for sftpuser from 192.168.1.xxx port 19212 ssh2: RSA SHA256:xxxxx
Oct 17 09:24:55 ip-192-168-4-xxx sshd[1742]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
Oct 17 09:24:55 ip-192-168-4-xxx sshd[1742]: pam_unix(sshd:session): session closed for user sftpuser
一応ファイルが転送できることも確認しておきましょう。
% ls -l ~/rec
total 0
% aws transfer start-file-transfer --connector-id c-xxxxx --send-file-paths /xxxxx/bimi-logo.svg --remote-directory-path /home/sftpuser/rec
{
"TransferId": "xxxxx"
}
% ls -l ~/rec
total 8
-rw-rw-r-- 1 sftpuser sftpuser 4722 Oct 17 09:40 bimi-logo.svg
終わりに
今回はSFTPコネクタの新しい接続方式を試してみました。
VPC Latticeと言われた時点で普段触らないので一瞬うっ...となったのですがSFTPコネクタで利用する分には受け口となる
Gatewayの準備と接続先の設定をちょっと入れるだけで本格的な知識は不要ですので設定自体はお手軽となります。
付随して発生する料金はあるものの通信をフルマネージドな領域ではなくVPCに持ち込むことで通信制御を色々できるようになるので経路の問題で断念されてた方にとってはかなり嬉しいアップデートではないでしょうか。
(特にサービスの性質的にAWS CLIを入れられずSFTPで接続するしかないといったような限られている環境が用途として多くなり、そういった環境だと他の制限も厳しくなると思いますので)