HTTPリクエストを送信するAWSラムダ関数を実装しようとしています。そのリクエストが失敗した場合（レスポンスはステータス200以外の場合）、リトライするまでにもう1時間待つ必要があります（ラムダが熱くなったままです）。これを実装する最良の方法は何ですか？頭に浮かぶ何ラムダ関数を今すぐ実行するか、または1時間以内に実行させる
は、何らかの形で私のHTTPリクエストを持続し、永続HTTP要求の場合には、指定した時間に再びラムダ関数をトリガすることができるということです。しかし、私にはその機能を提供するAWSサービスが完全にはわかりません。 SQSはここで助けになるオプションですか？
または、これに対してラムダの実行を動的にスケジュールできますか？再試行する要求は、最初の試行と同じにする必要があります。
他の提案はありますか？これのベストプラクティスは何ですか？
（ラムダ関数は、私の選択肢である。いかなるEC2またはそのようなことはできません）
前述のjarmodと同様に、SQSによって直接ラムダ関数をトリガすることはできません。要求が失敗した場合、
このSQSメッセージだけに見えるようになりますSQS遅延キュー（docs）
にアイテムをプッシュする：しかし、回避策（私は個人的に使用してきた1）は、次の操作を行うことであろう一定の遅延の後の待ち行列（あなたが1時間言及した）。
そして（私は分を使用）より小さな時間枠のクーロン値によってトリガされる第scheduledラムダ機能を有しています。
この第二の機能は、SQSキューをスキャンし、アイテムがキューにある場合、それを再試行する（SNSによってまたはAWS SDKのいずれか）あなたの最初のラムダ関数を呼び出します。
PS：1時間後に最初の関数の入力をここに格納して保存することができるラムダ関数が必要だと述べたので、SQS項目にデータを入れることができます。
私はあなたがこのためにAWS Step Functionsを詳しく見てみことを示唆しています。基本的にステップ関数は、各ステップでラムダ関数、つまりタスクを実行できる状態マシンです。あなたのAWSコンソールにログインし、「サービス」メニューから「ステップ関数」を選択した場合
詳しい情報は見つけることができます。 Get Startedボタンを押すと、異なるステップ関数のいくつかの実装例が表示されます。まず、「選択肢の状態」の例を詳しく見てみましょう（HTTP要求が成功したかどうかを判断するため）。そうでない場合は、「待機状態」の例に進みます。
このようにするのは魅力的です。しかし、私は呼び出し時間ができるだけ正確であることを知りたい。そして、例えば、この投稿は、削除がバックグラウンドで、TTLの後に行われたが、どれほど速いかについての保証はないと言っている：https://aws.amazon.com/blogs/aws/new-manage-dynamodb-items-using-生存時間 - ttl / – Gustav