3. In our CloudFormation template, the SolutionStackName will be 64bit Amazon Linux 2016.09 v2.3.0 running Ruby 2.3 (Puma). I know in the doc they label it Ruby 2.3 with Puma version 2.3.0 but that is NOT the name used for SolutionStackName. It's the italicized name below the title.

4. We use environment variables in our app that are pulled from S3. The environment file is copied from S3 using Puppet (not shown here). When Elastic Beanstalk starts the Puma server, we need to have those environment variables sourced, or exported to the environment. .ebextensions runs as the app is deployed. To ensure the the env vars are sourced, make sure the .ebextensions has proper .config.

VERY IMPORTANT: The key take away here is the container_commands directive. These commands will be executed in the same environment that the application will run in. All of the other directives execute prior to this, in a differing userspace.

Pay attention to anything in /var/log/eb-*, /var/log/cfn-* and of course /var/log/puma/puma.log

I've noticed that if a deploy fails early on, the instance may not be bootstrapped far enough to get any feedback on the Elastic Beanstalk deploy page. You may only get a generic error like: Update environment operation is complete, but with errors. For more information, see troubleshooting documentation. So dig deep into the logs mentioned above. I found that most of my failure had to do with our .ebextensions/ failing because AWS changed the directory structure around /opt/elasticbeanstalk.

Initially, I tried to update in place the old AMI with the new Solutions Stack Name. Big fat fail there. I could not get this to work. Spent way too much time shaving that cat.