AWS Elastic Beanstalk makes auto scaling and deployment of your web applications a breeze. If you’ve ever deployed highly available web applications such as critical business apps or an ecommerce site you’ve no doubt needed the ability to scale. To accomplish this, you first turn to a load balancing server.
Load balancing gives you two very important things.
- The ability to scale.
- The ability to be fault tolerant.
That sounds awesome, however you quickly found that a load balancing solution was difficult and costly. Even if you implemented it correctly, you were still limited by the physical architecture you budgeted for. Under most cases you were paying for it regardless if you used it or not. For example, here’s a basic list of things you would need to accomplish load balancing:
- A load balancing server
- Two or more web/application servers to handle the traffic and allow for balancing.
- A database server or clusterd database servers to handle all the extra data requests.
- Firewalls, switches, notification services, etc.
- A fulltime engineer to manage it all
While all of these items cost money, the biggest factor is #1 & #2. This dictates your true scalability.
Load balancers were typically priced by the number of web servers it could manage. For example, 1-5 servers, 1-10, 1-25, 1-100, etc. With each scaling group cost more money.
Web/Application Servers: In order to scale, you need something to scale to. This meant you’re required to have those servers physically sitting in your environment, just waiting to be called upon. If the servers aren’t being used, they are just sitting around eating up electricity and admin costing time for patches or hardware failures. That’s a lot of money taken from your bottom line. Oh, if there was a better way!...
Enter AWS Elastic Beanstalk (EBS)
Why yes, there is a better way. With AWS EBS, you only pay for the EC2 instances (Elastic Compute instances … aka servers) when you need them. They are spun up (activated) based on scaling rules you implement and spun down (shut down) and removed from your environment based on the other thresholds. The actual load balancing service of EBS is free. Yay!
In its simplest form you do the following:
- Set up EBS environment
- Configure the type of server you want (window, Linux, etc.).
- Configure EBS to scale based on events (network traffic, CPU max threshold – e.g. CPU at 80%)
- Configure EBS when to remove the extra servers (e.g. CPU hits 5%)
- Configure your security groups (aka firewall)
NOTE: You don’t have to do anything special to make sure your app is up and running. EBS will always keep at least 1 server active. Your configuration will indicate how new servers are spun up or down. Thus, your scalability is managed for you.
What does it cost?
The great thing about it – you are only charged for the EC2 instances you use at any given moment in time. EC2 is a generic term used by Amazon to define their elastic compute instance which a fancy word for a server. If your site traffic is light and you only need one server, then only one is loaded and you are only charged for that single server. If your running a massive sale, you may spike to 3 or 5 or more servers for a few hours or a few days. Once the traffic slows down, EBS will automatically spin down the unused servers. Keep in mind, you control the number of servers you can scale to. You might create a max of 2 servers, or 100 – you are in complete control. Technically speaking you can use EBS, without scaling and simply use 1 server. You can always change the scalablity later.
Your actual cost is dependent on your server configuration and how long they are used. You’ll pick one type of server which will spawn additional instances as needed (based on your configuration). EC2’s come in many flavors which range for operating systems, CPUs, Memory and storage. To get an idea of the actual cost, use of the price guide on AWS: On-Demand Pricing
When a new server is spun up via EBS, the server is a clean build. You can either use one of AWS’s default server images which is referred to as an AMI (Amazon Machine Image), or you can build your own. Typically, you should use one provided by AWS, as it will contain the latest service & security patches. If you use your own, you’ll need to manage the updates manually.
Once the machine is spun up it uses a package (that you build & provide) to install your web application. A package is a zip file that contains your one or more web applications. Each app is in a zip file of their own (within the top level zip), a manifest.json file indicating what’s in the top level zip file, and a .ebsextensions folder that contains other .config files which can execute actions during the installation.
The important thing to note here is that each time a new server is deployed, it’s a clean server, which means you need to have everything in your package (which can also contain a set of instructions on where to get more data). If your app has gigs of images or files, you shouldn’t store them in your package they should be somewhere else. If it’s imperative that they are on your local machine, you should store them on a S3 (an Amazon storage drive) and have them copied over as part of your deployment.
Databases and Images with AWS EBS
As mentioned previously, ideally you want to keep your deployment packages small, which means you should only store core images that are part of your application. If you have a system that generates files or stores tons of images, such as an eCommerce site with product images, you’ll need to offload those to another server.
Images & Dynamic files
If you have a lot of images in your application, you’ll want to store them on another server, such as a dedicate EC2 instance or content delivery server.
When using EBS don’t store your data on the EBS deployed (EC2) machines. Remember that each time a deployment occurs, it’s deployed on a new instance (a clean server). If your database is installed on the initial image, each deployment would start with that clean image… all your data would be reset to that initial state.
Instead use a dedicated server (not part of EBS) to store your data. For example, a Linux or windows server with the appropriate database installed. This machine will always be up and running. However if you’re looking for a data storage device that you don’t need to manage, then you should use AWS RDS (https://aws.amazon.com/rds/) which supports, Amazon Auroa, PostgreSQL, MySQL, MariaDB, Oracle, MS SQL. If you’re looking for a NoSQL alternative, there’s AWS DynamoDb.
Another benefit… Continuous Deployment (CD)
Now that you understand EBS, you are one step away from implementing continuous deployment. Even if you don’t want the ‘continuous’ part you could look at it as ‘single push’ deployment, where a ‘single push’ of a button does the deployment for you. If you are already using a build server such as Jenkins, you can add some additional commands to ‘talk’ to the AWS/CLI and deploy your latest build to Elastic Beanstalk.
Until next time, Happy Scaling!