Design considerations
Because applications deployed using Amazon Elastic Beanstalk run on Amazon Web Services 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 Amazon whitepapers, covering topics such as architecture, as well as
security and economics, see Amazon Cloud Computing 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 group for your Elastic Beanstalk environment.
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 Amazon, see Amazon Well-Architected Framework.
Security
Security on Amazon is a shared responsibility
Configure SSL to protect information that flows between your application and clients. To configure SSL, you need a free certificate from Amazon 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 Amazon CLI.
If ACM isn't available in your Amazon Web Services Region, you can purchase a certificate from an external CA, such as VeriSign or Entrust. Then, use the Amazon Command Line Interface (Amazon CLI) to upload a third-party or self-signed certificate and private key to Amazon 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.
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. Amazon 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 |
|---|---|---|
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, 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.
Software updates and patching
Amazon Elastic Beanstalk regularly releases platform updates to provide fixes, software updates, and new features. Elastic Beanstalk offers several options to handle platform updates. With managed platform updates 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.