[{"data":1,"prerenderedAt":72},["ShallowReactive",2],{"content-svc-lambda-guides-cost-optimization-5-filter-and-batch":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":64,"isCollapseableMenu":12,"nextDocItem":46,"previousDocItem":35,"contributorPaths":65,"contentName":71,"slug":45,"readingTime":17},"\u003Ch1>Filtering & Batching events\u003C\u002Fh1>\n\u003Cp>Are you building or have an existing stream processing application that uses AWS Lambda? Are you looking to optimize your Lambda costs? \u003C\u002Fp>\n\u003Cp>You are in the right place! Streaming applications are used in a variety of scenarios to gain business insights from clickstream data, capture the device data from thousands or millions of IoT devices, real-time stock trading applications, while imagination is the limit for the applications you can build. Once the stream data is available, it has to be processed as quickly as possible. AWS Lambda is a serverless compute service that allows companies to focus on delivering business value by removing the undifferentiated heavy-lifting of infrastructure management. AWS Lambda allows you to process the events from various data streams like Kinesis, DynamoDB, SQS, Kafka, and MQ, and automatically scales up and down to match the required capacity. Let's take a closer look into how you can reduce the overall Lambda costs while using streaming application. \u003C\u002Fp>\n\u003Cp>AWS Lambda function costs are based on three major factors - invocations, memory assigned, and the duration of the function. Changes to any of the three factors has a direct impact on the lambda costs, i.e. if we reduce the number of overall invocations, we can reduce the overall Lambda function costs.\u003C\u002Fp>\n\u003Ch2>\u003Cstrong>Filtering incoming events\u003C\u002Fstrong>\u003C\u002Fh2>\n\u003Cp>By configuring the event source with the filter criteria, you can reduce the number of messages that are used to invoke your Lambda function and the memory associated to filter out the events. By default, you can add up to \u003Cstrong>five\u003C\u002Fstrong> filters (10,240 characters) for a single event source mapping which are logically \u003Cstrong>ORed\u003C\u002Fstrong> together.  \u003C\u002Fp>\n\u003Cp>You can add filters to event source mappings for the following AWS services:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Amazon DynamoDB\u003C\u002Fli>\n\u003Cli>Amazon Kinesis Data Streams\u003C\u002Fli>\n\u003Cli>Amazon MQ\u003C\u002Fli>\n\u003Cli>Amazon Managed Streaming for Apache Kafka (Amazon MSK)\u003C\u002Fli>\n\u003Cli>Self-managed Apache Kafka\u003C\u002Fli>\n\u003Cli>Amazon Simple Queue Service (Amazon SQS)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Let's take an example of a shopping mall which uses 10,000 temperature sensors to automatically tune the air conditioner temperature. Stores with more customers, food courts, mall entrance tend to have higher temperatures compared to other spots within the mall. Assume the temperature sensors emits the temperature once a minute. Each month, the mall receives 10,000 * 60 * 24 * 31 ~ 450 million messages, which invokes the same number of Lambda invocations. With 255 MB of function memory and an average function duration of 100ms, let's filter out the temperatures which are greater than 70 \ndegrees in the mall entrance. You can configure the following filter \u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n\t"body": {\n\t\t"sensorId": [{\n\t\t\t"prefix": "mall-entrance-"\n\t\t}],\n\t\t"temperature": [{\n\t\t\t"numeric": [">", 70]\n\t\t}]\n\t}\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>For events, with sensorId that starts with "mall-entrance" and temperature greater than 70, the lambda function is invoked, else the message is discarded and the function is not invoked. If we need only 2.2% of the data, then the number of invocations and compute is reduced by 97.8% and similarly the Lambda costs. Let's see how the pricing changes with and without filtering: \u003C\u002Fp>\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Ffilter-batch-01.png\"\u002F>\n\n\n\u003Chr>\n\u003Ch2>\u003Cstrong>Batching incoming events\u003C\u002Fstrong>\u003C\u002Fh2>\n\u003Cp>An alternative way to optimize Lambda costs is by batching the incoming messages. AWS Lambda offers you to configure the batch size from the stream event sources. Lambda reads the messages in batches and provides these to your function as an event payload. \nYou can batch up to 10,000 messages or 6 MB whichever reaches first, and the poller invokes the Lambda function with the messages payload. Batching not only improves the throughput, but also speeds up the processing of your application, while reducing the overall Lambda costs.  \u003C\u002Fp>\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Ffilter-batch-02.png\"\u002F>\n\n\n\u003Ch3>\u003Cstrong>What should be my batch size?\u003C\u002Fstrong>\u003C\u002Fh3>\n\u003Cp>We recommend you to find the batch size that addresses your business needs and process the messages in parallel. Larger batch sizes mean lesser invocations, however, it does not mean that you always have to use the largest possible batch size. It has to be balanced with other components of your application, think about how the processed data influences the downstream services, third-party API requests, network capacity, database throughput\u002F IO limits. In addition, we recommend you to run load tests on your function code to test the Lambda code performance and tune the function memory according to the preferred batch size. \u003C\u002Fp>\n\u003Ch2>References\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Finvocation-eventfiltering.html\">https:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Finvocation-eventfiltering.html\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fintroducing-aws-lambda-batching-controls-for-message-broker-services\u002F\">https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fintroducing-aws-lambda-batching-controls-for-message-broker-services\u002F\u003C\u002Fa>\u003C\u002Fp>\n",{"title":6,"order":7},"5. Filter and batch events",5,"# Filtering & Batching events\n\nAre you building or have an existing stream processing application that uses AWS Lambda? Are you looking to optimize your Lambda costs? \n\nYou are in the right place! Streaming applications are used in a variety of scenarios to gain business insights from clickstream data, capture the device data from thousands or millions of IoT devices, real-time stock trading applications, while imagination is the limit for the applications you can build. Once the stream data is available, it has to be processed as quickly as possible. AWS Lambda is a serverless compute service that allows companies to focus on delivering business value by removing the undifferentiated heavy-lifting of infrastructure management. AWS Lambda allows you to process the events from various data streams like Kinesis, DynamoDB, SQS, Kafka, and MQ, and automatically scales up and down to match the required capacity. Let's take a closer look into how you can reduce the overall Lambda costs while using streaming application. \n\nAWS Lambda function costs are based on three major factors - invocations, memory assigned, and the duration of the function. Changes to any of the three factors has a direct impact on the lambda costs, i.e. if we reduce the number of overall invocations, we can reduce the overall Lambda function costs.\n\n## **Filtering incoming events**\n\nBy configuring the event source with the filter criteria, you can reduce the number of messages that are used to invoke your Lambda function and the memory associated to filter out the events. By default, you can add up to **five** filters (10,240 characters) for a single event source mapping which are logically **ORed** together.  \n\nYou can add filters to event source mappings for the following AWS services:\n\n- Amazon DynamoDB\n- Amazon Kinesis Data Streams\n- Amazon MQ\n- Amazon Managed Streaming for Apache Kafka (Amazon MSK)\n- Self-managed Apache Kafka\n- Amazon Simple Queue Service (Amazon SQS)\n\nLet's take an example of a shopping mall which uses 10,000 temperature sensors to automatically tune the air conditioner temperature. Stores with more customers, food courts, mall entrance tend to have higher temperatures compared to other spots within the mall. Assume the temperature sensors emits the temperature once a minute. Each month, the mall receives 10,000 * 60 * 24 * 31 ~ 450 million messages, which invokes the same number of Lambda invocations. With 255 MB of function memory and an average function duration of 100ms, let's filter out the temperatures which are greater than 70 \ndegrees in the mall entrance. You can configure the following filter \n\n```json\n{\n\t\"body\": {\n\t\t\"sensorId\": [{\n\t\t\t\"prefix\": \"mall-entrance-\"\n\t\t}],\n\t\t\"temperature\": [{\n\t\t\t\"numeric\": [\">\", 70]\n\t\t}]\n\t}\n}\n```\n\nFor events, with sensorId that starts with \"mall-entrance\" and temperature greater than 70, the lambda function is invoked, else the message is discarded and the function is not invoked. If we need only 2.2% of the data, then the number of invocations and compute is reduced by 97.8% and similarly the Lambda costs. Let's see how the pricing changes with and without filtering: \n\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Ffilter-batch-01.png\"\u002F>\n\n\n___\n\n## **Batching incoming events** \n\nAn alternative way to optimize Lambda costs is by batching the incoming messages. AWS Lambda offers you to configure the batch size from the stream event sources. Lambda reads the messages in batches and provides these to your function as an event payload. \nYou can batch up to 10,000 messages or 6 MB whichever reaches first, and the poller invokes the Lambda function with the messages payload. Batching not only improves the throughput, but also speeds up the processing of your application, while reducing the overall Lambda costs.  \n\n\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Ffilter-batch-02.png\"\u002F>\n\n\n### **What should be my batch size?** ### \n\nWe recommend you to find the batch size that addresses your business needs and process the messages in parallel. Larger batch sizes mean lesser invocations, however, it does not mean that you always have to use the largest possible batch size. It has to be balanced with other components of your application, think about how the processed data influences the downstream services, third-party API requests, network capacity, database throughput\u002F IO limits. In addition, we recommend you to run load tests on your function code to test the Lambda code performance and tune the function memory according to the preferred batch size. \n\n\n## References\n\nhttps:\u002F\u002Fdocs.aws.amazon.com\u002Flambda\u002Flatest\u002Fdg\u002Finvocation-eventfiltering.html\n\nhttps:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fintroducing-aws-lambda-batching-controls-for-message-broker-services\u002F",[10],{"title":11,"collapsible":12,"isCollapsed":12,"content":13},"Top 8 Optimizations",false,[14,21,28,35,42,46,52,58],{"title":15,"order":16,"time":17,"path":18,"id":19,"link":20},"1. Fine-tune Lambda power",1,"4 min","1-fine-tuning","1-fine-tuning.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F1-fine-tuning",{"title":22,"order":23,"time":24,"path":25,"id":26,"link":27},"2. Switch to Graviton2",2,"2 min","2-graviton","2-graviton.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F2-graviton",{"title":29,"order":30,"time":31,"path":32,"id":33,"link":34},"3. Fine-tune CloudWatch Logs",3,"1 min","3-cloudwatch","3-cloudwatch.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F3-cloudwatch",{"title":36,"order":37,"time":38,"path":39,"id":40,"link":41},"4. Don't pay for idle",4,"3 min","4-avoid-idle","4-avoid-idle.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F4-avoid-idle",{"title":6,"order":7,"time":17,"path":43,"id":44,"link":45},"5-filter-and-batch","5-filter-and-batch.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F5-filter-and-batch",{"title":47,"order":48,"time":38,"path":49,"id":50,"link":51},"6. Set realistic timeouts",6,"6-set-timeouts","6-set-timeouts.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F6-set-timeouts",{"title":53,"order":54,"time":31,"path":55,"id":56,"link":57},"7. Use direct integrations",7,"7-direct-integrations","7-direct-integrations.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F7-direct-integrations",{"title":59,"order":60,"time":31,"path":61,"id":62,"link":63},"8. Use CloudWatch embedded metric format",8,"8-emf","8-emf.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F8-emf","LIST",[66,67,68,69,70],"content\u002Fcontributors\u002Fdan-fox.json","content\u002Fcontributors\u002Fanton-aleksandrov.json","content\u002Fcontributors\u002Fjosh-kahn.json","content\u002Fcontributors\u002Fdhiraj-mahapatro.json","content\u002Fcontributors\u002Fvamsi-vikash-ankam.json","Cost Optimization for AWS Lambda",1792578873170]