[レポート] STG326 – フルマネージドの SFTP サービス！AWS Transfer for SFTP の紹介 #reinvent

本記事は、AWS re:Invent 2018 のセッション 「STG326 - Introducing AWS Transfer for SFTP, a Fully Managed SFTP Service for Amazon S3」のレポートです。

SFTP is used for the exchange of data across many industries, including financial services, healthcare, and retail. In this session, we will introduce you to AWS Transfer for SFTP, a service that helps you easily migrate file transfer workflows to AWS, without needing to modify applications or manage SFTP servers. We will demonstrate the product and talk about how to migrate your users so they continue to use their existing SFTP clients and credentials, while the data they access is stored in S3. You will also learn how FINRA is using this new service in conjunction with their Data Lake on AWS.

• スピーカー
  • Asa Kalavade - General Manager, AWS
  • Smitha Sriram - Senior Product Manager, AWS
  • Ranganathan Rajagopal - Senior Director, FINRA

レポート

アジェンダ

• なぜ AWS Transfer for SFTP を作ったのか？
• 利点、機能、価格
• FINRA が AWS SFTP を使用してファイル交換を容易にした方法

なぜ AWS Transfer for SFTP を作ったのか？

SFTP：それはここにもあるし、どこにでもある

プロトコルは、さまざまな業界のワークフローに深く埋め込まれている

• 第三者からのアップロードを受け取る
• 配信された値をデータに追加
• 内部的なデータ転送

今のオンプレミスでの SFTP アーキテクチャ

数百の SFTP クライアントやアプリケーションからの転送を受けるなかで、以下のような課題があった。

• オンプレミスでのデータ格納
• ホストサーバや、管理、監視
• インフラストラクチャの運用
• 前払いコスト (ライセンス)

SFTP ワークフローを AWS に移行すると

以下のような利点がある

• Amazon S3 は耐久性の高いストレージ
• データの処理、アーカイブ、および保持
• AWS サービスとの統合

数百のパートナーは、クラウドと統合するためにワークフローを変更してくれますか？

クラウドでのセルフホスト型 SFTP の課題

• VPC ホスト、スケーリング、監視
• ディレクトリ統合なし
• エンタープライズ機能が欠けている
• 使うには複雑

AWS Transfer for SFTP

Amazon S3 用のフルマネージド型 SFTP サービス

• 既存のワークフローをシームレスに移行
• AWS でフルマネージド
• 安全でコンプライアンス
• AWS サービスとのネイティブな統合
• コスト効率が高い
• 使いやすい

3つのステップで簡単に

1. ホストネームをマップする
   • ホストネームをサーバーエンドポイントと関連付ける
2. S3 バケットを選択
   • SFTP を介して転送されたデータを格納する S3 バケットにアクセスするための IAM ロールを作成
3. ユーザ設定
   • ファイル操作するためにユーザを作成し IAM ロールと関連付ける

これだけで、AWS SFTP サーバのエンドポイントが使えて、データ転送ができます。

今からの SFTP アーキテクチャ

今の数百ものユーザに対して、何の変更を要求することなく AWS Transfer for SFTP が使えます。

• フルマネージドなサービス
• エンドユーザの混乱はありません
• エンタープライズにも使えます
• 使い方はシンプル
• 従量課金
• クラウドネイティブな都合

シームレスな移行

• AWS Transfer for SFTP への移行は、エンドユーザから完全に透過的
  • 既存の SFTP ドメインのサービスエンドポイントへのルートに Amazon Route 53 を使う
  • 転送クライアントはそのまま使える
  • ホストネームと認証情報もそのまま使える
• エンドユーザの認証には、既存の ID プロバイダ（Microsoft AD、LDAP）を統合

フルマネージド

• SFTP サーバーの管理から時間を節約
• リアルタイムでニーズに合わせて自動的にスケーリングします。
• リージョン内のアベイラビリティーゾーン間で冗長化

AWS ネイティブに統合

• Amazon S3 バケットに保存し、アーカイブ、データ処理、解析に利用
• Amazon S3 events で、アップロードのポスト処理を自動化
• IAM でユーザのリソースアクセスを制御
• Amazon S3 もしくは AWS KMS を使って、データをサーバーサイドで暗号化

安全でコンプライアンス

• HIPAA 対応、PCI 準拠
• SSE-S3 や SSE-KMS など保存時の暗号化オプション
• Amazon CloudWatch でのエンドユーザーアクティビティトラッキング

コスト効率に優れている

• SFTP エンドポイント料金は、$0.30/時間
• SFTP のアップロードとダウンロードが $0.04/GB
• コストの例
  • 10GB/日 使用して、年間コストは $2.7K
  • 100GB/日 使用して、年間コストは $3.6K

使いやすい

• AWS マネジメントコンソールまたはサービス API を使用したセットアップと設定が簡単
• SFTP サーバーまたはユーザーアクセス設定に IT の専門知識は必要ありません

FINRA 事例

ストーリー

• オンプレミスの課題とクラウドジャーニー
• FINRA のデータレイクは AWS にある
• オンプレミス SFTP の課題
• AWS Transfer for SFTP による FINRA の ファイル交換プラットフォーム
• 次のステップ

オンプレミスの課題とクラウドジャーニー

オンプレミスデータとインフラストラクチャの辛み

• データ成長
  • Year-to-Year で 20% ~ 30% 成長
• インフラコスト
  • ピーク時にはコストが掛かりすぎる:　一定の EoL サイクル
  • インフラストラクチャやコアミッションにもっと費しますか？
• データガバナンスに関する質問
  • 何を持ってますか？ソースは？バージョンは？保持してるの？k
  • 40万以上のテーブルをトラッキングするのは容易ではない
• データ移行の問題
  • どのようにデータ管理をスケールするか？
  • 断片化にもかかわらず、どのように分析を実行できますか？

FINRA の AWS データレイク

スケーラブルなデータ管理

データはどこにありますか？

• すべてのデータは Amazon S3 にあります
  • マスターデータ、可用性、リージョン間のデータセキュリティ、レプリケーション、バージョニングなどの 1 つの場所にある
• コンピューティングからのストレージの分離

FINRA の AWS 使用統計

• 1日あたり 50,000 以上の Amazon EC2 ノード
• Amazon EC2 の 93% 以上は Amazon EMR の基盤（主にスポットインスタンス）
• 30 PB 以上のストレージ（Amazon S3, Amazon Glacier）

オンプレミス SFTP 概要と課題

SFTP@FINRA

• 使用法
  • 1000 以上のアクティブユー
  • 月あたり 600万 ファイルの転送
  • 月あたり 700万 Amazon S3 API コール
• オンプレミスアーキテクチャ
  • 本番環境の FTP サーバは 6台
  • 本番環境の NAS ストレージは 20TB
  • DR 環境は本番環境と同じ
  • SFTP ファイルの提出に基づく重要な SLA

FINRA の AWS アーキテクチャ

オンプレミスのファイル転送管理の課題

• 顧客のための複数エンドポイント
• 異なる実装
• セキュリティのアプローチは、異なる実装間で矛盾
• マルチアカウト、マルチな認可メカニズム
• すべての実装は冗長化されているわけではない
• カスタマイズされた COTS の複数バージョン
• オペレーションの冗長性

クラウド基盤の SFTP サービス（初期の選択）

選択	課題
1. 社内開発	ROI は全く魅力的ではなかった
2. 同じ COTS 製品を使う	FINRA AMI の管理に課題
3. AWS ネイティブな外部製品を使う	いくつかの機能でギャップ

FINRA が AWS SFTP を使用してファイル交換を容易にした方法

AWS SFTP によるファイル交換

SFTP エンドポイントの前段には Firewall と NLB を配置して、プライベートなエンドポイントとして利用しネットワーク的なアクセスを限定。次に、認証認可のバックグラウンドは Lambda + ECS で構成し、STS から一時的なトークンを取得して暗号化の KMS キーを取得するなど、セキュアな構成になっているのが判ります。

AWS Transfer for SFTP からどのような利点を得たか

• オペレーション不可の軽減
  • ゴールはオペレーション作業の軽減：ビジネスニーズに集中できる
  • フルマネージドは手作業が不要になり、インフラ管理も不要、パッチ適用も不要など
  • 自動的にスケーリング
  • マルチ AZ のサポートにより災害復旧の要件を満たす
• DevOps は AWS ネイティブと相性が良い
  • ネイティブな AWS サービスの統合により、一貫した管理エクスペリエンスで DevOps を標準化することができます。
  • FINRA は 以下のサービスと AWS FTP を統合している
    • データレイクのための Amazon S3
    • AWS KMS 暗号化
    • IAM
    • BYO 認証 のための API Gateway
      • 業界標準の AuthN や AuthZ をサポート
• Amazon S3 データレイクを単一のソースとした
  • ファイルのバージョン、データストアの場所の混乱はない

次のステップ

• 2019 1Q までに SFTP ワークロードを AWS Transfer for SFTP に移行する
• ファイル交換 を HTTPS サポートに拡張
• FINRA の顧客向けに、外部公開の単一ファイル共有基盤の立ち上げ
  • ドラッグ＆ドロップ でアップロードとダウンロード
  • 外部顧客向けに API をサポート

認証モードをより深く理解する

ユーザアクセスのサービス管理

• サービス内のユーザーIDとキーを保存し、管理する
  1. AWS マネージメントコンソールで使う、ユーザ認証情報とキーを構成
  2. ユーザは既存で提供されているクライアントと認証情報を使う
  3. ファイル転送は、IAM を使って Amazon S3 へのアクセスする

カスタム IdP のプラグイン

• カスタムされた IdP を持っている場合は、API Gateawy を使って統合する
  1. IdP 統合に API Gateay メソッドを使う
  2. サービスのユーザ認証は API Gateawy を経由して IdP を使う
  3. サービスはファイル転送の間、バケットへのアクセスのために IAM ロールを信頼する

さいごに

「S3 に FTP でファイル転送したいんだけど」というご相談をいただくケースは非常に多かったので、これで幸せになるユーザーはたくさんいるんじゃないでしょうか。FINRA の事例のような大規模環境での実績があると、これから導入しようと考えているユーザにとっては安心な実績ですね！

また、従来のクライアントや、認証情報をそのまま使え、エンドユーザからは透過的に移行できることは、現場の管理者にとっては非常に重要なポイントになりそうです！

以上！大阪オフィスの丸毛（@marumo1981）でした！