There are several things to consider before clicking that “Launch” button in the AWS (Amazon Web Services) console. The more you plan and take into consideration ahead of time, the more you can save yourself a few headaches down the road. I will go over some fundamental best practices to consider before launching your EC2 instance. These topics will cover storage, security, backup/recovery, and finally management.
Storage
With the low cost of Amazon’s Elastic Block Store (EBS), there are several ways to take advantage of this and use it to your benefit for your instance. Firstly, the root volume (operating system) should always be on its own EBS store. Keeping your root volume separate from your data volume plays to your advantage in a couple noted circumstances:
- Firstly, if there is ever a need to have that data copied over to another instance, you can simply take a snapshot of the data volume and attach it to the new instance without any additional space taken up by the operating system files being copied over as well.
- Secondly, if for whatever reason your operating system becomes corrupt, you can attach a new root volume to the instance with a working operating system and have all of your data intact since it is stored on a different EBS volume. Though you should think about what size volumes you will need now and in the future, if you ever find that you are short on space AWS makes resizing your volumes (or adding new ones) fairly quick and painless.
Also See: AWS S3 Storage Concepts for Windows Admins
Security
AWS has several different areas and layers of security to help keep your EC2 instances protected. Before any instance is launched you should have a policy in place or an idea about how you will handle access to your instances. Some things to consider are how you will create, store, rotate and distribute your AWS access credentials.
AWS access credentials are the first step to securing your EC2 instance. Identity Access Management (IAM) roles should be used when possible to handle any access to your EC2 instances. These roles can have only the access you specify so there is no need for a blanket “allow all to everything” mentality in terms of how things are being accessed.
Your EC2 instance should be making use of a VPC. An instanced launched inside the VPC benefits from the following:
- Assign static private IP addresses to your instances that persist across starts and stops
- Assign multiple IP addresses to your instances
- Define network interfaces, and attach one or more network interfaces to your instances
- Change security group membership for your instances while they’re running
- Control the outbound traffic from your instances (egress filtering) in addition to controlling the inbound traffic to them (ingress filtering)
- Add an additional layer of access control to your instan
ces in the form of network access control lists (ACL) - Run your instances on single-tenant hardware
{{cta(‘209aad85-272d-4e83-8cdc-4f30262bc921′,’justifyleft’)}}Security groups should be configured for each EC2 instance with the least privilege needed. Make use of the security group’s ability to tighten up the inbound and outbound rules allowed by specifying only those that are needed and also from where they are needed.
Backup and Recovery
Backing up your EC2 instances can be as simple as utilizing snapshots. Snapshots are a quick way to ensure your volumes are backed up. A custom script can be used to create snapshots for you on a regularly scheduled basis while retiring old snapshots that are not needed.
A good idea is to make use of Amazon’s availability zones for replicating your data. Replicating your data across multiple zones will ensure your data is still available even if a particular zone goes down for any reason. Although this is a rare occurrence, it has happened in the past, so this can minimize your risk by using multiple zones.
[NOTE: As with any backup/recovery solution, you will want to make sure it is verified and tested before the need for it actually arises.]
Management
Keeping track of all your EC2 resources can be a difficult task once your numbers start to climb. A way to solve this is to make use of AWS tags to tag your instance with relevant information. Keeping the instances tagged will help you manage your resources by allowing different methods of sorting or grouping based on the tag you chose.
AWS also has default service limits for all types of EC2 instances. You will want to make sure you know your limits and plan on sending a limit increase request before hitting the limit. The limit increase process is rather quick, but you don’t want to be blocked by not being able to launch a certain instance type simply because you have already hit your limit.
The Wrap-Up
The ideas I have{{cta(‘8a9fb233-94e7-4220-901a-dc7f556ed529′,’justifyright’)}}covered are some of the things that should be thought about and discussed before launching any instance. Planning ahead will save you time, allow you to be more efficient by making use of all AWS offers with their EC2 instances, and also keep your EC2 instances secure.
What other AWS EC2 instances best practices do you follow on a daily basis in your project work? Share your wisdom with us in a comment below!
Found this blog post useful? Make yourself comfortable and check out our blog home page to explore other technologies we use on a daily basis and the fixes we’ve solved in our day to day work. To make your life easier, subscribe to our blog to get instant updates sent straight to your inbox:
{{cta(‘33985992-7ced-4ebd-b7c8-4fcb88ae3da4′,’justifycenter’)}}
