AWS Step-by-Step
Best Practices for AWS EC2
AWS EC2 continues to be one of the most widely used AWS services. That being the case, I wanted to take the opportunity to share some real world best practices that can help you to use EC2 effectively.
Train New Admins on Foundational Concepts First
The EC2 dashboard does a good job of simplifying the instance creation process. An EC2 admin can easily create an instance, even if they don't necessarily understand what all of the options do. If you have inexperienced administrators who will be tasked with EC2 management, then my advice would be to train them on basic foundational concepts such as IAM, VPC, and CloudWatch before introducing them to EC2. A new admin will be better equipped to handle EC2 if they gain a solid understanding of these dependencies first.
Start Small and Scale
When it comes to deploying a new AWS instance, you don't necessarily have to choose the correct instance size at the time of deployment. The best approach is usually going to be to start out with a small instance size and then gradually increase the instance size based on how the instance performs.
This raises a couple of important questions, starting with how do you know which instance size to start with? There are three main things to consider when choosing an initial instance size. The first consideration is the nature of the workload. As an example, a small Web app might be able to run on a T3.small instance, whereas a light use database might require a T3.Medium instance.
A second consideration is the expected load that will be placed on the server. If you know how many users will be accessing the workload, the number of requests that are expected to be processed each second, the volume of data that the server will handle, or other such metrics, then you can begin to get a feel for the hardware that may be required in order to run the instance. It's also worth noting that operating system selection can play a role as well. As a general rule, Windows instances tend to be a bit more resource hungry than Linux instances.
The third consideration is based purely on personal experience. If you build EC2 instances often enough, you will begin to get a sense for how large an instance needs to be.
The important thing is to avoid creating an instance that is larger than it needs to be, "just in case." Remember, you can always switch to a larger or a smaller instance with very little effort.
Use the Right Tools for Scalability
So far, the discussion on instance scaling has centered around making an instance bigger or smaller based on the workload's hardware needs. This is what is known as scaling up (or down).
AWS CloudWatch is the preferred tool for assisting with scaling an instance up or down. CloudWatch reports on key performance metrics so that you can determine how heavily an instance is being used. If for example, you were to determine that an instance is using 70% to 80% of its CPU resources on a continuous basis, then it's probably time to scale to a larger instance. Remember, this metric is based on the sustained CPU load, not activity spikes.
Of course, CPU load is not the only metric that can be used to determine whether an EC2 instance needs to be scaled. Sustained memory use of 75% to 85% can also be an indicator that the instance needs to be scaled. However, if the instance's memory use steadily increases and never declines, it could be a symptom of a memory leak, which is an application problem not a scalability problem.
Storage can also become a bottleneck for EC2 instances. You might not necessarily need to scale an instance if there is a storage bottleneck, but you may need to switch to using a faster disk. Specifically, you should watch to make sure that the disk queue length does not consistently remain greater than 1 or 2 (ideally, it should be 0). Likewise, watch out for a BurstBalance approaching 0.
While scaling up involves upgrading to a larger instance, scaling out means adding additional instances to service a workload. This is often done for highly available Web apps. If you have such apps, then AWS recommends creating an auto scaling group.
An auto scaling group can add instances automatically when traffic increases and then remove those instances when the demand subsides. Better still, an auto scaling group can detect unhealthy instances and replace those instances automatically.
When creating an auto scaling group, it's important to specify a reasonable minimum and maximum number of instances. The minimum number of instances helps to ensure that your application remains online and available (assuming that there are at least two instances). Setting a maximum number of instances helps to prevent runaway costs.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.