text: Many traditional systems are designed to run periodically and process batches of transactions that 
  
  have built up over time. For example, a banking application may run every hour to process ATM 
  
  transactions into central ledgers. In Lambda-based applications, the custom processing should be 
  triggered by every event, allowing the service to scale up concurrency as needed, to provide near- 
  
  real time processing of transactions. 
  
  While you can run cron tasks in serverless applications by using Amazon EventBridge Scheduler, 
  
  consider the size of each batch of data that your event sends to Lambda. In this scenario, there 
  
  is potential for the volume of transactions to grow beyond what can be processed within the 15- 
  
  minute Lambda timeout. If the limitations of external systems force you to use a scheduler, you 
  
  should generally schedule for the shortest reasonable recurring time period. 
  
  For example, it’s not best practice to use a batch process that triggers a Lambda function to fetch 
  
  a list of new Amazon S3 objects. This is because the service might receive more new objects in 
  
  between batches than can be processed within a 15-minute Lambda function. 