anchor.diff:  
   This means you can scale down to zero when idle, which means you can use larger instances for the same cost.
   
  -Metrics are collected with a Lambda function, polling every 10 seconds based on the queue the stack is configured with. The autoscaler monitors only one queue, and the monitoring drives the scaling of the stack. This means that usually you need one Elastic stack per queue.
  +Metrics are collected with a Lambda function, polling every 10 seconds based on the queue the stack is configured with. The autoscaler monitors only one queue, and the monitoring drives the scaling of the stack. This means that usually you need one Elastic Stack per queue.
   
   ## Terminating the instance after the job is complete
   
  
positive.code: 
  An instance with a full disk can be causing jobs to fail. If such instance is not being replaced automatically — for example, because of a stack with the `MinSize` parameter greater than zero, you can manually terminate the instance using the EC2 Dashboard.
  
  ## Optimizing for slow Docker builds
  
  For large legacy applications the Docker build process might take a long time on new instances. For these cases it's recommended to create an optimized "builder" stack which doesn't scale down, keeps a warm docker cache and is responsible for building and pushing the application to Docker Hub before running the parallel build jobs across your normal CI stack.
  
  
negative.code: 
  ## Troubleshooting
  
  The Elastic CI Stack can be hard to troubleshoot, but here are some ways to debug exactly what's going on, and some solutions for specific situtions.
  
  ### Using CloudWatch Logs
  
  Elastic CI Stack sends logs to various CloudWatch log streams:
  
  * Buildkite Agent logs get sent to the `buildkite/buildkite-agent/{instance_id}` log stream. If there are problems within the agent itself, the agent logs should help diagnose.
  * Output from an Elastic CI Stack instance's startup script ([Linux](https://github.com/buildkite/elastic-ci-stack-for-aws/blob/master/packer/linux/conf/bin/bk-install-elastic-stack.sh) or [Windows](https://github.com/buildkite/elastic-ci-stack-for-aws/blob/master/packer/windows/conf/bin/bk-install-elastic-stack.ps1)) get sent to the `/buildkite/elastic-stack/{instance_id}` log stream. If an instance is failing to launch cleanly, it's often a problem with the startup script, making this log stream especially useful for debugging problems with the Elastic CI Stack
  
  Additionally, on Linux instances only:
  
  * Docker Daemon logs get sent to the `/buildkite/docker-daemon/{instance_id}` log stream. If docker is having a bad day on your machine, look here.
  * Output from the cloud init process, up until the startup script is initialised, is sent to `/buildkite/cloud-init/output/{instance_id}`. Logs from this stream can be useful for inspecting what environment variables were sent to the startup script.
  
  On Windows instances only:
  
  * Logs from the UserData execution process (analogous to the `/buildkite/cloud-init/output` group above) are sent to the `/buildkite/EC2Launch/UserdataExecution/{instance_id}` log stream.
  
  There are a couple of other log groups that the Elastic CI Stack sends logs to, but their use cases are pretty specific. For a full accounting of what logs are sent to CloudWatch, see the config for [Linux](https://github.com/buildkite/elastic-ci-stack-for-aws/blob/master/packer/linux/conf/cloudwatch-agent/config.json) and Windows.
  
  ### Accesessing  Elastic Stack instances directly
  
  Sometimes, looking at the logs isn't enough to figure out what's going on in your instances. In these cases, it can be useful to access the shell on the instance directly:
  
  * If your Elastic CI Stack has been configured to allow SSH access (using the `AuthorizedUsersUrl` parameter), run `ssh <some instance id>` in your terminal
  * If your Elastic CI Stack has **not** been configured to allow SSH access, you can still use AWS SSM to remotely access the instance. To do this, find the instance ID, and then run `aws ssm start-session --target <instance id>`
  
  ### Auto Scaling group fails to boot instances
  
  