re:Invent 2024: AWS Transfer Familyで実現するMFTのモダナイゼーション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Modernize managed file transfer with SFTP (STG305)
この動画では、AWS Transfer Familyを使用したManaged File Transferのモダナイゼーションについて解説しています。SFTPやFTPS、AS2などの複数プロトコルへの対応、認証とアクセス制御の柔軟性、自動化、集中管理されたログ記録と監査など、MFTに求められる主要な機能を詳しく説明します。Regeneronの事例では、AWS Transfer Familyの導入により90%のコスト削減を達成した具体的な成果が紹介されます。また、EventBridgeとの連携によるデータパイプラインの自動化や、新しく発表されたWeb Appsの機能、S3 Access Grantsを活用したアクセス制御など、最新の機能についても実際のデモを交えながら詳細に解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Transfer Familyの概要と本セッションの目的
みなさん、こんにちは。今朝の基調講演では、たくさんの刺激的な発表があり、早速試してみたいと思っていらっしゃることでしょう。本題に入る前に、少し手を挙げていただきたいと思います。SFTPを使用している方、あるいはエンドユーザーにSFTPを提供する必要がある方はどのくらいいらっしゃいますか？かなりの数の方がいらっしゃいますね。現在、従来型のManaged File Transferスタックを使用していて、モダナイズして置き換える方法を探している方はどのくらいいらっしゃいますか？素晴らしい。少し視点を変えて、MFTプラットフォームの一部としてAS2、AS4、EDIをお使いの方はどのくらいいらっしゃいますか？何人かの方が手を挙げていらっしゃいますね。最後に、パートナーとして、あるいはお客様のためにMFTスタックのモダナイゼーションを行っている方はどのくらいいらっしゃいますか？
手を挙げた方もそうでない方も、本日はSFTPを使用したManaged File Transferの管理とモダナイゼーションの方法について学んでいただけます。私はAWS Transfer Familyチームに所属するSmith Shriramです。同僚のFabioと一緒に登壇させていただきます。アジェンダをご紹介させていただきます。まず、Managed File Transferのモダナイゼーションの価値について説明し、実際にそれを実現したお客様の事例をご紹介します。次に、インテリジェントなデータパイプラインの一部として効果的に機能するMFTの構築方法について詳しく説明し、その重要性と、今年リリースした機能がどのように役立つかについてお話しします。
日曜日にリリースしたAWS Transfer Family Web Appsについて、私は非常に興奮しています。これは最新のリリースで、本セッションでも少し触れますが、明日のブレイクアウトセッションSTG217で詳しく説明します。メモしておいてください。Web Appsの仕組みとユースケースについて深く掘り下げます。FabioがクラウドネイティブなManaged File Transferの構築方法についてデモを行います。最後にまとめを行い、Q&Aの時間も設けています。
Managed File Transferのモダナイゼーションと顧客事例
まず、Managed File Transferに対する期待について整理してみましょう。最初によく聞かれるのは、複数のプロトコルへの対応です。SFTP、FTPS、AS2などの1つ以上のプロトコルが必要かもしれません。これが重要なのは、これらのプロトコルが業界標準だからです。つまり、組織の境界を越えてアプリケーション間でやり取りする場合、あなたのアプリケーションと取引先のアプリケーションが共通して使用できるのは、通常これらの業界標準プロトコルの1つということになります。2番目は認証と様々なアクセス制御の柔軟性です。多くの方がOctaやActive Directoryなど異なるディレクトリをお使いだと思いますが、MFTがこれらすべてのディレクトリをサポートしている必要があります。3番目の重要なトレンドは自動化です。プロセス全体を自動化して、1つ1つ手作業で管理する必要がないようにしたいというニーズです。そして4番目に最も重要なのは、集中管理されたログ記録と監査で、これにより多くの規制要件を満たすことができます。
お客様から伺っているのは - 多くの方が従来型のMFTスタックを管理されているとおっしゃっていましたが - そのスタックの管理は非常に課題の多いものとなっています。インフラストラクチャを管理し、接続性やストレージの増大するニーズに対応しなければならず、さらに取引先の数が増えるにつれて、それぞれの設定を管理する必要があります。そうした中で、オンプレミス環境でスタックを管理している場合、多くのデータはまだオンプレミスに保存されており、クラウド上のBIツールからはアクセスできない状態です。例えば、今朝の基調講演でBedrockのイノベーションについて多く聞かれたと思いますが、その一環として
オンプレミスでデータを保管していると、迅速なインサイトを得るのが非常に困難になります。規制業界で働いている方はどれくらいいらっしゃいますか？多くの手が挙がりましたね。その一環として、定期的にSFTPサーバーにパッチを適用し、セキュリティアップデートが確実に行われるようにする必要があります。これは皆さんのチームにとってさらなる負担となり、これらすべてを24時間365日稼働させることは、本来ならビジネスの差別化に使えるはずのリソースを消費してしまいます。
DevOpsでは、「Pets versus Cattle（ペットと家畜）」という有名な考え方があることをご存知の方も多いでしょう。多くのお客様が、MFTをペットのように扱いたくないとおっしゃっています。つまり、システムがダウンした時に、その特定のインフラを復旧させるために総力を挙げて世話をするような状況は避けたいということです。お客様が望んでいるのは、家畜のように扱うこと。つまり、システムリソースがダウンした際の個別の作業を最小限に抑え、クラウド上の他のインフラと同様に、共通のツールを使用して共通の環境にデプロイできることを望んでいるのです。
そこで私たちは、6年前のre:Invent 2018、ここLas VegasでまさにそのためにAWS Transfer Familyを発表しました。お客様のManaged File Transferの最新化を支援してきた6年間の経験を通じて、このサービスは管理の負担を軽減するだけでなく、データパイプラインの一部として活用できるように進化してきました。このサービスはフルマネージド型で、インフラの管理が不要で、高可用性があり、ビジネスの成長に応じてスケールします。すべてのサービスリソースはインフラストラクチャ・アズ・コードとしてデプロイできるため、開発者の皆様は簡単にアーキテクチャの一部として実行できます。また、複数のプロトコルをサポートしているため、取引先ネットワークを構築する際の柔軟性も確保できます。
今年、私たちはAmazon EventBridgeのサポートを開始しました。すべてのプロトコルを使用したファイルのアップロードやダウンロード時にイベントがトリガーされ、AWS Step Functionsのようなイベント駆動型ワークフローやジョブオーケストレーションエンジンを実行できます。これらのプロセスを自動化することで、ビジネスユーザーがそのデータからより迅速にインサイトを得られるようなダッシュボードを構築できます。世界中の数万のお客様がAWS Transfer Familyの恩恵を受けていることを、私は大変嬉しく思っています。
特に紹介したいお客様の一つがRegeneronです。彼らは、多くの皆様も共感されるかもしれない課題を抱えていました。それは従来型のオンプレミスMFTソリューションを使用していたことです。高額な費用がかかり、セキュリティ上の脅威があり、大きな運用オーバーヘッドを伴う多大なリソース投資が必要でした。さらに、求めていた認証オプションの柔軟性も得られませんでした。私たちはRegeneronのチームと緊密に協力し、AWS Transfer Familyを使用して社内ファイル転送サービスを構築し、認証やIPオプションの恩恵を受けられるようにしました。この新しいアーキテクチャにより、現在では多数の社内ユーザーと数千人の外部ユーザーがテラバイト規模のデータをアップロード・ダウンロードできるようになりました。運用負担を軽減し、コンプライアンス要件を満たし、さらに重要なことに、Transfer Familyを使用することで全体的に90%のコスト削減を達成しました。詳細をお知りになりたい方は、ぜひ写真を撮ってください。彼らがどのようにしてこれを実現したかを詳しく説明したブログ記事があります。
AWS Transfer Familyの主要機能と最新アップデート
データは私たちの日常生活において重要な要素となってきており、私と同じようなデータ愛好家の方々が大勢いらっしゃることを実感しています。そのデータからより迅速にインサイトを得るためには、Managed File Transferがデータパイプラインとネイティブに連携する必要があります。そして、まさにそれが、これからのセッションで取り上げるテーマです。
ファイルの到着、アップロード、ダウンロードをデータパイプラインとシームレスに連携させる方法について説明していきます。これにより、ビジネスユーザーがインサイトを得るまでの時間を、私たちのサービスを使ってより短縮できるようになります。
データレイクについて言えば、FINRAはAmazon S3が提供する多くのメリットを活用するため、S3をデータレイクとして使用したいと考えていました。本日のキーノートでもいくつかの関連する発表がありましたが、S3をデータレイクとして使用するためには、エンドユーザーがファイルを直接データレイクにアップロードできるSFTPサーバーが必要でした。彼らは自社でインフラを構築する代わりに、AWS Transfer Familyを使用してFileXプラットフォームを構築するため、私たちと協力しました。これにより運用の負担を軽減し、S3でのデータレイク構築とビジネスに必要なインサイトの獲得に集中することができました。
もう一つの例は電気自動車に関するものです。シンガポール政府は電気自動車の利用を促進したいと考えており、そのために充電ステーションが必要でした。充電ステーションを設置するには、かなりのインフラ投資が必要になります。この投資を行う前に、データに基づいた意思決定を行いたいと考えていました。しかし、そのデータの多くは、様々な場所の政府データベースやファイルシステムに保存されていました。彼らはAWS Transfer Family SFTPを使用して、そのデータをS3上のRawデータ・ランディングゾーンに取り込み、そこからAWS Step FunctionsやAmazon EMR Sparkジョブを簡単に開始して分析を行うことができました。他のお客様と同様に、CAPEXを削減してOPEXに置き換え、管理の負担を排除し、必要な場所に充電ステーションを建設するという最終目標に集中することができました。
私が紹介したお客様と同じように、多くの方々は非構造化データがあちこちに散在している状況にあります。AWS Transfer Familyは、これらの分散したデータソースをAWSに取り込むことを支援し、そこでさまざまなAWSサービスを使用して分析のためのデータの処理と変換を行うことができます。Amazon SageMaker、Amazon Bedrock、その他のサービスなど、データをAWSに取り込んでしまえば、可能性は無限大です。
現在、Managed File TransferとElectronic Data Interchangeに関する私たちのアプローチには3つの重要な柱があります。1つ目はサーバーで、SFTP、FTPS、FTP、AS2の構成を提供しています。最近、Web Appsをローンチしましたが、これはIAM Identity Centerで認証され、S3 Access Grantsでアクセス制御される、エンドユーザー向けのシンプルなWebインターフェースを提供します。2つ目はデータ処理で、組み込みのワークフローや、Step Functionsなどのジョブオーケストレーションエンジンを使用してより複雑な処理を構築できるイベントトリガーなど、複数のオプションを用意しています。3つ目はデータ統合で、昨年SFTPコネクターをローンチしました。これは、オンプレミス環境や取引先がホストする他のSFTPサーバーからデータを取得できる、スケーラブルな管理型クライアントです。
嬉しいことに、最近AWS B2B Data Interchangeに生成AIを活用したマッピングコード生成機能を追加しました。これにより、マッピングコードの構築に必要な時間と労力を大幅に削減できます。このサービスは、特にサプライチェーンや物流分野で取引先ネットワークを拡大したい場合など、数多くのユースケースを実現してきました。B2B Data Interchangeがその重労働を解消してくれます。
同様に、ヘルスケア分野で医療費請求処理や給付金、加入手続きに携わっており、コスト削減や医療の最適化、患者ケアの質の向上を目指してAWSでそのデータを簡単に活用したい場合も、このサービスによってそうしたアーキテクチャの構築を加速することができます。金融サービス分野でも多くのユースケースがあります。住宅ローン処理文書や不動産関連のデータを取り込む必要がある場合も、このサービスによってそうしたアーキテクチャに関連する重労働を軽減できます。
このサービスには4つの主要な機能があります。詳しく知りたい方は、ウェブサイトをご覧いただくか、ご質問がありましたら私たちにお声がけください。それでは、今年ローンチした機能について、データパイプラインとうまく連携するManaged File Transferの構築に役立つ内容を、Fabioにバトンタッチしたいと思います。ありがとうございます、Smitaさん。
イベントドリブンなデータパイプラインの構築
イベントドリブンについて話す際、本当に重要なのは、イベントを送信し、コンテキストを意識したイベントでデータ処理を自動化できる他のAWSサービスをターゲットにできる、しっかりとした中央イベントバスです。コンテキストを意識したというのは、誰がそのファイルをアップロードしたのか、いつアップロードされたのか、どのIPアドレスからファイルが来たのか、どのプロトコルが使用されたのかといった情報です。データの取り込みを容易にするため、複数のプロトコルをサポートする必要があります。私たちは、SFTP、FTPS、EDI用のAS2、そして最近では技術に詳しくないユーザー向けにHTTPSをサポートしています。もちろん、その上にガバナンスも必要です。そこで私たちは、インフラストラクチャに対するPCIやGxPなどの業界標準のサポートを含むセキュリティを担当し、お客様がセキュリティとコンプライアンスの要件に専念できるようにしています。
実際のデータパイプラインにインテリジェンスを追加する方法をお見せしましょう。データは Transfer Family を通じてインフラストラクチャに流れ込みます。このデータは通常、AWS の外部でホストされており、誰かが Transfer Family サーバーにファイルをアップロードしたり、Transfer Family コネクタを使用してファイルを取得したりする場合があります。Transfer Family を通じてファイルが取り込まれるとすぐにイベントが発生し、例えば AWS Step Functions のステートマシンをターゲットにして、データの取り込み、適切な場所への保存、そしてサービスがそのデータを利用できるようにするための全ステップをオーケストレーションすることができます。処理の後、Smita が言及した Bedrock を使用すれば、PDF ファイルの内容を読み取り、AWS Glue を使用してこの非構造化データを構造化データに変換し、Amazon Athena を使用して SQL 言語でクエリを実行したり、Amazon QuickSight を使用してデータを可視化したりすることができます。このスライドには、とても興味深いブログ記事への QR コードが表示されていますので、ぜひご覧になることをお勧めします。
Smita は MFT の3つの柱として、データへのアクセス、処理、統合について言及しました。アクセスの部分について詳しく見ていきましょう。 Transfer Family では、先ほど申し上げたように、プロトコルへのアクセスが提供されます。Web アププリケーションでサポートする新しいプロトコルとして HTTPS を追加しました。また、ネットワークセキュリティのオプションも提供しています。Transfer Family サーバーを作成する際、エンドポイントのホスト場所を選択できます - 外部からアクセス可能にすることも、VPC 内にエンドポイントをデプロイすることもできます。
セキュリティグループを活用してエンドポイントへのアクセスを制限することができます。さらに、アプリケーションパイプラインからのみアクセス可能なプライベート専用エンドポイントを作成することもできます。ネットワークセキュリティに加えて、強力な認証と認可も必要です。ユーザーに対して詳細な制御を行うためのオプションが必要です。次のスライドで詳しく説明しますが、今年、Okta、Azure AD、Amazon Cognito などの外部アイデンティティプロバイダーと AWS Transfer Family を簡単に統合できるツールキットをリリースしました。
すべてのデータプレーンとコントロールプレーンの API コールは Amazon CloudWatch と AWS CloudTrail に記録されます。ログは JSON 形式を使用しているため、CloudWatch で簡単にダッシュボードを作成できます。また、監査要件を満たすための CloudTrail もあります。 ユーザーが SSH キーを使用して認証する場合は、Transfer Family のマネージドユーザーを簡単に使用できます。ただし、パスワード認証が必要な場合は、AWS Directory Service との直接統合を提供しています。AWS でActive Directory をホストする場合はマネージドを使用できますし、オンプレミスの Active Directory に接続するためのコネクタを使用することもできます。
外部アイデンティティプロバイダーへの認証には AWS Lambda を使用するカスタム認証オプションを提供しており、Azure AD、Microsoft Directory、Amazon Cognito などほぼすべてのプロバイダーに対応できます。お客様からのフィードバックとして、この柔軟性は素晴らしいものの、 統合のための Lambda 関数を書くのに時間がかかるという声がありました。また、多くのお客様が複数の認証ソースとアイデンティティプロバイダーを使用しており、それらのアイデンティティプロバイダーを Transfer Family で引き続き使用したいと考えています。そのため、今年初めに外部アイデンティティプロバイダーと統合するためのツールキットをリリースしました。AWS CloudFormation テンプレートを使用して簡単にデプロイでき、複数のアイデンティティプロバイダーとのモジュール式の統合を提供し、DynamoDB の2つのテーブルで標準化されたスキーマを提供して、アイデンティティプロバイダーとユーザー、およびそのアクセス権限を定義できます。
セキュリティは組み込み済みで、特定のIPレンジからのアクセスに限定してユーザー認証を行うことも可能です。さまざまなIdentity Providerに対応したモジュールについては、GitHubリポジトリへのリンクを含む詳しい情報がブログ記事に掲載されています。 Amazon S3に保存されているデータに非技術者が簡単にアクセスできるように、今回Webアプリを提供することになりました。FTP、SFTP、AS2などのプロトコルはアプリケーションとの相性は良いのですが、非技術者にとってはそれほど使いやすくありません。Webアプリでは、外部ユーザーがS3にファイルをアップロードしたり、S3からファイルをダウンロードしたりできる、フルマネージドのWebインターフェースを提供します。設定は非常に簡単で、企業のブランドやカラースキームに合わせてカスタマイズすることができます。エンドユーザーにとっては、デモでお見せするように使い慣れたブラウザ体験となっており、一方で私たちは、基盤となるインフラの管理やHIPAA、PCIなどの基準への準拠、高可用性の確保を担当します。データへの簡単なアクセスについて説明しましたが、他のAWSサービスで利用できるようにするには、データの前処理が必要です。
Transfer Familyには2つのアプローチがあります。シンプルなワークフローが必要な場合は、図の左側にあるTransfer Family Managed Workflowsを使用できます。ファイルのコピー、タグ付け、復号化、削除などの処理をコードを書かずに実行でき、また事前定義されていないカスタムステップについては、ローコードのLambda関数を使用することができます。
しかし、レガシーなMFTで一般的な、よりフレキシブルでユーザーやファイルタイプに特化したワークフローを再現したい場合は、EventBridgeとの連携が真価を発揮します。柔軟性が高く、後ほどデモでお見せするように、Step Functionsなどでワークフローのステップを定義することができます。もう1つの重要な違いは、Transfer Family Managed Workflowsはサーバーを介してアップロードされたファイルでのみ動作するのに対し、EventBridge連携はファイルのアップロード、ダウンロード、さらにはコネクターを使用する場合など、あらゆる種類の操作で利用できることです。つまり、ファイルをアップロードする際に前処理を行ったり、SFTPサーバーからファイルをダウンロードした後に処理を行ったりすることができます。
これは、 Transfer Family Managed Workflowsを使用して設計できる典型的なシンプルなワークフローの例で、ファイルのアーカイブコピーを作成します。アップロード後にファイルを復号化し、Lambda関数を使用してGuardDutyなどを呼び出し、そのファイルのウイルススキャンを実行します。ワークフローの実行中に何か問題が発生して例外が発生した場合は、例外ハンドラーが用意されています。問題が発生した場合、例外が発生した際に異なるステップを実行する代替ワークフローを実行することができます。
そしてこちらが、EventBridge連携を使用して作成できる典型的なワークフローです。SFTPサーバーにファイルがアップロードされると、EventBridge連携を使用してStep Functionsのステートマシンをターゲットにし、そこでステップを実行していきます。ファイルにタグを付け、別のバケットにルーティングし、ファイルをアーカイブし、受け取ったファイルが期待通りのものであることを確認するためにファイルフォーマットをチェックできます。ファイルの暗号化や、暗号化されたファイルの復号化、マルウェアスキャン、あるいはPIIのスキャンを行って文書にそのような情報が含まれていないことを確認することもできます。そして、何か問題が発生した場合、例えばマルウェアスキャンで陽性が出た場合には、検疫用のエラーバケットにファイルを移動し、パートナーと何が起きたのかを確認することができます。
MFTインフラストラクチャーで外部データを統合する必要がある場合、SFTPコネクターは重要なコンポーネントとなります。既知のIPアドレスからの接続のみを許可する取引先とのファイル交換をシームレスに行えるよう、静的IPを導入しました。また、幅広い外部サーバー構成との互換性を確保するための標準化されたセキュリティポリシーも提供しています。SFTPコネクターは完全マネージド型のSFTPクライアントです。SFTPエンドポイントからのファイルのダウンロードやアップロードが可能で、今年はSFTPエンドポイントの一覧表示や既存のファイル転送のステータス確認のためのAPIを追加しました。これらの操作はAPIを使用してトリガーできるため、既存のパイプラインにシームレスに統合できます。
もちろん、SFTPサーバーと同様に、コネクターもすべての操作をCloudWatchとCloudTrailに記録するため、監査とセキュリティの要件を満たすことができます。ここでSFTPコネクターの主要な機能をいくつか詳しく見ていきましょう。まず第一に、これは完全マネージド型のクライアントです。転送するファイルの数を気にする必要はありません。生成されるトラフィックに応じて自動的にスケールします。コネクターを作成する際、コネクター自体の初期費用は発生せず、コネクターを使用して転送したデータ量に対してのみ料金が発生します。また、コネクターの作成は非常に簡単で、数分で完了します。
新しいAPIを使用することで、転送が進行中なのか、失敗したのか、成功したのかをリアルタイムで追跡できるようになりました。パイプラインの特定のポイントでファイル転送を開始する場合、転送が正常に完了したことを確認できなければ、次のステップに進むことができません。以前は、EventBridgeとの統合を使用する方法しかありませんでしたが、現在は簡単なAPI呼び出しで転送のステータスを確認でき、転送が完了した時点で次のステップに進むことができます。スライドに表示されているような、非常によく似たStep Functionsと処理パイプラインの作成方法を解説したこのブログ記事をぜひご覧ください。
デモに進む前に、昨年のre:Invent以降、私のチームが取り組んできたことについて少しお話ししたいと思います。2つのプロトコルについて、アウトバウンド転送用の静的IPを提供し、AS2プロトコルをEventBridgeと統合することでAS2のサポートを改善しました。また、互換性の観点から重要な自己署名証明書のサポートも導入しました。SFTPプロトコルについても同様に取り組みを進め、コネクター用の静的IPとEventBridge統合を提供しました。さらに、コネクターを使用して送受信できるファイルサイズと、実行可能な操作のスループットを向上させました。外部サーバー構成との互換性を高めるため、標準化されたセキュリティポリシーを導入しました。先ほどお話しした2つのAPIも導入しました。リージョンの観点では、AWS Transfer FamilyをCanada WestとMalaysiaリージョンでローンチしました。そして最後に、2日前に非技術者ユーザーがS3に保存されたデータに簡単にアクセスできるWeb appsをローンチしました。
それではデモの時間です。ただ、私のラップトップに移る前に、このデモのアーキテクチャーを簡単にご紹介したいと思います。2つのStep Functionsを使用します。1つ目は、外部のSFTPサーバー（これはたまたまTransfer Familyサーバーです）上のファイルを一覧表示します。ファイルを取得すると、EventBridgeがスライドに表示されている別のStep Functionsを呼び出します。このStep Functionsでは、ファイルを処理し、ファイルのコピーをアーカイブします。取得したファイルがPDFでない場合は復号化を行います。復号化後、Amazon GuardDutyを使用してマルウェアスキャンを実行し、スキャンが完了するのを待ってから、このパートナー固有の次のステップに進みます。これはEDIファイルをJSON形式に変換する処理で、AWS B2B Data Interchangeを使用してJSONファイルをS3バケットに保存します。最後のステップでは、もう必要ないため、元の暗号化されたファイルを削除します。
AWS Transfer Family Web Appsのデモンストレーション
AWS Transfer Family Web アプリにログインして、Web インターフェースから JSON ファイルと EDI ファイルにアクセスする方法をお見せします。これにより、Web アプリを使用するエンドユーザーの体験をご覧いただけます。 まず、reinvent24user アカウントを使って Transfer Web アプリにログインします。 ログインすると、誰でも特別なトレーニングなしで使える親しみやすい Web インターフェースが表示されます。このバケット内では partner_01 というプレフィックスしか見えません。後ほど、バケット内の特定のフォルダやプレフィックスへのアクセスをどのように制限しているかをお見せします。ここでは読み取りと書き込みの権限があり、ユーザーに対して読み取り専用、書き込み専用、またはその両方を付与するかを実際に決めることができます。
フォルダの中を見てみると、 予想通り何も見つかりません。ここで最初の Step Functions ステートマシンを起動します。 ステートマシンを実行する際、渡すパラメータはパートナーのID（この場合は partner_01）だけです。実際のユースケースでは、このステートマシンはおそらくスケジュールによってトリガーされるでしょう。今回はデモのために手動で実行しているだけです。
ステートマシンで何が起こっているかを見てみましょう。まず、get partner parameters ステップで DynamoDB にアクセスし、partner_01 のアイテムを取得します。この場合必要なのは、パートナーとの接続に使用するコネクタです。コネクタには、URI や SFTP サーバーへの認証に必要な認証情報を含む、パートナーへの接続に必要な設定が含まれています。その後、そこにあるファイルのリストを取得し、ステートマシンを一時停止します。この API は非同期的な性質を持つため、リスト取得を開始し、リストが完了するまで待機します。EventBridge からイベントを受け取ると、ステートマシンを再開し、JSON ファイルであるリストを確認します。リストに何も含まれていない場合は、することがないのでステートマシンは失敗します。リストにファイルが含まれている場合は、AWS Transfer Family API にこれらのファイルの転送を開始するよう指示します。
ファイル転送が完了すると、 EventBridge 連携を使用してこの Step Functions が起動され、今まさにトリガーされたところです。 ここで何が起こったかを見てみましょう。まず最初に、 ファイルに手を加える前にアーカイブコピーを作成します。次に、DynamoDB テーブルにアクセスして、復号化に使用する PGP キーや、この特定のパートナーに対して行いたい後処理の種類などの必要なパラメータを取得します。ファイルが暗号化されている場合は復号化を進め、そうでない場合は何もしません。その後、Amazon GuardDuty が有効になっている外部バケットにファイルを送信してマルウェアスキャンを開始し、GuardDuty がスキャンを完了するのを待ちます。スキャン結果を受け取ったらステートマシンを再開し、ファイルにマルウェアが感染している場合は、ファイルを隔離してダウンストリームアプリケーションで利用できないようにします。
ファイルがクリーンな場合は、そのパートナー固有のステップを実行します。この場合、ファイルを B2B Data Interchange に送信して EDI ファイルを JSON に変換し、最後に不要となった最初の復号化ファイルを削除します。
では、Web アプリに戻って更新してみましょう。EDIファイルが表示されています。 これは出荷状況の更新を提供するEDI 214ですが、このようにEDIフォーマットで表示されています。 EDIフォルダの中には、transformed fileフォルダがあります。 B2B Data Interchangeは、どのTransformerが使用されたかを識別できるように、Transformer IDを変換ファイルの先頭に付加します。ここでJSONファイルを確認できます。表示されている名前は、元のファイル名にタイムスタンプとJSON拡張子が付いたものです。これをダウンロードして見てみると、こちらに表示されているEDIファイルと同じ内容がJSON形式で表現されているのがわかります。
このJSONは、下流のERPシステムで利用することができます。ファイルにマルウェアが含まれていないことを確認し、自動的に変換されていることがわかります。もはやバッチ処理で行う必要はなく、ファイルが到着次第自動的に処理できます。これがユーザーから見た画面ですが、次は管理者の視点から見てみましょう。Transfer Familyコンソールに、この新しいWeb appsセクションを追加しました。これが先ほどログインしたWeb appです。Identity ProviderとしてIAM Identity Centerを使用していますが、Oktaなどの外部IDPをIdentity Centerとの連携を通じて使用することもできます。
ここにIdentity Centerで定義されているユーザーがいます。管理者として自分のユーザーを開くと、通常の管理タスクを実行できます。ユーザーのパスワードのリセット、アクセスの無効化、アクティブなセッションの確認、ログイン元のIPアドレスの確認、必要に応じてセッションの削除などが可能です。Web appに戻ると、Web appにIAMロールを割り当てて、Webアプリケーション全体の初期アクセス範囲を設定していることがわかります。ユーザーごとのアクセス範囲を制限するには、IAMとS3 Access Grantsを使用します。
ここでAccess grantsを見ると、いくつか作成済みのものがあり、そのうちの1つが私のユーザーに割り当てられています。これがそのAccess grantで、partner_01というプレフィックスが付いたこのバケットへのアクセス権を持っています。Grantの作成は非常に簡単で、S3に登録した場所を参照するだけです。このユーザーにアクセス権を付与したいバケットを選択しますが、バケット全体ではなく、特定のプレフィックスへのアクセスだけを許可したい場合、このように設定します。そして権限レベルを決定します - 今回はread-onlyにして、書き込みはできないようにします。次にGranteeのタイプを選択します。この場合はIAM Identity Centerです。このAccess grantを特定のユーザーまたはユーザーグループに割り当て、そのユーザーまたはグループの IDを指定するだけです。とても簡単ですね。
それでは、これらのパイプラインがEventBridgeを使ってどのように制御されているかを見ていきましょう。 EventBridgeを見ると、これはState Machineを一時停止してリスティングが完了するのを待つために使用したEventBridgeルールです。AWS Transfer Familyから発行されたイベントをキャプチャしています。私が注目しているのは、リスティングが正常に完了したか失敗したかを示すイベントだけです。そして、Step Functions のState Machineに移動してリスティングの結果を再開するLambda関数をターゲットとし、「リストがここにあるので取得してください」または「リストが失敗したのでState Machineを失敗させてください」と伝えます。
転送が完了すると、 別のEventBridgeルールを使用します。今回は、このタイプのイベントにのみ注目します。 コネクターがファイルを正常に取得したタイミングだけを知りたいのです。そうなった時、先ほどお見せしたStep Functionsを直接ターゲットとします。また、必要に応じてトラブルシューティングを容易にするため、EventBridgeでキャプチャしたこれらのイベントをすべてログとして記録するCloudWatchロググループもターゲットとしています。これでデモは終わりです。Smithさん、セッションのまとめとQ&Aの時間に戻したいと思います。
まとめと次のステップ：リソースとQ&A
ありがとう、Fabio。素晴らしいデモでした。皆さんがクラウドネイティブな MFTの一部として、Fabioが示したものを構築する方法を学んでいただけたと思います。次のステップとして、 もしAWSのアカウントマネージャーがいらっしゃる場合は、このファイル転送セッション、SFTPセッションに参加したことを伝え、Fabioが示したデモを構築できるワークショップへの参加を希望することをお伝えください。100、200、300レベルの約23のワークショップがあり、アカウントマネージャーがプライベートイベントとしてホストすることも、自己ペースで実施することもできます。また、お話ししたように、ツールキットは開発を加速するためのものなので、同じLambdaを一から作る必要はありません。また、DynamoDBを使用してアクセス制御を構築する方法についてのベストプラクティスも提供しています。
第三に、ワークショップについてご紹介したいと思います。QRコードを見たい方は、写真を撮ってください。 100、200、そして300レベルのワークショップがあります。Fabioが示したデモは200レベルと300レベルのワークショップにまたがっています。 第三のポイントに戻りますが、組織内にビルダーリソースがない方もいらっしゃるかもしれません。Transfer Familyのベストプラクティスを専門とするパートナープログラムがあり、MFTの構築をサポートしています。最近では、Scale Capacityが Los Angeles市のファイル転送インフラのモダナイゼーションとコスト削減を支援した事例があります。このウェブサイトでMFT移行に関するパートナー主導の成功事例をご覧いただけます。
製品のウェブサイトガイド、動画など、 さらに多くのリソースがあります。サービス内に多くのリソースがあり、これらのドキュメントは迅速な立ち上げに役立ちます。 Fabioが言及した最近のローンチと地域展開について、全体像をお伝えしたいと思います。Transfer Familyは、すべてのAWSコマーシャルリージョン、GovCloud、そして中国で利用可能です。多くの方がマルチリージョン展開をされていると思いますが、Transfer Familyは現在、これらの多くのリージョンで利用可能です。ストレージの学習の旅を続けていただければと思います。Transfer Family以外にも、AWSストレージを理解し活用するための多くのリソースがあります。それでは質疑応答の時間に移りたいと思います。数分ありますので、質問のある方は手を挙げてください。どんな質問にもお答えいたします。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion