Amazon Elastic Beanstalk, the company's platform as a service, is built on top of Elastic Compute Cloud, Elastic...
Load Balancing and Simple Storage Service. Consumers pay for the underlying services they use while Amazon Web Services provides the platform for free. There are two types of Elastic Beanstalk applications -- Web applications and back-end applications. It's important to choose the right type of application before working in the platform.
Essentially, Amazon Elastic Beanstalk is a configuration management and code deployment system that automatically manages AWS resources. You can store your code in the GIT revision control system and push new versions of the code directly to Beanstalk to publish a new release. Elastic Beanstalk stores zipped versions of the code in Simple Storage Service, or S3, and allows developers to deploy them to Elastic Compute Cloud (EC2) instances that an Auto Scaling group manages. Elastic Load Balancing (ELB) automatically routes traffic to Auto Scaling groups, which Elastic Beanstalk also configures.
Building Web applications
Web applications respond to user requests from a browser directly. They take traffic routed from ELB, optionally through a proxy like Nginx. You can also have Nginx serve up static content directly -- instead of requiring an application to manage static files. However, it's usually better to serve up static content via AWS CloudFront so you don't have any static assets served from application servers.
Because the proxy server adds limitations (it does not support Socket.io or advanced HTTP protocols like SPDY or HTTP2), I recommend disabling the proxy server entirely. Although they are called Web applications, this type of app can listen to any port (or multiple ports), as well as any protocol. The key with Web applications is that they respond directly to user requests and are proxied behind an elastic load balancer.
Building back-end applications
Back-end applications listen on an SQS queue for requests. An example of a back-end application is something that processes uploaded videos and converts them into a mobile format. SQS and a back-end application with Amazon Beanstalk can manage several workloads. If you're already using SQS to process batch background applications, consider using a back-end application from Beanstalk to automatically manage code updates.
Application monitoring in Elastic Beanstalk
It's always a good idea to keep an eye on application health. AWS Elastic Beanstalk has many automated checks to detect common issues. The health of any environment can be found through the Elastic Beanstalk Dashboard, which is a good place to begin troubleshooting.
Red application environments. If your application environment is red, that usually means there are no connections working properly. It tends to signal that all of your servers are down, or there is something broken with the service in general.
To fix a red environment, remove existing servers that are no longer accepting connections. If you set an Auto Scaling policy to use the ELB health check instead of an instance health check, the system will automatically remove servers. If you haven't done that, try killing off all of the instances in this environment manually using the EC2 Management Console. You should be able to search for the name of the environment in the console and see which servers match that.
Check the logs below the health indicator; sometimes you'll see logs indicating that instances have been removed or are starting up. If this is the case, you may need to wait for the situation to resolve itself. If not, you may need to investigate further.
Yellow application environments. If your application environment is yellow, that means the service is in a "degraded" state. This can happen if a percentage of servers go down or the system detects a cascading failure that has not yet resulted in a complete outage.
When you see this icon, you should immediately check the service. Beanstalk usually can recover at this point and launch replacement servers, but if you notice servers are dying or dead, it's often a good idea to kill them off manually. This issue could arise if servers are taking too long to spin up and become available to take requests. If you configured your Elastic Beanstalk environment to use ELB Health Checks, it will check to make sure instances can accept traffic before going into the ELB. But if instances take more than the provisioned amount of time (usually 10 to 15 minutes) to accept requests, they may be assumed to be faulty and automatically replaced. This can lead to the system endlessly starting and killing servers, so make sure servers take less than 10 minutes on average to start.
Grey application environments. A grey status means AWS Elastic Beanstalk is making changes or failed to make changes to an application environment. Once changes are made to an application environment -- either through a code deployment or a configuration change you've made in the console -- you must wait for those changes to propagate before you can make any other changes.
If your environment becomes stuck in this status for an extended period of time, try first rebuilding the environment. You may need to replace it with a new environment. In most cases, you can copy an environment from an existing one if you need to keep all the settings the same. If you can't replace the broken environment because changes are still listed as pending, you may be able to "cancel changes." If that doesn't work, contact AWS support to remove the broken environment.
I've often had issues show up with grey status environments because Elastic Beanstalk couldn't sync with its configuration. This can happen if you try to manually modify any of the resources under Beanstalk's control, such as the load balancer. If you're trying to modify the load balancer configuration, you must do this through Elastic Beanstalk or you may end up completely breaking the environment and getting it into an unrecoverable state.
Green application environments. A green status on your application environment indicates that everything is healthy.
If you are still encountering issues, it's likely the code or configuration -- not a server or something that Beanstalk can detect. Check application logs for more information. You can also perform a snapshot of the logs using Elastic Beanstalk or log into the servers directly to try to debug the issue.
Ways to manage cloud applications
Monitoring AWS applications with CloudTrail