The core of AWS is the compute and storage service provided by Elastic Computer Cloud or EC2. The EC2 services allow us to deploy virtual servers within an AWS environment. There are a number of elements in creating an EC2 instance and the service can be broken down into the following areas:
1 ) AMIs
AMIs, are Amazon Machine Images and these are essentially templates of pre-configured EC2 instances which allow you to quickly launch a new EC2 instance – or server and compute resources – based on the configuration within the AMI. This prevents you from having to install an operating system or any other common applications that you might need to install on a number of other EC2 instances.
From a high-level perspective, an AMI will include an operating system and applications, along with any custom configuration.
AWS provides a large number of AMIs covering different operating systems, from Linux Ubuntu and Centos; Red Hat Linux or RHEL; to Microsoft Windows, among others. When configuring your EC2 instance, selecting your AMI is the first configuration choice you will need to make. You can also create your own AMI images to help you speed up your own deployments. However, it is recommended that when starting with EC2, you used pre-defined AMIs within the AWS console or marketplace. You can then amend this as necessary.
Amending the AMI:
For example, you could start with selecting an AWS AMI, on a Linux server. Once it is up and running, you may then need to install a number of your own custom applications and make specific configuration changes. Now if you needed another server to perform the same functionality, you could go through the same process of selecting a Linux AWS AMI and, again, manually installing your applications and make your configurations. Or, once you have made those changes on the first server, you can then simply create a brand-new AMI of that instance with all the applications installed and configurations already made, that you need to deploy on a specific type of server resource (instance).
If you need another server with this same configuration, all you need to do is to select your custom AMI as the base image for your instance and it will launch the Linux server, your custom applications already installed, and any configurations already made. This saves time, money, hassle and is a key part of auto-scaling new instances to match demand (or reduce instances if demand and throughput drop).
2 ) Instance types
Once you have selected your AMI from any of the different sources already discussed, you must then select an instance type. An instance type simply defines the size of the instance from a CPU, memory, storage, and networking perspective. Having this flexibility of varied instances allows you to select the most appropriate size or power of a virtual server that you need for optimal performance with your applications.
These different instance types are categorized into different family types that offer distinct performance benefits which, again, helps you to select the most appropriate instance for your needs. Within each of these instance families, you will have a range of instance types with varied CPU, memory, storage, and networking performance. These instance families can be summarized as follows.
You can purchase EC2 instances through a variety of different payment plans. These have been designed to help you save costs by selecting the most appropriate option for your deployment. The different EC2 payment options are as follows:
Reserved instances allow you to purchase an instance type for a set period of time in return for a reduced cost compared to on-demand. This reduction can be as much as 75%. These reservations against instances must be purchased in either one- or three-year timeframes.
Reserved instances are used for long-term, predictable workloads, allowing you to make full use of the cost savings to be had when using compute resources offered by EC2.
Spot instances allow you to bid for unused EC2 compute resources; however, your resource is not guaranteed for a fixed period of time. To use an EC2 spot instance, you must bid higher than the current spot price which is set by AWS. This spot price fluctuates depending on supply and demand of the unused resource. If your bid price for an instance type is higher than the spot price, then you’ll purchase the instance; but as soon your bid price becomes lower than the fluctuating spot price, you will be issued a two-minute warning before the instance is automatically terminated and removed from your environment by AWS. The bonus of spot instances is that you can bid for large EC2 instances at a very low price point, saving a huge amount. But due to the nature of how the instances can suddenly be removed from your environment, spot instances are only useful for processing data and applications that can be suddenly interrupted, such as batch jobs and background processing of data.
One key point to make about pricing with EC2 instances is that you’ll only pay for the instance when it is up and running, excluding reserved instances all upfront. You will not pay for the instance if you are stopped or terminated the instance.
3 ) Tenancy
Tenancy relates to what underlying host your EC2 instance will reside on as a virtual server within the AWS data center. Again, there are different options available to you, with pros and cons to each.
4 ) User Data
During the configuration of your EC2 instance, there is a section called user data, which allows you to enter commands that will run during the first boot cycle of that instance. This is a great way to automatically perform functions upon boot, such as to pull down any additional software you want installing from any software repositories you may have. You could also download and get the latest OS updates during boot. For example, you could enter yum update /y for a Linux server, which will then update its own software automatically at time of boot.
5 ) Storage Options
As a part of the configuration when setting up an EC2 instance, you are asked to select and configure your storage requirements. Selecting storage for your EC2 instance will depend on what you intend to use the instance for and how critical the data is. Storage for EC2 can be classified between two distinct categories:
Persistent storage is available by using elastic block storage, EBS volumes; and ephemeral storage is created by some EC2 instances themselves using local storage on the underlying host, known as instance backed storage.
EBS:
EBS volumes are separate devices from the EC2 instance itself, and so it is not physically attached like ephemeral storage is attached. EBS volumes are akin to a SAN, and are considered network attached storage devices, which are then logically attached to the EC2 instance by the AWS network. This principle is not dissimilar to attaching an external hard disk to your home laptop or PC where the external hard disk would be your EBS volume and your PC is your EC2 instance.
The data on EBS volumes is automatically replicated to other EBS volumes within the same availability zone for resiliency, which is all managed by AWS. You can disconnect the EBS volume from your EC2 instance and the data will remain intact, allowing you to reattach it to another EC2 instance if required. You can also implement encryption on these volumes and, if required, take backup snapshots of all the data on the volume to the simple storage service, S3. EBS volumes can be created in different sizes, again with different performance capabilities depending on your requirements.
Ephemeral storage, or instance backed storage, is storage that is physically attached to the underlying host on which the EC2 instance resides on. This is similar to your own laptop or PCs hard disk. There is a difference here though. With AWS EC2 instances, as soon as the instance is stopped or terminated, all saved data on that disk is lost. If you reboot your instance, then that data will remain; but not if you stop it. Therefore, if you have any data that you need to retain, it is not recommended that you use instance backed storage for this data. Instead use EBS volumes for persistent data storage. Unlike EBS volumes, you are unable to detach instance store volumes from the instance.
6 ) Security
Security is fundamental with any deployment, and in creating an EC2 instance, you’ll be tasked to select a security group for your instance.
A security group is essentially a firewall for your instance, allowing you to restrict what traffic, from both an ingress and egress perspective, is allowed to communicate with it. You can restrict this communication by source, destination, inbound and outbound rules, along with which ports and protocols can be used.
At the very end of your EC2 instance creation, you will need to select an existing key pair or create and download a new one. A key pair, as the name implies, is made up of two components: a public key and a private key. The function of the key pairs is to encrypt the login information for Linux and Windows EC2 instances and then decrypt the same information, allowing you to authenticate onto the instance.
The public key encrypts data such as the user name and password. For Windows instances, the private key is used to decrypt this data, allowing you to gain access to the login credentials, including the password. For Linux instances, the private key is used to remotely connect onto the instance via SSH. The public key is held and kept by AWS. The private key is your responsibility to keep and ensure that it is not lost.
When you create your EC2 instance, you are given the opportunity to download the key pair. Once you have done this, you must keep that file safe until you are ready to log on to the associated EC2 instance. It’s worth noting that you can use the same key pair on multiple instances. Once you have authenticated onto the EC2 instance the first time, you can then set up your own local authentication methods, such as local Windows user accounts, allowing other users to connect and authenticate to it or even use Microsoft active directory.
It is your responsibility to maintain and install the latest OS patches and security fixes released by the OS vendor.
7 ) EC2 Status checks
From within the EC2 dashboard once you have launched your instance, you can view status checks. These status checks are used to check the health and status of your EC2 instance, and understanding what common faults could trigger these checks to fail can help you troubleshoot issues with your EC2 resources. There are two types of status checks:
Common issues that trigger system status checks to fail are loss of power, loss of network connectivity, and hardware and software issues on the underlying host. Basically, a system status check failure is out of your control as the fault lies with the components that AWS are responsible for. The best way to resolve this would be to stop the instance and restart. This is likely to cause the instance to launch on another physical host, resolving the issue. Do not reboot the instance, as this will cause the instance to continue running on the same physical server.
Instance status is something you need to fix. This check looks at the EC2 instance itself, rather than focusing on the underlying host. Common issues that trigger an instance check to fail, are incorrect network configurations, corrupt file systems, exhausted memory, or an incompatible kernel. These faults will require you to troubleshoot and resolve the issue.
