What is Elastic Cloud Compute (EC2)
EC2 stands for Elastic Compute Cloud. The service provides virtual servers in the cloud and is extremely scalable, meaning that it can grow with your business and can help reduce the amount of traffic forecasting required as it can scale up and down to cope with traffic demands.
Where does EC2 fit in your environment?
EC2 instances sit within the VPC and work in conjunction with a number of other services within the VPC. They’re protected by the NACL and and have their own security groups, which we will discuss through this section.
They are also protected via IAM policies and they are able to assume IAM roles to access other AWS services.
The below shows the different components of an EC2 instance. Each of these will be covered in detail below.
By default, all EC2 instances are launched with a private IP address. This enables them to communicate with other instances within the same VPC.
If your subnet settings allow for it, an instance can also be launched with a public IP address – which is only static for the life of the instance. To create an IP address that is always static, we can use an elastic IP.
An elastic IP provides you with a static public IPv4 address.You can attach an elastic IP to an instance, even if the instance only has a private IP address. Note: if an instance does have a public IP address already, the elastic IP will replace its default public IP address.
Elastic IP’s can be used to mask the failure of an instance. You do this by removing the IP from the failed instance & quickly remapping it to another, working instance in your account.
Security groups work on the instance level. They’re relatively similar to Network Access Control Lists in the sense that you can configure rules to allow certain types of traffic.
There are noticeable differences between a NACL and a security group:
- You can apply one or more security groups to an instance
- Security groups only support allow rules
- Security groups are stateful
- All rules are evaluated before a decision is made
- All traffic is denied, unless there is an explicit allow rule.
|Side Note: |
Note, that all inbound traffic is denied and all outbound traffic is allowed by default.
What does it mean to be stateful? Well, let’s say you allow inbound SSH traffic to your instance and that traffic requires a response from your server but you do not have SSH allowed in the outbound rules of your security group – it will still allow you to send the response. This is not true with NACL’s.
The default security group has all inbound and outbound traffic allowed by default.
There are a number of different instance types which are used to carry out different kinds of tasks in AWS.
|T2||General Purpose||Burstable Performance|
|M3||General Purposes||Nice Balance|
|C3/C4||Compute Optimized||High Traffic Web Servers|
|D2||Storage Optimized||Large Scale Data Warehouses|
|I2||Storage Optimized||Large Scale Data Warehouses|
|G2||GPU Optimized||Machine Learning / High Perf DB|
|P2||GPU Optimized||Machine Learning / High Perf DB|
|R3/R4||Memory Optimized||Databases / Large Enterprise Apps|
|X1||Memory Optimized||Databases / Large Enterprise Apps|
Amazon Machine Image (AMI)
Amazon Machine Images are pre-configured packages that provide the necessary information for an instance to launch. This information includes the operating system (of your choice), preinstalled software packages (like NGinx web server), the EBS (HDD) mapping and any other settings that are defined in the AMI.
There are three types of AMI:
- Community AMI’s – these are free to use but are generally limited to just operating system choice
- Marketplace AMI’s – these are more complex and include the operating system and other supporting packages (often licensed software). These are AMI’s which you must pay to use
- My AMI’s – these are the AMI’s you create and save on your AWS account
AMI’s can be used with auto scaling to launch pre-configured instances to meet demand or for disaster recovery purposes.
AWS uses two types of virtualization:
- HVM – this runs directly on the virtual machine as if it were running directly on the underlying hardware. It can take advantage of hardware extensions like enhanced networking.
- PV – can run on hardware that does not have explicit support for virtualization. However, it cannot take advantage of hardware extensions. HVM is the preferred option of virtualization in the AWS environment.
When you launch an instance, you can add your own bash scripts under the advanced details section. For example:
Yum update -y
Yum install -y httpd
Service httpd start
This would mean that your instance would be launched with HTTPD (Apache Web Server) already installed. You can view the scripts that ran on instance launch by using a curl command in the terminal:
You can also view the metadata using:
We call these bash scripts ‘bootstrapping’ your instance. It’s very useful in an autoscaling environment as you can script the instance to install Apache and download your website files during launch – meaning the instance is up and usable quickly – almost like a cookie-cutter for future instances that are launched.
EBS (Elastic Back Store) Volumes
Elastic Block Store (EBS) is block level storage on EC2 instances. It’s Network Attached Storage (NAS) and can be moved between instances with ease. It’s highly available and reliable storage and can be attached to any running EC2 instance in the same Availability Zone and can only be attached to a single EC2 instance at any given time.
EBS volumes can persist independently from the life of the instance. To do this, you’ll need to uncheck the box that says ‘delete on termination’ during the creation of your EC2 instance.
The achievable IOPS & storage space on each varies across different storage types. IOPS are measured in 256KB chunks:
|General Purpose||Ideal for test environments or small database instances. These achieve 3 IOPS per GB of provisioned storage. These drives do have burstable performance. |
For example, when you see 100/3000 IOPS when choosing your storage medium, this means you’ll have 100 IOPS, burstable to 3000 for short periods of time. Disk sizes are between 1GiB and 16GiB in size.
|Provisioned IOPS||Ideal for mission critical applications which require sustained performance. You can provision up to 20,000 IOPS. Disk sizes are between 4GiB and 16 GiB|
|Magnetic||Ideal for applications where performance is not at all important. These are extremely low cost but rarely utilized.|
|Side Note: |
Even volumes with provisioned IOPS may not provide the performance you expect. To achieve optimal performance, you should utilize EBS optimized instances which provide additional dedicated throughput for your EBS volume.
EC2 instances must have a root volume. You can add additional volumes to your EC2 instance and can move volumes between instances in the same availability zone.
You can use snapshots to backup or duplicate your EBS volumes. You can restore a backup by creating a new EBS volume, using the snapshot as a template. However, if you are to create an EBS volume from a snapshot, you must be aware that you will have a degraded performance (of up to 50%) until all the storage blocks on the EBS have been read – you can do this manually to achieve ‘normal’ performance levels.
Facts about snapshots;
- Snapshots are only for EBS volumes and do not apply to instance store volumes
- They’re incremental in nature – they only store the changes since the last snapshot
- If the ‘original’ snapshot is deleted, all data is still accessible, even though they’re incremental in nature
- Frequent snapshots increase durability and are therefore recommended for any environment
- Snapshots can degrade performance while they’re being taken. So if possible, these should be scheduled for non-peak hours
Instance Store Volumes
Unlike EBS, instance store volumes are physically attached to the host hardware running the instance. These drives hold ephemeral data – that means, the data on the drive exists for only the life of the instance. When the instance is stopped, shut down or terminated the data is erased. However, if the instance is rebooted, the data remains.
There are a few primary purchasing options for EC2 instances. They are described below:
|On Demand||The on-demand instances can be provisioned or terminated at any time you choose. You can choose to launch any instance type at any time. You are only charged while the instance is running.||High||High|
|Reserved||Reserved instances are cheaper than on-demand instances. This is because you commit to paying for a reserved instance for one or three years. Whether you use the instance or not, you are still liable for the costs.||Medium||Medium|
|Spot||Spot instances allow you to bid on instances that you want. For example, if you would usually pay $3 an hour for a specific EC2 instance, you could bid $1 per hour. If the price in the marketplace drops to your desired cost, you will be automatically provisioned the instance. |
As soon as the cost rises above your bid again, you will immediately lose your instance. You cannot guarantee you will have the instance for any specified length of time.
Placement groups are AWS’ answer to a big cloud problem. Let’s say, you need 10 instances and they all need to have extremely quick connectivity to one another? If it were in your own data centre, you’d put them right next to one another.
Well, AWS allows you to do the same. You can request that all your instances are put as physically close to one another as possible & you can utilize the low-latency 10Gbps link between those instances.
Now, all the instances you add to a placement group must be part of the same Availability Zone (AZ) and they MUST have enhanced networking (you can choose this at instance type selection).
- If an instance in a placement group is stopped, it will remain part of the placement group once it is restarted
- It’s suggested that you launch all your required instances into a placement group in a single request. This improves the chances of your machines being physically close to one another
- All instances in the placement group should ideally be the same instance type
- Instances that aren’t launched into a placement group can’t be added into one
- Placement groups cannot be merged together, cannot span multiple availability zones but can be connected
- Placement group names must be unique in your own AWS account
|Side Note: |
It is possible that if you add instances to your placement group at a later date, you’ll get an ‘insufficient capacity’ error. This can usually be resolved by stopping all instances in the group & starting them again.
Elastic Load Balancer (ELB)
The Elastic Load Balancer (ELB) evenly distributes traffic between EC2 instances that are associated it – across multiple availability zones. This enables us to build fault tolerance into our applications.
Further to balancing load, the ELB is able to identify unhealthy instances & stop serving traffic to them automatically. It’ll only start serving traffic back to that instance once it’s deemed to be healthy again.
It does this through health checks – using thresholds (the number of health checks which must be passed / failed for an instance to be deemed healthy / unhealthy) to assess the instances health.
You are charged for each hour (or partial hour) that you use the elastic load balancer and for each GB of transfer through the ELB.
An SSL certificate can be applied directly to the ELB, which reduces compute load on the EC2 instances.
|Multi-AZ load balancing not working||You’ll need to ensure that cross-zone load balancing is selected under the load balancer details tab.|
|Instances are healthy but ELB is not registering them||If this happens, ensure that the health check ping protocol is correct. If you are pinging on port 80, then that port will need to be allowed in your security group.|
|Access logs on web servers show IP of ELB not the source traffic||You can enable access logs to S3 under the details tab of the ELB|
|Unable to add instances to the ELB||The availability zone/ subnet in which your instances sit must be added to the ELB config under the instances tab.|
|Web traffic all show source IP of the ELB||Enable access logs on the ELB and store them in an S3 bucket.|
Autoscaling is the process of adding or removing EC2 instances to meet peaks in demand. It essentially ensures that the correct number of EC2 instances are available to serve all of your users / system processes, preventing a single instance from becoming overloaded.
There are two major components to autoscaling:
- Launch configurations: are effectively templates of the instance you wish to launch. You select the AMI, size & type of instance and have the opportunity to enter your own bash scripts for configuration on-launch.
- Autoscaling groups: these are the rules or settings (based on Cloudwatch metrics) that determine when an instance is added or removed.
You can configure notifications to go to SNS topics when an autoscaling rule is put into effect (adding / removing an instance).
If an instance is unhealthy, the ELB will remove it from service & the autoscaling group will replace it with a new, healthy instance. We call this ‘self healing’.
For an environment to be considered highly available and fault tolerant, it must have an elastic load balancer, serving traffic to an autoscaling group with a minimum of 2 EC2 instances in different availability zones.
|Autoscaling instance launches & terminates in short intervals||Your scale up and scale down thresholds in your autoscaling policies are probably too close together.|
|Autoscaling not happening||Check that you’ve not reached the max number of instances that you defined when setting up the autoscaling group.|
|Connectivity Issues||You’ll need to ensure that the correct security group ports are opened for your instance.|
|Cannot attach an EBS volume||Remember, an EBS volume must live in the same availability zone as the instance it’s attaching to. You can recreate an EBS volume by taking a snapshot & launching a volume in a new availability zone.|
|Cannot launch additional instances||You may have reached the AWS limit for EC2 instances on your account. You can check your limits under the ‘limits’ navigation item of the EC2 dashboard. You can request an increase in your limit from AWS.|
|Unable to download updates to your instance||You’ve probably launched your EC2 instance into a private subnet OR into a public subnet which does not auto-assign a public IP.|
|AMI unavailable in other regions||AMI’s are available only in the region they’re created. However, they can be easily copied to a new region.|
|Capacity error when launching into a placement group||This is a common error – it generally means that AWS can’t provision more instances close by to the existing instances in your placement group. To fix this, try stopping & starting all instances in the placement group.|