AWS Lambda（node.js）をAWS Kinesis Consumerとして使用しています。最大バッチサイズを設定できることがわかりますが、最小バッチサイズを設定できるかどうかは疑問です。そこで、各ラムダが少なくとも50個（または任意の数）のレコードを処理することを保証することができます。Kinesis Lambdaコンシューマー最小バッチサイズ
ラムダコンシューマがRDS MySQLインスタンスへの接続を確立する予定で、同時接続数を低く抑えようとしているため、最小バッチサイズが必要です。
最低限の設定機能がない場合は、回避策があれば幸いです。
ありがとうございました。
最初の質問私が持っているのは、あなたが川に何個のシャードを開いていますか？ 1つのシャードごとにラムダのインスタンスが1つだけ同時に実行されます。したがって、1つのシャードしかない場合は、一度に1つのラムダをRDSインスタンスに割り当てるだけです。
問題を示すデータがありますか？次の何
はがか確実に動作しない場合がありをハックです。おそらく、プロダクト環境では使用しないでください。
最小バッチサイズの場合、バッチサイズが希望のレコード数より少ない場合、node.jsラムダ関数からerrorを返すことができます。
など。
handler(event, context, callback) {
const records = event.Records;
if (records.length() < minBatchSize) {
callback('insufficient batch size');
} else {
processRecords(records, callback);
}
}
しかし二つの問題が頭に浮かぶ：あなたは上のように構成された最大のイベントの時間制限があるので、データを失うリスクを実行せずにこれを無制限に行うことはできません
1）あなたのストリーム。この時間の後、レコードはストリームから消えます。この機能には別途料金がかかります（extended data retention参照）。
ラムダ/キネシスシャードイテレータの年齢測定基準からバッチ年齢を推測することができます（http://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.htmlを参照）。
これはどれくらいの信頼性があるのかわかりません。特にシャードが2つ以上ある場合は特にそうです。 CloudWatchのはあなたを教えてくれません場合は
handler(event, context, callback) {
const records = event.Records;
if (records.length() < minBatchSize) {
if (calculateLambdaAge() > tooLongDelayThreshold) {
processRecords(records, callback);
} else {
callback(new Error('insufficient batch size'));
}
} else {
processRecords(records, callback);
}
}
calculateLambdaAge() {
// interrogate cloudwatch
}
、あなたのRDS（Redisの/ダイナモ）と少なくとも同じくらいスケーラブルだとどこかに自分を追跡する必要があるかもしれません。
2）＃1を信頼できるものにするのではなく、あなたのRDSインスタンスを拡大して現在の使用をより効率的にすることができますか？