Working with AWS EC2 burstable Instances

Technically incline folks may choose to use the “free” tier for the first 2 months from the AWS lightsail. Free comes at a cost of burstable CPU consumption. User of lightsail needs to get familiar with the overview of the Average CPU Utilization and Remaining CPU burst capacity as shown in the screenshot below.

Once the AWS EC2 burstable instance started, AWS will add a small amount of burstable credit as long as the EC2 instance CPU usage are not exceeding 10%. If deployment of software into the instances uses CPU exceeds 10%, the CPU burst capacity will be deducted. Remaining CPU burst at 0% capacity will cause capping of the performance for the EC2 instance.

In order for the CPU burst capacity the build to 100%, the EC2 must CPU utilization must not exceed 10%. This will the CPU burst capacity to accumulate to 100% capacity, over the period of 27 hours.

Therefore, before developers or system architects needs to understand this feature of EC2 burstable CPU, allow ample time for the CPU burst capacity to build up. In real world, when deploying applications, the software provisioning may utilized all the CPU burst capacity and causes bad user experience of software performance in the AWS cloud. If I were to be an enterprise solutions architect, I would not use EC2 that has burstable CPU capacity.

How to custom install AWSCli into linux based machine

Quote

Good new for AWS users, Amazon has release the new unified AWSCli was released in September 2013. Amazon did provide multiple ways to have the new AWSCli installed.

I have to admit the task of installation is more straight forward and simplified compared to the old AWS Cli.

At the time of this post, the AWSCli released version 1.2.6, and it runs on Python 2.6. Hence, this post will provide custom install of AWSCli into linux based machine.

For users who are planning to use the AWSCli bundle provided by Amazon here is the recommended steps in sequence. Disclaimer and note : I have not added any form of error catching or linux distro detection and I am assuming the linux distro used is redhat.

Installing AWSCli using the Amazon awscli-bundle

mkdir -p /opt/apps/tmp
cd /opt/apps/tmp
wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
unzip awscli-bundle.zip
mkdir -p /opt/apps/$(ls awscli-bundle/packages/ | egrep -o 'awscli-[0-9]\.[0-9]\.[0-9]')
./awscli-bundle/install -i /opt/apps/$(ls awscli-bundle/packages/ | egrep -o 'awscli-[0-9]\.[0-9]\.[0-9]')
/opt/apps/awscli/bin/aws --version
ln -s /opt/apps/$(ls awscli-bundle/packages/ | egrep -o 'awscli-[0-9]\.[0-9]\.[0-9]') /opt/apps/awscli
ln -s /opt/apps/awscli/bin/aws /usr/bin/aws
ln -s /opt/apps/awscli/bin/aws.cmd /usr/bin/aws.cmd
cd ~
rm -Rf /opt/apps/tmp

Installing AWS via pip

python --version
apt-get install python-pip
yum install python-pip
cd /opt/apps/
mkdir tmp
cd tmp
wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py
wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py
python ez_setup.py
python get-pip.py
pip install awscli==1.2.6
aws help
cd ~
rm -Rf /opt/apps/tmp

The advantage of AWSCli bundle over the pip method is, ease of install without need to get ez_setup and pip installed. Since the AWSCli bundle zip is hosted within Amazon Web Service network, it took me less than 1 seconds to download the 5MB AWSCli-bundle.zip file.

[root@ip-10-255-255-1 ~]# time wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
--2013-11-28 05:25:16-- https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
Resolving s3.amazonaws.com... 176.32.99.46
Connecting to s3.amazonaws.com|176.32.99.46|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5139105 (4.9M) [application/zip]
Saving to: `awscli-bundle.zip'

100%[================================================================================================================
===================================================================================>] 5,139,105 16.0M/s in 0.3s

2013-11-28 05:25:17 (16.0 MB/s) - `awscli-bundle.zip' saved [5139105/5139105]
real 0m0.611s
user 0m0.096s
sys 0m0.036s
[root@ip-10-255-255-1 ~]# time wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
--2013-11-28 05:25:49-- https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
Resolving s3.amazonaws.com... 176.32.99.46
Connecting to s3.amazonaws.com|176.32.99.46|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5139105 (4.9M) [application/zip]
Saving to: `awscli-bundle.zip'

100%[================================================================================================================
===================================================================================>] 5,139,105 19.6M/s in 0.2s

2013-11-28 05:25:49 (19.6 MB/s) - `awscli-bundle.zip' saved [5139105/5139105]
real 0m0.338s
user 0m0.076s
sys 0m0.036s

The downside of using the awscli bundle installation is users need to upload the awscli-bundle.zip into personal version control servers/services (such as github) in order to have version control of awscli. Therefore, there will be overhead of maintaining the version of the awscli and it will be labor intensive or makes processes complicated.

The only disadvantage of pip AWSCli is the pre-requisite of installing pip. And maybe in the future, would be a permanent removal of older awscli version from the pip public repository.

Administrator using pip will be able to make awscli to be installed into a customed directory such as /opt/apps by using the following pip command

pip install --install-option="--prefix=/opt/apps" awscli==1.2.6

Unfortunately, in doing so pip will no longer able to manage the awscli package. Administrators will need to have a small effort to remove the installed version manually before upgrading the AWSCli using the similar command.

As a closing, to my personal opinion pip is a better way to install and maintaining the version of AWSCli.