Budget Update: 14/05/2017

At close on midnight last night, I received an AWS notification email, telling me that my EC2 budget had passed one of its limits. Since my last budget post, my activity with AWS has been within the CloudFormation services, which is free-tier.
Budget Alarm

 

To understand why I was being charged, I checked upon billing info. The results showed that I was still being billed for EBS services.
14_05_17 Bill Report

 

My conclusion was that I had not completely deleted my EBS volumes during my last attempt. In checking the EC2 service, I was proven right.
EBS Volumes

 

This time, I made sure to delete my EBS volumes, and stop the unnecessary credit charge.
Deleting EBS Volumes

 

My next budget update should only show purposeful charge, which I have initiated.

 

 

Budget Report 14/04/2017

I received another billing alarm last night, this time with respect to my EC2 budget.
EC2 Alarm Forecasted50

Upon further inspection, the source of expenditure was from AWS’ EBS service. This seemed strange to me as I haven’t used EBS during this DinoStore project.

In order to gain a greater understanding of my expenditure, I compiled my AWS bills into a spreadsheet.

Budget Spreadsheet

EBS charge for April has been $0.64

I originally thought that it was due to the MySQL RDS instances that I created for Lab 2, and considered that it may relate to the snapshots that I had created. The dates however, for the creation of the EBS volumes were all in March, and my RDS snapshots were created in April. Upon looking into greater detail of the EBS volumes, I was able to determine that they related to previous RDS instances that I had created for my QwikLabs project.

By looking into AWS’ documentation on EBS volumes, I was able to determine their use and their cost:

Device use:

Device Cost

My next step was to detach the EBS volumes in order to cease any further charge.
Detaching EBS volumes

As for my DinoStore budgeting; I have been using Free-Tier available services and so will not have incurred any other charges.

Introduction to Amazon Elastic Block Store (EBS)

Introduction and Aim
The purpose of this lab is to gain basic understanding and comprehension of what is the Elastic Block Store (EBS) in AWS.
The Amazon Elastic Block Store is a service that provides block level storage for both EC2 instances and the AWS Cloud. Block level storage volumes are replicated within their availability zone, the redundancy increases security from an AWS server failure, and ensures a constant low latency. EBS also allow for scaling up and down of usage in very short time frames.

Goals

  • Create an EBS Volume in the Amazon Management Console
  • Add an EBS Volume to an instance
  • Snapshot an EBS Volume

 

Creating an Elastic Block Store Volume
EBS Volumes are found within the EC2 service. QwikLabs describes EBS Volumes as ‘hard drives in a computer. The data on them persists¬† through the lifetime of the volume and can be transported between virtual machines as needed.’

On the side panel of the EC2 display, the EBS contains two options; Volume and Snapshot. When creating a volume, the region to contain the volume is important to consider as the volume is replicated within the region.
In the ‘Create Volume’ dialog box, the settings are:
(a). Type: General Purpose (SSD)
(b). Size (GiB): 1
Availability Zone: Sydney (The region in which my AWS server is set): ap-southeast-2a

Create Volume

The created volume is able to be attached to an instance. I will use the instance that I created for my Introduction to EC2 with Windows server lab.
InkedRunning Instance_LI

Adding an EBS Volume to an instance
If the state of the volume is ‘available’, then a running instance will be able to be attached to it.
Attaching Instance Cropped

 

Snapshotting an EBS Volume and increasing performance
QwikLabs explains that ‘a snapshot of volume replicates the data in the volume. It also allows you to change the properties of the volume to enable features like provisioned IOPS’.

In the 1GiB volume, I can right click and ‘Force Detach Volume’. The lab script makes mention that the instance would need to be stopped before doing this so as to not force detach the drive. However, in this lab, the instance will remain running as there isn’t anything of importance within it, and the lab is focusing more on what can be done with a volume rather than whether the order of actions on the volume would follow production protocol.
InkedDetaching Volume_LI

Once the volume is detached, I can right click and ‘Create Snapshot’.
I want to ensure that the screenshot dialog box contains the following settings:
(a). Volume field matches created volume
(b). Name Box: qlebslab
(c).Description: ql ebs volume snapshot
Create Snapshot

I can then create the snapshot which will be stored within Snapshot under Elastic Block Store.
Snapshot

Then I can right click the snapshot and ‘Create Volume’. I want the following settings to be set within the volume dialog box:
(a). Type: Provisioned IOPS (SSD)
(b). Size (GiB): 10
(c). IOPS:300
(d). Availability Zone: Sydney: ap-southest-2a

Create Volume through Snapshot

Under Volumes, the new volume is present and contains the same data from the original but is larger in size and has IOPS.
Final Volume

 

Conclusion
It seems to me that EBS could be a very useful storage scheme for businesses that require the security of the replicated data. However, if I were looking to start my own business, I would want to compare pricing vs storage amount as to whether this form of storage compared to S3 storage is worthwhile from a cost perspective.