There are three components that are defined within the Elastic Beanstalk service:

• Application
• Environment
• Configuration 

An application is a logical grouping for multiple environments that belong to an application. Each environment will be running a specific platform. An overview of an application will display, showing different environments in the management console, like so:

When creating an environment, we'll need to specify a tier that will define the services that are provided by the environment. There are two tiers to choose from:

• Elastic Beanstalk tier: An application frontend that serves the Elastic Beanstalk page
• Worker tier: An application backend that performs tasks

The Elastic Beanstalk tier will usually be fronted by a load balancer, unless we're building a single instance in a non-highly available setup. The worker tier is fronted by an SQS queue where the requests for the worker tier are posted.

We can have multiple application versions within each application. An application version will be defined by the developers and will reflect the version of the code. Once deployed, we can select different versions for an environment and perform upgrades and rollbacks of an environment from within the Elastic Beanstalk's management. Application versions can be viewed in the management console, as demonstrated in the following screenshot:

Each environment will also have a configuration. This configuration will contain all of the necessary information for the Elastic Beanstalk service to build, deploy, and even customize the environment before it's ready to serve the code. When customizing an Elastic Beanstalk configuration, it is wise to save the environment configuration as it can be used to deploy new environments or as a backup in case we break our current configuration. We can take a look at the saved configurations in the management console, as demonstrated in the following screenshot: