Amazon EC2
After a several-month break from writing about AWS, I’m back for more posts. Since my last AWS post, I’ve been busy working on a MERN-stack application, starting a new job as a Software Engineer with Roll Call (a FiscalNote company), and putting the finishing touches on my debut album plus starting the second album. Now let’s get into this comprehensive post on EC2!
| Soundtrack: Blinkhorn, “Sketch 9 | Entropy” |
EC2 Essential Information
EC2 is an AWS service for scalable virtual servers in the cloud. An individual EC2 server is called a “instance.” There are a variety of different instance types and sizes that fulfill various use cases. EC2 instances can run many different operating systems, but most are on some type of Linux or Windows.
You may be familiar with how on-site servers host web traffic. AWS EC2 instances are similar, but they offer more flexibility. Besides being located in AWS data centers instead of in a space you control, EC2 Instances can easily be spun up or terminated — this makes EC2 a good option if you’re looking for something scalable and elastic. There are specific details regarding EC2 components, but I intend to give a high-level overview of EC2 at this point of the post. You should note that similar to how you would configure a new computer based on what your needs for it are, you configure your EC2 instance(s) based on how you intend to use them.
You have several different buying options when it comes to EC2.
You can purchase your EC2 instance On-Demand, which is the most expensive option, but it is also the most flexible buying option since you can purchase any type of EC2 Instance and provision/terminate it at any point. When you purchase your instance On-Demand, you are billed for every second that your instance is running.
Another purchasing option you have for EC2 Instance is a Reserved Instance, in which case you are offered a considerable price discount if you keep your instance running for set time between 1–3 years.
If you purchase Spot Instances, you are able to bid on the price of your instance and you will only be charged when the “spot” price is less than or equal to your bid price. Spot Instances help AWS sell unused instances, and for that reason, they offer a significant discount for this buying option. Spot prices will vary depending on supply and demand, and similar to the On-Demand option, you are charged by the second for when your spot instance is running. While spot instances are provisioned for you when your bid price is greater than or equal to the spot price, once the spot price peaks above your bid price, your instance will be terminated; for this reason, Spot Instances are not a good option for production applications that you always need to keep running.
The final EC2 instance buying option is having a Dedicated Host, which is essentially a physical machine that you have full control over. It’s possible to save money on licensing fees and meet specific regulatory compliance requirements with this option.
With EC2, you are responsible for the software-level security on your instance, which includes security groups, firewalls, AWS-provided EBS encryption, and applying an SSL certificate to the ELB (Elastic Load Balancer). AWS is responsible for the hypervisor and physical layer of security for your EC2, which includes DDoS protection, port scanning protection, and ingress network filtering.
EC2 instances are primarily made up of an Amazon Machine (AMI), the Instance Type, the Network Interface, and storage. At a high level, the AMI deals with the instance operating system among other settings, the Instance Type dictates the compute power, RAM, network bandwidth, etc., the Network Interface specifies public, private, and elastic IP addresses, and storage is essentially the instance’s hard drive, which can be network persistent storage as Elastic Block Store (EBS), ephemeral storage as the Instance Store, or scalable, elastic file storage as an Elastic File System (EFS). Below I will address the technical aspects of the AMI, Instance Type, Network Interface, the Elastic Load Balancer (ELB), and storage for EC2 Instances.
Operating System | AMI
Amazon Machine Images (AMIs) are templates required to launch an EC2 instance and they include an operating system, software packages, and other required settings such as root storage and virtualization types. In the event of a disaster, AMIs are used with Autoscaling to quickly launch new servers on demand. You can pick an AMI from the AWS marketplace (these typically come packaged with additional licensed software), choose from a list of AWS or community provided AMIs, or you can create your own AMI.
Virtualization, which in the context of EC2 refers to using a portion of the instance’s processing power and storage to run an operating system, is included in the realm of AMIs. Virtualization in EC2 is run either by Xen Hypervisor software or the KVM-based Nitro Hypervisor; that said, AWS has migrated towards the Nitro Hypervisor. While you control the virtual machine(s) within your instance, it’s important to note that AWS still handles the maintenance of the physical server in addition to the hypervisor layer.
Hardware | Instance Type
EC2 instances may be comprised varying hardware component; specifically, the compute power (processor/vCPU), memory (RAM), storage (hard drive), and network performance (bandwidth will differ between the different EC2 Instance Types). Instance Types are grouped into five families: General Purpose, Compute Optimized, Memory Optimized, Accelerated Computing, and Storage Optimized.
The General Purpose family includes the T2, M5, M4, and A1 types. T2s feature burstable performance and are good for many purposes. M4 and M5s are good for small to mid-size databases, enterprise applications, and data processing. A1s can scale out workloads such as web servers, development environments, and containerized microservices.
C4 and C5 instance types belong to the Compute Optimized family. These types are high-performance web servers that are useful for science and engineering applications and ad serving.
R5, R4, X1, High Memory, and Z1d types belong to the Memory Optimized family. The types in the Memory Optimized family are ideal for high performance databases, in-memory databases, and large data processing engines.
The Accelerated Computing family contains P3, P2, G4, G3, and F1 instance types. P2s and P3s can be used for machine and deep learning, high performance databases, and server-size GPU compute workloads. G4s and G3s are a good choice for 3D visualizations and rendering, application streaming, video encoding, server-side graphics workloads, and machine learning inference for applications. F1s can be used for genomic research, financial analysis, big data, and security.
Finally, the Storage Optimized family is comprised of H1, I3, and D2 instance types. H1s and D2s are useful for MapReduce, HDFS, network file systems, and data processing applications. I3 instances can be used for NoSQL databases such as MongoDB, data warehouses, and Elastisearch.
Hard Drive | Storage & EBS Snapshot
EBS (Elastic Block Store) volumes are persistent, which means they can still exist even after the EC2 instance they are associated with is decommissioned. These EBS volumes are called network attached storage because they can be attached or detached to or from various EC2 instances, but they can only be attached to one instance at a time. The EBS volumes are backed up to a snapshot, which means they can be restored into a new EBS volume down the line. EBS volumes are replicated within their Availability Zone by default.
EBS input/output operations are measured in IOPS, which are input/output operations per second that AWS measures in 256 KB chunks or smaller. If the operations are greater than 256 KB chunks, they are measured in distinct 256 KB chunks. Your EC2 instances I/O performance is greatly influenced by the type of EBS volume you specify.
If you create an EBS volume from a snapshot, it must be initialized, which occurs the first time a storage block on the instance is read and can impact performance up to 50%. In production environments, you can avoid this performance impact by manually reading all the blocks.
There are several types of EBS volumes: General Purpose SSD, Provisioned IOPS SSD, Throughput Optimized HDD and Cold HDD, and EBS Magnetic.
General Purpose SSDs are often used for development or test environments and smaller database instances. The have a performance of 3 IOPS/GB of storage size and their storage size ranges from 1 GB to 16 TB.
Provisioned IOPS SSD volumes are typically used for mission critical applications that need sustained IOPS performance. They are good for large database workloads and range from 4 GB to 16 TB in size.
Throughput Optimized HDD and Cold HDD are cheaper than the SSD volume options but are also less performant. Cold HDDs are designed for infrequent usage. These options range from 500 GB to 16 TB in storage. Note that a Throughput Optimized HDD and Cold HDD cannot be a boot volume.
The EBS Magnetic volume option is low cost and can be used when performance is not a concern and data is infrequently accessed. These volume sizes are at a minimum 1 GB and at max 1 TB large.
EC2 instance store volumes are virtual machines whose hardware is attached to the host server on which EC2 instance is running. Since the data on the instance store volumes only lasts for the duration of the EC2 instance, the instance store volumes are considered ephemeral storage. The EC2 instance can be rebooted and the instance store volume will retain the data stored on it, but if the instance is shut down, the data on the instance store volume will be lost. Not all EC2 instance types can store instance store volumes.
As I alluded to above, one handy feature of EBS volumes is that you can take a snapshot of a point-in-time backup of an EBS volume and store it in S3. The snapshots are incremental in nature, so each snapshot only stores the differences from the previously stored snapshot. That said, if the original snapshot is deleted, all the data will still be available in the other snapshots. You can fully restore EBS volumes from the snapshots stored on S3. Keep in mind that when snapshots are being taken, they can degrade performance, so they should be taken in non-peak hours if possible.
Elastic File System
The Elastic File System (EFS) is a scalable storage option for EC2. The EFS storage is elastic, which means that the storage capacity will increase or decrease as you add or remove files. With EFS, your applications running on EC2 will always have the storage they need. All EFS maintenance is handled by AWS and you only pay for the amount of storage you are using.
EFS can be accessed by multiple EC2 instances at the same time, so all of your EC2 instances could access your EFS or applications spanning multiple instances can access the same data. EFS can be mounted to on-premises servers, which allows you to migrate data from on-premises servers to EFS or use EFS as a backup solution. EFS maintains low latency and high levels of throughput, even when scaling up to petabytes in size.
Considering security, you control the EFS through POSIX permissions. You can use a VPC for network access control and IAM for API access control with EFS. You can encrypt the data in your EFS with the AWS Key Management Service (KMS).
Use cases for EFS include big data & analytics, media processing workflows, and web serving and content management.
Load Balancing | ELB
Load balancing is a method used for distributing incoming traffic among servers. Elastic Load Balancing (ELB) is the EC2 service that automates the even distribution of traffic between instances associated with the ELB. The ELB can distribute incoming traffic to EC2 instances across multiple Availability Zones. By allowing an SSL certificate to be applied directly to an ELB, ELB’s can help reduce compute power on the EC2 instances associated with them.
You have three options when maintaining session state with an ELB:
- The ELB can issue the user a cookie if they don’t already have one and then the ELB will send the user to a specific instance based on their cookie.
- The ELB can use an application-generated cookie to associate a session with an instance and then the ELB sends the user to a specific instance based on that cookie.
- A caching service such as Amazon ElastiCache can be used to maintain session state, which is the recommended approach of these three options. In this option, ELB requests are evenly distributed among the instances. The instances then check the caching service for the session, and if no session exists in the caching service, the instance can check a backing database for the session.
Networking | IP Addresses
Whenever you create EC2 instances, they are given private IP addresses that are meant for internal communication between instances within a Virtual Private Cloud (VPC). Public IP addresses are required if you want your EC2 instance to have direct communication with the open internet. When creating your EC2 instance, you have the option to enable a public IP address for it.
Elastic IP Addresses (EIP) are static IPv4 addresses designed for dynamic cloud computing. EIPs are public, and with them, you can attach a public IP address to an EC2 instance that was created only with a private IP address or you can hide instance failure or software by quickly remapping the address to a separate instance in your account. When you attach an EIP to an instance, it replaces the instance’s default public IP address while the EIP remains attached.