メインコンテンツへスキップ

AWS ノード

AWS ノードを使用すると、フローから直接 AWS のサービスと連携できます。データの取得、リソースの作成や変更、複数の AWS サービスにまたがるアクションの実行に使用します。あるノードの出力は次のノードの入力となるため、一連のアクションとオペレーションを定義できます。

アクションを探す​

フローに AWS ノードを追加する際は、プロバイダとして AWS を選択し、検索または AWS サービス内を参照してアクションを探してください。加えて、テンプレートノードを使用すると、あらかじめ構成されたアクションのグループを現在のフローに追加できます。

Search all a provider's services for an action

アクションを設定する​

アクションノードを選択すると、設定用の 3 つのタブを備えたサイドパネルが開きます。

Action configuration

  • Parameters：このタブには選択したサービスとアクション、およびそれらを変更するオプションが表示されます。このタブでは承認設定も行います。利用できるパラメータはサービスとアクションによって異なります。パラメータタイプや、前のノードから値（リスト全体やマップを含む）を参照する方法については、Parameter typesを参照してください。

  • Permissions：このタブでは、アクションを実行するために必要な権限を保持しているかを確認でき、権限が不足している場合の対処方法が表示されます。APIs in CloudFlowも参照してください。

承認を必須にする​

アクションの実行前に承認が必要な場合は、Permissions タブで Require approval for this action を選択してください。

Require approval for action

  • Notification provider：承認者への通知方法として Slack かメールのどちらを使用するかを指定します。Slack を使用する場合は、事前に DoiT との共有 Slack チャンネルを作成しておく必要があります。

  • Message（任意）：承認者向けのメッセージです。メッセージには前のノードのフィールドを追加できます。メッセージが作成されると、そのフィールドのデータがメッセージ内に表示されます。これにより、受信者はシステムに移動して手動で関連情報を検索することなく、意思決定に必要な詳細を確認できます。フィールドの配列はカンマ区切りのリストとして表示されます。例：Instance ID: i-123,i-466

  • Reject approval after certain time（任意）：アクションが承認を待機する最大時間を制限します。利用可能な時間単位は Hours・Days・Weeks・Months です。たとえば、承認者が 24 時間以内にアクションを承認または拒否する必要があるように設定できます。指定した時間内に承認者が何も行わない場合、そのアクションは自動的に拒否されます。

ウェイターを追加する​

ウェイターは、フローが次のステップに進む前に、フロー内の AWS アクションが完了していることを保証します。多くの AWS オペレーションは非同期で、API コールはリソースが最終状態に到達する前に戻ります。ウェイターはその状態に到達するまでポーリングを行うため、後続のノードで結果に依存できます。これは、リソースを作成または変更し、次のステップに進む前にそれらを利用可能な状態にする必要がある場合、例えば、ボリュームをアタッチしたり通知を送信したりする前に EC2 インスタンスが running 状態になるまで待機する場合に有用です。

アクションにウェイターが必要な場合は、Enable waiter を選択してください。ウェイターを有効にしたら、Waiter type を選択します。

  • Built-in：AWS サービスが提供する事前定義済みウェイターを使用します。Built-in ウェイターは多くの一般的なアクションで利用可能で、ポーリングロジックを自動的に処理します。選択したアクションに対応する Built-in ウェイターが存在しない場合、このオプションは利用できず、ウェイタータイプは自動的に Custom に設定されます。

  • Custom：JMESPath 式を使用して独自のポーリング条件を定義します。アクションに Built-in ウェイターが存在しない場合や、Built-in ウェイターではカバーされない特定の条件を待つ必要がある場合に使用します。Custom ウェイターは create アクションと generate アクションでは使用できません。これは、Custom ウェイターが、JMESPath 条件が満たされるまで各ポーリング時に同じアクションを再実行することで機能するためです。create・generate コールはべき等ではないため、繰り返し実行すると重複したリソースが作成されたり、その他の望ましくない副作用が発生したりする可能性があります。これらのオペレーションでは、アクションがサポートしている場合は Built-in ウェイターを使用するか、create・generate を一度だけ実行し、その後で Custom ウェイター付きの read または describe アクションを別に使用してください。

Built-in ウェイター​

Waiter for action

  • Wait until：このアクションに使用するウェイターを選択します。ドロップダウンには、現在の AWS サービスとアクションに適用可能なウェイターのみが表示されます（例：EC2 RunInstances に対する InstanceRunning）。

  • （任意）Parameters：ウェイターがどのリソースをポーリングするか（例：どの EC2 インスタンスか、どの S3 バケットか）を指定する必要があります。このセクションでその値を指定します。現在のアクションの出力やフロー内の前のノードからフィールドを参照できます（例：RunInstances が返したインスタンス ID や、前のステップのバケット名）。

  • （任意）Override waiter configuration：ウェイターがどのくらいの時間、どの頻度でポーリングを行うかを調整します。

    • Max wait time：失敗とみなすまでに待機する最大時間（秒）です。デフォルトは 20 分です。

    • Min delay・Max delay：ポーリング試行間の最小および最大秒数です。これらを調整することで、処理の速いオペレーション向けにウェイターを高速化したり、処理の遅いオペレーション向けに負荷を軽減したりできます。

  • （任意）+ Add additional parameters：1 つ以上のパラメータを追加し、値を手動入力するか、+ ボタンを使用して現在のアクションまたは前のノードのフィールドを挿入して設定します。ウェイターがチェック対象のリソースを正確に把握する必要がある場合にパラメータを追加します。例えば、InstanceRunning ウェイターでは InstanceId パラメータを追加し、RunInstances の出力からインスタンス ID を参照して、その特定のインスタンスが準備完了になるまでフローが待機するようにできます。

    ヒント

    これらのオプションの詳細については、AWS SDK ドキュメントの WaiterConfiguration を参照してください。

Custom ウェイター​

Custom ウェイターを使用すると、Built-in ウェイターが利用できない場合や特定の状態を確認する必要がある場合に、独自のポーリング条件を定義できます。

Custom ウェイターは create アクションと generate アクションでは使用できません。これは、Custom ウェイターが、JMESPath 条件が満たされるまで各ポーリング時に同じアクションを再実行することで機能するためです。create・generate コールはべき等ではないため、繰り返し実行すると重複したリソースが作成されたり、その他の望ましくない副作用が発生したりする可能性があります。これらのオペレーションでは、アクションがサポートしている場合は Built-in ウェイターを使用するか、create・generate を一度だけ実行し、その後で Custom ウェイター付きの read または describe アクションを別に使用してください。

例えば、新しい EC2 インスタンスを作成する際にフローを円滑に実行するには、2 段階のプロセスを使用するのが最適です。まず 1 つ目のノードでインスタンスを作成します。その後、2 つ目のノードを追加してステータスを確認します。これは、起動を待つ間に誤って重複するサーバーを作成してしまうことを防ぐためです。

  1. Create the instance：RunInstances ノードを使用してインスタンスを起動します。ここでは Custom ウェイターを追加しないでください。このノードは注文を行うためだけに一度だけ実行される必要があります。

  2. Check the status：直後に DescribeInstances ノードを追加します。1 つ目のノードの Instance ID を使用して、このノードがどのサーバーを確認するかを正確に指定します。2 つ目のノードで Custom ウェイターを有効にし、running など必要なステータスをチェックするように設定します。

これらのステップを分離することで、2 つ目のノードに対して、インスタンスが running 状態に到達するまで待機し定期的に確認するよう指示できます。これにより、1 つ目のインスタンスが起動するのを待つ間にシステムが誤って 2 つ目のインスタンスを作成しようとする事態を防げます。2 つ目のノードがインスタンスの準備完了を確認すると、フローは自動的に次のタスクへ進みます。

Waiter for action

  • JMESPath condition： JMESPath 構文を使用して条件を定義します。式はアクション結果に対して評価され、真偽値を返す必要があります。条件がまだ満たされていない場合、一定の遅延の後にアクションが再度呼び出されます。これは条件が満たされるか最大リトライ回数に達するまで繰り返されます。例えば、status == 'RUNNING' は、リソースがそのステータスを報告するまで待機します。

  • Max retries（1〜30）：失敗とみなす前にアクションを再実行する最大回数です。デフォルトは 5 です。

  • Min delay (ms)・Max delay (ms)：試行間の遅延は、これらの範囲内で指数バックオフを使用します。Min delay のデフォルトは 1000 ms、Max delay のデフォルトは 10000 ms です。

ウェイターの例​

一般的なパターンとしては、AWS アクションでリソースを作成し、そのリソースが利用可能になるまで待機してから、別のアクションや通知を実行します。

  1. Trigger：例えば、schedule や manual trigger など。

  2. AWS node：リソースを作成または変更するアクションを実行します（例：EC2 RunInstances、S3 CreateBucket）。ウェイターを有効にし、適切な Wait until の値（例：InstanceRunning、BucketExists）を選択します。

  3. Next nodes：ノードの出力を Notification node、別の AWS アクション（例：インスタンス ID を使用したボリュームのアタッチ）、または結果に基づいて分岐する Branch node で使用します。

ウェイターを使用しない場合、次のノードはリソースがまだ pending 状態のうちに実行され、失敗したり正しく動作しなかったりする可能性があります。ウェイターを使用すると、リソースが目的の状態に到達した後にのみフローが進行します。

テスト​

ノードをテストするには、Test を選択してください。

に最終更新