Resources referenced within this lecture:

• Lab: Create your first Amazon EC2 Instance (Windows) 
• Lab: Create your first Amazon EC2 Instance (Linux)

Transcript

Helo, and welcome to this lecture where I will explain what the EC2 service is and does, and how to configure an EC2 instance. Let's get started. As EC2 is one of the most common services used throughout AWS, I want to discuss this service in great detail over the other services that I'll cover in this course. EC2 is the most common compute service that AWS offers as it allows you to deploy virtual service within your AWS environment, and most people will require a server in one form or another as a part of their solution. There are a number of elements in creating your EC2 instance, which I want to break down and explain.

This will hopefully help to define how the service works, and answer a number of questions that you may have. The EC2 service can be broken down into the following sections: Amazon Machine Images, AMIs, instance types, instance purchasing options, tenancy, user data, storage options, and security. The first point I want to cover are AMIs, Amazon Machine Images. These are essentially templates of pre-configured EC2 instances, which allow you to quickly launch a new EC2 instance 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 to Red Hat to Microsoft Windows among others. You could also select an AMI from the AWS Marketplace. The AWS Marketplace is basically an online store that allows you to purchase AMIs from trusted vendors like Cisco, Citrix, Alert Logic, et cetera. These vendor AMIs may have specific applications and configurations already made such as instances that are optimized with built-in security and monitoring tools or contain database migration systems. Lastly, community AMIs also exist, which are a repository of AMIs that have been created and shared by other AWS members.

Let's now take a look at 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. General purpose.

Instance types within this family have a balanced mix of CPU, memory, and storage making them ideal for small to medium databases and test and development service and back-end service. Compute optimized. As the name implies, instance types within this family have a greater focus on compute. They have the highest performing processes installed allowing them to be used for high performance front-end service, web service, high performance science and engineering applications, video encoding, and batch processing. GPU. GPU stands for graphics processing unit, and so, the instances within this family are optimized for graphic-intensive applications. Memory optimized. Instance types here are primarily used for large-scale, enterprise-class, in-memory applications such as performing realtime processing of unstructured data or for in-memory databases such as SAP HANA.

Storage optimized. As expected, these are optimized for enhanced storage. Instances in this family use SSD-backed instance storage for low latency and very high input/output performance including very high IOPS, which stands for input/output operations per second. These are great for analytics workloads, and NoSQL databases, data file systems, and log processing applications. You can purchase EC2 instances through a variety of different payment plans. These have been designed to help you save cost by selecting the most appropriate option for your deployment. The different EC2 payment options are as follows: on-demand instances, reserved instances, spot instances, dedicated instances, and dedicated hosts.

It's good to be aware of these different options as by having an understanding of these can help you save a considerable amount of money depending on your use case. Let me run through each option to help explain starting with on-demand instances. These are EC2 instances that you can launch at any time, and have it provisioned and available to you within minutes. You can use this instance for a shorter time or for as long as you need before terminating the instance.

These instances have a flat rate, and is determined on the instance type selected, and is paid by the hour. On-demand instances are typically used for short-term uses where workloads can be irregular, and where the workload can't be interrupted. Many users of AWS use on-demand instances within their testing and development environments. 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. Further reductions can be achieved with reserved instances depending on which payment methods you select.

There are three options available to you. All upfront, the complete payment for the one or three-year reservation is paid. This offers the largest discount, and no further payment is required regardless of the number of hours the instance is used. Partial upfront, a smaller upfront payment is made, and then a discount is applied to any hours used by the instance during the term. No upfront. No upfront or partial payments are made, and the smallest discount of the three models is applied to any hours used by the instance. 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 be 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 will purchase that instance, but as soon as 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 the 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 being 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 have stopped or terminated the instance. Let me now talk to you about EC2 tenancy. This 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. Shared tenancy. This option will launch your EC2 instance on any available host with the specified resources required for your selected instance type regardless of which other customers and users also have EC2 instances running on the same host, hence, the shared tenancy name. Advanced security mechanisms are in place within one EC2 instance access in another on the same host. How the security is applied and operated is out of scope for this course, and is maintained by AWS themselves. Dedicated tenancy includes both dedicated instances and dedicated hosts. Dedicated instances are hosted on hardware that no other customer can access.

It can only be accessed by your own AWS account. You may be required to launch your instances as a dedicated instance due to internal security policies or external compliance controls. Dedicated instances do incur additional charges due to the fact you are preventing other customers from running EC2 instances on the same hardware, and so, there will be unused capacity. Dedicated hosts. Dedicated hosts are effectively the same as dedicated instances, however, they offer additional visibility and control over how you place your instances on a physical host. This allows you to use the same host for a number of instances that you want to launch. Also, dedicated hosts allow to align with any compliance and regulatory requirements.

If you do not need to address any compliance issues that require dedicated tenancy, then I recommend using shared tenancy to reduce your overall costs. 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 and ephemeral, which is temporary storage. Persistent storage is available by using elastic blob storage, EBS volumes, and ephemeral storage is created by some EC2 instances themselves using local storage on the underlying host known as instance back storage. Let's look at each of these storage options in greater depth. EBS volumes are separate devices from the EC2 instance itself, and so, it is not physically attached like ephemeral storages.

EBS volumes are considered network-attached storage devices, which are then logically attached to the EC2 instance via 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 external disk is separate from your own computer's in-dock hard disk, and is instead attached via a cable whereas this would be reflected as the AWS network, which are an EBS volume and an EC2 instance. The data on these volumes are 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 with 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 volume can be created in different sizes again with different performance capabilities depending on your requirements. Ephemeral storage or instance back storage is storage that is physically attached to the underlying host on which the EC2 instance resides on. Looking back at our previous example, this would be similar to your own laptop or PC's 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 back 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.

Security is fundamental with any deployment, and so, I just want to highlight a couple of points relating to security around EC2. Firstly and during creation of your EC2 instance, you will 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. More information on security groups can be found in my previous blog found here covering instance level security. Before we move on from EC2, I just want to point out one last item relating to the status checks that you can see from within the EC2 dashboard once you have launched your instance.

These status checks are used to check the health and status of your EC2 instance, and understanding what common faults to trigger these checks to fail can help you troubleshoot issues with your EC2 resources. There are two types of status checks: system status checks and instance status checks. Let's look at system status checks first. If this fails, then this is likely to be an issue with the underlying host rather than a configuration issue with your EC2 instance itself. 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 like to close 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. Let's now take a look at the instance status checks. These differ from system status checks as if this fails, then it will likely require your input to help resolve the issue. This check looks at the EC2 instance itself rather than focusing on the underlying host.

Common issues that trigger this check to fail are incorrect network configuration, corrupt file systems, exhausted memory, or an incompatible kernel. These faults will require you to troubleshoot and resolve the issue, for example, change in the network configuration. That brings us to the end of this lecture on EC2. Like I mentioned previously, this was going to be the longest and the most in-depth lecture simply due to this being a key compute service. If you would like some hands-on experience with EC2, then we do offer two labs in which you can practice creating your own EC2 instances for both Linux and Windows. Coming up in the next lecture, I will discuss elastic load balancing and auto scaling.