# Understanding concepts in Elastic Beanstalk
Becoming familiar with the concepts and terms will help you gain an understanding needed for deploying your applications with Elastic Beanstalk.
![\[Illustrative diagram showing the relationship between an Elastic Beanstalk application and web/worker environments.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-overview.png)
## Application
An Elastic Beanstalk *application* is a container for Elastic Beanstalk components, including *environments*, *versions*, and *environment configurations*. Within an Elastic Beanstalk application, you manage all the resources relevant to running your code.
## Application version
In Elastic Beanstalk, an *application version* refers to a specific, labeled iteration of deployable code for a web application. An application version points to an Amazon Simple Storage Service (Amazon S3) object that contains the deployable code, such as a Java WAR file.
An application version is part of an application. Applications can have many versions and each application version is unique. In a running environment, you can deploy any application version you already uploaded to the application, or you can upload and immediately deploy a new application version. For example, you could upload multiple application versions to test differences between them.
## Environment
An *environment* is a collection of AWS resources running an application version. Each environment runs only one application version at a time, however, you can run the same application version or different application versions in many environments simultaneously. When you create an environment, Elastic Beanstalk provisions the resources needed in your AWS account to run the application version you specified.
## Environment tier
When you launch an Elastic Beanstalk environment, you first choose an environment tier. The environment tier designates the type of application that the environment runs and determines what resources Elastic Beanstalk provisions to support it. An application that serves HTTP requests runs in a [web server environment tier](concepts-webserver.md). A backend environment that pulls tasks from an Amazon Simple Queue Service (Amazon SQS) queue runs in a [worker environment tier](concepts-worker.md).
## Environment configuration
An *environment configuration* identifies a collection of parameters and settings that define how an environment and its associated resources behave. When you update an environment’s configuration settings, Elastic Beanstalk automatically applies the changes to existing resources or deletes and deploys new resources (depending on the type of change).
## Saved configuration
A *saved configuration* is a template that you can use as a starting point for creating unique environment configurations. You can create and modify saved configurations, and apply them to environments, using the Elastic Beanstalk console, EB CLI, AWS CLI, or API. The API and the AWS CLI refer to saved configurations as *configuration templates*.
## Platform
A *platform* is a combination of an operating system, programming language runtime, web server, application server, and Elastic Beanstalk components. You design and target your web application to a platform. Elastic Beanstalk provides a variety of platforms on which you can build your applications.
For details, see [Elastic Beanstalk platforms](concepts-all-platforms.md).
# Elastic Beanstalk web server environments
The following diagram shows an example Elastic Beanstalk architecture for a web server environment tier, and shows how the components in that type of environment tier work together.
![\[AWS Elastic Beanstalk web server tier architecture diagram.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-architecture2.png)
The environment is the heart of the application. In the diagram, the environment is shown within the top-level solid line. When you create an environment, Elastic Beanstalk provisions the resources required to run your application. AWS resources created for an environment include one elastic load balancer (ELB in the diagram), an Auto Scaling group, and one or more Amazon Elastic Compute Cloud (Amazon EC2) instances.
Every environment has a CNAME (URL) that points to a load balancer. The environment has a URL, such as `myapp.us-west-2.elasticbeanstalk.com`. This URL is aliased in [Amazon Route 53](https://aws.amazon.com/route53/) to an Elastic Load Balancing URL—something like `abcdef-123456.us-west-2.elb.amazonaws.com`—by using a CNAME record. [Amazon Route 53](https://aws.amazon.com/route53/) is a highly available and scalable Domain Name System (DNS) web service. It provides secure and reliable routing to your infrastructure. Your domain name that you registered with your DNS provider will forward requests to the CNAME.
The load balancer sits in front of the Amazon EC2 instances, which are part of an Auto Scaling group. Amazon EC2 Auto Scaling automatically starts additional Amazon EC2 instances to accommodate increasing load on your application. If the load on your application decreases, Amazon EC2 Auto Scaling stops instances, but always leaves at least one instance running.
The software stack running on the Amazon EC2 instances is dependent on the *container type*. A container type defines the infrastructure topology and software stack to be used for that environment. For example, an Elastic Beanstalk environment with an Apache Tomcat container uses the Amazon Linux operating system, Apache web server, and Apache Tomcat software. For a list of supported container types, see [Elastic Beanstalk supported platforms](concepts.platforms.md). Each Amazon EC2 instance that runs your application uses one of these container types. In addition, a software component called the *host manager (HM)* runs on each Amazon EC2 instance. The host manager is responsible for the following:
+ Deploying the application
+ Aggregating events and metrics for retrieval via the console, the API, or the command line
+ Generating instance-level events
+ Monitoring the application log files for critical errors
+ Monitoring the application server
+ Patching instance components
+ Rotating your application's log files and publishing them to Amazon S3
The host manager reports metrics, errors and events, and server instance status, which are available via the Elastic Beanstalk console, APIs, and CLIs.
The Amazon EC2 instances shown in the diagram are part of one *security group*. A security group defines the firewall rules for your instances. By default, Elastic Beanstalk defines a security group, which allows everyone to connect using port 80 (HTTP). You can define more than one security group. For example, you can define a security group for your database server. For more information about Amazon EC2 security groups and how to configure them for your Elastic Beanstalk application, see [EC2 security groups](using-features.managing.ec2.console.md#using-features.managing.ec2.securitygroups).
# Elastic Beanstalk worker environments
AWS resources created for a worker environment tier include an Auto Scaling group, one or more Amazon EC2 instances, and an IAM role. For the worker environment tier, Elastic Beanstalk also creates and provisions an Amazon SQS queue if you don’t already have one. When you launch a worker environment, Elastic Beanstalk installs the necessary support files for your programming language of choice and a daemon on each EC2 instance in the Auto Scaling group. The daemon reads messages from an Amazon SQS queue. The daemon sends data from each message that it reads to the web application running in the worker environment for processing. If you have multiple instances in your worker environment, each instance has its own daemon, but they all read from the same Amazon SQS queue.
The following diagram shows the different components and their interactions across environments and AWS services.
![\[AWS Elastic Beanstalk worker tier architecture diagram.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/aeb-architecture_worker.png)
Amazon CloudWatch is used for alarms and health monitoring. For more information, go to [Basic health reporting](using-features.healthstatus.md).
For details about how the worker environment tier works, see [Elastic Beanstalk worker environments](using-features-managing-env-tiers.md).
# Design considerations for your Elastic Beanstalk applications
Because applications deployed using AWS Elastic Beanstalk run on AWS Cloud resources, you should keep several configuration factors in mind to optimize your applications: *scalability*, *security*, *persistent storage*, *fault tolerance*, *content delivery*, *software updates and patching*, and *connectivity*. Each of these are covered separately in this topic. For a comprehensive list of technical AWS whitepapers, covering topics such as architecture, as well as security and economics, see [AWS Cloud Computing Whitepapers](https://aws.amazon.com/whitepapers/).
## Scalability
When operating in a physical hardware environment, in contrast to a cloud environment, you can approach scalability in one of either two ways. Either you can scale up through vertical scaling or you can scale out through horizontal scaling. The scale-up approach requires that you invest in powerful hardware, which can support the increasing demands of your business. The scale-out approach requires that you follow a distributed model of investment. As such, your hardware and application acquisitions can be more targeted, your data sets are federated, and your design is service oriented. The scale-up approach can be expensive, and there's also the risk that your demand could outgrow your capacity. In this regard, the scale-out approach is usually more effective. However, when using it, you must be able to predict demand at regular intervals and deploy infrastructure in chunks to meet that demand. As a result, this approach can often lead to unused capacity and might require some careful monitoring.
By migrating to the cloud, you can make your infrastructure align well with demand by leveraging the elasticity of cloud. Elasticity helps to streamline resource acquisition and release. With it, your infrastructure can rapidly scale in and scale out as demand fluctuates. To use it, configure your Auto Scaling settings to scale up or down based on the metrics for the resources in your environment. For example, you can set metrics such as server utilization or network I/O. You can use Auto Scaling for compute capacity to be added automatically whenever usage rises and for it to be removed whenever usage drops. You can publish system metrics (for example, CPU, memory, disk I/O, and network I/O) to Amazon CloudWatch. Then, you can use CloudWatch to configure alarms to trigger Auto Scaling actions or send notifications based on these metrics. For instructions on how to configure Auto Scaling, see [Auto Scaling your Elastic Beanstalk environment instances](using-features.managing.as.md).
We also recommend that you design all your Elastic Beanstalk applications as *stateless* as possible, using loosely coupled, fault-tolerant components that can be scaled out as needed. For more information about designing scalable application architectures for AWS, see [https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html).
## Security
Security on AWS is a [shared responsibility](https://aws.amazon.com/compliance/shared-responsibility-model/). Amazon Web Services protects the physical resources in your environment and ensures that the Cloud is a safe place for you to run applications. You're responsible for the security of data coming in and out of your Elastic Beanstalk environment and the security of your application.
Configure SSL to protect information that flows between your application and clients. To configure SSL, you need a free certificate from AWS Certificate Manager (ACM). If you already have a certificate from an external certificate authority (CA), you can use ACM to import that your certificate. Otherwise, you can import it using the AWS CLI.
If ACM isn't [available in your AWS Region](https://docs.aws.amazon.com/general/latest/gr/acm.html), you can purchase a certificate from an external CA, such as VeriSign or Entrust. Then, use the AWS Command Line Interface (AWS CLI) to upload a third-party or self-signed certificate and private key to AWS Identity and Access Management (IAM). The public key of the certificate authenticates your server to the browser. It also serves as the basis for creating the shared session key that encrypts the data in both directions. For instructions on how to create, upload, and assign an SSL certificate to your environment, see [Configuring HTTPS for your Elastic Beanstalk environment](configuring-https.md).
When you configure an SSL certificate for your environment, data is encrypted between the client and the Elastic Load Balancing load balancer for your environment. By default, encryption is terminated at the load balancer, and traffic between the load balancer and Amazon EC2 instances is unencrypted.
## Persistent storage
Elastic Beanstalk applications run on Amazon EC2 instances that have no persistent local storage. When the Amazon EC2 instances terminate, the local file system isn't saved. New Amazon EC2 instances start with a default file system. We recommend that you configure your application to store data in a persistent data source. AWS offers a number of persistent storage services that you can use for your application. The following table lists them.
| Storage service | Service documentation | Elastic Beanstalk integration |
| --- | --- | --- |
| [Amazon S3](https://aws.amazon.com/s3/) | [Amazon Simple Storage Service Documentation](https://aws.amazon.com/documentation/s3/) | [Using Elastic Beanstalk with Amazon S3](AWSHowTo.S3.md) |
| [Amazon Elastic File System](https://aws.amazon.com/efs/) | [Amazon Elastic File System Documentation](https://aws.amazon.com/documentation/efs/) | [Using Elastic Beanstalk with Amazon Elastic File System](services-efs.md) |
| [Amazon Elastic Block Store](https://aws.amazon.com/ebs/) | [Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) [Feature Guide: Elastic Block Store](https://aws.amazon.com/articles/1667) | |
| [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) | [Amazon DynamoDB Documentation](https://aws.amazon.com/documentation/dynamodb/) | [Using Elastic Beanstalk with Amazon DynamoDB](AWSHowTo.dynamoDB.md) |
| [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/) | [Amazon Relational Database Service Documentation](https://aws.amazon.com/documentation/rds/) | [Using Elastic Beanstalk with Amazon RDS](AWSHowTo.RDS.md) |
**Note**
Elastic Beanstalk creates a *webapp* user for you to set up as the owner of application directories on EC2 instances. For Amazon Linux 2 platform versions that are released on or after [Feburary 3, 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-02-03-linux.html#release-2022-02-03-linux.changes), Elastic Beanstalk assigns the *webapp* user a uid (user id) and gid (group id) value of 900 for new environments. It does the same for existing environments following a platform version update. This approach keeps consistent access permission for the *webapp* user to permanent file system storage.
In the unlikely situation that another user or process is already using 900, the operating system defaults the *webapp* user uid and gid to another value. Run the Linux command **id webapp** on your EC2 instances to verify the uid and gid values that are assigned to the *webapp* user.
## Fault tolerance
As a rule of thumb, you should be a pessimist when designing architecture for the cloud. Leverage the elasticity that it offers. Always design, implement, and deploy for automated recovery from failure. Use multiple Availability Zones for your Amazon EC2 instances and for Amazon RDS. Availability Zones are conceptually like logical data centers. Use Amazon CloudWatch to get more visibility into the health of your Elastic Beanstalk application and take appropriate actions in case of hardware failure or performance degradation. Configure your Auto Scaling settings to maintain your fleet of Amazon EC2 instances at a fixed size so that unhealthy Amazon EC2 instances are replaced by new ones. If you're using Amazon RDS, then set the retention period for backups, so that Amazon RDS can perform automated backups.
## Content delivery
When users connect to your website, their requests may be routed through a number of individual networks. As a result, users might experience poor performance due to high latency. Amazon CloudFront can help ameliorate latency issues by distributing your web content, such as images and video, across a network of edge locations around the world. Users' requests are routed to the nearest edge location, so content is delivered with the best possible performance. CloudFront works seamlessly with Amazon S3, which durably stores the original, definitive versions of your files. For more information about Amazon CloudFront, see the [Amazon CloudFront Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html).
## Software updates and patching
AWS Elastic Beanstalk regularly releases [platform updates](using-features.platform.upgrade.md) to provide fixes, software updates, and new features. Elastic Beanstalk offers several options to handle platform updates. With [managed platform updates](environment-platform-update-managed.md) your environment automatically upgrades to the latest version of a platform during a scheduled maintenance window while your application remains in service. For environments created on November 25, 2019 or later using the Elastic Beanstalk console, managed updates are enabled by default whenever possible. You can also manually initiate updates using the Elastic Beanstalk console or EB CLI.
## Connectivity
Elastic Beanstalk needs to be able to connect to the instances in your environment to complete deployments. When you deploy an Elastic Beanstalk application inside an Amazon VPC, the configuration required to enable connectivity depends on the type of Amazon VPC environment you create:
+ For single-instance environments, no additional configuration is required. This is because, with these environments, Elastic Beanstalk assigns each Amazon EC2 instance a public Elastic IP address that enables the instance to communicate directly with the internet.
+ For load-balanced, scalable environments in an Amazon VPC with both public and private subnets, you must do the following:
+ Create a load balancer in the public subnet to route inbound traffic from the internet to the Amazon EC2 instances.
+ Create a network address translation (NAT) device to route outbound traffic from the Amazon EC2 instances in private subnets to the internet.
+ Create inbound and outbound routing rules for the Amazon EC2 instances inside the private subnet.
+ If you're using a NAT instance, configure the security groups for the NAT instance and Amazon EC2 instances to enable internet communication.
+ For a load-balanced, scalable environment in an Amazon VPC that has one public subnet, no additional configuration is required. This is because, with this environment, your Amazon EC2 instances are configured with a public IP address that enables the instances to communicate with the internet.
For more information about using Elastic Beanstalk with Amazon VPC, see [Using Elastic Beanstalk with Amazon VPC](vpc.md).