Truc con : on ne peut pas utiliser le résultat du get-repository-policy dans le set-repository-policy pour cloner.

Il faut au passage enlever les \n qui trainent dans la réponse

 $ cat monitor_beanstalk.py
#!/bin/python

import boto3
import pprint
pp = pprint.PrettyPrinter(indent=4)


#List all env and status and instances health

client = boto3.client('elasticbeanstalk')


envs = client.describe_environments()['Environments']

#pp.pprint(envs)


for env in envs:
    print 'ApplicationName: {} EnvironmentName: {} Health: {} HealthStatus: {} Status: {}'.format(env['ApplicationName'].ljust(30),env['EnvironmentName'].ljust(30),env['Health'].ljust(10),env.get('HealthStatus', 'N/A').ljust(10),env['Status'].ljust(10))
    if (env['Health'] != 'Green') or (env.get('HealthStatus', 'N/A') != 'Ok' and env.get('HealthStatus', 'N/A') != 'N/A'):
        print '\nProblem'
        details = client.describe_environment_health(EnvironmentName=env['EnvironmentName'],AttributeNames=['All'])
        #pp.pprint(details)
        print details['Causes']
        print details['InstancesHealth']
        print '\n'

why EFS sucks

If you enable s3 enpoint in your route table, it's kind of tricky to know if the endpoint is really working. Two things to validate:
1) traceroute tcp before and after (traceroute -T s3-us-west-1.amazonaws.com 443)
You will see more hope when endpoint not activated
2) try an s3 sync cross region with enpoint activated : it should failed since it's not supported (yet @ 2017-05-02)

Good boy atlassian!

As the included diagram portrays, in a common workflow, the worker instance will consume messages sent to a specified Amazon SQS from another service (e.g.: a web server or another worker). These messages will be received by the worker via POST requests. This eliminates the necessity of configuring a worker as an always-on service, as well as having to add code for reading and consuming messages from an AWS SQS queue. In other words, the worker is implemented as a standard RESTful API/Service that will react to a message sent to it at an specific endpoint via a POST request. This is an awesome approach by Amazon to microservices and reactive design.

The conversion of the SQS message to a POST request is executed by what AWS calls the "SQS Daemon" or "Sqsd". This is a simple daemon they pre-install in the worker tier instances that is constantly monitoring an specific AWS SQS queue (provided by configuration) for new messages. When new messages arrive, it constructs a POST request and sends it to a specific endpoint (also provided via configuration). If the endpoint consumes it without errors and returns a 2** HTTP Code in its response, the "Sqsd" deletes the message from the queue to signal that its consumption was successful.

However, even though this approach is extremely powerful, Amazon does not provide the code of this daemon as open source. Therefore, we have reproduced its behavior by creating our own version of the "Sqsd" free for everyone to use. Moreover, we have provided lots of customization and configuration properties so that it can be molded to your specific use cases.