[{"data":1,"prerenderedAt":72},["ShallowReactive",2],{"content-svc-lambda-guides-cost-optimization-6-set-timeouts":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":8,"menu":9,"menuType":64,"isCollapseableMenu":12,"nextDocItem":52,"previousDocItem":42,"contributorPaths":65,"contentName":71,"slug":51,"readingTime":38},"\u003Ch1>Set realistic function timeouts\u003C\u002Fh1>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Flambda\u002F\">AWS Lambda\u003C\u002Fa> functions run code for a set amount of time before timing out. The \u003Cem>timeout\u003C\u002Fem> configuration is the maximum amount of time, up to fifteen (15) minutes, that an invocation of your Lambda function can run. The default timeout is three (3) seconds, but you can adjust the timeout in one second intervals.\u003C\u002Fp>\n\u003Cp>Setting an appropriate timeout can be beneficial in containing costs of your Lambda-based application. This is particularly true in the unhappy path, when errors, blocking actions (for example, opening a network connection), or slow dependencies lead to your function running longer than desired or is necessary. When your function reaches its configured timeout, execution of the function will end.\u003C\u002Fp>\n\u003Cp>AWS Lambda is billed per millisecond of execution time. Setting realistic timeouts for functions prevents paying for execution that is not of value.\u003C\u002Fp>\n\u003Cp>Consider a synchronous workload that includes \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fapi-gateway\u002F\">Amazon API Gateway\u003C\u002Fa> and a Lambda function:\u003C\u002Fp>\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Fset-timeouts-01.png\"\u002F>\n\n\u003Cp>API Gateway has a \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fapigateway\u002Flatest\u002Fdeveloperguide\u002Flimits.html\">maximum integration timeout of thirty (30) seconds\u003C\u002Fa>. API Gateway returns an integration error if the Lambda function does not return within thirty seconds. Milliseconds of execution beyond 30 seconds is execution time paid for, but not utilized by the system.\u003C\u002Fp>\n\u003Cp>When setting function timeouts, consider:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Downstream latency of dependencies when your function calls another service. Include network latency, particularly if the dependency is called over the internet.\u003C\u002Fli>\n\u003Cli>Potential retries in case of errors. For example, the AWS SDK will automatically retry failed actions by default. This is effective, particularly in case of temporary failures or throttles, but leads to a longer function execution.\u003C\u002Fli>\n\u003Cli>Potential for unhandled or unexpected errors in the system that may lead to uncaught exceptions.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002Ftimeouts-retries-and-backoff-with-jitter\u002F\">Amazon Builders Library\u003C\u002Fa> article on timeouts, retries, and backoff reviews considerations for handling failures at Amazon.\u003C\u002Fp>\n\u003Cp>Realistic timeouts protect against function execution in the error (or "unhappy") path primarily.\u003C\u002Fp>\n\u003Cp>Our recommendation is to set a timeout of less than 29-seconds for all synchronous invocations, or those in which the caller is waiting for a response. Example event sources include API Gateway, \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fappsync\u002F\">AWS AppSync\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fdeveloper.amazon.com\u002Fen-US\u002Falexa\u002Falexa-developer-documentation-welcome\">Amazon Alexa Skills\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Longer timeouts are appropriate for asynchronous invocations, but consider timeouts longer than 1-minute to be an exception that requires review and testing. While these may be appropriate, consider \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fstep-functions\u002F\">AWS Step Function\u003C\u002Fa> or other integration services if substantial time is spent waiting for dependencies.\u003C\u002Fp>\n\u003Cp>Setting realistic timeouts are an important protection against incurring cost for unnecessary execution time.\u003C\u002Fp>\n",{"title":6,"order":7},"6. Set realistic timeouts",6,"# Set realistic function timeouts\n\n[AWS Lambda](https:\u002F\u002Faws.amazon.com\u002Flambda\u002F) functions run code for a set amount of time before timing out. The *timeout* configuration is the maximum amount of time, up to fifteen (15) minutes, that an invocation of your Lambda function can run. The default timeout is three (3) seconds, but you can adjust the timeout in one second intervals.\n\nSetting an appropriate timeout can be beneficial in containing costs of your Lambda-based application. This is particularly true in the unhappy path, when errors, blocking actions (for example, opening a network connection), or slow dependencies lead to your function running longer than desired or is necessary. When your function reaches its configured timeout, execution of the function will end.\n\nAWS Lambda is billed per millisecond of execution time. Setting realistic timeouts for functions prevents paying for execution that is not of value.\n\nConsider a synchronous workload that includes [Amazon API Gateway](https:\u002F\u002Faws.amazon.com\u002Fapi-gateway\u002F) and a Lambda function:\n\n\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002Fassets\u002Fset-timeouts-01.png\"\u002F>\n\nAPI Gateway has a [maximum integration timeout of thirty (30) seconds](https:\u002F\u002Fdocs.aws.amazon.com\u002Fapigateway\u002Flatest\u002Fdeveloperguide\u002Flimits.html). API Gateway returns an integration error if the Lambda function does not return within thirty seconds. Milliseconds of execution beyond 30 seconds is execution time paid for, but not utilized by the system.\n\nWhen setting function timeouts, consider:\n\n* Downstream latency of dependencies when your function calls another service. Include network latency, particularly if the dependency is called over the internet.\n* Potential retries in case of errors. For example, the AWS SDK will automatically retry failed actions by default. This is effective, particularly in case of temporary failures or throttles, but leads to a longer function execution.\n* Potential for unhandled or unexpected errors in the system that may lead to uncaught exceptions.\n\nThe [Amazon Builders Library](https:\u002F\u002Faws.amazon.com\u002Fbuilders-library\u002Ftimeouts-retries-and-backoff-with-jitter\u002F) article on timeouts, retries, and backoff reviews considerations for handling failures at Amazon.\n\nRealistic timeouts protect against function execution in the error (or \"unhappy\") path primarily.\n\nOur recommendation is to set a timeout of less than 29-seconds for all synchronous invocations, or those in which the caller is waiting for a response. Example event sources include API Gateway, [AWS AppSync](https:\u002F\u002Faws.amazon.com\u002Fappsync\u002F), and [Amazon Alexa Skills](https:\u002F\u002Fdeveloper.amazon.com\u002Fen-US\u002Falexa\u002Falexa-developer-documentation-welcome).\n\nLonger timeouts are appropriate for asynchronous invocations, but consider timeouts longer than 1-minute to be an exception that requires review and testing. While these may be appropriate, consider [AWS Step Function](https:\u002F\u002Faws.amazon.com\u002Fstep-functions\u002F) or other integration services if substantial time is spent waiting for dependencies.\n\nSetting realistic timeouts are an important protection against incurring cost for unnecessary execution time.",[10],{"title":11,"collapsible":12,"isCollapsed":12,"content":13},"Top 8 Optimizations",false,[14,21,28,35,42,48,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":43,"order":44,"time":17,"path":45,"id":46,"link":47},"5. Filter and batch events",5,"5-filter-and-batch","5-filter-and-batch.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fcost-optimization\u002F5-filter-and-batch",{"title":6,"order":7,"time":38,"path":49,"id":50,"link":51},"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",1792665272235]