翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Transfer Family マネージドワークフロー
AWS Transfer Family は、ファイル処理のマネージドワークフローをサポートしています。管理されたワークフローを使えば、SFTP、FTPS、または FTP でファイルが転送された後に、ワークフローを開始することができます。この機能を使えば、ファイル処理に必要なすべてのステップを調整することで、企業間（B2B）ファイル交換のコンプライアンス要件を安全かつコスト効率よく満たすことができます。さらに、エンドツーエンドの監査と可視化というメリットがあります。
![\[管理されたワークフローがファイル処理をどのように支援するかを示すフロー図。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-diagram.png)
マネージドワークフローは、ファイル処理タスクをオーケストレーションすることで、ダウンストリームのアプリケーションで消費される前にデータを前処理するのに役立ちます。このようなファイル処理タスクには以下が含まれる場合があります。
+ ファイルをユーザー固有のフォルダーに移動します。
+ ワークフローの一部としてファイルを復号します。
+ ファイルのタグ付け
+ AWS Lambda 関数を作成してワークフローにアタッチすることで、カスタム処理を実行します。
+ ファイルが正常に転送されたら通知を送信する。(このユースケースの詳細については、[AWS Transfer Family 「マネージドワークフローを使用してファイル配信通知をカスタマイズ](https://aws.amazon.com/blogs/storage/customize-file-delivery-notifications-using-aws-transfer-family-managed-workflows/)する」を参照してください。)
組織内の複数の事業部門にまたがる一般的なアップロード後のファイル処理タスクを迅速に複製して標準化するには、Infrastructure as Code (IaC) を使用してワークフローを展開できます。完全にアップロードされたファイルに対して開始する管理ワークフローを指定できます。また、セッションが途中で切断されたために部分的にしかアップロードされないファイルに対して、別の管理ワークフローを開始するように指定することもできます。組み込みの例外処理機能により、ファイル処理の結果にすばやく対応できるとともに、失敗の処理方法を制御できます。さらに、ワークフローの各ステップでは詳細なログが生成され、それを監査してデータの系統を追跡できます。
始めるには、以下のタスクを実行する：
1. 要件に基づいて、コピー、タグ付け、およびその他のステップなどの前処理アクションを含めるようにワークフローを設定します。詳細については、「[ワークフローを作成する](create-workflow.md)」を参照してください。
1. Transfer Familyがワークフローを実行するための実行ロールを設定します。詳細については、「[ワークフローの IAM ポリシー](workflow-execution-role.md)」を参照してください。
1. ワークフローをサーバーにマップすると、ファイルの到着時に、このワークフローで指定されたアクションがリアルタイムで評価され、開始されます。詳細については、「[ワークフローの設定と実行](create-workflow.md#configure-workflow)」を参照してください。
**関連情報**
+ ワークフローの実行を監視するには、[Transfer Family サーバーの CloudWatch メトリクスの使用](metrics.md)を参照してください。
+ 詳細な実行ログとトラブルシューティング情報については、[Amazon CloudWatch を使ってワークフロー関連のエラーをトラブルシューティングする](workflow-issues.md#workflows-cloudwatch-errors)を参照してください。
+ Transfer Family は、ブログ投稿と、ファイル転送ソリューションの構築に役立つワークショップを提供します。このソリューションは、 AWS Transfer Family マネージド SFTP/FTPS エンドポイントに 、ユーザー管理に Amazon Cognito と DynamoDB を活用します。
ブログ記事は、 [AWS Transfer Family および Amazon S3 での ID プロバイダーとしての Amazon Cognito Amazon S3](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/)の使用で入手できます。ワークショップの詳細については、[こちらを参照してください](https://catalog.workshops.aws/transfer-family-sftp/en-US)。
+ 次の動画では Transfer Family マネージドワークフローについて簡単に紹介しています。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/t-iNqCRospw)
+ 次のワークショップでは、外部 SFTP サーバーから Amazon S3 へのファイル転送と、それらのファイルの一般的な前処理と後処理を含む、完全に自動化されたイベント駆動型ワークフローを構築するための実践的なラボを提供します。[イベント駆動型 MFT ワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/e55c90e0-bbb0-47e1-be83-6bafa3a59a8a/en-US)です。
この動画では、このワークショップのウォークスルーを紹介します。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/oojopisG4lA)
**Topics**
+ [ワークフローを作成する](create-workflow.md)
+ [事前定義されたステップを使用する](nominal-steps-workflow.md)
+ [カスタムのファイル処理ステップを使用してください。](custom-step-details.md)
+ [ワークフローの IAM ポリシー](workflow-execution-role.md)
+ [ワークフローの例外処理](#exception-workflow)
+ [ワークフロー実行のモニタリング](cloudwatch-workflow.md)
+ [テンプレートからワークフローを作成する](workflow-template.md)
+ [Transfer Family サーバーからワークフローを削除する](#remove-workflow-association)
+ [マネージドワークフローの制限事項と機能制限](#limitations-workflow)
マネージドワークフローを開始する際のヒントについては、次のリソースを参照してください。
+ [AWS Transfer Family マネージドワークフロー](https://www.youtube.com/watch?v=t-iNqCRospw)デモビデオ
+ [AWS Transfer Family ワークフローを使用したクラウドネイティブなファイル転送プラットフォームの構築](https://aws.amazon.com/blogs/architecture/building-a-cloud-native-file-transfer-platform-using-aws-transfer-family-workflows/)に関するブログ記事
# ワークフローを作成する
このトピックで説明されているように AWS マネジメントコンソール、 を使用してマネージドワークフローを作成できます。ワークフローの作成プロセスをできるだけ簡単にするために、コンソールのほとんどのセクションでコンテキストヘルプパネルを使用できます。
ワークフローには次の 2 種類のステップがあります。
+ **ノミナルステップ** — ノミナルステップは、受信ファイルに適用したいファイル処理ステップです。ノミナルステップを複数選択した場合、各ステップは線形シーケンスで処理されます。
+ **例外処理ステップ** – 例外ハンドラーは、わずかなステップが失敗したり、検証エラーが発生した場合に AWS Transfer Family 実行されるファイル処理ステップです。
**ワークフローを作成する**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. ナビゲーションペインで [**Workflows**] (ワークフロー) を選択します。
1. [**Workflows**] (ワークフロー) ページで [**Create workflow**] (ワークフローの作成) を選択します。
1. 「**ワークフローの作成**」ページで、説明を入力します。この説明は [**Workflows**] (ワークフロー) ページに表示されます。
1. **[ノミナルステップ]** セクションで **[ステップを追加]** を選択します。1 つ以上のステップを追加します。
1. 使用可能なオプションからステップタイプを選択します。各種ステップの詳細については、[事前定義されたステップを使用する](nominal-steps-workflow.md) を参照してください。
1. [**Next**] (次へ) を選択してからステップのパラメータを設定します。
1. [**Next**] (次へ) を選択してからステップの詳細を見直します。
1. 「**ステップの作成**」を選択してステップを追加し、次に進みます。
1. 必要に応じて、ステップを追加し続けます。ワークフローの最大ステップ数は 8 です。
1. 必要なノミナルステップをすべて追加したら、**[例外ハンドラー — オプション]** セクションまでスクロールし、**[ステップを追加]** を選択します。
**注記**
リアルタイムで失敗を通知できるように、ワークフローが失敗したときに実行する例外ハンドラーとステップを設定することをお勧めします。
1. 例外ハンドラを設定するには、前述と同じ方法でステップを追加します。いずれかのステップでファイルに起因する例外が発生すると、例外ハンドラが 1 つずつ呼び出されます。
1. (オプション) **[タグ]** セクションまでスクロールダウンし、ワークフローのタグを追加します。
1. 設定を見直して [**Create workflow**] (ワークフローの作成) を選択します。
**重要**
ワークフローを作成した後は編集できないため、設定を注意深く確認してください。
## ワークフローの設定と実行
ワークフローを実行する前に、そのワークフローを Transfer Family サーバーに関連付ける必要があります。
**アップロードされたファイルに対してワークフローを実行するように Transfer Family を設定するには**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. 左側のナビゲーションペインで [**Servers**] (サーバー) を選択します。
+ ワークフローを既存のサーバーに追加するには、ワークフローで使用するサーバーを選択します。
+ または、新しいサーバーを作成して、そのサーバーにワークフローを追加します。詳細については、「[SFTP、FTPS、または FTP サーバーエンドポイントの設定](tf-server-endpoint.md)」を参照してください。
1. サーバーの詳細ページで下にスクロールして [**Additional details**] (その他の詳細) セクションで [**Edit**] (編集) を選択します。
**注記**
デフォルトでは、サーバーに関連付けられたワークフローはありません。[**Additional details**] (その他の詳細) セクションを使用して、選択したサーバーにワークフローを関連付けます。
1. 「**追加詳細の編集**」ページの「**管理ワークフロー**」セクションで、すべてのアップロードに対して実行するワークフローを選択します。
**注記**
ワークフローがまだない場合は、「**新しいワークフローを作成する**」を選択し、ワークフローを作成します。
1. 使用するワークフロー ID を選択します。
1. 実行ロールを選択します。これは、Transfer Family がワークフローのステップを実行するときに引き受ける役割です。詳細については、「[ワークフローの IAM ポリシー](workflow-execution-role.md)」を参照してください。**[保存]** を選択します。
![\[マネージドワークフロー画面。ワークフローと実行ロールの値が表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-addtoserver.png)
**注記**
ワークフローをサーバーに関連付けたくない場合は、関連付けを削除できます。詳細については、「[Transfer Family サーバーからワークフローを削除する](transfer-workflows.md#remove-workflow-association)」を参照してください。
「**ワークフローを実行する**」
ワークフローを実行するには、関連付けられたワークフローで設定した Transfer Family サーバーにファイルをアップロードします。
**注記**
サーバーからワークフローを削除し、新しいワークフローに置き換える場合、またはサーバー構成を更新する場合（ワークフローの実行ロールに影響する）、新しいワークフローを実行する前に約 10 分間待機する必要があります。Transfer Family サーバーはワークフローの詳細をキャッシュし、サーバーがキャッシュを更新するのに10分かかります。
さらに、アクティブな SFTP セッションからログアウトし、10 分間の待ち時間の後にログインし直すと、変更を確認できます。
**Example**
```
# Execute a workflow
> sftp bob@s-1234567890abcdef0.server.transfer.us-east-1.amazonaws.com
Connected to s-1234567890abcdef0.server.transfer.us-east-1.amazonaws.com.
sftp> put doc1.pdf
Uploading doc1.pdf to /amzn-s3-demo-bucket/home/users/bob/doc1.pdf
doc1.pdf 100% 5013KB 601.0KB/s 00:08
sftp> exit
>
```
ファイルがアップロードされると、定義されたアクションがファイルに対して実行されます。たとえば、ワークフローにコピーステップが含まれている場合、そのステップで定義した場所にファイルがコピーされます。Amazon CloudWatch Logs を使用して、実行されたステップとその実行ステータスを追跡することができます。
## ワークフロー詳細の表示
以前に作成したワークフローの詳細や、ワークフローの実行状況を見ることができます。これらの詳細を表示するには、 コンソールまたは AWS Command Line Interface () を使用できますAWS CLI。
------
#### [ Console ]
**ワークフロー詳細の表示**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. ナビゲーションペインで [**Workflows**] (ワークフロー) を選択します。
1. [**Workflows**] (ワークフロー) ページでワークフローを選択します。
ワークフローの詳細ページが開きます。
![\[Transfer Family ワークフローのワークフロー詳細画面。説明、ステップ、例外ハンドラー、および処理中の実行が表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-overview.png)
------
#### [ CLI ]
ワークフローの詳細を表示するには、次の例に示すように CLI で `describe-workflow` コマンドを使用します。ワークフロー ID `w-1234567890abcdef0` を独自の値に置き換えます。詳細については、「AWS CLI コマンドリファレンス」の「[describe-workflow](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/transfer/describe-workflow.html)」を参照してください。
```
# View Workflow details
> aws transfer describe-workflow --workflow-id w-1234567890abcdef0
{
"Workflow": {
"Arn": "arn:aws:transfer:us-east-1:111122223333:workflow/w-1234567890abcdef0",
"WorkflowId": "w-1234567890abcdef0",
"Name": "Copy file to shared_files",
"Steps": [
{
"Type": "COPY",
"CopyStepDetails": {
"Name": "Copy to shared",
"FileLocation": {
"S3FileLocation": {
"Bucket": "amzn-s3-demo-bucket",
"Key": "home/shared_files/"
}
}
}
}
],
"OnException": {}
}
}
```
------
ワークフローが AWS CloudFormation スタックの一部として作成された場合は、 CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を使用してワークフローを管理できます。
![\[スタックの一部であるワークフローのワークフロー詳細画面には AWS CloudFormation 、CloudFormation でこのワークフローを管理するメッセージが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-cloudformation-link.png)
# 事前定義されたステップを使用する
ワークフローを作成する場合、このトピックで説明した以下の定義済みステップのいずれかを追加することを選択できます。独自のカスタムファイル処理ステップを追加することもできます。詳細については、「[カスタムのファイル処理ステップを使用してください。](custom-step-details.md)」を参照してください。
**Topics**
+ [ファイルをコピーする](#copy-step-details)
+ [ファイルを復号化します。](#decrypt-step-details)
+ [タグファイル](#tag-step-details)
+ [ファイルを削除する](#delete-step-details)
+ [ワークフローの名前付き変数](#workflow-named-variables)
+ [タグ付けと削除のワークフローの例](#sourcefile-workflow)
## ファイルをコピーする
ファイルのコピーステップでは、アップロードされたファイルのコピーを新しい Amazon S3 ロケーションに作成します。現在、ファイルコピーステップは Amazon S3 でのみ使用できます。
次のコピーファイルステップでは、*amzn-s3-demo-destination-bucket *の `test`フォルダにファイルをコピーします。
ファイルのコピーステップがワークフローの最初のステップでない場合は、**[ファイルロケーション]** を指定できます。ファイルの場所を指定することで、前のステップで使用したファイルまたはアップロードされた元のファイルのいずれかをコピーできます。この機能を使用すると、ファイルのアーカイブや記録の保持のためにソースファイルをそのまま保持したまま、元のファイルの複数のコピーを作成できます。例については、[タグ付けと削除のワークフローの例](#sourcefile-workflow)を参照してください。
![\[ワークフロー画面 前のステップから作成されたファイルをコピーする... ボタンが選択されました。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-copy.png)
### バケットとキーの詳細を提供する
ファイルのコピーステップのバケット名とキーを指定する必要があります。キーには、パス名またはファイル名を指定できます。キーがパス名またはファイル名のどちらとして扱われるかは、キーの末尾にスラッシュ (`/`) を付けるかどうかで決まります。
最後の文字が「`/`」の場合、ファイルはフォルダにコピーされ、その名前は変わりません。最後の文字が英数字の場合、アップロードしたファイルの名前が path 値に変更されます。その名前のファイルがすでに存在する場合、動作は**[既存を上書き]** フィールドの設定によって異なります。
+ **[既存を上書き]** を選択した場合、既存のファイルは処理中のファイルに置き換えられます。
+ **[既存を上書き]** が選択されていない場合は何も起こらず、ワークフロー処理は停止します。
**ヒント**
同じファイルパスで同時書き込みを実行すると、ファイルの上書き時に予期しない動作が発生する可能性があります。
たとえば、キー値が `test/` であれば、アップロードされたファイルは `test` フォルダにコピーされます。キーの値が `test/today` で、「**Overwrite existing**」が選択されている場合、アップロードしたファイルはすべて `test` フォルダー内の `today` という名前のファイルにコピーされ、後続のファイルはそれぞれ前のファイルが上書きされます。
**注記**
Amazon S3 ではバケットとオブジェクトをサポートしており、階層はありません。しかし、オブジェクトキーの名前に接頭辞や区切り文字を使うことで、フォルダに似た方法で階層を暗示し、データを整理することができます。
### ファイルのコピーステップでは名前付き変数を使用します。
ファイルのコピーステップでは、変数を使用してファイルをユーザー固有のフォルダーに動的にコピーできます。現在、`${transfer:UserName}`または`${transfer:UploadDate}`を変数として使用して、ファイルをアップロードしている特定のユーザーの宛先に、または現在の日付に基づいてファイルをコピーできます。
次の例では、ユーザー`richard-roe`がファイルをアップロードすると、そのファイルは`amzn-s3-demo-destination-bucket/richard-roe/processed/`フォルダーにコピーされます。ユーザー`mary-major`がファイルをアップロードすると、そのファイルは`amzn-s3-demo-destination-bucket/mary-major/processed/`フォルダーにコピーされます。
![\[を使用してパラメータ化されたバケットとキーを示すコピーステップのパラメータ画面UserName。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-copy-dynamic.png)
同様に、`${transfer:UploadDate}`を変数として使って、現在の日付にちなんだ名前のコピー先にファイルをコピーすることができます。次の例では、コピー先を 2022 年 2 月 1 日の`${transfer:UploadDate}/processed`に設定すると、アップロードされたファイルは`amzn-s3-demo-destination-bucket/2022-02-01/processed/`フォルダーにコピーされます。
![\[を使用してパラメータ化されたバケットとキーを示すコピーステップのパラメータ画面UploadDate。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-copy-dynamic-date.png)
これらの変数は両方を組み合わせて使用することもできます。たとえば、送信**先キープレフィックス**を に設定して**folder/\$1\$1transfer:UserName\$1/\$1\$1transfer:UploadDate\$1/**、 などのネストされたフォルダを作成できます`folder/marymajor/2023-01-05/`。
### コピーステップの IAM 権限
コピーステップを成功させるには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-destination-bucket"
]
}, {
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
}
```
**注記**
`s3:ListBucket`権限は、**[既存を上書き]** を選択しない場合にのみ必要です。この権限は、バケットをチェックして、同じ名前のファイルがすでに存在するかどうかを確認します。**[既存を上書き]** を選択した場合、ワークフローはファイルを確認する必要はなく、書き込むだけで済みます。
Amazon S3 ファイルにタグがある場合は、IAM ポリシーに 1 つまたは 2 つのアクセス許可を追加する必要があります。
バージョン管理されていない Amazon S3 ファイルに`s3:GetObjectTagging`を追加します。
バージョン管理されている Amazon S3 ファイルに`s3:GetObjectVersionTagging`を追加します。
## ファイルを復号化します。
AWS ストレージブログには、Transfer Family Managed ワークフロー、[PGP および を使用したファイルの暗号化と復号化を使用してコードを記述せずにファイルを単純に復号 AWS Transfer Family](https://aws.amazon.com/blogs/storage/encrypt-and-decrypt-files-with-pgp-and-aws-transfer-family/)する方法を説明する投稿があります。
### サポートされている対称暗号化アルゴリズム
PGP 復号の場合、Transfer Family は PGP ファイル内の実際のファイルデータを暗号化するために使用される対称暗号化アルゴリズムをサポートしています。
+ サポートされている対称暗号化アルゴリズムの詳細については、「」を参照してください[PGP 対称暗号化アルゴリズム](key-management.md#pgp-symmetric-algorithms)。
+ これらの対称アルゴリズムで使用される PGP キーペアアルゴリズムの詳細については、「」を参照してください[PGP キーペアアルゴリズム](key-management.md#pgp-key-algorithms)。
### PGP 復号化をワークフローで使用してください。
Transfer Family には完璧なプライバシー (PGP) 復号のサポートが組み込まれています。SFTP、FTPS、またはFTP経由でAmazon Simple Storage Service（Amazon S3）またはAmazon Elastic File System（Amazon EFS）にアップロードされたファイルでPGP復号を使用できます。
PGP 復号化を使用するには、ファイルの復号に使用する PGP プライベートキーを作成して保存する必要があります。ユーザーは、Transfer Familyサーバーにファイルをアップロードする前に、対応するPGP暗号鍵を使用してファイルを暗号化することができます。暗号化されたファイルを受信したら、ワークフローでそれらのファイルを復号化できます。詳細なチュートリアルについては、「[ファイルを復号するためのマネージドワークフローの設定](workflow-decrypt-tutorial.md)」を参照してください。
サポートされている PGP アルゴリズムと推奨事項については、「」を参照してください[PGP 暗号化および復号アルゴリズム](key-management.md#pgp-encryption-algorithms)。
**PGP 復号化をワークフローで使用するには**
1. ワークフローをホストする Transfer Family サーバーを特定するか、新しいサーバーを作成します。PGP キーを正しいシークレット名で AWS Secrets Manager に保存する前に、サーバ ID が必要です。
1. PGP キーを必要なシークレット名 AWS Secrets Manager で に保存します。詳細については、「[キーペアを管理する](manage-pgp-keys.md)」を参照してください。ワークフローは、Secrets Manager のシークレット名に基づいて、復号に使用する正しいPGPキーを自動的に見つけることができます。
**注記**
Secrets Manager にシークレットを保存すると、 AWS アカウント に料金が発生します。料金については、「[AWS Secrets Manager 料金](https://aws.amazon.com/secrets-manager/pricing)」を参照してください。
1. PGP キーペアを使用してファイルを暗号化します。（対応クライアントのリストは [サポートされている PGP クライアント](pgp-key-clients.md) を参照のこと）。コマンドラインを使用している場合は、以下のコマンドを実行します。このコマンドを使用するには、`username@example.com`をPGPキー・ペアの作成に使用した電子メール・アドレスに置き換えます。`testfile.txt` を暗号化したいファイル名に置き換えます。
```
gpg -e -r username@example.com testfile.txt
```
**重要**
AWS Transfer Family ワークフローで使用するファイルを暗号化する場合は、必ず `-r`パラメータを使用して非匿名受信者を指定してください。匿名暗号化 (受信者を指定しない) では、システムが復号に使用するキーを特定できないため、ワークフローで復号化が失敗する可能性があります。この問題のデバッグ情報は、「」で入手できます[匿名受信者の暗号化問題のトラブルシューティング](workflow-issues.md#workflows-decrypt-anonymous)。
1. 暗号化されたファイルを Transfer Family サーバーにアップロードします。
1. ワークフローで復号化ステップを設定します。詳細については、「[復号ステップを追加する](#decrypt-step-procedure)」を参照してください。
### 復号ステップを追加する
復号化ステップでは、ワークフローの一部として Amazon S3 または Amazon EFS にアップロードされた暗号化されたファイルを復号化します。復号化の設定の詳細については、[PGP 復号化をワークフローで使用してください。](#configure-decryption) を参照してください。
ワークフローの復号化ステップを作成するときは、復号化されたファイルの保存先を指定する必要があります。また、宛先にファイルがすでに存在する場合、既存のファイルを上書きするかどうかも選択する必要があります。Amazon CloudWatch Logs を使用すると、復号ワークフローの結果をモニタリングし、各ファイルの監査ログをリアルタイムで取得できます。
ステップの **[Decrypt ファイル]** タイプを選択すると、**[パラメータの設定]** ページが表示されます。「**PGP 復号化パラメーターの設定**」セクションに値を入力します。
利用可能なオプションは以下の通りである：
+ **ステップ名** — ステップの説明的な名前を入力します。
+ **ファイルロケーション** — ファイルの場所を指定することで、前のステップで使用したファイルまたはアップロードされた元のファイルのいずれかを復号できます。
**注記**
このパラメータは、このステップがワークフローの最初のステップである場合は使用できません。
+ **復号されたファイルの宛先** — 復号されたファイルの宛先として Amazon S3 バケットまたは Amazon EFS ファイルシステムを選択します。
+ Amazon S3 を選択した場合、宛先バケット名と宛先キープレフィックスを指定する必要があります。宛先キープレフィックスをユーザー名でパラメータ化するには、「**宛先キープレフィックス**」に**\$1\$1transfer:UserName\$1**と入力します。同様に、アップロード日ごとに宛先キープレフィックスをパラメータ化するには、「**宛先キープレフィックス**」に**\$1\$1Transfer:UploadDate\$1**と入力します。
+ Amazon EFS を選択する場合は、デスティネーションファイルシステムとパスを指定する必要があります。
**注記**
ここで選択するストレージオプションは、このワークフローが関連する Transfer Family サーバが使用するストレージシステムと一致する必要があります。作成されていない場合は、このワークフローを実行しようとしたときにエラーが発生します。
+ **既存の上書き** — ファイルをアップロードし、同じファイル名のファイルが宛先にすでに存在する場合、動作はこのパラメーターの設定によって異なります。
+ **[既存を上書き]** を選択した場合、既存のファイルは処理中のファイルに置き換えられます。
+ **[既存を上書き]** が選択されていない場合は何も起こらず、ワークフロー処理は停止します。
**ヒント**
同じファイルパスで同時書き込みを実行すると、ファイルの上書き時に予期しない動作が発生する可能性があります。
次のスクリーンショットは、ファイルの復号化ステップで選択できるオプションの例を示しています。
![\[サンプル値を含む PGP 復号パラメータの設定セクションを示す AWS Transfer Family コンソール。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-decrypt-details.png)
### 復号化ステップの IAM 権限
復号化ステップを成功させるには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-destination-bucket"
]
}, {
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
}, {
"Sid": "Decrypt",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:aws/transfer/*"
}
```
**注記**
`s3:ListBucket`権限は、**[既存を上書き]** を選択しない場合にのみ必要です。この権限は、バケットをチェックして、同じ名前のファイルがすでに存在するかどうかを確認します。**[既存を上書き]** を選択した場合、ワークフローはファイルを確認する必要はなく、書き込むだけで済みます。
Amazon S3 ファイルにタグがある場合は、IAM ポリシーに 1 つまたは 2 つのアクセス許可を追加する必要があります。
バージョン管理されていない Amazon S3 ファイルに`s3:GetObjectTagging`を追加します。
バージョン管理されている Amazon S3 ファイルに`s3:GetObjectVersionTagging`を追加します。
## タグファイル
受信ファイルにタグを付けてさらに下流処理を行うには、タグステップを使用します。受信ファイルに割り当てるタグの値を入力します。現在、タグオペレーションは Transfer Family サーバーストレージに Amazon S3 を使用している場合にのみサポートされます。
次のタグステップ例では、`scan_outcome`と`clean`をそれぞれタグキーと値として割り当てます。
![\[タグ付けステップの詳細を示すワークフロー画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-tag.png)
タグステップを成功させるには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "Tag",
"Effect": "Allow",
"Action": [
"s3:PutObjectTagging",
"s3:PutObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
```
**注記**
ワークフローに、コピーまたは復号ステップの前に実行されるタグステップが含まれている場合は、IAM ポリシーに 1 つまたは 2 つのアクセス許可を追加する必要があります。
バージョン管理されていない Amazon S3 ファイルに`s3:GetObjectTagging`を追加します。
バージョン管理されている Amazon S3 ファイルに`s3:GetObjectVersionTagging`を追加します。
## ファイルを削除する
処理済みのファイルを前のワークフローステップから削除したり、最初にアップロードしたファイルを削除したりするには、ファイル削除ステップを使用します。
![\[削除ステップの詳細を示すワークフロー画面。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-delete.png)
削除ステップを正常に実行するには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "Delete",
"Effect": "Allow",
"Action": [
"s3:DeleteObjectVersion",
"s3:DeleteObject"
],
"Resource": "arn:aws:secretsmanager:region:account-ID:secret:aws/transfer/*"
}
```
## ワークフローの名前付き変数
コピーと復号化のステップでは、変数を使用してアクションを動的に実行できます。現在、 は次の名前付き変数 AWS Transfer Family をサポートしています。
+ `${transfer:UserName}`を使用して、ファイルをアップロードしているユーザーに基づいて、ファイルを宛先にコピーまたは復号します。
+ `${transfer:UploadDate}`を使用して、現在の日付に基づいて、ファイルを宛先にロケーションにコピーまたは復号します。
## タグ付けと削除のワークフローの例
次の例は、データ分析プラットフォームなどのダウンストリームアプリケーションで処理する必要がある受信ファイルにタグを付けるワークフローを示しています。受信ファイルにタグを付けた後、ワークフローはストレージコストを節約するために最初にアップロードされたファイルを削除します。
------
#### [ Console ]
**例:タグ付けして移動するワークフロー**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. ナビゲーションペインで [**Workflows**] (ワークフロー) を選択します。
1. [**Workflows**] (ワークフロー) ページで [**Create workflow**] (ワークフローの作成) を選択します。
1. 「**ワークフローの作成**」ページで、説明を入力します。この説明は [**Workflows**] (ワークフロー) ページに表示されます。
1. 最初のステップ (コピー) を追加します。
1. **[ノミナルステップ]** セクションで **[ステップを追加]** を選択します。
1. 「**ファイルのコピー**」を選択し、「**次へ**」を選択します。
1. ステップ名を入力し、宛先バケットとkey prefix スを選択します。
![\[コピーステップの詳細を示すワークフロー画面。コピー先のバケットとキープレフィックスが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-copy-first-step.png)
1. [**Next**] (次へ) を選択してからステップの詳細を見直します。
1. 「**ステップの作成**」を選択してステップを追加し、次に進みます。
1. 2 番目のステップ (タグ) を追加します。
1. **[ノミナルステップ]** セクションで **[ステップを追加]** を選択します。
1. 「**ファイルのタグ付け**」を選択し、「**次へ**」を選択します。
1. ステップ名を入力します。
1. **[ファイルロケーション]** で、**[前の手順で作成したファイルにタグを付ける]** を選択します。
1. **[キー]** と **[値]** を入力します。
![\[タグ付けワークフローステップの設定画面。前のステップで作成したファイルのタグ付けラジオボタンが選択されています。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-tag.png)
1. [**Next**] (次へ) を選択してからステップの詳細を見直します。
1. 「**ステップの作成**」を選択してステップを追加し、次に進みます。
1. 3 番目のステップ (削除) を追加します。
1. **[ノミナルステップ]** セクションで **[ステップを追加]** を選択します。
1. 「**ファイルの削除**」を選択し、「**次へ**」を選択します。
![\[削除ワークフローステップの設定画面。元のソースファイルの削除ラジオボタンが選択されています。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-delete.png)
1. ステップ名を入力します。
1. **[ファイルロケーション]** で **[元のソースファイルを削除]** を選択します。
1. [**Next**] (次へ) を選択してからステップの詳細を見直します。
1. 「**ステップの作成**」を選択してステップを追加し、次に進みます。
1. ワークフロー設定を確認し、し、「**ワークフローの作成**」を選択します。
------
#### [ CLI ]
**例:タグ付けして移動するワークフロー**
1. 以下のコードをファイルに保存します；例えば、`tagAndMoveWorkflow.json`。`user input placeholder` を、ユーザー自身の情報に置き換えます。
```
[
{
"Type": "COPY",
"CopyStepDetails": {
"Name": "CopyStep",
"DestinationFileLocation": {
"S3FileLocation": {
"Bucket": "amzn-s3-demo-bucket",
"Key": "test/"
}
}
}
},
{
"Type": "TAG",
"TagStepDetails": {
"Name": "TagStep",
"Tags": [
{
"Key": "name",
"Value": "demo"
}
],
"SourceFileLocation": "${previous.file}"
}
},
{
"Type": "DELETE",
"DeleteStepDetails":{
"Name":"DeleteStep",
"SourceFileLocation": "${original.file}"
}
}
]
```
最初のステップでは、アップロードしたファイルを新しい Amazon S3 ロケーションにコピーします。2 番目のステップでは、新しいロケーションにコピーされたファイル (`previous.file`) にタグ (キーと値のペア) を追加します。最後に、3 番目のステップで元のファイル (`original.file`) を削除します。
1. 保存したファイルからワークフローを作成します。`user input placeholder` を、ユーザー自身の情報に置き換えます。
```
aws transfer create-workflow --description "short-description" --steps file://path-to-file --region region-ID
```
例えば、次のようになります。
```
aws transfer create-workflow --description "copy-tag-delete workflow" --steps file://tagAndMoveWorkflow.json --region us-east-1
```
**注記**
ファイルを使用してパラメータを読み込む方法について詳しくは、「[ファイルからパラメータをロードする方法](https://docs.aws.amazon.com//cli/latest/userguide/cli-usage-parameters-file.html)」を参照してください。
1. 既存のサーバーを更新します。
**注記**
この手順では、すでに Transfer Family サーバーがあり、それにワークフローを関連付けることを前提としています。そうでない場合は、「[SFTP、FTPS、または FTP サーバーエンドポイントの設定](tf-server-endpoint.md)」を参照してください。`user input placeholder` を、ユーザー自身の情報に置き換えます。
```
aws transfer update-server --server-id server-ID --region region-ID
--workflow-details '{"OnUpload":[{ "WorkflowId": "workflow-ID","ExecutionRole": "execution-role-ARN"}]}'
```
例えば、次のようになります。
```
aws transfer update-server --server-id s-1234567890abcdef0 --region us-east-2
--workflow-details '{"OnUpload":[{ "WorkflowId": "w-abcdef01234567890","ExecutionRole": "arn:aws:iam::111111111111:role/nikki-wolf-execution-role"}]}'
```
------
# カスタムのファイル処理ステップを使用してください。
カスタムファイル処理ステップを使用することで、 AWS Lambdaを使用して独自のファイル処理ロジックを実現できます。ファイルが到着すると、Transfer Family サーバーは、ファイルの暗号化、マルウェアのスキャン、不正なファイルタイプのチェックなど、カスタムファイル処理ロジックを含む Lambda 関数を呼び出します。次の例では、ターゲット AWS Lambda 関数が前のステップの出力ファイルを処理するのに使われています。
![\[カスタムステップ画面。前のステップから作成されたファイルにカスタム処理を適用ラジオボタンが選択され、Lambda 関数がターゲットフィールドに表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-custom.png)
**注記**
サンプルの Lambda 関数については、「[カスタムワークフローステップの Lambda 関数の例](#example-workflow-lambda)」を参照してください。イベント (Lambda に渡されるファイルの場所を含む) の例については、[ファイルのアップロード AWS Lambda 時に に送信されるイベントの例](#example-workflow-lambdas)を参照してください。
カスタムワークフローステップでは、「[SendWorkflowStepState](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html)」API オペレーションを呼び出すように Lambda 関数を構成する必要があります。`SendWorkflowStepState` は、ステップの完了を成功か失敗のどちらかのステータスでワークフロー実行に通知します。`SendWorkflowStepState`API オペレーションのステータスにより、Lambda 関数の結果に基づいて、例外ハンドラーステップまたは線形シーケンスのノミナルステップが呼び出されます。
Lambda 関数が失敗するかタイムアウトになると、ステップが失敗し、CloudWatch Logs `StepErrored` が表示されます。Lambda 関数がノミナルステップの一部であり、その関数が`SendWorkflowStepState`に`Status="FAILURE"`で応答するかタイムアウトした場合、フローは例外ハンドラステップに進みます。この場合、ワークフローは残りの (もしあれば) 名目上のステップを実行し続けません。詳細については、[ワークフローの例外処理](transfer-workflows.md#exception-workflow)を参照してください。
`SendWorkflowStepState` API オペレーションを呼び出す際には、以下のパラメーターを送信する必要があります。
```
{
"ExecutionId": "string",
"Status": "string",
"Token": "string",
"WorkflowId": "string"
}
```
Lambda 関数実行時に渡される入力イベントから、`ExecutionId`、`Token`、`WorkflowId` を抽出することができます（以下のセクションに例を示す）。`Status` 値は `SUCCESS` または `FAILURE` のいずれかです。
Lambda 関数から `SendWorkflowStepState` API オペレーションを呼び出すには、[マネージドワークフローの導入](doc-history.md#workflows-introduced)後に発行されたバージョンの AWS SDK を使用する必要があります。
## 複数の Lambda 関数を続けて使用する
複数のカスタムステップを次々に使用する場合、**[ファイルロケーション]** オプションは 1 つのカスタムステップのみを使用する場合とは動作が異なります。Transfer Family は、Lambda で処理されたファイルを戻して次のステップの入力として使用することをサポートしていません。そのため、`previous.file`オプションを使用するように構成された複数のカスタム・ステップがある場合、それらはすべて同じファイルの場所（最初のカスタム・ステップの入力ファイルの場所）を使用します。
**注記**
カスタムステップの後に定義済みのステップ (タグ付け、コピー、復号化、または削除) がある場合も、`previous.file`設定の動作は異なります。定義済みステップが`previous.file`設定を使用するように構成されている場合、定義済みステップはカスタム・ステップで使用されるのと同じ入力ファイルを使用します。カスタムステップで処理されたファイルは、定義済みのステップには渡されません。
## カスタム処理後のファイルへのアクセス
Amazon S3 をストレージとして使用していて、ワークフローに最初にアップロードされたファイルに対してアクションを実行するカスタムステップが含まれている場合、以降のステップでは処理されたファイルにアクセスできません。つまり、カスタムステップの後のどのステップも、カスタムステップの出力から更新されたファイルを参照することはできません。
例えば、ワークフローに次の 3 つがあるとします。
+ **ステップ 1** — `example-file.txt` という名前のファイルをアップロードします。
+ **ステップ 2** — `example-file.txt`を何らかの方法で変更する Lambda 関数を呼び出します。
+ **ステップ 3** — 更新されたバージョンの`example-file.txt`に対して、さらなる処理を試みます。
ステップ 3 の`sourceFileLocation`を`${original.file}`として設定した場合、ステップ 3 では、でサーバがステップ 1 ファイルをストレージにアップロードしたときの元のファイルロケーションが使用されます。ステップ 3 で`${previous.file}`を使用している場合、ステップ 3 はステップ 2 が入力として使用したファイルの場所を再利用します。
そのため、ステップ 3 ではエラーが発生します。例えば、ステップ 3 で更新された`example-file.txt`をコピーしようとすると、以下のエラーが発生します。
```
{
"type": "StepErrored",
"details": {
"errorType": "NOT_FOUND",
"errorMessage": "ETag constraint not met (Service: null; Status Code: 412; Error Code: null; Request ID: null; S3 Extended Request ID: null; Proxy: null)",
"stepType": "COPY",
"stepName": "CopyFile"
},
```
このエラーは、カスタム・ステップで`example-file.txt`用のエンティティ・タグ （ETag） が変更され、元のファイルと一致しなくなるために発生します。
**注記**
Amazon EFS ではファイルの識別にエンティティタグを使用しないため、Amazon EFS を使用している場合はこの動作は発生しません。
## ファイルのアップロード AWS Lambda 時に に送信されるイベントの例
次の例は、ファイルのアップロードが完了した AWS Lambda ときに に送信されるイベントを示しています。ある例では、ドメインが Amazon S3 で構成されている Transfer Family サーバーを使用しています。もう 1 つは Transfer Family サーバーでドメインで Amazon EFS を使用する例です。
------
#### [ Custom step that uses an Amazon S3 domain ]
```
{
"token": "MzI0Nzc4ZDktMGRmMi00MjFhLTgxMjUtYWZmZmRmODNkYjc0",
"serviceMetadata": {
"executionDetails": {
"workflowId": "w-1234567890example",
"executionId": "abcd1234-aa11-bb22-cc33-abcdef123456"
},
"transferDetails": {
"sessionId": "36688ff5d2deda8c",
"userName": "myuser",
"serverId": "s-example1234567890"
}
},
"fileLocation": {
"domain": "S3",
"bucket": "amzn-s3-demo-bucket",
"key": "path/to/mykey",
"eTag": "d8e8fca2dc0f896fd7cb4cb0031ba249",
"versionId": null
}
}
```
------
#### [ Custom step that uses an Amazon EFS domain ]
```
{
"token": "MTg0N2Y3N2UtNWI5Ny00ZmZlLTk5YTgtZTU3YzViYjllNmZm",
"serviceMetadata": {
"executionDetails": {
"workflowId": "w-1234567890example",
"executionId": "abcd1234-aa11-bb22-cc33-abcdef123456"
},
"transferDetails": {
"sessionId": "36688ff5d2deda8c",
"userName": "myuser",
"serverId": "s-example1234567890"
}
},
"fileLocation": {
"domain": "EFS",
"fileSystemId": "fs-1234567",
"path": "/path/to/myfile"
}
}
```
------
## カスタムワークフローステップの Lambda 関数の例
以下の Lambda 関数は、実行ステータスに関する情報を抽出し、「[SendWorkflowStepState](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html)」API オペレーションを呼び出して、ステップ（`SUCCESS` または `FAILURE`）のステータスをワークフローに返します。関数が`SendWorkflowStepState` API オペレーションを呼び出す前に、ワークフローロジックに基づいたアクションを取るように Lambda を設定できます。
```
import json
import boto3
transfer = boto3.client('transfer')
def lambda_handler(event, context):
print(json.dumps(event))
# call the SendWorkflowStepState API to notify the workflow about the step's SUCCESS or FAILURE status
response = transfer.send_workflow_step_state(
WorkflowId=event['serviceMetadata']['executionDetails']['workflowId'],
ExecutionId=event['serviceMetadata']['executionDetails']['executionId'],
Token=event['token'],
Status='SUCCESS|FAILURE'
)
print(json.dumps(response))
return {
'statusCode': 200,
'body': json.dumps(response)
}
```
## カスタムステップの IAM 権限
Lambda を呼び出すステップを成功させるには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "Custom",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:region:account-id:function:function-name"
]
}
```
# ワークフローの IAM ポリシー
ワークフローをサーバーに追加する際、実行ロールを選択する必要があります。サーバーは、ワークフローの実行時にこのロールを使用します。ロールに適切なアクセス許可がない場合は、ワークフローを実行 AWS Transfer Family できません。
このセクションでは、ワークフローの実行に使用できる AWS Identity and Access Management (IAM) アクセス許可の 1 つのセットについて説明します。このトピックの後半で、他の例を紹介しています。
**注記**
Amazon S3 ファイルにタグがある場合は、IAM ポリシーに 1 つまたは 2 つのアクセス許可を追加する必要があります。
バージョン管理されていない Amazon S3 ファイルに`s3:GetObjectTagging`を追加します。
バージョン管理されている Amazon S3 ファイルに`s3:GetObjectVersionTagging`を追加します。
**ワークフローの実行ロールを作成するには**
1. 新しい IAM ロールを作成し、 AWS 管理ポリシー`AWSTransferFullAccess`をロールに追加します。新しい IAM ロールの作成についての詳細は、[IAM ポリシーとロールを作成する](requirements-roles.md) を参照してください。
1. 次のアクセス許可を持つポリシーを作成してロールにアタッチします。`user input placeholder` を、ユーザー自身の情報に置き換えます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ConsoleAccess",
"Effect": "Allow",
"Action": "s3:GetBucketLocation",
"Resource": "*"
},
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Sid": "GetObjectVersion",
"Effect": "Allow",
"Action": "s3:GetObjectVersion",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Sid": "Custom",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:us-east-1:123456789012:function:function-name"
]
},
{
"Sid": "Tag",
"Effect": "Allow",
"Action": [
"s3:PutObjectTagging",
"s3:PutObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
1. このロールを保存し、ワークフローをサーバーに追加する際に実行ロールとして指定します。
**注記**
IAM ロールを構築する場合、 では、ワークフローで可能な限りリソースへのアクセスを制限する AWS ことをお勧めします。
## ワークフローの信頼関係
ワークフロー実行ロールには、`transfer.amazonaws.com`との信頼関係も必要です。 AWS Transfer Familyとの信頼関係を築くには、[信頼関係を確立するには](requirements-roles.md#establish-trust-transfer) を参照してください。
信頼関係を築いている間は、「混乱した代理人」問題を避けるための対策を講じることもできます。この問題の説明と回避方法の例については、[サービス間の混乱した代理の防止](confused-deputy.md)を参照してください。
## 実行ロールの例:復号化、コピー、タグ付け
タグ付け、コピー、復号化のステップを含むワークフローがある場合は、次の IAM ポリシーを使用できます。`user input placeholder` を、ユーザー自身の情報に置き換えます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CopyRead",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging",
"s3:GetObjectVersionTagging"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-source-bucket/*"
},
{
"Sid": "CopyWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
},
{
"Sid": "CopyList",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-source-bucket",
"arn:aws:s3:::amzn-s3-demo-destination-bucket"
]
},
{
"Sid": "Tag",
"Effect": "Allow",
"Action": [
"s3:PutObjectTagging",
"s3:PutObjectVersionTagging"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*",
"Condition": {
"StringEquals": {
"s3:RequestObjectTag/Archive": "yes"
}
}
},
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-destination-bucket"
]
},
{
"Sid": "HomeDirObjectAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/*"
},
{
"Sid": "Decrypt",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:aws/transfer/*"
}
]
}
```
## 実行ロールの例:関数の実行と削除
この例では、 AWS Lambda 関数を呼び出すワークフローがあります。ワークフローがアップロードされたファイルを削除し、前のステップで失敗したワークフロー実行を処理する例外ハンドラーステップがある場合は、次の IAM ポリシーを使用してください。`user input placeholder` を、ユーザー自身の情報に置き換えます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Delete",
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::bucket-name"
},
{
"Sid": "Custom",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:us-east-1:123456789012:function:function-name"
]
}
]
}
```
## ワークフローの例外処理
ワークフローの実行中にエラーが発生した場合、指定した例外処理ステップが実行されます。ワークフローのエラー処理手順は、ワークフローの指名手順を指定するのと同じ方法で指定します。たとえば、受信ファイルを検証するためのカスタム処理をわずかな手順で設定したとします。ファイルの検証に失敗した場合、例外処理ステップで管理者にメールを送信できます。
以下のワークフロー例には、2 つのステップが含まれている：
+ アップロードされたファイルが CSV 形式かどうかをチェックする、ごく普通のステップの 1 つです。
+ アップロードされたファイルが CSV 形式でない場合に電子メールを送信する例外処理ステップで、通常のステップは失敗します。
例外処理ステップを開始するには、公称ステップの AWS Lambda 関数が で応答する必要があります`Status="FAILURE"`。ワークフローにおけるエラー処理の詳細については、[カスタムのファイル処理ステップを使用してください。](custom-step-details.md) を参照してください。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflow-exception-sample.png)
# ワークフロー実行のモニタリング
Amazon CloudWatch は、 AWS クラウド で実行している AWS リソースとアプリケーションをリアルタイムでモニタリングします。Amazon CloudWatch を使って、ワークフローを測定できる変数であるメトリクスを収集し、追跡できます。Amazon CloudWatch を使用してワークフローメトリックスと統合ログを表示できます。
## ワークフローの CloudWatch ログ記録
CloudWatch は、ワークフローの進行状況と結果に関する統合監査とログ記録を提供します。
**ワークフローの Amazon CloudWatch Logs を表示する**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で Amazon CloudWatch コンソールを開きます。
1. 左側のナビゲーションペインで、「**ログ**」を選択し、「**ロググループ**」を選択します。
1. **ロググループ**ページのナビゲーションバーで、 AWS Transfer Family サーバーに適したリージョンを選択します。
1. サーバーに対応するロググループを選択します。
例えば、サーバー ID が `s-1234567890abcdef0` であれば、ロググループは `/aws/transfer/s-1234567890abcdef0` です。
1. サーバーのロググループの詳細ページに、最新のログストリームが表示されます。調査対象のユーザーには 2 つのログストリームがあります。
+ Secure Shell (SSH) File Transfer Protocol (SFTP) セッションごとに 1 つずつ。
+ 1 つはサーバーで実行中のワークフロー用です。ワークフローのログストリームの形式は `username.workflowID.uniqueStreamSuffix` です。
例えば、ユーザーが `mary-major` である場合、以下のようなログストリームがある：
```
mary-major-east.1234567890abcdef0
mary.w-abcdef01234567890.021345abcdef6789
```
**注記**
この例に挙げた 16 桁の英数字の識別子は架空のものです。Amazon CloudWatch に表示される値は異なります。
`mary-major-usa-east.1234567890abcdef0`の **[ログイベント]** ページには各ユーザーセッションの詳細が表示され、`mary.w-abcdef01234567890.021345abcdef6789`ログストリームにはワークフローの詳細が含まれます。
以下は、コピーステップを含むワークフロー（`w-abcdef01234567890`）に基づく、`mary.w-abcdef01234567890.021345abcdef6789` のログストリームのサンプルです。
```
{
"type": "ExecutionStarted",
"details": {
"input": {
"initialFileLocation": {
"bucket": "amzn-s3-demo-bucket",
"key": "mary/workflowSteps2.json",
"versionId": "version-id",
"etag": "etag-id"
}
}
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails": {
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"StepStarted",
"details": {
"input": {
"fileLocation": {
"backingStore":"S3",
"bucket":"amzn-s3-demo-bucket",
"key":"mary/workflowSteps2.json",
"versionId":"version-id",
"etag":"etag-id"
}
},
"stepType":"COPY",
"stepName":"copyToShared"
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails": {
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"StepCompleted",
"details":{
"output":{},
"stepType":"COPY",
"stepName":"copyToShared"
},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails":{
"serverId":"server-id",
"username":"mary",
"sessionId":"session-id"
}
},
{
"type":"ExecutionCompleted",
"details": {},
"workflowId":"w-abcdef01234567890",
"executionId":"execution-id",
"transferDetails":{
"serverId":"s-server-id",
"username":"mary",
"sessionId":"session-id"
}
}
```
## ワークフローの CloudWatch メトリクス
AWS Transfer Family には、ワークフローの複数のメトリクスが用意されています。過去 1 分間に開始された、正常に完了した、失敗したワークフロー実行の数を示す指標を表示できます。Transfer Family の CloudWatch メトリクスについては、[Transfer Family サーバーの CloudWatch メトリクスの使用](metrics.md)で説明しています。
# テンプレートからワークフローを作成する
テンプレートからワークフローとサーバーを作成する CloudFormation スタックをデプロイできます。この手順には、ワークフローをすばやくデプロイするために使用できる例が含まれています。
**AWS Transfer Family ワークフローとサーバーを作成する CloudFormation スタックを作成するには**
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. 以下のコードをファイルに保存します。
------
#### [ YAML ]
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
SFTPServer:
Type: 'AWS::Transfer::Server'
Properties:
WorkflowDetails:
OnUpload:
- ExecutionRole: workflow-execution-role-arn
WorkflowId: !GetAtt
- TransferWorkflow
- WorkflowId
TransferWorkflow:
Type: AWS::Transfer::Workflow
Properties:
Description: Transfer Family Workflows Blog
Steps:
- Type: COPY
CopyStepDetails:
Name: copyToUserKey
DestinationFileLocation:
S3FileLocation:
Bucket: archived-records
Key: ${transfer:UserName}/
OverwriteExisting: 'TRUE'
- Type: TAG
TagStepDetails:
Name: tagFileForArchive
Tags:
- Key: Archive
Value: yes
- Type: CUSTOM
CustomStepDetails:
Name: transferExtract
Target: arn:aws:lambda:region:account-id:function:function-name
TimeoutSeconds: 60
- Type: DELETE
DeleteStepDetails:
Name: DeleteInputFile
SourceFileLocation: '${original.file}'
Tags:
- Key: Name
Value: TransferFamilyWorkflows
```
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Resources": {
"SFTPServer": {
"Type": "AWS::Transfer::Server",
"Properties": {
"WorkflowDetails": {
"OnUpload": [
{
"ExecutionRole": "workflow-execution-role-arn",
"WorkflowId": {
"Fn::GetAtt": [
"TransferWorkflow",
"WorkflowId"
]
}
}
]
}
}
},
"TransferWorkflow": {
"Type": "AWS::Transfer::Workflow",
"Properties": {
"Description": "Transfer Family Workflows Blog",
"Steps": [
{
"Type": "COPY",
"CopyStepDetails": {
"Name": "copyToUserKey",
"DestinationFileLocation": {
"S3FileLocation": {
"Bucket": "archived-records",
"Key": "${transfer:UserName}/"
}
},
"OverwriteExisting": "TRUE"
}
},
{
"Type": "TAG",
"TagStepDetails": {
"Name": "tagFileForArchive",
"Tags": [
{
"Key": "Archive",
"Value": "yes"
}
]
}
},
{
"Type": "CUSTOM",
"CustomStepDetails": {
"Name": "transferExtract",
"Target": "arn:aws:lambda:region:account-id:function:function-name",
"TimeoutSeconds": 60
}
},
{
"Type": "DELETE",
"DeleteStepDetails": {
"Name": "DeleteInputFile",
"SourceFileLocation": "${original.file}"
}
}
],
"Tags": [
{
"Key": "Name",
"Value": "TransferFamilyWorkflows"
}
]
}
}
}
}
```
------
1. 次の項目を実際の値に置き換えます。
+ *`workflow-execution-role-arn`* を実際のワークフロー実行ロールの ARN に置き換えます。例: `arn:aws:transfer:us-east-2:111122223333:workflow/w-1234567890abcdef0`
+ `arn:aws:lambda:region:account-id:function:function-name` を Lambda 関数の ARN に置き換えます。例えば、`arn:aws:lambda:us-east-2:123456789012:function:example-lambda-idp`。
1. *AWS CloudFormation 「 ユーザーガイド*」の CloudFormation 「スタックテンプレート[の選択」の「既存のテンプレートからスタックを](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html)デプロイする手順」に従います。
スタックがデプロイされた後、CloudFormation コンソールの「**Outputs**」タブでその詳細を見ることができます。テンプレートは、サービスマネージドユーザーを使用する新しい AWS Transfer Family SFTP サーバーと新しいワークフローを作成し、ワークフローを新しいサーバーに関連付けます。
## Transfer Family サーバーからワークフローを削除する
ワークフローを Transfer Family サーバーに関連付けていて、その関連付けを削除したい場合は、コンソールを使用するか、プログラムを使用して削除できます。
------
#### [ Console ]
**Transfer Family サーバーからワークフローを削除するには**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. 左側のナビゲーションペインで [**Servers**] (サーバー) を選択します。
1. 「**サーバー ID**」欄でサーバーの識別子を選択します。
1. サーバーの詳細ページで下にスクロールして [**Additional details**] (その他の詳細) セクションで [**Edit**] (編集) を選択します。
1. 「**追加情報の編集**」ページの「**管理されたワークフロー**」セクションで、すべての設定の情報をクリアします。
+ ワークフローのリストから **[ファイルアップロードを完了するワークフロー]** のダッシュ（-）を選択します。
+ まだクリアされていない場合は、**[部分ファイルアップロード用ワークフロー]** のワークフローリストからダッシュ（-）を選択します。
+ **[マネージドワークフロー実行ロール]** のロールのリストからダッシュ (-) を選択します。
ダッシュが表示されていない場合は、表示されるまで上にスクロールしてください。ダッシュは各メニューの最初の値です。
画面は以下のようになるはずです。
![\[マネージドワークフローペイン。すべてのパラメータがクリアされています。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-remove-from-server.png)
1. 下にスクロールし、「**保存**」を選択して変更を保存します。
------
#### [ CLI ]
`update-server`(または API の`UpdateServer`) 呼び出しを使用し、`OnUpload`および`OnPartialUpload`パラメータには空の引数を指定します。
から AWS CLI、次のコマンドを実行します。
```
aws transfer update-server --server-id your-server-id --workflow-details '{"OnPartialUpload":[],"OnUpload":[]}'
```
`your-server-id`をサーバーの ID に置き換えます。例えば、サーバー ID が`s-01234567890abcdef`の場合、コマンドは次のようになります。
```
aws transfer update-server --server-id s-01234567890abcdef --workflow-details '{"OnPartialUpload":[],"OnUpload":[]}'
```
------
## マネージドワークフローの制限事項と機能制限
**制限事項**
現時点では AWS Transfer Familyのアップロード後処理ワークフローに以下の制限事項が適用されます。
+ クロスアカウント関数とクロスリージョン AWS Lambda 関数はサポートされていません。ただし、 AWS Identity and Access Management (IAM) ポリシーが正しく設定されていれば、アカウント間でコピーできます。
+ すべてのワークフローステップで、ワークフローがアクセスする Amazon S3 バケットは、ワークフロー自体と同じリージョンにある必要があります。
+ 復号ステップでは、復号先がリージョンとバッキングストアのソースと一致する必要があります (例えば、復号するファイルが Amazon S3 に保存されている場合、指定された宛先も Amazon S3 にある必要がある)。
+ 非同期カスタムステップのみがサポートされます。
+ カスタムステップタイムアウトは概算です。つまり、指定された時間よりも若干タイムアウトに時間がかかる可能性があります。さらに、ワークフローは Lambda 関数に依存します。したがって、実行中に関数が遅延した場合、ワークフローは遅延を認識しません。
+ スロットリング制限を超えた場合、Transfer Family はワークフローオペレーションをキューに追加しません。
+ ワークフローは、サイズが 0 のファイルに対しては開始されません。サイズが 0 より大きいファイルは、関連するワークフローを開始します。
+ AS2 プロトコルを使用する Transfer Family サーバーにファイル処理ワークフローをアタッチできますが、AS2 メッセージはサーバーにアタッチされたワークフローを実行しません。
**機能制限**
さらに、Transfer Family のワークフローには、次の機能制限が適用されます。
+ リージョンごと、アカウントごとのワークフロー数は 10 に制限されています。
+ カスタムステップの最大タイムアウト値は 30 分です。
+ ワークフローの最大ステップ数は 8 です。
+ ワークグループあたりのタグの最大数は 50 です。
+ 復号ステップを含む同時実行の最大数は、ワークフローあたり 250 です。
+ Transfer Family サーバー 1 台につき、1 ユーザーにつき最大 3 つの PGP 秘密鍵を保存できます。
+ 復号化されたファイルの最大サイズは 10 GB です。
+ 新しい実行速度は、バースト容量が 100 でリフィル率が 1 の「[トークンバケット](https://en.wikipedia.org/wiki/Token_bucket)」システムを使用して調整しています。
+ サーバーからワークフローを削除し、新しいワークフローに置き換える場合、またはサーバー構成を更新する場合（ワークフローの実行ロールに影響する）、新しいワークフローを実行する前に約 10 分間待機する必要があります。Transfer Family サーバーはワークフローの詳細をキャッシュし、サーバーがキャッシュを更新するのに10分かかります。
さらに、アクティブな SFTP セッションからログアウトし、10 分間の待ち時間の後にログインし直すと、変更を確認できます。