AWS Certified Solutions Architect — EC2

Amazon Elastic Compute Cloud (EC2) provides scalable computing capacity in the cloud. EC2 is one of the most used services inside AWS, enabling its users to eliminate the upfront cost that comes in acquiring hardware. Running virtual environments, known as instances inside of EC2, is the equivalent of having an actual hardware, with the advantage of scaling in and out with just a few changes on AWS.

Instances

Instances are the core of EC2. They are virtual environments that run an operating system and behave like any computer we know. Instances can be in three different states:

• Running: when an instance is active and can be accessed per defined policies
• Stopped: the equivalent of having your computer turned off. The instance is still there, but we cannot access until we start it again.
• Terminated: the instance was removed from EC2 and cannot be accessed anymore

We only have costs when an instance is running. This means that if we stopped an instance we don’t pay anything until we decided to start it again. It is important to notice that the volume associated with the instance will be charged normally, though.

We can assign a public IP to an instance to make it available on the internet. If we choose this option from the EC2 launch wizard it will work just fine, but be careful: if we reboot or stop or instance there is no guarantee that the public IP will remain the same. Actually, the chance of getting a different public IP when the instance starts again is very high. If we need to have a fixed public IP we need to allocate an Elastic IP. An Elastic IP is a public IP address that will remain with us until we release it and can be allocated to be used on an EC2 instance. In this case, even if the machine is stopped, reboot or even terminated we still maintain the public IP address on our control.

Types of instance

Instances can have different computational power. If we want to run a small application that is going to be used only for a few people it seems more logical to buy an instance that doesn’t have many vCPU or GBs of memory available, since it would be overkill. The same applies to a bigger application, that it is used for lots of people: we expect a powerful machine to handle this kind of situation.

AWS has different instances to different use cases. There are five different families of instances available, each one optimized for a specific case:

• General Purpose: instances that provide a good balance between CPU performance, memory, and network resources.
• Compute Optimized: instances with the lowest price/compute performance ratio.
• Memory Optimized: instances with the lower price per GB
• Accelerated Computing Instances: instances optimized for graphics-intensive applications
• Storage Optimized: instances that deliver a higher I/O performance

Each family has many types of instances to choose. Types will basically differ from each other based on the hardware they run. Besides hardware difference, there is the T2 type, which is a type of instance that it’s called burstable. T2 belongs to the General Purpose family and will accumulate CPU power if it is on idle, which can be used later if it is needed. This is an ideal scenario for applications that have usage peaks in some period of the day and are not frequently accessed in others. Using a T2 instance allows the application to burst performance when needed, reducing the cost of having to launch another instance for these specific periods of time.

Payment options

Instances have some big advantages when compared to buying hardware: we only pay for what we actually use, we don’t have to worry about buying instances days or months in advance since everything we need to launch a new instance is some clicks. We don’t have to worry about the costs of hardware maintenance as well.

Despite looking a very optimized way of reducing costs already, we can reduce it even further inside AWS. Choosing the right type of payment can have a big impact on the final cost, so knowing the options and when to use them becomes very important. AWS has three types of instances that can be bought: on-demand, reserved and supported instances.

On-demand instances are the default option when going into EC2. As the name suggest they are charged on-demand: if we’re using the machine we are paying for it, otherwise, we are free of charge. The big advantage that on-demand instances bring is that we don’t have any ties with Amazon. If we decide to buy or own hardware and move from there we can do it right away. Since this model is the one which gives more freedom, this is also the model with the more expensive price.

What happens if the company decides that AWS is the place to host their applications for a long time? In this case, it is possible to use reserved instances. Reserved instances guarantee that we’ll have it available for the chosen period of time. As of today, we can choose to reserve an instance for one or three years. We also can choose how much money we want to put up in front. The more the money we pay right away the cheaper the instance becomes. It is possible to get up to 60% of discount in this model, so when we’re planning to stick with AWS for some time this option becomes very attractive.

Buying reserved instances also guarantee higher priority: if AWS runs out of an instance type, who already reserved it will have it guaranteed, while those who chose on-demand will be left behind. Although we cannot change the type of instance we are allowed to change its sub-type: if we reserved a t2.medium we can change it to a t2.large, but we cannot change it to an m4.large. What happens if we want to change the instance type or we don’t want or reserved instance anymore? We can sell it on AWS. The instance will be available to be bought and as soon as someone buys it we don’t have to pay it anymore.

The last model of payment is spot instances. They allow us to bid on spare compute cloud time. They are very cheap instances compared to the on-demand model and are a very good option to run processes that can be interrupted. This type of instance should never run in a production environment since Amazon can take it back anytime they want to. This will happen when the computational power that was unused starts to be used again.

Storage

Just like in a computer we have at home EC2 instances have a disk to store data. These disks are called volumes inside AWS and are available in two different options: root volumes and Elastic Block Store (EBS) volumes. Root volumes are an EBS volume like the other ones, but they are used to run the operating system on the EC2 instance. They can have other configurations along with the OS, but they cannot be encrypted, which means that sensitive data you want to protect to be compliance with shouldn’t be placed on them. Root volumes are build from an Amazon Machine Image (AMI), which contains the software configuration that the user wants to run.

Elastic Block Store

EBS Volumes provides persistent data block storage volumes. To improve durability, an EBS volume will be replicated through the availability zones of the region. EBS volumes outlive the instance they were created, which means we can attach it to another EC2 instance after having the original terminated. It is important to notice that we cannot attach the same EBS volume in two instances at the same time. On the other hand, it is possible to have many volumes attached to one instance. EBS volumes are created in a specific availability zone and can only be attached to an EC2 that is in there as well.

EBS are measured by IOPS, the input/operations per second that go through the disk. Each IOP is 256 KB or smaller. If an operation greater than 256 KB is sent to the disk it will be divided in more than one IOP. For instance, if a 512 KB read is performed, two IOPS are counted in that second. EBS volumes can be created in three different types:

• General Purpose SSD: this option provides an SSD to store our data. It is usually used on dev/test or applications that don’t have a big amount of disk usage. As happens to the EC2 t2 instance, the General Purpose SSD has burstable performance: if we don’t use all of our IOPS in a second it will accumulate to be used later. The IOPS can accumulate up to 3000. Each GB of disk will grant us 3 IOPS, with the minimum of IOPS-guaranteed to be 100. This SSD has a minimum size of 4 GiB and a maximum size of 16 TiB
• Provisioned IOPS SSD: this option also provides an SSD to store data. The difference between this and the General Purpose SSD is the burstable performance. When choosing Provisioned IOPS we reserve a number of IOPS and pay for it, but they’ll be guaranteed regardless of disk size. This means we can have a 100 GiB disk and acquire 1000 IOPS at the same time. The main use of this option is when we know that our application will load or write big amounts of data and we want to ensure we have the right performance. The minimum and maximum size are the same as the General Purpose SSD: 4 GiB and 16 TiB, respectively.
• Magnetic: option that allows us to reduce costs. Should be used when performance it’s not important or when data is rarely requested. Since it is an option that usually doesn’t meet the requirements of a production environment the max size of the disk is limited as well: the minimum size of the disk is 1 GiB and it only allows us to create a 1 TiB disk at most.

Snapshots

To increase data durability we can take snapshots of our EBS volumes. They can serve as a backup, allowing to reverse some change that breaks our system. They can also be used to create AMIs of customized data, making it easier to configure instances with all requirements that the company needs to fulfill. For instance, we can run a basic Amazon Linux AMI, install and configure our applications, take a snapshot and make an AMI from it. The next time we need to launch an instance to run our application we can just select the AMI we just created and everything will be configured when the instances launch.

Snapshots are stored in S3, which means they are very durable. We cannot access it using our S3 account, though. If we take a snapshot it will only be available through EC2 Snapshots, none of our buckets will be used to store them, only Amazon have access to it. Another important aspect of Snapshots is that we only pay for the data one time. The first snapshot will store all the data inside the disk and the following ones will only store the difference between them and the previous one. If we take 10 snapshots without any change we’ll pay only for the price of the first one. It is important to notice that snapshots degrade the instance performance and should be taken in non-peak periods of time.

Elastic Load Balancer

The Amazon Elastic Load Balancer is used to balance traffic across EC2 instances, aiming for high availability and fault tolerance. We can use them as public load balancers, that will be reachable on the internet, as well as internal load balances, which will be only used inside our network.
When creating a load balancer we choose the ports that it will listen to. All incoming from these ports will be passed to the target group. We also have to choose at least two subnets, so if something happens with one of the AZ we still can route the traffic to the other one.

A target group is a group os EC2 instances that will receive the request from the load balancer. We define in which port the request should be received and then we pass it to one of the instances. When defining the target group we must choose a port and a path to AWS perform a health check. A health check pings the given path/port. If it receives a response the instance is considered healthy, otherwise, the instance will be removed from the ELB. The options regarding health check are:

• Healthy threshold: how many times a request has to succeed before the instance is considered healthy
• Unhealthy threshold: how many times a request has to fail before the instance is considered unhealthy
• Timeout: how many seconds should the ELB wait for the response
  Interval: how many seconds should be between requests
• Success codes: the HTTP code which should be returned to a request be considered successful

The ELB uses round-robin to send user requests to the target group. If a target group has 3 instances names instanceA, instanceB, instanceC, and receive four requests, the ELB will send them to instanceA, instanceB, instance and instanceA, respectively.

Amazon has two kinds of ELB available: Classic Load Balancer and Application Load Balancer. The Classic Load Balancer has all the features mentioned in this section. It was the original ELB and it is still available for use. The Application Load Balancer has the same functionalities than the Classic, and also allows making more complex decisions, such as Content-Based routing.