AWS Certified Solutions Architect

AWS Certified Solutions Architect, Associate Level – Passed Today!

I just passed AWS’s Certified Solutions Architect – Associate Level exam – I hold certificate number “AWS-ASA-2564.” After completing the exam, I feel that passing AWS exam ensures that the test taker:

  1. has a knowledge of how most of the AWS services work.
  2. has a good idea of how to improve availability through architecture using multiple AZs.
  3. a good idea of what how Amazon wants you to architect and utilize their services.

Changing an EC2 Instance’s Security Group

How to change an EC2 Instance’s Security Group

A number of folks have asked me how to change an EC2 instance’s security group – Amazon’s documentation will tell you that “After you launch an instance in EC2-Classic, you can’t change its security groups” (from While this is technically true, creating a new instance that is a member of the security groups you wish and attaching the previous instance’s EBS volumes is an easy way to accomplish the same thing. Instructions below.

Modifying an EC2 Instance’s Security Group:

  1. Note instance attributes of the EC2 instance for which you wish to modify security group membership. For example, note the instance’s availability zone, AMI, instance-type.
  2. Shutdown the instance.
  3. Create a new instance. Use the same attributes as the previous instance: the same availability zone, the same AMI, the same instance-type. Make one modification – the security groups of this new instance should reflect the desired security group configuration.
  4. Note the new instance ID. Ensure that both the previous and new instances are in a “shut-down” state.
  5. Detach volume(s) from previous instance.
  6. Attach volume(s) to new instance.
  7. Startup the new instance – you’ll find that the new instance contains all the same data and attributes as the previous instance – the only difference will be the Security Group configuration of the new instance.

If you have any questions, comments or suggestions please feel free to comment.

Running fsck on EC2, Part 2

Running fsck on EC2, Part 2

This post describes a quicker method for running fsck on an EC2 instance’s root filesystem.

Create a “/forcefsck” file in the root filesystem and configure appropriately.

colin@devcolin:~$ sudo su -
root@devcolin:~# echo y > /forcefsck


The “y” character placed in the /forcefsck file will respond to all fsck prompts with the default “yes.” This will avoid the reported hangs if/when fsck prompts for user input on EC2 instance startup.

Restart the EC2 Instance

Wait for the system to restart.

Confirm that fsck Ran

You can confirm by:

  1. Examining the EC2 System Log from the AWS Console. Look for the lines:
    fsck from util-linux 2.20.1
    Checking disk drives for errors. This may take several minutes.
  2. Examine the “Last checked” time shown by the tune2fs utility:
    colin@devcolin:~$ sudo tune2fs -l /dev/xvda1 | grep "Last checked"
    Last checked: Wed Mar 5 05:59:01 2014


Running fsck on EC2, Part 1

Running fsck on EC2, Part 1

I encountered a situation where I wished to run fsck on an EC2 instance’s root filesystem. As running on fsck on a mounted filesystem is not recommended, I had two choices:

  1. Shutdown the EC2 instance, detach the EBS volume, attach this EBS volume to another EC2 instance and run fsck.
  2. Find a way to run fsck on the root filesystem during EC2 instance startup.

Running fsck during during EC2 instance startup is widely reported to be troublesome. The typical complaint is that fsck prompts for input at the console – an example of this problem is here: for an example.


How to run fsck on an EC2 instance’s root directory.

Longer method (see “Running fsck on EC2 – part 2” for a Quick and Dirty fsck Method)

The solution for running fsck on an EC2 instance’s root directory is described below. Note that this is tested on Ubuntu 12.0.4 LTS. The steps below describe a method for safely checking a root filesytem.

Enable root filesystem fsck

Open  /etc/fstab – example below:

sudo vi /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
/dev/xvda3 none swap sw,comment=cloudconfig 0 0

Change the value “fs_passno” for the root filesystem from “0” to “1”. The “fs_passno” number is the last column in the an fstab entry.

sudo vi /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 1

The default value of “fs_passno” is “0” – the “0” value specifies a filesystem that should not be checked by fsck – in other words, a default EC2 instance should not have fsck checks performed, presumably because this could cause problems if fsck prompted the user for input on startup. Changing this value to 1 designates the the /etc/fstab entry as that of the root filesystem – and of a filesystem that should be checked by fsck if a check is requested.

Set fsck to Automatically Fix Errors at Startup

The other part of this change requires setting your EC2 instance to automatically fix errors that fsck finds (so as to not prompt you at startup). Instructions are below:

Open /etc/default/rcS and change the FSCKFIX value

sudo vi /etc/default/rcS
#FSCKFIX=no is the default value for FSCKFIX


sudo vi /etc/default/rcS

Confirm the time that fsck was last run:

Use  tune2fs to determine the when fsck was last run on the root filesystem. By comparing the “Last checked” time given at this moment and after the restart you’ll be able to confirm that fsck ran.

colin@devcolin:~$ sudo tune2fs -l /dev/xvda1 | grep "Last checked"
Last checked:             Sat Jul 28 08:09:37 2012

Reboot the EC2 Instance.

I use the Amazon console or EC2 tools for this.

Confirm Reboot

colin@devcolin:~$ uptime
 07:51:22 up 1 min, 1 user, load average: 2.56, 0.81, 0.28

Confirm fsck Ran Correctly

colin@devcolin:~$ sudo tune2fs -l /dev/xvda1 | grep "Last checked"
Last checked:             Tue Mar  4 07:50:06 2014

Return /etc Files to Defaults

  1. In /etc/fstab, change the “fs_passno” to 0
  2. In /etc/default/rcS change FSCKFIX to FSCKFIX=no