回答:
私がしたことの1つは、SQSキューのCloudWatchアラームをApproximateNumberOfMessagesVisible（>= 1 for 5 minutes）に作成することでした。アラームは、ラムダ関数をトリガーするSNSトピックに公開します。ラムダ関数は、キューをクリアするまでループします。
アラームからトリガーするのに最大5分かかることがありますが、キューをポーリングする必要なしにバッチスケジュールされたタスクに対して素晴らしく機能します。（アクティブなキューのアラーム粒度は5分です。）
行くことができないSQS -> SNSだけSNS -> SQSです。
Lambda はスケジューリングをサポートするようになったため、1つのオプションはLambda関数にSQSポーラーを実装して頻繁に実行することです。
考慮すべきもう1つのオプションは、実際にキューが必要かどうかです。Lambdaは非同期処理（イベント呼び出しモード経由）をサポートしており、透過的に水平方向にスケーリングして並列呼び出しを処理する必要があります。ラムダ関数が、並列実行を制限する可能性のある中央状態ストアへのアクセスを必要としない場合、おそらくすべての呼び出しを並列で実行できます。ただし、アカウントごとに100の同時実行制限があると思われるので、その下に留まるにはメッセージをバッチ処理する必要があります。
SQSキューはSNSトピックにサブスクライブできるため、受信したSNSメッセージを処理できます。現在、追加のコーディングなしでは他の方向に実行できません（LambdaFAQを参照）。
方法はいくつかありますが、より一般的なイベント駆動型システムを使用するほどエレガントではありませんAWS event->SQS->Lambda。そうでない場合は、SQSキューの処理方法をカスタマイズ/実装する必要があります。
SQSLambdaこれは少し前に尋ねられて答えられましたが、これについて自分で考えたので、アプローチを追加すると思いました。
前述のとおり、ここではイベントソースが最善の策である可能性があります。あるいは、これをテストしたことも考えていませんでした（したがって、これは一種のアカデミックです）。
1. Create a SNS topic.............................: SNS-topic-01
2. Subscribe a SQS queue to that topic............: SQS-queue-01
3. Subscribe a Lambda Function to that topic......: LAMBDA-func-01
この構成を使用して、SNSトピックにメッセージを送信すると、SQSキューにメッセージがキューイングされ、同時にコンパニオンLambda関数がトリガーされます。そのLambda関数は、非常に同じSQSキューを読み取るように書き込まれますが、ロングポーリングが有効になっている（最大20秒）ため、エンキューが完了する前にキューを読み取らない（つまり、競合状態）。
本質的に、このスキームはジャストインタイムで、エンキューされたSQSメッセージごとに1つのLambda関数を呼び出します。同時のロングポールリーダーがSQSでどのように機能するかわかりません（...削除されますか？）が、これはこれを解決することを検討する別の方法です。= :)