I have a web service running on AWS that consists of a cluster of Nginx servers running on multiple EC2 instances, load-balanced using an Elastic Load Balancer. Each Nginx instance is identical, and the service relies on a single reference data file containing rows of text based data that's used to generate the response to incoming POST requests to the web service (the contents of the file are read in to memory at startup).

This reference data file is generated by a separate process, updated every 24 hours and made available in a designated S3 bucket. I'm trying to decide on the most robust way of getting the updated file from S3 on to the EC2 instances and having Nginx read them in again (making Nginx read them in again is the easy part: I just need to send the Nginx master process a SIGHUP).

The two main requirements of the solution are that it:

1. runs entirely in the cloud (i.e. using AWS services only) as no physical hardware is available.
2. minimises the impact on availability of the web service, by scheduling the update/reload on each server so that they occur in a staggered fashion, rather than all at the same time.

Options I'm currently considering are:

1. Having a cron job on each EC2 instance that will pull the updated file from S3 and cause Nginx to reload it, once every 24 hours (with a randomised offset so as to stagger the update).
2. Having an AWS Lambda triggered when the file is updated on S3, where the Lambda copies the file to the running EC2 instances and causes Nginx to reload it.

Is option (2) viable? i.e. is it possible to write a Lambda that can identify all running EC2 instances for the current account that match an instance name pattern? And having identified the EC2 instances, is it possible to have the Lambda copy the file from S3 to each EC2 instance? I'm not too clear on what that entails.

Assuming it's possible, does option (2) give me any real advantage over option (1)? I'm open to hearing other ways of doing this too.