I have used different configuration management tools for different use cases in the past. I liked how puppet had a central server and clients pull on a schedule. This way continuous control can be asserted. Ansible on the other hand is much simpler to use and works better during provisioning. Amazon AWS has a service that can help with using Ansible playbooks and continuous application. Some notes below on a POC I did.

Getting the pre-reqs done can be a little tricky so I suggest read and follow this doc carefully: https://aws.amazon.com/blogs/mt/running-ansible-playbooks-using-ec2-systems-manager-run-command-and-state-manager/

In short the high level tasks are:
- Create a role and attach a policy "AmazonEC2RoleforSSM".
- Create simple ansible playbook only httpd for a start. Use the yml in OS and run ansible-playbook to test first.
- Create State Manager Association. Name new association, pick AWS-RunAnsiblePlaybook. Insert yml into "Parameters" section. Manually select Instance and pick schedule.
- Test "Apply association now" and check log in OS.
- Check amazon-ssm-agent.log

I used an Amazon Linux 2 image so we know it meets pre-reqs on the OS side. Note keep viewing the amazon-ssm-agent.log file to troubleshoot. I did not show the logs here but did quite a bit of repetition before it worked. I also have since this article built out the yml to perform the following steps: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-lamp-amazon-linux-2.html

Ensure ansible and yml is working.

# amazon-linux-extras install ansible2

# ansible-playbook /tmp/test.yml 
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
PLAY [This sets up an httpd webserver] ******************************************************************************************************************************************************************
skipping: no hosts matched
PLAY RECAP **********************************************************************************************************************************************************************************************

Monitor log file

# tail -f /var/log/amazon/ssm/amazon-ssm-agent.log
2018-09-12 15:47:51 INFO [instanceID=i-0e38cd17dfed16658] [MessagingDeliveryService] SendReply Response{
  Description: "Reply b667cd46-f314-4d66-ab6e-280f144fe218 was successfully sent.",
  MessageId: "aws.ssm.22e5df47-1051-4b3d-8d86-5d65abab2646.i-0e38cd17dfed16658",
  ReplyId: "b667cd46-f314-4d66-ab6e-280f144fe218",
  ReplyStatus: "QUEUED"
}
2018-09-12 15:52:27 INFO [HealthCheck] HealthCheck reporting agent health.
2018-09-12 15:56:45 INFO [instanceID=i-0e38cd17dfed16658] [LongRunningPluginsManager] There are no long running plugins currently getting executed - skipping their healthcheck
2018-09-12 15:57:01 INFO [instanceID=i-0e38cd17dfed16658] [MessagingDeliveryService] [Association] Schedule manager refreshed with 0 associations, 0 new assocations associated
2018-09-12 15:57:27 INFO [HealthCheck] HealthCheck reporting agent health.

It appears like there is a bug with setting the timezone with ansible. Maybe it will be fixed soon but a workaround like below worked for me.

Issue:
Timezone module cannot set timezone in not systemd based system #19745
https://github.com/ansible/ansible/issues/19745

Should work like this:

   - name: set timezone to New_York
     timezone:
      name: America/New_York

Workaround like this:

  vars:
   - timezone: America/New_York


   - name: Check current timezone
     shell: awk -F\" '{ print $2}' /etc/sysconfig/clock
     register: current_zone
     changed_when: False

   - name: Set EST timezone
     file: src=/usr/share/zoneinfo/{{ timezone }}  dest=/etc/localtime state=link force=yes
     when: current_zone.stdout != '{{ timezone }}'